Bug#1071082: Bug#1048703: NMU pushed to DELAYED/10

2024-05-24 Thread Martin Quinson
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

2023-11-06 Thread Martin Quinson
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

2023-02-22 Thread Martin Quinson
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

2022-10-15 Thread Martin Quinson
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

2022-09-19 Thread Martin Quinson
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=ign=7=7=only=ftbfs-20220917=lu...@debian.org=1=1=1=1#results
> 
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
> 
> If you reassign this bug to another package, please 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

2022-09-06 Thread Martin Quinson
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

2022-09-06 Thread Martin Quinson
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

2022-08-25 Thread Martin Quinson
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

2022-06-11 Thread Martin Quinson
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

2021-07-16 Thread Martin Quinson
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

2021-07-16 Thread Martin Quinson
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

2021-07-13 Thread Martin Quinson
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

2021-04-06 Thread Martin Quinson
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

2020-06-06 Thread Martin Quinson
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

2020-05-22 Thread Martin Quinson
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

2020-05-21 Thread Martin Quinson
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]

2020-05-20 Thread Martin Quinson
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

2020-02-13 Thread Martin Quinson

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)

2020-02-11 Thread Martin Quinson
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

2018-10-28 Thread Martin Quinson
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

2018-10-27 Thread Martin Quinson
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

2017-10-07 Thread Martin Quinson
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
> <martin.quin...@ens-rennes.fr> 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

2017-10-04 Thread Martin Quinson
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

2017-10-04 Thread Martin Quinson
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=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

2017-08-24 Thread Martin Quinson
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

2017-08-22 Thread Martin Quinson
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

2017-08-13 Thread Martin Quinson
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

2017-08-08 Thread Martin Quinson
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

2017-07-17 Thread Martin Quinson
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

2017-03-28 Thread Martin Quinson
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

2017-03-28 Thread Martin Quinson
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)

2016-12-20 Thread Martin Quinson
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)

2016-12-20 Thread Martin Quinson
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

2016-12-20 Thread Martin Quinson
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 <martin.quin...@loria.fr>
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 <mquin...@debian.org>  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

2016-12-20 Thread Martin Quinson
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 <martin.quin...@loria.fr>
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 <mquin...@debian.org>  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

2016-11-21 Thread Martin Quinson
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ää

2016-11-20 Thread Martin Quinson
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

2016-09-04 Thread Martin Quinson
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 <martin.quin...@loria.fr>
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

2016-08-18 Thread Martin Quinson
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"

2016-08-15 Thread Martin Quinson
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

2016-08-15 Thread Martin Quinson
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

2016-06-15 Thread Martin Quinson
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

2016-04-19 Thread Martin Quinson
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.

2016-02-09 Thread Martin Quinson
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

2015-11-17 Thread Martin Quinson
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 

Bug#794704: viva: FTBFS

2015-08-07 Thread Martin Quinson
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

2015-08-07 Thread Martin Quinson
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 QtGui
 #include QPushButton
+
+#ifndef Q_MOC_RUN /* MOC can choke on some boost headers */
 #include boost/foreach.hpp
+#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 boost/foreach.hpp
+#endif
 #include float.h
 
 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 QtGui
 #include QPushButton
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 boost/foreach.hpp
 #include float.h


signature.asc
Description: Digital signature


Bug#794704: viva: FTBFS

2015-08-06 Thread Martin Quinson
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=274496page=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

2014-11-19 Thread Martin Quinson
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

2014-11-13 Thread Martin Quinson

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

2014-11-12 Thread Martin Quinson
]   - 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.br/ 
^
  src/plm/core/ui/AboutPLMDialog.java:127: error: unmappable character for 
  encoding ASCII
  + The PLM Team: Martin Quinson, G??rald Oster 
  and others.br/ 
 ^
  src/plm/core/ui/OSXAdapter.java:54: error: unmappable character for 
  encoding ASCII
  Copyright ?? 2003-2007 Apple, Inc., All Rights Reserved
^
  src/plm/core/ui/OSXAdapter.java:54: error: unmappable character for 
  encoding ASCII
  Copyright ?? 2003-2007 Apple, Inc., All Rights Reserved
 ^
  src/plm/test/simple/test/PythonSimpleExerciseTest.java:13: error: 
  unmappable character for encoding ASCII
  return zqkd??ajd??\\;
  ^
  src/plm/test/simple/test/PythonSimpleExerciseTest.java:13: error: 
  unmappable character for encoding ASCII
  return zqkd??ajd??\\;
   ^
  src/plm/test/simple/test/PythonSimpleExerciseTest.java:13: error: 
  unmappable character for encoding ASCII
  return zqkd??ajd??\\;
   ^
  src/plm/test/simple/test/PythonSimpleExerciseTest.java:13: error: 
  unmappable character for encoding ASCII
  return zqkd??ajd??\\;
