Re: imagemagick@6.9.11-48 to graft or not to graft with 6.9.12-2

[Andreas Enge]

Hello Mark and Léo,

Am Mon, Mar 22, 2021 at 05:12:35PM -0400 schrieb Mark H Weaver:
> However, I think it would be going too far to adopt your proposal as a
> general rule for all grafts.  In some cases, it can clearly be seen that
> an upstream release includes little more than bug fixes.  For example,
> if the recent gvfs-1.40.2 security update had required grafting, I would
> not have hesitated to do so, and that would have been much simpler and
> IMO cleaner than importing the upstream patches into our tree.

Am Tue, Mar 23, 2021 at 02:34:52PM +0100 schrieb Léo Le Bouter:
> In general my opinion is that backporting fixes is time-consuming and
> that if we have to do it each time I wont be able to keep up with the
> load. I'd rather update things to a version that already includes fixes
> and is supported by upstream even at the cost of world rebuilds. I
> can't deal with upstreams who either do not backport fixes, or don't
> integrate fixes at all.

these are very good arguments, which I understand and share. But moving
to another version is problematic even when there is no soname bump, as
I wrote in my bug report https://issues.guix.gnu.org/47315; grafts with
different version numbers lead to a command line behaviour that is not
understandable:

$ guix package -A imagemagick
imagemagick 6.9.12-2g   out,doc gnu/packages/imagemagick.scm:132:2
imagemagick 6.9.11-48   out,doc gnu/packages/imagemagick.scm:48:2

$ guix build imagemagick@6.9.11
guix build: error: imagemagick: package not found for version 6.9.11

$ guix build imagemagick@6.9.11-48
/gnu/store/c30y49vg735g6b4hh590zrc9fmvcsy0w-imagemagick-6.9.12-2g-doc
/gnu/store/l3hr0fimip6v7vmkgxbqygsglxaxasy0-imagemagick-6.9.12-2g

>From a user's perspective, inkscape@6.9.11 is at the time there and not
there; it is shown by "guix package", but then not accessible for install-
ation, but silently "glossed over" in favour of a different version.

I just noticed that I can do this:
$ guix build imagemagick@6.9.11-48 --no-grafts
/gnu/store/wlnciwhn6llwqwywf4hq739v5bbcrq3h-imagemagick-6.9.11-48-doc
/gnu/store/vlix7fclb7ifjgmxgpwr1pvraff89w7b-imagemagick-6.9.11-48
But I can also do this:
$ guix build imagemagick@6.9.12-2g --no-grafts
/gnu/store/4s20df0zjmmys8zvlvynksrwz5xqk9ls-imagemagick-6.9.12-2g-doc
/gnu/store/7iwx7rj1ipsbgb9wgimrrflniyxpilw3-imagemagick-6.9.12-2g
where I do not know what I would have expected - the ungrafted version
of 6.9.12 is 6.9.11, no? At the same time, for once it respects my
wish for a specific version.

Otherwise said, grafting to different versions breaks our semantic for
designating packages, in which version numbers play an important role,
and replaces it by a mess which even with the examples above I have a
hard time understanding.
 
Caeterum censeo:
The real fix is probably to do less grafts and more rebuilds...

Andreas

Re: imagemagick@6.9.11-48 to graft or not to graft with 6.9.12-2

[Andreas Enge]

Am Fri, Mar 19, 2021 at 10:40:45AM +0100 schrieb Léo Le Bouter:
> We had a user reporting that Inkscape stopped working after the graft (
> https://logs.guix.gnu.org/guix/2021-03-18.log#100200), after which we
> decided on IRC with rekado we might cheat by symlinking the shared
> libraries, which I've done in commit
> 2e0ff59f0cd836b156f1ef2e78791d864ce3cfcd, from a glance it didnt seem
> the soname change caused backwards incompatible changes but only
> forward incompatible changes.

It happens I just wanted to use inkscape, started submitting a bug report:
   https://issues.guix.gnu.org/47315
and ended up realising that this is exactly the issue discussed on
guix-devel.

I cannot afford a "guix pull" right now, since with
   https://issues.guix.gnu.org/31719
this might mean a download of a few gigabytes, so I did not check whether
the symlinking fix does work.

But honestly, this feels like piling a cludge (symlinking) onto a cludge
(grafting), and that we are not in the high quality approach for which
I appreciate Guix.

Personally, I would suggest to revert the commits. If the CVE is sufficiently
important (it would be useful if the commit log or the diff itself contained
its number), maybe we can update the imagemagick version on the wip-release
branch, which is supposed to be built soon and merged back to master?

And please let us agree that in the future, we only backport fixes in grafts
and do not update version numbers.

Andreas

Re: Release 1.2.1: status

[Andreas Enge]

Hello,

Am Thu, Mar 18, 2021 at 03:28:38PM +0100 schrieb zimoun:
>   guix weather --display-missing

I am giving it a try, but after about one hour at 100% CPU on one core it
is still only half way through. Is this normal? I think I will stop it to
at least redirect the output into a file...

Andreas

Re: Release on April 18th?

[Andreas Enge]

Hello,

Am Fri, Mar 12, 2021 at 12:33:18AM -0800 schrieb Chris Marusich:
> The proc man page has this to say about column 7:
>   (7) optional fields: zero or more fields of the form "tag[:value]"

And it goes on like this:
(8)  separator: the end of the optional fields is marked
   by a single hyphen.

So it looks like it is enough to search for a hyphen surrounded by spaces.
The hyphen is apparently there also when there is no optional field (7),
as can be seen from your examples and also my own system, where both occur
in parallel:
34 26 253:0 /gnu/store /gnu/store ro,noatime - ext4 /dev/mapper/cryptroot rw
51 26 253:0 /var/lib/docker /var/lib/docker rw,relatime shared:1 - ext4 
/dev/mapper/cryptroot rw

Alternatively, one can also count from the back to get the fields labelled
(9) to (11) (which may be (8) to (10) in case there are no optional fields).
(I was momentarily confused by "(12) super option*s*"; but these are
apparently separated by commas and not whitespace.)

Andreas

Re: Release on April 18th?

[Andreas Enge]

Hello,

Am Tue, Mar 02, 2021 at 03:03:50PM -0500 schrieb Leo Famulari:
> I think that timeline is too short for core-updates, although it depends
> on how many people choose to monitor the building and fix problems.
> Regarding the bug tracker, I don't think we've begun identifying
> core-updates bugs yet.

it would be nice if core-updates could be part of the release. I have
been waiting for gmp, mpfr and mpc to appear in master. In particular
mpfr-4.1.0 has been released in July 2020, and I have updated it in
core-updates in the same month. Even with a release in April, that makes
9 months! Otherwise, we would end very far off the 6 months suggested in
doc/contributing.texi.

If I read the git history correctly, we have merged core-updates for the
last time in May 2020. Shocking numbers. Hopefully the recent progress
in continuous integration will help us reach our goal of more frequent
merging again.

Andreas

Re: Guix in Debian!

[Andreas Enge]

Hello Pjotr,

Am Sun, Feb 28, 2021 at 04:56:25PM +0100 schrieb Pjotr Prins:
>   root@machine:/home/wrk# ps xau|grep guix
>   root5268  0.0  0.0  12944  5088 ?Ss   09:44   0:00 
> /usr/bin/guix-daemon --build-users-group=_guixbuild
> 
> Mind blowing stuff :)

nice indeed!

> And as a normal user
>   guix pull 
>   Updating channel 'guix' from Git repository at 
> 'https://git.savannah.gnu.org/git/guix.git'...
>   guix pull: error: Git error: SSL error: 0x - UNKNOWN ERROR CODE 
> (0001)
> The certificates work for Guix, but not for git. Not sure what the problem is.

This is not related to Debian, see here:
   https://issues.guix.gnu.org/46829

Andreas

Re: Xpdf with or without Qt

[Andreas Enge]

Thank you, Vincent, Leo and Simon for all your suggestions!

I note that they differ in whether xpdf gets recompiled when dependencies
change (keeping a package around in a scheme file or channel) or not (using
inferiors or a separate, not updated profile); probably both may have their
advantages and disadvantages in practice.

Andreas

Re: Xpdf with or without Qt

[Andreas Enge]

Hello Vincent,

thanks for your quick reply!

Am Fri, Feb 26, 2021 at 05:27:47PM +0100 schrieb Vincent Legoll:
>   If Qt isn't found, the GUI viewer (xpdf) won't be built, but the
>   command line tools will still be built.

Okay, I see. So they changed the program, and we should follow, although
I am not that happy about it - for a "more standard" pdf reader, I might
as well switch to evince or okular.

So I would like to ask a help-guix type question (but keep it here since
the context is already set up):
How can I personally keep the old variant?
Should I create a custom channel with xpdf@4.02? Or even xpdf@5 to have
a higher version number, but with the old 4.02 package code and source?
Or a manifest including some time-machine thing, or a personal package
transformation that compiles xpdf --with-source=...?

Andreas

Xpdf with or without Qt

[Andreas Enge]

Hello,

commit 35089dca4053bf5888441d1648086cdadb6eb1e4 adds Qt to the xpdf package
and removes most X libraries. The result is quite different and does not
correspond to the synopsis "...based on the Motif toolkit" any more, and we
get closer to more modern pdf readers such as evince or okular. On the other
hand, I have been using xpdf as a "no frills" reader with an interface that
had not changed forever, which I am missing now.

Is this a change that became necessary with the update from 4.02 to 4.03
(that looks minor from the numbers!)? If no, I would like to suggest getting
back to the previous inputs. If yes, I do not quite know what to do :)

Andreas

Re: Changes to the branching workflow

[Andreas Enge]

Am Fri, Feb 12, 2021 at 03:17:34PM -0500 schrieb Leo Famulari:
> What do you think? Should we stick with the plan I wrote in the manual?
> Or change it?

>From what I understood of the discussion, I would also go with Tobias's and
Efraim's suggestion: There is a core-updates branch that is constantly open
and where people can push; this does not seem to leave a possibility of
mistake, almost by definition. Then we can branch off core-updates-frozen,
which is frozen :), except for cherry-picked bug fixing commits and merges
from master. Once it is finished, it is merged into master and deleted.

The one thing where maybe problems can occur is that now there is the
core-updates branch that has wildly advanced, and that needs to somehow be
tamed to go with the new master branch. But the situation would be the same
if it were called core-updates-next, I suppose.

Technically speaking, this is the same as your suggestion, Leo, but it
avoids the constant dance between core-updates, that disappears and
reappears under the name core-updates-next, that disappears and reappears
under the name core-updates, and so on.

Andreas

Re: Guix Day: Notes from the CI session

[Andreas Enge]

Hello,

