bug#42698: easyrpg package fails to build

[Vinícius dos Santos Oliveira]

Here's the tail of the build log:

  CXX  src/libeasyrpg_player_a-game_actors.o
src/game_actor.cpp: In member function ‘virtual int
Game_Actor::GetBattleX() const’:
src/game_actor.cpp:919:28: error: ‘const class RPG::Terrain’ has no member
named ‘grid_c’; did you mean ‘grid_top_y’?
right = left + terrain->grid_c / 1103;
^~
grid_top_y
src/game_actor.cpp: In member function ‘virtual int
Game_Actor::GetBattleY() const’:
src/game_actor.cpp:1001:19: error: ‘const class RPG::Terrain’ has no member
named ‘grid_a’; did you mean ‘grid_top_y’?
top = terrain->grid_a;
   ^~
   grid_top_y
src/game_actor.cpp:1002:28: error: ‘const class RPG::Terrain’ has no member
named ‘grid_b’; did you mean ‘grid_top_y’?
bottom = top + terrain->grid_b / 13;
^~
grid_top_y
src/game_actor.cpp: In member function ‘void Game_Actor::SetSprite(const
string&, int, bool)’:
src/game_actor.cpp:1075:12: error: ‘class RPG::SaveActor’ has no member
named ‘sprite_flags’; did you mean ‘sprite_name’?
  GetData().sprite_flags = transparent ? 3 : 0;
^~~~
sprite_name
make[1]: *** [Makefile:2566: src/libeasyrpg_player_a-game_actor.o] Error 1
make[1]: *** Waiting for unfinished jobs
make[1]: Leaving directory
'/tmp/guix-build-easyrpg-player-0.6.1.drv-0/easyrpg-player-0.6.1'
make: *** [Makefile:1332: all] Error 2
command "make" "-j" "4" failed with status 2

I think there's a mismatch between easyrpg-player (0.6.1) and liblcf
(0.6.2) versions. Just by bumping the easyrpg-player package, the problem
should go away I think.

-- 
Vinícius dos Santos Oliveira
https://vinipsmaker.github.io/

bug#42698: easyrpg package fails to build

[Efraim Flashner]

Thanks. Fixed with 948b59dfd5caa8fe5fc0feb3300f12b37820e23f


-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#33542: Strange tarball download error on Hydra

[Ludovic Courtès]

Hi,

Mark H Weaver  skribis:

> Mark H Weaver  writes:
>
>> On Hydra, the armhf builds for al variants of 'linux-libre-4.14.84'
>> failed because the tarball download failed.  See below for the build
>> log.  Strangely, it was unable to find the (guix base16) module.
>
> I now see that 89f1fee8e788fc32d08583b4207c1ecb91d50f28 added a new use
> of (guix base16) during downloads, and that the copies of Guix currently
> running on the armhf build slaves is too old to include (guix base16).

This bug is now 2 years old and not applicable to deployments made since
then.  Closing!

Ludo’.

bug#26302: Multilingual web site is on-line!

[Ludovic Courtès]

Hi,

"pelzflorian (Florian Pelz)"  skribis:

> Since there is no Makefile, I suppose it is enough to put the website
> directory of the guix-artwork repo in a tar file.

Sounds good to me.

> What version number should we give it?  That of Guix, or a MMDD?
> I suppose the version number should be part of the POT file’s
> Project-Id-Version field and the tar filename, but I don’t know.

I’d say MMDD.  The coordinator might have suggestions.

> Should we at the same time send a tarball of Guix’ prospective new
> release?

It can happen separately but it’d be nice!

> Could you Julien or someone else send the tarball(s) off to the TP
> coordinator?

That’d be great.   Julien, let us know if you’d rather hand over this
responsibility.

Cheers,
Ludo’.

bug#41063: emacs-guix: unrecognized keyword error

[Ludovic Courtès]

Hi Michael,

Michael Rohleder  skribis:

>>   https://gitlab.com/emacs-guix/emacs-guix/-/issues/18
>
> This is fixed with the latest (gitlab) version:
>
> From 1c58fd7f2de4623bb051e7f8472e703290663e64 Mon Sep 17 00:00:00 2001
> From: Michael Rohleder 
> Date: Fri, 31 Jul 2020 08:33:43 +0200
> Subject: [PATCH] gnu: emacs-guix: Update to latest gitlab version.
>
> * gnu/packages/emacs-xyz.scm (emacs-guix): Update to a 0.5.2 snapshot.
> fix https://issues.guix.gnu.org/41063
> [source] changes to git-getch.
> [snippet] removed.
> [native-inputs] added tools to build.

Awesome.  Applied, thanks!

Ludo’.

bug#42162: Recovering source tarballs

[Timothy Sample]

Hi Ludovic,

Ludovic Courtès  writes:

> Wooohoo!  Is it that time of the year when people give presents to one
> another?  I can’t believe it.  :-)