^
  src/plm/test/simple/test/JavaSimpleExerciseTest.java:13: error: unmappable 
  character for encoding ASCII
  return zqkd??ajd??\\;
  ^
  src/plm/test/simple/test/JavaSimpleExerciseTest.java:13: error: unmappable 
  character for encoding ASCII
  return zqkd??ajd??\\;
   ^
  src/plm/test/simple/test/JavaSimpleExerciseTest.java:13: error: unmappable 
  character for encoding ASCII
  return zqkd??ajd??\\;
   ^
  src/plm/test/simple/test/JavaSimpleExerciseTest.java:13: error: unmappable 
  character for encoding ASCII
  return zqkd??ajd??\\;
^
  src/lessons/recursion/cons/Increasing.java:31: error: unmappable character 
  for encoding ASCII

Bug#768732: plm: FTBFS in jessie: src/plm/core/model/Game.java:97: error: unmappable character for encoding ASCII

2014-11-12 Thread Martin Quinson
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#758821: That's probably a failed download or something

2014-08-27 Thread Martin Quinson
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

2014-06-16 Thread Martin Quinson
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

2014-05-11 Thread Martin Quinson
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
  JSONArray arrayResult = (JSONArray) JSONValue.parse(response);
  ^
symbol:   variable JSONValue
location: class Course
  

Bug#744351: matrixssl: Uterly old package, with many known security issues

2014-04-13 Thread Martin Quinson
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

2013-12-22 Thread Martin Quinson
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=20t=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

2012-12-31 Thread Martin Quinson
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 martin.quin...@loria.fr
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 mquin...@debian.org  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

2012-12-24 Thread Martin Quinson
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

2012-12-10 Thread Martin Quinson
, 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() {
+return UnsignedInt64.binToIntOffset(key, 8); 
+}
+}
+
+class UnsignedInt64 {
+private UnsignedInt64() {}
+
+public static long binToInt(byte[] b) {
+return  binToIntOffset(b, 0);
+}
+
+public static long binToIntOffset(byte[] b, int off

Bug#672034: [Bug 996965] Re: Fail to build on amd64

2012-05-10 Thread Martin Quinson
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.49arch=ia64ver=1.49.0-3stamp=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.

2012-04-15 Thread Martin Quinson
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=widelandsarch=kfreebsd-amd64ver=1%3A17%7Erc2-2stamp=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?

2010-03-08 Thread Martin Quinson
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: packagename -- RoM; reasons 
 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#572966: flexml: should this package be removed?

2010-03-08 Thread Martin Quinson
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#559110: nws: should this package be removed?

2009-12-02 Thread Martin Quinson
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: packagename -- RoM; reasons
 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

2008-10-20 Thread martin quinson
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) ...
 BLOCKS

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

2007-10-02 Thread Martin Quinson
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

2007-06-28 Thread Martin Quinson
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!
 
 quote
 [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.
 /quote
 
 -- 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)

2006-10-20 Thread Martin Quinson
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

2006-06-26 Thread Martin Quinson
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

2006-05-30 Thread Martin Quinson
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

2006-05-12 Thread Martin Quinson
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

2006-02-17 Thread Martin Quinson
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

2006-01-09 Thread Martin Quinson
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

2006-01-02 Thread Martin Quinson
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#299601: Could you please check whether this bug is fixed in widelands build 9half?

2005-12-31 Thread Martin Quinson
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#345384: widelands: Critical Error: Unhandled exception: basic_string::replace

2005-12-31 Thread Martin Quinson
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#322780: FTBFS with gcc4.0

2005-08-12 Thread Martin Quinson
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

2005-05-10 Thread Martin Quinson
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: po4a: FTBFS: tries to get Terminal Size on build

2005-03-21 Thread Martin Quinson
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: Ok, found a way to reproduce it

2005-03-21 Thread Martin Quinson
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

2005-03-20 Thread Martin Quinson
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

2005-03-15 Thread Martin Quinson
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

2005-02-14 Thread Martin Quinson
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

2005-01-12 Thread Martin Quinson
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