Bug#1075274: minetest is marked for autoremoval from testing
Hello, This bug seems related to https://github.com/minetest/minetest/issues/14738 If so, the fix is rather trivial and provided in the github issue. I could do an upload on need, even if I did not do any since years for this package. Tell me. Have a good one, Mt signature.asc Description: This is a digitally signed message part
Bug#1073038: po4a: Fails due to undefined subroutine Locale::Po4a::Pod::dgettext
Hello, I just updated the NEWS file. I hope it's OK now, but any potential improvement is welcome. Mt Le jeudi 13 juin 2024 à 01:09 +0200, Guillem Jover a écrit : > On Thu, 2024-06-13 at 00:45:14 +0200, Martin Quinson wrote: > > Le jeudi 13 juin 2024 à 00:29 +0200, Guillem Jover a écrit : > > > On Thu, 2024-06-13 at 00:02:43 +0200, Martin Quinson wrote: > > > > The problem is that Perl has a rather unexpected behavior wrt utf8, > > > > UTF-8 > > > > and UTF8. These names are not aliases of others in Perl. See > > > > https://perldoc.perl.org/Encode#UTF-8-vs.-utf8-vs.-UTF8 > > > > > > Sure, but here I think this does not matter (in theory), because it > > > depends on how the pod parser interprets the encoding name, and from > > > checking the perl code it seems it maps /utf-?8/i to ":encoding(UTF-8)". > > > So they are really treated the same, at least when it comes to POD, that > > > does not mean perl has that distinction for the encoding in other > > > contexts. > > > > Ok, ok. You are perfectly right. This distinction between utf8 and UTF-8 is > > perfectly useless in the context of POD files. I just pushed yet another > > commit > > to not do that in POD. > > Perfect, thanks! :) > > > Please tell me whether it looks good to you now. > > I just hot-fixed my installed po4a and it seems to be working fine > now. Thank you! > > You might also perhaps want to update the NEWS file after that change > though? :) > > Regards, > Guillem signature.asc Description: This is a digitally signed message part
Bug#1073038: po4a: Fails due to undefined subroutine Locale::Po4a::Pod::dgettext
Le jeudi 13 juin 2024 à 00:29 +0200, Guillem Jover a écrit : > On Thu, 2024-06-13 at 00:02:43 +0200, Martin Quinson wrote: > > Le mercredi 12 juin 2024 à 17:14 +0200, Guillem Jover a écrit : > > > > > > Unfortunately neither Encode::find_encoding()->name nor > > > Encode::resolve_alias() seem helpful here because they return > > > "utf-8-strict" for "UTF-8" which will not match against "utf-8" for > > > the canonical "utf8". > > > > The problem is that Perl has a rather unexpected behavior wrt utf8, UTF-8 > > and UTF8. These names are not aliases of others in Perl. See > > https://perldoc.perl.org/Encode#UTF-8-vs.-utf8-vs.-UTF8 > > Sure, but here I think this does not matter (in theory), because it > depends on how the pod parser interprets the encoding name, and from > checking the perl code it seems it maps /utf-?8/i to ":encoding(UTF-8)". > So they are really treated the same, at least when it comes to POD, that > does not mean perl has that distinction for the encoding in other > contexts. Ok, ok. You are perfectly right. This distinction between utf8 and UTF-8 is perfectly useless in the context of POD files. I just pushed yet another commit to not do that in POD. > Please tell me whether it looks good to you now. Thanks, Mt signature.asc Description: This is a digitally signed message part
Bug#1072594: This was not a failure caused by po4a, but a misconfiguration in goobox
I think that the fix applied to #1072594 (recoding the input file from latin-1 to UTF-8) was not necessary. Changing the config of po4a to correctly specify the used encoding would have worked. I tried to improve the error messages upstream to help future users to debug such issues, but in any case, this does not justify a RC bug against po4a, thus closing. Thanks for reporting, Mt signature.asc Description: This is a digitally signed message part
Bug#1073038: po4a: Fails due to undefined subroutine Locale::Po4a::Pod::dgettext
Hello, I just commited a fix for the undefined subroutine error. Le mercredi 12 juin 2024 à 17:14 +0200, Guillem Jover a écrit : > > That fixed that issue but then it fails with: > > > > ,--- > > PO4A man.stamp > > po4a::pod: The file deb-buildinfo.pod declares utf8 as encoding, but you > > provided UTF-8 as master charset. Please change either > > setting. > > at /usr/bin/po4a line 1663. > > make[2]: *** [Makefile:902: man.stamp] Error 255 > > `--- > > I think the charset comparison is too naive though, and does not cover > for example any aliases listed in «man Encode::Supported». I think a > better comparison logic could look like this: > > ,--- > use Encode; > > my $enc_charset = Encode::find_encoding($charset); > my $enc_master_charset = Encode::find_encoding($master_charset); > > say 'match' if $enc_charset->mime_name eq $enc_master_charset->mime_name; > `--- > > Unfortunately neither Encode::find_encoding()->name nor > Encode::resolve_alias() seem helpful here because they return > "utf-8-strict" for "UTF-8" which will not match against "utf-8" for > the canonical "utf8". The problem is that Perl has a rather unexpected behavior wrt utf8, UTF-8 and UTF8. These names are not aliases of others in Perl. See https://perldoc.perl.org/Encode#UTF-8-vs.-utf8-vs.-UTF8 So I don't think that you will find a piece of Perl code that will allow to merge these names to declare that they are equivalent. In some sense, that's the essence of all issues I introduced in po4a v0.70 when introducing perlIO to control the encoding issues. I went from a lax system being utf8 by default but happily taking latin-1 encoding files to a much stricter UTF-8 system by default and forcing the user to specify if they want another encoding. Instead, I just pushed a commit changing the error message when charsets are utf8 and UTF-8 to insist on the difference between these encodings in Perl. https://github.com/mquinson/po4a/commit/afe6e1344ffad9d87dd807a81ed6467d6101b15f Please tell me if it's enough. > I'm not sure whether lib/Locale/Po4a/Xml.pod might need a similar > treatment, because that might depend on what encodings are supported > in there, against what is supported in po4a I guess. Ah, good catch. I'd have forgotten this one. Thanks for your help chasing this down, Mt signature.asc Description: This is a digitally signed message part
Bug#1073038: po4a: Fails due to undefined subroutine Locale::Po4a::Pod::dgettext
Le mercredi 12 juin 2024 à 04:47 +0200, Guillem Jover a écrit :
> Package: po4a
> Version: 0.70
> Severity: serious
>
> Hi!
>
> When building dpkg, it now fails with something like this:
>
> ,---
> Making check in man
> make[1]: Entering directory '/dpkg/man'
> /usr/bin/po4a --previous --srcdir . --destdir . --no-backups --porefs file
> --msgmerge-opt=--add-location=file --package-name dpkg-man --package-version
> 1.22.6-80-gec07 --copyright-holder "Dpkg Developers" --msgid-bugs-address
> debian-d...@lists.debian.org ./po/po4a.cfg
> Undefined subroutine &Locale::Po4a::Pod::dgettext called at
> /usr/share/perl5/Locale/Po4a/Pod.pm line 94, <$fh> line 21.
> make[1]: *** [Makefile:902: man.stamp] Error 255
> make[1]: Leaving directory '/dpkg/man'
> `---
>
> It seems the module is missing some import.
Hello,
the attached patch could help, but I fail to reproduce the failure in the first
place. I built dpkg v1.22.6 against po4a v0.72 and it builds with no failure.
The "Making check in man" section LGTM but I'm not sure of what it should look
like.
I tried the git version of po4a with git-pbuilder, but it complains about not
being able to determine whether it's a git or a release build. I must be
missing some config on my side.
Could you please do the following steps, please?
* Try whether the failure still happens with the latest po4a
* Try whether the attached patch applied to the latest po4a helps
* Tell me more details about how to reproduce the failure
Thanks in advance, and sorry for the inconvenience. To me, this part of po4a
code was not changed in years, so I need help to understand the issue.
Mt
diff --git a/lib/Locale/Po4a/Pod.pm b/lib/Locale/Po4a/Pod.pm
index 4b3dc042..bd3d5c1a 100644
--- a/lib/Locale/Po4a/Pod.pm
+++ b/lib/Locale/Po4a/Pod.pm
@@ -27,6 +27,8 @@ use vars qw(@ISA);
use Carp qw(croak confess);
+use Locale::Po4a::Common qw(dgettext);
+
sub initialize { }
sub translate {
signature.asc
Description: This is a digitally signed message part
Bug#1072643: Upstream po4a now hints about a possible fix to this issue
Hello, I just commited an improved error message in https://github.com/mquinson/po4a/commit/0717616bce2a281a3b7a2348f0d1d9abc9f1b892 I hope that it's enough to fix this issue. Bye, Mt signature.asc Description: This is a digitally signed message part
Bug#1072760: Bug#1072643: Bug#1072760: ikiwiki: FTBFS: Parse errors: No plan found in TAP output
Le lundi 10 juin 2024 à 10:21 +0100, Jonathan Dowland a écrit :
> On Fri, Jun 07, 2024 at 05:22:32PM +0200, Santiago Vila wrote:
> > During a rebuild of all packages in unstable, your package failed to build:
> …
> > t/po.t (Wstat: 65280 (exited 255) Tests: 38 Failed:
> > 0)
> > Non-zero exit status: 255
> > Parse errors: No plan found in TAP output
>
> On the face of it this looks to be a result of po4a changes. I'm not
> sure if the root cause is the same as #1072643 yet; further
> investigation is required.
>
I think that the relevant part of the logs is here:
---
Cannot write to a file without refname at
/usr/share/perl5/Locale/Po4a/TransTractor.pm line 444.
Locale::Po4a::TransTractor::read(Locale::Po4a::Text=HASH(0x559ec7d9f248),
"/tmp/ikiwiki-test-po.nKtVlhHS3_/src/index.mdwn") called at /build/ikiwiki-
3.20200202.4/blib/lib/IkiWiki/Plu
gin/po.pm line 907
IkiWiki::Plugin::po::refreshpot("/tmp/ikiwiki-test-
po.nKtVlhHS3_/src/index.mdwn") called at t/po.t line 225
main::refresh_n_scan("index.mdwn", "translatable.mdwn",
"nontranslatable.mdwn") called at t/po.t line 233
# Tests were run but no plan was declared and done_testing() was not seen.
# Looks like your test exited with 255 just after 38.
t/po.t .
-
That's really astonishing for me. I could not imagine that this function is
called by someone else than po4a itself...
This bug is related to https://github.com/mquinson/po4a/issues/504 which
requires a documentation improvement in po4a, but the bug to fix is in ikiwiki.
You should update your calls to this function to follow the prototype
modification. I'm sorry about that, but I fail to see another option.
Sorry for the inconvenience,
Mt
signature.asc
Description: This is a digitally signed message part
Bug#1072760: Bug#1072643: Bug#1072760: ikiwiki: FTBFS: Parse errors: No plan found in TAP output
Le lundi 10 juin 2024 à 10:21 +0100, Jonathan Dowland a écrit : > On Fri, Jun 07, 2024 at 05:22:32PM +0200, Santiago Vila wrote: > > During a rebuild of all packages in unstable, your package failed to build: > … > > t/po.t (Wstat: 65280 (exited 255) Tests: 38 Failed: > > 0) > > Non-zero exit status: 255 > > Parse errors: No plan found in TAP output > > On the face of it this looks to be a result of po4a changes. I'm not > sure if the root cause is the same as #1072643 yet; further > investigation is required. These two bugs are unrelated. The failure on goobox (#1072643) is linked to the fact that po4a is now much less forgiving about charsets. It now supposes UTF encoding unless specified otherwise. Before, it was relying on the default Perl behavior, which tries to do "the right thing" even if the user does something wrong. This is why previously, the ISO-8859-15 files were accepted without additional configuration while now po4a reports that it's not UTF. Fixing this simply requires to specify the encoding using the -M flag. The question may be about why we changed this. The answer is that the default Perl behavior was not always right leading to messy failures (in particular with gettext which makes things even more complex when msgids contain non-ascii chars), while the new behavior gives us more control. I'll try to improve the error messages to make things more explicit. On its side, the failure on ikiwiki (#1072760) is related to the fact that ikiwiki is using a function that I consider as a private API in po4a and recently changed. The fix is simply to update the the calls of that API in ikiwiki's code, and the update is trivial (simply give the filename twice to use it as refname). Sorry about the inconvenience, but please people, do not CC both bugs as they are unrelated. Sorry again about the inconvenience, Mt signature.asc Description: This is a digitally signed message part
Bug#1071082: Bug#1048703: NMU pushed to DELAYED/10
Hello Pierre, many many thanks for the upload. You just did what I was supposed to do, thanks for that. If you still have your PLM tree around, I'd appreciate if you could push them to the salsa git too. If you don't have that, that's not a problem. I'll try to fulfill my role at some point. Thanks again for your good work, Mt Le mercredi 22 mai 2024 à 23:08 +0200, Pierre Gruet a écrit : > Dear Maintainer, > > I have just uploaded fixes for bugs 1048703 and 1071082 to DELAYED/10. > This is to prevent testing autoremoval of plm on June, 11th. > > Enclosed is the source debdiff of this NMU. It is strictly based upon > the patches I submitted in the two bug logs. > > Please tell me if I should delay or cancel the foreseen NMU. > > Best wishes, > > -- > Pierre signature.asc Description: This is a digitally signed message part
Bug#1042642: ns3: FTBFS with Sphinx 7.1, docutils 0.20: make[6]: *** [Makefile:75: html] Error 2
Hello, thanks for your hard work investigating on this. I confirm that this fixes the build. I am currently relaunching the build with a proper changelog entry before uploading to unstable. The patch I came up with is here: https://salsa.debian.org/debian/ns3/-/blob/master/debian/patches/sphinx-7 Many many thanks for your help, I was not there at all. Mt Le lundi 06 novembre 2023 à 18:12 +0100, s3v a écrit : > Dear Maintainer, > > Problematic lines seem to be [1][2][3]. > After fixing all of them, I was able to build successfully your package in > a sid chroot environment. > > Kind Regards > > [1] > https://sources.debian.org/src/ns3/3.40-1/ns-3.40/doc/models/source/conf.py/#L68 > [2] > https://sources.debian.org/src/ns3/3.40-1/ns-3.40/doc/manual/source/conf.py/#L68 > [3] > https://sources.debian.org/src/ns3/3.40-1/ns-3.40/doc/tutorial/source/conf.py/#L66 signature.asc Description: This is a digitally signed message part
Bug#1030658: More info needed on the RC bug you opened
tag 1030658 +moreinfo thanks Hello Damyan, sorry for not noticing this bug before, I thought I was subscribed to the package. It looks like a missing dependency to me. Could you please give me the output of `ldd /usr/bin/zeal` ? I tried to dig a bit to understand what's going wrong, but the runtime dependencies of the package are auto-generated as they should, and the resulting binary package seem to have the correct dependencies. Could you also please try to install libssl3 manually to see whether it helps? Thanks for reporting, Mt signature.asc Description: This is a digitally signed message part
Bug#1020108: quilt: diff for NMU version 0.66-2.2
Hello everybody, many thanks for your help. There is no need to delay your NMU any further. You could also upload it directly, I'm really happy with your help. I'd really love to see someone helping me updating the package to the latest version. quilt is in maintainance mode upstream, and it's a pitty that I fail to get the latest improvement in Debian since such a long time. Thanks again for your help, and enjoy. Mt Le samedi 15 octobre 2022 à 11:21 +0200, Christoph Biedl a écrit : > tags 1020108 + pending > user debian-rele...@lists.debian.org > usertags 1020108 + bsp-2022-10-de-karlsruhe > thank you > > Dear maintainer, > > turns out this has already been addressed in upstream git, so cherry-picking > that one is the way to go. > > To fix the issues with this package, I've prepared an NMU for quilt > (versioned as 0.66-2.2), debdiff below. An upload to DELAYED/5 will > follow shortly. Please feel free to tell me if I should delay it > longer. > > Regards, > > Christoph -- Pour une évaluation indépendante, transparente et rigoureuse ! Je soutiens la Commission d'Évaluation de l'Inria. signature.asc Description: This is a digitally signed message part
Bug#1020108: quilt: FTBFS: dh_auto_test: error: make -j8 check "TESTSUITEFLAGS=-j8 --verbose" VERBOSE=1 returned exit code 2
Control: tag -1 help I seem to remember that this is a transient bug, that does not occure all the time at all. That being said, I'm not sure I already tested running the tests in parallel. Is that really a FTBFS if the failure only happens under this setting? I tend to remove the FTBFS severity on this one, but I'm not sure. I'm really short on time these days, so any help is welcome. It's maybe the occasion to upgrade the package to the new upstream release, but we have a lot of patches that I'd like to integrate upstream. It takes time because upstream is picky and only integrate sensible changes. I do not blame them for that (to the contrary), but I don't often trust myself to discuss our changes with them. The package is uptodate on salsa. Thanks for any help that could be provided. Mt Le dimanche 18 septembre 2022 à 08:40 +0200, Lucas Nussbaum a écrit : > Source: quilt > Version: 0.66-2.1 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20220917 ftbfs-bookworm > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): > > make[2]: Entering directory '/<>' > > [add-filename-check.test] > > 6 commands (6 passed, 0 failed) > > [altered-series.test] > > 12 commands (12 passed, 0 failed) > > [comments.test] > > 11 commands (11 passed, 0 failed) > > [applied.test] > > 15 commands (15 passed, 0 failed) > > [dir-a-b.test] > > 11 commands (11 passed, 0 failed) > > [colon-in-patch-name.test] > > 23 commands (23 passed, 0 failed) > > [create-delete.test] > > [4] $ mkdir patches -- ok > > [6] $ echo delete > delete -- ok > > [7] $ quilt new test.diff -- ok > > [10] $ quilt add create -- ok > > [13] $ echo create > create -- ok > > [14] $ quilt refresh -- ok > > [17] $ quilt add delete -- ok > > [20] $ rm -f delete -- ok > > [21] $ quilt refresh -- ok > > [23] $ quilt header -r -- ok > > [31] $ quilt patches -v create -- ok > > [33] $ quilt patches delete -- ok > > [36] $ quilt pop -q -- ok > > [40] $ quilt patches create -- ok > > [42] $ quilt patches -v delete -- ok > > [44] $ quilt patches -- /dev/null dev/null null --- -- failed > > grep: warning: stray \ before / != ~ > > grep: warning: stray \ before / != ~ > > grep: warning: stray \ before / != ~ > > [46] $ echo create > create -- ok > > [47] $ rm -f delete -- ok > > [48] $ patch -p1 --dry-run < patches/test.diff -- ok > > 19 commands (18 passed, 1 failed) > > make[2]: *** [Makefile:411: test/.create-delete.ok] Error 1 > > make[2]: *** Waiting for unfinished jobs > > [annotate.test] > > 31 commands (31 passed, 0 failed) > > [duplicate-patch-in-series.test] > > 9 commands (9 passed, 0 failed) > > [conflicts.test] > > 39 commands (39 passed, 0 failed) > > [auto-refresh.test] > > 14 commands (14 passed, 0 failed) > > [dotglob.test] > > 7 commands (7 passed, 0 failed) > > [delete.test] > > 34 commands (34 passed, 0 failed) > > [backup-files.test] > > 119 commands (119 passed, 0 failed) > > make[2]: Leaving directory '/<>' > > dh_auto_test: error: make -j8 check "TESTSUITEFLAGS=-j8 --verbose" VERBOSE=1 > > returned exit code 2 > > > The full build log is available from: > http://qa-logs.debian.net/2022/09/17/quilt_0.66-2.1_unstable.log > > All bugs filed during this archive rebuild are listed at: > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20220917;users=lu...@debian.org > or: > https://udd.debian.org/bugs/?release=na&merged=ign&fnewerval=7&flastmodval=7&fusertag=only&fusertagtag=ftbfs-20220917&fusertaguser=lu...@debian.org&allbugs=1&cseverity=1&ctags=1&caffected=1#results > > A list of current common problems and possible solutions is available at > http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! > > If you reassign this bug to another package, please marking it as 'affects'- > ing > this package. See https://www.debian.org/Bugs/server-control#affects > > If you fail to reproduce this, please provide a build log and diff it with > mine > so that we can identify if something relevant changed in the meantime. -- Pour une évaluation indépendante, transparente et rigoureuse ! Je soutiens la Commission d'Évaluation de l'Inria. signature.asc Description: This is a digitally signed message part
Bug#1018966: widelands-data: RC
Hello Bastien, thanks for your patch. I discussed the MR on salsa (in short, I'd like to understand why my current setup is not working and what it is that you try to fix). In addition, please note that widelands does not build on salsa's CI because of its size. You'll have to test your patch manually, I fear ;) If you know how to get its CI working on salsa, I'm really interested, of course. Thanks again for your help, Mt > This is in fact an RC bug that should have been catch by piuparts > > Patch here not tested please test by runing CI on salsa > https://salsa.debian.org/games-team/widelands/-/merge_requests/2 -- Pour une évaluation indépendante, transparente et rigoureuse ! Je soutiens la Commission d'Évaluation de l'Inria. signature.asc Description: This is a digitally signed message part
Bug#1018966: Information needed about your bug against widelands
Hello waxhead, could you please tell us what is the result of the following command on your machine? ls -la /usr/share/games/widelands/data/i18n/fonts/Culmus/TaameyFrankCLM-Medium.ttf This file is included in the widelands-data package, that seem installed on your machine, so I fail to understand how things could go wrong. Thanks in advance, Mt signature.asc Description: This is a digitally signed message part
Bug#1010804: Thanks for the patch
Hello, I just tested your patch and it works. I will upload the new package shortly. Thanks for your work, Mt. signature.asc Description: This is a digitally signed message part
Bug#1010804: Segfault when applying this patch
package frogatto
tag 1010804 - patch
tag 1010804 + helpneeded
thanks
Hello,
I confirm that the package is not building without this patch, and that the
build proceeds with this patch. But the problem is that the code is segfaulting
systematically when I build the package with this patch. The failure occures
everytime I get out of the house, at the very beginning of the game (all
settings default).
At first I thought it was unrelated, but the valgrind trace is the following:
==549940== Jump to the invalid address stated on the next line
==549940==at 0x0: ???
==549940==by 0x5B62C4: water::draw_area(water::area const&, int, int, int,
int) const (water.cpp:169)
==549940==by 0x5B6705: water::draw(int, int, int, int) const (water.cpp:125)
==549940==by 0x451763: level::draw(int, int, int, int) const
(level.cpp:1930)
==549940==by 0x2FC8C9: render_scene(level const&, screen_position&, entity
const*, bool) (draw_scene.cpp:358)
==549940==by 0x48753B: level_runner::play_cycle() (level_runner.cpp:1410)
==549940==by 0x488B33: level_runner::play_level() (level_runner.cpp:713)
==549940==by 0x1E341E: main (main.cpp:830)
==549940== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==549940==
==549940==
==549940== Process terminating with default action of signal 11 (SIGSEGV)
==549940==at 0x4DED07F: raise (raise.c:45)
==549940==by 0x4DED1FF: ??? (in
/usr/lib/x86_64-linux-gnu/libpthread-2.33.so)
And the line pointed is the following:
#if defined(TARGET_OS_HARMATTAN) || defined(TARGET_PANDORA) ||
defined(TARGET_TEGRA) || defined(TARGET_BLACKBERRY)
if (glBlendEquationOES) {
glBlendEquationOES(GL_FUNC_REVERSE_SUBTRACT_OES);
}
#elif defined(GL_OES_blend_subtract)
glBlendEquationOES(GL_FUNC_REVERSE_SUBTRACT_OES);<-- HERE!
THIS IS LINE 169
#elif defined(USE_GLES2)
glBlendEquation(GL_FUNC_REVERSE_SUBTRACT);
#else
if(GLEW_EXT_blend_equation_separate && (GLEW_ARB_imaging ||
GLEW_VERSION_1_4)) {
glBlendEquation(GL_FUNC_REVERSE_SUBTRACT);
} else {
const int max_color = std::max(water_color[0],
std::max(water_color[1], water_color[2]));
water_color[0] = (max_color - water_color[0])/8;
water_color[1] = (max_color - water_color[1])/8;
water_color[2] = (max_color - water_color[2])/8;
}
#endif
So I feel bad about applying the patch and uploading the package to the archive.
Any help is welcomed. The package is uptodate on salsa.
Mt
signature.asc
Description: This is a digitally signed message part
Bug#991061: ns3 FTBFS with imagemagick with the #987504 change
Thanks for the additional info, and for the patch in the first place. I'll upload it asap. Thx, Mt. signature.asc Description: PGP signature
Bug#991061: ns3 FTBFS with imagemagick with the #987504 change
Hello, I'm sorry to ask, but I fear I need additional information, please. It seems to me that this patch merely circumvent the change in ImageMagik to allow the handling of eps file during the construction of the package. Am I right, or is it only disabling the dangerous parts of the converter while retrieving the parts we need? Sorry to ask, I'm very bad with ImageMagik. Even if it's re-enabling the conversion of eps files for the package building, I guess that this is a good emergency solution to not delay the release too much, provided that we trust the eps files that come with ns-3. Thanks for the proposal. But I would prefer not to live with such a complex and even somewhat dangerous patch in my package, so I'm curious about other solutions that would allow to convert eps to png without ImageMagik. Maybe using gimp and Script-Fu? Thanks for that patch anyway, Mt Le Fri, Jul 16, 2021 at 06:21:21PM +0200, Dennis Filder a écrit : > Control: tag -1 patch > > With this patch the build finished for me. > > Regards, > Dennis Filder > Description: Override overly strict ImageMagick security policy (#987504) > This patch derives a more permissive ImageMagick security policy from > the system default. > Author: Dennis Filder > Last-Update: 2021-07-16 > Bug-Debian: https://bugs.debian.org/991061 > --- a/ns-3.31/doc/models/Makefile > +++ b/ns-3.31/doc/models/Makefile > @@ -496,6 +496,8 @@ > > RESCALE = ../../utils/rescale-pdf.sh > > +POLFILE = "/etc/$(shell convert -version|sed -n '/^Version: /s@Version: > ImageMagick \([[:digit:]]\+\)\..*@ImageMagick-\1@p')/policy.xml" > + > %.eps : %.dia > @echo dia $(notdir $<) > @$(DIA) -t eps $< -e $@ >/dev/null > @@ -506,7 +508,9 @@ > > %.png : %.eps > @echo convert $(notdir $<) > - @$(CONVERT) $< $@ >/dev/null > + test -d ../../../debian/tmp/ImageMagick || mkdir -p > ../../../debian/tmp/ImageMagick > + test -f ../../../debian/tmp/ImageMagick/policy.xml || sed -e '/ domain="coder" rights="none" pattern="PS" .>/s@"none"@"read|write"@' > "$(POLFILE)" > ../../../debian/tmp/ImageMagick/policy.xml > + XDG_CONFIG_HOME="$(shell pwd)/../../../debian/tmp" $(CONVERT) $< $@ > >/dev/null > > %.pdf : %.eps > @echo epstopdf $(notdir $<) > @@ -556,6 +560,7 @@ > clean: > -rm -rf $(BUILDDIR)/* > -rm -rf $(SOURCETEMP) > + -rm -Rf ../../../debian/tmp/ImageMagick > > frag: pickle > @if test ! -d $(BUILDDIR)/frag; then mkdir $(BUILDDIR)/frag; fi -- The web was not envisioned as a form of television when it was invented. But, like it or not, it is rapidly resembling TV: linear, passive, programmed and inward-looking. -- Hossein Derakhshan https://medium.com/matter/the-web-we-have-to-save-2eb1fe15a426 signature.asc Description: PGP signature
Bug#991061: ns3 FTBFS with imagemagick with the #987504 change
Hello, thanks for the report. I've read through the bugs both in debian and ubuntu, and I found the location of the issue in the package (ns3 is quite a large package). ns-3.31/doc/models/Makefile reads (many lines omitted): ``` CONVERT = convert # specify figures from which .png and .pdf figures need to be # generated (all dia and eps figures) IMAGES_EPS = \ $(FIGURES)/lena-dual-stripe.eps \ %.png : %.eps @echo convert $(notdir $<) @$(CONVERT) $< $@ >/dev/null ``` Now, the question is about what is the best move from here. I cannot do as in the bug I've seen by Ubuntu where the eps doc was disabled, as we use(d) convert to move the other way around, eps -> png. Is there another way to convert eps to png that I could use (according to google, ImageMagik is THE way to go here), or shall I ship a broken documentation? Any advice would be welcome here. Thanks, Mt. - Le 13 Juil 21, à 15:59, Adrian Bunk b...@debian.org a écrit : > Source: ns3 > Version: 3.29+dfsg-3 > Severity: serious > Tags: ftbfs > > https://tests.reproducible-builds.org/debian/rb-pkg/buster/amd64/ns3.html > > ... > convert lena-dual-stripe.eps > convert-im6.q16: attempt to perform an operation not allowed by the security > policy `PS' @ error/constitute.c/IsCoderAuthorized/408. > convert-im6.q16: no images defined `source-temp/figures/lena-dual-stripe.png' > @ > error/convert.c/ConvertImageCommand/3258. > make[2]: *** [Makefile:475: source-temp/figures/lena-dual-stripe.png] Error 1 > > > See #987504 for background.
Bug#858498: Please reject simgrid_3.27+dfsg-1
Hello FTP masters, I'm sorry for the extra burden, but I uploaded the new upstream release to unstable by error instead of experimental. This upload needs to be canceled so that I can fix the version in testing. #858498 is RC and was reopened an hour ago. Sorry again for the extra burden, Mt. signature.asc Description: PGP signature
Bug#962368: frogatto-data: Source-only upload not automatically built for non-free packages
Hello, thanks for pointing me to this, I didn't know. And even now, I'm not sure of whether frogatto-data is auto-buildable. The reason why it's non-free is because the licence file states: "The Frogatto game and all content is available for download free of charge from http://www.frogatto.com. The game may be redistributed for non-commercial purposes so long as the entire package is kept in-tact and unmodified. This license must also be included and kept in-tact. It is forbidden to distribute the game, or any portion thereof for any commercial or revenue-generating purpose." Under this light, should I mark the package as auto-buildable? I tend to think so but would appreciate your guidance. In the meanwhile, I'll do a source+binary upload of the package. Thanks again, Mt. - Le 7 Juin 20, à 0:05, Boyuan Yang by...@debian.org a écrit : > Source: frogatto-data > Severity: serious > Version: 1.3.1+dfsg-2 > X-Debbugs-CC: mquin...@debian.org > > Dear Debian frogatto-data maintainers, > > Thanks for updating package frogatto-data in Debian. However, you just > made a source-only upload against a non-free package, which would cause > problems. > > By default, Debian's buildd will not build non-free packages due to > licensing concerns. If your package has no licensing concerns, please > follow instructions as written in the Developers Reference [1] to mark > the package as auto-buildable. If not, please make a binary-only upload > (or a source+binary upload) to actually make sure that the deb package > exists in the archive. > > -- > Regards, > Boyuan Yang > > [1] > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#marking-non-free-packages-as-auto-buildable
Bug#960892: another fix
Control: -1 fixed-upstream Thanks On Fri, May 22, 2020 at 02:35:34AM +0200, Axel Beckert wrote: > Hi Martin. > > Martin Quinson wrote: > > I gave another try to this fix, and the current git version of po4a > > manages to build aptitude even with the recent patch removed. > > > > Could you please give it a try, just to ensure that I didn't mess up > > my verification? > > Can confirm. Thanks for caring! Thanks for this test. I'm happy that this bug is gone now. I will release a new upstream version on Sunday. I'm just giving a few days to the translators to update their work since the fix introduced some strings, and since you have a temporarily fix in aptitude. Have a good one, Mt. -- Walking on water and developing software from a specification are easy if both are frozen. signature.asc Description: PGP signature
Bug#960892: another fix
Hello, I gave another try to this fix, and the current git version of po4a manages to build aptitude even with the recent patch removed. Could you please give it a try, just to ensure that I didn't mess up my verification? Thanks in advance, Mt. -- Reject: The reference on the SimGrid toolkit is outdated. -- Bastard Reviewer From Hell signature.asc Description: PGP signature
Bug#960892: po4a: --srcdir ignored by [po_directory]
Hello, your patch was included in an upstream release. The debian package should be updated shortly. Thanks for your patience, Mt. -- You have a problem and decide to use floats. Now you have 2.0001 problems. signature.asc Description: PGP signature
Bug#951115: New version uploaded
severity 951115 normal thanks Hello, so I uploaded a version of this package without mipsel, and it built nicely on all architectures where its dependencies are to be found (all official architectures plus some others). Thus downgrading this bug. Thanks, Mt. signature.asc Description: PGP signature
Bug#951115: ns3: FTBFS on mipsel (OOM of the linker)
Source: src:ns3 Version: 3.30+dfsg-3.1 Severity: serious Tag: ftbfs Tag: help Hello, I'm the maintainer of this package. I'm opening this bug to discuss the issue with whom may be interested, and keep track of the discussion. The package is currently trying to enter testing to fix 2 (easy) RC bugs, but fails to do so because builds fail on mipsel with the following message: -- as: out of memory allocating 17107680 bytes after a total of 567459840 bytes /tmp/cc23jwIU.s: Assembler messages: /tmp/cc23jwIU.s: Fatal error: can't close /<>/ns-3.30/build- shared/src/lte/bindings/ns3module.cc.7.o: memory exhausted -- I tried to reduce the memory consumption with the following chunks in debian/rules: -- ifeq ($(DEB_HOST_GNU_CPU),mipsel) # Drop the debug symbols all together on mipsel to avoid OOM causing FTBFS export DEB_CFLAGS_MAINT_STRIP=-g export DEB_CXXFLAGS_MAINT_STRIP=-g endif LDFLAGS+=-Wl,--as-needed # Define CFLAGS and friends to harden the build -- must come any addition to these variables DPKG_EXPORT_BUILDFLAGS = 1 include /usr/share/dpkg/buildflags.mk ifeq ($(DEB_HOST_GNU_CPU),mipsel) # Further reduce the memory consumption on mipsel LDFLAGS += -Wl,--reduce-memory-overheads -Wl,--no-keep-memory endif --- The version that failed on the buildd servers does not have these changes, but I tested it on the porterbox. I manually inspected the command-line parameters passed to the parser, and it seem to be all right. Compiling without -g and linking with the reduce-memory-overheads (unless I'm wrong). But this is not sufficient: I get exactly the same error message. In addition, I don't think that this is a real bug of as. ns-3 is a very large library, and upstream is not paying a lot of effort on reducing its size or optimizing the linking phase. I don't have any idea of how to fix it myself. I guess that I should ask for the removal of the mipsel version of this package, but I'm not entirely sure. I'd love to have ns-3 building on every platform, even if I'm certain that nobody will ever try to use it on this platform. This is a rather inefficient simulator used in science. Users will more probably deploy it to a fast compute server. But still, if possible, being compilable on mipsel too would be healthy for the software, if I could. Any help or advice is really really welcomed. Everything is in the salsa repository. Thanks, Mt -- Vae Soli. signature.asc Description: PGP signature
Bug#912074: FindBoost cannot find the stacktrace component
severity: normal reassign 912074 cmake-data thanks Hello, searching further, I see that I'm wrong in the sense that no other boost package provide the header files, and that the header file I'm looking for is actually on my system: $ dlocate /usr/include/boost/stacktrace.hpp libboost1.67-dev:amd64: /usr/include/boost/stacktrace.hpp I'm deeply sorry for this mistake. I blamed the boost packages for nothing. So I need to be more accurate. My symptoms are that cmake fails to find the stacktrace package: The following CMakeList.txt produces the following output: [CMakeLists.txt]--- cmake_minimum_required(VERSION 2.8.8) project(BugReport C CXX) find_package(Boost COMPONENTS stacktrace) [output]--- $ cmake . -- The C compiler identification is GNU 8.2.0 -- The CXX compiler identification is GNU 8.2.0 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done CMake Warning at /usr/share/cmake-3.12/Modules/FindBoost.cmake:1743 (message): No header defined for stacktrace; skipping header check Call Stack (most recent call first): CMakeLists.txt:5 (find_package) -- Could NOT find Boost -- Configuring done -- Generating done -- Build files have been written to: /tmp/toto I do have the following packages: ii cmake 3.12.3-2 amd64 cross-platform, open-source make system ii cmake-data3.12.3-2 all CMake data files (modules, templates and documentation) ii libboost-stacktrace1.67-dev:amd64 1.67.0-7 amd64 library to capture and print stack traces - development files ii libboost1.67-dev:amd641.67.0-7 amd64 Boost C++ Libraries development files Sorry again for the mess, and thanks for your time. Mt signature.asc Description: PGP signature
Bug#912074: libboost-stacktrace1.67-dev: header boost/stacktrace.hpp not included in libboost-stacktrace1.67-dev
Package: libboost-stacktrace1.67-dev Version: 1.67.0-7 Severity: grave Justification: renders package unusable Dear maintainers, I'm really pleased that this new stacktrace library made its way into boost and into debian, but it seems that something went wrong when packaging it because the header files seem to be missing. Here is the content of my version: $ dpkg -L libboost-stacktrace1.67-dev /. /usr /usr/lib /usr/lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/libboost_stacktrace_addr2line.a /usr/lib/x86_64-linux-gnu/libboost_stacktrace_backtrace.a /usr/lib/x86_64-linux-gnu/libboost_stacktrace_basic.a /usr/lib/x86_64-linux-gnu/libboost_stacktrace_noop.a /usr/share /usr/share/doc /usr/share/doc/libboost-stacktrace1.67-dev /usr/share/doc/libboost-stacktrace1.67-dev/changelog.Debian.gz /usr/share/doc/libboost-stacktrace1.67-dev/copyright /usr/lib/x86_64-linux-gnu/libboost_stacktrace_addr2line.so /usr/lib/x86_64-linux-gnu/libboost_stacktrace_backtrace.so /usr/lib/x86_64-linux-gnu/libboost_stacktrace_basic.so /usr/lib/x86_64-linux-gnu/libboost_stacktrace_noop.so As you can see, there is no headerfile while upstream seem to distribute some: https://github.com/boostorg/stacktrace Or maybe I missed something obvious? Many thanks for your work, Mt -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libboost-stacktrace1.67-dev depends on: ii libboost-stacktrace1.67.0 1.67.0-7 ii libboost1.67-dev 1.67.0-7 libboost-stacktrace1.67-dev recommends no packages. libboost-stacktrace1.67-dev suggests no packages. -- no debconf information -- The great thing about TCP jokes is that you always get them. signature.asc Description: PGP signature
Bug#785565: [Ns-developers] State of ns3 in the Debian distribution
Hello, Please do not applogize, there is nothing to be ashamed for. Real life often restrain us from contributing to Debian and others... That's life. Thank you for all you did in the past, and what you will manage to do in the future. That would be really great if you could do an upload without the python-pygoocanvas dependency, please. Thanks in advance, Mt. On Sat, Oct 07, 2017 at 04:28:59PM +0800, YunQiang Su wrote: > Sorry for everyone. > I didn't take care of ns3 for years. > > I will update it in few days. > > On Thu, Oct 5, 2017 at 3:54 AM, Martin Quinson > wrote: > > Hello Tom, thanks for your reply. > > > > On Wed, Oct 04, 2017 at 06:08:01PM +, Tom Henderson wrote: > >> Hi Martin, responses inline below. > >> > >> On 10/04/2017 05:26 AM, Martin Quinson wrote: > >> > Hello dear developers, > >> > > >> > Also, if you have an easy way to drop these dependencies (by disabling > >> > them at build time), that could solve the issue on our side. I know I > >> > should RTFM for that, but I fail to find the time, and I would > >> > appreciate this help in the package maintainance, please. The current > >> > build receipe is here (that's a makefile): > >> > http://sources.debian.net/src/ns3/3.26%2Bdfsg-1/debian/rules/ > >> There isn't an ns-3 build dependency on netanim. The pyviz visualizer is > >> automatically left out of the configuration if the prerequisites are not > >> found by Waf. Is this sufficient (if we don't resolve these package > >> dependencies in time)? > > > > Ok, then I will rebuild the package without that dependency, upload > > it, and it should do the trick for now, I guess. I'll keep you posted. > > > >> We are about to make a new ns-3 release (3.27). We also noticed that the > >> netanim package in Debian stretch is very old (3.100+ while we are now at > >> 3.108). Can we work towards replacing the old versions with the new > >> versions in the current release of Debian, or must we wait until the next > >> Debian release? > > > > There is a plenty of time before the next official Debian release > > (maybe one year and half). So we can definitely work something out for > > Debian. Ubuntu regularly picks the packages in the Debian rolling > > release as a basis for their own releases, but I'm unaware of their > > schedule. I'd say that March 2018 is the target for the next LTS > > release of Ubuntu. > > > > The problem is that I have personnally I don't have any personal > > interest in netanim myself, and absolutely no time to devote to that > > task. If you can come up with a patch against the packaging scripts > > that refresh it, I can certainly mentor the package upload. > > > > Thanks, Mt. > > > > -- > > It's so easy to laugh, it's so easy to hate, > > it takes strength to be gentle and kind. -- Morrissey, I Know It's Over. > > > > -- > YunQiang Su -- alvin: mais ça, au moins dans ma tête, c'est à peu près clair frs69wq: bah t'enverra ta tête aux relecteurs alors... signature.asc Description: PGP signature
Bug#785565: [Ns-developers] State of ns3 in the Debian distribution
Hello Tom, thanks for your reply. On Wed, Oct 04, 2017 at 06:08:01PM +, Tom Henderson wrote: > Hi Martin, responses inline below. > > On 10/04/2017 05:26 AM, Martin Quinson wrote: > > Hello dear developers, > > > > Also, if you have an easy way to drop these dependencies (by disabling > > them at build time), that could solve the issue on our side. I know I > > should RTFM for that, but I fail to find the time, and I would > > appreciate this help in the package maintainance, please. The current > > build receipe is here (that's a makefile): > > http://sources.debian.net/src/ns3/3.26%2Bdfsg-1/debian/rules/ > There isn't an ns-3 build dependency on netanim. The pyviz visualizer is > automatically left out of the configuration if the prerequisites are not > found by Waf. Is this sufficient (if we don't resolve these package > dependencies in time)? Ok, then I will rebuild the package without that dependency, upload it, and it should do the trick for now, I guess. I'll keep you posted. > We are about to make a new ns-3 release (3.27). We also noticed that the > netanim package in Debian stretch is very old (3.100+ while we are now at > 3.108). Can we work towards replacing the old versions with the new > versions in the current release of Debian, or must we wait until the next > Debian release? There is a plenty of time before the next official Debian release (maybe one year and half). So we can definitely work something out for Debian. Ubuntu regularly picks the packages in the Debian rolling release as a basis for their own releases, but I'm unaware of their schedule. I'd say that March 2018 is the target for the next LTS release of Ubuntu. The problem is that I have personnally I don't have any personal interest in netanim myself, and absolutely no time to devote to that task. If you can come up with a patch against the packaging scripts that refresh it, I can certainly mentor the package upload. Thanks, Mt. -- It's so easy to laugh, it's so easy to hate, it takes strength to be gentle and kind. -- Morrissey, I Know It's Over. signature.asc Description: PGP signature
Bug#785565: State of ns3 in the Debian distribution
Hello dear developers, [I hope that this is the right channel for this. Please be patient if not] I come to you to raise you awareness on the state of NS3 in Debian. It suffers of two bugs concerning the graphical interface(s). One of them is seen "important", meaning that ns3 will not be part of the next Debian release (and it will also be dropped by derivative distributions such as Ubuntu). The problems are described here and here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785565 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875071 In short, the first bug is about the dependency on pygoocanvas, that will soon be removed from Debian. If ns3 keeps depending on it, ns3 will be completely removed also (it is already removed from the "testing" rolling release, and will be completely wipped out if we don't take any action). The second bug is about the same kind of issue with Qt4. But I think we have more time to react (as described in the bug report). So, my question is to know whether you have any plan to replace these dependencies with the modern versions of these functionnality (gir in the case of pygoocanvas IIRC, and Qt5 in the other case). Also, if you have an easy way to drop these dependencies (by disabling them at build time), that could solve the issue on our side. I know I should RTFM for that, but I fail to find the time, and I would appreciate this help in the package maintainance, please. The current build receipe is here (that's a makefile): http://sources.debian.net/src/ns3/3.26%2Bdfsg-1/debian/rules/ If you're interested, the build logs are here: https://buildd.debian.org/status/package.php?p=ns3&suite=sid When answering this email, that'd be great if you could keep the bug reports in CC so that we can keep track of it from the Debian perspective. -- You have a problem and decide to use git. Now you have a forest of subtly incompatible solutions. signature.asc Description: PGP signature
Bug#872881: simgrid: FTBFS: `__atomic_fetch_add_8' undefined
Hello,
thanks for the patch. I came to something very similar, only
protecting it to be used only by GCC. I was waiting to find the time
to test it before upload, but if you tested, I'll upload it right away.
Many thanks,
Mt
On Wed, Aug 23, 2017 at 02:41:15PM +0100, James Cowgill wrote:
> Hi,
>
> The attached patch seems to work (ie replace atomic-library with it).
> Using target_link_libraries should put any linker arguments at the end
> instead of the beginning.
>
> Thanks,
> James
> --- a/tools/cmake/MakeLib.cmake
> +++ b/tools/cmake/MakeLib.cmake
> @@ -114,6 +114,7 @@ if(enable_smpi AND APPLE)
>set(SIMGRID_DEP "${SIMGRID_DEP} -Wl,-U -Wl,_smpi_simulated_main")
> endif()
>
> +set(SIMGRID_DEP "${SIMGRID_DEP} -Wl,--as-needed -latomic -Wl,--no-as-needed")
> target_link_libraries(simgrid${SIMGRID_DEP})
>
> # Dependencies from maintainer mode
--
If the facts don't fit the theory, change the facts.
-- Albert Einstein (?)
signature.asc
Description: PGP signature
Bug#872881: The proposed fix is not enough
reopen 872881 thanks Hello, the "-Wl,--as-needed -latomic" trick was not enough, the bug is not gone. Sorry for not testing it before, I was too confident. I must confess that I have no idea of how to fix this bug, and any help would be welcome. Thanks, Mt. -- Data and source codes are to scientific experimental studies what proofs are to mathematics. They thus need to be reviewed and shared. signature.asc Description: PGP signature
Bug#871357: packaging-tutorial: FTBFS: Unescaped left brace in regex is illegal here in regex; marked by <-- HERE in m/\\end{ <-- HERE document}/ at /usr/share/perl5/Locale/Po4a/TransTractor.pm line 6
On Sun, Aug 13, 2017 at 12:25:54PM -0400, gregor herrmann wrote: > What po4a could maybe do is to mention in the documentation that the > string in "position=something" in addendums will be interpreted as a > Perl regexp later. It's already the case: position (mandatory) a Perl regexp. The addendum will be placed near the line matching this regexp. Note that we're speaking about the translated document here, not the original. If more than a line match this expression (or none), the addition will fail. It is indeed better to report an error than inserting the addendum at the wrong location. (I just added "Perl" in the first sentence, but the doc is otherwise unchanged) If it's not explicit enough, please tell me how I could improve it. Thanks, Mt. -- If Java had true garbage collection, most programs would delete themselves upon execution. -- Robert Sewell signature.asc Description: PGP signature
Bug#871357: packaging-tutorial: FTBFS: Unescaped left brace in regex is illegal here in regex; marked by <-- HERE in m/\\end{ <-- HERE document}/ at /usr/share/perl5/Locale/Po4a/TransTractor.pm line 6
Hello,
Thanks for investigating this bug.
On Tue, Aug 08, 2017 at 04:13:47PM -0400, gregor herrmann wrote:
> Control: tag -1 + patch
>
> On Mon, 07 Aug 2017 11:58:29 -0400, Lucas Nussbaum wrote:
>
> > > Unescaped left brace in regex is illegal here in regex; marked by <--
> > > HERE in m/\\end{ <-- HERE document}/ at
> > > /usr/share/perl5/Locale/Po4a/TransTractor.pm line 643.
> > > debian/rules:13: recipe for target 'override_dh_auto_build' failed
> > > make[1]: *** [override_dh_auto_build] Error 255
>
> That's an interesting bug.
>
> The error is in /usr/share/perl5/Locale/Po4a/TransTractor.pm:643
> which is
> my $found = scalar grep { /$position/ } @{$self->{TT}{doc_out}};
> and $position (comes from addendum_parse() in the same file and)
> contains '\\end{document}' at that point.
>
> And this '\\end{document}' itself comes from files in the
> packaging-tutorial po4a directory.
>
> So I don't know if po4a needs a generic fix, or packaging-tutorial
> needs to change how it uses it.
I would be unable to generate a patch for the first option. My perl is
rather rotten nowadays. I think that the second option is sensible:
packaging-tutorial is providing some code that is interpreted by po4a,
so it should ensure that it provides correct code.
> I'm attaching a patch for the second option.
Many thanks for that. It looks great to me.
Bye, Mt.
--
The most exciting phrase to hear in science, the one that heralds new
discoveries, is not "Eureka!" (I found it!) but "That's funny ..."
--- Isaac Asimov
signature.asc
Description: PGP signature
Bug#826502: quilt: diff for NMU version 0.63-8.1
On Mon, Jul 17, 2017 at 08:47:02PM +0200, gregor herrmann wrote: > Control: tags 826502 + pending > > Dear maintainer, > > I've prepared an NMU for quilt (versioned as 0.63-8.1) and > uploaded it to DELAYED/5. Please feel free to tell me if I > should delay it longer. Hello, many thanks for this change, and for the upload. As usual, I'm struggling with the maintainance of quilt. Any help is welcome, so please do not delay your upload. If you want to fix other stuff while you are at it (or even package the newer upstream releases), please do not hesitate and help me... Thanks again, Mt. signature.asc Description: PGP signature
Bug#858934: apt FTBFS with po4a 0.50-1
On Tue, Mar 28, 2017 at 11:09:14PM +0200, David Kalnischkies wrote: > > The full command is: > > cd /path/to/apt/build/doc && po4a --previous --no-backups > --package-name='apt-doc' --package-version='1.4~rc2' > --msgid-bugs-address='APT\ Development\ Team\ ' > --translate-only de/guide.de.dbk --srcdir /path/to/apt/doc --destdir > /path/to/apt/build/doc /path/to/apt/doc/po4a.conf > > As you can see we switch into a build directory and instruct po4a to > pick up all files it needs with --srcdir from the source. That used to > work, but it seems to no longer work in the new version – I can fix the > build with a simple symlink: > > ln -s /path/to/apt/doc/po /path/to/apt/build/doc/po > > As I don't see what the apt buildsystem could be doing wrong in po4a > call and because it worked before I am reassign to po4a to fix that > regression – especially as we are in freeze. > > If there is something wrong with the call on the other hand it would be > nice if we could get some details on what to do instead and how to > achieve compatibility with "old" and "new" po4a. The error is definitly on my side. I added something to fail on broken po files, but I forgot to deal with the srcdir command line option. Now, my fix in 0.51 is suboptimal because files loaded through --srcdir will not be checked for validity. I was too much in a hurry to fix that FTBFS that my stupidity created... I think it can remain this way until after the end of the freeze. > Thanks Martin for picking up po4a development btw even if the timing is > a bit unfortunate for (accidental?) uploads to unstable… Yeah, well, I'm really stupid on this one. I was thinking that po4a is a small little package laying at the border of the Debian galaxy, and that since a RC bug against the version in testing was really improbable after all that time, I could use the slot in unstable with no bad impact on the freeze process. I did not think that po4a is a build-dep of many packages and could thus prevent them from reentering testing to fix RC bugs there. I feel stupid now :) Bye, Mt. -- You have a problem and decide to use threads. have randomNow problems. you signature.asc Description: PGP signature
Bug#858934: apt FTBFS with po4a 0.50-1
Hello, I'm the maintainer of po4a. Indeed, it seems that my fix to #855431 was not really appropriate. I will upload a new po4a within the hour to not break if the po file does not exist. Sorry, Mt. On Tue, Mar 28, 2017 at 10:05:52PM +0200, Helmut Grohne wrote: > Source: apt > Version: 1.4~rc2 > Severity: serious > User: helm...@debian.org > Usertags: rebootstrap > > Since today apt fails to build from source in unstable on amd64. The > typical failure looks like: > > | cd "/<>/obj-x86_64-linux-gnu/doc" && po4a --previous > --no-backups --package-name='apt-doc' --package-version='1.4~rc2' > --msgid-bugs-address='APT\ Development\ Team\ | Invalid po file po/es.po: > | msgfmt: error while opening "po/es.po" for reading: No such file or > directory > | > | doc/CMakeFiles/apt-man.dir/build.make:916: recipe for target > 'doc/es/apt.es.8.po4a-stamp' failed > | make[4]: *** [doc/es/apt.es.8.po4a-stamp] Error 1 > > It seems very likely that this FTBFS is a result of the po4a 0.50-1 > upload, at least the timing matches precisely. Uploader Cced. I didn't > look any further, please reassign as appropriate. > > Helmut -- Moi, Adam et Ève, j'y crois plus tu vois, parce que je suis pas un idiot : la pomme, ça peut pas être mauvais, c'est plein de pectine... -- Jean Claude Van Damme signature.asc Description: PGP signature
Bug#847283: quilt-el: copyright file missing after upgrade (policy 12.5)
On Wed, Dec 21, 2016 at 02:12:32AM +0100, Andreas Beckmann wrote: > On 2016-12-21 01:58, Martin Quinson wrote: > > Hello, > > > > I think I fixed this with a maintscript, but this is the first time I > > do so. I'd feel better if you could double-check that I did it right, > > eg by rerunning the script, please. > > looking at the commit, that doesn't work on upgrades from testing > (work as in "clean up the mess the previous version forgot") > > The canonical version when introducing a .maintscript is > $current_version plus "~", so in your case 0.63-6~ > meaning: "on upgrades from any version older than 0.63-6~ we do that > action" But since there is a tag you probably uploaded it already, so > you would fix that by bumping the version to 0.63-7~ in the next release. Gosh. In the meanwhile, I discovered that I previously forgot an easy patch in the BTS and uploaded a 0.63-7 version... Well, 0.63-8 is on its way to unstable. I wanted to be quick, but you hardly do a good job in a rush... Thanks for your help, Mt. -- Nos péchés sont têtus, nos repentirs sont lâches --- Ch.Baudelaire, Les fleurs du mal signature.asc Description: PGP signature
Bug#847283: quilt-el: copyright file missing after upgrade (policy 12.5)
Hello,
I think I fixed this with a maintscript, but this is the first time I
do so. I'd feel better if you could double-check that I did it right,
eg by rerunning the script, please.
Thanks for your work,
Mt.
On Tue, Dec 06, 2016 at 11:33:34PM +0100, Andreas Beckmann wrote:
> Package: quilt-el
> Version: 0.63-5
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
>
> Hi,
>
> a test with piuparts revealed that your package misses the copyright
> file after an upgrade, which is a violation of Policy 12.5:
> https://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile
>
> After the upgrade /usr/share/doc/$PACKAGE/ is just an empty directory.
>
> This was observed on the following upgrade paths:
>
> wheezy -> jessie (no package in jessie, keeping wheezy version
> installed) -> stretch
>
> >From the attached log (scroll to the bottom...):
>
> 3m38.6s ERROR: WARN: Inadequate results from running adequate!
> quilt-el: missing-copyright-file /usr/share/doc/quilt-el/copyright
>
> 3m43.4s DUMP:
> MISSING COPYRIGHT FILE: /usr/share/doc/quilt-el/copyright
> # ls -lad /usr/share/doc/quilt-el
> drwxr-xr-x 2 root root 40 Sep 15 10:31 /usr/share/doc/quilt-el
> # ls -la /usr/share/doc/quilt-el/
> total 0
> drwxr-xr-x 2 root root 40 Sep 15 10:31 .
> drwxr-xr-x 294 root root 6060 Sep 15 10:31 ..
>
>
> Additional info may be available here:
> https://wiki.debian.org/MissingCopyrightFile
>
> Note that dpkg intentionally does not replace directories with symlinks
> and vice versa, you need the maintainer scripts to do this.
> See in particular the end of point 4 in
> https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-unpackphase
>
> It is recommended to use the dpkg-maintscript-helper commands
> 'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14)
> to perform the conversion, ideally using d/$PACKAGE.maintscript.
> Do not forget to add 'Pre-Depends: ${misc:Pre-Depends}' in d/control.
> See dpkg-maintscript-helper(1) and dh_installdeb(1) for details.
>
>
> cheers,
>
> Andreas
--
You have a problem and decide to use floats.
Now you have 2.0001 problems.
signature.asc
Description: PGP signature
Bug#847283: marked as pending
tag 847283 pending thanks Hello, Bug #847283 reported by you has been fixed in the Git repository. You can see the changelog below, and you can check the diff of the fix at: http://git.debian.org/?p=collab-maint/quilt.git;a=commitdiff;h=66be989 --- commit 66be989db992dc9dffc132d1e7c84c1b9cb35a14 Author: Martin Quinson Date: Wed Dec 21 01:31:41 2016 +0100 fix the transition of quilt-el from wheezy diff --git a/debian/changelog b/debian/changelog index 6892e05..cf77f69 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +quilt (0.63-6) unstable; urgency=medium + + * Fix the transition from wheezy version of quilt-el: +Add a dir_to_symlink maintscript (Closes: #847283). + + -- Martin Quinson Wed, 21 Dec 2016 01:31:13 +0100 + quilt (0.63-5) unstable; urgency=medium * Fix the emacs autoload file (Closes: #837125).
Bug#847283: marked as pending
tag 847283 pending thanks Hello, Bug #847283 reported by you has been fixed in the Git repository. You can see the changelog below, and you can check the diff of the fix at: http://git.debian.org/?p=collab-maint/quilt.git;a=commitdiff;h=66be989 --- commit 66be989db992dc9dffc132d1e7c84c1b9cb35a14 Author: Martin Quinson Date: Wed Dec 21 01:31:41 2016 +0100 fix the transition of quilt-el from wheezy diff --git a/debian/changelog b/debian/changelog index 6892e05..cf77f69 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +quilt (0.63-6) unstable; urgency=medium + + * Fix the transition from wheezy version of quilt-el: +Add a dir_to_symlink maintscript (Closes: #847283). + + -- Martin Quinson Wed, 21 Dec 2016 01:31:13 +0100 + quilt (0.63-5) unstable; urgency=medium * Fix the emacs autoload file (Closes: #837125).
Bug#725768: And now with the patch, sorry
Index: j/tkcvs-8.2.3/debian/control
===
--- j.orig/tkcvs-8.2.3/debian/control
+++ j/tkcvs-8.2.3/debian/control
@@ -8,7 +8,7 @@ Build-Depends: debhelper (>= 7.0.0)
Package: tkcvs
Architecture: all
-Depends: cvs | subversion, tk8.4 | tk8.5, ttf-dejavu, ${misc:Depends}
+Depends: cvs | subversion, tk (>=8.4), ttf-dejavu, ${misc:Depends}
Replaces: tkdiff
Provides: tkdiff
Recommends: xterm | x-terminal-emulator, dirdiff
Index: j/tkcvs-8.2.3/debian/control
===
--- j.orig/tkcvs-8.2.3/debian/control
+++ j/tkcvs-8.2.3/debian/control
@@ -8,7 +8,7 @@ Build-Depends: debhelper (>= 7.0.0)
Package: tkcvs
Architecture: all
-Depends: cvs | subversion, tk8.4 | tk8.5, ttf-dejavu, ${misc:Depends}
+Depends: cvs | subversion, tk (>=8.4), ttf-dejavu, ${misc:Depends}
Replaces: tkdiff
Provides: tkdiff
Recommends: xterm | x-terminal-emulator, dirdiff
signature.asc
Description: PGP signature
Bug#725768: Here is a working patch, provided by Teppo Mäenpää
tag 725768 patch thanks Hello, attached is a trival patch (provided by Teppo Mäenpää). I just tested, and it works rather well: the package builds and installs like a charm with this change. Once installed, tkdiff seems to work (at least, it starts). Tim, could you please take care of this grave bug so that your package could reintegrate testing? If not, could someone NMU this package, please? Thanks in advance, Mt. -- There are only two kinds of programming languages: those people always bitch about and those nobody uses. -- Bjarne Stroustrup. signature.asc Description: PGP signature
Bug#836510: marked as pending
tag 836510 pending thanks Hello, Bug #836510 reported by you has been fixed in the Git repository. You can see the changelog below, and you can check the diff of the fix at: http://git.debian.org/?p=collab-maint/quilt.git;a=commitdiff;h=819ca9e --- commit 819ca9ef9c890e47741bacb034643be25786b265 Author: Martin Quinson Date: Sun Sep 4 13:50:43 2016 +0200 don't test failure of diff with binary files, as it does not fail anymore diff --git a/debian/changelog b/debian/changelog index b678439..609ae61 100644 --- a/debian/changelog +++ b/debian/changelog @@ -7,7 +7,9 @@ quilt (0.63-4) unstable; urgency=medium Thanks to Jeremy Sowden for the patch. * d/control: use non-obsolete values for Vcs-git field. * d/p/fixbuildrun: fix some annoying warnings in test/run - * Use dh_bash-completion to do the Right Thing. + * d/p/diff_binary: don't test failure with binary files, as it does +not fail anymore with modern diffs (Closes: #836510). + * Use dh_bash-completion to do the Right Thing. [ Raphaël Hertzog ] * Drop myself from Uploaders.
Bug#833775: Working on this
Hello, It seems that the problem is gcc6, not boost1.61 but that's not a big deal. I'm working on this and should be able to produce a patch very soon. Bye, Mt. -- Arguing with an engineer is a lot like wrestling in the mud with a pig. After a couple of hours, you realize the pig likes it. signature.asc Description: PGP signature
Bug#827349: viva: FTBFS: Parse error at "BOOST_JOIN"
Hello,
I applied both patches to paje and re-uploaded, but it is not
sufficient. I now get "PajeThreadReader.h: No such file or directory"
when compiling viva. I tried the latest upstream release, but it does
not help, so I filled https://github.com/schnorr/viva/issues/10
If you have an idea, please speak up because I don't :(
Mt
On Tue, Aug 02, 2016 at 09:25:13AM +, Radovan Birdic wrote:
> Bug #794704 was fixed with no-boost-moc-ftbfs patch in the older version,
> which wrapping
> boost includes in #ifndef Q_MOC_RUN ... #endif
>
> Applying no-boost-moc-ftbfs patch solves "BOOST_JOIN" error but new issue
> appear:
>
> > error: no matching function for call to
> > 'PajeSimulator::PajeSimulator(double&, int&)'
>
> This issue occurs because constructor "PajeSimulator(double&, int&)" was
> removed in the new version of pajeng package.
> On upstream, this constructor was returned:
> https://github.com/schnorr/pajeng/commit/827c3826eb12cebc7b4f7569be8aebff7a7a8796
>
> Patch put-back-PajeSimulator-constructor.patch includes these changes.
>
> Using pajeng that includes mentioned patches I was able to build viva package
> successfully on mips* and amd64.
>
> Regards,
> Radovan
> commit 827c3826eb12cebc7b4f7569be8aebff7a7a8796
> Author: Lucas Mello Schnorr
> Date: Thu Jul 7 05:32:26 2016 -0300
>
> put back this constructor since viva relies on it
>
> diff --git a/src/libpaje/PajeSimulator.cc b/src/libpaje/PajeSimulator.cc
> index 7f0182d..100ca70 100644
> --- a/src/libpaje/PajeSimulator.cc
> +++ b/src/libpaje/PajeSimulator.cc
> @@ -33,6 +33,13 @@ PajeSimulator::PajeSimulator (double stopat)
>init ();
> }
>
> +PajeSimulator::PajeSimulator (double stopat, int ignore)
> +{
> + stopSimulationAtTime = stopat;
> + ignoreIncompleteLinks = ignore;
> + init ();
> +}
> +
> PajeSimulator::PajeSimulator (double stopat, int ignore, bool noImbrication)
> {
>stopSimulationAtTime = stopat;
> diff --git a/src/libpaje/PajeSimulator.h b/src/libpaje/PajeSimulator.h
> index b806d8b..bb13c8c 100644
> --- a/src/libpaje/PajeSimulator.h
> +++ b/src/libpaje/PajeSimulator.h
> @@ -62,6 +62,7 @@ protected:
> public:
>PajeSimulator();
>PajeSimulator(double stopat);
> + PajeSimulator(double stopat, int ignoreIncompleteLinks);
>PajeSimulator(double stopat, int ignoreIncompleteLinks, bool
> noImbrication);
>~PajeSimulator();
>void report (void);
--
Le sens commun n'est pas si commun (Common sense is not so common).
-- Voltaire
signature.asc
Description: PGP signature
Bug#827349: The problem is in pajeng actually
reassign 827349 pajeng thanks The file to patch is actually in pajeng, even if the breakage is in viva. Thus reassigning. Thanks, Mt. -- La théorie, c'est quand on sait tout et que rien ne fonctionne. La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi. -- Albert Einstein (?) signature.asc Description: PGP signature
Bug#827349: Thanks for reporting
This bug is "very similar" to #794704, that was reported and fixed a year ago. This calls for more investigations, but I just wanted to point that fact out. Bye, Mt. -- For every complex problem there is a solution which is simple, neat and wrong. signature.asc Description: PGP signature
Bug#821369: my bad
Hello, I'm sorry, I didn't notice the netanim package. I will stop building it from the ns3 source package. Sorry, Mt. -- If it isn't straightforward to modify it, it will never be any good. It will never be fast, it will never be correct. And it will eventually be replaced by something modifiable. -- Paul Phillips signature.asc Description: PGP signature
Bug#814272: simgrid: FTBFS: Could not figure the stack direction.
Hello, On Tue, Feb 09, 2016 at 03:09:09PM -0500, Aaron M. Ucko wrote: > > Automated builds of simgrid generally failed: Yes, that hurts. It's all red! pitty. > ERRORCould not figure the stack direction. > -- LTO seems usable. > -- Add CFLAGS: "-g -O2 -fstack-protector-strong -Wformat > -Werror=format-security -O3" to CMAKE_C_FLAGS > [...] > /«PKGBUILDDIR»/src/simix/smx_context.c:142:16: error: 'PTH_STACKGROWTH' > undeclared (first use in this function) > > It's not entirely clear from the public logs what went wrong, but I > suspect CMake may have tried to build prog_stackgrowth.c with -O3, > which turns on -finline-functions, breaking the test. Parallel building does not help here, for sure. And the diagnosis further is complicated by the fact that my cmake output was broken when the stack direction detection fails (I'm in the upstream team). I just commited a fix for that message, so that we get more info. That is why the build starts even after the line "ERRORCould not figure the stack direction", sorry. Your analysis would be correct: these flags clearly break the stack test. That is why they get added at the end of the configuration, once all tests are ran. So, this is not it. > The fallback > logic didn't help even on the limited set of processor types it tried > to cover because CMAKE_SYSTEM_PROCESSOR corresponds to the output of > uname -p (typically "unknown" on Debian) rather than uname -m. I would say that the fallback works, as it managed to compile on i386 ;) But this is not an option, I'll investiguate further. Right now, I forgot my laptop adapter at lab, and I will soon be offline... If you want to give it a spin, the modified version is in the package git. > Could you please take a look? Many thanks to you for investigating so far. Bye, Mt. -- It is not in improving the candle technology that electricty was discovered, understood and mastered. signature.asc Description: PGP signature
Bug#805409: scala: FTBFS without network connexion
Package: scala Version: 2.11.7 Severity: serious Justification: FTBFS Hello, it seems that the patch to stop maven from downloading some stuff from the internet is not effective because the package still fails to build from source when I unplug the net. The very bad news is that from what I understand from the logs, it tries to download scala itself to build scala: | [artifact:dependencies] Downloading: org/scala-lang/scala-compiler/2.11.x /scala-compiler-2.11.x.pom from repository central at file:///usr/share/maven-repo I fear a bootstraping issue here, not sure. Thanks for packaging scala, that's very pleasant to have it easily installed. Mt -- System Information: Debian Release: stretch/sid Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages scala depends on: ii default-jre-headless [java6-runtime-headless]2:1.7-52 ii openjdk-7-jre-headless [java6-runtime-headless] 7u75-2.5.4-2 ii openjdk-8-jre-headless [java6-runtime-headless] 8u66-b01-1 scala recommends no packages. scala suggests no packages. -- no debconf information -- La drogue était un milieu plutôt sain avant que le sport ne s'en mêle. Script started on Tue Nov 17 13:37:43 2015 dpkg-buildpackage: source package scala dpkg-buildpackage: source version 2.11.6-1 dpkg-buildpackage: source distribution unstable dpkg-buildpackage: source changed by Emmanuel Bourg dpkg-buildpackage: host architecture amd64 dpkg-source --before-build scala-2.11.6 fakeroot debian/rules clean dh clean --with javahelper --with maven_repo_helper dh_testdir debian/rules override_dh_auto_clean make[1]: Entering directory '/tmp/scala-2.11.6' rm -rf build dists buildcharacter.properties debian/poms/*.pom.xml make[1]: Leaving directory '/tmp/scala-2.11.6' jh_clean mh_clean dh_clean dpkg-source -b scala-2.11.6 dpkg-source: info: using source format '3.0 (quilt)' dpkg-source: info: building scala using existing ./scala_2.11.6.orig.tar.xz dpkg-source: info: building scala in scala_2.11.6-1.debian.tar.xz dpkg-source: info: building scala in scala_2.11.6-1.dsc debian/rules build dh build --with javahelper --with maven_repo_helper dh_testdir dh_auto_configure jh_linkjars debian/rules override_dh_auto_build make[1]: Entering directory '/tmp/scala-2.11.6' # Build Scala ANT_OPTS="-Xmx1024M -Xss64M" \ ant -Dversion.number="2.11.6" \ -Djunit.version=4.x \ -Dextra.repo.url=file:///usr/share/maven-repo \ -Djline.version=2.x \ -Dstarr.version=2.11.x \ fastdist-opt docs Buildfile: /tmp/scala-2.11.6/build.xml fastdist-opt: init.git: init: [copy] Copying 2 files to /tmp/scala-2.11.6/build/deps/junit [artifact:dependencies] There were no dependencies specified [artifact:dependencies] There were no dependencies specified [artifact:dependencies] There were no dependencies specified [artifact:dependencies] There were no dependencies specified [artifact:dependencies] There were no dependencies specified [copy] Copying 4 files to /tmp/scala-2.11.6/build/deps/repl [artifact:dependencies] Downloading: org/scala-lang/modules/scala-xml_2.11/1.0.3/scala-xml_2.11-1.0.3-sources.jar from repository central at file:///usr/share/maven-repo [artifact:dependencies] File: /usr/share/maven-repo/org/scala-lang/modules/scala-xml_2.11/1.0.3/scala-xml_2.11-1.0.3-sources.jar does not exist [artifact:dependencies] [INFO] Unable to find resource 'org.scala-lang.modules:scala-xml_2.11:java-source:sources:1.0.3' in repository central (file:///usr/share/maven-repo) [artifact:dependencies] Downloading: org/scala-lang/modules/scala-xml_2.11/1.0.3/scala-xml_2.11-1.0.3-javadoc.jar from repository central at file:///usr/share/maven-repo [artifact:dependencies] File: /usr/share/maven-repo/org/scala-lang/modules/scala-xml_2.11/1.0.3/scala-xml_2.11-1.0.3-javadoc.jar does not exist [artifact:dependencies] [INFO] Unable to find resource 'org.scala-lang.modules:scala-xml_2.11:java-source:javadoc:1.0.3' in repository central (file:///usr/share/maven-repo) [artifact:dependencies] Downloading: org/scala-lang/scala-library/2.11.x/scala-library-2.11.x-sources.jar from repository central at file:///usr/share/maven-repo [artifact:dependencies] File: /usr/share/maven-repo/org/scala-lang/scala-library/2.11.x/scala-library-2.11.x-sources.jar does not exist [artifact:dependencies] [INFO] Unable to find resource 'org.scala-lang:scala-library:java-source:sources:2.11.x' in repository central (file:///usr/share/maven-repo) [artifact:dependencies] Downloading: org/scala-lang/scala-library/2.11.x/scala-library-2.11.x-javadoc.jar from repository central at file:///usr/share/maven-repo [artifact:dependencies] File: /usr/share/maven-repo/org/scala-lang/scala-library/2.11.x/scala-library-2.11.x-javadoc.jar does not exist [artifact:depen
Bug#794704: viva: FTBFS
control: tags -1 help
On Thu, Aug 06, 2015 at 10:48:12PM +0200, Martin Quinson wrote:
> On Thu, Aug 06, 2015 at 12:38:41PM +0200, Tobias Frost wrote:
> >
> > Hi Martin,
> >
> > Thanks for the reply!
> > can you check if the workaround would solve this; Maybe a quick fix would
> > help to get the libconfig transition forward faster, as a new upstream
> > version takes lots more time...
> >
>
> I will need to wait for tomorrow night as I have no good connexion
> here. I'm not even sure of when this mail will get out of my box :(
Ok, I'm back to the civilization, and I now have a decent connexion. I
did as you adviced, trying to first fix the FTBFS and then package the
next version, but I didn't manage to do so.
I tried to abuse the include system as described in
https://bugs.debian.org/653796
ie, with
QT4_WRAP_CPP(sources ${moc-sources} OPTIONS
-DBOOST_TT_HAS_OPERATOR_HPP_INCLUDED)
but it didn't work for me.
I tried to include boost headers only if MOC is not in use, as with
attached patch1, but it did not work.
I tried to define BOOST_TT_HAS_OPERATOR_HPP_INCLUDED if MOC is in use,
as with attached patch2, but it did not work either.
http://anonscm.debian.org/cgit/pkg-kde/kde-extras/qt-gstreamer.git/commit/?id=4116865bd6f36870b6cab16119a5c52c8d1ee796
I must be stupid since these fixes did work in other projects so I
must do something wrong, but I fail to see what. I'm now clueless, and
any help (or even better, patch) would be welcome :-(
Taging the bug as such.
Sorry, Mt.
--
A few hours at the desk can very easily be replaced by a few months in
the lab.-- old engineers saying
Fix a FTBFS due to the bad interaction of Qt4 and boost 1.48 and higher.
The MOC source parser have only a partial support of the C++ standard,
and boost is using the full potential of that standard, so don't load
the boost headers when MOC is parsing the source.
See https://bugreports.qt.io/browse/QTBUG-22829 for more details on
this crude hack.
---
src/utils/QPajeTypeFilter.cc |3 +++
src/vv_treemap/PajeTreemap.cc |2 ++
3 files changed, 11 insertions(+), 3 deletions(-)
Index: b/src/utils/QPajeTypeFilter.cc
===
--- a/src/utils/QPajeTypeFilter.cc
+++ b/src/utils/QPajeTypeFilter.cc
@@ -17,7 +17,10 @@
#include "QPajeTypeFilter.h"
#include
#include
+
+#ifndef Q_MOC_RUN /* MOC can choke on some boost headers */
#include
+#endif
QPajeTypeFilter::QPajeTypeFilter (QWidget *parent)
{
Index: b/src/vv_treemap/PajeTreemap.cc
===
--- a/src/vv_treemap/PajeTreemap.cc
+++ b/src/vv_treemap/PajeTreemap.cc
@@ -15,7 +15,9 @@
along with PajeNG. If not, see <http://www.gnu.org/licenses/>.
*/
#include "PajeTreemap.h"
+#ifndef Q_MOC_RUN /* MOC can choke on some boost headers */
#include
+#endif
#include
PajeTreemap::PajeTreemap (PajeTreemap *parent, PajeComponent *filter,
PajeContainer *container)
Fix a FTBFS due to the bad interaction of Qt4 and boost 1.48 and higher.
The MOC source parser have only a partial support of the C++ standard,
and boost is using the full potential of that standard, so don't load
the boost headers when MOC is parsing the source.
See https://bugreports.qt.io/browse/QTBUG-22829 for more details on
this crude hack.
---
src/utils/QPajeTypeFilter.cc |4
src/vv_treemap/PajeTreemap.cc |4
2 files changed, 8 insertions(+)
Index: b/src/utils/QPajeTypeFilter.cc
===
--- a/src/utils/QPajeTypeFilter.cc
+++ b/src/utils/QPajeTypeFilter.cc
@@ -14,6 +14,10 @@
You should have received a copy of the GNU Public License
along with Viva. If not, see <http://www.gnu.org/licenses/>.
*/
+#ifndef Q_MOC_RUN /* MOC can choke on some boost headers */
+#define BOOST_TT_HAS_OPERATOR_HPP_INCLUDED /* So abuse header inclusion
protection to prevent Moc from including Boost internals */
+#endif
+
#include "QPajeTypeFilter.h"
#include
#include
Index: b/src/vv_treemap/PajeTreemap.cc
===
--- a/src/vv_treemap/PajeTreemap.cc
+++ b/src/vv_treemap/PajeTreemap.cc
@@ -14,6 +14,10 @@
You should have received a copy of the GNU Public License
along with PajeNG. If not, see <http://www.gnu.org/licenses/>.
*/
+#ifndef Q_MOC_RUN /* MOC can choke on some boost headers */
+#define BOOST_TT_HAS_OPERATOR_HPP_INCLUDED /* So abuse header inclusion
protection to prevent Moc from including Boost internals */
+#endif
+
#include "PajeTreemap.h"
#include
#include
signature.asc
Description: Digital signature
Bug#794704: viva: FTBFS
On Thu, Aug 06, 2015 at 12:38:41PM +0200, Tobias Frost wrote: > > Hi Martin, > > Thanks for the reply! > can you check if the workaround would solve this; Maybe a quick fix would > help to get the libconfig transition forward faster, as a new upstream > version takes lots more time... > I will need to wait for tomorrow night as I have no good connexion here. I'm not even sure of when this mail will get out of my box :( Sorry, Mt -- You have a problem and decide to use floats. Now you have 2.0001 problems. -- Old Computer Engineers saying signature.asc Description: Digital signature
Bug#794704: viva: FTBFS
Hello, I'm in the process of packaging the new upstream release to see if it helps. Thanks for the report and the workaround. Bye, Mt. On Thu, Aug 06, 2015 at 02:02:40AM +0200, Sebastian Ramacher wrote: > On 2015-08-05 22:35:20, Tobias Frost wrote: > > [ 1%] Generating src/utils/moc_QPajeTypeFilter.cxx > > cd > > /home/tobi/libconfig-rebuild/viva-1.0+git20140604.271f86fa51/obj-x86_64-linux-gnu/src/utils > > && /usr/lib/x86_64-linux-gnu/qt4/bin/moc > > @/home/tobi/libconfig-rebuild/viva-1.0+git20140604.271f86fa51/obj-x86_64-linux-gnu/src/utils/moc_QPajeTypeFilter.cxx_parameters > > usr/include/boost/type_traits/detail/has_binary_operator.hp:50: Parse error > > at "BOOST_JOIN" > > See [1] for a workaround. > > Cheers > > [1] > https://bugreports.qt.io/browse/QTBUG-22829?focusedCommentId=274496&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-274496 > -- > Sebastian Ramacher -- Pour être heureux, il faut penser au bonheur d'un autre. -- Gaston Bachelard (La Psychanalyse du feu, 1949) signature.asc Description: Digital signature
Bug#733974: Bug#769965: minetest: please support init.d scripts and a global configuration file
On Tue, Nov 18, 2014 at 11:16:51PM +0100, Markus Koschany wrote: > > I agree that https://bugs.debian.org/733974 is a problem that should be > fixed for Jessie. I suggest we wait a few more days until Friday and > give the maintainer a chance to respond to the bug report. However the > package looks rather neglected to me hence I would like to suggest that > you just grab my attached debdiff from #733974 and NMU the package. I'm > confident that the changes qualify for an unblock by the release team. I > hope your last upload to unstable didn't introduce to many changes then > I think we can get both, the Hurd FTBFS fix and the libjsoncpp fix, past > the release team. I just uploaded the fixed package for libjsoncpp. Thanks for preparing the debdiff, I always feel unconfident to work with packages that are neither in a git not a svn. I confirmed that this is enough to fix the problem in minetest. We just need to get the new libjsoncpp in Jessie, the current minetest can stay. If you quickly know how to request that unblock, I'd be really grateful if you could do so, please. > I think we should get in contact with Dominik George who already > packaged some Minetest mods in the past. Perhaps he might be interested > to package one of the other popular mods from this list > > http://minetest.net/mods > > He probably just needs a sponsor. Michael Dorrington also advertised his > interest in packaging some Minetest mods on the mailing list not very > long ago. I'm ok with helping if I'm contacted, but I wont seek for more work myself ;) [...] > I intend to finish the systemd integration until Friday. I think we > could try to achieve something similar like Fedora and use instantiated > services, so that you could run multiple Minetest servers at the same time. > > http://pkgs.fedoraproject.org/cgit/minetest.git/tree/minetest@.service > > I will also add logrotate support to the server package, so that all log > files are rotated on a regular basis. That'd be perfect, indeed. The last issue that naggles me about minetest is whether we should switch to freeminer at some point. The upstream community have forked, and I cannot decide which version is the best one. We should maybe package both, but that also seem to unnecessary burden the Debian archive. There too, your advice would be very welcome. Thanks for your time, Mt. -- Technique sans politique n'est que renforcement des nuisants. -- Rabelais (traduction en français moderne). signature.asc Description: Digital signature
Bug#768732: plm: FTBFS in jessie: src/plm/core/model/Game.java:97: error: unmappable character for encoding ASCII
On Wed, Nov 12, 2014 at 03:35:50PM +0100, Lucas Nussbaum wrote: > > couldn't you build with javac -encoding "UTF-8"? > See > http://stackoverflow.com/questions/1726174/how-to-compile-a-java-source-file-which-is-encoded-as-utf-8 Thanks for the hint. I would have expected jh_build to do the right thing for me, but apparently it is not the case. I just asked jh_build to pass that flags to javac, and it seems all good now. > Regarding the msggrep warnings, I'm not sure if they are really > harmless. Thinking again, that should be harmless. I cannot see any after rebuilding the package in a chroot similar to yours. Many thanks for your assistance, and sorry, I'm really fuzzy in my head these days. The fixed package was just uploaded. Bye, Mt. -- Les chats, c'est vraiment des branleurs. -- Alain Chabat signature.asc Description: Digital signature
Bug#768732: plm: FTBFS in jessie: src/plm/core/model/Game.java:97: error: unmappable character for encoding ASCII
retitle 768732 plm: FTBFS in non-UTF-8 settings thanks Hello, thanks for this additional information, that's indeed the source of the problem. The PLM package builds correctly if I set LC_ALL=C.UTF-8 in addition to your settings and fails without it. But, it seems to me that the package built with non-utf locale settings will not be functionnal for non-english speakers. At least that's what I understand from the msggrep warnings. Could you please point me to the part of the policy that is relevant to the locale settings of the builder? I fail to find anything relevant by myself, sorry. In the meanwhile, I will patch most of the java files to not use the UTF encoding. I'm just reluctant do so in some cases where it would not be an improvement. For example, it would request to write the name of "Gérald Oster" as "Gerald Oster". Not a big deal, but not nice. I guess that it would not be ok to set LC_ALL=C.UTF-8 in the rules file, right? Thanks for your patience and sorry for the complications, Mt. On Wed, Nov 12, 2014 at 01:34:04PM +0100, Lucas Nussbaum wrote: > Hi, > > On 12/11/14 at 11:27 +0100, Martin Quinson wrote: > > Hello, > > > > I must confess that I fail to reproduce your bug. > > > > it seems to me that the bug comes from a strange setting in LC_ALL. > > # locale > LANG= > LANGUAGE= > LC_CTYPE="POSIX" > LC_NUMERIC="POSIX" > LC_TIME="POSIX" > LC_COLLATE="POSIX" > LC_MONETARY="POSIX" > LC_MESSAGES="POSIX" > LC_PAPER="POSIX" > LC_NAME="POSIX" > LC_ADDRESS="POSIX" > LC_TELEPHONE="POSIX" > LC_MEASUREMENT="POSIX" > LC_IDENTIFICATION="POSIX" > LC_ALL= > > > before the java compiler, msggrep complains that ANSI_X3.4-1968 is not > > a valid value for UTF-encoded files. > > > > Did your chroot have any unconventional settings with that regard? > > No. Also, I did not notice any other locale-related failure while filing bugs. > > Lucas -- HARDWARE n.m.: partie de l'ordinateur qui reçoit les coups quand le software se plante. signature.asc Description: Digital signature
Bug#768732: plm: FTBFS in jessie: src/plm/core/model/Game.java:97: error: unmappable character for encoding ASCII
rep',
> > [exec] then convert back to UTF-8 using 'msgconv'.
> > [exec] msggrep: warning: Locale charset "ANSI_X3.4-1968" is different
> > from
> > [exec] input file charset "UTF-8".
> > [exec] msggrep: warning: Locale charset "ANSI_X3.4-1968" is different
> > from
> > [exec] input file charset "UTF-8".
> > [exec] Output of 'msggrep' might be incorrect.
> > [exec] Possible workarounds are:
> > [exec] Output of 'msggrep' might be incorrect.
> > [exec] Possible workarounds are:
> > [exec] - Set LC_ALL to a locale with encoding UTF-8.
> > [exec] - Convert the translation catalog to ASCII
> > using 'msgconv',
> > [exec] - Set LC_ALL to a locale with encoding UTF-8.
> > [exec] - Convert the translation catalog to ASCII
> > using 'msgconv',
> > [exec] then apply 'msggrep',
> > [exec] then convert back to UTF-8 using 'msgconv'.
> > [exec] then apply 'msggrep',
> > [exec] then convert back to UTF-8 using 'msgconv'.
> >
> > i18n-generate-jar:
> > [mkdir] Created dir: /«BUILDDIR»/plm-2.4.11+repack/site/po
> > [gettext-dist] Processing en.po
> > [gettext-dist] msgfmt --java2 -d ./site/po -r org.plm.i18n.Messages -l en
> > /«BUILDDIR»/plm-2.4.11+repack/l10n/engine/en.po
> > [gettext-dist] Processing fr.po
> > [gettext-dist] msgfmt --java2 -d ./site/po -r org.plm.i18n.Messages -l fr
> > /«BUILDDIR»/plm-2.4.11+repack/l10n/engine/fr.po
> > [gettext-dist] Processing it.po
> > [gettext-dist] msgfmt --java2 -d ./site/po -r org.plm.i18n.Messages -l it
> > /«BUILDDIR»/plm-2.4.11+repack/l10n/engine/it.po
> > [gettext-dist] Processing pt_BR.po
> > [gettext-dist] msgfmt --java2 -d ./site/po -r org.plm.i18n.Messages -l
> > pt_BR /«BUILDDIR»/plm-2.4.11+repack/l10n/engine/pt_BR.po
> > [jar] Building jar: /«BUILDDIR»/plm-2.4.11+repack/lib/plm-messages.jar
> >[delete] Deleting directory /«BUILDDIR»/plm-2.4.11+repack/site/po
> >
> > BUILD SUCCESSFUL
> > Total time: 12 seconds
> > cd debian/_jh_build.plm && jar xf ../../lib/plm-messages.jar org
> > # Finally, ask the scripts to compile our stuff, too
> > jh_build --no-javadoc --javacopts="-source 1.7"
> > find src/ -name *.java -and -type f -print0 | xargs -0
> > /usr/lib/jvm/default-java/bin/javac -g -cp
> > /usr/share/java/miglayout.jar:/usr/share/java/rsyntaxtextarea.jar:/usr/share/java/gettext-commons.jar:/usr/share/java/junit4.jar:/usr/share/java/org.eclipse.jgit.jar:/usr/share/java/json-simple.jar:/usr/share/java/jython.jar:.:/usr/share/java/httpclient.jar:/usr/share/java/httpcore.jar:/usr/share/java/commons-logging.jar:/usr/share/java/httpmime.jar:.:.:debian/_jh_build.plm
> > -d debian/_jh_build.plm -source 1.7
> > src/plm/core/model/Game.java:97: error: unmappable character for encoding
> > ASCII
> > public static final String [][] humanLangs = { {"English","en"},
> > {"Francais","fr"}, {"Italiano","it"}, {"Portugu??s brasileiro", "pt_BR"} };
> >
> > ^
> > src/plm/core/model/Game.java:97: error: unmappable character for encoding
> > ASCII
> > public static final String [][] humanLangs = { {"English","en"},
> > {"Francais","fr"}, {"Italiano","it"}, {"Portugu??s brasileiro", "pt_BR"} };
> >
> > ^
> > src/plm/core/ui/AboutPLMDialog.java:127: error: unmappable character for
> > encoding ASCII
> > + "The PLM Team: Martin Quinson, G??rald Oster
> > and others. "
> > ^
> > src/plm/core/ui/AboutPLMDialog.java:127: error: unmappable character for
> > encoding ASCII
> > + "The PLM Team: Martin Quinson, G??rald Oster
> > and others. "
> >
Bug#758821: That's probably a failed download or something
tag 758821 moreinfo thanks Hello, I kinda think that widelands can correctly upgrade from stable to testing, because nothing appears on my piuparts dashbord: https://piuparts.debian.org/sid/source/w/widelands.html Are you sure that the file was correctly downloaded and everything? Downloading the file again will not help if your partition is full. Also try using an alternate mirror if possible. Actually, I tend to think that you did not correctly remove that file from your archive, as your problem seem really related to http://askubuntu.com/questions/475632/brocken-package-for-libavcodec54-libx264-123-in-ubuntu-14-04lts Please try running these commands to see if it helps: sudo apt-get clean sudo apt-get install -f Thanks for reporting, Mt -- There are three kinds of lies -- lies, damned lies, and statistics. -- Benjamin Disraeli, British Prime Minister signature.asc Description: Digital signature
Bug#751109: quilt: FTBFS - ../run-test-completion "foo bar foo" quilt add f -- failed
On Tue, Jun 10, 2014 at 01:35:54PM +0100, Michael Tautschnig wrote: > Package: quilt > Version: 0.63-2 > Severity: serious > Usertags: goto-cc > > During a rebuild of all Debian packages in a clean sid chroot (using > cowbuilder > and pbuilder) the build failed with the following error. > > [...] > [14] $ quilt patches "foo bar" -- ok > [16] $ echo foo > "foo bar" -- ok > [18] $ ../run-test-completion "foo bar foo" quilt add f -- failed > FAIL: quilt add f -> foo foo bar != foo bar foo !~ PASS:.* > [...] > 34 commands (33 passed, 1 failed) > > It seems that some component involved does not preserve the order. The full > build log is attached. Thanks for the report and sorry for the delay. I'm under a serious work spike here. On need, one simply has to remove the file debian/patches/test-completion from the collection, and it will fix the issue. There is no additional issue in the installed software, but in the test suite. I don't fix it right away because upstream asked me to rewrite that patch anyway: http://lists.nongnu.org/archive/html/quilt-dev/2014-06/msg00014.html I'll fix both at the same time. Sorry again for the delay, Mt -- Les esprits sont comme les parachutes, ils ne fonctionnent que lorsqu'ils sont ouverts. --- Pierre Desproges signature.asc Description: Digital signature
Bug#747792: plm: FTBFS: error: package org.json.simple does not exist
Thanks for the report. I'm astonished, as I swear I built that package in a pbuilder before uploading it, and it obviously worked. I'll investigate if json changed recently. Martin, puzzeled. On Sun, May 11, 2014 at 07:26:13PM +0200, David Suárez wrote: > Source: plm > Version: 2.3+repack-3 > Severity: serious > Tags: jessie sid > User: debian...@lists.debian.org > Usertags: qa-ftbfs-20140510 qa-ftbfs > Justification: FTBFS on amd64 > > Hi, > > During a rebuild of all packages in sid, your package failed to build on > amd64. > > Relevant part (hopefully): ^ > > src/plm/core/model/Course.java:7: error: package org.json.simple does not > > exist > > import org.json.simple.JSONArray; > > ^ > > src/plm/core/model/Course.java:8: error: package org.json.simple does not > > exist > > import org.json.simple.JSONObject; > > ^ > > src/plm/core/model/Course.java:9: error: package org.json.simple does not > > exist > > import org.json.simple.JSONValue; > > ^ > > src/plm/core/model/ServerUserData.java:9: error: package org.json.simple > > does not exist > > import org.json.simple.JSONArray; > > ^ > > src/plm/core/model/ServerUserData.java:10: error: package org.json.simple > > does not exist > > import org.json.simple.JSONObject; > > ^ > > src/plm/core/model/ServerUserData.java:11: error: package org.json.simple > > does not exist > > import org.json.simple.JSONValue; > > ^ > > src/plm/core/model/HelpAppEngine.java:11: error: package org.json.simple > > does not exist > > import org.json.simple.JSONObject; > > ^ > > src/plm/core/model/session/ZipSessionKit.java:16: error: package > > org.json.simple does not exist > > import org.json.simple.JSONObject; > > ^ > > src/plm/core/model/session/ZipSessionKit.java:17: error: package > > org.json.simple does not exist > > import org.json.simple.JSONValue; > > ^ > > src/plm/core/model/session/ZipSessionKit.java:18: error: package > > org.json.simple.parser does not exist > > import org.json.simple.parser.ParseException; > > ^ > > src/plm/core/model/tracking/ServerSpy.java:3: error: package > > org.json.simple does not exist > > import org.json.simple.JSONObject; > > ^ > > src/plm/core/ui/action/ExportCloudSession.java:27: error: package > > org.json.simple does not exist > > import org.json.simple.JSONObject; > > ^ > > src/plm/core/ui/action/ExportCloudSession.java:28: error: package > > org.json.simple does not exist > > import org.json.simple.JSONValue; > > ^ > > src/plm/core/model/Course.java:53: error: cannot find symbol > > JSONObject jsonObject = new JSONObject(); > > ^ > > symbol: class JSONObject > > location: class Course > > src/plm/core/model/Course.java:53: error: cannot find symbol > > JSONObject jsonObject = new JSONObject(); > > ^ > > symbol: class JSONObject > > location: class Course > > src/plm/core/model/Course.java:75: error: cannot find symbol > > JSONObject jsonObject = new JSONObject(); > > ^ > > symbol: class JSONObject > > location: class Course > > src/plm/core/model/Course.java:75: error: cannot find symbol > > JSONObject jsonObject = new JSONObject(); > > ^ > > symbol: class JSONObject > > location: class Course > > src/plm/core/model/Course.java:102: error: cannot find symbol > > JSONObject jsonObject = new JSONObject(); > > ^ > > symbol: class JSONObject > > location: class Course > > src/plm/core/model/Course.java:102: error: cannot find symbol > > JSONObject jsonObject = new JSONObject(); > > ^ > > symbol: class JSONObject > > location: class Course > > src/plm/core/model/Course.java:123: error: cannot find symbol > > JSONObject jsonObject = new JSONObject(); > > ^ > > symbol: class JSONObject > > location: class Course > > src/plm/core/model/Course.java:123: error: cannot find symbol > > JSONObject jsonObject = new JSONObject(); > > ^ > > symbol: class JSONObject > > location: class Course > > src/plm/core/model/Course.java:133: error: cannot find symbol > > JSONArray arrayResult = (JSONArray) JSONValue.parse(response); > > ^ > > symbol: class JSONArray > > location: class Course > > src/plm/core/model/Course.java:133: error: cannot find symbol > > JSONArray arrayResult = (JSONArray) JSONValue.parse(response); > > ^ > > symbol: class JSONArray > > location: class Course > > src/plm/core/model/Course.java:133: error: cannot find symbol
Bug#744351: matrixssl: Uterly old package, with many known security issues
Source: matrixssl Severity: grave Tags: security Justification: user security hole Dear Maintainer, the version currently packaged in Debian is 5 years old, while many security issues were fixed in the upstream package meanwhile. I came to know the situation after reading the following research article: https://www.cs.utexas.edu/~shmat/shmat_oak14.pdf They showed that matrixssl is vulnerable to man-in-the-middle attacks with v1 certificates (page 2). Indeed, a new version of matrixssl (3.6.0) was released on april 9 to fix that issue. (the information is thus fully public already) But actually, since the currently packaged version is 1.8, released back in 2009, I'm not completely sure of whether this perticular flaw was already packaged at that time. In my mind, such an ancient "security"-related package is deceiving to our users. I think that this package should either be updated, or simply removed from the archive. But Jessie should not be released with that as is. Bye, Mt. -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- La drogue était un milieu plutôt sain avant que le sport ne s'en mêle. signature.asc Description: Digital signature
Bug#731372: RFA: spring -- modern full-3D RTS game engine
Unfortunately, I don't have the workpower to adopt spring for now. I don't even play this game myself :) Sorry, Mt. On Sat, Dec 21, 2013 at 11:43:35PM +0100, Markus Koschany wrote: > retitle 719618 RFA: spring -- modern full-3D RTS game engine > noowner 719618 > tags 731372 patch > thanks > > > Hello Jan and Martin, > > I have overhauled the Debian spring package and committed everything to > the team's git repository. The new package closes almost every bug > except the ones which require exceptional efforts by upstream, namely > making spring work on other architectures than amd64 or i386. > > I'm sure that I improved the package but I don't intend to become one of > the uploaders at the moment. There are far too many embedded third party > software libraries and I can't see that upstream will try to change that > in the near future. I'm also a little disappointed that there is no kind > of security mailing list and only little effort to work with upstream > developers of embedded libs like assimp to incorporate spring's changes. [1] > > However I would really appreciate it if someone reviewed the current > packaging work and helped with fixing the current RC bug. > > As far as I can see the springlobby package could also benefit from a > new upstream release and rapid-spring is no longer supported (see the > info at the bottom of the page) [2] I don't think it's worth to support > this package for Jessie. > > In any case > > Happy Christmas! > > > > [1] http://springrts.com/phpbb/viewtopic.php?f=20&t=31300 > [2] http://springrts.com/wiki/GamesDownloads > -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- Tony (C.A.R.) Hoare. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#697034: marked as pending
tag 697034 pending thanks Hello, Bug #697034 reported by you has been fixed in the Git repository. You can see the changelog below, and you can check the diff of the fix at: http://git.debian.org/?p=collab-maint/quilt.git;a=commitdiff;h=dc9e56b --- commit dc9e56b04587883d8746227b6152cae9d77c3d52 Author: Martin Quinson Date: Mon Dec 31 12:27:42 2012 +0100 only touch the non-empty files to not create unwanted files diff --git a/debian/changelog b/debian/changelog index ac6a7f1..2b80a10 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,6 +1,8 @@ quilt (0.60-5) UNRELEASED; urgency=low * Update Standards-Version to 3.9.4 (no change) + * d/p/push_timeskew: only touch the non-empty files to not create +any unwanted files (Closes: #697034). -- Martin Quinson Sun, 30 Dec 2012 21:42:51 +0100 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#696424: Possible patch
Hello,
attached is a possible patch for that issue. This is just a starting
point, as I was not able to test the patch myself. Also, I used 660 as
permissions to the file, I'm not sure of whether it's sensible or not.
Please review and test before applying.
HTH anyway,
Mt.
--
Nous avons neuf mois de vie privée avant de naître, ça devrait nous
suffire. -- Heathcote Williams, Actuel n°48, novembre 74.
Initial report (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-5638)
| The sanlock server creates the /var/log/sanlock.log world writable
| allowing any one on the system to wipe the contents of the log file or
| to store data within the log file (bypassing any quotas applied to
| their account). The affected code (in src/log.c) is:
|
| int setup_logging(void) {
| int fd, rv;
| snprintf(logfile_path, PATH_MAX, "%s/%s", SANLK_LOG_DIR,
| SANLK_LOGFILE_NAME);
| logfile_fp = fopen(logfile_path, "a+");
This patch was proposed by Martin Quinson, but not really tested as I
don't use sanlock myself. Also, I used 660 as permissions to the file,
I'm not sure of whether it's sensible or not.
Index: sanlock-2.2/src/log.c
===
--- sanlock-2.2.orig/src/log.c 2012-05-07 17:43:52.0 +0200
+++ sanlock-2.2/src/log.c 2012-12-24 22:19:10.437901274 +0100
@@ -252,10 +252,12 @@
snprintf(logfile_path, PATH_MAX, "%s/%s", SANLK_LOG_DIR,
SANLK_LOGFILE_NAME);
- logfile_fp = fopen(logfile_path, "a+");
- if (logfile_fp) {
- fd = fileno(logfile_fp);
+ fd = open(logfile_path,O_CREAT | O_WRONLY, S_IRUSR|S_IWUSR | S_IRGRP|S_IWGRP);
+ if (fd != -1) {
fcntl(fd, F_SETFD, fcntl(fd, F_GETFD, 0) | FD_CLOEXEC);
+ logfile_fp = fdopen(fd, "a+");
+ } else {
+ logfile_fp = NULL;
}
log_ents = malloc(log_num_ents * sizeof(struct entry));
Bug#694694: Patch for review
@@
+package org.jruby.util;
+
+/**
+ * Original author: Martin Bosslet
+ * Original license:
+ * Copyright (c) 2012 Martin Boßlet
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining
+ * a copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sublicense, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
+ * LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
+ * OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
+ * WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Adapted by Martin Quinson (mquin...@debian.org) to accept the hash32 prototype that is used in jruby.
+ * (same license applies)
+ *
+ */
+public class SipHash {
+public static int hash32(byte[] src, int offset, int length, byte[] seed) {
+long m;
+State s = new State(new SipKey(seed));
+int iter = length / 8;
+
+for(int i=0; i < iter; i++) {
+m = UnsignedInt64.binToIntOffset(src, (i * 8) + offset);
+s.processBlock(m);
+}
+
+m = lastBlock(src, offset, length, iter);
+s.processBlock(m);
+s.finish();
+return s.digest32();
+
+}
+
+private static long lastBlock(byte[] data, int offset, int length, int iter) {
+long last = ((long) length) << 56;
+int off = iter * 8+offset;
+
+switch (length % 8) {
+case 7:
+last |= ((long) data[off + 6]) << 48;
+case 6:
+last |= ((long) data[off + 5]) << 40;
+case 5:
+last |= ((long) data[off + 4]) << 32;
+case 4:
+last |= ((long) data[off + 3]) << 24;
+case 3:
+last |= ((long) data[off + 2]) << 16;
+case 2:
+last |= ((long) data[off + 1]) << 8;
+case 1:
+last |= (long) data[off];
+break;
+case 0:
+break;
+}
+return last;
+}
+
+private static class State {
+private long v0;
+private long v1;
+private long v2;
+private long v3;
+
+public State(SipKey key) {
+v0 = 0x736f6d6570736575L;
+v1 = 0x646f72616e646f6dL;
+v2 = 0x6c7967656e657261L;
+v3 = 0x7465646279746573L;
+
+long k0 = key.getLeftHalf();
+long k1 = key.getRightHalf();
+
+v0 ^= k0;
+v1 ^= k1;
+v2 ^= k0;
+v3 ^= k1;
+}
+
+private void compress() {
+v0 += v1;
+v2 += v3;
+v1 = UnsignedInt64.rotateLeft(v1, 13);
+v3 = UnsignedInt64.rotateLeft(v3, 16);
+v1 ^= v0;
+v3 ^= v2;
+v0 = UnsignedInt64.rotateLeft(v0, 32);
+v2 += v1;
+v0 += v3;
+v1 = UnsignedInt64.rotateLeft(v1, 17);
+v3 = UnsignedInt64.rotateLeft(v3, 21);
+v1 ^= v2;
+v3 ^= v0;
+v2 = UnsignedInt64.rotateLeft(v2, 32);
+}
+
+private void compressTimes(int times) {
+for (int i=0; i < times; i++) {
+compress();
+}
+}
+
+public void processBlock(long m) {
+v3 ^= m;
+compressTimes(2);
+v0 ^= m;
+}
+
+public void finish() {
+v2 ^= 0xff;
+compressTimes(4);
+}
+
+public long digest() {
+return v0 ^ v1 ^ v2 ^ v3;
+}
+public int digest32() {
+long res = digest();
+return ((int) (res & 0x)) ^ ((int) (res >>> 32));
+}
+}
+}
+
+class SipKey {
+private final byte[] key;
+
+public SipKey(byte[] key) {
+if (key == null || key.length != 16)
+throw new RuntimeException("SipHash key must be 16 bytes");
+this.key = key;
+}
+
+long getLeftHalf() {
+ return UnsignedInt64.binToIntOffset(key, 0);
+}
+
+long getRightHalf() {
+
Bug#672034: [Bug 996965] Re: Fail to build on amd64
On Thu, May 10, 2012 at 10:33:37AM -, Jens Beyer (Qcumber-some) wrote: > >From what I could get from this forum thread: > > https://bbs.archlinux.org/viewtopic.php?id=138992 > > it seems that a rebuild of boost libraries with the new compiler (read: > gcc-4.7.0) should solve this. > > Martin, can you confirm if the libboost packages which are used in this > build are already built by gcc-4.7.0? It seems to me that the lastest libboost in debian unstable on amd64 were built with gcc-4.6 https://buildd.debian.org/status/fetch.php?pkg=boost1.49&arch=ia64&ver=1.49.0-3&stamp=1336330572 I'm CCing the debian bug for information archival. Thanks investiguating this, Mt. -- Le pointeur est aux données ce que la boucle while est au code. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#668670: widelands: FTBFS[kfreebsd]: *** No targets specified and no makefile found. Stop.
Package: widelands fixed 668670 1:17~rc2-3 thanks for the fish This problem was fixed in upload 1:17~rc2-3 of the package, thanks for reporting. Bye, Mt. On Sat, Apr 14, 2012 at 12:22:43AM +0200, Christoph Egger wrote: > Package: src:widelands > Version: 1:17~rc2-2 > Severity: serious > Tags: sid wheezy > User: debian-...@lists.debian.org > Usertags: kfreebsd > X-Debbugs-Cc: debian-...@lists.debian.org > Justification: fails to build from source (but built successfully in the past) > > Hi! > > Your package failed to build on the kfreebsd-* buildds: > >debian/rules override_dh_auto_build > make[1]: Entering directory > `/build/buildd-widelands_17~rc2-2-kfreebsd-amd64-GDo7hT/widelands-17~rc2' > cd build-debian; make > make[2]: *** No targets specified and no makefile found. Stop. > > Full build log at > https://buildd.debian.org/status/fetch.php?pkg=widelands&arch=kfreebsd-amd64&ver=1%3A17%7Erc2-2&stamp=1334240897 > > Regards > > Christoph > > If you have further questions please mail debian-...@lists.debian.org > > -- > 9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731 > Debian Developer | Lisp Hacker | CaCert Assurer > > -- Les chats, c'est vraiment des branleurs. -- Alain Chabat -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#572966: flexml: should this package be removed?
reopen 572966 retitle 572966 Packaging could easily be improved tag 572966 patch severity 572966 minor thanks Hi again, ok. Point taken. I feel ashamed of the easy with which you solved the issues, and I'll try to upload something solving these issues. Reopening the bug to not loose the discussion & patch. Thanks for this patch, and the rest of your work, Mt. Le lundi 08 mars 2010 à 11:18 +0100, Jan Hauke Rahm a écrit : > Hi again, > > On Mon, Mar 08, 2010 at 09:37:55AM +0100, Martin Quinson wrote: > > You must be kidding, right? > > No, I'm not. Although I acknowledge what you're saying and of course > accept your decision not to remove the package. Note that for this exact > reason I didn't send a request to remove it to ftp-masters but a > proposal to you. I understand my proposal wasn't that welcome :) > > > This package works just fine and have no bug > > beside a request for removing someone from uploaders. There's a bunch of > > requests from lintian about the packaging format, but since the software > > works just fine (and does so since 3 years), nobody should need to > > rebuild it anytime soon, so I dont feel the fact that the rules do not > > follow the lastest stadards as release critical. > > Well, I disagree here. Of course this is not release critical but if you > took the time to actually update the package, you'd see that it makes a > few changes. Yes, the code compiles apparently the same way, but two > changes are simply managed in the resulting binary: > * actually put the examples in there (you just have an empty dir) > * doc-base is nowadays organized by triggers which makes the generated > maintainer scripts useless > > I attached what I would change if this were a QA package. After all it's > your call and I'm not judging what you do, but from a QA perspective I'd > strongly go for a few changes (and if we're at it, do all of them). > > > Moreover, I'm not very active, but I'm not completely MIA: I read debian > > mails, and react to important matter. Since I use flexml on a daily > > basis, if something goes wrong with that soft, I'll handle it. > > Noted. Thanks for clearing that up. > > > Finally, a popcon score of 100 is quite a huge amount given the fact > > that this is a developer only tool, targeting only C programmer forced > > to add some XML in their project, but not willing to add a depend on > > some "fancy" library. > > Sorry, I didn't notice this earlier. Popcon is often misleading but it's > impossible to by-hand check every single package that exact. :( > > > That is why I'm closing this bug report. > > Right. > > > Thanks for you QA work anyway, > > Mt. > > You're welcome! > > Hauke > on behalf of Debian QA/MIA -- Chaque fois que je regarde la télé et que je vois ces pauvres enfants affamés à travers le monde, je me mets à pleurer sans pouvoir m'en empecher. Je veux dire, j'aimerais bien être mince comme eux, mais sans les mouches, la guerre et tout ca. --- Mariah Carey -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#572966: flexml: should this package be removed?
close 572966 thanks Hey there, You must be kidding, right? This package works just fine and have no bug beside a request for removing someone from uploaders. There's a bunch of requests from lintian about the packaging format, but since the software works just fine (and does so since 3 years), nobody should need to rebuild it anytime soon, so I dont feel the fact that the rules do not follow the lastest stadards as release critical. Moreover, I'm not very active, but I'm not completely MIA: I read debian mails, and react to important matter. Since I use flexml on a daily basis, if something goes wrong with that soft, I'll handle it. Finally, a popcon score of 100 is quite a huge amount given the fact that this is a developer only tool, targeting only C programmer forced to add some XML in their project, but not willing to add a depend on some "fancy" library. That is why I'm closing this bug report. Thanks for you QA work anyway, Mt. Le dimanche 07 mars 2010 à 22:11 +0100, Jan Hauke Rahm a écrit : > Package: flexml > Version: 1.8-1 > Severity: serious > Tags: squeeze sid > User: debian...@lists.debian.org > Usertags: proposed-removal > > Dear Maintainers, > > while reviewing some packages, your package came up as a possible > candidate for removal from Debian, because: > > * you all are MIA, right? > * standards-version 3.5.10, i.e. very outdated > -> last upload in 2007 > * lintian errors and warnings > * low popcon (< 100) > > If you think that it should be orphaned instead of being removed from > Debian, please reply to this bug and tell so. > > If you disagree and want to continue to maintain this package, please > just close this bug and do an upload also fixing the other issues. > > If you agree that it should be removed, send the following commands to > cont...@bugs.debian.org (replace nn with this bug's number): > > severity nn normal > reassign nn ftp.debian.org > retitle nn RM: -- RoM; > thanks > > For more information, see > http://wiki.debian.org/ftpmaster_Removals > http://ftp-master.debian.org/removals.txt > > Thank you, > > Hauke > on behalf of Debian QA/MIA -- I don't care whichever programming language we choose, as long as it's C. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#559110: nws: should this package be removed?
Hello, I just contacted upstream to check what their plan about this are. My opinion is that if they do not update it upstream, it should be removed. That would be a pity because there is no direct replacement, but anyway. Bye, Mt. Le mardi 01 décembre 2009 à 22:46 +, Simon McVittie a écrit : > Package: nws > Version: 2.13-6.1 > Severity: serious > Justification: RC-buggy, extremely low popcon, no releases since 2005 > User: debian...@lists.debian.org > Usertags: proposed-removal > > nws seems like a possible candidate for removal from Debian: > > * RC-buggy (runs init script without going via invoke-rc.d) > * extremely low popcon (3) > * no upstream release since 2005 > * contains a mis-packaged static library which should be in the -dev package > (I won't bother filing a separate bug for this) > > If you want to keep this package around in Debian, please just close this bug, > and do an upload to fix the issues in it. > > If you don't think it's worth keeping, please send the following commands > to cont...@bugs.debian.org, replacing nn with this bug's number: > > severity nn normal > reassign nn ftp.debian.org > retitle nn RM: -- RoM; > thanks > > For more information, see > http://wiki.debian.org/ftpmaster_Removals > http://ftp-master.debian.org/removals.txt > > Regards, > smcv -- I can't believe the authors took the time to present, analyze and prove an algorithm for this middle-school problem. -- Bastard Reviewer >From Hell -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#502763: nws: piuparts test fails: ucf blocks, reading on stdin
package nws close 502763 thanks Le dimanche 19 octobre 2008 à 15:38 +0200, Lucas Nussbaum a écrit : > Package: nws > Version: 2.13-6.1 > Severity: serious > User: [EMAIL PROTECTED] > Usertags: piuparts-20081019 piuparts > > Hi, > > During tests using piuparts of all packages in lenny, > I ran into the following problem: [...] > > Errors were encountered while processing: > >nws > > E: Sub-process /usr/bin/dpkg returned an error code (1) > > ucf blocks, reading on stdin, without displaying anything: > Setting up nws (2.13-6.1) ... > It does not block for ever, it displays that at the end: Creating config file /etc/nws.conf with new version Starting the NWS family on arthur: nameserver memory sensor. 1224507448 28858 Error: register.c:529 ConnectToHost: connect to arthur.loria.fr:8060 failed 1224507448 28858 Error: host_protocol.c:1130 HostNameServerInfo: couldn't talk to arthur.loria.fr:8060 1224507452 28858 Error: register.c:529 ConnectToHost: connect to arthur.loria.fr:8060 failed 1224507452 28858 Error: host_protocol.c:1104 GetHostInfo: couldn't talk to arthur.loria.fr:8060 1224507452 28858 Error: nws_api.c:609 GetNameServer: failed to get HOST_TEST Unable to contact sensor arthur.loria.fr:8060 failed. 1224507456 28867 Error: register.c:529 ConnectToHost: connect to arthur.loria.fr:8060 failed 1224507456 28867 Error: host_protocol.c:1130 HostNameServerInfo: couldn't talk to arthur.loria.fr:8060 1224507460 28867 Error: register.c:529 ConnectToHost: connect to arthur.loria.fr:8060 failed 1224507460 28867 Error: host_protocol.c:1104 GetHostInfo: couldn't talk to arthur.loria.fr:8060 1224507460 28867 Error: nws_api.c:609 GetNameServer: failed to get HOST_TEST Unable to contact sensor arthur.loria.fr:8060 failed. Make sure that your chroot can route messages to itself, and it will help the process. # echo "127.0.1.1 arthur.loria.fr" >> /etc/hosts Thanks for testing anyway, Mt. signature.asc Description: Ceci est une partie de message numériquement signée
Bug#295191: Status: build9 doesn't really fit to a stable release
On Sun, Sep 30, 2007 at 04:54:53PM +0200, Lucas Nussbaum wrote: > Hi Martin, > > On 30/09/07 at 12:52 +, Bug#295191 wrote: > > retitle 295191 build9 doesn't really fit to a stable release > > What about build10 ? The upgraded package didn't build at the first try. I won't be able to improve this situation before another week or two. Sorry, Mt. -- A folk definition of insanity is to do the same thing over and over again and to expect the results to be different. By this definition, we in fact require that programmers of multithreaded systems be insane. Were they sane, they could not understand their programs. -- Edward A. Lee, The Problem with Threads. signature.asc Description: Digital signature
Bug#430081: quilt: FTBFS
I'm quite surprised, because the version in sid is 46-2, not 45-6. Did you check whether the new version works better for you ? Thanks, Mt. On Fri, Jun 22, 2007 at 10:53:26AM +0200, Tshepang Lekhonkhobe wrote: > Package: quilt > Version: 0.45-6 > Severity: serious > Justification: no longer builds from source > > Me know not what to do. Help! > > > [58] $ quilt mail --mbox mbox --prefix "test" --subject "This is a > test" -m "Message" -- failed > Could not determine the envelope sender address. Please use --sender. > != Patches patches/1.diff, patches/5.diff have duplicate subject > headers. > [61] $ cat - no-subject > patches/5.diff -- ok > [65] $ quilt mail --mbox mbox --prefix "test" --subject "This is a > test" -m "Message" --signature "" -- failed > Could not determine the envelope sender address. Please use --sender. != ~ > [66] $ grep -e '^Subject:' -e '^To:' -e '^Cc:' -e '^-- $' -e '^ ' mbox -- > failed > grep: mbox: No such file or directory != Subject: [test 0/5] This is a test > ~ != -- > ~ != Cc: Dummy <[EMAIL PROTECTED]> > ~ != Subject: [test 1/5] Subject of > 1.diff > ~ != -- > ~ != Cc: Dummy <[EMAIL PROTECTED]> > ~ != Subject: [test 2/5] Subject > of 2.diff is: split into multiple lines > ~ != -- > ~ != To: "John X. Doe" <[EMAIL PROTECTED]> > ~ != Subject: [test 3/5] Subject of > 3.diff > ~ != To: John X. Doe <[EMAIL PROTECTED]> > ~ != -- > ~ != Cc: "Joe R. Hacker" <[EMAIL > PROTECTED]>, > ~ != "John X. Doe" <[EMAIL PROTECTED]>, > ~ != > =?UTF-8?q?=C3=9C=20is=20an=20umlaut?= <[EMAIL PROTECTED]> > ~ != Subject: [test 4/5] First > paragraph used as subject of 4.diff. > ~ != Cc: "John X. Doe" <[EMAIL PROTECTED]> > ~ != Cc: Ü is an umlaut > <[EMAIL PROTECTED]> > ~ != -- > ~ != Subject: [test 5/5] Subject of > 5.diff > ~ != -- > [89] $ cd .. -- ok > [90] $ rm -rf d -- ok > 20 commands (17 passed, 3 failed) > make[1]: *** [test/.mail.ok] Error 3 > make[1]: Leaving directory `/home/wena/temp/quilt-0.46' > make: *** [debian/stamp-makefile-check] Error 2 > Build command 'cd quilt-0.46 && dpkg-buildpackage -b -uc' failed. > > > -- System Information: > Debian Release: lenny/sid > Architecture: i386 (i686) > > Kernel: Linux 2.6.21-1-686 (SMP w/2 CPU cores) > Locale: LANG=en_ZA.UTF-8, LC_CTYPE=en_ZA.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/bash > > Versions of packages quilt depends on: > ii bzip2 1.0.3-7high-quality block-sorting > file co > ii diffstat 1.43-2 produces graph of changes > introduc > ii gawk 1:3.1.5.dfsg-4 GNU awk, a pattern scanning > and pr > ii gettext 0.16.1-1 GNU Internationalization > utilities > ii patch 2.5.9-4Apply a diff file to an > original > > quilt recommends no packages. > > -- no debconf information > > > -- > my place on the web: > floss-and-misc.blogspot.com > -- I don't care whichever programming language we choose, as long as it's C. signature.asc Description: Digital signature
Bug#393985: quilt: FTBFS: 20 commands (15 passed, 5 failed)
retitle 393985 Bug#393985: quilt: FTBFS on misconfigured chroots severity 393985 normal thanks Hello, the error message you get is: Could not determine the envelope sender address. Please use --sender. This happens when quilt fails to retrieve the hostname, ie: - /etc/mailname does not exist - `hostname -f` does not return a fqdn - neither does `hostname` Ie, it only happens on misconfigured build daemons and chroots ;) I'll fix the testsuite by using the --sender flag to override your bad configuration, but I'm lowering the gravity because I don't see as an etch blocker at all. Bye, Mt. On Wed, Oct 18, 2006 at 10:04:48PM +0200, Andreas Jochens wrote: > Package: quilt > Version: 0.45-4 > Severity: serious > > Hello, > > when building 'quilt' on in a clean unstable chroot, > I get the following error: > > [14] $ ls patches/ > series -- ok > [15] $ quilt mail --mbox mbox --prefix "test" --subject "This is a test" -m > "Message" -- failed > Could not determine the envelope sender address. Please use --sender. != > Unable to extract a subject header from patches/1.diff > [18] $ cat - no-subject > patches/1.diff -- ok > [24] $ quilt mail --mbox mbox --prefix "test" -m "Message" -- failed > Could not determine the envelope sender address. Please use --sender. != > Introduction has no subject header > [27] $ cat - no-subject > patches/2.diff -- ok > [38] $ cat - no-subject > patches/3.diff -- ok > [44] $ cat - no-subject > patches/4.diff -- ok > [53] $ cat - no-subject > patches/5.diff -- ok > [57] $ ls patches/ > series -- ok > [58] $ quilt mail --mbox mbox --prefix "test" --subject "This is a test" -m > "Message" -- failed > Could not determine the envelope sender address. Please use --sender. != > Patches patches/1.diff, patches/5.diff have duplicate subject headers. > [61] $ cat - no-subject > patches/5.diff -- ok > [65] $ quilt mail --mbox mbox --prefix "test" --subject "This is a test" -m > "Message" -- failed > Could not determine the envelope sender address. Please use --sender. != ~ > [66] $ grep -e '^Subject:' -e '^To:' -e '^Cc:' -e '^--$' -e '^ ' mbox -- > failed > grep: mbox: No such file or directory != Subject: [test 0/5] This is a test > ~ != -- > ~ != Cc: Dummy <[EMAIL PROTECTED]> > ~ != Subject: [test 1/5] Subject of 1.diff > ~ != -- > ~ != Cc: Dummy <[EMAIL PROTECTED]> > ~ != Subject: [test 2/5] Subject of > 2.diff is: split into multiple lines > ~ != -- > ~ != To: "John X. Doe" <[EMAIL PROTECTED]> > ~ != Subject: [test 3/5] Subject of 3.diff > ~ != To: John X. Doe <[EMAIL PROTECTED]> > ~ != -- > ~ != Cc: "Joe R. Hacker" <[EMAIL > PROTECTED]>, > ~ != "John X. Doe" <[EMAIL PROTECTED]>, > ~ != > =?UTF-8?q?=C3=9C=20is=20an=20umlaut?= <[EMAIL PROTECTED]> > ~ != Subject: [test 4/5] First paragraph > used as subject of 4.diff. > ~ != Cc: "John X. Doe" <[EMAIL PROTECTED]> > ~ != Cc: Ü is an umlaut <[EMAIL > PROTECTED]> > ~ != -- > ~ != Subject: [test 5/5] Subject of 5.diff > ~ != -- > [89] $ cd .. -- ok > [90] $ rm -rf d -- ok > 20 commands (15 passed, 5 failed) > make[1]: *** [test/.mail.ok] Error 5 > make[1]: Leaving directory `/quilt-0.45' > make: *** [debian/stamp-makefile-check] Error 2 > > Regards > Andreas Jochens > -- Learning and doing is the true spirit of free software -- learning without doing gets you academic sterility, and doing without learning is all too often the way things are done in proprietary software. -- Raph Levien signature.asc Description: Digital signature
Bug#375300: This breaks my package too
My package po4a is FTBFS because of this bug: dh_md5sums dh_builddeb dpkg-deb: building package po4a' in ../po4a_0.26-1_all.deb'. tar: -: file name read contains nul character dpkg-genchanges Dude, would you mind fixing it by making --widecards the default setting, please ? I guess that at least half of the archive is broken because of this cosmetic change. Thanks in advance, Mt. signature.asc Description: Digital signature
Bug#365147: xbubble: FTBFS with new X packages: Bad link line
Hello Uwe, this bug is RC and has a patch since a long while. Would you mind uploading this before someone NMU the package, please ? Thanks, Mt. On Fri, Apr 28, 2006 at 11:46:33AM +0200, Daniel Schepler wrote: > Package: xbubble > Version: 0.5.11.1-1 > Severity: serious > > From my pbuilder build log: > > ... > checking for X... libraries , headers in standard search path > checking for XOpenDisplay in -lX11... yes > checking whether NLS is requested... yes > ... > cc -g -O3 -finline-functions -ffast-math -funroll-loops -fno-strict-aliasing > -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -Wshadow > -Wpointer-arith -Wchar-subscripts -Wcomment -Wformat -Wwrite-strings > -Wno-unused-variable -Wno-unused-function -Wno-unused-label -Werror -g -o > xbubble utils.o rectangle.o cell.o loadpng.o rgba.o init.o sprite.o bubble.o > opponent.o board.o timer.o game.o dialog.o screens.o xbubble.o > path_generated.o -lX11 -L -lpng -lz -lm > loadpng.o: In function `load_png_file': > /tmp/buildd/xbubble-0.5.11.1/src/loadpng.c:59: undefined reference to > `png_check_sig' > ... > collect2: ld returned 1 exit status > make[3]: *** [xbubble] Error 1 > make[3]: Leaving directory `/tmp/buildd/xbubble-0.5.11.1/src' > make[2]: *** [all] Error 2 > make[2]: Leaving directory `/tmp/buildd/xbubble-0.5.11.1/src' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/tmp/buildd/xbubble-0.5.11.1' > make: *** [debian/stamp-makefile-build] Error 2 > -- > Daniel Schepler > > > -- Nos péchés sont têtus, nos repentirs sont lâches --- Ch.Baudelaire, Les fleurs du mal signature.asc Description: Digital signature
Bug#365147: xbubble: Patch for this problem
Fixed in 0.5.11.2 upstream, released 5 minutes ago. Thanks for the patch, I didn't find the time to investigate the issue. Bye, Mt. On Fri, May 12, 2006 at 05:03:00PM +0200, Bas Wijnen wrote: > Package: xbubble > Followup-For: Bug #365147 > > Here's a patch which fixes the problem. autoconf must be rerun after > patching before building the package. > > The problem was that with the new X, the libraries don't need any flags > anymore, so x_libraries was empty. > > --- configure.ac.orig 2006-05-12 16:59:22.0 +0200 > +++ configure.ac 2006-05-12 16:59:45.0 +0200 > @@ -28,7 +28,9 @@ fi > if test x"$x_includes" != x; then >CPPFLAGS="$CPPFLAGS -I$x_includes" > fi > -LIBS="-L$x_libraries $LIBS" > +if test x"$x_libraries" != x; then > + LIBS="-L$x_libraries $LIBS" > +fi > AC_CHECK_LIB(X11, XOpenDisplay,,[AC_MSG_ERROR([cannot find libX11 !])]) > > -- System Information: > Debian Release: testing/unstable > APT prefers unstable > APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') > Architecture: i386 (i686) > Shell: /bin/sh linked to /bin/bash > Kernel: Linux 2.6.11 > Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) > > > -- The only stupid question is the unasked one. signature.asc Description: Digital signature
Bug#353101: Fix
It looks like this bug comes from a missing coma on the Recommends: httpd bind9 line. The new dpkg seems to be much stricter on such lines. The good point is that this issue is trivial to fix. Thanks for doing so, Mt. signature.asc Description: Digital signature
Bug#346764: xbubble: FTBFS: build-depends on removed xlibs-dev
tag 346764 patch thanks On Mon, Jan 09, 2006 at 02:38:56AM +0100, Adeodato Simó wrote: > Package: xbubble > Version: 0.5.10-2 > Severity: serious > > Hello, > > This is a serious bug filed against your package because it > build-depends on xlibs-dev, which as announced in [1] a while ago, is > no longer available in sid. This makes your package fail to build from > source. > Hello, I just digged this one, and the list of needed build-deps seems to be: libx11-dev, x-dev, libxt-dev Note that the last one is not really needed by the build, but only by the configury I use as upstream maintainer and that I should probably fix. Any help welcome on this one, too ;) Bye, Mt. -- You should apply this fix which solves the newest Internet Explorer Vulnerability described in MS05-023. It is important that you apply this fix now since we estimate the Buffer Overflow is at a Critical Level. -- Text attached to the WORM_TORVIL.C mail virus. signature.asc Description: Digital signature
Bug#345384: widelands: Critical Error: Unhandled exception: basic_string::replace
Yeah, I forgot to specify that on my boring x86, I do not get this bug. I thus rely on you to provide some useful information to the developers so that they can track and fix the issue. Thanks for your collaboration, Mt. On Sat, Dec 31, 2005 at 01:35:16AM +0100, Artur R. Czechowski wrote: > Package: widelands > Version: build9half-1 > Severity: serious > > Hello, > I run widelands, then Single Player, Tutorial Campaign and Mission 1: > Eyes in the Darkness - Game Basics. > After about 2 seconds game raises a Critical Error with message: > Unhandled exception: basic_string::replace. > > Regards > Artur > > -- System Information: > Debian Release: testing/unstable > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: amd64 (x86_64) signature.asc Description: Digital signature
Bug#345384: widelands: Critical Error: Unhandled exception: basic_string::replace
Please install the widelands-dbg package and try to generate a backtrace. For this, run $ gdb /usr/games/widelands (wait for the prompt) $ run (do what is needed to generate the crash) $ backtrace (copy/paste the output into a mail) If you don't install widelands-dbg before hands, the backtrace won't be very informative for the developpers. You can also generate a coredump (see your other bug against widelands), and use it to generate a backtrace. As you want. The outputs of the game may help, too. Run $ script widelands to capture it. Then attach the generated typescript file to a mail. Bye, Mt. On Sat, Dec 31, 2005 at 01:35:16AM +0100, Artur R. Czechowski wrote: > Package: widelands > Version: build9half-1 > Severity: serious > > Hello, > I run widelands, then Single Player, Tutorial Campaign and Mission 1: > Eyes in the Darkness - Game Basics. > After about 2 seconds game raises a Critical Error with message: > Unhandled exception: basic_string::replace. > > Regards > Artur > > -- System Information: > Debian Release: testing/unstable > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: amd64 (x86_64) > Shell: /bin/sh linked to /bin/bash > Kernel: Linux 2.6.14-2-amd64-generic > Locale: LANG=C, LC_CTYPE=pl_PL (charmap=ISO-8859-2) > > Versions of packages widelands depends on: > ii libc6 2.3.5-9 GNU C Library: Shared libraries > an > ii libgcc1 1:4.0.2-5GCC support library > ii libpng12-0 1.2.8rel-5 PNG library - runtime > ii libsdl-image1.2 1.2.4-1 image loading library for Simple > D > ii libsdl-mixer1.2 1.2.6-1.1mixer library for Simple > DirectMed > ii libsdl-net1.2 1.2.5-5 network library for Simple > DirectM > ii libsdl-ttf2.0-0 2.0.7-1 ttf library for Simple > DirectMedia > ii libsdl1.2debian 1.2.9-0.0Simple DirectMedia Layer > ii libstdc++6 4.0.2-5 The GNU Standard C++ Library v3 > ii widelands-data build9half-1 fantasy real-time strategy game > (d > ii zlib1g 1:1.2.3-9compression library - runtime > > widelands recommends no packages. > > -- no debconf information > > -- Let's call it an accidental feature. -- Larry Wall signature.asc Description: Digital signature
Bug#299601: Could you please check whether this bug is fixed in widelands build 9half?
Hello, a while ago, you reported that widelands sometimes hang and grab input. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=299601 This problem was never reported again, and a new version came out (neither in debian nor on upstreams mailing lists). I am thus inclined to think that the issue disapeared. It would be great if you could check whether the issue is still present. If not, I'll close the bug in a few months if nobody encounters it again. Bye, Mt. -- Let's call it an accidental feature. -- Larry Wall signature.asc Description: Digital signature
Bug#324597: pootle is unusable without jtoolkit
Package: pootle Version: 0.8.2005.0217-1 Severity: serious Hello, I gave the package a try, and unfortunately, I think that the package is misnamed. It should be called translate. Indeed, the complete translation toolkit is present in the package, but the pootle software is completely useless as is. Indeed, it misses a dependency on jtoolkit ... which is not packaged yet. Without it, it refuses to start. So, this dependency is a bar minimum for pootle, but there is several other packages which should be also packaged to get the full pootle power. See for example on: http://translate.sourceforge.net/wiki/pootleadmin It would be also great if the pootle server could be started automatically (as a non-root user) at startup. In any case, many thanks for packaging this software, which I feel very promising. Bye, Mt. signature.asc Description: Digital signature
Bug#322780: FTBFS with gcc4.0
Package: widelands Severity: critical Version: build9-6 Hello, I just tried to transition this package to gcc4, and it failed to build. So, I open this bug to prevent other to give it a try. That's something I need to sort out with upstream (I'm widelands maintainer), and I'm hoping it may be fixed in next upstream version, due some day this summer. Bye, Mt. signature.asc Description: Digital signature
Bug#308478: [Pkg-shadow-devel] Bug#308478: passwd: Allowable characters in user/group names regex broken
Ok, this one is easy to fix, you just have to remove the dash sign in 00list. Please don't commit the fix to the cvs yet, we are moving to svn. Do you want me to upload the fix? I think that since it's not sarge critical, it can wait tomorrow. But you may not agree. In which case, I can upload a fixed version in the next 5 mn. Christian, I'm just waiting for the green light. But don't touch the cvs now. Bye, Mt. On Tue, May 10, 2005 at 02:03:46PM +0100, Adam D. Barratt wrote: > Package: passwd > Version: 4.0.3-33 > Severity: critical > Tags: sid > Justification: Breaks unrelated software (exim4 plus others) > > Hi, > > Between -32 and -33, a chunk of code from libmisc/chkname.c:good_name() was > moved in to 406_good_name.dpatch. Unfortunately, that file is currently > commented out in debian/patches/00list, and the patch is therefore not > applied. > > This leads to an inability to install exim4, as the user/group name > "Debian-exim4" does not match upstream's regex ([a-z_][a-z0-9_-]*). > > For example: > > Adding system-user for exim (v4) > groupadd: Debian-exim is a not a valid group name > groupdel: group Debian-exim does not exist > dpkg: error processing exim4-config (--configure): > subprocess post-installation script returned error exit status 1 > > Regards, > > Adam > > > > ___ > Pkg-shadow-devel mailing list > [EMAIL PROTECTED] > http://lists.alioth.debian.org/mailman/listinfo/pkg-shadow-devel signature.asc Description: Digital signature
Bug#300395: Ok, found a way to reproduce it
Hello, I found a way to reproduce it (playing with at(1) and friends). The fix I proposed was not enough. I'm on it, hold your breath... ;) Thanks, Mt. signature.asc Description: Digital signature
Bug#300395: po4a: FTBFS: tries to get Terminal Size on build
Hello, I cannot reproduce this bug on my machine, and I'm thus embarrassed to fix it. I mean that a clean pbuild does not trigger the fix on my box. Does it come from the fact that I call pbuilder from the command line while you have a robot (cronjob?) calling it for you? Anyway, I would really appreciate if you could test the attached patch. I plan to upload a package with this change tomorow or so, but I'd prefer to make sure it's the right fix before loading the servers. Thanks for your time, Mt. On Sat, Mar 19, 2005 at 02:11:12PM +0100, Roland Stigge wrote: > Package: po4a > Version: 0.20-1 > Severity: serious > > Hi, > > building the package po4a in a clean build environment > (with pbuilder) on i386 results in: > [...] > > -- > DARTS - Debian Archive Regression Test Suite > http://darts.alioth.debian.org/ > > Please note that this report has not been generated fully automatically. > DARTS just helped finding the problem. > > diff -ruN po4a-0.20.orig/debian/changelog po4a-0.20/debian/changelog --- po4a-0.20.orig/debian/changelog 2005-03-21 10:14:41.0 +0100 +++ po4a-0.20/debian/changelog 2005-03-21 10:17:30.0 +0100 @@ -1,3 +1,13 @@ +po4a (0.20-2) unstable; urgency=medium + + Release critical bug fix. + + [Martin Quinson] + * Set the COLUMNS during the build to prevent issues arising when + building without a terminal (Closes: #300395). + + -- Martin Quinson <[EMAIL PROTECTED]> Mon, 21 Mar 2005 10:04:59 +0100 + po4a (0.20-1) unstable; urgency=low [Nicolas François] diff -ruN po4a-0.20.orig/debian/rules po4a-0.20/debian/rules --- po4a-0.20.orig/debian/rules 2005-03-21 10:14:41.0 +0100 +++ po4a-0.20/debian/rules 2005-03-21 10:12:38.0 +0100 @@ -3,6 +3,11 @@ package = po4a +# Attempt to close #300395: FTBFS: tries to get Terminal Size on build +COLUMNS?=76 +LINES?=24 +# (end of close attempt) + # Uncomment this to turn on verbose mode. #export DH_VERBOSE=1 signature.asc Description: Digital signature
Bug#300395: po4a: FTBFS: tries to get Terminal Size on build
Argh. I build all my packages in pbuilder myself before uploading, but I didn't try to redirect the output... Thanks for noticing, I'm on it. Mt. On Sat, Mar 19, 2005 at 02:11:12PM +0100, Roland Stigge wrote: > Package: po4a > Version: 0.20-1 > Severity: serious > > Hi, > > building the package po4a in a clean build environment > (with pbuilder) on i386 results in: > > = > [...] > lib/Locale/Po4a/Chooser.pm -> blib/lib/Locale/Po4a/Chooser.pm > Manifying blib/script/po4a-translate -> blib/bindoc/po4a-translate.1p > Manifying blib/script/po4a-normalize -> blib/bindoc/po4a-normalize.1p > Manifying blib/script/po4a -> blib/bindoc/po4a.1p > Manifying blib/script/po4a-updatepo -> blib/bindoc/po4a-updatepo.1p > Manifying blib/script/po4a-gettextize -> blib/bindoc/po4a-gettextize.1p > Manifying blib/lib/Locale/Po4a/Pod.pm -> blib/libdoc/Locale::Po4a::Pod.3pm > Manifying blib/lib/Locale/Po4a/LaTeX.pm -> blib/libdoc/Locale::Po4a::LaTeX.3pm > Manifying blib/lib/Locale/Po4a/TransTractor.pm -> > blib/libdoc/Locale::Po4a::TransTractor.3pm > Manifying blib/lib/Locale/Po4a/Po.pm -> blib/libdoc/Locale::Po4a::Po.3pm > Manifying blib/lib/Locale/Po4a/Sgml.pm -> blib/libdoc/Locale::Po4a::Sgml.3pm > Manifying blib/lib/Locale/Po4a/Common.pm -> > blib/libdoc/Locale::Po4a::Common.3pm > Manifying blib/lib/Locale/Po4a/KernelHelp.pm -> > blib/libdoc/Locale::Po4a::KernelHelp.3pm > Manifying blib/lib/Locale/Po4a/Guide.pm -> blib/libdoc/Locale::Po4a::Guide.3pm > Manifying blib/lib/Locale/Po4a/Xml.pm -> blib/libdoc/Locale::Po4a::Xml.3pm > Manifying blib/lib/Locale/Po4a/Man.pm -> blib/libdoc/Locale::Po4a::Man.3pm > Manifying blib/lib/Locale/Po4a/Dia.pm -> blib/libdoc/Locale::Po4a::Dia.3pm > Manifying blib/lib/Locale/Po4a/Docbook.pm -> > blib/libdoc/Locale::Po4a::Docbook.3pm > Manifying blib/lib/Locale/Po4a/Chooser.pm -> > blib/libdoc/Locale::Po4a::Chooser.3pm > Manifying blib/lib/Locale/Po4a/TeX.pm -> blib/libdoc/Locale::Po4a::TeX.3pm > Deleting META.yml > XX Update documentation pot files: > > done. > XX Update documentation fr.po: > > done. > XX Update documentation es.po: > > done. > XX Update documentation ca.po: > > done. > XX Update documentation it.po: > > done. > X Translate binary manpages to it > Unable to get Terminal Size. The TIOCGWINSZ ioctl didn't work. The COLUMNS > and LINES environment variables didn't work. The resize program didn't work. > at /usr/lib/perl5/Term/ReadKey.pm line 343. > Died at /tmp/buildd/po4a-0.20/_build/lib/My/Builder.pm line 151. > make: *** [build-stamp] Error 127 > = > > This happens if the build output is detached from a terminal (redirected to a > build log file). > > Thanks for considering. > > > -- > DARTS - Debian Archive Regression Test Suite > http://darts.alioth.debian.org/ > > Please note that this report has not been generated fully automatically. > DARTS just helped finding the problem. > > signature.asc Description: Digital signature
Bug#299601: widelands hangs and grab keyboard and mouse
Could you attach the logs of the game, for example, next time you reproduce this bug? The best would be to run the game from within the attached script and then attach the whole /tmp/widelands- directory to the bug repport. It would also help if you could kill the process from another machine on the network so that the coredump gets generated. (killall -SEGV widelands) Does this also happen when the game does not grab the focus? Thanks a lot, Mt. On Tue, Mar 15, 2005 at 10:30:56AM +0100, Marcin wrote: > Package: widelands > Version: build9-3 > Severity: serious > Justification: unknow > > After long play widelands cause hang all system and grab keyboard and > mouse. It's not possible to do any thing so you must hard restrart computer. > > It's show occasionally but i got it 3 times. > > Marcin > > -- System Information: > Debian Release: 3.1 > APT prefers testing > APT policy: (500, 'testing') > Architecture: i386 (i686) > Kernel: Linux 2.6.8-2-686 > Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2) > > Versions of packages widelands depends on: > ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries > an > ii libgcc1 1:3.4.3-6 GCC support library > ii libsdl-image1 1.2.4-1image loading library for Simple > D > ii libsdl-net1.2 1.2.5-3network library for Simple > DirectM > ii libsdl-ttf2.0 2.0.6-5ttf library for Simple > DirectMedia > ii libsdl1.2debi 1.2.7+1.2.8cvs20041007-4.1 Simple DirectMedia Layer > ii libstdc++51:3.3.5-8 The GNU Standard C++ Library v3 > ii widelands-dat build9-3 fantasy real-time strategy game > (d > > -- no debconf information > > widelands.sh Description: Bourne shell script signature.asc Description: Digital signature
Bug#295107: widelands: can't fulfill the build dependencies in sarge
I uploaded build9-5 yesterday. It does not have those build-dep (the relevant code is not activated in the package yet since I don't feel it mature enough), so I just tagged the bug pending, and I'll close it when (if ;) this version enters testing. Thanks for your time, Mt. On Sun, Feb 13, 2005 at 07:39:02PM +0100, Adrian Bunk wrote: > Package: widelands > Version: build9-3 > Severity: serious > Tags: sarge > > > The following build dependencies can't be fulfilled in sarge: > - libggzcore-dev > - libggzdmod-dev > - libggz-dev > signature.asc Description: Digital signature
Bug#289750: widelands-data contains non-free font Knights.ttf
Ups, sorry I should have checked myself, I guess. I discussed this issue with upstream, and they removed the file from their CVS right away. I'll do the same for the package soonish. Thanks for your help, Mt. On Mon, Jan 10, 2005 at 11:47:12AM -0800, Josh Triplett wrote: > Package: widelands-data > Version: build8-2 > Severity: serious > > widelands-data contains the font file Knights.ttf, containing the font > KnightsTemplar. "strings Knights.ttf" reveals that the font is by > Iconian Fonts, for which Googling leads to http://www.iconian.com/ . > The front page of that site says: > > All fonts are e-mailware, meaning the fonts are distributed for free > > personal use and for use by charities or non-profit organizations (as > > these are generally, to me, noncommercial uses). Feel free to contact > > me if you would like to use any of the fonts for commercial purposes. > > I do ask that if you like any of my fonts, you please let me know by > > e-mailing me at [EMAIL PROTECTED], hence the name "e-mailware". These > > fonts may be freely distributed and may be included on any free font > > archive site so long as the "readme" text file is not removed from > > the ZIP file. If you have more questions, try the FAQ. > > This does not satisfy the DFSG, as it requires contacting the author, > and restricts types of use. > > This font should be removed from the widelands-data package as soon as > possible, and replaced with some Free font. > > In the meantime, I'll try contacting the font designer, and see if they > would be willing to permit use of that font under the GPL. > > - Josh Triplett signature.asc Description: Digital signature
