Bug#902174: #902174: RFP: mes

2019-11-13 Thread Vagrant Cascadian 
On 2019-11-13, Jan Nieuwenhuizen wrote:
> Vagrant Cascadian writes:
>> Still one test suite failure on amd64, i386 works fine. The failing test
>> on amd64 is:
>>
>>   lib/tests/dirent/90-readdir.c
>>
>> Is there any way to mark the failing test as XFAIL conditionally by
>> architecture?
>
> As a developer: yes; not really as a user/packager atm.  IOW, you will
> need a patch.
>
> The strange thing is that I tried to reproduce on a bullseye/sid VM of
> about 2months ago; and for me all tests pass?

Well, they've consistently failed for me ... hrm.


> Anyway, I have updated the wip-0.20 branch to include three patches
>
> --8<---cut here---start->8---
> build: Mark lib/tests/dirent/90-readdir.c as XFAIL on x86_64-gcc.
> build: Mark lib/tests/dirent/90-readdir.c as XFAIL on x86_64-mescc.
> build: Mark lib/tests/dirent/90-readdir.c as XFAIL on x86_64.
> --8<---cut here---end--->8---
>
> you can cherry-pick the one that works for you.

I did a quick build with all three, and it worked. Will triage exactly
which of the three are needed another time.


>> A bigger blocker at this point is that mes installs numerous files in
>> /usr/include/, such as /usr/include/alloca.h, that conflict with other
>> packages such as libc6-dev. In a Debian environment, we typically can't
>> have multiple packages shipping the same files in the same PATHS. Other
>> libc implementations seem to put them in /usr/include/IMPLEMENTATION/
>> subdirs, e.g. /usr/include/mes/.
>
> On wip-0.20, I have fixed install to honor configure's
> --includedir=, so you may use
>
> ./configure --includedir=/usr/include/mes
>
> that should work now.

That worked pefectly!


>> With the /usr/include issue solved and ideally the test suite failure
>> too, it would in my opinion be feasible to upload to Debian!
>
> Hope this fixes it,
> a big thank you again!

And thanks likewise for quickly responding with patches!

Pushed updates to my packaging branch.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#902174: #902174: RFP: mes

2019-11-13 Thread Jan Nieuwenhuizen 
Vagrant Cascadian writes:

> Updated to 0.20 a while back and have iterated through a few test builds
> on i386, and it appears to be working:
>
>   https://salsa.debian.org/vagrant/mes

\o/

>> A few test failures on amd64, but i386 tests run fine.
>
> Still one test suite failure on amd64, i386 works fine. The failing test
> on amd64 is:
>
>   lib/tests/dirent/90-readdir.c
>
> Is there any way to mark the failing test as XFAIL conditionally by
> architecture?

As a developer: yes; not really as a user/packager atm.  IOW, you will
need a patch.

The strange thing is that I tried to reproduce on a bullseye/sid VM of
about 2months ago; and for me all tests pass?

Anyway, I have updated the wip-0.20 branch to include three patches

--8<---cut here---start->8---
build: Mark lib/tests/dirent/90-readdir.c as XFAIL on x86_64-gcc.
build: Mark lib/tests/dirent/90-readdir.c as XFAIL on x86_64-mescc.
build: Mark lib/tests/dirent/90-readdir.c as XFAIL on x86_64.
--8<---cut here---end--->8---

you can cherry-pick the one that works for you.

> A bigger blocker at this point is that mes installs numerous files in
> /usr/include/, such as /usr/include/alloca.h, that conflict with other
> packages such as libc6-dev. In a Debian environment, we typically can't
> have multiple packages shipping the same files in the same PATHS. Other
> libc implementations seem to put them in /usr/include/IMPLEMENTATION/
> subdirs, e.g. /usr/include/mes/.

On wip-0.20, I have fixed install to honor configure's
--includedir=, so you may use

./configure --includedir=/usr/include/mes

that should work now.

> With the /usr/include issue solved and ideally the test suite failure
> too, it would in my opinion be feasible to upload to Debian!

Hope this fixes it,
a big thank you again!

