Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)
On Sun, Dec 03, 2023 at 02:18:38AM -0600, Aaron Rainbolt wrote: > > [Catch 2] > While it is definitely possible to port the > openMSX tests to use catch2 v3, we will be departing from what > upstream supports, and that seems like it could lead to way more work > than necessary (for instance, what if the next major release of > openMSX still uses catch2 v2 and uses it in a way that's incompatible > with catch2 v3? Then we have to maintain that delta from upstream > ourselves, possibly for an extended period of time). You are misunderstanding me. First of all, I was expecting the changes to be minor. So I was thinking we can write a patch and let upstream use it. They are very responsive, so I would expect them to include our patch immediately. However, if it is a lot of work, it might be better to just file a bug report upstream. I would expect them to respond to that as well, by doing it themselves. Although it might take some time. So because we are in a bit of a hurry with openMSX dropping from testing, I think the approach for now is to use the bundled catch2-v2, and either port it for them, or let them know it needs to be ported. > One possible solution might be for Debian to ship multiple major > versions of catch2. I don't know enough about catch2 to know if that is a good idea. It might be, but it's certainly out of the scope of this problem. > Maybe this is something we can bring up to whoever maintains catch2 in > Debian. Yes, that sounds like a good idea. They will probably have an intelligent opinion about it. > I'm not so sure it's a Lintian bug since HTML files oftentimes *are* > compiled from other source code. They are, but Lintian is now very forceful in saying that files like these are definitely compiled, which is just false. So if there is no better way to detect this, at the very least the certainty of the problem should be decreased (from error to warning, for example). It is quite common for hand-written text files (including html files) to contain long lines and it is not reasonable for all those files to either be required to be line-wrapped, nor for all those packages to contain overrides. I think that due to the urgency, I'll make a new package based on your work and upload it. We can figure out how to handle the remaining issues after that. Thanks again, Bas signature.asc Description: PGP signature
Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)
Hi, This is starting to look great, thanks a lot of all the work. :-) However, I still see a few issues with it: - the references to C-BIOS in the XML configuration files should not be removed. When running, they are usually availably from the cbios package. And if the user didn't install that, OpenMSX will detect this and handle it properly. - The bundled catch2 should not be used. So the proper solution would be to port the code to the newer version, and to keep the bundled version out of it. Using the bundled version is acceptable as a temporary solution, but if we do that, we should file a bug report that the packaged version should be used again. - I prefer to not override the source-is-missing lintian messages. The reason is that there are 3 kinds of messages, each with their own solution: 1. An actual bug in the code. The solution is to fix the code. 2. A bug in Lintian. This code should not trigger the message. The solution is to fix Lintian. 3. A special (and rare) case. This code should not trigger the message, but it is unreasonable to expect Lintian to understand that. The solution is to add an override. IMO what we have here is 2, not 3. Adding an override implies that there is nothing wrong with Lintian's behavior, which is incorrect; there is a bug filed against Lintian for this and it should be fixed there. Unused overrides can unexpectedly hide actual problems, so when it gets fixed in Lintian, the overrides need to be removed, but it is unlikely that anyone will think of this, because there will not be a notification that the bug is fixed. Because of all this, I prefer to not silence Lintian. The messages do indicate an actual bug, it's just not in this package. Thanks, Bas On Wed, Nov 29, 2023 at 06:50:59PM -0600, Aaron Rainbolt wrote: > Alright, here's the latest openMSX package with all C-BIOS binaries patched > out. Now that there's no new binaries, I can just send this as a debdiff > attachment. Keep in mind all the binary files mentioned in the diff have to > be deleted from the source tree. > > Thanks for collaborating with me so we could come up with the best solution > possible for this! The debdiff is attached. > > -- > Aaron Rainbolt > Lubuntu Developer > Matrix: @arraybolt3:matrix.org > IRC: arraybolt3 on irc.libera.chat > GitHub: https://github.com/ArrayBolt3
Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)
On Wed, Nov 29, 2023 at 01:52:46PM -0600, Aaron Rainbolt wrote: > It appears that the C-BIOS package in Debian only ships the most recent > C-BIOS files. I think we can't just depend on it for this reason, since the > older C-BIOS ROMs are needed to avoid save state breakage. See > Contrib/cbios-old/README in the openMSX package. Well, in that case that problem exists right now as well, as the openmsx package does not include any version of cbios; it just Depends: on the cbios package. While I'm not sure if this is something that requires fixing (I need to think more about that), the proper way to fix it would be inside the cbios package, I think. Those copies are only included in openmsx for convenience; the cbios package (including old versions of it) is the source for those binaries. If they need to be installed, it should be done from the package that has their source. Copying the source to also be available in the openmsx package (where the binaries aren't even used) doesn't make sense to me. So as far as the openmsx package is concerned, I think we should just remove the binaries from the source package. Then the next step is to solve this problem (or decide that it does not need solving) in the cbios package. Thanks, Bas
Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)
Hi, Thanks a lot for not just finding those issues, but also fixing them! That is much appreciated. As for the license, Manuel (who is upstream) pointed out that the entire source code is (and always has been) GPL-2 only. The only issue with that is the packaging, which is GPL-3+. But that was my doing; the original was GPL-2 (I thought GPL-2+, but perhaps that isn't true and I wasn't even allowed to make it GPL-3+). In any case, I'll happily change the license to my work into GPL-2+, so that it is compatible with the rest of OpenMSX. Obviously the link should also point to GPL-2. As for cbios: I was not aware that it was included in the source tree. Fact is that it doesn't need to be; it is useful for running the system, but it is not even required for that and it is also not required for compiling it. If it were, I'd build-depend on the Debian package. So while I appreciate your efforts to track down and package the sources, I think the better approach is to remove the binaries from Debian's source package, just like the Windows dll. Do you agree that that would be a more elegant solution? Thanks, Bas On Mon, Nov 27, 2023 at 03:14:37PM -0600, Aaron Rainbolt wrote: > On 11/27/23 15:02, Manuel Bilderbeek wrote: > > On 27-11-2023 02:11, Aaron Rainbolt wrote: > > > Alright, I have fully rebuilt the copyright file. I also ended up > > > adding the source code for several releases of C-BIOS into the > > > packaging. As this code is in the form of zipped files for the sake > > > of size, it's not exactly practical to provide the new source > > > package changes as a debdiff since debdiffs don't communicate binary > > > file changes very well. So here's a .tar.gz of the new source > > > package tree, detach-signed with my GPG key. > > > https://github.com/ArrayBolt3/openmsx-packaging (I put it on GitHub > > > since Gmail didn't want to let me send the package as a file > > > attachment.) > > But why would you include the cbios sources in the openMSX package, as > > there is already a cbios package, which provides the binaries and has > > the sources as source package? > > Because openMSX vendors pre-built C-BIOS binaries, so therefore the source > package must include the sources for it to be DFSG compliant. See > https://www.debian.org/social_contract DFSG section 2. There is no build > dependency on C-BIOS since C-BIOS binaries are provided in openMSX rather > than sources. There is no binary dependency on C-BIOS either for the same > reason. A user who downloads the source for the Debian openMSX package will > not get all of the source, since there are multiple C-BIOS binaries with no > source code. openMSX does point to the C-BIOS sources on SourceForge, but > SourceForge isn't guaranteed to always exist. I do not think it is > sufficient for some of the sources the user should have been given to just > be "somewhere in the archive", leaving it up to the user to find them. > Including C-BIOS source in the source package of openMSX ensures that even > if all else fails (no upstream source, no way of pulling the C-BIOS source > package for some reason) a user will always get the sources for the software > they downloaded the source package of. > > > > > > > (You probably will notice some superfluous-file-pattern warnings > > > from Lintian when you build this - I do not understand why these are > > > occurring as the file patterns it's griping about are *not* > > > superfluous and don't appear to be overridden by any later > > > statements in the copyright file. I suspect a Lintian bug here.) > > > > > > > -- > > Kind regards, > > Manuel > > -- > Aaron Rainbolt > Lubuntu Developer > Matrix: @arraybolt3:matrix.org > IRC: arraybolt3 on irc.libera.chat > GitHub: https://github.com/ArrayBolt3
Bug#1056780: openmsx: Source-less Windows binary in source package (and other packaging issues)
Hi, First of all, thank you for the report and patch. I'll look in more detail shortly. However, after quickly looking over it, I have one question: you change the license from "GPL (any version)" to "GPL (version 2)". Why did you do that? The upstream license information is admittedly not very clear, but I certainly don't think it says this. Anyway, upstream is also monitoring the Debian BTS, so perhaps they can let us know what license version they intend to use. Manuel? There is code included that says "version 3 or later", so version 2 is not allowed for that. I had not checked license information for a while, but after checking now, I see one file which specifically says "version 2" as well. That may be a problem, but I think it will be fine; I'll check it. Anyway, relicensing the entire tree as "GPL2 only" is a pretty big change that doesn't seem like a good idea to me (and it's possibly incorrect/not allowed). What was your reasoning behind this? Thanks, Bas On Sun, Nov 26, 2023 at 12:35:15AM -0600, Aaron Rainbolt wrote: > Uh... ok so apparently either Gmail or the Debian BTS ate my patch, so > here's a second attempt, this time as a file attachment. > > Also, it appears that the openMSX maintainer's debian.org email address must > be pointing to an Apple support address since I've now gotten two "Thank you > for contacting us" emails from apple.com. > > -- > Aaron Rainbolt > Lubuntu Developer > Matrix: @arraybolt3:matrix.org > IRC: arraybolt3 on irc.libera.chat > GitHub: https://github.com/ArrayBolt3 > Binary files /tmp/phkMJNskDj/openmsx-19.1/Contrib/codec/Win32/zmbv.dll and > /tmp/Cd74GNmEnl/openmsx-19.1+dfsg/Contrib/codec/Win32/zmbv.dll differ > diff -Nru openmsx-19.1/debian/changelog openmsx-19.1+dfsg/debian/changelog > --- openmsx-19.1/debian/changelog 2023-09-01 01:39:39.0 -0500 > +++ openmsx-19.1+dfsg/debian/changelog2023-11-24 13:47:59.0 > -0600 > @@ -1,3 +1,25 @@ > +openmsx (19.1+dfsg-2) unstable; urgency=medium > + > + * Override spurious source-is-missing Lintian errors. > + * Don't build-depend on dpkg-dev, it's guaranteed to be installed in a > +Debian build environment. > + * Repack the upstream tarball to remove a prebuilt Windows binary. > +(Closes: #1056780) > + * Set 'DEB_BUILD_MAINT_OPTIONS = hardening=+all' in debian/rules. > + * Remove debian/source/include-binaries, every file listed in it doesn't > +exist. > + * Make debian/copyright point to more specific license files in > +/usr/share/common-licenses. > + * Set 'Rules-Requires-Root: no' in debian/control. > + * Use debhelper 13 rather than debhelper 10. > + * Override spurious package-contains-documentation-outside-usr-share-doc > +Lintian gripes. > + * Created debian/upstream/metadata file. > + * Switch back to using vendored catch2, the catch2 Debian package now ships > +catch2 v3 whereas openMSX uses catch2 v2. > + > + -- Aaron Rainbolt Fri, 24 Nov 2023 13:47:59 -0600 > + > openmsx (19.1-1) unstable; urgency=medium > >* New upstream release. > diff -Nru openmsx-19.1/debian/compat openmsx-19.1+dfsg/debian/compat > --- openmsx-19.1/debian/compat2017-08-06 07:57:22.0 -0500 > +++ openmsx-19.1+dfsg/debian/compat 1969-12-31 18:00:00.0 -0600 > @@ -1 +0,0 @@ > -10 > diff -Nru openmsx-19.1/debian/control openmsx-19.1+dfsg/debian/control > --- openmsx-19.1/debian/control 2023-08-03 02:11:39.0 -0500 > +++ openmsx-19.1+dfsg/debian/control 2023-11-24 13:47:59.0 -0600 > @@ -2,9 +2,10 @@ > Section: otherosfs > Priority: optional > Maintainer: Bas Wijnen > -Build-Depends: debhelper (>= 10), dpkg-dev, docbook-to-man, libsdl2-dev, > libpng-dev, tcl-dev, libgl-dev, libglew-dev, libsdl2-ttf-dev, python3, > libvorbis-dev, libtheora-dev, libogg-dev, libao-dev, libfreetype-dev, catch2 > +Build-Depends: debhelper-compat (= 13), docbook-to-man, libsdl2-dev, > libpng-dev, tcl-dev, libgl-dev, libglew-dev, libsdl2-ttf-dev, python3, > libvorbis-dev, libtheora-dev, libogg-dev, libao-dev, libfreetype-dev > Standards-Version: 4.6.2 > Homepage: https://openmsx.org > +Rules-Requires-Root: no > > Package: openmsx > Architecture: any > diff -Nru openmsx-19.1/debian/copyright openmsx-19.1+dfsg/debian/copyright > --- openmsx-19.1/debian/copyright 2021-06-17 06:21:11.0 -0500 > +++ openmsx-19.1+dfsg/debian/copyright2023-11-24 13:47:59.0 > -0600 > @@ -2,29 +2,31 @@ > Upstream-Name: openMSX > Upstream-Contact: https://web.libera.chat/#openMSX > Source: https://github.com/openMSX/openMSX/ > +Files-Excluded: Contrib/cod
Bug#1037804: Fixed upstream
control: tags -1 +fixed-upstream This bug has been fixed upstream. Since a new version is released soon, I'll wait for that. That fix will be included when it is packaged. Thanks, Bas
Bug#834472: vmmlib: Patch for address #834472 , #897845
Hi, Thanks for the help! I don't have time to test it now, but the patch looks good. Feel free to NMU without delay. Thanks, Bas On Wed, Oct 31, 2018 at 12:24:29AM +0800, Ying-Chun Liu (PaulLiu) wrote: > Hi all, > > I'll also do NMU in 10 days if nobody denies it. > > debdiff as attachment > > Yours, > Paul > > > -- > PaulLiu (劉穎駿) > E-mail: Ying-Chun Liu (PaulLiu) > diff -Nru vmmlib-1.0/debian/changelog vmmlib-1.0/debian/changelog > --- vmmlib-1.0/debian/changelog 2012-04-29 07:22:43.0 +0800 > +++ vmmlib-1.0/debian/changelog 2018-10-31 00:10:19.0 +0800 > @@ -1,3 +1,11 @@ > +vmmlib (1.0-2.1) unstable; urgency=low > + > + * Non-maintainer upload. > + * Add debian/patches/fix_ftbfs_gcc8.patch > +- Fix FTBFS on gcc8 (Closes: #897845) (Closes: #834472) > + > + -- Ying-Chun Liu (PaulLiu) Wed, 31 Oct 2018 00:10:19 > +0800 > + > vmmlib (1.0-2) unstable; urgency=low > >* Add dependency to build test suite. (Closes: #663949) > diff -Nru vmmlib-1.0/debian/compat vmmlib-1.0/debian/compat > --- vmmlib-1.0/debian/compat 2011-11-26 17:22:16.0 +0800 > +++ vmmlib-1.0/debian/compat 2018-10-29 16:05:44.0 +0800 > @@ -1 +1 @@ > -8 > +10 > diff -Nru vmmlib-1.0/debian/control vmmlib-1.0/debian/control > --- vmmlib-1.0/debian/control 2012-04-29 07:22:07.0 +0800 > +++ vmmlib-1.0/debian/control 2018-10-29 16:05:53.0 +0800 > @@ -2,7 +2,7 @@ > Section: libdevel > Priority: optional > Maintainer: Bas Wijnen > -Build-Depends: debhelper (>= 8), libblas-dev, liblapack-dev, libf2c2-dev > +Build-Depends: debhelper (>= 10), libblas-dev, liblapack-dev, libf2c2-dev > Standards-Version: 3.9.3 > > Package: libvmmlib-dev > diff -Nru vmmlib-1.0/debian/patches/fix_ftbfs_gcc8.patch > vmmlib-1.0/debian/patches/fix_ftbfs_gcc8.patch > --- vmmlib-1.0/debian/patches/fix_ftbfs_gcc8.patch1970-01-01 > 08:00:00.0 +0800 > +++ vmmlib-1.0/debian/patches/fix_ftbfs_gcc8.patch2018-10-29 > 19:46:59.0 +0800 > @@ -0,0 +1,142 @@ > +Description: Fix FTBFS on gcc-8 > + There are several build failed due to min/max/abs defined somewhere. > + We have to undef it to let it uses those from > +Author: Ying-Chun Liu (PaulLiu) > +Bug-Debian: https://bugs.debian.org/834472 > +Last-Update: 2018-10-25 > +Index: vmmlib-1.0/include/vmmlib/vector.hpp > +=== > +--- vmmlib-1.0.orig/include/vmmlib/vector.hpp > vmmlib-1.0/include/vmmlib/vector.hpp > +@@ -1,6 +1,10 @@ > + #ifndef __VMML__VECTOR__HPP__ > + #define __VMML__VECTOR__HPP__ > + > ++#undef min > ++#undef max > ++#undef abs > ++ > + #include > + #include > + #include > +Index: vmmlib-1.0/include/vmmlib/quaternion.hpp > +=== > +--- vmmlib-1.0.orig/include/vmmlib/quaternion.hpp > vmmlib-1.0/include/vmmlib/quaternion.hpp > +@@ -757,7 +757,7 @@ quaternion< T >::operator-=( const vecto > + x() -= xyz.x(); > + y() -= xyz.y(); > + z() -= xyz.z(); > +-return *this; > ++//return *this; > + } > + > + > +Index: vmmlib-1.0/tests/tensor3_test.cpp > +=== > +--- vmmlib-1.0.orig/tests/tensor3_test.cpp > vmmlib-1.0/tests/tensor3_test.cpp > +@@ -1,5 +1,9 @@ > + #include "tensor3_test.hpp" > + > ++#undef max > ++#undef min > ++#undef abs > ++ > + #include > + #include > + > +Index: vmmlib-1.0/tests/tucker3_tensor_test.cpp > +=== > +--- vmmlib-1.0.orig/tests/tucker3_tensor_test.cpp > vmmlib-1.0/tests/tucker3_tensor_test.cpp > +@@ -1,5 +1,9 @@ > + #include "tucker3_tensor_test.hpp" > + > ++#undef min > ++#undef max > ++#undef abs > ++ > + #include > + #include > + > +Index: vmmlib-1.0/tests/qtucker3_tensor_test.cpp > +=== > +--- vmmlib-1.0.orig/tests/qtucker3_tensor_test.cpp > vmmlib-1.0/tests/qtucker3_tensor_test.cpp > +@@ -1,4 +1,6 @@ > + #include "qtucker3_tensor_test.hpp" > ++#undef min > ++ > + #include > + #include > + > +Index: vmmlib-1.0/tests/tucker3_exporter_importer_test.cpp > +=== > +--- vmmlib-1.0.orig/tests/tucker3_exporter_importer_test.cpp > vmmlib-1.0/tests/tucker3_exporter_importer_test.cpp > +@@ -1,4 +1,5 @@ > + #include "tuc
Bug#894770: alternative workaround
Control: severity -1 important On Mon, Apr 30, 2018 at 05:34:02AM +0100, b...@hotsite.to wrote: > Just install the package arduino-mk Arduino-mk depends on arduino-core, which is provided by src:arduino. Due to the severity of this bug, all of that is about to be removed from testing. The justification that it renders the package unusable is obviously incorrect: the arduino-core part is still usable and also the gui can be used for developing, just not for testing. So even though this bug is important and needs to be fixed, it should not trigger a removal from testing. I'm lowering the severity for that reason. (I'm not the maintainer of Arduino, but I am the maintainer of arduino-mighty-1284p, which depends on arduino-core and would also be removed from testing.) Thanks, Bas signature.asc Description: PGP signature
Bug#817681: NMU for stx2any
Control: tags 817681 + patch
Control: tags 817681 + pending
Dear maintainer,
In order to avoid removal of my packages from testing, I've prepared an NMU for
stx2any (versioned as 1.56-2.1) and uploaded it to DELAYED/7. Please feel free
to tell me if I should delay it longer.
Thanks,
Bas
diff -u stx2any-1.56/debian/control stx2any-1.56/debian/control
--- stx2any-1.56/debian/control
+++ stx2any-1.56/debian/control
@@ -3,12 +3,12 @@
Priority: extra
Maintainer: Panu Kalliokoski
Build-Depends-Indep: w3m, m4
-Build-Depends: debhelper (>= 4)
+Build-Depends: debhelper (>= 9)
Standards-Version: 3.7.2
Package: stx2any
Architecture: all
-Depends: m4
+Depends: m4, ${misc:Depends}
Recommends: w3m, tidy, python (>= 2.1)
Description: Converter from structured plain text to other formats
stx2any is a converter from structured text (Stx), which is plain text
diff -u stx2any-1.56/debian/changelog stx2any-1.56/debian/changelog
--- stx2any-1.56/debian/changelog
+++ stx2any-1.56/debian/changelog
@@ -1,3 +1,10 @@
+stx2any (1.56-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Use debhelper compat level 9. (closes: #817681)
+
+ -- Bas Wijnen Mon, 20 Jun 2016 03:28:52 -0400
+
stx2any (1.56-2) unstable; urgency=low
* Updated standards-version
diff -u stx2any-1.56/debian/compat stx2any-1.56/debian/compat
--- stx2any-1.56/debian/compat
+++ stx2any-1.56/debian/compat
@@ -1 +1 @@
-4
+9
Bug#822650: Build environment details
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Martin, I can indeed reproduce it here. The problem seems to be that the new libstdc++ is more strict in the includes in requires. I've added two and it builds again. I'll upload a new package soon. Thanks for the report! For the impatient: both src/RTScheduler.cc and src/video/ZMBVEncoder.cc need: #include Thanks, Bas On Tue, Apr 26, 2016 at 01:02:14PM -0700, Martin Michlmayr wrote: > Hi Bas, > > * Bas Wijnen [2016-04-26 19:52]: > > Thanks for the report. Can you give more information on the build > > environment you used? What processor architecture, compiler > > version, versions of libraries that were used (especially > > libstdc++)? > > It's just a re-build of the package in a current Debian unstable > chroot (using sbuild). > > Seems like libstdc++6 is 6.0.1-2 in unstable now. > > I've to catch a flight soon but I can answer more questions later. > But you should see the failure in an up-to-date unstable chroot. > -- > Martin Michlmayr > Linux for HPE Helion, Hewlett Packard Enterprise -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJXJSG3AAoJEJzRfVgHwHE6cdUP/0mDAJfsVrXCwz98/VdFFg4Y JGBcEBO6qfZOnCGZtiZoUfHGaV4Wk/LcAy3hZpte+/GnRG1wcVotjohjazVy+64s IMaucXUUW2IScFKJOtbfAHHtmoWDFTeu7I1B5urkoTvXF2MX1P/t4t1avsz+yjHr OrBsd/BOcl5b1AW2vx+0VHeI6GNf5yry5SkOa5J4j4CCZOTSabTSPUf/yM6h1Ocy ONGPr9q5BnQiJpfoqnKyXMBTdPzsmSsg66NaE0mHwxvJ3+4A7DQug1wnJGUnH3y+ Li0Dj2SU/RMi7z/dTiYVSRdHRJL0bf034hGovlCkubUbdb6fcyrtM7o4s2vdeW+G G6G3xsbuEfqa3BLbf9zo+bipBnZlJwRMcKryDX/TR6XDZmYnlyuVaBRWmocDBQKV j9YCMQ0b3Fzoyucjkszg2QYp+X/NJan9TytvM0NrU8haRZjFObhzK3SsSQrdVyMk DFIKXoFO0uGaA3iCJdScEcePA1K4FcvLEsVz5jk+nbAd2OlyPDKAU2oBSTrZ2BRr I4bb6QbnsxYR1GVGVxQQ8V7S8A3oqgzh6JKywlHd8hx6BEBYhBNUnudlbvTSqZkx w0STLPtPvyhvv6BcXUjDwlY1iFRcpgreIOGXr1TsyC3A4cMPGQjt5s+6xDBVFxEh VF9L2yt0Th9T2BB+fQ3J =K+tJ -END PGP SIGNATURE-
Bug#822650: Build environment details
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Martin, Thanks for the report. Can you give more information on the build environment you used? What processor architecture, compiler version, versions of libraries that were used (especially libstdc++)? The report seems to be from a buildd, also because you're mentioning sbuild, but I don't see a failed build with this message on buildd.debian.org/openmsx/ so that confuses me a little. Some more information would be appreciated. Thanks, Bas -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJXH8bgAAoJEJzRfVgHwHE6nWwP/30uNNY0jxKXo8kPlyijVx1+ K+5ONfWHnnzjuqLpjHdGiFtbRE/YEwTVv+u5IBiA1c/Lkeot5H5WHmn3gO5CNtEo aV7aqMQhNcz8WDn8xjb8ir/pTqhtc4dCCvxlz91ub2notE80a75O2TXipODxdjYT PSk1+xmtIPJWlU4ctvoyV9E/dFiZYQsix7xDqrbfFx+vVYBuwqXIPj1nDbuLemjW GReOMbze8wXJWEYsfloiLXsrH9gY0foGWPHMc/UPdHQ/mVVbsFOXsTdnzAMZFdsB ORerw6/vhki38jCnT936UxhusGfq03+Zi+xlJNTvvCgzvENQa4vEz9HQFW095ejL IcSGKa6oi2EY+Tnoc4Clxzk8bnjc7TlQ/YRWTQzcp+boluGtjmZ6UIh+Y4nhZCMj VJW4rtaYBEIsst3WYfXqjD7IEwWhpAnO9NOCTco9D0s/uPILhVMTdbFIV2JNp8Kk O3yGQlL/CMkDThVJO1osyHroIj7uUDM7BBfYZg+Ymr1/dSBhHzeclyylvdr5iH/E rjq7JrL4kvTZhWchufmKidsGxIUWcdUW8O7tw1fVtFnPXKo8dbAIBDCevqDFhu+K 05uQpdvUU6+XppMW2MwDBnW6RbWfTCDE7jNxethWPJMbZO1e8y2ny8cDpcN2SJcq 7w+VgxdY/cGivQu2Hz88 =18/h -END PGP SIGNATURE-
Bug#818787: Mass Bug Filing: Missing Build-Depends: graphviz
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Mar 22, 2016 at 05:04:50PM +0100, Santiago Vila wrote: > So the number of affected packages if the default HAVE_DOT is changed > to "no" would be quite low. > > If, instead, doxygen is changed to depend on graphviz, there would be > nothing to report at all. I think that it is reasonable to use HAVE_DOT as the default (and add it to Depends in doxygen). The upside is that generated documentation is better; the downside is that builder machines need an extra package installed. Builders shouldn't be so low on resources that that is an issue for them. Thanks, Bas -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJW8XZVAAoJEJzRfVgHwHE6/WYP/AwmgDodFIJqVpr7yA1ETWCB t0dK+UyEtwpCUcnR9BMUM4K50tMn19EOzEktuogBxCWLfJWyMg8DnAa6cXke9kgQ lynbVl2T0nDIrSyGnSqx1Kqzy+K4FG6w6Hh/9qjKN3yCnTkNqo5ISlW0+pkRh2Ln VYHD9WG2Xy0Heu5cruyxX+Bx7ximzfTKNkH3duWD7ixEa1GQS3qaVd0ybSAAxb0R 4YoWK+2bY9n1ExTpU1qtKBxfwfJp30NS144I9TUjnKrR0b684kx75fv+TAI60B4j uBJtsBQ0YtyWAx+0BGl1uHiszG0PvXsvtmX07aLFUvTNe0jm+n0f8NbxK2wZ0+IR 6IMolkaQMy/tApBWXKKeGPDhF760iaERE/lK3Cfb/cEaS64i7h35loJg8itP87O1 SXee2vVkbByTHtMhM0KxwAAmXLYaLyhrEJWQQyFfstIbBT3yNpvo4r/V+F0kwxM+ s6QFBcZuuJ4MD44bm0Z3duRi9DhIid/oHwOw8akELAtPsKqkoFCzNMMeOMgXMysC J3UtShQ8iT39gMcJIZq8XSr8O2r3ohAVDfJAt53KRjnLIddZayUKgTwNzD3EMD2w jmUK0kg2thBlZbu+C1ElXjRTTcTJVmVjqpiyLt9dKYV4l74p7SAgU2wXpEbHuMtw 8DddW4ejVpMWWbBFw90W =QEB7 -END PGP SIGNATURE-
Bug#818787: Mass Bug Filing: Missing Build-Depends: graphviz
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Mar 21, 2016 at 11:26:16AM +0100, Santiago Vila wrote: > > Yes, so that's a bug in those programs, not in doxygen. It would be > > "fixed" by > > adding graphviz as a Depends to doxygen, but that would be incorrect. > > Please note that it is really doxygen who calls dot while those > programs are being built, not really those programs. And doxygen calls > dot because the HAVE_DOT variable is set to yes by doxygen, indicating > that the dot command is available. No, it is a configuration option which is set by the calling program. It defaults to yes, and for that reason it makes sense that there should be a Recommends relation. But the caller is not required to keep the default, so if it does, it is calling dot through doxygen. > Do you agree, at least, that it is not doxygen business to claim > that the dot command is available without a Depends? I just reread policy, and changed my mind on this. Policy says: The Depends field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality. The Recommends field should list packages that would be found together with this one in all but unusual installations. I wouldn't consider the graphs a "significant amount of functionality", but that is subjective. I'd leave it to the package maintainer to decide whether that is the case. Given that they chose to make HAVE_DOT the default, it seems that they do, so then a Depends would be in order. On the other hand, if they decide that it isn't, then the proper way to use doxygen with HAVE_DOT enabled (explicitly or as the default) is to depend on graphviz. So I agree that if HAVE_DOT defaults to yes, it should be a Depends relation. > Since we are all Cc:ing the bug address: This bug report is not to ask > doxygen to depend on graphviz, that would be only one of the two possible > outcomes. Agreed. Thanks, Bas -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJW8AViAAoJEJzRfVgHwHE6nVAP/Rz/av7mSDWdE2ZbLuhHi53h rLhES9CKE3YGIY7rXIyrKDIr3o2XiKYQtO4yLEhyBzxRPjMdxta2hnr/xUGyzlaW icR+/ugj9agt8oN11As/kTdr1HZVxjgyaGWAlbaNu6xrFFoK0EZ8atKmroPXtL6R jjfVJBDWpssX+G5oI4xWX0toVRCp6r9HYMuJIei33qDoSzyVekx0GUXaG/zSE5Pe tpKHR+swiYbM6d9s0MB7TyjTDDdN83XX9LnBEwXOtEn6FVeFJ1eBl2VgTXNF1wRu q01jIQFmdIgrpJey6GImfwA1uqrCg8QNqThvOA7//NY0iBXIb37jLNsi5ir90Ot5 LYakDtJtwpi6bq+AZo+THQ4AKChQX28PCuZHGAVbaDycbM0fhbfriJ6pqAQZ5Ut/ dZhjrP6FaPZ/AxowS14lv+tl5dreP9ZnaQE6yqNvKztPNp8AkQPerne0EPYlNr4I OFw4/CzOyMjaT7U7Hb0xjzJw5CHsZodjPkdTysgNzBfHsNLKsIzKiL29HtwA7bIR QNiuP9ANAgPIL/XYidiSpTVwrjj3kKKQ7/niAAwVRq4aPJBACKxYeT7Zy3a9BDDk mnmU4Ahfnu6Q6RB/wYKxChs/CZgadcGrWWuRUfELP/HEfHIig6PWLR5nFAuTBG9r YAgQtIkupO2lRRVOBqBM =5Z8f -END PGP SIGNATURE-
Bug#818787: Mass Bug Filing: Missing Build-Depends: graphviz
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, Mar 20, 2016 at 08:07:55PM +0100, Adam Borowski wrote: > On Sun, Mar 20, 2016 at 06:51:23PM +0000, Bas Wijnen wrote: > > That also means that programs calling dot will need graphviz in their > > Build-Depends, no matter what the default is. > > As is, a number of them do call dot without the build-dependency. Yes, so that's a bug in those programs, not in doxygen. It would be "fixed" by adding graphviz as a Depends to doxygen, but that would be incorrect. > > > The disappoining moral for this is that nobody looks at their build > > > logs... > > > > I don't think that's disappointing at all! It means we have built a system > > that will let us know when something is wrong. > > That would be the case if doxygen propagated the error, which it does not. And that _is_ a bug in doxygen, IMO. If it cannot produce the requested output, it should abort with an error. Thanks, Bas -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJW74DXAAoJEJzRfVgHwHE6jBIP/RbYo/q85gRUI5YIyEwAETF0 RLpIWDvWFvJRhg9TGfVA3VfeAmLrsOG59V6cwuszObY1I1VX1NVpJi1RoUTiZ9O2 d7l3boQ8YRb8ll3e49LLsfHoIWw6Tp30KjbrrvsOWjH/18NDZkEK89uXFzK+/U8/ kDMADNsFvpo6/5MzSp59LSn7+YvKKuOOSypkPR2K1DzYhCL8lPno3lq8lCX6uAz/ oXjwIuFMR1KNJx/pxL9DeM+bP+9qwe0xQlL48C7kuGzvyT0ZF2gofETtlHvAbrQe Mg3y7EbBKU6hNLi7hs9KqI8G9h+9FuyI5jeyNv0ixQQrtbDWlY8j2LBOQbwBGnNO PeSQ0e+HmcRQgPCqBcysGxmCfTpJmfS+lAC5Q3ip62sVHIQzot/GnQBUBVZLUi2W JGBF+JJirQ33cIw8v67Uguy4GO3/ba/I+NZFKug4poPvskmuVhMJHB0gU5Nr3mL0 Sn3dC54mzPtQk6Eq8oace9hZl39v3dHhWG/Oce/dL8sKhwkIUhc19LGk/mc0aHCQ FC2bTVLMeCM3ZjCso1piXA10WeD5JFK2hg4B4sQCtbePQLfWXTsLsKSkNdEWqpU3 NeEeMtVaQwyMV0WRQD5JKSoClpTSsQf7cF+c+U3IKVOhkZJpwh8TKUQASo9f6Ywe Rj66EyyM2s72+7qVxS9Z =fTpp -END PGP SIGNATURE-
Bug#818787: Mass Bug Filing: Missing Build-Depends: graphviz
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I think you are mistaken about a few things. On Sun, Mar 20, 2016 at 06:04:55PM +0100, Santiago Vila wrote: > The maintainer points out that the default value for HAVE_DOT is NO, > so he's reluctant to add the build-dependency. If the program can be used without it, it should not be a Depends. That's what Recommends are for. Default values have nothing to do with it; Depends are for things that will make the program unusable if they aren't present, Recommends are for things that should almost always be installed with the program. That also means that programs calling dot will need graphviz in their Build-Depends, no matter what the default is. > But this is inconsistent with having graphviz in the Suggests line for > doxygen. I agree that if it is the default, it should be Recommends, not Suggests. This doesn't change anything for the problem you're describing, however. > The disappoining moral for this is that nobody looks at their build logs... I don't think that's disappointing at all! It means we have built a system that will let us know when something is wrong. That means we don't need to poll for errors, because they will be pushed to us. (I think porters are still doing this manually at least some of the time; I think FTBFS bugs should be reported automatically.) In other words, my solution to this bug would be to make doxygen exit with an error code when calling dot fails. Then make will fail, it's an FTBFS, it gets fixed, and everyone is happy. Thanks, Bas -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJW7vEqAAoJEJzRfVgHwHE6Gm4QAKAhBvdYk+2kTZ6SKTjgH/B0 4OIBO8nSOJe+O5yTB3AordZq2zZS1afM0oWB3JiVfa6l6Ka9dfC8f9TOlvW5xGnm pj0OO7b7jrH5oK5XToqj3DvDphNKpNwWnHKbeBWlJY779SVBa50kdwnbtg77wa5k ZBl1NWLFlFeRgjbG6BQpn1l50NyRLMzTumLFtF+rpZACAwoiH+bkJVDlu83lfM72 /B4WLl9G7wxnhwhtfs2PcvRaYF8EzGuNDizu2PbwCp31CKUszF4+0q9JiqHtTwmV VIFxB31fSU/RpmEIxI086wStd/Rax+Cn8HfAyTY6/tIOVBCeHYnNajWZkVEcNsoj srsaGpPEGJouGr/MLqQIk5n6LLsiERq4aha5WpmccmgkNCxTIUXZlU62J6y5DzlT lDkG5NXkEuf1qsk9bUJQEAbvdCKfbX6mtlbibxtGlSpeZ6LwfsQ+M9MoX300kH84 UYHMovo6M9CHXLdxt9AJOVBJTbERXbKVysnrov2pVlZSZiPFu7M/haz6Um13Vsku AlIpYRYpfTRiNZ/dg1Tf0AtnMkSIqhy1441Jj+Egpe9EXAs9GfWaYNOa1yZYm1d8 1Wcbh0NdzakVDNmTWuPg47bGt7IOGUcgM74DQuRLCWxcaOOnErs0nI7+3x3kZ+5/ 77few9WmaB+ZHhDWb+Vv =AU0O -END PGP SIGNATURE-
Bug#750918: Fixed in last upload
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Aug 11, 2015 at 06:24:42AM +0100, Olly Betts wrote: > The wx BD has reverted to libwxgtk2.8-dev in 0.11.0-1: How did that happen? I thought I removed every trace of the old library from my system... I'll make sure I do that now. I think a binNMU would fix this bug, right? Thanks, Bas -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJVy5uuAAoJEJzRfVgHwHE6Wt0P/1EJB5AAE9KGjgWj6/fKOX/6 x90KQjkPeP8KAU5gCW/NnQvRW5MmJd8Km4ezOr8dckt2uuUZ+1sdUD8Uuz7Odnht uk2g7T2KjCZDD9brVcdTWxWzKeK2QHZdsfBbWKSHdeqRgGNV0UkV3HaT6qsouTgS KyIKaPPprkWXPxPN2xw99GRqTRd6IGoZiWSffLTyADGr5arFNmoW5OnzedAwMpdc nZyKmRdfQRpVeJP/9xC9csE7w3ZOWI6oNpxQushpV50E09FDISzvB86Zbd/+nDYI K/s/c/6E5+oYTXHV6fUCLghy1yw+Oy4rzGnmfQpWadse916yaF9xBj5LZXlXS80c +hksDABCQbcNFRWJP8WKx1FmSPCRQ6fGYKENGxrikg5j8HnAZxFTBauTvadXtGhK 8ZXHPaPOTTym60Zeax794VxqK0S9558aDSyanv+Aa6+63peJgKn3f1bohURZeKYD 05UwzHtjmKdmulaC28dc1M+gCTPISK6X/EKnq2Oro2M/ZPQIwPiWlCnzcxilYgup NRBA+Y3dkZic9BBtt3E3YfjCv/5OOQHhw5f6ndOrjSzzQYUkJCbuf/XbOJ5bZzIh mcFB9KcFX2TZwoLzEm0kIXjllTnFR33wQ8BFI7lEeEBHG54vn2TV9eAD0+EQYnNk sSlwkVNFUBG6GBBzk2V9 =PE7N -END PGP SIGNATURE-
Bug#754757: timeout during g++
On Thu, Sep 25, 2014 at 09:50:10PM +1000, Aníbal Monsalve Salazar wrote: > Please see Dejan's patch at the end of message #25 of bug #754757: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754757#25 Thanks for the reply. I've seen that patch, but it turns optimization off. As I wrote, I think that is undesirable. Do you mean to say that the mips team does not want to have this package compiled with optimization? That seems like a bad idea to me, but if that's what you want, I'll do it. Thanks, Bas signature.asc Description: Digital signature
Bug#754757: timeout during g++
Hello Mips-porters, My package, openmsx, failed to build on mips due to a compiler timeout. (#754757) Looking at the earlier successful buildd logs, it has always taken quite long to build. In the bug it was reported that compilation does succeed if it is not interrupted, so the compiler doesn't hang. It can be worked around by disabling optimization, but my guess is that if even the buildds are so slow, mips users will need all the optimization they can get. What do you suggest I do? My preference would be to get the timeout value increased, so that it will build as is. Is that an option? Thank you, Bas Wijnen Ps: Please Cc me on replies, I'm not subscribed. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#759250: [3dprinter-general] Bug#759250: arduino-mighty-1284p: FTBFS - inttypes.h: No such file or directory
On Tue, Sep 09, 2014 at 07:06:42PM +0100, Marcos Marado wrote: > This can be solved by adding avr-libc to the Build-Depends. Great, thanks for that! I'll upload that fix in a moment. Thanks, Bas signature.asc Description: Digital signature
Bug#754757: openmsx: FTBFS on mips: timeout during g++
Ok, I should read things better. This bug was in openmsx, not openmsx-catapult. Ignore my previous reply. However, as Manuel writes, I don't see anything mips-specific here. "Build killed with signal TERM after 300 minutes of inactivity" sounds like something is hanging, or otherwise the buildd is very slow (my guess is "inactivity" means "didn't finish yet"). The latter is an option: previous builds on mips took more than 3 hours as well. I wouldn't expect that to almost double with this version, but is it possible that nothing was wrong and it simply didn't finish in the 300 minutes? Don't other packages have problems with this limit? Thanks, Bas On Mon, Jul 14, 2014 at 02:28:48AM +0200, Cyril Brulebois wrote: > Source: openmsx > Version: 0.10.1-1 > Severity: serious > Justification: FTBFS > > Hi, > > your package no longer builds on mips: > | Compiling video/scalers/HQ2xScaler.cc... > | g++ \ > | -MP -MMD -MF derived/mips-linux-debian/dep/video/scalers/HQ2xScaler.d \ > | -o derived/mips-linux-debian/obj/video/scalers/HQ2xScaler.o -g > -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -O3-pipe > -std=gnu++0x -Wall -Wextra -Wundef -Wunused-macros > -Wno-missing-field-initializers -Wzero-as-null-pointer-constant -Isrc > -Isrc/cassette -Isrc/commands -Isrc/config -Isrc/console -Isrc/cpu > -Isrc/debugger -Isrc/events -Isrc/fdc -Isrc/file -Isrc/ide -Isrc/input > -Isrc/laserdisc -Isrc/memory -Isrc/security -Isrc/serial -Isrc/settings > -Isrc/sound -Isrc/thread -Isrc/utils -Isrc/video -Isrc/video/ld > -Isrc/video/scalers -Isrc/video/v9990 -Iderived/mips-linux-debian/config > -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/SDL > -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/freetype2 -I/usr/include/libpng12 > -I/usr/include/tcl8.5 -I/usr/include/libxml2 -c > src/video/scalers/HQ2xScaler.cc > | E: Caught signal ‘Terminated’: terminating immediately > | make[2]: *** [derived/mips-linux-debian/obj/video/scalers/HQ2xScaler.o] > Terminated > | make: *** [build-arch] Terminated > | make[1]: *** [override_dh_auto_build] Terminated > > Full build log: > > https://buildd.debian.org/status/fetch.php?pkg=openmsx&arch=mips&ver=0.10.1-1&stamp=1405264499 > > Mraw, > KiBi. signature.asc Description: Digital signature
Bug#754757: openmsx: FTBFS on mips: timeout during g++
Control: notfound -1 0.10.1-2 Hi, Thanks for the report. I'm not sure what the problem was, but the new version (which is identical except for the wxwidgets dependency) built fine. I'm guessing it was an issue with the buildd. I'm closing this bug, because the package is now built by the buildd and present in unstable. Thanks, Bas On Mon, Jul 14, 2014 at 02:28:48AM +0200, Cyril Brulebois wrote: > Source: openmsx > Version: 0.10.1-1 > Severity: serious > Justification: FTBFS > > Hi, > > your package no longer builds on mips: > | Compiling video/scalers/HQ2xScaler.cc... > | g++ \ > | -MP -MMD -MF derived/mips-linux-debian/dep/video/scalers/HQ2xScaler.d \ > | -o derived/mips-linux-debian/obj/video/scalers/HQ2xScaler.o -g > -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -O3-pipe > -std=gnu++0x -Wall -Wextra -Wundef -Wunused-macros > -Wno-missing-field-initializers -Wzero-as-null-pointer-constant -Isrc > -Isrc/cassette -Isrc/commands -Isrc/config -Isrc/console -Isrc/cpu > -Isrc/debugger -Isrc/events -Isrc/fdc -Isrc/file -Isrc/ide -Isrc/input > -Isrc/laserdisc -Isrc/memory -Isrc/security -Isrc/serial -Isrc/settings > -Isrc/sound -Isrc/thread -Isrc/utils -Isrc/video -Isrc/video/ld > -Isrc/video/scalers -Isrc/video/v9990 -Iderived/mips-linux-debian/config > -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/SDL > -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/freetype2 -I/usr/include/libpng12 > -I/usr/include/tcl8.5 -I/usr/include/libxml2 -c > src/video/scalers/HQ2xScaler.cc > | E: Caught signal ‘Terminated’: terminating immediately > | make[2]: *** [derived/mips-linux-debian/obj/video/scalers/HQ2xScaler.o] > Terminated > | make: *** [build-arch] Terminated > | make[1]: *** [override_dh_auto_build] Terminated > > Full build log: > > https://buildd.debian.org/status/fetch.php?pkg=openmsx&arch=mips&ver=0.10.1-1&stamp=1405264499 > > Mraw, > KiBi. signature.asc Description: Digital signature
Bug#750918: Fixed in last upload
Yes, I'll upload a new version this week. Thanks, Bas On Sun, Jul 27, 2014 at 03:01:25PM +0200, Manuel Bilderbeek wrote: > Hi, > > On 22-07-14 02:43, Olly Betts wrote: > >On Thu, Jul 10, 2014 at 02:52:35AM +0200, Bas Wijnen wrote: > >>I forgot to close this bug in the changelog of the last upload; the new > >>upstream release fixes it. > > > >Although the new upstream release apparently adds wx3 support, you > >didn't update the build dependencies in debian/control, so you're still > >building against wxwidgets2.8. > > Can one of you fix this please? Would be a pity if it would get > removed because of this small (but rather crucial ;-) mistake... > > -- > Grtjs, Manuel > > PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ ) > PPS: Visit my homepage at http://manuel.msxnet.org/ signature.asc Description: Digital signature
Bug#754340: Unable to run fsck manually when instructed to do so
Package: systemd-sysv Version: 204-14 Severity: critical Justification: impossible to boot system (The severity seems inflated, but it didn't fit any of the lower RC levels and it should be RC IMO. It is also pretty easy to fix, I hope, so I'd suggest doing that instead of worrying about the proper severity.) My system had some serious hard drive problems and because of that remounted my root file system read-only. Before investigating anything, I rebooted the system to see if that would solve anything. On reboot, fsck was run and it failed, telling me to run it manually. Then it provided me a shell. So far so good. However, fsck / failed because the filesystem was mounted read-write. mount / -o remount,ro failed because the filesystem was busy. This being my only computer at that moment, I did not have internet to look up how to do this in systemd (which I'm guessing has a way to make remounting read-only work, but I'm not familiar with it). The only reason I was able to continue, was that after some trying it hit a bad file and automatically remounted the filesystem read-only. At that point, I could run fsck and it would boot again, allowing me to proceed with diagnosing the problem. My suggested solution is to document the method for remounting the root filesystem read-only (or the method for getting help on the commands that do such things) in the error message that says fsck must be run manually, or perhaps whenever a shell is spawned so early during boot. This is essential to be able to rescue the system, and since it's changed compared to how it worked for decades, you can't assume that everyone knows how to do it. This is even more important given systemd's dependency scheme which installs it on machines where the owner isn't aware of it. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.14-1-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages systemd-sysv depends on: ii systemd 204-14 systemd-sysv recommends no packages. systemd-sysv 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#740297: crashes on startup
Package: pcb2gcode Version: 1.1.4-git20110915-1 Severity: grave Tags: upstream patch Justification: makes package unusable Pcb2gcode crashes when starting. In Ubuntu, there is a patch to fix this: http://patches.ubuntu.com/p/pcb2gcode/pcb2gcode_1.1.4-git20110915-1ubuntu3.patch (This patch contains some junk, but the actual fix (in options.cpp) is easy to filter out.) Thanks, Bas -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.12-1-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages pcb2gcode depends on: ii gerbv 2.6.0-1 ii libatk1.0-0 2.10.0-2 ii libboost-program-options1.54.0 1.54.0-4 ii libc6 2.18-3 ii libcairo2 1.12.16-2 ii libcairomm-1.0-11.10.0-1 ii libfontconfig1 2.11.0-5 ii libfreetype62.5.2-1 ii libgcc1 1:4.8.2-16 ii libgdk-pixbuf2.0-0 2.30.5-1 ii libglib2.0-02.38.2-5 ii libglibmm-2.4-1c2a 2.36.2-1 ii libgtk2.0-0 2.24.22-1 ii libgtkmm-2.4-1c2a 1:2.24.4-1 ii libpango-1.0-0 1.36.0-1+b1 ii libpangocairo-1.0-0 1.36.0-1+b1 ii libpangoft2-1.0-0 1.36.0-1+b1 ii libpangomm-1.4-12.34.0-1 ii libsigc++-2.0-0c2a 2.2.11-3 ii libstdc++6 4.8.2-16 pcb2gcode recommends no packages. pcb2gcode suggests no packages. -- no debconf information signature.asc Description: Digital signature
Bug#724944: xserver-xorg-video-intel: segfaults when trying to play movies
Package: xserver-xorg-video-intel Version: 2:2.21.15-1+b1 Severity: grave Justification: kills entire session; including applications running on it, which likely results in data loss. I can reliably crash the X server by starting almost any video with almost any player. At least mplayer, xine, totem, and xawtv (showing images from my webcam) have managed to crash it. Log file attached. If you need debugging symbols or anything like that, let me know how to generate it and I'm happy to send it. The only way I have currently found to play video without crashing X, is using mplayer -vo x11. I think that disables a lot of hardware acceleration, but I'm by no means an expert on this topic. Thanks, Bas Xorg.0.log.old Description: application/trash
Bug#718454: arduino-mk: diff for NMU version 0.10-2.1
Control: tags 709115 + patch Control: tags 709115 + pending Control: tags 718454 + patch Control: tags 718454 + pending Dear maintainer, As mentioned in my previous e-mail, I've prepared an NMU for arduino-mk (versioned as 0.10-2.1) and uploaded it to DELAYED/8. Please feel free to tell me if I should delay it longer. Thanks, Bas diff -Nru arduino-mk-0.10/debian/changelog arduino-mk-0.10/debian/changelog --- arduino-mk-0.10/debian/changelog 2013-05-05 19:19:39.0 -0400 +++ arduino-mk-0.10/debian/changelog 2013-07-31 19:21:50.0 -0400 @@ -1,3 +1,11 @@ +arduino-mk (0.10-2.1) UNRELEASED; urgency=low + + * Non-maintainer upload. + * Use $(wildcard) on list of file types. (Closes: #718454) + * Add default variables for Debian systems. (Closes: #709115) + + -- Bas Wijnen Wed, 31 Jul 2013 19:19:58 -0400 + arduino-mk (0.10-2) unstable; urgency=low * Merge from experimental to unstable diff -Nru arduino-mk-0.10/debian/patches/line_count.patch arduino-mk-0.10/debian/patches/line_count.patch --- arduino-mk-0.10/debian/patches/line_count.patch 2013-05-05 19:18:32.0 -0400 +++ arduino-mk-0.10/debian/patches/line_count.patch 2013-07-31 18:56:22.0 -0400 @@ -3,10 +3,10 @@ Author: Ben Hildred Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702754 Forwarded: https://github.com/mjoldfield/Arduino-Makefile/pull/34 -Index: arduino-mk/arduino-mk/Arduino.mk +Index: arduino-mk-0.10/arduino-mk/Arduino.mk === arduino-mk.orig/arduino-mk/Arduino.mk 2013-05-05 18:24:20.084212878 -0400 -+++ arduino-mk/arduino-mk/Arduino.mk 2013-05-05 18:24:20.076212877 -0400 +--- arduino-mk-0.10.orig/arduino-mk/Arduino.mk 2013-07-31 18:54:47.353399980 -0400 arduino-mk-0.10/arduino-mk/Arduino.mk 2013-07-31 18:56:16.565390945 -0400 @@ -490,7 +490,12 @@ CORE_LIB = $(OBJDIR)/libcore.a @@ -39,8 +39,8 @@ $(CORE_LIB): $(CORE_OBJS) $(LIB_OBJS) $(USER_LIB_OBJS) $(AR) rcs $@ $(CORE_OBJS) $(LIB_OBJS) $(USER_LIB_OBJS) -+$(LIB_DEP_FILE): $(OBJDIR) *.ino *.cpp *.c *.h *.pde -+ grep -h '^[ ]*#[ ]*include[ ]*<' -- *.ino *.cpp *.c *.h *.pde|sed 's!^.*<\(.*\)\.h>.*!\1!'|sort -u|xargs -d '\n' echo 'ARDUINO_LIBS =' > $(LIB_DEP_FILE) ++$(LIB_DEP_FILE): $(OBJDIR) $(wildcard *.ino *.cpp *.c *.h *.pde) ++ grep -h '^[ ]*#[ ]*include[ ]*<' -- $(wildcard *.ino *.cpp *.c *.h *.pde)|sed 's!^.*<\(.*\)\.h>.*!\1!'|sort -u|xargs -d '\n' echo 'ARDUINO_LIBS =' > $(LIB_DEP_FILE) + echo >> $(LIB_DEP_FILE) + $(DEP_FILE): $(OBJDIR) $(DEPS) diff -Nru arduino-mk-0.10/debian/patches/mjo_makefile_debianise arduino-mk-0.10/debian/patches/mjo_makefile_debianise --- arduino-mk-0.10/debian/patches/mjo_makefile_debianise 2013-03-10 17:18:49.0 -0400 +++ arduino-mk-0.10/debian/patches/mjo_makefile_debianise 2013-07-31 19:28:15.0 -0400 @@ -3,11 +3,11 @@ Origin: vendor Forwarded: not-needed -Index: arduino-mk/arduino-mk/Arduino.mk +Index: arduino-mk-0.10/arduino-mk/Arduino.mk === arduino-mk.orig/arduino-mk/Arduino.mk 2012-11-09 11:51:17.281716281 -0500 -+++ arduino-mk/arduino-mk/Arduino.mk 2012-11-11 10:27:28.524096850 -0500 -@@ -120,10 +120,10 @@ +--- arduino-mk-0.10.orig/arduino-mk/Arduino.mk 2013-07-31 19:26:09.233366380 -0400 arduino-mk-0.10/arduino-mk/Arduino.mk 2013-07-31 19:28:05.029337760 -0400 +@@ -120,12 +120,19 @@ # ARDUINO_DIR = /Applications/Arduino.app/Contents/Resources/Java # ARDMK_DIR = /usr/local # @@ -19,8 +19,17 @@ +# ARDMK_DIR = /usr # AVR_TOOLS_DIR = /usr # ++# These are set up as defaults in this Debian version of this Makefile. ++# If your Makefile sets other values, they will override these defaults. ++# Additionally, a default for ARDUINO_PORT is set to ++# /dev/ttyACM* /dev/ttyUSB* ++# This means that on GNU/Linux system you shouldn't need to specify ++# the port in most cases. ++# # You can either set these up in the Makefile, or put them in your -@@ -154,7 +154,7 @@ + # environment e.g. in your .bashrc + # +@@ -154,7 +161,7 @@ # BOARD_TAG= uno # ARDUINO_PORT = /dev/cu.usb* # @@ -29,7 +38,7 @@ # # Hopefully these will be self-explanatory but in case they're not: # -@@ -237,10 +237,10 @@ +@@ -237,10 +244,10 @@ # ARDUINO_DIR = /Applications/Arduino.app/Contents/Resources/Java # ARDMK_DIR = /usr/local # @@ -42,3 +51,16 @@ # AVR_TOOLS_DIR = /usr # # +@@ -290,6 +297,12 @@ + ARDUINO_VERSION = 100 + endif + ++# Set up defaults for Debian ++ARDUINO_DIR ?= /usr/share/arduino ++ARDMK_DIR ?= /usr ++AVR_TOOLS_DIR ?= /usr ++ARDUINO_PORT ?= /dev/ttyACM* /dev/ttyUSB* ++ + + # Arduino and system paths + # signature.asc Description: Digital signature
Bug#718454: arduino-mk: Doesn't work at all
Package: arduino-mk Version: 0.10-2 Severity: grave Justification: make will always fail with this Makefile The line number patch to the Makefile has a problem: it requires one of each file type candidates to be present, including *.ino and *.pde, but if both of these two are present, it will (rightfully) fail to build anything. I'm preparing an NMU for this, which I shall upload to DELAYED/8 in a moment. Because there was no reply to my suggestion in bug #709115, which I submitted more than two months ago, I'm assuming that you agree this is a good idea and I'm including this in the NMU as well. This is by no means intended to force anything onto you as a maintainer; please feel free to request a different fix, or ask me to cancel the upload altogether so you can fix it yourself. Thanks, Bas Wijnen signature.asc Description: Digital signature
Bug#690394: Bug#690877: unblock: love/0.8.0-3
On 23-12-12 00:37, Ivo De Decker wrote: > I prepared a TPU upload to fix the copyright file bug (#690394) in wheezy. The > debdiff is attached. Looks good. However, version 0.8.0-3 is already in unstable, so please make the version 0.8.0-2.1 instead. Will you upload the package? > I also included a lintian override for the ftp-master autoreject (bug > #690492). I don't know if this is needed for TPU uploads. As Julien downgraded > bug #690492 from serious to important, I suspect the embedded copy of glee can > stay for wheezy. In don't usually like lintian overrides, but I suppose this is a good use for one. Still I'd prefer the error to be visible, and override the autoreject instead of lintian itself... Thanks, Bas signature.asc Description: OpenPGP digital signature
Bug#693663: This driver is too buggy to live
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 tags 693663 + confirmed thanks Hello Ben, Thank you for your work to document all these issues. If there would be an alternative, I would not hesitate to get rid of this module. Unfortunately, there isn't. This module was originally written for Linux 2.6.8, including (almost) all the bugs, by the manufacturer of the hardware. I adjusted it so it uses dkms and can compile on newer kernels. I noticed the bad coding, but didn't start fixing all the bugs so far. If I would give priority to this package, I would try to rewrite it so that it conforms to v4l2. As it is now, the only reasonable (and documented) way to use it is through a non-free library provided by the hardware producer. Now that I think about it, this means it really belongs in contrib. I am using this module, and I (manually) make sure that I don't have any races. I agree that this should be done by technical means. Also, I think I see some of the other problems you describe (in particular the memory leakage). I'm interested to get this fixed, but not so interested that I've started doing it already. Summarizing: - - I agree that this module should not be in a stable release. - - I think it does deserve to be in unstable, because people with this hardware want to use it on Debian; this support is better than no support. - - I very much invite people to help and fix the issues. - - I'll make some changes to the description to make clear that the module is buggy. Thanks, Bas On 19-11-12 04:20, Ben Hutchings wrote: > Package: pvcam-dkms Version: 4.1.0-2 Severity: grave > > There is a complete lack of locking, memory barriers or anything > that could protect against races: > > - Two tasks calling device_open() on the same camera at the same > time may race and succeed, which violates the assumption that: /* > With the Linux driver - each camera */ /* is totally exclusive use! > */ - Two tasks may race in device_ioctl() on the same file. - The > ISR is not synchronised with the tasks requesting I/O. > > A failed device_ioctl() may mark the camera closed, but doesn't > prevent the same file handle from being used, so again there can be > two file handles for the same camera. > > Various functions can return positive numbers (= success) for > errors. > > device_ioctl() doesn't consistently check whether copy_from_user() > or copy_to_user() succeeded. > > pvcam_create_buffer() doesn't map memory correctly: virt_to_bus() > doesn't generally work for PCI devices, and won't translate NULL to > 0, so in case memory allocation fails it will not abort. > > pvcam_write_read() assumes little-endian byte order on the host. > > loadPCIflash() reads directly from user addresses without using > copy_from_user(). > > Unimplemented functions quietly do nothing instead of returning a > meaningful error. > > In most error cases that the driver actually bothers to check for, > it immediately returns without clearing up resources that have been > allocated. This can result in a crash or resource leak. > > Ben. > > -- System Information: Debian Release: wheezy/sid APT prefers > stable-updates APT policy: (500, 'stable-updates'), (500, > 'proposed-updates'), (500, 'unstable'), (500, 'stable'), (1, > 'experimental') Architecture: i386 (x86_64) Foreign Architectures: > amd64 > > Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: > LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh > linked to /bin/dash > > Versions of packages pvcam-dkms depends on: ii dkms 2.2.0.3-1.2 > > Versions of packages pvcam-dkms recommends: pn libpvcam > > pvcam-dkms suggests no packages. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlC3SK8ACgkQFShl+2J8z5WOsACfV2hhEWamjOPcO9+E2ssA8mDM V2EAoJZ+1tgbVlCQI75wyZN5qfF2Fov9 =kFtF -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#690370: Upload rejected
On Tue, Oct 23, 2012 at 07:47:29PM +0200, Luca Falavigna wrote: > The upload has been rejected because of the following lintian error: > embedded-library usr/lib/python2.6/dist-packages/fife/_fife.so: glee I had the same problem with love. It was trivial to switch from the upstream-provided copy to the Debian package; see the patch in love's svn for details. (The fact that Miriam had already written most of the patch made it even more trivial, I just had to activate the code; thanks Miriam. :-) ) Thanks, Bas signature.asc Description: Digital signature
Bug#639405: This bug seems outdated
Bugs similar to this one were filed for python 2.7 and python 3. There they were fixed by removing those files. They could be fixed for this package in the same way. Is it because python 2.6 is about to be removed anyway that this didn't happen? signature.asc Description: Digital signature
Bug#690492: love_0.8.0-2_i386.changes REJECTED
Hi again, I solved this bug by using the already present code to replace GLee with the system version. For this package, that means the problem is solved (the package got accepted), but you may want to be less strict with autorejections in cases like this one. Thanks, Bas On Mon, Oct 15, 2012 at 08:41:48AM +0200, Bas Wijnen wrote: > On Sun, Oct 14, 2012 at 11:05:28PM +0200, Ansgar Burchardt wrote: > > > Update: this bug was already worked around in the Debian package: the > > > files included by upstream are not used, and the debian library package > > > is used instead. The embeded copy is in the upstream source, and that is > > > an upstream bug (which should trigger the lintian warning). > > > > Are you sure the Debian package does not use the embedded copy? The > > lintian error seems to be triggered by the binary package (as it > > includes the path). > > I was pretty sure, but you seem to be right. Ah, now I see: here's the > entry from the changelog: > * Tried to removed internal glee, but it doesn't seem to like the > system's one > > So it wasn't used, indeed. > > Thanks for the clarification, > Bas > ___ > Pkg-games-devel mailing list > pkg-games-de...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-games-devel signature.asc Description: Digital signature
Bug#690492: love_0.8.0-2_i386.changes REJECTED
On Sun, Oct 14, 2012 at 11:05:28PM +0200, Ansgar Burchardt wrote: > > Update: this bug was already worked around in the Debian package: the > > files included by upstream are not used, and the debian library package > > is used instead. The embeded copy is in the upstream source, and that is > > an upstream bug (which should trigger the lintian warning). > > Are you sure the Debian package does not use the embedded copy? The > lintian error seems to be triggered by the binary package (as it > includes the path). I was pretty sure, but you seem to be right. Ah, now I see: here's the entry from the changelog: * Tried to removed internal glee, but it doesn't seem to like the system's one So it wasn't used, indeed. Thanks for the clarification, Bas signature.asc Description: Digital signature
Bug#690492: love_0.8.0-2_i386.changes REJECTED
notfound 690492 0.8.0-1 thanks On Sun, Oct 14, 2012 at 06:57:43PM +0200, Bas Wijnen wrote: > On Sun, Oct 14, 2012 at 04:02:50PM +, Debian FTP Masters wrote: > > love: lintian output: 'embedded-library usr/bin/love-0.8: glee', > > automatically rejected package. > > love: If you have a good reason, you may override this lintian tag. > > I didn't touch that. I could override this error, but I shouldn't, > because it is a valid error. I didn't fix it, but I still would like the > other bugfixes to be included in stable (so I need to get the package > included in unstable first). Update: this bug was already worked around in the Debian package: the files included by upstream are not used, and the debian library package is used instead. The embeded copy is in the upstream source, and that is an upstream bug (which should trigger the lintian warning). The question remains: how should I get this package into unstable? Thanks, Bas signature.asc Description: Digital signature
Bug#690492: love: uses embedded copy of GLee
Package: love Version: 0.8.0-1 Severity: serious Justification: package gets rejected by ftp-master. LÖVE includes a copy of GLee, which is also packaged in Debian. It should use that package instead. signature.asc Description: Digital signature
Bug#689283: Sorry, I uploaded this to unstable by accident
Hi, While I was fixing this bug, I had two problems: my mail system wasn't properly configured, so you didn't see my message announcing that I planned an NMU to DELAYED/5. And I forgot to use the delayed queue, so it is now in unstable already. I do think the bug is fixed with the upload, but I intended to give you some more time to do things your way, should that be different. Sorry about that. I hope this is no problem for you. Please let me know if I need to do anything to fix things up. Thanks, Bas signature.asc Description: Digital signature
Bug#688436: ampache: diff for NMU version 3.6-git408e713+dfsg-3.1
tags 688436 + patch
tags 688436 + pending
thanks
Dear maintainer,
I've prepared an NMU for ampache (versioned as 3.6-git408e713+dfsg-3.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.
As you can see, I have only added ampache.prerm, where I remove the link
/etc/ampache/ampache.conf. The other files are automatically removed by dpkg.
It is removed on the remove action (not purge), just like the other links in
/etc. The files they link to are conffiles, and are properly removed by the
package only on purge.
Just now I'm thinking that you could also let the link be managed, by adding it
to ampache.links. Is there a reason you don't do that?
If you have any questions, including a request for sponsorship of a new
version, feel free to contact me.
Thanks,
Bas
diff -Nru ampache-3.6-git408e713+dfsg/debian/ampache.postrm
ampache-3.6-git408e713+dfsg/debian/ampache.postrm
--- ampache-3.6-git408e713+dfsg/debian/ampache.postrm 2012-09-22
23:59:04.0 +0200
+++ ampache-3.6-git408e713+dfsg/debian/ampache.postrm 2012-10-14
17:13:27.0 +0200
@@ -4,14 +4,6 @@
. /usr/share/debconf/confmodule
-#ampache.conf is left behind during purge so remove it manually this way
-#everything is removed on purge.
-ampconf_rm(){
- if [ -e /etc/ampache/ampache.conf ]; then
- rm -f /etc/ampache/ampache.conf
- fi
-}
-
restart_server(){
if [ -e /var/run/apache2.pid ]; then
service apache2 reload
@@ -24,7 +16,6 @@
if [ "$re_start" = "false" ]; then
printf "Please restart the web server manually."
elif [ "$re_start" = "true" ]; then
- ampconf_rm
restart_server
else
printf "unable to de-configure ampache, please do so
manually.\n"
diff -Nru ampache-3.6-git408e713+dfsg/debian/ampache.prerm
ampache-3.6-git408e713+dfsg/debian/ampache.prerm
--- ampache-3.6-git408e713+dfsg/debian/ampache.prerm1970-01-01
01:00:00.0 +0100
+++ ampache-3.6-git408e713+dfsg/debian/ampache.prerm2012-10-14
17:18:01.0 +0200
@@ -0,0 +1,8 @@
+#!/bin/sh -e
+
+# This link is created on postinst, so must be removed explicitly.
+rm -f /etc/ampache/ampache.conf
+
+#DEBHELPER#
+
+exit 0
diff -Nru ampache-3.6-git408e713+dfsg/debian/changelog
ampache-3.6-git408e713+dfsg/debian/changelog
--- ampache-3.6-git408e713+dfsg/debian/changelog2012-09-22
16:21:57.0 +0200
+++ ampache-3.6-git408e713+dfsg/debian/changelog2012-10-14
17:15:09.0 +0200
@@ -1,3 +1,10 @@
+ampache (3.6-git408e713+dfsg-3.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Remove generated link in prerm. Closes: #688436
+
+ -- Bas Wijnen Sun, 14 Oct 2012 16:31:58 +0200
+
ampache (3.6-git408e713+dfsg-3) unstable; urgency=low
* Remove statements in debian/ampache.postrm that manually remove conffiles,
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#688436: New plan
Hi, Reading the bug again, I realized you are doing the wrong thing here. You put a lot of effort into removing files which are automatically removed by purging the package. The bug is that your scripts _do_ remove the files, not that they don't. I'll prepare a fixed package and upload it to the delayed queue. Thanks, Bas signature.asc Description: Digital signature
Bug#684889: Confirmed, but FTBFS with patch
tags 684889 + patch thanks The test case from the link in the original report does indeed cause a segmentation fault for me. I looked over the patch which was linked, and it looks good. However, when I applied it, the compile failed one of its tests. This may not be related to the patch, though. I do not have the computing power at hand to try more compiles. Below I quoted the final part of the output. Thanks, Bas /tmp/eglibc-2.13/build-tree/i386-i686/elf/check-localplt /tmp/eglibc-2.13/build-tree/i386-i686/libc.so /tmp/eglibc-2.13/build-tree/i386-i686/math/libm.so /tmp/eglibc-2.13/build-tree/i386-i686/nptl/libpthread.so /tmp/eglibc-2.13/build-tree/i386-i686/rt/librt.so /tmp/eglibc-2.13/build-tree/i386-i686/dlfcn/libdl.so /tmp/eglibc-2.13/build-tree/i386-i686/resolv/libresolv.so /tmp/eglibc-2.13/build-tree/i386-i686/crypt/libcrypt.so | \ LC_ALL=C sort | \ diff -u ../scripts/data/localplt-i386-linux-gnu.data - > /tmp/eglibc-2.13/build-tree/i386-i686/elf/check-localplt.out make[3]: Leaving directory `/tmp/eglibc-2.13/elf' scripts/check-c++-types.sh scripts/data/c++-types-i386-linux-gnu.data g++-4.4 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -fstrict-aliasing -g -march=i686 -mtune=generic -pipe -mpreferred-stack-boundary=2 -Iinclude -I/tmp/eglibc-2.13/build-tree/i386-i686 -Isysdeps/i386/elf -Inptl/sysdeps/unix/sysv/linux/i386/i686 -Isysdeps/unix/sysv/linux/i386/i686 -Inptl/sysdeps/unix/sysv/linux/i386 -Isysdeps/unix/sysv/linux/i386 -Inptl/sysdeps/unix/sysv/linux -Inptl/sysdeps/pthread -Isysdeps/pthread -Isysdeps/unix/sysv/linux -Isysdeps/gnu -Isysdeps/unix/common -Isysdeps/unix/mman -Isysdeps/unix/inet -Isysdeps/unix/sysv/i386 -Inptl/sysdeps/unix/sysv -Isysdeps/unix/sysv -Isysdeps/unix/i386 -Inptl/sysdeps/unix -Isysdeps/unix -Isysdeps/posix -Isysdeps/i386/i686/fpu -Isysdeps/i386/i686/multiarch -Inptl/sysdeps/i386/i686 -Isysdeps/i386/i686 -Isysdeps/i386/i486 -Inptl/sysdeps/i386/i486 -Isysdeps/i386/fpu -Inptl/sysdeps/i386 -Isysdeps/i386 -Isysdeps/wordsize-32 -Isysdeps/ieee754/ldbl-96 -Isysdeps/ieee754/dbl-64 -Isysdeps/ieee754/flt-32 -Isysdeps/ieee754 -Isysdeps/generic/elf -Isysdeps/generic -Inptl -Ilibio -I. -nostdinc -isystem /usr/lib/gcc/i486-linux-gnu/4.4.7/include -isystem /usr/lib/gcc/i486-linux-gnu/4.4.7/include-fixed -isystem /tmp/eglibc-2.13/debian/include -D_LIBC_REENTRANT -include include/libc-symbols.h > /tmp/eglibc-2.13/build-tree/i386-i686/c++-types-check.out scripts/check-local-headers.sh "/usr/include" "/tmp/eglibc-2.13/build-tree/i386-i686/" > /tmp/eglibc-2.13/build-tree/i386-i686/check-local-headers.out /usr/bin/perl scripts/begin-end-check.pl argp/argp.h assert/assert.h catgets/nl_types.h crypt/crypt.h ctype/ctype.h debug/execinfo.h dirent/dirent.h dlfcn/dlfcn.h elf/elf.h elf/link.h gmon/sys/gmon.h gmon/sys/gmon_out.h gmon/sys/profil.h grp/grp.h gshadow/gshadow.h iconv/iconv.h iconv/gconv.h inet/netinet/ether.h inet/netinet/icmp6.h inet/netinet/igmp.h inet/netinet/in.h inet/netinet/ip6.h inet/arpa/ftp.h inet/arpa/inet.h inet/arpa/telnet.h inet/arpa/tftp.h inet/protocols/routed.h inet/protocols/rwhod.h inet/protocols/talkd.h inet/protocols/timed.h inet/aliases.h inet/ifaddrs.h inet/netinet/ip6.h inet/netinet/icmp6.h intl/libintl.h io/sys/stat.h io/sys/statfs.h io/sys/vfs.h io/sys/statvfs.h io/fcntl.h io/sys/fcntl.h io/poll.h io/sys/poll.h io/utime.h io/ftw.h io/fts.h io/sys/sendfile.h libio/stdio.h libio/libio.h locale/locale.h locale/langinfo.h locale/xlocale.h login/utmp.h login/lastlog.h login/pty.h malloc/malloc.h malloc/obstack.h malloc/mcheck.h math/math.h math/complex.h math/fenv.h math/tgmath.h misc/sys/uio.h nis/rpcsvc/nis.h nis/rpcsvc/nis_callback.h nis/rpcsvc/nis_tags.h nis/rpcsvc/nislib.h nis/rpcsvc/yp.h nis/rpcsvc/yp_prot.h nis/rpcsvc/ypclnt.h nis/rpcsvc/ypupd.h nptl_db/thread_db.h nptl/sysdeps/pthread/pthread.h nptl/semaphore.h nss/nss.h posix/sys/utsname.h posix/sys/times.h posix/sys/wait.h posix/sys/types.h posix/unistd.h posix/glob.h posix/regex.h posix/wordexp.h posix/fnmatch.h posix/getopt.h posix/tar.h posix/sys/unistd.h posix/sched.h posix/re_comp.h posix/wait.h posix/cpio.h posix/spawn.h pwd/pwd.h resolv/resolv.h resolv/netdb.h resolv/arpa/nameser.h resolv/arpa/nameser_compat.h resource/sys/resource.h resource/sys/vlimit.h resource/sys/vtimes.h resource/ulimit.h rt/aio.h rt/mqueue.h setjmp/setjmp.h shadow/shadow.h signal/signal.h signal/sys/signal.h socket/sys/socket.h socket/sys/un.h stdio-common/printf.h stdio-common/stdio_ext.h stdlib/stdlib.h stdlib/alloca.h stdlib/monetary.h stdlib/fmtmsg.h stdlib/ucontext.h sysdeps/generic/inttypes.h sysdeps/generic/stdint.h stdlib/errno.h stdlib/sys/errno.h string/string.h string/strings.h string/memory.h string/endian.h string/argz.h string/envz.h string/byteswap.h sunrpc/rpc/auth.h sunrpc/rpc/auth_des.h sunrpc/rpc/auth_unix.h sunrpc/rpc/clnt.h sunrpc/rpc/des_crypt.h sunrpc/rpc/key_prot.h sunrpc/rpc/netdb.h sunrpc/rpc/pmap_clnt.h sunrpc/rpc/pmap_prot.h sunrpc/rpc/pmap_rm
Bug#684923: Solution for this bug
After some discussion at the Utrecht BSP[1], we've submitted a wishlist
bug (#690390) to debconf which would make solving this bug easier. Our
suggestion is to change debconf so it uses values from config files
instead of its cache (the last seen answer). This means it can also no
longer reset config files to their older state based on this cache.
("This file is managed by debconf" is not a valid excuse for messing
with manual changes; your package is not allowed to revert user changes
to config files, no matter if it happens through debconf or not.)
If our suggestions is implemented, it would be easier to solve this
problem, but it would still need to allow debconf to read and write the
configuration. This is another aspect of this bug: it is appearantly too
hard to understand how to make the package do what you want. Pointing to
documentation is not a proper solution; if it is easy to do this wrong,
then it should be changed to a more intuitive method.
Thanks,
Bas
[1] http://wiki.debian.org/BSP/2012/10/nl/Utrecht
signature.asc
Description: Digital signature
Bug#689283: Sorry, I forgot to use DELAYED for uploading
As I posted, I wanted to upload this fix to DELAYED/5, but I accidentily uploaded it directly into the archive. Sorry about that, I hope you don't have a problem with it. Thanks, Bas signature.asc Description: OpenPGP digital signature
Bug#688436: Patch review
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've checked your patch and have a few comments: Is there a reason you put several commands in parallel in both clauses of an if statement? Specifically, I'm talking about the postrm script, the new purge block. Most of those lines can be outside the if AFAICS. The ifs in your new rm_* functions seem useless: you use rm -f anyway, so that doesn't fail if the target doesn't exist. That means the functions are really only one line; it would be possible (and a lot shorter) to put that line in the script instead of the function calls. Your changes to lib/log.lib.php and modules/captcha/captcha.php are not documented anywhere, and don't seem appropiate for a freeze exception. If they're really needed, please document them. "somethng weird has happened please restart the webserver manually" shoud be "Something weird has happened, please restart the webserver manually." If you reply by sunday, I can upload the new package for you. If you don't, I'll upload it with the above changed as indicated as NMU to the delayed queue. Thanks, Bas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlB5QVMACgkQFShl+2J8z5XgfgCgwsspUIGWW99An1M5AjgnxFyN Sv4AoJGPL6oSYGHDDHPtEeOwwygdA1SW =vVrW -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#688935: openmsx: FTBFS on arm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: openmsx Severity: serious - Original Message Subject: failed armhf build of openmsx 0.9.0-1 Date: Wed, 26 Sep 2012 13:00:06 + From: Debian buildds To: open...@packages.qa.debian.org * Source package: openmsx * Version: 0.9.0-1 * Architecture: armhf * State: failed * Suite: sid * Builder: henze.debian.org * Build log: https://buildd.debian.org/fetch.cgi?pkg=openmsx&arch=armhf&ver=0.9.0-1&stamp=1348664233&file=log Please note that these notifications do not necessarily mean bug reports in your package but could also be caused by other packages, temporary uninstallabilities and arch-specific breakages. A look at the build log despite this disclaimer would be appreciated however. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlBj9DwACgkQFShl+2J8z5U2SgCgtRC+CmQLYWHOnjDsRTuX4/O6 X/YAoIovvczxmn+zkVzoE69eFAKJLUxW =Cz0v -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#687851: freedink: diff for NMU version 1.08.20120427-2.1
Hi, Thanks for your patch. I had another patch waiting upstream, which I have just submitted to Debian as well (#688934). This fixes a bug which makes some dmods unplayable. I'm not sure if this is bad enough for a freeze exception, though. If you think it is, please consider including it in your NMU. Thanks, Bas On 27-09-12 00:15, David Prévot wrote: > tags 687851 + patch > tags 687860 + patch > thanks > > Dear maintainer, > > I've prepared an NMU for freedink (versioned as 1.08.20120427-2.1) and > uploaded it to DELAYED/2. Please feel free to tell me if I > should delay it longer. > > I'll take care of the unblock request. > > Regards. > > David > > > > ___ > Pkg-games-devel mailing list > pkg-games-de...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-games-devel signature.asc Description: OpenPGP digital signature
Bug#678085: python-lua: unsuitable for testing
Package: python-lua Version: 0.2-1 Severity: serious Python-lua is still quite experimental and subject to change. To avoid maintainance, it should not be in the upcoming release, and therefore removed from testing. The only reverse dependency is wherpygo, which should also be removed from testing. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#678084: wherpygo: not suitable for upcoming release
Package: wherpygo Version: 0.4-1 Severity: serious Wherpygo is subject to lots of changes. Also, the name will change in the near future. As it is, it should not be included in the upcoming release, and therefore it should be removed from testing. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#636442: Bugs are fixed
close 636442 close 640618 thanks These bugs were because of incorrect dependencies in doxygen-latex. These have been fixed now, so libshevek should also compile without problems. Thanks, Bas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#650208: phlipple: crash at startup
Package: phlipple Version: 0.8.2-1 Severity: grave Justification: renders package unusable When trying to start phlipple, I briefly see a black window, then it crashes with a segmentation fault. I built it with symbols to get a meaningful stack backtrace: phlipple-0.8.2$ gdb src/phlipple GNU gdb (GDB) 7.3-debian Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i486-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /home/shevek/tmp/phlipple-0.8.2/src/phlipple...done. (gdb) run Starting program: /home/shevek/tmp/phlipple-0.8.2/src/phlipple [Thread debugging using libthread_db enabled] [New Thread 0xb2d26b70 (LWP 29623)] [Thread 0xb2d26b70 (LWP 29623) exited] [New Thread 0xb2d26b70 (LWP 29624)] [New Thread 0xb2525b70 (LWP 29625)] Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x08055341 in quad_renderer_init () at quadrenderer.c:55 #2 0x080556f0 in SceneManager_reshape (w=640, h=480) at scenes.c:103 #3 0x08053c4b in OS_mainLoop () at osinterface_sdl.c:163 #4 0x080556ca in SceneManager_run () at scenes.c:90 #5 0x08050ebc in main (argc=1, argv=0xb374) at main.c:26 (gdb) quit My system does not have hardware openGL support, but other 3D programs work fine (though sometimes slow). Thanks, Bas Wijnen -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#636442: doxygen-latex: missing dependencies
Package: doxygen-latex Version: 1.7.4-4 When building latex documentation with doxygen, more packages are required to make everything work. What is required: ghostscript texlive-fonts-recommended Since the previous update of doxygen-latex was very fast, I intend to wait with reuploading libshevek, so I don't need to specify these as build-dependencies in there (as they don't belong there). Thanks, Bas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#636442: libshevek: FTBFS: Fatal error occurred, no output PDF file produced!
Hi, Nobuhiro Iwamatsu schreef op wo 03-08-2011 om 12:46 [+0900]: > Source: libshevek > Version: 1.1-2 > Severity: serious > Justification: fails to build from source > > Hi, > > libshevek FTBFS on all architectures. > https://buildd.debian.org/status/package.php?p=libshevek&suite=unstable > http://buildd.debian-ports.org/status/package.php?p=libshevek&suite=sid ... > Could you check your package? pbuilder wasn't working, so I was just hoping I had all the dependencies right. Appearantly I didn't. :-( I'll have a look at it, thanks for reporting. Bas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#634731: libshevek: FTBFS - errors building refman.pdf
Hi, Aaron M. Ucko schreef op di 19-07-2011 om 14:06 [-0400]: > Binary-only builds of libshevek in minimal environments (as autobuilders > typically provide) are failing due to trying to build the > manual without all necessary build dependencies: Thanks for reporting, and sorry that I didn't use pbuilder to find this myself. > > sh: epstopdf: not found > > error: Problems running epstopdf. Check your TeX installation! > [...] > > ! LaTeX Error: File `xcolor.sty' not found. > > You can find epstopdf in texlive-font-utils and xcolor.sty in > latex-xcolor, though taking advantage of the doxygen-latex metapackage > would save you from listing the latter yourself. Hm, that should also include epstopdf, since I only use it for running generating pdf with doxygen. I'll report it there. > That said, given that the resulting PDF file rightly winds up in the > architecture-independent libshevek-doc binary package, I'd moreover > recommend moving all relevant dependencies to Build-Depends-Indep and > arranging for binary-only builds to skip building documentation > altogether. (To that end, though, please note that per #178809, using > the build-indep target is ineffective at present; you can instead > conditionalize the relevant command[s] or run them out of binary-indep.) I know that it doesn't work still. I prefer not to spend time on it until there is a proper recommendation of what packages should do, combined with a roadmap for making it useful at some point. > At any rate, could you please address these errors? Thanks! Of course. Thanks again for reporting, Bas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#530032: Closing or downgrading severity
On Tue, Sep 15, 2009 at 12:07:41PM +0200, Julien Cristau wrote:
> you may want to add here something like:
>
> if ((aip->ai_family == AF_INET6) &&
> (setsockopt(fds[*num_fds], IPPROTO_IPV6, IPV6_V6ONLY,
> &yes, sizeof(yes)) < 0)) {
> net_closesocket(fds[*num_fds]);
> continue;
> }
>
> to avoid on ipv6 socket trying to get ipv4 connections (if you're
> looping over all addresses anyway, you'll have AF_INET sockets for your
> v4 addresses)
Thanks, that will probably fix the problem and make things work. Still,
I can't believe that this is the "normal" way to listen for incoming
connections from the internet. It's just much too complex.
Roland, can you test if this addition to my patch makes the warning go
away for you, and that it results in the server listening on both
protocols?
Thanks,
Bas
signature.asc
Description: Digital signature
Bug#530032: Closing or downgrading severity
On Mon, Sep 14, 2009 at 11:25:22PM -0700, Steve Langasek wrote: > On Tue, Sep 15, 2009 at 07:51:00AM +0200, Roland Clobus wrote: > > I still think that this bug report now contains two bugs reports: > > 1) Fixing playing games with localhost (especially for computer players) > > 2) Making the server IPv6 compliant > > > No 1. is fixed, and that fix alone should be enough to make a new > > release. > > It would be nice if no 2. would be fixed, but that can be done slightly > > later. > > Except that you've fixed #1 in a manner which is redundant if #2 were fixed > properly. There may be weird routing problems which result in a port being shown as listening, but unable to accept connections. Especially because the meta-server get the port to advertise from the server, not from probing.[1] So IMO it is good to keep the "try all options"-loop, even if it should never be needed in properly configured networks. Thanks, Bas [1] Which is something we should eventually fix as well. The meta-server should simply use getpeername() on the socket that connects to it. No extra network traffic is required. signature.asc Description: Digital signature
Bug#530032: Closing or downgrading severity
On Tue, Sep 15, 2009 at 07:51:00AM +0200, Roland Clobus wrote: > On Sat, 2009-09-12 at 15:57 +0200, Bas Wijnen wrote: > > I'm a bit confused: this is a Debian bug, so the problem presumably > > exists on Debian systems. This may be different on GNU/kFreeBSD, but > > the reporter is using GNU/Linux, like the system I'm testing on. > > > > Anyway, I'm attaching the patch. > > That patch does not work as advertised. I get the error, and the result > (according to netstat) is that the server only listens on IPv4. > > Somewhere when I upgraded to kernel 2.6.30 Pioneers broke, so I assume > that the automatic IPv6<->IPv4 bridge was removed. In that case, the bug may not actually be in Pioneers. At least it explains my confusion: I tested it on a stable system, with a 2.6.26 kernel. I don't see how this can be fixed, if the approach of the patch to listen twice doesn't work. In the ipv6(7) man page, it says: IPv4 connections can be handled with the v6 API by using the v4-mapped-on-v6 address type; thus a program only needs only to support this API type to support both protocols. This is handled transparently by the address handling functions in libc. The reverse does not seem to be the case, however. So the problem is that the IPv4 address is returned first, it is listened on, then the IPv6 address is returned, and the address is already in use. A solution might be to do the listening in two rounds, first ignoring all IPv4 addresses and after that using only them (and not warning about address already in use failures there). While this works, I consider it a kernel bug if it really is so hard to do it right. Steve, do you know more about this? > I still think that this bug report now contains two bugs reports: > 1) Fixing playing games with localhost (especially for computer players) > 2) Making the server IPv6 compliant > > No 1. is fixed, and that fix alone should be enough to make a new > release. > It would be nice if no 2. would be fixed, but that can be done slightly > later. I agree that they are separate problems, and that 1. is more severe. However, since IPv6 support is a release goal for Debian, I would like to have 2. fixed at least before the freeze as well. (It was originally planned in november, I think, but is probably a bit later still.) So if it can be fixed in the same release, I would prefer that. Thanks, Bas signature.asc Description: Digital signature
Bug#530032: Closing or downgrading severity
On Fri, Sep 11, 2009 at 10:59:41PM +0200, Roland Clobus wrote:
> On Wed, 2009-09-09 at 10:11 -0700, Steve Langasek wrote:
> > Well, that's not a proper fix for the bug then. The server should be
> > listening on both IPv6 and IPv4.
>
> I think the bug that was reported: 'Unable to play games using
> localhost' is adequately fixed by adapting the clients.
> I agree that it should be nice if the server would listen on all
> available protocols. IMO that would be another bug report with severity
> 'wishlist', while this bug with severity 'grave' can be closed.
I've written a patch which listens on everything returned by
getaddrinfo. The call returns two structures, but the second bind fails
with "address already in use". It seems the problem doesn't occur in
Debian, because it automatically listens on both IPv4 and IPv6(?) So
I'm a bit confused: this is a Debian bug, so the problem presumably
exists on Debian systems. This may be different on GNU/kFreeBSD, but
the reporter is using GNU/Linux, like the system I'm testing on.
Anyway, I'm attaching the patch.
Thanks,
Bas
Index: common/network.h
===
--- common/network.h (revision 1459)
+++ common/network.h (working copy)
@@ -82,9 +82,10 @@
* @param port The port
* @retval error_message If opening fails, a description of the error
* You should g_free the error_message
- * @return A file descriptor if succesfull, or -1 if it fails
+ * @retval num_fds The number of valid fds in the returned array
+ * @return An array of file descriptors if succesfull, or NULL if it fails
*/
-int net_open_listening_socket(const gchar * port, gchar ** error_message);
+int *net_open_listening_socket(const gchar * port, gchar ** error_message, int *num_fds);
/** Close a socket
*/
Index: common/network.c
===
--- common/network.c (revision 1459)
+++ common/network.c (working copy)
@@ -743,14 +743,17 @@
return pioneers_dir;
}
-int net_open_listening_socket(const gchar * port, gchar ** error_message)
+int *net_open_listening_socket(const gchar * port, gchar ** error_message, int *num_fds)
{
#ifdef HAVE_GETADDRINFO_ET_AL
int err;
struct addrinfo hints, *ai, *aip;
int yes;
- gint fd = -1;
+ int *fds;
+ int max_num_fds;
+ *num_fds = 0;
+
memset(&hints, 0, sizeof(hints));
hints.ai_family = NETWORK_PROTOCOL;
@@ -763,65 +766,77 @@
g_strdup_printf(_(""
"Error creating struct addrinfo: %s"),
gai_strerror(err));
- return -1;
+ return NULL;
}
+ max_num_fds = 0;
for (aip = ai; aip; aip = aip->ai_next) {
- fd = socket(aip->ai_family, SOCK_STREAM, 0);
- if (fd < 0) {
+ ++max_num_fds;
+ }
+
+ fds = g_malloc (max_num_fds * sizeof (*fds));
+ for (aip = ai; aip; aip = aip->ai_next) {
+ fds[*num_fds] = socket(aip->ai_family, SOCK_STREAM, 0);
+ if (fds[*num_fds] < 0) {
continue;
}
- yes = 1;
/* setsockopt() before bind(); otherwise it has no effect! -- egnor */
+ yes = 1;
if (setsockopt
- (fd, SOL_SOCKET, SO_REUSEADDR, &yes,
+ (fds[*num_fds], SOL_SOCKET, SO_REUSEADDR, &yes,
sizeof(yes)) < 0) {
- net_closesocket(fd);
+ g_warning(_(""
+ "Not using socket because setting REUSEADDR failed: %s\n"),
+ net_errormsg());
+ net_closesocket(fds[*num_fds]);
continue;
}
- if (bind(fd, aip->ai_addr, aip->ai_addrlen) < 0) {
- net_closesocket(fd);
+ if (bind(fds[*num_fds], aip->ai_addr, aip->ai_addrlen) < 0) {
+ g_warning(_(""
+ "Not using socket because bind failed: %s\n"),
+ net_errormsg());
+ net_closesocket(fds[*num_fds]);
continue;
}
- break;
- }
+ if (net_set_socket_non_blocking(fds[*num_fds])) {
+ g_warning(_(""
+ "Not using socket because it cannot be set to non-blocking: %s\n"),
+ net_errormsg());
+ net_closesocket(fds[*num_fds]);
+ continue;
+ }
- if (!aip) {
- *error_message =
- g_strdup_printf(_(""
- "Error creating listening socket: %s\n"),
-net_errormsg());
- freeaddrinfo(ai);
- return -1;
+ if (listen(fds[*num_fds], 5) < 0) {
+ g_warning(_(""
+ "Not using socket because listening failed: %s\n"),
+ net_errormsg());
+ net_closesocket(fds[*num_fds]);
+ continue;
+ }
+
+ /* Listening succeeded. Keep the fd and continue. */
+ ++*num_fds;
}
freeaddrinfo(ai);
- if (net_set_socket_non_blocking(fd)) {
+ if (*num_fds == 0) {
+ g_free (fds);
*error_message =
g_strdup_printf(_(""
- "Error setting socket non-blocking: %s\n"),
+ "Error creating listening socket: %s\n"),
net_errormsg());
- net_closesocket(fd);
- return -1;
+ return NULL;
}
- if (listen(fd, 5) < 0) {
- *error_message =
- g_strdup_printf(_(""
- "Error during listen on socket: %s\n"),
-net_errormsg());
- net_closesocket(fd);
- return -1;
- }
*error_message = NULL;
- return fd;
+ return fds;
#else
Bug#530032: Fix applied upstream
On Tue, Sep 08, 2009 at 11:35:10AM -0700, Steve Langasek wrote: > On Tue, Sep 08, 2009 at 07:58:21PM +0200, Bas Wijnen wrote: > > On Mon, Sep 07, 2009 at 07:44:44AM +0200, Roland Clobus wrote: > > > I've applied a patch to the subversion repository upstream. An incoming > > > connection will now correctly try all available protocols. > > > > On my computer (with kernel 2.6.30, and localhost mentioned > > > in /etc/hosts for 127.0.0.1 and ::1 netstat reports that the server is > > > running on IPv4. The clients will connect correctly. > > > While this solves the problem, it doesn't use the better solution that > > Steve suggested (if I understand you correctly), namely to make the > > server IPv6-capable. That shouldn't be hard at all, I think. It is > > probably just a matter of changing old gethostbyname calls into > > getaddrinfo calls. > > Unfortunately, no; it's already using getaddrinfo(), but doesn't iterate the > results to ensure we're listening on all the addresses in question. That's not unfortunate at all. ;-) It means that Roland's patch probably is the clean solution that we want. If you mean it is unfortunate that good programs need this looping, then I agree with you. :-) Thanks, Bas signature.asc Description: Digital signature
Bug#545364: Confirmed; video card is the problem
Hi, I receive the same message. It happens after the "linux" command, both when it is run from the menu (by waiting for the timeout or selecting the item), and when typing it into the prompt. My video card is an ATI Radeon 9000. I didn't have another one handy, but removing the video card made the system boot (and I could reinstall grub-legacy over an ssh connection). This is a particularly big problem, because the upgrade path seems very safe: I got a message in my old bootloader, selected chainload into grub2, booted from there, and then told it to make the upgrade "real". I don't know why the problem didn't show up through the chainload, but it makes the problem much worse (I wouldn't have upgraded if it would). I hope you are able to fix this problem. Let me know if I can do anything to help diagnose it. Thanks, Bas signature.asc Description: Digital signature
Bug#530032: Fix applied upstream
On Mon, Sep 07, 2009 at 07:44:44AM +0200, Roland Clobus wrote: > I've applied a patch to the subversion repository upstream. An incoming > connection will now correctly try all available protocols. > > On my computer (with kernel 2.6.30, and localhost mentioned > in /etc/hosts for 127.0.0.1 and ::1 netstat reports that the server is > running on IPv4. The clients will connect correctly. While this solves the problem, it doesn't use the better solution that Steve suggested (if I understand you correctly), namely to make the server IPv6-capable. That shouldn't be hard at all, I think. It is probably just a matter of changing old gethostbyname calls into getaddrinfo calls. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://a82-93-13-222.adsl.xs4all.nl/e-mail.html signature.asc Description: Digital signature
Bug#533597: pioneers-console: Actually, this represents a violation of Debian Policy
On Thu, Jun 25, 2009 at 05:46:18AM -0700, Steve Langasek wrote: > On Thu, Jun 25, 2009 at 02:31:32PM +0200, Bas Wijnen wrote: > > I see. That's a pity, I would have liked to allow users to use debconf, > > but still be able to edit the files by hand in the place where they > > expect them (/etc). Policy does not seem to allow this. > > Yes, it does. What it doesn't allow is to ship a file *as a conffile* and > edit it with debconf. Ah, of course. I somehow thought that everything in /etc had to be a conffile. In fact, everything in /etc must be a configuration file (the FHS says so), and everything shipped there automatically is a conffile. > You have to copy the config file from a template in /usr/share/$package in > the package postinst. I'll do that. Thanks for the hint. Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://a82-93-13-222.adsl.xs4all.nl/e-mail.html signature.asc Description: Digital signature
Bug#533597: pioneers-console: Actually, this represents a violation of Debian Policy
On Fri, Jun 19, 2009 at 12:25:22AM -0700, Josh Triplett wrote: > Upon rechecking Debian Policy, I realized that this behavior represents > a violation of Debian Policy 10.7.3 > <http://www.debian.org/doc/debian-policy/ch-files.html#s10.7.3>. A > package must not ship configuration files in the package as conffiles > and then modify them in maintainer scripts. I see. That's a pity, I would have liked to allow users to use debconf, but still be able to edit the files by hand in the place where they expect them (/etc). Policy does not seem to allow this. > Thus, please stop shipping the file in the pioneers-console package, and > instead have the maintainer scripts create the file. > > Alternatively, since the init script has very sane defaults, you might > consider just shipping the configuration file with commented-out > defaults and removing the debconf questions entirely. I'll think about which solution I like better. Thanks for reporting the feedback, Bas Wijnen -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://a82-93-13-222.adsl.xs4all.nl/e-mail.html signature.asc Description: Digital signature
Bug#524864: sdcc: Replaces/Conflicts missing
Hi, On Mon, Apr 20, 2009 at 02:41:33PM +0200, Gudjon I. Gudjonsson wrote: > The problem is that inc2h.pl is in sdcc-libraries in version 2.8.0 but > I moved it to sdcc in version 2.9.0 without considering this problem. > Please remove the old one and then it will install without problems. I > will try to find a solution to the package. The solution in such a case is to use a versioned conflicts rule in sdcc: Conflicts: sdcc-libraries (<< 2.9.0) Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://a82-93-13-222.adsl.xs4all.nl/e-mail.html signature.asc Description: Digital signature
Bug#515982: linux-image-2.6-486: Cannot boot on i486
Package: linux-image-2.6-486 Version: 2.6.26+17 Severity: Grave Justification: Makes package unusable Installing lenny on a 486 is not possible, because the installer kernel cannot boot. Upgrading from Etch will work, but only if the old kernel continues to be used. When trying to boot the kernel, it seems to panic immediately (I can't really check, because my hercules monitor doesn't allow scrollback). I copied the crash message (by hand, so it may contain some typos, and I left some numbers out; please ask if they are important, it's easy to reproduce, if you have the hardware). Below is the text that's on screen after trying to boot. I also included the output of /proc/cpuinfo (when using Etch's 2.6.18 kernel). The cache is switched off to make sure that wasn't the problem; the result is identical if I do switch it on. Thanks, Bas Call Trace: native_init_IRQ+0x46/0x79 apply_paravirt+0x81/0x91 do_IRQ+0x50/0x60 common_interrupt+0x23/0x30 vprintk+0x269/0x275 ktime_get+0xd/0x21 tick_nohz_stop_sched_tick+0x24f/0x259 do_IRQ+0x50/0x60 common_interrupt+0x23/0x30 alternative_instructions+0x23/0x3c check_bugs+0xd2/0xd4 start_kernel+0x271/0x27e = Code: 00 89 c2 fa 90 8d b4 26 00 00 00 00 90 89 c8 89 ef c1 e8 02 89 c1 f3 a5 89 d9 83 e1 03 74 02 f3 a4 89 d0 50 9d 90 8d b4 26 00 00 <00> 00 b8 01 00 00 00 0f a2 5a 89 e8 5b 5e 5f 5d c3 55 31 c9 57 EIP: [] text_poke_early+0x41/0x52 SS:ESP 0068:c0363eb0 ---[ end trace 4eaa2a86a8e2da22 ]--- Kernel panic - not syncing: Attempted to kill the idle task! processor : 0 vendor_id : GenuineIntel cpu family : 4 model : 8 model name : 486 DX/4 stepping: 0 cache size : 0 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme bogomips: 49.40 -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://a82-93-13-222.adsl.xs4all.nl/e-mail.html signature.asc Description: Digital signature
Bug#496807: gnucash: silently removes main files while trying to save without lock
On Wed, Aug 27, 2008 at 01:02:56PM -0700, Thomas Bushnell BSG wrote: > > I was trying to use gnucash over sshfs, to allow several machines to > > handle the same file. It complained that it was unable to get a lock, > > and so couldn't prevent simultaneous writes. This was no problem, > > because there isn't another person working on them. For the rest, > > everything seemed to work fine. > > > > However, when trying to reopen the file, I found that it had not been > > written, but instead it was deleted. So not only did I lose the work of > > the session, but it actually deleted my previous work as well. > > Are you sure this isn't a bug in sshfs? No, I'm not sure about that. But from gnucash's behaviour, it seems that sshfs doesn't support locking (which I suppose is a known missing feature, but I didn't check), and gnucash handles that situation very badly. It is possible that the entire problem is with sshfs. More testing would be needed to find that out, either with trying to lock files on sshfs, or with gnucash on other filesystems which don't support locking. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://a82-93-13-222.adsl.xs4all.nl/e-mail.html signature.asc Description: Digital signature
Bug#496807: gnucash: silently removes main files while trying to save without lock
Package: gnucash Version: 2.2.6-1 Severity: grave Justification: causes data loss I was trying to use gnucash over sshfs, to allow several machines to handle the same file. It complained that it was unable to get a lock, and so couldn't prevent simultaneous writes. This was no problem, because there isn't another person working on them. For the rest, everything seemed to work fine. However, when trying to reopen the file, I found that it had not been written, but instead it was deleted. So not only did I lose the work of the session, but it actually deleted my previous work as well. I tried creating a new file, which also complains about the lock file, but seems to work fine otherwise, but it also doesn't create the file. This would have been a "critical issue" (causes serious data loss), except that gnucash writes loads of log and backup files, so normally most of the work will not actually be lost. As a quick fix, it would be acceptable to turn the lock warning into an error. Thanks, Bas Wijnen signature.asc Description: Digital signature
Bug#495319: uswsusp: s2disk reboots instead of halting
Package: uswsusp Version: 0.8.1 Severity: Grave Justification: Makes package mostly unusable When closing the lid of my laptop, I have set it to call s2disk. This used to work fine, but since recently, instead of halting at the end of the process, it reboots. This means that for the suspend to work, I must close the lid to start the process, then open it again to reach the power button, and wait for the reboot, then switch off the machine manually again. This is very annoying, as it makes the normal way of working (close the lid and walk away) impossible. I'm not sure if this is a uswsusp bug, it could just as well be in the kernel. Feel free to reassign. :-) My kernel package is linux-image-2.6.26-1-686, version 2.6.26-2. /proc/cpuinfo contains: processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Celeron(R) CPU 2.80GHz stepping: 9 cpu MHz : 2800.000 cache size : 128 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe up pebs bts cid xtpr bogomips: 5592.89 clflush size: 64 power management: Thanks, Bas Wijnen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#485511: pioneers-console: maintainer scripts fail with dash as /bin/sh
tags 485511 +pending thanks Hi, On Mon, Jun 09, 2008 at 06:40:45PM -0400, Aaron M. Ucko wrote: > test ! -r "$CONFFILE" || . "$CONFFILE" > > fails if the configuration file contains no content (as it does by > default), as test's non-zero exit status ends up standing. Dash considers it an error to source an empty file? Strange... > I'd suggest rewriting that as > > if test -r "$CONFFILE"; then > . "$CONFFILE" > fi Will do. > Anyway, once I got past that problem, I ran into another: the config > and postinst scripts both use the bashism "function x" rather than the > portable "x ()". Ok, I'll change that as well. > Could you please either fix your scripts to work under other shells > (posh, dash) I'll do that. > or else explicitly run them under bash? For things which can be fixed as easily as this? No thanks! :-) Thanks for reporting these issues. I'll make a new upload soon, and shall include them. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Bug#476021: sketch: FTBFS: Died at make.pl line 21, line 10. (reproduced with new version)
Hi Lucas and David,
On Mon, Apr 14, 2008 at 01:49:20PM +0200, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on i386.
That is highly surprising. I built it in a pbuilder chroot before
uploading, and everything worked fine. The following hint doesn't seem
to point at this issue:
> This rebuild was done with gcc 4.3 instead of gcc 4.2, because gcc 4.3 is now
> the default on most architectures (even if it's not the case on i386 yet).
> Feel free to downgrade this bug to 'important' if your package is only built
> on i386, and this bug is specific to gcc 4.3 (i.e the package builds fine with
> gcc 4.2).
Because the problem is:
> > (./ex070.tex
> > ! Missing number, treated as zero.
> >
> >n
> > l.4 \begin{pspicture}(-1,0)(1,nan)
> >
> > ?
In other words, a TeX error, not a gcc error.
Also, according to buildd.debian.org/sketch, there is no problem on any
architecture (it's installed on all except sparc, where it's "building"
at this moment). If gcc-4.3 would be the problem, this would have
caused several of those to break as well.
David, do you have any idea what could be the problem?
By the way, I received a notice that a new upstream version was out as
well, so you could package that when fixing this.
Thanks,
Bas
--
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html
signature.asc
Description: Digital signature
Bug#431994: version problem
Hello again, I just received a rejection for my NMU, because I failed to realize that 1.7.3-0.1 is smaller than 1.7.3+b1 (see bug #437392). Sorry about that. I'm uploading the same patch with version 1.7.3+nmu1, which should be fine (although it does produce a lintian warning). This time, I'll upload the package directly to the archive, since this fix should have been ACCEPTED now anyway. The new patch is attached. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html diff -urp old/debtags-1.7.3/debian/changelog new/debtags-1.7.3+nmu1/debian/changelog --- old/debtags-1.7.3/debian/changelog 2007-07-06 15:21:25.0 +0200 +++ new/debtags-1.7.3+nmu1/debian/changelog 2008-03-13 11:16:35.0 +0100 @@ -1,3 +1,13 @@ +debtags (1.7.3+nmu1) unstable; urgency=low + + * Non-maintainer upload. + * Don't try to run debtags in cronjob when binary is not present. (Closes: +#435067, #435235, #435243, #457058) + * Don't make cron mail output unless an error is encountered. (Closes: + #431994) + + -- Bas Wijnen <[EMAIL PROTECTED]> Thu, 13 Mar 2008 11:16:22 +0100 + debtags (1.7.3) unstable; urgency=low * Allow to install extra tag sources in /etc/debtags/sources.list.d/ diff -urp old/debtags-1.7.3/debian/debtags.cron.daily new/debtags-1.7.3+nmu1/debian/debtags.cron.daily --- old/debtags-1.7.3/debian/debtags.cron.daily 2007-07-06 15:21:25.0 +0200 +++ new/debtags-1.7.3+nmu1/debian/debtags.cron.daily 2008-03-13 11:15:25.0 +0100 @@ -1,4 +1,4 @@ #!/bin/sh # Update the data and index files of Debtags -debtags update +test ! -x /usr/bin/debtags || /usr/bin/debtags update 2>/dev/null || echo debtags update error signature.asc Description: Digital signature
Bug#431994: debtags: NMU patch fixing cron stuff
Hi, I'm about to upload an NMU with a fix for all the bugs in the To: of this message (that's just 2, really). The change is a combination of the patches which were already in the bts. The full patch is attached to this mail. There doesn't seem to be consensus about the version numbering for NMUs to native packages. I've used what devref says and dch does, but this suggests that the new package is non-native. It isn't, of course. I'll upload the package to the 7-day delayed queue, so if there's something you dislike about it, you have 7 days to cancel the upload, or better, send a fix which pleases you more directly to the archive. :-) Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html diff -rup old/debtags-1.7.3/debian/changelog new/debtags-1.7.3/debian/changelog --- old/debtags-1.7.3/debian/changelog 2007-07-06 15:21:25.0 +0200 +++ new/debtags-1.7.3/debian/changelog 2008-03-06 19:56:55.0 +0100 @@ -1,3 +1,13 @@ +debtags (1.7.3-0.1) unstable; urgency=low + + * Non-maintainer upload. + * Don't try to run debtags in cronjob when binary is not present. (Closes: +#435067, #435235, #435243, #457058) + * Don't make cron mail output unless an error is encountered. (Closes: +#431994) + + -- Bas Wijnen <[EMAIL PROTECTED]> Thu, 06 Mar 2008 18:53:21 +0100 + debtags (1.7.3) unstable; urgency=low * Allow to install extra tag sources in /etc/debtags/sources.list.d/ diff -rup old/debtags-1.7.3/debian/debtags.cron.daily new/debtags-1.7.3/debian/debtags.cron.daily --- old/debtags-1.7.3/debian/debtags.cron.daily 2007-07-06 15:21:25.0 +0200 +++ new/debtags-1.7.3/debian/debtags.cron.daily 2008-03-06 18:45:49.0 +0100 @@ -1,4 +1,4 @@ #!/bin/sh # Update the data and index files of Debtags -debtags update +test ! -x /usr/bin/debtags || /usr/bin/debtags update 2>/dev/null || echo debtags update error signature.asc Description: Digital signature
Bug#464346: gfpoken: old Build-Depends
Package: gfpoken Version: 0.31-1 Severity: Serious Justification: FTBFS Tags: Pending Ok, I shouldn't upload things just before going to bed... I didn't update the build dependencies in the control file, which means the package cannot build on a clean system. This will soon be fixed. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Bug#460042: Build failure on alpha: fix delayed
I'm delaying a fix for this. The reason is that bug #458881 is causing an FTBFS as well, so this is really hard to test. I'll try to fix it by porting the whole thing to gtk+-2. This is also a good idea, because gtk+-1.2 is getting really old, and it's probably a good idea to remove it at some point. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Bug#460042: gfpoken: gimp script fails on alpha
Package: gfpoken Version: 0.30-5 Severity: serious Justification: FTBFS The gimp script hangs when building on alpha. I don't know why. I'm thinking of rewriting the script to use a different image processor than the gimp, because the gimp seems to be continuously changing its input requirements. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Bug#458881: gfpoken: FTBFS: configure: error: Cannot build without Gdk-Imlib
reassign 458881 imlib-base retitle 458881 imlib-config: Fails to set include dir for --cflags-gdk thanks On Thu, Jan 03, 2008 at 02:31:13PM +0100, Lucas Nussbaum wrote: > On 03/01/08 at 14:04 +0100, Bas Wijnen wrote: > > Thanks for reporting this. However, I don't understand what's wrong. I > > hope you have some of the logs from the build process, or can regenerate > > them (in particular config.log). > > Sure, here is config.log, generated in a clean sid amd64 chroot. Thanks. > configure:3847: checking for IMLIB - version >= 1.8.2 > configure:3919: gcc -o conftest -g -O2conftest.c -L/usr/lib -lgdk_imlib > >&5 > In file included from /usr/include/gdk_imlib.h:5, > from conftest.c:13: > /usr/include/gdk_imlib_types.h:1:21: error: gdk/gdk.h: No such file or > directory This seems to be the problem. The file is in /usr/include/gtk-1.2/gdk/gdk.h, so the option -I/usr/include/gtk-1.2 is needed for it to be found as . That option used to be given by imlib-config --cflags-gdk, as part of `gtk-config --cflags`, but it isn't anymore. That is fine for normal programs (assuming the idea is that programs should specify it themselves if they need it, although that doesn't seem sensible since imlib-gdk cannot be used without gdk), but then /usr/share/aclocal/imlib.m4 should pass it itself. I'm reassigning this bug to imlib-base, which contains imlib-config and /usr/share/aclocal/imlib.m4. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Bug#458881: gfpoken: FTBFS: configure: error: Cannot build without Gdk-Imlib
Hi, Thanks for reporting this. However, I don't understand what's wrong. I hope you have some of the logs from the build process, or can regenerate them (in particular config.log). On Thu, Jan 03, 2008 at 01:11:22PM +0100, Lucas Nussbaum wrote: > > checking for imlib-config... /usr/bin/imlib-config > > checking for IMLIB - version >= 1.8.2... no > > *** Could not run IMLIB test program, checking why... > > *** The test program failed to compile or link. See the file config.log > for the > > *** exact error that occured. This usually means IMLIB was incorrectly > installed > > *** or that you have moved IMLIB since it was installed. In the latter > case, you > > *** may want to edit the imlib-config script: /usr/bin/imlib-config > > configure: error: Cannot build without Gdk-Imlib Perhaps the bug is in gdk-imlib? I know there are plans to remove it from the archive, but that shouldn't mean it doesn't work at all, right? Looking at /usr/share/aclocal/imlib.m4, I don't see what can be wrong. The build log shows that gdk-imlib11-dev version 1.9.15 is installed, and that's the same I have here (on ia-32). Thanks for your help, Bas Wijnen -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Bug#453198: NMU uploaded to delayed/7 queue
Hi, I've sponsored Li Daobing's NMU patch and uploaded it to the delayed/7 queue. This means that if you (the maintainer) don't like the solution, you still have 7 days to cancel the actual upload. You should be getting mail about that as well, I think. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Bug#450433: gfpoken: FTBFS: libgnomevfs-WARNING **: Unable to create ~/.gnome2 directory: No such file or directory
On Wed, Nov 07, 2007 at 12:24:49PM +0100, Lucas Nussbaum wrote: > The build actually doesn't fail, it just blocks for hours. The SIGTERM > is caused by me killing the build processes after hours.. This suggests that the gimp-script in mktiles fails to execute gimp-quit. That would not surprise me either: your build uses a newer version of the gimp than I had, and they aren't really expecting script-fu to be used for batch processing in my experience. I'll see if this is indeed the problem. > 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 the gimp script is indeed the problem, I could add it there, but I think most people (and certainly most upstreams) consider artwork something to package prebuilt, if it is generated at all. Is it useful anyway to add it? Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Bug#441126: gfpoken - FTBFS: montage: unable to open image `/tmp/tmp.pFPMh17125/blender//0064.png': No such file or directory.
On Wed, Nov 07, 2007 at 10:24:37AM +0100, Lucas Nussbaum wrote: > severity 441126 serious > thanks Why the severity-upgrade? The actual problem is in blender AFAIK, not in gfpoken, so if the severity must be upgraded, it should be that of #441216. Gfpoken failed to build because of it, but that's worked-around by using pre-built files when blender fails. So at this moment the only thing I (as gfpoken maintainer) can do, is wait for blender to be fixed. In the meantime, there is no real problem (because there is a workaround). This doesn't seem "serious" to me. > It's not an endianess problem: I see this too on i386. You do? It built fine for me on i386. What version of blender is this about? It can't be a blender version problem either, because on mips it fails, but on mipsel it succeeds, and both builds used 2.45-1. > It seems to be caused by the fact that something tries to write to > $HOME during the build. I took a lot of care to get rid of that problem (setting $HOME to a tempdir, for example). If I missed something, please let me know what. However, it seems unlikely because the buildds use a nonexistent home, and many of them can build the package successfully (including running blender). Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Bug#444509: [Sponsor found] Re: Bug#444509: grig: FTBFS: error: 'GtkTooltips' undeclared
I didn't read the discussion before, but I think I know what it's about anyway, and I'd like to say something about it. :-) On Tue, Oct 09, 2007 at 07:51:48PM +0200, Cyril Brulebois wrote: > Bernd Zeimetz <[EMAIL PROTECTED]> (09/10/2007): > > > I could have stripped these parts from the diff, but they would be > > > added anyway, > > > > no, you can just remove them in your clean target. > > The point is exactly about adding them in the clean target, so that > their being up-to-date is ensured during the build. Running auto* will regenerate all files, so they will be up to date. IMO (but others disagree), this is a good thing: everything should be regenerated during a build. This ensures that the included files are indeed the source, and that users who change the source can use Debian's build system to create packages with those changes included. If you regenerate all generated files, it is safe to remove them in the clean target. That way, they will be skipped by the diff, which will make the diff.gz much cleaner. > > No need to change them at all - they're replaced at build time anyway. > > Exactly because they are handled in the clean target, from which you > propose to remove them. I might have troubles understanding your logic, > if any. If I understand correctly, you are installing new versions of config.* in the clean target. I suppose you do not run autoconf/automake, because if you do, there is no need to do that. The proposal was (it seems to me) to change that. If you do run automake and autoconf, the new versions will be installed and you don't need to do anything. Removing them in the clean target is just for making the diff.gz nice. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Bug#442854: hex-a-hop: [m68k] FTBFS: packfile.h:57: error: size of array 'static_assert1' is negative
On Mon, Sep 17, 2007 at 03:34:25PM +0200, Jens Seidel wrote:
> > The package fails to build on m68k, see
> > http://buildd.debian.org/fetch.cgi?&pkg=hex-a-hop&ver=0.0.20070315-5&arch=m68k&stamp=1189827580&file=log
> >
> > g++ -Wall -W -g -DUSE_GETTEXT -O2 -D_VERSION=\"1.0.0\"
> > -DDATA_DIR=\"/usr/share/games/hex-a-hop\" `sdl-config --cflags` -c -o
> > hex_puzzzle.o hex_puzzzle.cpp
> > packfile.h:57: error: size of array 'static_assert1' is negative
> > http://lists.alioth.debian.org/mailman/listinfo/pkg-games-devel
>
> Oops, I explitely added this test and now I wonder whether I should be
> happy that this error was found or not :-)
>
> I do not have access to a m68k machine. Bas, could you please provide
> the output of typeof(Entry), where Entry is defined in packfile.h?
I don't have one either, but I can see if I may be able to get the test
done anyway. If someone else has one, please do it instead. :-)
I saw the problem because I just browsed the buildd logs of my
(maintained and sponsored) packages.
> If it is smaller as 8 I can probably add some dummy data the other way
> is probably a little bit more difficult (how to change the alignment of
> data?).
If you know sizes, you can use this notation (this creates a struct
where the 32-bit value is not 32-bit-aligned):
struct descriptor_register
{
unsigned limit : 16;
unsigned base : 32 __attribute__((packed));
unsigned padding : 16;
};
> The problem is that hex-a-hop reads a char data stream and interprets it as
> an array of type Entry. I knew that this could cause trouble so I added the
> assert test.
Sounds like it's better to rewrite the parsing from "compiler, this here
is an array of these things" to manually parsing the data and filling
the array. Reading binary data directly from disk is a very good way to
get non-portable programs. ;-)
But I think I already heard you mention something like that before, and
it was too hard to fix it all in patches, right? If upstream isn't
interested/responding, then a fork may be a good idea...
> Is the build machine a 64 bit system?
I know nothing more about it than what's on the website. I don't think
m68k machines are 64 bit, but I'm not very familiar with them.
If there's no other way, I think I can get shell access to a Debian
machine, I'm not sure how complex it is to arrange that.
Thanks,
Bas
--
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html
signature.asc
Description: Digital signature
Bug#442854: hex-a-hop: [m68k] FTBFS: packfile.h:57: error: size of array 'static_assert1' is negative
Package: hex-a-hop Version: 0.0.20070315-5 Severity: Serious Justification: FTBFS The package fails to build on m68k, see http://buildd.debian.org/fetch.cgi?&pkg=hex-a-hop&ver=0.0.20070315-5&arch=m68k&stamp=1189827580&file=log g++ -Wall -W -g -DUSE_GETTEXT -O2 -D_VERSION=\"1.0.0\" -DDATA_DIR=\"/usr/share/games/hex-a-hop\" `sdl-config --cflags` -c -o hex_puzzzle.o hex_puzzzle.cpp packfile.h:57: error: size of array 'static_assert1' is negative make[1]: *** [hex_puzzzle.o] Error 1 -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Bug#441759: pioneers-server-gtk dies on startup
Hi, Thanks for reporting this. I had pioneers-console depend on the wrong data package. As a workaround, you can install pioneers-console-data manually. I'll upload a new version with correct dependencies. Thanks, Bas Wijnen On Mon, Sep 10, 2007 at 07:02:19PM -0400, aleksey wrote: > Either clicking "create game" in the "start a new game" dialog box in > the GTK pioneers client, or running pioneers-server-gtk directly results > in the following output: > > ** ERROR **: No games available > aborting... > Aborted -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Bug#441210: gfpoken: FTBFS: gimp script broken
Package: gfpoken Version: 0.30-2 Severity: serious The script to build the tile images doesn't work. This makes the build fail. I hope to soon find the cause and upload a fix. -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Bug#441126: gfpoken - FTBFS: montage: unable to open image `/tmp/tmp.pFPMh17125/blender//0064.png': No such file or directory.
Hi, Thanks for letting me know. This seems to be an endianness-problem in Blender, seeing that the same failure happens on mips, but not on mipsel or other little-endian architectures. (There's a different error there ;-) ). I'll file a bug there and block this one on it. In the meantime, I'll ship pre-built images and let the build work even if blender can't load the file. While I don't like using precompiled files, it is better than waiting possibly a long time for a fix which will probably not be given high priority by the Blender people. Thanks again, Bas Wijnen On Thu, Sep 06, 2007 at 11:35:29PM +0200, Bastian Blank wrote: > Package: gfpoken > Version: 0.30-2 > Severity: serious > > There was an error while trying to autobuild your package: > > > Automatic build of gfpoken_0.30-2 on lxdebian.bfinv.de by sbuild/s390 98 > [...] > > ./art/mkmarbles > > guessing 'blender-bin' == '/usr/bin/blender-bin' > > Compiled with Python version 2.4.4. > > Checking for installed Python... got it! > > Loading ./art/marbles.blend failed: File incomplete > > > > Error: no such file or Blender text -- initdir. > > ERROR: No camera > > > > Blender quit > > montage: unable to open image `/tmp/tmp.pFPMh17125/blender//0064.png': No > > such file or directory. > > make[1]: *** [png/marbles.png] Error 1 > > make[1]: Leaving directory `/build/buildd/gfpoken-0.30' > > make: *** [build-stamp] Error 2 > > ** > > Build finished at 20070906-1352 > > FAILED [dpkg-buildpackage died] > > > ___ > Pkg-games-devel mailing list > [EMAIL PROTECTED] > http://lists.alioth.debian.org/mailman/listinfo/pkg-games-devel -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Bug#440671: gfpoken - FTBFS: error: Cannot create folder '/srv/buildd/.gimp-2.4': Permission denied
Hi, Thanks for reporting this. Appearantly running gimp as part of the build process has become harder than before. I'll have a look at this. However, it's hard to check if the next upload will work, because building works fine in pbuilder, for example. Is there a way to test the build before uploading, or should I just try and see if it works? Thanks, Bas On Mon, Sep 03, 2007 at 04:49:11PM +0200, Bastian Blank wrote: > Package: gfpoken > Version: 0.30-1 > Severity: serious > > There was an error while trying to autobuild your package: > > > Automatic build of gfpoken_0.30-1 on lxdebian.bfinv.de by sbuild/s390 98 > [...] > > ./art/mktiles > > LibGimpThumb-Message: Cannot determine a valid home directory. > > Thumbnails will be stored in the folder for temporary files (/tmp) instead. > > error: Cannot create folder '/srv/buildd/.gimp-2.4': Permission denied > > make[1]: *** [tiles-stamp] Error 1 > > make[1]: Leaving directory `/build/buildd/gfpoken-0.30' > > make: *** [build-stamp] Error 2 > > ** > > Build finished at 20070830-0020 > > FAILED [dpkg-buildpackage died] > > > ___ > Pkg-games-devel mailing list > [EMAIL PROTECTED] > http://lists.alioth.debian.org/mailman/listinfo/pkg-games-devel -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Bug#439492: Fixed in new upstream version
Hi, Thanks for reporting this. The problem was in the tile-building script, which used gimp scripting. The new version of the gimp is stricter with its language rules, so the script no longer worked. I fixed that in the new upload. Thanks again, Bas Wijnen -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Bug#434741: hex-a-hop: segfaults right after trying to start
On Thu, Jul 26, 2007 at 02:03:23PM +0200, Gerfried Fuchs wrote: > I guess the trying to allocate huge parts of memory might be related to > an endianness problem within the .dat file. Is the dat file format > documented somehwere? Maybe someone able to do so wants to check that > code for endianness problems in that area? You are right, indeed. The offending code is in packfile.h (PackFile1::Read): int size; fseek(f, -(int)sizeof(size), SEEK_END); int end_offset = ftell(f); fread(&size, sizeof(size), 1, f); fseek(f, end_offset - size, SEEK_SET); Obviously, size needs to be transformed to host endianness after reading it. Also, it seems broken because it uses sizeof(size). This means that on 64bit architectures, it will read the last 8 bytes of the file. Since the file itself is in arch-all, and thus not rebuilt, this cannot be correct. Sorry I'm not attaching a patch, but with this info it shouldn't be too hard for someone else to write one. Hope that helps, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Bug#294520: Patch for this bug
Hi, Great to see some work being done on this! On Sat, Jul 07, 2007 at 03:20:03PM +0200, Samuel Thibault wrote: > This is really a bug in libparted. The difference between parted and > qtparted is that qtparted uses ped_disk_duplicate() for getting a fresh > copy of the partition table. And it happends that ped_disk_duplicate() > calls ped_disk_add_partition(), which makes a lot of "bureaucracy", > including _renumbering_ through _partition_enumerate()... (and > alignment, etc...) > > Here is patch for making ped_disk_duplicate() add the partition itself > in a much direct way, so as to make sure the duplicated partition is > really exactly the same as the original. > > Bas Wijnen, le Wed 22 Feb 2006 11:57:08 +0100, a ?crit : > > On Wed, Feb 15, 2006 at 10:21:42PM -0600, Adam Porter wrote: > > > On Friday 10 February 2006 06:46, Bas Wijnen wrote: > > > > Could you please test if the problem is solved with this patch? > > The patch doesn't solve the real issue explained above. Can you explain? Given your description I would expect the patch to fix both the problem and the symptom (of wrongly-numbered partitions). Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Bug#427614: z80asm: Fails to assemble bit instructions
Package: z80asm Version: 1.3-1 Severity: grave Justification: renders package unusable The bit instructions (bit, rst, set) don't work anymore. I should have reported this before the migration to testing, sorry about that. I hope to have a fix ready soon. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.17-1-686 (SMP w/1 CPU core) 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 z80asm depends on: ii libc6 2.5-9+b1 GNU C Library: Shared libraries z80asm recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#409602: bumprace locks up when game over during crash
Package: bumprace Version: 1.5.2-1 Severity: grave Justification: causes non-serious data loss I crashed (in 1-player mode) my ship during the last ticks of the clock, so that "Crashed" and "timeout" were on screen simultaneously. After that, it asked me to enter my name for the high score list, but the keyboard was not working. I switched to a vc to kill the program, after which the resolution of my desktop was wrong, and the mouse was no longer working. I managed to shut down the running programs using keyboard shortcuts, but I don't expect "normal" users to be able to do this. They'd have to restart the computer, or at least X, which is why I consider this a data-loss bug. Feel free to downgrade the severity if you disagree. It is a very rare situation after all. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages bumprace depends on: ii bumprace-data 1.5.2-1 data files for bumprace ii libc6 2.3.6.ds1-10 GNU C Library: Shared libraries ii libjpeg62 6b-13The Independent JPEG Group's JPEG ii libsdl-image1.2 1.2.5-3 image loading library for Simple D ii libsdl-mixer1.2 1.2.6-1.1+b2 mixer library for Simple DirectMed ii libsdl1.2debian 1.2.11-7 Simple DirectMedia Layer ii zlib1g 1:1.2.3-13 compression library - runtime bumprace recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#407537: sdljump: should be removed from testing
On Fri, Jan 19, 2007 at 01:07:07PM +0100, Cyril Brulebois wrote: > Bas Wijnen <[EMAIL PROTECTED]> (19/01/2007): > > Now that gnujump has entered testing, sdljump should be removed from > > the archive. The package has been renamed. > > Hi, > > wouldn't be a RoM (bug against ftpmaster) the way to go? Yes, I sent that as well, but I wanted an RC bug to make even more sure that it doesn't get released with Etch. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Bug#407537: sdljump: should be removed from testing
Package: sdljump Version: 1.0.0-2 Severity: serious Now that gnujump has entered testing, sdljump should be removed from the archive. The package has been renamed. -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Bug#404012: I'm not planning to change z80asm, please let me know if I misunderstood you
Hi, You wrote in response to bug #404012 "It be fixed in upload." I conclude from that that you'll remove the file from z88dk-bin. If that is not the case, or you want to propose some other solution, please let me know. Thanks, Bas Wijnen -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Bug#403424: gnujump: Packages contains no binary or data
Hi Cyril and Sebastian, Thanks for reporting and fixing this. I was appearantly a bit too fast with the rename. Since I fixed the problem before reading Cyril's e-mail, I applied a slightly different fix, but this time I tested the result properly (which of course I should have done in the first place as well). I just uploaded the new version, including the manpage typo fix. Thanks, Bas Wijnen On Sun, Dec 17, 2006 at 09:33:49PM +0100, Cyril Brulebois wrote: > Cyril Brulebois <[EMAIL PROTECTED]> (17/12/2006): > > cd /debian; rename s/sdljump/gnujump/ sdljump* > > That's a little more subtle, but a fixed source package is available at > the following address: > > http://kibi.sysif.net/pub/packages/gnujump/gnujump_1.0.0-2.dsc > > Cheers, > > -- > Cyril Brulebois > ___ > Pkg-games-devel mailing list > Pkg-games-devel@lists.alioth.debian.org > http://lists.alioth.debian.org/mailman/listinfo/pkg-games-devel -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Bug#383738: Bug found (partly) in sane
Hi, The segfault I hit was due to incorrect error handling in sane. When that is fixed, I get a scanner error "incorrect window". I have no idea where it comes from (perhaps the scanner itself), grep doesn't find the message in the source (neither in the module, nor in sane). Anyway, I think the patch should just be used. Although it isn't enough to fix my scanner, it should at least be an improvement, and it may work for the other scanners. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Bug#383738: perhaps the patch doesn't work
While the patch I just sent makes the code compile, I just tried using it to scan with the onscsi module (microtek scanner), and both xsane and xscanimage segfault. Backtrace from xsane: (gdb) bt #0 0xb6e33c45 in sanei_scsi_req_enter2 () from /usr/lib/sane/libsane-microtek2.so.1 #1 0xb6e341de in sanei_scsi_cmd2 () from /usr/lib/sane/libsane-microtek2.so.1 #2 0xb6e34270 in sanei_scsi_cmd () from /usr/lib/sane/libsane-microtek2.so.1 #3 0xb6e279de in sane_microtek2_start () from /usr/lib/sane/libsane-microtek2.so.1 #4 0xb7f31a8f in sane_dll_start () from /usr/lib/libsane.so.1 #5 0xb7f337bd in sane_start () from /usr/lib/libsane.so.1 It seems to be a bug in sane, but it seemed a good idea to mention it before this patch is applied. :-) Any reports of scanners which do work with this patch would probably be welcome, though, as they would mean that the patch is at least useful: without it the code doesn't even compile, anyway. :-) Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Bug#383738: ppscsi-source: and the attachment ;-)
Sorry, I forgot to attach the patch. Here it is. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html ppscsi.tar.bz2 Description: Binary data signature.asc Description: Digital signature
Bug#383738: ppscsi-source: Patch for this and new 2.6.18 problem
tags 383738 +patch
thanks
Hi,
First I ran into a problem that scsi_request is no longer available in 2.6.18.
Fortunately it isn't used in the module, so just removing types from the
header files fixed that.
Than I ran into the problem of this bug, so I patched that as well. Attached
is the resulting .tar.bz2 file, which works when it is put in /usr/src. The
package source looked a bit too complicated to see at a glance where to change
it, but I suppose that should be easy for the maintainer. The changes I made
are in
modules/ppscsi/{scsi,scsi_typedefs,ppscsi}.h
(which can of course be easily seen with diff -urp on the unpacked original
and modified tarballs.)
Thanks,
Bas
--
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html
signature.asc
Description: Digital signature
Bug#388568: Acknowledgement (xserver-xorg: postinst can hang)
tags 388568 +patch thanks I have found the problem. On line 966 of the postinst it says: db_input "$PRIORITY" "$TEMPLATE" || debug_echo "v_s_d_i/db_input $PRIORITY $TEMPLATE" This is followed by if [ $? -eq 30 ]; then The return value of 30 is specified for db_input. However, if db_input returns 30, debug_echo is called, which always returns 0. So the check never matches, and the validation loop is entered even though no question is asked. The easiest solution is to remove the debug_echo. If it is needed for some reason, a construct like this should be made (note that this happens in a set +e block): db_input "$PRIORITY" "$TEMPLATE" retval=$? if [ $retval -ne 0 ] ; then debug_echo "v_s_d_i/db_input $PRIORITY $TEMPLATE" ; fi if [ $? -eq 30 ]; then Thanks, Bas Wijnen -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Bug#388568: xserver-xorg: postinst can hang
Package: xserver-xorg Version: 7.1.0-1 Severity: Grave Justification: Renders package unusable When trying to make a live CD using live-package, the install hangs on the postinst of xserver-xorg. Breaking out of it and doing dpkg --configure --pending by hand (so the debconf frontend is not noninteractive) in the chroot results in a looping null_string_error (from templates). No question is asked, just the error and when I press Ok the error reappears. Looking at the postinst, this can only come from line 1249, getting a monitor identifier. I have no idea why this happens now though, since yesterday I managed to make some CD images. Perhaps a new debconf version was released in between... -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Bug#371086: if you edit history, old RC bugs will show up again
On Sun, Sep 10, 2006 at 09:49:11AM +0200, Andreas Barth wrote: > Hi, Hi, > bug 371086 shows up again as RC, as the version this bug was fixed in > (pioneers/0.9.64-1) is no longer mentioned in the changelog. Oops, I must have forgotten to synchronise the changelog. > If this version was really cut out, you need to fix this bug again. It wasn't. > If this version is still part of history, please don't cut it out in the > changelog. Right. Thanks for notifying me, I'll fix it in the next upload. Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