Am Tue, Feb 09, 2021 at 04:45:26PM -0500 schrieb Leo Famulari:
> Regarding hosting, I heard objections to spending significant amounts of
> money on it. But, there was also an objection to hosting the machines in
> people's homes. Do we know anyone who could donate some rackspace? Or
> office-space, if we acquire workstations instead of servers?

that is not quite what I objected :)  I think that if we buy many
not so expensive machines, we could host them at people's homes. I was
just a bit hesitant that individuals host a 1€ machine. If there
is only one or two, I might be able to host them at my institute, however.

Andreas

Re: New “ungrafting” branch

[Andreas Enge]

Hello,

Am Mon, Dec 14, 2020 at 04:00:36PM -0500 schrieb Leo Famulari:
> I agree, it's not a violation of the functional packaging model in a
> strict sense.

if I understand correctly, it remains confusing in a non-strict sense:
grafting is functional, but it is not the same function. Precisely, the
function for grafted packages has more arguments, the original input and the
replacement one. And only one of these arguments is visible in the package
definition, the other one enters through the backdoor (it is declared in
the input itself).

Andreas

Re: New “ungrafting” branch

[Andreas Enge]

Hello,

On Tue, Dec 08, 2020 at 03:13:40PM +0100, zimoun wrote:
> I have missed the discussion on IRC and I do not understand the
> rationale.  What's the point of "ungrafting"?

I suppose it is just a branch with all the patches that are grafted applied,
so that it is not necessary to graft them anymore. An excellent initiative,
I just built inkscape with 36 grafts!

Andreas

Re: [support-re...@gandi.net: [GANDI] guixsd.org expires in 60 days]

[Andreas Enge]

Hello,

On Sat, Dec 05, 2020 at 05:25:58PM +0100, Tobias Geerinckx-Rice wrote:
> If cost is a pain point, note that Gandi's current annual renewal price of
> €19 isn't the lowest around.

cost is not the problem; but I like tidying up and getting rid of cruft,
and I feel that this old domain is some hassle for not much gain: I need to
- pay by credit card;
- make a wire transfer from the Guix Europe account to my own account;
- add an entry to the Guix Europe ledger and check everything is okay.

I was against renewing it already two years ago, but the Solidary
Administrative Council of Guix Europe decided by consensus last year
to keep it for one more year, and to let it run out later.

If you prefer to keep the domain, you should bring it for a discussion
and a new vote of the SAC. I am still against renewing it, but if people
think we should do it, I can live with a renewal as well.

Andreas

[support-re...@gandi.net: [GANDI] guixsd.org expires in 60 days]

[Andreas Enge]

Hello all,

just for your information, our domain name guixsd.org will expire soon
(how many out there still remember that we own it?). We decided last year
to renew it for just one more year and to let it run out. 

So if we still have anything pointing there, it would be good to change
it now.

Andreas


- Forwarded message from Gandi  -
Hello,

This email concerns the renewal of the domain name guixsd.org at Gandi, for 
which you are a contact via the username or organization "guix_europe". 

The entire world is currently going through a very turbulent period right now, 
and in light of this global public health crisis, we are aware that priorities 
are being reconsidered.

Nevertheless, it is important that we inform you that the domain name 
guixsd.org will expire at the Registry in 60 days, on 27 Jan 2021 21:39 UTC. 

If you would like to keep this domain, you must renew it before this date. The 
domain will be renewable at the normal price until 13 Mar 2021 11:39 UTC

IMPORTANT: if you miss the renewal deadline, your domain name will be deleted 
from our system on 13 Mar 2021 11:39 UTC. Its status will then change to 
"restorable" until 12 Apr 2021 21:39 UTC. Note, however, that the price of a 
restoration may be considerably higher than for a regular renewal.
- End forwarded message -

Re: Thank you for participating in the Guix Day!

[Andreas Enge]

Hello,

On Tue, Nov 24, 2020 at 09:13:38PM +0530, Arun Isaac wrote:
> Guix Day was wonderful. Thank you very much for organizing it! More than
> anything, I attended just to see people's faces, and put faces to
> names. Seeing smiling faces is surprisingly motivating, especially in
> lockdown times. :-)

I can only second that - it is even nicer to meet in person, but this
was a really social event online.

> I'm happy it was an online event and I could participate. I live in
> India and travelling to Europe is a bank-breaking endeavour that is
> normally out of the question. I think even future offline Guix Days,
> after the pandemic, should have an online component so that a wide
> audience can participate easily. It's not the same as an actual offline
> presence, but it's better than nothing at all.

Hybrid events are probably quite difficult to organise, but others with
more knowledge on the topic have already spoken up. What we could do in
any case, lockdown or not, is provide for *both* online events such as
this one and, once it is possible again, offline/hybrid events.

Thanks to Julien and Simon for all the work they have invested and to
Fosshost for hosting the videoconference.

Andreas

Re: Using #true and #false everywhere?

[Andreas Enge]

On Wed, Oct 21, 2020 at 11:59:40AM +0200, Ludovic Courtès wrote:
> What material are you referring to?  SICP & co.?

I simply used my favourite search engine with something such as
   scheme language boolean

In my case the first link is to the racket manual:
   https://docs.racket-lang.org/reference/booleans.html

Or this:
   https://courses.cs.washington.edu/courses/cse341/02sp/scheme/basics.html

Or the Wikipedia entry:
   https://en.wikipedia.org/wiki/Scheme_%28programming_language%29

Any kind of search quickly reveals that booleans in Scheme are coded
using #t and #f; whereas to find #true and #false, my impression is that
one already needs to know that these are possibilities. I find their use
more confusing than helpful.

Now if we drop the #t from phases as discussed in the present thread,
that would be even better. I have never been convinced by phases that
always return #t and never #f; what is the point of a return value
if it is not really checked?

Andreas

Re: Using #true and #false everywhere?

[Andreas Enge]

Hello,

On Tue, Oct 20, 2020 at 02:45:54PM +0200, zimoun wrote:
> You are playing the devil's lawyer role, right?
> This is a question about the standard, right?  It is not about #true
> or #false vs #t or #f.
> The Guile manual explains well, isn't it?

yes, indeed. What I want to say: Besides other problems that newcomers of
different backgrounds might have when learning Scheme and/or Guile and/or
Guix, having to learn that "#f" means "false" is in my opinion one of the
least; whereas my other examples provide what I think are real difficulties
(some of which simply need a bit of studying of documentation).

Andreas

Re: Using #true and #false everywhere?

[Andreas Enge]

And since we are on the bikeshedding front, I feel like writing a second
message.

On Fri, Oct 16, 2020 at 12:38:23PM +0200, Ludovic Courtès wrote:
> As discussed on IRC recently, several of us think that using “#true” and
> “#false” instead of “#t” and “#f” throughout or documentation and code
> would probably make it easier for newcomers to decipher that.

Honestly, I think either of them is sufficiently easy to understand, in the
presence of much more difficult questions:
- The "non-typedness of booleans": Does "(if 1 2 3)" raise an exception or
  work, and if the latter is true, what is the result? And if I replace
  "1" by "0" or the empty list? (In Guix, this is related to the question:
  Do I need to add #t or #f at the end of a phase, or is the value of its
  last statement sufficient?)
- What are the different procedures for comparing things?
- What are quotes, quasiquotes, unquotes? How do they relate to code staging
  in Guix? (This is to me the most difficult part of Guix code, in particular
  for someone coming from a language where code is code and data are data.)
- Actually, why are there two ways to define literal lists? Do they have
  the same result? This is a mixture of the previous two questions; try
 (eq? '(1) '(1))
  vs.
 (eq? '(1) (list 1))
  or
 (eq? (list 1) (list 1))
  Then try again with eqv? and equal?.
  Then try again with "(eq? '() (list))" and so on. (This one still
  surprises me.)
  Does it matter? (Probably not much in the context of Guix.)
- If I want to know what are and what happens in the phases of
  the perl build system, do I look in build/perl-build-system.scm or
  build-system/perl.scm? Why is there no build-system/perl-build-system.scm
  or build/perl.scm instead? (Just a little trolling at the end of my post,
  no real harm intended ;-) But I am honestly unable to remember the answer,
  and look at the two files every time I wonder about a build system, which
  is of course entirely feasible, some might even argue instructional.)

Andreas

Re: Using #true and #false everywhere?

[Andreas Enge]

Hello,

on the bikeshedding front: I find #true and #false confusing, since
everything I see on the Scheme language seems to use #t and #f. My first
impression was that #true and #false were guilisms...

On Fri, Oct 16, 2020 at 03:36:06PM +0200, Tobias Geerinckx-Rice wrote:
> Maxim Cournoyer 写道：
> > I'd only agree to such a change if it's already been standardized in the
> > RnRS as such
> Sure, I think that's implied.  #true and #false are part of the R7RS-small
> standard.

...but since this does not seem to be the case, I can live with either.

Try this for the fun of it:
$ guile
scheme@(guile-user)> (eq? #t #true)
$1 = #t

So this would be another argument to stay with #t.

Andreas

Re: Did nmap just become non-free?

[Andreas Enge]

Hello,

On Thu, Oct 15, 2020 at 12:12:45AM +0200, Marius Bakke wrote:
>   Proprietary software companies wishing to use or incorporate Covered
>   Software within their programs must contact Licensor to purchase a
>   separate license. Open source developers who wish to incorporate parts
>   of Covered Software into free software with conflicting licenses may
>   write Licensor to request a waiver of terms.
> 
> From .
> 
> So a "proprietary software company" cannot use or incorporate nmap
> within a program, even if that program is free (as in software)?

the formulation is weird, but I am reading this more as "you cannot
incorporate this software into a proprietary one", which more or less
summarises the difference between the GPL and the LGPL.

In guix/licenses.scm, the previous entry for nmap (dating from 2016),
instead of providing a link to https://www.gnu.org/licenses/ , gave one
to https://fedoraproject.org/wiki/Licensing/Nmap , which classifies the
license as free, but incompatible with the GPL.

It would be nice to get feedback from the FSF on the question, indeed;
but I am less pessimistic than you!

Andreas

Re: 32-bit builds on 64-bit hardware/VMs

[Andreas Enge]

Hello,

On Mon, Oct 12, 2020 at 01:52:18PM +0200, Ludovic Courtès wrote:
> As a start, could you comment out in ‘machines-for-berlin.scm’ the
> machines that need to be removed in order to not run 32-bit builds in
> potentially buggy environments?

already done by Danny in commit 81b5eab1a85196725895502637e2540a1535ce8b
of the maintenance repository. However, that leaves only two machines
for armhf. If we had an image for the Novena board, I could set up one
or two more :)  In any case, it will not be enough to keep up with the
architecture.

Andreas

Guix Europe yearly assembly minutes

[Andreas Enge]

Hello,

the minutes of the yearly assembly of Guix Europe, which we held last June,
are finally online:
   
https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/guix-europe/minutes/ga-20200621.txt