janneke

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Bug#902174: #902174: RFP: mes

2019-11-12 Thread Vagrant Cascadian 
On 2019-06-10, Vagrant Cascadian wrote:
> On 2019-06-10, Vagrant Cascadian wrote:
> I updated to b3fa6273210200cf2694491b07ed5a328e9a4e62 from upstream,
> added a few packaging updates, and... The current branch builds a
> package!
>
>   https://salsa.debian.org/vagrant/mes

Updated to 0.20 a while back and have iterated through a few test builds
on i386, and it appears to be working:

  https://salsa.debian.org/vagrant/mes


> A few test failures on amd64, but i386 tests run fine.

Still one test suite failure on amd64, i386 works fine. The failing test
on amd64 is:

  lib/tests/dirent/90-readdir.c

Is there any way to mark the failing test as XFAIL conditionally by
architecture?


A bigger blocker at this point is that mes installs numerous files in
/usr/include/, such as /usr/include/alloca.h, that conflict with other
packages such as libc6-dev. In a Debian environment, we typically can't
have multiple packages shipping the same files in the same PATHS. Other
libc implementations seem to put them in /usr/include/IMPLEMENTATION/
subdirs, e.g. /usr/include/mes/.

With the /usr/include issue solved and ideally the test suite failure
too, it would in my opinion be feasible to upload to Debian!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#902174: #902174: RFP: mes

2019-06-10 Thread Vagrant Cascadian 
On 2019-06-10, Vagrant Cascadian wrote:
> On 2019-06-10, Jan Nieuwenhuizen wrote:
>> Vagrant Cascadian writes:
>>> Mes itself still fails to build

I updated to b3fa6273210200cf2694491b07ed5a328e9a4e62 from upstream,
added a few packaging updates, and... The current branch builds a
package!

  https://salsa.debian.org/vagrant/mes

A few test failures on amd64, but i386 tests run fine.

Plenty of policy and lintian issues to sort out yet... but getting
there.


live well,
  vagrant

Bug#902174: #902174: RFP: mes

2019-06-10 Thread Vagrant Cascadian 
On 2019-06-10, Jan Nieuwenhuizen wrote:
> Vagrant Cascadian writes:
>> Mes itself still fails to build
...
>> configure fails to detect nyacc. It may be an issue
>> with multi-arch paths (e.g. /usr/lib/guile/2.2
>> vs. /usr/lib/x86_64-linux-gnu/guile/2.2).
>
> Oops, that looks like a bug, thanks.  I hope it's harmless...

The configure script still fails to detect nyacc (with version 0.86.0,
0.86.9, 0.92.0, 0.93.0 or 0.94.0):

  checking for nyacc [0.86.0]... command[11]: ("/usr/bin/guile-2.2 -c
  '(use-modules (nyacc lalr)) (display *nyacc-version*)'" "--version") => []
  no

When I run the command from the commandline:

  $ /usr/bin/guile-2.2  -c '(use-modules (nyacc lalr)) (display 
*nyacc-version*)'
  0.94.0

Same with any of the other versions of nyacc...

So not sure why ./configure is getting an empty result... how is
configure passing the "--version" argument?


>> Will need to do some better troubleshooting later... but this appears to
>> be the last build failure i tried based on the wip branch:
>>
>> ../pre-inst-env mescc -m 64 -c -D HAVE_CONFIG_H=1 -I include -I
>> ../include -I ../include/linux/x86_64 -static -o crt1.o
>> ../lib/linux/x86_64-mes-mescc/crt1.c
>> unhandled exception:unbound-variable:(move-specl-attr)
>> Backtrace:
>> /<>/scripts/mescc: line 56: 24904 Segmentation fault
>> ${SCHEME-$MES} --no-auto-compile -e main -L /usr/share/guile/site/2.2 -C
>> /usr/lib/guile/2.2/site-ccache $bindir/mescc.scm $sep "$@"
>> make[1]: *** [GNUmakefile:95: build] Error 139
>
> This could be a problem with Nyacc 0.93.0, find a patch attached for
> that.