Not to be too cynical, but I think it’s just the time of year that I get
frustrated with what I should be working on, and start fantasizing about
green-field projects.  :p

> Timothy Sample  skribis:
>
>> The header and footer are read directly from the file.  Finding the
>> compressor is harder.  I followed the approach taken by the pristine-tar
>> project.  That is, try a bunch of compressors and hope for a match.
>> Currently, I have:
>>
>> • gnu-best
>> • gnu-best-rsync
>> • gnu
>> • gnu-rsync
>> • gnu-fast
>> • gnu-fast-rsync
>> • zlib-best
>> • zlib
>> • zlib-fast
>> • zlib-best-perl
>> • zlib-perl
>> • zlib-fast-perl
>> • gnu-best-rsync-1.4
>> • gnu-rsync-1.4
>> • gnu-fast-rsync-1.4
>
> I would have used the integers that zlib supports, but I guess that
> doesn’t capture this whole gamut of compression setups.  And yeah, it’s
> not great that we actually have to try and find the right compression
> levels, but there’s no way around it it seems, and as you write, we can
> expect a couple of variants to be the most commonly used ones.

My first instinct was “this is impossible – a DEFLATE compressor can do
just about whatever it wants!”  Then I looked at pristine-tar and
realized that their hack probably works pretty well.  If I had infinite
time, I would think about some kind of fully general, parameterized LZ77
algorithm that could describe any implementation.  If I had a lot of
time I would peel back the curtain on Gzip and zlib and expose their
tuning parameters.  That would be nicer, but keep in mind we will have
to cover XZ, bzip2, and ZIP, too!  There’s a bit of balance between
quality and coverage.  Any improvement to the representation of the
compression algorithm could be implemented easily: just replace the
names with their improved representation.

One thing pristine-tar does is reorder the compressor list based on the
input metadata.  A Gzip member usually stores its compression level, so
it makes sense to try everything at that level first before moving one.

>> Originally, I used your code, but I ran into some problems.  Namely,
>> real tarballs are not well-behaved.  I wrote new code to keep track of
>> subtle things like the formatting of the octal values.
>
> Yeah I guess I was too optimistic.  :-)  I wanted to have the
> serialization/deserialization code automatically generated by that
> macro, but yeah, it doesn’t capture enough details for real-world
> tarballs.

I enjoyed your implementation!  I might even bring back its style.  It
was a little stiff for trying to figure out exactly what I needed for
reproducing the tarballs.

> Do you know how frequently you get “weird” tarballs?  I was thinking
> about having something that works for plain GNU tar, but it’s even
> better to have something that works with “unusual” tarballs!

I don’t have hard numbers, but I would say that a good handful (5–10%)
have “X-format” fields, meaning their octal formatting is unusual.  (I’m
looking at “grep -A 10 default-header” over all the S-Exp files.)  The
most charming thing is the “uname” and “gname” fields.  For example,
“rtmidi-4.0.0” was made by “gary” from “staff”.  :)

> (BTW the code I posted or the one in Disarchive could perhaps replace
> the one in Gash-Utils.  I was frustrated to not see a ‘fold-archive’
> procedure there, notably.)

I really like “fold-archive”.  One of the reasons I started doing this
is to possibly share code with Gash-Utils.  It’s not as easy as I was
hoping, but I’m planning on improving things there based on my
experience here.  I’ve now worked with four Scheme tar implementations,
maybe if I write a really good one I could cap that number at five!

>> To avoid hitting the SWH archive at all, I introduced a directory cache
>> so that I can store the directories locally.  If the directory cache is
>> available, directories are stored and retrieved from it.
>
> I guess we can get back to them eventually to estimate our coverage ratio.

It would be nice to know, but pretty hard to find out with the rate
limit.  I guess it will improve immensely when we set up a
“sources.json” file.

>> You mean like ?  :)
>
> Woow.  :-)
>
> We could actually have a CI job to create the database: it would
> basically do ‘disarchive save’ for each tarball and store that using a
> layout like the one you used.  Then we could have a job somewhere that
> periodically fetches that and adds it to the database.  WDYT?

Maybe  I assume that Disarchive would fail for a few of them.  We
would need a plan for monitoring those failures so that Disarchive can
be improved.  Also, unless I’m misunderstanding something, this means
building the whole database at every commit, no?  That would take a lot
of time and space.  On the other hand, it would be 

bug#42702: catch2 build failure on ARM

[maxim . cournoyer]

On ARM systems, (armhf-linux, aarch64-linux), the catch2 package fails to 
build, due to a
compilation warning treated as an error:

[ 90%] Building CXX object 
CMakeFiles/SelfTest.dir/include/reporters/catch_reporter_xml.cpp.o
/gnu/store/ap7hgyv4rjqmhg4a6cb6cypsh3g1f5q4-gcc-7.5.0/bin/c++   
-I/tmp/guix-build-catch2-2.1.2.drv-0/source/include  -O2 -g -DNDEBUG   -Wall 
-Wextra -Wunreachable-code -Wpedantic -Werror -std=c++11 -o 
CMakeFiles/SelfTest.dir/include/reporters/catch_reporter_xml.cpp.o -c 
/tmp/guix-build-catch2-2.1.2.drv-0/source/include/reporters/catch_reporter_xml.cpp
/tmp/guix-build-catch2-2.1.2.drv-0/source/include/internal/catch_tostring.cpp: 
In static member function ‘static std::__cxx11::string 
Catch::StringMaker::convert(char)’:
/tmp/guix-build-catch2-2.1.2.drv-0/source/include/internal/catch_tostring.cpp:202:21:
 error: comparison is always true due to limited range of data type 
[-Werror=type-limits]
 } else if ('\0' <= value && value < ' ') {
~^~~~

bug#42702: catch2 build failure on ARM

[maxim . cournoyer]

maxim.courno...@gmail.com writes:

> On ARM systems, (armhf-linux, aarch64-linux), the catch2 package fails to 
> build, due to a
> compilation warning treated as an error:
>
> [ 90%] Building CXX object 
> CMakeFiles/SelfTest.dir/include/reporters/catch_reporter_xml.cpp.o
> /gnu/store/ap7hgyv4rjqmhg4a6cb6cypsh3g1f5q4-gcc-7.5.0/bin/c++   
> -I/tmp/guix-build-catch2-2.1.2.drv-0/source/include  -O2 -g -DNDEBUG   -Wall 
> -Wextra -Wunreachable-code -Wpedantic -Werror -std=c++11 -o 
> CMakeFiles/SelfTest.dir/include/reporters/catch_reporter_xml.cpp.o -c 
> /tmp/guix-build-catch2-2.1.2.drv-0/source/include/reporters/catch_reporter_xml.cpp
> /tmp/guix-build-catch2-2.1.2.drv-0/source/include/internal/catch_tostring.cpp:
>  In static member function ‘static std::__cxx11::string 
> Catch::StringMaker::convert(char)’:
> /tmp/guix-build-catch2-2.1.2.drv-0/source/include/internal/catch_tostring.cpp:202:21:
>  error: comparison is always true due to limited range of data type 
> [-Werror=type-limits]
>  } else if ('\0' <= value && value < ' ') {
> ~^~~~

This is also the case for i686-linux.

bug#42601: Guix install bug: error: Unbound variable: ~S

[maxim . cournoyer]

Hi,

Bengt Richter  writes:

> Hi,
>
> On +2020-07-30 00:15:56 +0200, Ricardo Wurmus wrote:
>> 
>> Jan Wielkiewicz  writes:
>> 
>> > Dnia 2020-07-29, o godz. 22:17:01
>> > Ricardo Wurmus  napisał(a):
>> >
>> >> 
>> >> “avr-toolchain” is a procedure, not a package.  Use
>> >> “avr-toolchain-4.9” or “avr-toolchain-5”.
>> >> 
>> >
>> > Success!
>> >
>> > What about the strange message though?
>> > "incorrect package definition" would be better.
>> 
>> “Unbound variable: ~S” looks like a format string with a placeholder
>> that didn’t get replaced with an actual value.  It would be marginally
>> better if it said “Unbound variable: avr-toolchain”.
>
> I suspect there are also bugs lurking in the exception-reporting chain between
> a (throw 'exception args ...) and the ultimate format statement that produces
> a message with "~S" in it. Perhaps one got fixed or avoided in the upgrade?

That would be my hunch too!  I had reported and tried to fix such problems
here: http://issues.guix.gnu.org/41956.  Still unresolved, it requires
more effort to be fixed properly (writing tests mostly).

Maxim

bug#42162: Recovering source tarballs

[Ricardo Wurmus]

zimoun  writes:

> Yes, but for example all the packages in gnu/packages/bioconductor.scm
> could be "git-fetch".  Today the source is over url-fetch but it could
> be over git-fetch with https://git.bioconductor.org/packages/flowCore or
> g...@git.bioconductor.org:packages/flowCore.

We should do that (and soon), especially because Bioconductor does not
keep an archive of old releases.  We can discuss this on a separate
issue lest we derail the discussion at hand.

-- 
Ricardo

bug#42702: catch2 build failure on ARM

[Danny Milosavljevic]

Hi Maxim,

On Mon, 03 Aug 2020 14:22:21 -0400
maxim.courno...@gmail.com wrote:

>  } else if ('\0' <= value && value < ' ') {
> ~^~~~

I think that this tries to find non-printable characters, so those with ASCII
codes 0 < value < 32 and 128 < value < 255.  But char is unsigned on ARM, so
it won't do that with the code above.  Therefore, this IS an error and treating
it as a warning would be very, very, bad.


pgpwpCb9RJkSr.pgp
Description: OpenPGP digital signature