Enjoy,

Andreas

Re: Release v1.2 timetable

[Andreas Enge]

On Tue, Oct 06, 2020 at 09:57:20AM +0200, Mathieu Othacehe wrote:
> The CI is already building substitutes for two images
> (hurd-barebones-qcow2-image and pine64-barebones-raw-image). We could
> maybe release 1.2 version of those images.

Nice! For completely selfish reasons, I would like to also see an
image for the novena board.

Andreas

Re: 03/03: hydra: Update the file with the machines in the bayfront build farm.

[Andreas Enge]

Hello!

On Sun, Sep 20, 2020 at 03:22:25PM +0200, Ludovic Courtès wrote:
> ‘speed’ should be used with care: in general, you always want it to be
> the same (not to be confused with ‘parallel-builds’).  In the case
> above, the risk is that milano will always be chosen.

See https://issues.guix.gnu.org/43773 .

Once this is fixed, I agree.

Andreas

Re: Guix Paths

[Andreas Enge]

Hello,

On Mon, Sep 21, 2020 at 01:32:52AM +, Buttery Pancake wrote:
> I am wondering why Guix chose `/var/guix` path instead of `/gnu/var/guix` or 
> `/
> guix/var/guix`, as Nix uses `/nix/var/nix`?
> I do think that having only one or two directories under root, `/gnu` and/or 
> `/
> guix` is better, instead of having Guix related files under multiple
> directories (/var, /run etc.). It will be neat, clean and unique.

I agree especially with the problem that the store database is usually
saved under /var/guix/db - it would be much nicer if the store could be
copied over from one machine to another simply by copying one directory.
But that could also be solved by moving just the database to /gnu/store/db,
I suppose.

In a similar vein, it is annoying to have to use "--localstatedir=/var"
when configuring. The default configuration should simply be, well, the
default... And then it might as well be /gnu, too.

Andreas

Re: Packaging pd

[Andreas Enge]

Thanks for your replies, Ludovic and Ricardo!

On Mon, Sep 07, 2020 at 12:22:45PM +0200, Ricardo Wurmus wrote:
> > Now there already is a "pd" in Guix; are there any precedents on how to
> > name a second pd? "pd-polytope"? "primal-dual"? "pd-primal-dual"?
> “pd” in Guix is “Pure Data”, the visual data flow language that’s often
> used for music.  It is an option to rename it to “pure-data”.

I opted for "primal-dual" and put it into guix-past. So there is no
particular reason to rename the "pd" that already made it into guix
master.

Andreas

Re: IceCat-78.2 preview on 'wip-icecat-78' branch; need icedove-78.

[Andreas Enge]

Hello,

On Mon, Sep 14, 2020 at 11:14:03PM +0200, Jonathan Brielmaier wrote:
> ice-9/boot-9.scm:1669:16: In procedure raise-exception:
> In procedure delete-file: No such file or directory

just a quick guess: The nss recipe calls "delete-file" a few times in
the replaced "install" phase. Maybe you could uncomment these lines and
see whether one of the files does not exist any more with a newer nss.

Andreas

Re: What should "guix build --source" produce? (was Re: Dependency cycle issues when using a Gexp-based snippet)

[Andreas Enge]

Hello Maxim,

On Fri, Sep 11, 2020 at 02:22:44PM -0400, Maxim Cournoyer wrote:
> +@cindex snippets, when to use
> +The boundary between using an origin snippet versus a build phase to
> +modify the sources of a package can be elusive.  Origin snippets are
> +typically used to remove unnecessary files such as bundled libraries,
> +nonfree sources, or to apply simple substitutions.  The source derived
> +from an origin should produce a source that can be used to build the
> +package on any system that the upstream package supports (i.e., act as
> +the corresponding source).  In particular, origin patches or snippets
> +must not embed store items in the sources; such patching should rather
> +be done using build phases.

that sounds good to me! However, I would not use the word "patch" in
"origin patches or snippets must not embed store items",
since patches are yet something else as defined in the "patches"
field; almost by definition, they cannot embed store items. So in the end:
"In particular, origin snippets must not embed store items in the sources;
such modifications should rather be done using build phases."

Thanks,

Andreas

Re: What should "guix build --source" produce? (was Re: Dependency cycle issues when using a Gexp-based snippet)

[Andreas Enge]

Hello Mark,