Patch seems to have fixed that issue.


After some aggressive patching for /bin/sh -> /bin/bash and using bash
-x, it manages to get further, but it still fails building libmes:

  + trace 'CC lib/libmes.c' /usr/bin/gcc -c -Wdate-time
  -D_FORTIFY_SOURCE=2 -D POSIX=1 -D WITH_GLIBC=1 -D POSIX=1 -D
  WITH_GLIBC=1 -g -O2
  -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
  -Werror=format-security -o lib/libmes.o lib/libmes.c
  + echo '  CC lib/libmes.c'
CC lib/libmes.c
  + shift
  + eval /usr/bin/gcc -c -Wdate-time -D_FORTIFY_SOURCE=2 -D POSIX=1 -D
  WITH_GLIBC=1 -D POSIX=1 -D WITH_GLIBC=1 -g -O2
  -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
  -Werror=format-security -o lib/libmes.o lib/libmes.c '>>build.log'
  '2>&1'
  ++ /usr/bin/gcc -c -Wdate-time -D_FORTIFY_SOURCE=2 -D POSIX=1 -D
  WITH_GLIBC=1 -D POSIX=1 -D WITH_GLIBC=1 -g -O2
  -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
  -Werror=format-security -o lib/libmes.o lib/libmes.c
  make[1]: *** [GNUmakefile:83: build] Error 1
  make[1]: Leaving directory '/<>'
  dh_auto_build: make -j4 returned exit code 2
  make: *** [debian/rules:9: build-arch] Error 2
  dpkg-buildpackage: error: debian/rules build-arch subprocess returned
  exit status 2

I also tried without the hardening build flags, but no real difference.


live well,
  vagrant

Bug#902174: #902174: RFP: mes

2019-06-10 Thread Jan Nieuwenhuizen 
Vagrant Cascadian writes:

Hi!

> Mes itself still fails to build, but I updated to 0.19, and made a
> branch based off of janneke's wip branch as well
> (debian/master-wip). configure fails to detect nyacc. It may be an issue
> with multi-arch paths (e.g. /usr/lib/guile/2.2
> vs. /usr/lib/x86_64-linux-gnu/guile/2.2).

Oops, that looks like a bug, thanks.  I hope it's harmless...

> Many of the '#! /bin/sh' scripts contain bashisms which may not be
> compatible with Debian's (usual) /bin/sh, dash after a quick check with
> "checkbashisms". I could patch all the #! headers and audit all the
> calls to "sh" directly, but that seems a bit unmaintainable in the
> long-run.

Sure, this needs to be fixed; I'll look into it, thanks.

> Will need to do some better troubleshooting later... but this appears to
> be the last build failure i tried based on the wip branch:
>
> ../pre-inst-env mescc -m 64 -c -D HAVE_CONFIG_H=1 -I include -I
> ../include -I ../include/linux/x86_64 -static -o crt1.o
> ../lib/linux/x86_64-mes-mescc/crt1.c
> unhandled exception:unbound-variable:(move-specl-attr)
> Backtrace:
> /<>/scripts/mescc: line 56: 24904 Segmentation fault
> ${SCHEME-$MES} --no-auto-compile -e main -L /usr/share/guile/site/2.2 -C
> /usr/lib/guile/2.2/site-ccache $bindir/mescc.scm $sep "$@"
> make[1]: *** [GNUmakefile:95: build] Error 139

This could be a problem with Nyacc 0.93.0, find a patch attached for
that.

Thank you,
Greetings, janneke

>From b3fa6273210200cf2694491b07ed5a328e9a4e62 Mon Sep 17 00:00:00 2001
From: Jan Nieuwenhuizen 
Date: Sun, 9 Jun 2019 19:42:42 +0200
Subject: [PATCH] mes: Update to Nyacc 0.93.