On Tue, Sep 08, 2020 at 12:07:01AM -0400, Mark H Weaver wrote:
> > + (let ((coreutils #+(canonical-package coreutils)))
> > +   (substitute* "configure"
> > + (("/bin/pwd")
> > +  (string-append coreutils "/bin/pwd")))
> > +   (substitute* "src/corelib/global/global.pri"
> > + (("/bin/ls")
> > +  (string-append coreutils "/bin/ls"
> > + #t)
> 
> In my opinion, "guix build --source PACKAGE" should produce sources that
> can be used to build the package on any system that the upstream package
> supports, not just on Guix systems.

that sounds good to me, in particular taking your subsequent arguments into
account. Guix sources could be just as useful as Debian sources in this
respect. Could this not be the elusive boundary between preparing the source
and adding a phase to the build arguments?

Andreas

Re: python-docker-py

[Andreas Enge]

On Fri, Aug 28, 2020 at 05:41:12PM +0200, Andreas Enge wrote:
> Are you okay with renaming the package? There are only 2 dependent packages
> (fdroidserver, on which I am currently working; and docker-compose)?

Done in commit b8cb3eb63bf298d7b8965b3b41d45dce34771952.

Andreas

Packaging pd

[Andreas Enge]

Hello,

I knew that three letter software names are bad, but there is worse -
two letter software names! I would like to package
  pd - Primal-Dual Methods for Vertex and Facet Enumeration
  http://www.cs.unb.ca/~bremner/software/pd/

Now there already is a "pd" in Guix; are there any precedents on how to
name a second pd? "pd-polytope"? "primal-dual"? "pd-primal-dual"?

Then is there a point in packaging it at all? This is more or less a
one-shot research software, I think, with no versioning. So maybe not
relevant enough? (Let us have this Wikipedia discussion!) In that case,
I would like to add it to the guix-past channel, since I need it for
the 10 years reproducibility challenge, so the naming question still
stands. By the way, how are naming conflicts between channels resolved?

Thanks for your thoughts,

Andreas

python-docker-py

[Andreas Enge]

Hello,

commit 3146b6da6dd3124f8693f48a9ed7ff8208324e23 moves python-docker-py from
version 1.10.6 to 3.7.3. I think that at the same time, it should have been
renamed to python-docker:
- as can be seen in the source, it is downloaded from the "docker" project
  on pypi;
- it advertises itself as "Name: docker" in 
  lib/python3.8/site-packages/docker-3.7.3-py3.8.egg-info/PKG-INFO

Are you okay with renaming the package? There are only 2 dependent packages
(fdroidserver, on which I am currently working; and docker-compose)?
Do we need a special field to mark the replacement? I do not expect that
users have installed this package independently of fdroid or docker-compose.

Andreas

Re: Bootstrapping core-updates fails with mpc-1.2.1dev

[Andreas Enge]

I might have found the reason thanks to "guix build -K".
Here are a few files in the gcc source directory:
lrwxrwxrwx  1 andreas users   9 Aug 20 22:29 gmp -> gmp-6.0.0
drwxr-xr-x 15 andreas users4096 Aug 20 22:29 gmp-6.0.0/
lrwxrwxrwx  1 andreas users   9 Aug 20 22:29 mpc -> mpc-1.2.1
drwxr-xr-x  8 andreas users4096 Aug 20 22:29 mpc-1.2.1dev/
lrwxrwxrwx  1 andreas users  10 Aug 20 22:29 mpfr -> mpfr-4.1.0
drwxr-xr-x  9 andreas users4096 Aug 20 22:29 mpfr-4.1.0/

So it looks like gcc can cope with different gmp/mpfr/mpc version numbers,
but not with the "dev" suffix.

I will give it another try.

Andreas

Bootstrapping core-updates fails with mpc-1.2.1dev

[Andreas Enge]

Hello,

after the release of mpc-1.2.0, I tried to update the version in core-updates.
More precisely, I used a tarball of the current master under the name of
mpc-1.2.1dev, with an additional commit. Then bootstrapping fails.

For someone with bayfront access, the build log is in
   
/var/log/guix/drvs/ay/qa5whpm2nq3667ff69xzqvn9119b8g-gcc-cross-boot0-7.5.0.drv.gz

It ends with this:
...
g++ -fno-PIE -c  -DIN_GCC_FRONTEND -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE 
  -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall 
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute 
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros 
-Wno-overlength-strings   -DHAVE_CONFIG_H -I. -Ic -I../../gcc-7.5.0/gcc 
-I../../gcc-7.5.0/gcc/c -I../../gcc-7.5.0/gcc/../include 
-I../../gcc-7.5.0/gcc/../libcpp/include 
-I/tmp/guix-build-gcc-cross-boot0-7.5.0.drv-0/build/./gmp 
-I/tmp/guix-build-gcc-cross-boot0-7.5.0.drv-0/gcc-7.5.0/gmp 
-I/tmp/guix-build-gcc-cross-boot0-7.5.0.drv-0/build/./mpfr/src 
-I/tmp/guix-build-gcc-cross-boot0-7.5.0.drv-0/gcc-7.5.0/mpfr/src  
-I../../gcc-7.5.0/gcc/../libdecnumber -I../../gcc-7.5.0/gcc/../libdecnumber/dpd 
-I../libdecnumber -I../../gcc-7.5.0/gcc/../libbacktrace   -o c/c-typeck.o -MT 
c/c-typeck.o -MMD -MP -MF c/.deps/c-typeck.TPo ../../gcc-7.5.0/gcc/c/c-typeck.c
In file included from ../../gcc-7.5.0/gcc/c/c-decl.c:53:0:
../../gcc-7.5.0/gcc/builtins.h:23:17: fatal error: mpc.h: No such file or 
directory
 #include 
 ^
compilation terminated.
make[2]: *** [Makefile:1099: c/c-decl.o] Error 1
...

Does this ring a bell? I do not quite see how this can be related to the mpc
version used for bootstrapping; and the phase unpack-gmp is carried out
and does unpack my mpc-1.2.1dev.tar.gz after gmp and mpfr.

What is strange in the compiler line above is that gmp and mpfr are
referenced by -I directives, but mpc is not.

Is there anything special with gmp-7.5.0 that prevents it from being compiled
with a newer mpc? The build log also shows that gmp and mpfr are compiled in
their respective subdirectories, but mpc is not.

Andreas

Re: MPFR and MPC

[Andreas Enge]

Hello,

On Mon, Jul 27, 2020 at 12:58:52PM +0200, Ludovic Courtès wrote:
> It’s gonna take a while, but I think we’d rather be safe than sorry
> given that these two libraries underpin the toolchain chain (sic).

oh well, never ask a question when you fear the answer might not be
what you hope for :)

> I think you could test the update on ‘core-updates’ with:
>   ./pre-inst-env guix build -e '(@@ (gnu packages commencement) gcc-final)'

Luckily I remembered that I do have access to a powerful build machine,
so I even went as far as to execute
   ./pre-inst-env guix build mpfr,
which succeeds; so I am going to push the patch.

Thanks!

Andreas

MPFR and MPC

[Andreas Enge]

Hello,

mpfr just had a new release 4.1.0:
   https://ftp.gnu.org/pub/gnu/mpfr/
and I am planning to make one for mpc as well.

Should I follow some procedure for an update in Guix, or could I just push
two commits to core-updates?

Andreas

Re: TeX Live 2019 wanted

[Andreas Enge]

On Mon, Dec 16, 2019 at 11:41:57PM +0100, Marius Bakke wrote:
> Errh, the patch only works if you already have Poppler 0.83.0.  For the
> current 'core-updates' branch, I believe you can use the same approach
> but fetch poppler-0.76.0.cc instead (or take Arch's patch[0]).

Ah, this is rocket science! I guessed so much as to use the 0.76.0 file;
however, the build now fails with the following:

/gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7/bin/bash 
./libtool  --tag=CXX   --mode=link g++ -Wreturn-type -Wno-write-strings -g -O2  
 -o pdftex pdftexdir/pdftex-pdftexextra.o synctexdir/pdftex-synctex.o 
pdftex-pdftexini.o pdftex-pdftex0.o pdftex-pdftex-pool.o libpdftex.a 
-L/gnu/store/3snpwk7jl8i125bhiilvk9scqc4mnsx7-libpng-1.6.37/lib 
-L/gnu/store/qx7p7hiq90mi7r78hcr9cyskccy2j4bg-zlib-1.2.11/lib -lpng16 -lz -lz 
-L/gnu/store/18q4r8bpwmpm4w15zipf66l3bvdjzfbs-poppler-0.79.0/lib -lpoppler 
libmd5.a lib/lib.a 
/tmp/guix-build-texlive-bin-20190410.drv-0/build/texk/kpathsea/libkpathsea.la  
-lm
libtool: link: g++ -Wreturn-type -Wno-write-strings -g -O2 -o pdftex 
pdftexdir/pdftex-pdftexextra.o synctexdir/pdftex-synctex.o pdftex-pdftexini.o 
pdftex-pdftex0.o pdftex-pdftex-pool.o  libpdftex.a 
-L/gnu/store/3snpwk7jl8i125bhiilvk9scqc4mnsx7-libpng-1.6.37/lib 
-L/gnu/store/qx7p7hiq90mi7r78hcr9cyskccy2j4bg-zlib-1.2.11/lib 
/gnu/store/3snpwk7jl8i125bhiilvk9scqc4mnsx7-libpng-1.6.37/lib/libpng16.so -lz 
-L/gnu/store/18q4r8bpwmpm4w15zipf66l3bvdjzfbs-poppler-0.79.0/lib -lpoppler 
libmd5.a lib/lib.a 
/tmp/guix-build-texlive-bin-20190410.drv-0/build/texk/kpathsea/.libs/libkpathsea.a
 -lm -Wl,-rpath 
-Wl,/gnu/store/3snpwk7jl8i125bhiilvk9scqc4mnsx7-libpng-1.6.37/lib -Wl,-rpath 
-Wl,/gnu/store/3snpwk7jl8i125bhiilvk9scqc4mnsx7-libpng-1.6.37/lib
ld: libpdftex.a(libpdftex_a-writeimg.o): in function `readimage':
/tmp/guix-build-texlive-bin-20190410.drv-0/build/texk/web2c/../../../texlive-20190410-source/texk/web2c/pdftexdir/writeimg.c:320:
 undefined reference to `read_pdf_info'
ld: libpdftex.a(libpdftex_a-writeimg.o): in function `undumpimagemeta':
/tmp/guix-build-texlive-bin-20190410.drv-0/build/texk/web2c/../../../texlive-20190410-source/texk/web2c/pdftexdir/writeimg.c:546:
 undefined reference to `read_pdf_info'
collect2: error: ld returned 1 exit status

read_pdf_info is defined precisely in the pdftoepdf-poppler*.cc

And using "strings" on libpdftex.a shows that the function name occurs.

Andreas

Re: Profiles/manifests-related command line interface enhancements

[Andreas Enge]

Hello,

I am reading up on old threads during the holiday season...

On Sun, Nov 17, 2019 at 12:30:11PM +0100, Konrad Hinsen wrote:
> If enough people are willing to work on this (beginners included!), we
> could run a "CLI working group" that plays with alternatives to the
> current CLI, implemented as a separate Guile package so it won't perturb
> business as usual. That requires a few people working on implementation,
> and a much larger group willing to test-drive the design(s) and provide
> feedback.

Could we reach out to some experienced UI designers? Is there actually
any such thing as "CLUI designers"?

Andreas

Re: TeX Live 2019 wanted

[Andreas Enge]

I gave it a try, dropped the patches, then the phase use-code-for-new-poppler
fails for texlive-bin; maybe these poppler phases can be dropped, but I am
not quite familiar with them.

Andreas

Re: TeX Live 2019 wanted

[Andreas Enge]

Hello,

On Sat, Dec 14, 2019 at 08:06:19PM +0100, Marius Bakke wrote:
> Ricardo, do you think you'll have time for a TeX Live 2019 update in the
> coming weeks?  If not, could you outline the required changes for
> enterprising Guix contributors?

before your mail I had already tried to update the monolithic texlive, but
one of the patches did not apply any more; since I did not know what they
were for, I pushed it to the back of the queue. From what you write, I
suppose the patches could simply be dropped?

Then I was unsure how updating the texlive sources would impact the
modular texlive packages. Is anything special needed?

Andreas

Re: The Guix Days: stream?

[Andreas Enge]

On Thu, Dec 12, 2019 at 06:57:27PM +0100, zimoun wrote:
> Previously, we discussed on the possibility to video stream chunks of
> these 2 days.

Honestly, I do not think it is a good idea for an "un-conference".
These two days are more devoted to hacking, hands-on activities and
spontaneous working groups, and less for "formal" talks; the latter have
their place in the FOSDEM track.

Andreas

Re: Python package naming: Dots vs hyphens

[Andreas Enge]

Hello,

On Wed, Nov 06, 2019 at 07:49:56AM +0100, pelzflorian (Florian Pelz) wrote:
> Shall I rename python-zope-* to python-zope.*?

the package naming guidelines say "replace underscores by hyphens".
I would extend this to say "replace punctuation marks by (one) hyphen".
Probably when we wrote the paragraph, the case had not presented
itself yet. Similar things are done at least in perl, where the "::"
of the module hierarchy is replaced by "-". Is this case analogous to
python?

Andreas

Re: qt4 packages

[Andreas Enge]

On Mon, Jul 15, 2019 at 09:17:02PM +0300, Efraim Flashner wrote:
> texmacs Debian dropped 2(?) versions ago

I just added it during the Guile/Guix days at Strasbourg, please do not
drop it... Also, it is a GNU project. It may have been removed from Debian
because it depends on guile-1.8; but there is hope they will eventually
move to a more recent version.

Andreas

Re: Cuirass Ghzminutes enhancement idea

[Andreas Enge]

On Fri, Jun 21, 2019 at 05:43:54PM +0200, swedebugia wrote:
>  Maybe we could have an additional time measurement: Ghzminutes.
> E.g. if the build took 60 minutes on a 3 Ghz machine it took 20 Ghzminutes.

180 GHzmin?

Andreas

Re: 01/01: gnu: Add libgd.

[Andreas Enge]

On Thu, Jun 20, 2019 at 12:43:41PM +0200, Nicolas Goaziou wrote:
> But, isn't the project's name libgd?

I would say so. It is the domain name and also the tarball name.
The website starts with a news item:
"The LibGD team is proud to announce the 2.2.5 release of libgd."

But renaming it now looks like a major effort...

Andreas

Re: 01/01: gnu: Add libgd.

[Andreas Enge]

On Thu, Jun 20, 2019 at 11:06:47AM +0200, Ludovic Courtès wrote:
> This library is already available as ‘gd’ in (gnu packages gd).  :-)

Ah, I overlooked it also! Probably because I looked for "libgd" or
"gdlib".

Andreas

Re: 01/01: gnu: Add ratpoints.

[Andreas Enge]

On Thu, Jun 20, 2019 at 11:04:35AM +0200, Ludovic Courtès wrote:
> > +++ b/gnu/packages/patches/ratpoints-sturm_and_rp_private.patch
> Could you add a sentence or two explaining what the patch does and what
> its upstream status is?  This is especially important for non-trivial
> patches like this one.

Nobody knows :-)  The patch appears without further comments in the Sage
build system.

The upstream code has not changed since 2011, something I have been seeing
a lot over the last few days with seemingly abandoned mathematics code, but
which is not dropped since it is still the most efficient implementation
for solving a given problem. Luckily this one is C, the C++ packages often
do not even compile anymore without specific patches from the Sage project.

In this case, there is hope though, from SPKG.txt:
"NOTE: the ratpoints package has been assimilated by PARI/GP. Therefore,
this package (as Sage package) is deprecated. In the future, it will be
removed from Sage."

So maybe we could move it (again, sorry...), to the sagemath module,
with the plan to drop it as soon as Sage does not need it anymore?

Andreas

Re: Difference between Scintilla's license and ISC

[Andreas Enge]

Hello!

I do not get why the license can be free with the non-commercial clause.
What am I misunderstanding?

Andreas

Re: Difference between Scintilla's license and ISC

[Andreas Enge]

Hello,

I think that the Scintilla license is non-free...

On Wed, Jun 19, 2019 at 01:24:15PM +0200, Nicolas Goaziou wrote:
> Permission to use, copy, modify, and distribute this software and
> its documentation for any purpose and without fee is hereby granted,
> 
> and the ISC license is:
> Permission to use, copy, modify, and/or distribute this software for
> any purpose with or without fee is hereby granted,

Notice the lack of the little word "with" in the first license.

Andreas

Re: Packaging Sagemath

[Andreas Enge]

On Tue, Jun 18, 2019 at 01:30:06PM +0200, Andreas Enge wrote:
> We may as well delete the packaged
> items (as I have been doing for two or three I just packaged now), and
> leave only TODO items.

Well, no; I have actually kept packages that I did not yet add to my
preliminary sage recipe, be they available or not. It is just that I have
been packaging "in order", with every new package immediately added to
sage and then deleted from the list.

Andreas

Re: Packaging Sagemath

[Andreas Enge]

On Tue, Jun 18, 2019 at 11:47:29AM +0200, Nicolas Goaziou wrote:
> I followed the link, but, IIUC, it is not up-to-date. For example, we
> already have packaged many of them. Would it be useful to set-up
> a world-writable document (e.g., a pad) somewhere, with a list of the
> packages yet to be packaged, or a checklist with all packages that we
> could tick-off?

Indeed, many of them are already available, this is the list of all
dependencies that we will (probably) have to add to the Sage recipe at
some point. I did not go through it to check which ones we already have.

> For example, here is such an up-to-date list, barring a few FIXME
> I wasn't sure about:

Thanks for the work on the list! As far as I can tell, the web page is
already a world-writable pad; just click on the pencil or the split-page
icons at the top left of the page. We may as well delete the packaged
items (as I have been doing for two or three I just packaged now), and
leave only TODO items.

> I'll try to help when I have time.

Great, I was actually thinking of you when I wrote the message, since
you added a few mathematical software packages already :-)

Andreas

Packaging Sagemath

[Andreas Enge]

Hello,

until Thursday evening, before joining the Guile-Guix-Perl days in
Strasbourg, I am taking part in a coding sprint around packaging Sagemath:
   https://hackmd.io/j5FzB173Q4uaExUw-6Glpg#
My personal goal is to get closer to having Sage in Guix. As usual, I have
started a package definition and am adding dependencies one by one as the
build fails; current status attached. But there is also a list of (altogether
181!) required dependencies, which I extracted here:
   https://hackmd.io/zatG6NwtTWKF5asn_fmcIw?view
So sooner or later we will need all of these packages, and if you feel
motivated to package one or the other we do not have yet, you are more
than welcome!

Andreas

;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2019 Andreas Enge 
;;;
;;; This file is part of GNU Guix.
;;;
;;; GNU Guix 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 Guix 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 Guix.  If not, see <http://www.gnu.org/licenses/>.

(define-module (gnu packages sagemath)
  #:use-module ((guix licenses) #:prefix license:)
  #:use-module (guix build-system gnu)
  #:use-module (guix build-system python)
  #:use-module (guix download)
  #:use-module (guix git-download)
  #:use-module (guix packages)
  #:use-module (gnu packages algebra)
  #:use-module (gnu packages autotools)
  #:use-module (gnu packages bdw-gc)
  #:use-module (gnu packages boost)
  #:use-module (gnu packages compression)
  #:use-module (gnu packages graph)
  #:use-module (gnu packages lisp)
  #:use-module (gnu packages maths)
  #:use-module (gnu packages multiprecision)
  #:use-module (gnu packages pkg-config)
  #:use-module (gnu packages python)
  #:use-module (gnu packages python-xyz))


(define-public python-cypari2
  (package
(name "python-cypari2")
(version "2.1.1")
(source
 (origin
   (method url-fetch)
   (uri (pypi-uri "cypari2" version))
   (sha256
(base32
 "1nwkzgqvbw6361x0rpggy1q5nx663fswhpvg8md6xhqyfwpgc7nz"
(build-system python-build-system)
(native-inputs
 `(("python-cython" ,python-cython)))
(propagated-inputs
 `(("python-cysignals" ,python-cysignals)))
(inputs
 `(("gmp" ,gmp)
   ("pari-gp", pari-gp)))
(home-page "https://cypari2.readthedocs.io/;)
(synopsis
 "Python interface to the number theory library libpari")
(description
 "Cypari2 provides a Python interface to the number theory library
PARI/GP.  It has been spun off from the SageMath mathematics software system,
but it can be used independently.")
(license license:gpl2+)))

(define-public python2-cypari2
  (package-with-python2 python-cypari2))

;; The stable version of the following package is not young enough to be
;; used with Sage, since it does not support cython. One would need to
;; use an alpha release. On the other hand, Sage can be built without it.
(define-public python-gmpy2
  (package
(name "python-gmpy2")
(version "2.0.8")
(source (origin
  (method url-fetch)
  (uri (pypi-uri "gmpy2" version ".zip"))
  (sha256
   (base32
"0grx6zmi99iaslm07w6c2aqpnmbkgrxcqjrqpfq223xri0r3w8yx"
(build-system python-build-system)
(native-inputs
 `(("unzip" ,unzip)))
(inputs
 `(("gmp" ,gmp)
   ("mpfr" ,mpfr)
   ("mpc" ,mpc)))
(home-page "https://github.com/aleaxit/gmpy;)
(synopsis
 "GMP/MPIR, MPFR, and MPC interface to Python 2.6+ and 3.x")
(description
 "This package provides a Python interface to the GNU multiprecision
libraries GMO, MPFR and MPC.")
(license license:lgpl3+)))

(define-public python2-gmpy2
  (package-with-python2 python-gmpy2))

(define-public cliquer
  (package
(name "cliquer")
(version "1.21")
;; The original source package is available from the home page and
;; has not seen any release since 2010; it comes with only a Makefile
;; without an "install" target. Instead, there is an autotoolized
;; tarball available from the Sage project.
(source
 (origin
   (method url-fetch)
   (uri "http://users.ox.ac.uk/~coml0531/sage/cliquer-1.21.tar.gz;)
   (sha256
(base32
 "1hdzrmrx0nvvj8kbwxrs8swqgkd284khz

Re: Digimend kernel drivers for Guix

[Andreas Enge]

Hello Tobias,

you do not like false things, do you?

On Tue, May 28, 2019 at 08:33:29PM +0200, Tobias Geerinckx-Rice wrote:
> Tobias Geerinckx-Rice wrote:
> > However, in this case, please use the even simpler:
> >  (arguments
> >   '(#:tests?)); no test suite
> 
> Not sure what went wrong here, but this should obviously be:
>  (arguments
>   '(#:tests?)); no test suite

  (arguments
   '(#:tests? #f)); no test suite

Andreas

Re: guile-bash updated source url

[Andreas Enge]

Hello,

On Sun, Apr 28, 2019 at 10:28:43AM +0200, david.lars...@selfhosted.xyz wrote:
> This is my first contribution to guix and it's just a minor fix for
> the guile-bash package which had an outdated source url. I was able to
> retrieve the same revision of the package via the software-heritage
> project's website and upload it to gitlab. Then I installed it
> successfully via guix package -f my-guile-bash.scm using the gitlab url,
> then copied it to the existing guile-xyz.scm in gnu/packages.
> I have attached a patch-file with the changes.

should the package not be retrieved automatically from Software Heritage
with the newest Guix API? And apart from that, will it be desirable to keep
around an unmaintained software for which the source has disappeared?

Andreas

Re: Error building linux-libre on Overdrive 1000

[Andreas Enge]

On Tue, Apr 09, 2019 at 04:37:09PM +0200, Tobias Geerinckx-Rice wrote:
> ‘guix system init’ fails for me in the following way on the following
> version:
> 
>  $ guix describe
>  Generation 4Apr 08 2019 23:29:08(current)
> guix 2afb793
> repository URL: https://git.savannah.gnu.org/git/guix.git
> branch: master
> commit: 2afb79392d39df05e5b285ea46dd59eafb0616d8
> 
> I'd attach the system configuration, but it's basically the one from
> guix-maintenance/hydra/overdrive.scm.  There's nothing custom about the
> kernel.

I confirm after just trying to reconfigure, with commit
36dbad3858ca4229e9ec319bd4983fca7835067d.
Cc-ing the bug tracker.

Andreas

Re: 05/15: gnu: wesnoth: Rename package to the-battle-for-wesnoth.

[Andreas Enge]

On Fri, Mar 29, 2019 at 03:02:00PM +0100, Tobias Geerinckx-Rice wrote:
> I still think this change should be reverted

I also think so.

The wording in the naming guidelines is intentionally a bit vague;
the intention was definitely to take in general the tarball name, or maybe
if this does not fit the domain name or something "similarly canonical".
The tarball name does not always work, for instance in cases where it is
"v0.15.zip". So we cannot have a strict rule, but the idea was to take the
"canonical short name". When writing the section, I did not expect this
part to lead to controversies; the real question was how to handle special
characters (lowercase, replace underscores with dashes), and what to do
for (at the time) python packages.

I am happy to make the wording clearer. But I am not sure whether replacing
"project name" by "package name" makes a difference. What is a "package"?
But if you think it is better, why not.

We could also add "short" in front of "projet"/"package name", and maybe
add that this usually corresponds to something like the base name of the
tarball, the git repository name or the domain where the project is hosted.

What do you think?

Andreas

Re: 06/15: gnu: wesnoth-server: Rename package to the-battle-for-wesnoth-server.

[Andreas Enge]

Hello,

On Tue, Mar 26, 2019 at 04:32:46PM +0100, Pierre Neidhardt wrote:
> Sorry, I misunderstood the conclusion of the discussion: I thought that
> we would simply follow the package naming convention as per the manual.

I am confused about this statement. The naming convention speaks a bit
vaguely of "project name chosen upstream"; very often, this means the
tarball name. Now there is www.wesnoth.org, which distributes tarballs and
executable files called wesnoth.*. So I would argue that the upstream
name is "wesnoth" and would suggest to revert this change.

This is in a similar spirit to "gcc" for instance; we do not call it
"gnu-compiler-collection" either, although this is the long name used
on their project web page.

Andreas

Re: bug#25970: mozjs build failure

[Andreas Enge]

Hello,

On Mon, Feb 04, 2019 at 11:27:05PM +0100, Leo Famulari wrote:
> The package in question, mozjs 24, is no longer used by gnome-shell, or
> by any other Guix package.
> 
> So, if it still fails to build, we can consider removing it.

the package builds, but I see no need to keep it. Do you agree to remove
it together with mozjs@17? The latter would require a little work, since
all other mozjs packages inherit from it. If there is consensus, I can
look into it.

Andreas

Re: Eliminate environment variable hints?

[Andreas Enge]

Hello,

On Tue, Feb 19, 2019 at 08:41:47AM +0100, Ricardo Wurmus wrote:
> This only needs to be done when GUIX_PROFILE is not set.  The
> definitions in etc/profile either reference /gnu/store directories
> directly (when GUIX_PROFILE is not set) or they reference the profile
> links (when GUIX_PROFILE is set).

that is an interesting point, thanks a lot for explaining it! So I think
that the best advice the command could give would be both to set GUIX_PROFILE
and to source etc/profile.

Andreas

Re: Eliminate environment variable hints?

[Andreas Enge]

Hello,

On Mon, Feb 18, 2019 at 10:56:13PM +0100, Ricardo Wurmus wrote:
> when installing a package into a profile Guix very helpfully tells you
> that you may need to set certain environment variables.  It doesn’t tell
> you that these environment variables can also be set by source’ing the
> generated etc/profile file.

something I noticed is that I see these recommendations also when the
environment variables are already set, precisely by sourcing the (previous)
$HOME/.guix-profile/etc/profile. Now the profile changed, so they need to
be re-sourced (which I usually do by calling "bash" from bash, since I source
from the .bashrc).

On the other hand, using the recommended environment variables would survive
profile changes, since they look like
   export 
PATH="/home/andreas/.guix-profile/bin:/home/andreas/.guix-profile/sbin${PATH:+:}$PATH"
instead of pointing to /gnu/store/...-profile/bin with a particular hash.

So the two are clearly not equivalent. Which of them is actually
preferable? I find it a bit confusing that after running
"guix package -i hello" I cannot run "hello" immediately, unlike in
Debian.

I would not be too worried about bash vs. other shells: The current
suggestions already would not work in csh...

Andreas

Re: Policy to remove obsolete packages

[Andreas Enge]

On Mon, Feb 04, 2019 at 12:16:12PM +0100, Björn Höfling wrote:
> If a package is broken for more than 6 months, we should just remove it
> from Guix. Prior to removing, we should announce on the dev mailing
> list, maybe someone will care about it then. If there is no response
> within 2 weeks, we really remove it.

We were both in the talk and had the same reaction, so indeed I agree.

Andreas

Re: Meeting in Brussels on Wednesday evening?

[Andreas Enge]

On Tue, Jan 29, 2019 at 10:52:18AM +0100, Ludovic Courtès wrote:
> I’d be available tomorrow (Wed. 30th) at around 8PM in Brussels.
> Would anyone be willing to join for a drink + dinner?
> We could meet at “Au Bon vieux temps”¹ (it’s a must!) and then head to a
> neighboring restaurant.

Sorry for polluting the mailing list with a personal request:
I will arrive in Brussels at 21:47 and stay at ICAB.

Could someone also staying at ICAB and joining the group pick up my keys,
and give them to me later at the restaurant?

Please contact me privately,

Andreas

Re: Guix Days starting in two days!

[Andreas Enge]

On Tue, Jan 29, 2019 at 10:58:24AM +0100, Ludovic Courtès wrote:
> We’ll update  as
> needed to share practical info.  Please email Pjotr, Manolis, Ricardo,
> or myself if you have any questions.

And since we need to book food now, please tell us if you are mentioned
on the wiki page, but finally will not attend; or vice versa.

Andreas

Re: Changes in the spending committee for the FSF Fund

[Andreas Enge]

Hello,

On Fri, Jan 25, 2019 at 11:57:21PM +0100, Ludovic Courtès wrote:
> There’s a ledger for the Guix Europe non-profit¹, which is a separate
> entity, but most of the transactions on the funds held at the FSF have
> been made via Guix Europe.

And the decisions of the Solidary Administrative Council are also made public:
   
https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/guix-europe/minutes

>From the beginning, it has been our aim to be as open as possible about
our activities.

Andreas

Re: bug#33676: GuixSD on eoma68-a20?

[Andreas Enge]

On Sat, Dec 15, 2018 at 02:04:58PM -0500, Mark H Weaver wrote:
> >> See also 
> >> https://blog.merovius.de/2013/10/20/ext4-mysterious-no-space-left-on.html
> > It was, and I disabled it. Hopefully this does not break anything...
> Why did you disable it?

Because we get exactly these spurious ENOSPC mentioned in the blog post
on bayfront when the disk is only one third full.

Now I am happy to try out any other combination of flags that solves the
problem.

So should I add dir_index again (is this possible live?), and then
add large_dir?

Andreas

Re: bug#33676: GuixSD on eoma68-a20?

[Andreas Enge]

On Fri, Dec 14, 2018 at 09:50:26PM +0100, Danny Milosavljevic wrote:
> can you check whether dirindex (hashtables for directory) is enabled?
> # tune2fs -l /dev/... | grep -o dir_index
> See also 
> https://blog.merovius.de/2013/10/20/ext4-mysterious-no-space-left-on.html

It was, and I disabled it. Hopefully this does not break anything...
But does this not mean a big performance hit on /gnu/store/.links?

Andreas

Re: GuixSD on AArch64

[Andreas Enge]

Hello Vagrant,

On Mon, Oct 22, 2018 at 12:17:58PM -0700, Vagrant Cascadian wrote:
> Looking like u-boot 2019.01 might be more likely, but modest patches
> work with 2018.11-rc2. I'll probably bring the pinebook with me to the
> Paris meetup in December... though with only 2GB of ram it might not
> make the most exciting GuixSD system... :)

did you come to the meeting, and did you manage to install GuixSD
on your Pinebook?

Andreas

Re: End of beta soon? drop i686?

[Andreas Enge]

On Wed, Dec 12, 2018 at 03:16:56AM +0100, Ricardo Wurmus wrote:
> > I'm opposed to dropping i686 support.  If we dropped support for systems
> > that are not well supported in Guix, the only system left standing would
> > be x86_64-linux.  I believe it is of paramount importance that Guix be
> > portable to multiple processor architectures.  Even if we are not yet
> > able to provide a good user experience on other systems, we can still
> > keep the bulk of our code portable and multi-architecture aware.
> 
> I whole-heartedly agree with Mark.  We will not drop i686 support.

And a big advantage of i686, even if noone were to use it anymore, is that
we have a large build farm capacity, since it is built on the x86_64 machines.
So it can act as our "canary in the mine", warning of portability problems.

Andreas

Re: bug#33676: GuixSD on eoma68-a20?

[Andreas Enge]

Hello Danny,

On Mon, Dec 10, 2018 at 11:30:14AM +0100, Danny Milosavljevic wrote:
> I've tried it now and I get:
> dannym@bayfront ~/src/guix$ ./pre-inst-env guix system disk-image 
> --system=armhf-linux gnu/system/install.scm
> ...
> importing file or directory 
> '/gnu/store/3qrkj5zqmhnkr953xznmy96fq8i55ia5-glibc-b
> ootstrap-0'...
> found valid signature for 
> '/gnu/store/3qrkj5zqmhnkr953xznmy96fq8i55ia5-glibc-boo
> tstrap-0'
> guix offload: error: link: No space left on device

this is the mysterious error message we have seen before: There is still
plenty of space on all the machines! I think it was related to an ext4
limitation on the number of files, or the number of files inside a single
directory. I ran some garbage collection on bayfront, and it can now offload
and retrieve builds again. Please give it another try!

Andreas

Re: bug#33676: GuixSD on eoma68-a20?

[Andreas Enge]

Hello Danny,

On Sat, Dec 08, 2018 at 06:12:14PM +0100, Danny Milosavljevic wrote:
> Guix received one but we have so far be unable to get the GuixSD flash
> image because something always breaks on Hydra before it's done

although the problem seems to lie somewhere else, I would just like to
point out that you can use your account on bayfront to build things for
arm as well - it offloads to the redhill machine. Notice, however, that
this is a single machine building everything from source without using
the hydra or berlin build farms for substitutes.

I can also give you a direct login on redhill if you need it.

Andreas

Re: [bug#33600] [PATCH 0/3] Defaulting to ci.guix.info (aka. berlin.guixsd.org)

[Andreas Enge]

On Tue, Dec 04, 2018 at 11:28:51AM +0100, Ludovic Courtès wrote:
> Awesome.  I’ve added a file to record that info in
> guix-maintenance.git.  Please feel free to complete it; for instance
> it’d be good to know the expiration date of each domain.

Done for guixsd.org. It expires on January 27. I would be okay to let it
run out if guix.info is sufficiently marketed in the meantime.

Andreas

Re: [bug#33600] [PATCH 0/3] Defaulting to ci.guix.info (aka. berlin.guixsd.org)

[Andreas Enge]

On Tue, Dec 04, 2018 at 10:03:01AM +0100, Ludovic Courtès wrote:
> As for guixsd.org, it was initially owned by Andreas Enge who
> transferred it to Guix Europe and also provided credentials to me and I
> think a couple of other people, though I forgot who.  Andreas?

Apart from you, to Ricardo Wurmus, Christopher Baines and Manolis Ragkousis.
I am of course happy to share the credentials with more people from the
Guix sysadmin group.

Andreas

Re: [bug#33600] [PATCH 0/3] Defaulting to ci.guix.info (aka. berlin.guixsd.org)

[Andreas Enge]

On Mon, Dec 03, 2018 at 06:44:43PM -0500, Mark H Weaver wrote:
> Who owns the guix.info domain?  Also, who owns the guixsd.org domain?

guixsd.org is owned by the Guix Europe association. guix.info, as far as
I know, by Ricardo. Plans are to drop guixsd.org in the long run, and I
would suggest to transfer guix.info to Guix Europe at the next renewal.

Andreas

Re: mips64el machine - mrustc

[Andreas Enge]

Hello Danny,

I have a mips64 machine (the mini-pc desktop version of Mark's laptop,
with only one core). It is excruciatingly slow (if I remember well, just
compiling guix takes a few hours) and makes a tractor like noise, so I
turned it off and moved it to my closet. But I could take it out again
and try to let it run during the day when I am not there, and see if
I manage to upgrade Guix on it.

Andreas

Re: FSDG status of chromium

[Andreas Enge]

Hello,

On Tue, Sep 25, 2018 at 09:08:42PM +0200, Marius Bakke wrote:
> That leaves "first party" source files.  Admittedly I haven't audited
> all of those other than superficial grepping.  Do you know whether parts
> of Chromium are considered non-free?  I noticed a number of files are
> missing license information: in those cases I have assumed that the
> top-level "LICENSE" file (BSD-3) applies.

Debian has a package "chromium-browser" in the free section:
   https://tracker.debian.org/pkg/chromium-browser

So at least it is apparently possible to get a working binary with only
free sources.

Andreas

Re: What ARM hardware should we buy and where should we host it?

[Andreas Enge]

On Fri, Sep 14, 2018 at 11:37:25PM +0200, Ricardo Wurmus wrote:
> Thanks for sharing this.  In my opinion, it would be good if we could
> increase the number of build machines first before we allow too much of
> the funds to be regularly consumed by hosting costs.

Indeed, I just mentioned it to give a data point, and would personally
prefer to spread out hosting for free inside the community.

Andreas

Re: Blog: Guix packaging tutorial

[Andreas Enge]

Hello Pierre,

nice idea! I agree with Ricardo's suggestions.

You could have a look at the slides of a talk I gave at GHM 2013 in the
"maintenance" git repo, inside the talks/ghm-2013/andreas directory.
Some things are outdated (we did not have the macros to manipulate build
phases yet).

There I start actually from an even more basic view point, since the
target audience was people not knowing Scheme at all: first, a few basic
notions of Scheme (quoting and unqoting is needed all the time); then
how to modify an existing package without inputs using gnu-build-system;
then how to handle inputs; and so on.

Andreas

Re: What ARM hardware should we buy and where should we host it?

[Andreas Enge]

Hello,

On Mon, Sep 03, 2018 at 01:37:54PM +0200, Ricardo Wurmus wrote:
> The first question is what ARM hardware to buy; the second is where to
> host that hardware.  Here are some considerations:

concerning hosting, I could easily host one smaller machine (like the
Overdrive 1000) in my living room, Tobias has stepped up, and I suppose
other members of the Guix community could do so as well. So we would end
up with a somewhat distributed effort, which would be nice for resilience
and spreading system administration load. Currently the web page for
the Overdrive 1000 mentions 26 available units for 600U US$ plus shipping
and tax. The Overdrive 3000 is out of stock.

For more centralised options, we could host machines at Aquilenet; in
addition to the rack in the datacentre where they host bayfront, they
just opened a "free form hosting option". Prices are here:
   https://atelier.aquilenet.fr/projects/services/wiki/Hergementlibre/7/diff
Prices are more or less proportional to electricity consumption; they state
that for 30W on average we would need to pay 20€/month. Over a few years
of lifetime this would add up quite considerably, compared to the distributed
solution.

Andreas

Re: FOSDEM 2019 - stand

[Andreas Enge]

I will probably attend FOSDEM again, and if I do, then I would
like to spend a slot at the stall.

On Sun, Sep 09, 2018 at 03:13:57PM +0200, Tonton wrote:
> I have some stickers [1]; I might
> get more of the same, but slightly bigger. I'll bring what I have - if I can.

We should be able to sponsor stickers through Guix Europe.

Andreas

Re: Guix on aarch64

[Andreas Enge]

Hello,

On Tue, Aug 28, 2018 at 09:57:49AM +0200, Ricardo Wurmus wrote:
> I can remove one of the build machines from Berlin.

would this not aggravate the problem with the availability of substitutes?
As I understand it, then we would have two separate machines, each of
which would build the same packages; and if two machines are not enough
to keep up with the pace of development, with only one things should become
even worse. So if we move machines, maybe we should move both of them for a
little while, until the proposed changes to cuirass and the berlin storage
architecture are implemented?

Or would it make sense to instead disable automatic evaluation of the aarch64
derivations, and to only start them manually for "important" commits?

Andreas

Re: RFC: Portability should be a higher priority for Guix (was Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.)

[Andreas Enge]

Hello,

On Thu, Jul 05, 2018 at 11:04:31AM +0200, Jonathan Brielmaier wrote:
> I just want to bring POWER up as a freedom-respecting architecture.
> Especially the TalosII from RaptorCS[0]. I know that guix does not work
> on ppc64le yet, but I'm working for it :) They tend to be quite
> expensive, but you get a decent performance on compiling and packing[1].

this is indeed an exciting architecture. Vikings had a machine on display
at their FOSDEM table earlier this year. But the price is still quite
steep, if you know anybody who would sponsor a machine...

Andreas

Re: RFC: Portability should be a higher priority for Guix (was Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.)

[Andreas Enge]

Hello all,

of course I can all but agree that support for "exotic" hardware is very
desirable, especially since, as Mark pointed out, we would like it to become
more mainstream!

On Thu, Jul 05, 2018 at 08:38:19AM +0200, Ricardo Wurmus wrote:
> One thing that would help, in my opinion, is to purchase hardware and
> make it available to interested developers and/or join these new
> machines to the build farm.

If people want to look at armhf, one of the donated Novena boards is currently
running in my living room, under the name of redhill.guixsd.org. I could
of course create accounts for Guix developers who want to have access to
debug the architecture.

Andreas

Re: a92d97266 seems to break master

[Andreas Enge]

Hello,

On Tue, May 22, 2018 at 12:56:55AM +0800, Alex Vong wrote:
> a92d97266dffcd1ab5c40a379005a7db1fc3dad4 seems to breaks master with the
> following error:
> make[2]: *** No rule to make target 'gnu/packages/patches/pius.patch', needed 
> by 'all-am'.  Stop.

apologies, my mistake! I forgot that "git commit -a" is not enough when
adding a new file. Too long since I added patches!

This is corrected in the last commit, thanks a lot for your quick reaction.

Andreas

Re: Shepherd release!

[Andreas Enge]

On Mon, Mar 19, 2018 at 05:42:11PM +0100, Ludovic Courtès wrote:
> You probably need to run ‘gettextize’ first.

That is strange, why have I never heard about this command before?
Anyway, I tried, and it shows a lot of scary warnings:

...
Updating Makefile.am (backup is in Makefile.am~)
Updating configure.ac (backup is in configure.ac~)
Adding an entry to ChangeLog (backup is in ChangeLog~)

Please update po/Makevars so that it defines all the variables mentioned
in po/Makevars.template.
You can then remove po/Makevars.template.

Please run 'aclocal -I m4' to regenerate the aclocal.m4 file.
You need aclocal from GNU automake 1.9 (or newer) to do this.
Then run 'autoconf' to regenerate the configure file.

You might also want to copy the convenience header file gettext.h
from the 
/gnu/store/xd2ifxzy0wah00b4pj83djsqaw03793x-gettext-0.19.8.1/share/gettext 
directory into your package.
It is a wrapper around  that implements the configure --disable-nls
option.

Press Return to acknowledge the previous three paragraphs.


Then I just went ahead and did "autoreconf -vfi", but this yielded the
following error message:

autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
configure.ac:86: error: `po/Makefile.in' is already registered with 
AC_CONFIG_FILES.
../../lib/autoconf/status.m4:288: AC_CONFIG_FILES is expanded from...
configure.ac:86: the top level
autom4te: /gnu/store/mqjjsvkvpbgp9ykmi9jcylzw44qk1hr4-m4-1.4.18/bin/m4 failed 
with exit status: 1
aclocal: error: echo failed with exit status: 1
autoreconf: aclocal failed with exit status: 1


Maybe I should follow the advice in the above "three paragraphs"?

$ aclocal -I m4
configure.ac:86: error: `po/Makefile.in' is already registered with 
AC_CONFIG_FILES.
../../lib/autoconf/status.m4:288: AC_CONFIG_FILES is expanded from...
configure.ac:86: the top level
autom4te: /gnu/store/mqjjsvkvpbgp9ykmi9jcylzw44qk1hr4-m4-1.4.18/bin/m4 failed 
with exit status: 1
aclocal: error: echo failed with exit status: 1


This looks like the previous analysis by David Pirotte:

On Fri, Mar 16, 2018 at 11:47:24PM -0300, David Pirotte wrote:
> Here there are two problems:
>
> 1-the configure.ac has a tipo
>
>   line 86, it has '... po/Makefile.in'
>   but it should be '... po/Makefile'
>
> 2-the po subdir does not have a Makefile.in


Andreas

Re: Shepherd release!

[Andreas Enge]

Hello!

On Fri, Mar 16, 2018 at 01:44:37PM +0100, Ludovic Courtès wrote:
> For the record, it can be tested on GuixSD by running “make dist” in the
> Shepherd and then applying a patch like this in Guix:

I am already failing in getting the shepherd configured. On a fresh git
checkout, I do
   autoreconf -vfi
and obtain the following:

autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
aclocal: warning: couldn't open directory 'm4': No such file or directory
autoreconf: configure.ac: tracing
autoreconf: configure.ac: AM_GNU_GETTEXT is used, but not AM_GNU_GETTEXT_VERSION
autoreconf: configure.ac: not using Libtool
autoreconf: running: 
/gnu/store/lpic7aaifz4v2ih54sqgwn82p13zrjrh-autoconf-2.69/bin/autoconf --force
autoreconf: configure.ac: not using Autoheader
autoreconf: running: automake --add-missing --copy --force-missing
configure.ac:17: error: required file 'build-aux/config.rpath' not found
configure.ac:17: error: required file './ABOUT-NLS' not found
autoreconf: automake failed with exit status: 1

This happens with the most recent automake-1.16.1 from Guix, but also with
the previously installed 1.15.1.

To test my luck, I did a "touch" on these two files; then ./configure fails
with the following:

...
checking  constants... done
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: error: cannot find input file: `po/Makefile.in.in'

Did I forget to execute anything else?

Andreas

Re: Language tag for traditional Chinese

[Andreas Enge]

Hello,

On Tue, Mar 06, 2018 at 08:35:46PM +0800, Alex Vong wrote:
> I also want to add tranditional Chinese translation to guix in the
> future (after I figure out how to use handwriting recognition). I think
> I will still use the zh_TW since I think it is an established convention
> for distro. But I am not sure if the same convention holds for web
> page.

if you look at the web page of the Translation Project, the two Chinese
language codes seem to be zh_CN and zh_TW:
   https://translationproject.org/team/index.html
There is also zh_HK, but no translation team is referenced for it.

Andreas

Re: 0.14.1?

[Andreas Enge]

On Mon, Mar 05, 2018 at 06:07:07PM +0100, Ricardo Wurmus wrote:
> Now that so much time has passed and so many packages have been added
> and updated we could even do 0.15.0.

This should be one of the few pleasures of the release managers,
to decide about version numbers and code names!

Andreas

Re: 0.14.1?

[Andreas Enge]

On Mon, Mar 05, 2018 at 10:41:34AM +0100, Ludovic Courtès wrote:
> I would like to add the new Shepherd as well, which should be ready
> anytime soon.

It would be important to fix bug
   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30299
first, and maybe other shepherd related bugs in the tracker.

Andreas

Re: Nginx service fails

[Andreas Enge]

Hello,

On Mon, Mar 05, 2018 at 12:43:35AM +0100, Andreas Enge wrote:
> $ guix system reconfigure AE/clementi.scm
> guix system: error: failed to load 'AE/clementi.scm':
> AE/clementi.scm:5:0: In procedure allocate-struct: Wrong type argument in 
> position 2: 25

I think I know the answer: .cache contains the compiled file for the operating
system declaration (clementi.go), and with the recent changes to how these are
parsed, it is incompatible.

> Is this normal? How are users supposed to know they should delete .cache?

Hopefully, this does not occur with "guix pull", and then it might be
considered normal... Is .cache actually necessary, since we generally
recompile from make files? Or is it needed since the make files do not
encode the precise dependency graph of the modules, as they usually do
for C code? If it is not necessary, could it be disabled by the project?

Andreas

Re: bug#30706: Nginx service fails

[Andreas Enge]

On Mon, Mar 05, 2018 at 08:23:18AM +0100, Ricardo Wurmus wrote:
> I had the same error when updating my i686 netbook after a long while.
> After a reboot everything seemed to be fine, though.

Ah, thanks for the information! A reboot made things worse in my case -
I rebooted the virtual machine, and now I cannot ssh into it any more.
So it looks like I will have to set it up from scratch again...

In my case, the problem occurred between February 28 and March 4.

Andreas

Re: Nginx service fails

[Andreas Enge]

PS: I rebooted the virtual machine, and now it looks as if even the
openssh service did not start:
... port 22: Connection refused
:-(

Re: Nginx service fails

[Andreas Enge]

Hello Danny,

thanks for your quick reply!

On Mon, Mar 05, 2018 at 12:07:44AM +0100, Danny Milosavljevic wrote:
> find-long-options is supposed to be in gnu/build/linux-boot.scm and
> gnu/services/base.scm is using it.
> 
> It's in there for some weeks now...
> 
> You can find out where guix is by:
> readlink $(which guix)
> and then examine the scm files there...

It should not matter, since I am using "./pre-inst-env" in a current
git checkout. But "guix --version" is at 0.14.0-9.bdf0c64, which also
has find-long-options. I did a successful reconfigure on February 28.

Trying to use the old guix (without ./pre-inst-env), I am also running
into trouble:
$ guix system reconfigure AE/clementi.scm
guix system: error: failed to load 'AE/clementi.scm':
AE/clementi.scm:5:0: In procedure allocate-struct: Wrong type argument in 
position 2: 25

The configuration file looks like this:
(use-modules (gnu))
(use-service-modules networking ssh web)
(use-package-modules screen ssh vim)

(operating-system
  (host-name "clementi")

So line 5 is "operating-system". I think there is a problem with caching
somewhere:
$ rm -rf ~/.cache
$ guix system reconfigure AE/clementi.scm
Now things happen. (But they hang when contacting the substitute server.)

It has also bitten me in the other direction:
When I run "guix system reconfigure...", press "Ctrl-C" immediately, and then
run "./pre-inst-env guix system reconfigure...", I get almost the same message:
guix system: error: failed to load 'AE/clementi.scm':
/home/andreas/guix/AE/clementi.scm:5:0: In procedure allocate-struct: Wrong 
type argument in position 2: 24

Is this normal? How are users supposed to know they should delete .cache?
And when is this actually necessary?

Andreas

Re: Nginx service fails

[Andreas Enge]

Well, I am turning this into a bug report, since it still occurs with
the latest git commit ac1a9ce8b07f3b80900ee08436ff6e683e8dc195 .

This is the result of "./pre-inst-env guix system reconfigure ...",
where "..." is my configuration file:

...
creating nginx log directory '/var/log/nginx'
creating nginx run directory '/var/run/nginx'
creating nginx temp directories 
'/var/run/nginx/{client_body,proxy,fastcgi,uwsgi,scgi}_temp'
nginx: [alert] could not open error log file: open() 
"/gnu/store/pp71iff1qxwhh82vm34g18h9kmn0xrg5-nginx-1.13.9/logs/error.log" 
failed (2: No such file or directory)
nginx: the configuration file 
/gnu/store/5ixkryw6jl32cm6d1g9jb8dm9rbz8csc-nginx.conf syntax is ok
nginx: configuration file 
/gnu/store/5ixkryw6jl32cm6d1g9jb8dm9rbz8csc-nginx.conf test is successful
`/gnu/store/zchh8s3r1bbmia3zfxsyhsz3c4b9fmps-openssh-authorized-keys/root' -> 
`/etc/ssh/authorized_keys.d/root'
`/gnu/store/zchh8s3r1bbmia3zfxsyhsz3c4b9fmps-openssh-authorized-keys/andreas' 
-> `/etc/ssh/authorized_keys.d/andreas'
guix system: loading new services: user-homes term-auto nginx...
shepherd: Evaluating user expression (register-services (primitive-load 
"/gnu/st?") ?).
guix system: error: exception caught while executing 'eval' on service 'root':
find-long-options: unbound variable
Installing for i386-pc platform.
/gnu/store/1dnbfda2p1bxwyl0rcm96ka9pmi0wb88-grub-2.02/sbin/grub-install: 
warning: disk does not exist, so falling back to partition device /dev/xvda2.
/gnu/store/1dnbfda2p1bxwyl0rcm96ka9pmi0wb88-grub-2.02/sbin/grub-install: 
warning: disk does not exist, so falling back to partition device /dev/xvda2.
/gnu/store/1dnbfda2p1bxwyl0rcm96ka9pmi0wb88-grub-2.02/sbin/grub-install: 
warning: disk does not exist, so falling back to partition device /dev/xvda2.
/gnu/store/1dnbfda2p1bxwyl0rcm96ka9pmi0wb88-grub-2.02/sbin/grub-install: error: 
cannot find a GRUB drive for /dev/sda.  Check your device.map.
guix system: error: failed to install bootloader 
/gnu/store/9iv63jm07klxvrr4fpwv6q5vpnca13ja-bootloader-installer

The final error is "normal", since I am installing in a Xen virtual machine,
where /dev/sda does not exist; it did not matter before.
The real error occurs above, the "uncaught exception".

But:
# herd status nginx
herd: service 'nginx' could not be found

Then I do a
# ./pre-inst-env guix system roll-back
# herd status nginx
herd: service 'nginx' could not be found

Otherwise said, I can go back, but my previously running web server has
definitely gone! How do I get it back?

Andreas

Nginx service fails

[Andreas Enge]

Hello,

writing to guix-devel first, since I am not sure whether I should file
a bug report. When reconfiguring my virtual machine today after I had
added a virtual host to nginx, it failed with the following error message:

...
creating nginx log directory '/var/log/nginx'
creating nginx run directory '/var/run/nginx'
creating nginx temp directories 
'/var/run/nginx/{client_body,proxy,fastcgi,uwsgi,scgi}_temp'
nginx: [alert] could not open error log file: open() 
"/gnu/store/pp71iff1qxwhh82vm34g18h9kmn0xrg5-nginx-1.13.9/logs/error.log" 
failed (2: No such file or directory)
nginx: the configuration file 
/gnu/store/5ixkryw6jl32cm6d1g9jb8dm9rbz8csc-nginx.conf syntax is ok
nginx: configuration file 
/gnu/store/5ixkryw6jl32cm6d1g9jb8dm9rbz8csc-nginx.conf test is successful
`/gnu/store/zchh8s3r1bbmia3zfxsyhsz3c4b9fmps-openssh-authorized-keys/root' -> 
`/etc/ssh/authorized_keys.d/root'
`/gnu/store/zchh8s3r1bbmia3zfxsyhsz3c4b9fmps-openssh-authorized-keys/andreas' 
-> `/etc/ssh/authorized_keys.d/andreas'
guix system: loading new services: user-homes term-auto nginx...
shepherd: Evaluating user expression (register-services (primitive-load 
"/gnu/st?") ?).
guix system: error: exception caught while executing 'eval' on service 'root':
find-long-options: unbound variable

And then the nginx service had disappeared. Even "guix system roll-back"
did not bring it back.

Since then I am trying to recompile a more recent git checkout, so I can
probably not reproduce the problem. But does it ring a bell?

Andreas

Re: Posts in languages other than English on help-guix?

[Andreas Enge]

On Fri, Mar 02, 2018 at 08:31:36PM +, ng0 wrote:
> To not pick the generischer Maskulinum (which would be contrary the rest of 
> our
> Documentation guidelines)

Indeed, it is difficult to write grammatically and syntactically correct,
pleasant to read, gender neutral German! I am not a fan of these strange new
constructions that encapsulate both the male and female form into one word
with the help of interpunctuation in the middle of the word.

So here is a new trial, translating more freely, and hopefully satisfying
all requirements:

("de"
 "Melden Sie sich bei der „Help“-Mailingliste an, um per E-Mail
gemeinschaftlichen Rat zu GuixSD und Guix zu bekommen.  Sie können
Nachrichten auch auf deutsch verfassen.")

What do you think?

Andreas

Re: Posts in languages other than English on help-guix?

[Andreas Enge]

On Fri, Mar 02, 2018 at 04:47:45PM +, ng0 wrote:
> On topic: I think it's too much to suggest to include something that indicates
> the language of the post in the subject?

I think people will easily recognise languages they speak in a post!

Andreas

Re: Posts in languages other than English on help-guix?

[Andreas Enge]

Hello!

On Fri, Mar 02, 2018 at 05:02:40PM +0100, Ludovic Courtès wrote:
> What about allowing posts on help-guix in one of the languages that
> regular contributors know, in addition to English?

That sounds like a good idea. However, in the text, I would still say that
English is the preferred language, or the language in which one is most
likely to get a useful reply.

> The alternative would be to create separate language-specific lists, but
> some (rightfully) think there’s a risk of a disconnect with actual
> developers.

Indeed, unless we get a lot of multilingual traffic, at which point we can
still create separate lists.

> +   "Subscribe to the Help mailing list to get support from the GuixSD
> +and GNU Guix community via email.  You can post messages in English though we
> +also accept other languages.")
> +  ("eo"
> +   "Subskribu al la retmesaĝolisto \"Help\" por demandi helpon pri
> +GuixSD kaj GNU Guix al la grupo.  Vi povas skribi esperantlingve.")
> +  ("fr"
> +   "Abonnez-vous à la liste de diffusion « Help » pour obtenir l'aide
> +de la communauté sur GuixSD et GNU Guix par courrier électronique.  Vous
> +pouvez envoyer des messages en Français."))

("de"
 "Melden Sie sich bei der „Help“-Mailingliste an, um per E-Mail Hilfe von 
anderen
GuixSD- und Guix-Nutzern zu bekommen.  Sie können Nachrichten auch auf deutsch
schicken.")

(Zur Frage, ob es "auf deutsch" oder "auf Deutsch" heißt, siehe
   
http://www.belleslettres.eu/content/rechtschreibung/auf-deutsch-rechtschreibung.php
 .)

Andreas

Re: Kernel modules in initrd

[Andreas Enge]

Hello,

On Fri, Feb 23, 2018 at 03:28:55PM +0100, Danny Milosavljevic wrote:
> No, wait, according to 
> https://unix.stackexchange.com/questions/43699/debian-does-not-detect-serial-pci-card-after-reboot/43723#43723
>  ,
> the kernel should be doing that even without udev.  Are we sure we need to 
> manually modprobe the stuff in gnu/build/linux-boot.scm in
> the first place?  I think we should just add kmod to the initrd - that's it.

in that case, if I understand correctly, the security question would not
be a problem any more, right, as only really needed modules would be loaded
by the kernel? Then we could add more modules to the initrd.

Andreas

Re: Kernel modules in initrd

[Andreas Enge]

Hello Danny,

On Thu, Feb 22, 2018 at 10:34:03PM +0100, Danny Milosavljevic wrote:
> When you booted from the USB key the system DIDN'T need mptsas to find
> ITS root filesystem.  So it booted fine and in the end of it all you had
> a working GNU Linux, with udev.
> 
> Then udev saw the hard disk and udev went and loaded the kernel
> module (from the root filesystem, not from the initrd), as it was
> supposed to do.

thanks for the explanations, I agree with your analysis.
So the patch you propose looks good to me.

Andreas