* mes/module/nyacc/lang/c99/util.mes: New file.
* mes/module/nyacc/lang/c99/parser.mes: Use it.
* module/mescc/compile.scm (ast->info): Update for Nyacc 0.93.0.
* module/mescc/preprocess.scm (need-progress):  Likewise.
(ast-strip-comment): Likewise.
---
 mes/module/nyacc/lang/c99/parser.mes |  3 +-
 mes/module/nyacc/lang/c99/util.mes   | 45 
 module/mescc/compile.scm |  4 +++
 module/mescc/preprocess.scm  |  3 +-
 4 files changed, 53 insertions(+), 2 deletions(-)
 create mode 100644 mes/module/nyacc/lang/c99/util.mes

diff --git a/mes/module/nyacc/lang/c99/parser.mes b/mes/module/nyacc/lang/c99/parser.mes
index 1a9aaf732..9fbb5fd1e 100644
--- a/mes/module/nyacc/lang/c99/parser.mes
+++ b/mes/module/nyacc/lang/c99/parser.mes
@@ -1,7 +1,7 @@
 ;;; -*-scheme-*-
 
 ;;; GNU Mes --- Maxwell Equations of Software
-;;; Copyright © 2016,2017 Jan (janneke) Nieuwenhuizen 
+;;; Copyright © 2016,2017,2019 Jan (janneke) Nieuwenhuizen 
 ;;;
 ;;; This file is part of GNU Mes.
 ;;;
@@ -35,5 +35,6 @@
 (mes-use-module (nyacc lang sx-util))
 (mes-use-module (nyacc lang util))
 (mes-use-module (nyacc lang c99 cpp))
+(mes-use-module (nyacc lang c99 util))
 
 (include-from-path "nyacc/lang/c99/parser.scm")
diff --git a/mes/module/nyacc/lang/c99/util.mes b/mes/module/nyacc/lang/c99/util.mes
new file mode 100644
index 0..b4e24885a
--- /dev/null
+++ b/mes/module/nyacc/lang/c99/util.mes
@@ -0,0 +1,45 @@
+;;; -*-scheme-*-
+
+;;; GNU Mes --- Maxwell Equations of Software
+;;; Copyright © 2019 Jan (janneke) Nieuwenhuizen 
+;;;
+;;; This file is part of GNU Mes.
+;;;
+;;; GNU Mes is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; GNU Mes is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;;; GNU General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU General Public License
+;;; along with GNU Mes.  If not, see .
+
+;;; Commentary:
+
+;;; Code:
+
+(mes-use-module (mes guile))
+(mes-use-module (mes catch))
+(mes-use-module (mes fluids))
+(mes-use-module (mes pretty-print))
+(mes-use-module (mes optargs))
+(mes-use-module (srfi srfi-1))
+(mes-use-module (srfi srfi-9))
+(mes-use-module (sxml xpath))
+
+;; FIXME: Nyacc 0.93.0:
+;; FIXME: (mes-use-module (srfi srfi-2))
+;; FIXME: (mes-use-module (sxml fold))
+;; FIXME: (ice-9 popen)
+;; FIXME: (ice-9 rdelim)
+(define (export . rest) #t)
+(define (close-port port) #t)
+
+(mes-use-module (nyacc lang util))
+(mes-use-module (nyacc lang sx-util))
+
+(include-from-path "nyacc/lang/c99/util.scm")
diff --git a/module/mescc/compile.scm b/module/mescc/compile.scm
index 74a2defff..39b352c09 100644
--- a/module/mescc/compile.scm
+++ b/module/mescc/compile.scm
@@ -1713,6 +1713,10 @@
   ((asm-expr ,gnuc (,null ,arg0 . string))
(append-text info (wrap-as (asm->m1 arg0
 
+  ;; Nyacc 0.90.2
+  ((asm-expr ,gnuc (string ,arg0))
+   (append-text info (wrap-as (asm->m1 arg0
+
   ((expr-stmt (fctn-call (p-expr (ident

Bug#902174: #902174: RFP: mes

2019-06-09 Thread Vagrant Cascadian 
On 2019-05-19, Vagrant Cascadian wrote:
> I made another pass at the Debian packaging needed for Mes.
>
> mescc-tools 0.6.1 builds fine for me:
>
>   https://salsa.debian.org/vagrant/mescc-tools

And uploaded, waiting in NEW:

  https://ftp-master.debian.org/new/mescc-tools_0.6.1-1.html


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#902174: #902174: RFP: mes

2019-05-19 Thread Vagrant Cascadian 
On 2019-02-13, Jan Nieuwenhuizen wrote:
> I have resurrected the debian package descriptions for Nyacc,
> MesCC-tools and Mes, and updated them to the latest versions.

I made another pass at the Debian packaging needed for Mes.

mescc-tools 0.6.1 builds fine for me:

  https://salsa.debian.org/vagrant/mescc-tools


Upstream nyacc 0.86.0, 0.86.9 and 0.92.0 all build fine for me:

  https://salsa.debian.org/vagrant/nyacc

There are two branches wip/debian/master-0.86.x and
wip/debian/master-0.92.x.


Mes itself still fails to build, but I updated to 0.19, and made a
branch based off of janneke's wip branch as well
(debian/master-wip). configure fails to detect nyacc. It may be an issue
with multi-arch paths (e.g. /usr/lib/guile/2.2
vs. /usr/lib/x86_64-linux-gnu/guile/2.2).

Many of the '#! /bin/sh' scripts contain bashisms which may not be
compatible with Debian's (usual) /bin/sh, dash after a quick check with
"checkbashisms". I could patch all the #! headers and audit all the
calls to "sh" directly, but that seems a bit unmaintainable in the
long-run.

Will need to do some better troubleshooting later... but this appears to
be the last build failure i tried based on the wip branch:

../pre-inst-env mescc -m 64 -c -D HAVE_CONFIG_H=1 -I include -I
../include -I ../include/linux/x86_64 -static -o crt1.o
../lib/linux/x86_64-mes-mescc/crt1.c
unhandled exception:unbound-variable:(move-specl-attr)
Backtrace:
/<>/scripts/mescc: line 56: 24904 Segmentation fault
${SCHEME-$MES} --no-auto-compile -e main -L /usr/share/guile/site/2.2 -C
/usr/lib/guile/2.2/site-ccache $bindir/mescc.scm $sep "$@"
make[1]: *** [GNUmakefile:95: build] Error 139


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#902174: #902174: RFP: mes

2019-02-13 Thread Jan Nieuwenhuizen 
Jan Nieuwenhuizen writes:

Hi!

I have resurrected the debian package descriptions for Nyacc,
MesCC-tools and Mes, and updated them to the latest versions.

It would be great if you could take a look at them.

The descriptions are available on a `wip-debian' branch for

https://gitlab.com/janneke/nyacc
https://gitlab.com/janneke/mescc-tools
https://gitlab.com/janneke/mes   # for convenience, canonical git at
  https://git.savannah.gnu.org/git/mes.git

Meanwhile a lot has happened with Mes: it has become a GNU package and
now drives the Reduced Binary Seed bootstrap of the GNU Guix system, see
http://joyofsource.com/reduced-binary-seed-bootstrap.html

Anyway, the latest release of Mes (v0.19) does not build and install
well on Debian; so you'll need not only the debian/ directory for Mes
but also the state of the git archive it lives in.  If that's a problem
we can do a 0.19.1 release -- we're expecting a nice 0.20 release within
a month or so.

Greetings,
janneke

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Bug#902174: #902174: RFP: mes

2018-07-09 Thread Jan Nieuwenhuizen 
Vagrant Cascadian writes:

>> http://gitlab.com/janneke/nyacc
>
> Built!

Yay!

> Tried building with this, and had a couple issues.
>
> The clean target assumes a git checkout:
>
>   clean:
> git clean -dfx
>
> But Debian builds against tarballs of the source, and running 'git clean
> -dfx' from a directory with the source unpackaged but no .git directory
> fails.

Ah, bummer.  I'm somewhat reluctant to add and maintain a nice `make
clean' in the age of git.  So what I've tried is to have configure (I
really need to cleanup that thing) create a git archive if necessary.
Would that work?

> The configure target doesn't take some common options, and fails when
> unknown options are passed, such as --includedir. The default build
> passed these:
>
>   ./configure --build=x86_64-linux-gnu --prefix=/usr
> --includedir=\${prefix}/include --mandir=\${prefix}/share/man
> --infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var
> --disable-silent-rules --libdir=\${prefix}/lib/x86_64-linux-gnu
> --libexecdir=\${prefix}/lib/x86_64-linux-gnu --runstatedir=/run
> --disable-maintainer-mode --disable-dependency-tracking

That's helpful!  I made sure this command now works.  The pain of not
using autotools is almost becoming as great as the pain of not using
them.

> From the ./configure help output, it suggests that only --prefix and
> --sysconfdir are supported, but maybe not all the supported options are
> documented.

Currently, only --prefix and --infodir are supported.

> Working around that by only passing:
>
>   ./configure --prefix=/usr --sysconfdir=/etc
>
> And a no-op clean target...

Okay...hoping that's not necessary and my git init hack works.

> Still fails to build:
>
> build-aux/build-cc.sh
> ...
> ;;; WARNING: compilation of 
> /<>/mes-0.16+0.3da4d01/build-aux/mes-snarf.scm failed:
> ;;; ERROR: failed to create path for auto-compiled file 
> "/<>/mes-0.16+0.3da4d01/build-aux/mes-snarf.scm"
> mes-snarf[guile]...
> lib/libmes.c:21:10: fatal error: libmes.h: No such file or directory
>  #include 

Ah...CPPFLAGS, CFLAGS get overridden.  I revised my build.

> So, some progress, but still some work left to do! :)

Something like this was to be expected, please have a look at my new
wip-gnu branch (or `debian' which is currently wip-gnu+your patches).

I intend to release this as 0.16.1 if/once it builds for you.

Do you prefer me including your debian packaging patches, i.e. having them
"upstream" or is that inconvenient?

Thanks!
Greetings,
janneke

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Bug#902174: #902174: RFP: mes

2018-07-08 Thread Jan Nieuwenhuizen 
Matt Wette writes:

> I don't understand why `eval' is needed, esp when forcing the shell to
> be bash.
> Is there any reference to this usage?

Debian's configure looks like what I wrote in the commit message (it
uses more options)

./configure --prefix=/usr --infodir=\${prefix}/share/info

Without the eval, this results in a Makfile with this snippet

GUILE=guile
SITE_SCM_DIR=/usr/share/guile/site/2.2
SITE_SCM_GO_DIR=/usr/lib/guile/2.2/site-ccache
INFODIR=${prefix}/share/info

Adding eval fixes this, it produces

GUILE=guile
SITE_SCM_DIR=/usr/share/guile/site/2.2
SITE_SCM_GO_DIR=/usr/lib/guile/2.2/site-ccache
INFODIR=/usr/share/info

Another fix would have been to also set `prefix' in Makefile

GUILE=guile
prefix=/usr

but that would have meant a much bigger Makefile change.  Reasons
of symmetry would demand

prefix=/usr
GUILE=guile
SITE_SCM_DIR=${prefix}/share/guile/site/2.2
SITE_SCM_GO_DIR=${prefix}/lib/guile/2.2/site-ccache
INFODIR=${prefix}/share/info

but then, because Nyacc uses

make -C .. -f Makefile.nyacc

we probably also need to pass prefix variable to the sub-makes...So I
chose the easy solution.

Greetings,
janneke

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Bug#902174: #902174: RFP: mes

2018-07-08 Thread Vagrant Cascadian 
On 2018-07-08, Jan Nieuwenhuizen wrote:
> Vagrant Cascadian writes:
>> Packaging branch for nyacc:
>>
>>   https://salsa.debian.org/vagrant/nyacc
>>
>> Fails to build as it installs info pages to /share/info. Doesn't appear
>> to respect DESTDIR= ... but setting --infodir doesn't work as I would
>> expect either, suddently appending --prefix to it.
>
> I have looked into this; please see `debian' branch at
>
> http://gitlab.com/janneke/nyacc

Built!


>> And also a packaging branch for mes itself, but of course can't test it
>> until nyacc is working:
>>
>>   https://salsa.debian.org/vagrant/mes
>
> I will have a look at this later.  You will probably want to rebase on
> my `wip-gnu' branch: it has (experimental) DESTDIR and other Debian
> build support (e.g.: do not assume /bin/sh is bash, resurrect guile-2.0).

Tried building with this, and had a couple issues.

The clean target assumes a git checkout:

  clean:
git clean -dfx

But Debian builds against tarballs of the source, and running 'git clean
-dfx' from a directory with the source unpackaged but no .git directory
fails.

The configure target doesn't take some common options, and fails when
unknown options are passed, such as --includedir. The default build
passed these:

  ./configure --build=x86_64-linux-gnu --prefix=/usr
--includedir=\${prefix}/include --mandir=\${prefix}/share/man
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var
--disable-silent-rules --libdir=\${prefix}/lib/x86_64-linux-gnu
--libexecdir=\${prefix}/lib/x86_64-linux-gnu --runstatedir=/run
--disable-maintainer-mode --disable-dependency-tracking

From the ./configure help output, it suggests that only --prefix and
--sysconfdir are supported, but maybe not all the supported options are
documented.


Working around that by only passing:

  ./configure --prefix=/usr --sysconfdir=/etc

And a no-op clean target...


Still fails to build:

build-aux/build-cc.sh
...
;;; WARNING: compilation of 
/<>/mes-0.16+0.3da4d01/build-aux/mes-snarf.scm failed:
;;; ERROR: failed to create path for auto-compiled file 
"/<>/mes-0.16+0.3da4d01/build-aux/mes-snarf.scm"
mes-snarf[guile]...
lib/libmes.c:21:10: fatal error: libmes.h: No such file or directory
 #include 
  ^~
compilation terminated.
make[2]: *** [GNUmakefile:39: cc] Error 1
make[2]: Leaving directory '/<>/mes-0.16+0.3da4d01'
make[1]: *** [GNUmakefile:123: src/mes.gcc-out] Error 2
make[1]: *** Waiting for unfinished jobs
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;   or pass the --no-auto-compile argument to disable.
;;; compiling /<>/mes-0.16+0.3da4d01/build-aux/mes-snarf.scm
;;; WARNING: compilation of 
/<>/mes-0.16+0.3da4d01/build-aux/mes-snarf.scm failed:

;;; ERROR: failed to create path for auto-compiled file 
"/<>/mes-0.16+0.3da4d01/build-aux/mes-snarf.scm"
mes-snarf[guile]...
lib/libmes.c:21:10: fatal error: libmes.h: No such file or directory
 #include 
  ^~
compilation terminated.
make[1]: *** [GNUmakefile:36: build] Error 1
make[1]: Leaving directory '/<>/mes-0.16+0.3da4d01'
dh_auto_build: make -j4 returned exit code 2


So, some progress, but still some work left to do! :)


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#902174: #902174: RFP: mes

2018-07-08 Thread Vagrant Cascadian 
On 2018-07-08, Jan Nieuwenhuizen wrote:
> Vagrant Cascadian writes:
>
> @Matt: some Nyacc patches attached.
>
>>> I took a quick stab at this, and it first requires packaging:
...
>> Packaging branch for nyacc:
>>
>>   https://salsa.debian.org/vagrant/nyacc
>>
>> Fails to build as it installs info pages to /share/info. Doesn't appear
>> to respect DESTDIR= ... but setting --infodir doesn't work as I would
>> expect either, suddently appending --prefix to it.
>
> I have looked into this; please see `debian' branch at
>
> http://gitlab.com/janneke/nyacc

Thanks!


> I have created patches for Nyacc to aid Debian packaging; see attached.
> They are on my debian branch, as well as on my master.  I also made some
> WIP changes to the debian packaging: most notably: I could not find
> guile-2.2.

guile-2.2 is in Debian testing and unstable, though guile-2.0 is in
stable, testing and unstable. For upload to Debian, it would probably be
best to use the newest guile version available, unless there's a
compelling reason to use guile-2.0, or possibly work the package to
support both guile-2.2 and guile-2.0.


>> And also a packaging branch for mes itself, but of course can't test it
>> until nyacc is working:
>>
>>   https://salsa.debian.org/vagrant/mes
>
> I will have a look at this later.  You will probably want to rebase on
> my `wip-gnu' branch: it has (experimental) DESTDIR and other Debian
> build support (e.g.: do not assume /bin/sh is bash, resurrect guile-2.0).

Will take a look, thanks!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#902174: #902174: RFP: mes

2018-07-08 Thread Matt Wette 

On 07/08/2018 03:47 AM, Jan Nieuwenhuizen wrote:

Vagrant Cascadian writes:

@Matt: some Nyacc patches attached.


I took a quick stab at this, and it first requires packaging:

   https://github.com/oriansj/mescc-tools

Packaging branch for mescc-tools:

   https://salsa.debian.org/vagrant/mescc-tools

Compiles, maybe it even works!

Wow, thanks!


   https://gitlab.com/janneke/nyacc

Packaging branch for nyacc:

   https://salsa.debian.org/vagrant/nyacc

Fails to build as it installs info pages to /share/info. Doesn't appear
to respect DESTDIR= ... but setting --infodir doesn't work as I would
expect either, suddently appending --prefix to it.

I have looked into this; please see `debian' branch at

 http://gitlab.com/janneke/nyacc

I have created patches for Nyacc to aid Debian packaging; see attached.
They are on my debian branch, as well as on my master.  I also made some
WIP changes to the debian packaging: most notably: I could not find
guile-2.2.


And also a packaging branch for mes itself, but of course can't test it
until nyacc is working:

   https://salsa.debian.org/vagrant/mes

I will have a look at this later.  You will probably want to rebase on
my `wip-gnu' branch: it has (experimental) DESTDIR and other Debian
build support (e.g.: do not assume /bin/sh is bash, resurrect guile-2.0).

Greetings,
janneke




I don't understand why `eval' is needed, esp when forcing the shell to 
be bash.

Is there any reference to this usage?

Matt

Bug#902174: #902174: RFP: mes

2018-07-06 Thread Vagrant Cascadian 
On 2018-07-06, Vagrant Cascadian wrote:
> On 2018-06-22, Geert Stappers wrote:
>> Package name : mes
>>  Version : 0.15
>>  Upstream Author : Jan Nieuwenhuizen 
>>  URL : https://gitlab.com/janneke/mes
>>  License : GNU GPLv3
>> Programming Lang : C
>>  Description : Maxwell Equations of Software
>>
>> Mes aims to help create full source bootstrapping for GuixSD as part
>> of the bootstrappable builds effort.
>
> I took a quick stab at this, and it first requires packaging:
>
>   https://github.com/oriansj/mescc-tools

Packaging branch for mescc-tools:

  https://salsa.debian.org/vagrant/mescc-tools

Compiles, maybe it even works!


>   https://gitlab.com/janneke/nyacc

Packaging branch for nyacc:

  https://salsa.debian.org/vagrant/nyacc

Fails to build as it installs info pages to /share/info. Doesn't appear
to respect DESTDIR= ... but setting --infodir doesn't work as I would
expect either, suddently appending --prefix to it.


And also a packaging branch for mes itself, but of course can't test it
until nyacc is working:

  https://salsa.debian.org/vagrant/mes


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#902174: #902174: RFP: mes

2018-07-06 Thread Vagrant Cascadian 
On 2018-06-22, Geert Stappers wrote:
> Package name : mes
>  Version : 0.15
>  Upstream Author : Jan Nieuwenhuizen 
>  URL : https://gitlab.com/janneke/mes
>  License : GNU GPLv3
> Programming Lang : C
>  Description : Maxwell Equations of Software
>
> Mes aims to help create full source bootstrapping for GuixSD as part
> of the bootstrappable builds effort.

I took a quick stab at this, and it first requires packaging:

  https://github.com/oriansj/mescc-tools
  
  https://gitlab.com/janneke/nyacc


live well,
  vagrant


signature.asc
Description: PGP signature