Volunteering

[Felipe López]

Hi,

I've been helping in libre software projects for some years. The last
project in which I participated was gNewSense. I helped there since
version 2.4 doing some graphics, documentation, and translations. I've
done some scripting in Python, and I'm learning to program, but I'm a
naive programmer.

I read somewhere that you may be needing some graphics soon. In
gNewSense I used to do visual-theme proposals for each mayor version of
the system [1][2] and I would like to do the same for Guix if you think
it's OK. Is anyone working on the visual part of the project?

Thanks,


[1] http://galaxia.rtfd.org/
[2] http://gnsaurora.rtfd.org/

-- 
Luis Felipe López Acevedo
http://sirgazil.bitbucket.org/

Re: [PATCH 0/2] gnu: Add sdl-union and guile-sdl

[Ludovic Courtès]

David Thompson  skribis:

> Regarding sdl-union:
>
> * This package isn't useful for users, only developers.  Should I keep it
> private so that it doesn't show up in package searches?

Probably, yes.  But could you remind me why it’s needed?  ISTR from
earlier discussions that some tools (‘sdl-config’?) assume that all the
headers and libraries are in the same directory, right?

Could you add the explanation as a comment or the ‘description’ field in
the source?

> * I wasn't sure how to fill out the metadata fields.  Thoughts on what
>   they should be?

What you did is fine, or you could add the explanation mentioned above.

> Regarding guile-sdl:
>
> * This package doesn't build.  However, if I build with --keep-failed
> and run `make clean && make` in /tmp/nix-.../guile-sdl-0.5.1, the build
> is successful.  Does anyone have any thoughts about why this might be?
> I really need some help here.

Did you try #:parallel-build? #f and/or #:parallel-tests? #f?
Otherwise, perhaps you could post the fail of the build log to see if we
have an idea.

Thanks!

Ludo’.

Re: Font package naming convention

[Ludovic Courtès]

Andreas Enge  skribis:

> On Sun, Nov 02, 2014 at 06:18:19PM +0100, Ludovic Courtès wrote:
>> Some of the fonts created by foundries are often referred to it using
>> the foundry’s name, such as “Bitstream Vera”; there are also
>> counter-examples, like Gentium, Charis, etc. (by SIL.)
>> 
>> So, again very informally, I would suggest to use the foundry name in
>> cases where people expect to see it, and in cases where it removes
>> ambiguity with similarly-named fonts.
>> 
>> What do people think?
>
> I think it would be nice to add the foundry when it is know, such as
> sil-gentium etc.; personally I find it an interesting information to have
> (we would get a complete list of all packages sil fonts, for instance).

OK, it makes sense to me.

If there’s rough consensus on this, the next step would be to write this
informal rule in the manual, and to update package names.

Any volunteer?  Alex?  :-)

Thanks,
Ludo’.

Re: Different versions of a package in the same profile?

[Ludovic Courtès]

Federico Beffa  skribis:

> Andreas Enge  writes:
>
>> On Sun, Nov 02, 2014 at 06:22:28PM +0100, Ludovic Courtès wrote:
>> There is also the question of conflicts with identical file names. They are
>> already there now, but their probability should be higher with identical
>> package names. Maybe we need to rethink the handling of conflicts also.
>
> In the past I did use the packaging system called SEPP
>
> http://oss.oetiker.ch/op-sepp/

Interesting.

> It allow installing several versions of a program on a single system.
> The way they use to avoid naming conflicts it to systematically add a
> suffix to binary names, with the suffix corresponding to the version of
> the package.  They even went one step further and they added a suffix
> with the initials of the administrator who packaged the application.
>
> Each program was available with several names. For program foo:
> - foo
> - foo-1.2.3
> - foo-1.2.3-fb
> Obviously if more foo versions were installed, only one would be
> referred to by foo.  The others were available with versioned names.
>
> As a user, the system did work very well.
>
> To handle updating, specifying foo should update the version owning
> the name foo.

OK, this is a strategy similar to what Andreas was suggesting.

> To update another version one would give the versioned name
> "foo-1.2.3".

I see.

Ludo’.

Re: [PATCH] gnu: Add freeimage.

[Ludovic Courtès]

Andreas Enge  skribis:

> Could you have a look? To me it looks as if there is bad assembly code
> in the source:
> /tmp/nix-build-freeimage-3.16.0.drv-0/cc1WaZEm.s: Assembler messages:
> /tmp/nix-build-freeimage-3.16.0.drv-0/cc1WaZEm.s:360: Error: opcode not 
> supported on this processor: mips3 (mips3) `madd $24,$10'
> ...

Same problem as with Valgrind, so I would suggest disabling builds on
MIPS, as done in commit 67a86d3.

Ludo’.

Re: Changing python-wrapper to handle lib/ etc.

[Ludovic Courtès]

Andreas Enge  skribis:

> On Thu, Oct 30, 2014 at 02:12:58PM +0100, Ludovic Courtès wrote:
>> We’ll also need the patch from
>>  in
>> this branch.
>
> Maybe not

Indeed.  (I replied in the other thread.)

> I created the branch, see its progress at
>http://hydra.gnu.org/jobset/gnu/wip-python

Apparently the main regression is SWIG, which fails to find Python.h:

  http://hydra.gnu.org/build/134431

Ludo’.

Re: Volunteering

[Ludovic Courtès]

Hello,

Felipe López  skribis:

> I read somewhere that you may be needing some graphics soon. In
> gNewSense I used to do visual-theme proposals for each mayor version of
> the system [1][2] and I would like to do the same for Guix if you think
> it's OK. Is anyone working on the visual part of the project?

Not that I know of.  Your help would be welcome!

Examples of things that would be nice to have include a GRUB background
image and a SLiM (login manager) login image.  (And we have plans to
make a new release within a couple of weeks, if you need an incentive to
get started.  ;-))

Then of course, the Web page needs love, although we’re a bit
constrained by the gnu.org infrastructure (server-side includes etc.)
and the need for consistency across gnu.org Web pages.

“Promotional” images or banners similar in spirit to those you did for
gNewSense would be nice as well.


I’ve just created a new repository for artwork in general, which
currently only contains the logo:

  http://git.savannah.gnu.org/cgit/guix/guix-artwork.git

It would be convenient if things you do could go there, in the preferred
form (most of the time SVG I suppose?)

WDYT?  :-)

Thanks,
Ludo’.

Re: [PATCH] gnu: Add freeimage.

[Andreas Enge]

On Mon, Nov 03, 2014 at 10:00:38AM +0100, Ludovic Courtès wrote:
> Same problem as with Valgrind, so I would suggest disabling builds on
> MIPS, as done in commit 67a86d3.

Speaking of valgrind, how is transitivity of disabled builds handled,
on hydra and by the users?

I noticed that some packages do not build on mipss due to a dependency
on valgrind, for instance petsc-openmpi and petsc-complex-openmpi:
   http://hydra.gnu.org/build/132921
   http://hydra.gnu.org/build/132781
It was a bit confusing to me at first, since valgrind was not in the
"still failing jobs" tab, until I realised it was also not in the "still
succeeding jobs" tab and in fact disabled.

The two packages in question depend indirectly on valgrind via openmpi.
Now openmpi seems to be disabled for mips on hydra also, although it is
not explicitly disabled in the package recipe. These two other packages
are not disabled, however. So does this mean that the dependency graph
for disabled inputs is followed only to depth 1?

Andreas

Re: Font package naming convention

[Andreas Enge]

On Mon, Nov 03, 2014 at 09:53:21AM +0100, Ludovic Courtès wrote:
> If there’s rough consensus on this, the next step would be to write this
> informal rule in the manual, and to update package names.
> 
> Any volunteer?  Alex?  :-)

I volunteer, as I feel responsible for the package guidelines.

Andreas

[andr...@enge.fr: ATLAS fails to build on mips]

[Andreas Enge]

As I am not sure if Fede is subscribed to the bug mailing list,
I am forwarding my report here. It is
   http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18933

Andreas


- Forwarded message from Andreas Enge  -
ATLAS fails to build on mipsel64:
   http://hydra.gnu.org/build/133025
with
mkdir ARCHS
make -f Make.top startup
make[1]: Entering directory '/tmp/nix-build-atlas-3.10.2.drv-0/build'
Make.top:1: Make.inc: No such file or directory
make[1]: *** No rule to make target 'Make.inc'.  Stop.
make[1]: Leaving directory '/tmp/nix-build-atlas-3.10.2.drv-0/build'

Can this be repaired, or is the package not supposed to work on mipsel64?
In the latter case, we would need to disable it for this architecture.

Andreas
- End forwarded message -

Re: Changing python-wrapper to handle lib/ etc.

[Federico Beffa]

On Sun, Nov 2, 2014 at 10:32 PM, Andreas Enge  wrote:
> With the new python wrapper, something is found:
> checking for python3-config... python3-config
> checking for Python 3.x prefix... 
> /gnu/store/r6614z0w2inxn78wzaa7ic5sai8s7l9f-python-3.3.5
> checking for Python 3.x exec-prefix... 
> /gnu/store/r6614z0w2inxn78wzaa7ic5sai8s7l9f-python-3.3.5
> checking for Python 3.x version... python3.3
> checking for Python 3.x lib dir... lib
> checking for Python 3.x header files... 
> -I/gnu/store/r6614z0w2inxn78wzaa7ic5sai8s7l9f-python-3.3.5/include/python3.3m 
> -I/gnu/store/r6614z0w2inxn78wzaa7ic5sai8s7l9f-python-3.3.5/include/python3.3m
> checking for Python 3.x library... Not found
>
> Whatever this means! The header files are correctly located in the python3.3m
> subdirectory of the include directory. However, the CPATH includes only
> the include/ directory itself (logic!). And apparently the tests do not
> use the correct include path.
>
> Could maybe a swig specialist have a look?

I've just noticed the following sentence in the release of version 2.0.12:

- Compilation fixes on some systems for the generated Lua, PHP, Python
and R wrappers.

See http://www.swig.org/

Maybe, it was an upstream bug?

Regards,
Fede

Re: Changing python-wrapper to handle lib/ etc.

[Andreas Enge]

On Mon, Nov 03, 2014 at 11:11:22AM +0100, Federico Beffa wrote:
> - Compilation fixes on some systems for the generated Lua, PHP, Python
> and R wrappers.
> Maybe, it was an upstream bug?

Thanks, I will try to update and keep you updated.

Andreas

Re: Font package naming convention

[Alex Kost]

Andreas Enge (2014-11-03 12:30 +0300) wrote:

> On Mon, Nov 03, 2014 at 09:53:21AM +0100, Ludovic Courtès wrote:
>> If there’s rough consensus on this, the next step would be to write this
>> informal rule in the manual, and to update package names.
>> 
>> Any volunteer?  Alex?  :-)
>
> I volunteer, as I feel responsible for the package guidelines.

Great!  Thanks and sorry if my messages here were offensive.  I'm going
to update and resend my patch with liberation fonts package for the new
convention when the names of the existing font packages will be updated.

-- 
Alex

Re: Volunteering

[Felipe López]

On 03/11/14 04:27, Ludovic Courtès wrote:
> Hello,
> 
> Felipe López  skribis:
> 
>> I read somewhere that you may be needing some graphics soon. In
>> gNewSense I used to do visual-theme proposals for each mayor version of
>> the system [1][2] and I would like to do the same for Guix if you think
>> it's OK. Is anyone working on the visual part of the project?
> 
> Not that I know of.  Your help would be welcome!
> 
> Examples of things that would be nice to have include a GRUB background
> image and a SLiM (login manager) login image.  (And we have plans to
> make a new release within a couple of weeks, if you need an incentive to
> get started.  ;-))

I'll start working on these.

> 
> Then of course, the Web page needs love, although we’re a bit
> constrained by the gnu.org infrastructure (server-side includes etc.)
> and the need for consistency across gnu.org Web pages.

I'll see if I can work on the website later.


> “Promotional” images or banners similar in spirit to those you did for
> gNewSense would be nice as well.
> 
> 
> I’ve just created a new repository for artwork in general, which
> currently only contains the logo:
> 
>   http://git.savannah.gnu.org/cgit/guix/guix-artwork.git
> 
> It would be convenient if things you do could go there, in the preferred
> form (most of the time SVG I suppose?)

Should I send patches to the mailing list or do I join Guix in Savannah
for commit access?

> 
> WDYT?  :-)
> 
> Thanks,
> Ludo’.
> 

-- 
Luis Felipe López Acevedo
http://sirgazil.bitbucket.org/

Re: [PATCH] gnu: add atlas

[Ludovic Courtès]

Federico Beffa  skribis:

> Thanks for the offer!  I've created an account.  My knowledge of git
> is very limited and I've never pushed any change with it.  I will
> therefore need some guidance.  I'm reading Git Pro
> http://git-scm.com/book/en/v2

No problem.  If in doubt just ask by email or stop by #guix on Freenode.

> Do you have any other pointer, possibly more concise and in line with
> guix's use?

Please read the “Commit Access” section in ‘HACKING’ for a start, and
make sure you follow these guidelines.

I don’t really know of good Git documentation to recommend.

If you use Emacs, I recommend Magit as the Git user interface.  It’s
powerful, and I think it makes it easier to understand what’s going on
with Git.

Welcome on board!  :-)

Ludo’.

Re: [PATCH] gnu: Add Cython

[Ludovic Courtès]

Federico Beffa  skribis:

> From 3155aa1ec614afb01b7bff0bbf3eabb4ee5bb0de Mon Sep 17 00:00:00 2001
> From: Federico Beffa 
> Date: Mon, 20 Oct 2014 19:52:45 +0200
> Subject: [PATCH] gnu: Add Cython
>
> * gnu/packages/python.scm(cython,cython2): New variables.

Pushed, with missing spaces in the commit log added.

Thanks!

Ludo’.

Re: [PATCH] gnu: Add docbook-xml-4.2

[Ludovic Courtès]

Andreas Enge  skribis:

> On Sun, Nov 02, 2014 at 06:26:59PM +0100, Federico Beffa wrote:
>> Add version 4.2.  It is needed by dconf.
>
> This looks very safe

Yes, please push.

> (although we will end up with four versions of it!).

Right, but it seems inherent to DocBook and document systems in general:
unlike software, documents are rarely “ported” to the new “APIs”.

Ludo’.

Re: [PATCH] gnu: Add Cython

[Andreas Enge]

On Mon, Nov 03, 2014 at 05:57:58PM +0100, Ludovic Courtès wrote:
> Federico Beffa  skribis:
> > Subject: [PATCH] gnu: Add Cython
> > * gnu/packages/python.scm(cython,cython2): New variables.
> Pushed, with missing spaces in the commit log added.

I think that should have gone on the wip-python branch eventually instead
of being pushed now... Never mind, we can always adapt it later!

Andreas

Re: Volunteering

[Ludovic Courtès]

Felipe López  skribis:

> Should I send patches to the mailing list or do I join Guix in Savannah
> for commit access?

Patches would be inadequate.  What about posting a link to the SVGs to
the mailing list so we can see, and then commit those that are selected
to the artwork.git repo?

For the latter, please request to join Guix on Savannah, as you note.

Thanks,
Ludo’.

Re: [PATCH] gnu: Add Cython

[Ludovic Courtès]

Andreas Enge  skribis:

> On Mon, Nov 03, 2014 at 05:57:58PM +0100, Ludovic Courtès wrote:
>> Federico Beffa  skribis:
>> > Subject: [PATCH] gnu: Add Cython
>> > * gnu/packages/python.scm(cython,cython2): New variables.
>> Pushed, with missing spaces in the commit log added.
>
> I think that should have gone on the wip-python branch eventually instead
> of being pushed now... Never mind, we can always adapt it later!

Oh, apologies then.

But are you sure you aren’t confusing it with NumPy, which requires the
new python-wrapper?

Ludo’.

Re: [PATCH] gnu: Add Cython

[Andreas Enge]

On Mon, Nov 03, 2014 at 08:42:25PM +0100, Ludovic Courtès wrote:
> But are you sure you aren’t confusing it with NumPy, which requires the
> new python-wrapper?

Probably I am confusing things, even less problems then!

Andreas

Re: [PATCH] gnu: Add Cython

[Federico Beffa]

On Mon, Nov 3, 2014 at 8:50 PM, Andreas Enge  wrote:
> On Mon, Nov 03, 2014 at 08:42:25PM +0100, Ludovic Courtès wrote:
>> But are you sure you aren’t confusing it with NumPy, which requires the
>> new python-wrapper?
>
> Probably I am confusing things, even less problems then!
>

No, Andreas is right: this patch suffers from the same problem as Numpy.

Fede

Re: Changing python-wrapper to handle lib/ etc.

[Andreas Enge]

On Mon, Nov 03, 2014 at 11:13:45AM +0100, Andreas Enge wrote:
> Thanks, I will try to update and keep you updated.

This was it not. There is also a newer swig-3.0.2, but it also does not
solve the problem. My suspicion is that swig has never worked with python
for us. So my current solution would be to disable it and push this change
if all dependent packages build. Someone interested in swig and python can
then try to fix this.

Andreas

Re: [PATCH] gnu: Add freeimage.

[Ludovic Courtès]

Andreas Enge  skribis:

> On Mon, Nov 03, 2014 at 10:00:38AM +0100, Ludovic Courtès wrote:
>> Same problem as with Valgrind, so I would suggest disabling builds on
>> MIPS, as done in commit 67a86d3.
>
> Speaking of valgrind, how is transitivity of disabled builds handled,
> on hydra and by the users?

There’s nothing preventing users to build Valgrind on mips64el-linux,
currently.

On Hydra, build-aux/hydra/gnu-system.scm uses
‘package-transitive-supported-systems’, which returns the intersection
of a package’s ‘supported-systems’ and that of its inputs (with the
assumption that implicit inputs are all supported everywhere.)

> I noticed that some packages do not build on mipss due to a dependency
> on valgrind, for instance petsc-openmpi and petsc-complex-openmpi:
>http://hydra.gnu.org/build/132921
>http://hydra.gnu.org/build/132781
> It was a bit confusing to me at first, since valgrind was not in the
> "still failing jobs" tab, until I realised it was also not in the "still
> succeeding jobs" tab and in fact disabled.
>
> The two packages in question depend indirectly on valgrind via openmpi.
> Now openmpi seems to be disabled for mips on hydra also, although it is
> not explicitly disabled in the package recipe. These two other packages
> are not disabled, however. So does this mean that the dependency graph
> for disabled inputs is followed only to depth 1?

Oh right, that’s a bug.  Fixed in commit c37a74b.

Thanks for the report!

Ludo’.

Re: Font package naming convention

[Ludovic Courtès]

Andreas Enge  skribis:

> On Mon, Nov 03, 2014 at 09:53:21AM +0100, Ludovic Courtès wrote:
>> If there’s rough consensus on this, the next step would be to write this
>> informal rule in the manual, and to update package names.
>> 
>> Any volunteer?  Alex?  :-)
>
> I volunteer, as I feel responsible for the package guidelines.

Perfect, thank you!

Ludo’.

Re: Changing python-wrapper to handle lib/ etc.

[Andreas Enge]

On Mon, Nov 03, 2014 at 09:19:28PM +0100, Andreas Enge wrote:
> This was it not. There is also a newer swig-3.0.2, but it also does not
> solve the problem. My suspicion is that swig has never worked with python
> for us. So my current solution would be to disable it and push this change
> if all dependent packages build. Someone interested in swig and python can
> then try to fix this.

In 2.0.12 without python, now the guile tests fail... 3.0.2 without python
compiles well, so I am trying to build the swig dependencies now.

Andreas

Re: [PATCH] gnu: Add Cython

[Federico Beffa]

On Mon, Nov 3, 2014 at 9:12 PM, Federico Beffa  wrote:
> No, Andreas is right: this patch suffers from the same problem as Numpy.

Maybe I wasn't clear :-)  the patch does include python as an input.
So, it will build in master, without any change in python-wrapper.
After the changes in python-wrapper, we may want to remove the python
input.

Regards,
Fede

Re: Changing python-wrapper to handle lib/ etc.

[Andreas Enge]

On Mon, Nov 03, 2014 at 09:49:21PM +0100, Andreas Enge wrote:
> In 2.0.12 without python, now the guile tests fail... 3.0.2 without python
> compiles well, so I am trying to build the swig dependencies now.

Everything worked well, so I pushed this solution to wip-python.

Andreas

Re: [PATCH 1/2] gnu: librsvg: Generate complete loaders.cache including support for SVG.

[Ludovic Courtès]

Federico Beffa  skribis:

> As mentioned in a previous email, the cache generated by default does
> not include support for SVG provided by librsvg itself.  With this
> patch we generate a full cache file.

Nice.

> From 36c6d59180bdb2d80e169938097efca39431c122 Mon Sep 17 00:00:00 2001
> From: Federico Beffa 
> Date: Sun, 2 Nov 2014 18:01:08 +0100
> Subject: [PATCH 1/2] gnu: librsvg: Generate complete loaders.cache including
>  support for SVG.
>
> * gnu/packages/gnome.scm (librsvg): Add 'generate-full-chage phase.
 ^^
Typo.

> + (system 
> +  (string-append 
> +   "gdk-pixbuf-query-loaders " 
> +   loaders-directory "/libpixbufloader-svg.so "
> +   (fold (lambda (s p) (string-append s " " p))  "" 
> + (find-files (assoc-ref inputs "gdk-pixbuf") 
> + "libpixbufloader-.*\\.so"))
> +   "> " loaders-directory ".cache")

It may be clearer to replace fold with ‘string-join’

  (string-join (find-files ...))

... in which case the import of (srfi srfi-1) can also be removed.

OK to commit with these changes.

Thanks,
Ludo’.

Re: [PATCH 2/2] gnu: Add gnome-themes-standard.

[Ludovic Courtès]

Federico Beffa  skribis:

> From 7439f19c1f2966466da88554478b796c3bfca429 Mon Sep 17 00:00:00 2001
> From: Federico Beffa 
> Date: Sun, 2 Nov 2014 18:09:33 +0100
> Subject: [PATCH 2/2] gnu: Add gnome-themes-standard.
>
> * gnu/packages/gnome.scm (gnome-themes-standard): New variable.

[...]

> +;; The version of this package should be the same as the version of
> +;; gnome-desktop.
> +(define-public gnome-themes-standard
> +  (package
> +(name "gnome-themes-standard")
> +(version "3.10.0")

Please use (version (package-version gnome-desktop)) here, and put the
comment just above it.

> +   (uri (string-append "mirror://gnome/sources/" name "/" 
> +   (string-take version 4) "/" name "-"

Use ‘version-major+minor’ instead of ‘string-take’.

OK to push with these changes.

Thanks!

Ludo’.

Re: [PATCH 2/2] emacs: Add interface for comparing generations.

[Ludovic Courtès]

Alex Kost  skribis:

> Ludovic Courtès (2014-11-02 20:59 +0300) wrote:
>
>> Alex Kost  skribis:
>>
>>> In short, now (with this patch) after marking 2 generations (by pressing
>>> "m" in a “generation-list” buffer), you can perform diff/ediff on
>>> generation packages or manifests.  Thanks to Ludovic for the idea.
>>
>> I just tried it, and I like it!
>>
>> There are cases where the output of ‘=’ is slightly confusing: the
>> buffers being compared don’t include the directory name of the packages,
>> so, when packages have been upgraded (different directory names, but
>> same version), it just says “no differences.”
>>
>> Perhaps the fix would be to add the directory names in the buffers being
>> diffed, in a format similar to that of ‘guix package -I’?
>
> Indeed, I added the store paths, thanks (the modified patch is attached).

Nice!

>> I have another case where C-u = shows that the only difference is the
>> addition of one package, but = shows a diff with only minuses, as if
>> everything had been removed.  Any idea what could be wrong?

I can’t seem to reproduce that problem.  I must have messed things up
before, sorry for the noise.

>> Also, s/The Emacs Editor/GNU Emacs Manual/, which is the real title of
>> the Emacs manual as it appears in the texi source.
>
> Oh, I thought it should be the title which appears in the info (I mean
> the first line in the Top node).
>
> Perhaps "s/The Emacs Editor/The GNU Emacs Manual/"?  As it's the most
> common (but not the one) variant in the Emacs Lisp manual, for example here:
> 

OK (I think they should add “The” in emacs.texi.)

> Also I used "The Emacs Editor" several times in “emacs.texi”.  Should I
> replace all instances in this patch or make a separate commit for that?

Yes, please.

> Just out of curiosity.  Do you usually prefer "diff" over "ediff"?
> (I find the latter much convenient)

The default behavior for ediff is to create another frame for control,
and that doesn’t work well with the tiling window manager I’m using.
Also, it’s really a mode that you enter and have to leave afterwards.
So I tend to prefer diff for simple diffs, and I resort to ediff in more
tricky situations (like when I have to compare two .drv files for
debugging, uh! ;-)).

Thanks,
Ludo’.

Re: [PATCH] gnu: Add freeimage.

[David Thompson]

Andreas Enge  writes:

> Unfortunately, it fails to build on mips:
>http://hydra.gnu.org/build/136438
> Could you have a look? To me it looks as if there is bad assembly code
> in the source:
> /tmp/nix-build-freeimage-3.16.0.drv-0/cc1WaZEm.s: Assembler messages:
> /tmp/nix-build-freeimage-3.16.0.drv-0/cc1WaZEm.s:360: Error: opcode not 
> supported on this processor: mips3 (mips3) `madd $24,$10'
> ...

Here's a patch that drops MIPS support.  Okay to push?

>From 67515d4f69b7deda45be7fb6e7ebf260d5e0439b Mon Sep 17 00:00:00 2001
From: David Thompson 
Date: Mon, 3 Nov 2014 18:26:38 -0500
Subject: [PATCH] gnu: freeimage: Remove MIPS from supported-systems.

* gnu/packages/image.scm (freeimage): Drop support for "mips64el-linux".
---
 gnu/packages/image.scm | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/gnu/packages/image.scm b/gnu/packages/image.scm
index f4f4c78..7a22bf4 100644
--- a/gnu/packages/image.scm
+++ b/gnu/packages/image.scm
@@ -377,6 +377,8 @@ supplies a generic doubly-linked list and some string functions.")
   #:tests? #f)) ; no check target
(native-inputs
 `(("unzip" ,unzip)))
+   ;; Fails to build on MIPS due to assembly code in the source.
+   (supported-systems (delete "mips64el-linux" %supported-systems))
(synopsis "Library for handling popular graphics image formats")
(description
 "FreeImage is a library for developers who would like to support popular
-- 
2.1.1


-- 
David Thompson
Web Developer - Free Software Foundation - http://fsf.org
GPG Key: 0FF1D807
Support the FSF: https://fsf.org/donate

Re: [PATCH 2/2] emacs: Add interface for comparing generations.

[Alex Kost]

Ludovic Courtès (2014-11-04 01:22 +0300) wrote:

> Alex Kost  skribis:

[...]

>> Perhaps "s/The Emacs Editor/The GNU Emacs Manual/"?  As it's the most
>> common (but not the one) variant in the Emacs Lisp manual, for example here:
>> 
>
> OK (I think they should add “The” in emacs.texi.)
>
>> Also I used "The Emacs Editor" several times in “emacs.texi”.  Should I
>> replace all instances in this patch or make a separate commit for that?
>
> Yes, please.

Sorry, yes for «replace all instances in this patch» or for «make a
separate commit»?  I think the latter, so I've attached a patch for
that.  OK to commit?

>> Just out of curiosity.  Do you usually prefer "diff" over "ediff"?
>> (I find the latter much convenient)
>
> The default behavior for ediff is to create another frame for control,
> and that doesn’t work well with the tiling window manager I’m using.
> Also, it’s really a mode that you enter and have to leave afterwards.
> So I tend to prefer diff for simple diffs, and I resort to ediff in more
> tricky situations (like when I have to compare two .drv files for
> debugging, uh! ;-)).

Oh, indeed; I forgot about the defaults.  Yeah, additional frame and
vertical splitting are evil :-)  So I use the following settings:

  (setq
   ediff-window-setup-function #'ediff-setup-windows-plain ; no new frame
   ediff-split-window-function #'split-window-horizontally
   ediff-grab-mouse nil)

But the most unpleasant default behaviour for me is that Ediff doesn't
restore the previous window configuration.  To "fix" it, I use:



ediff-tmp.el
Description: application/emacs-lisp

Sorry for being verbose on an unrelated topic, but maybe someone who
will read it, find it useful (I also recommend to look at
).

>From ae8f292fba3fee0b89a877a7ad61045d2bc91e2c Mon Sep 17 00:00:00 2001
From: Alex Kost 
Date: Tue, 4 Nov 2014 10:20:41 +0300
Subject: [PATCH] doc: emacs: Fix titles of the printed manuals.

* doc/emacs.texi: Use the proper names of the printed manuals in the
  cross references.
---
 doc/emacs.texi | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/doc/emacs.texi b/doc/emacs.texi
index 1b134d7..1d7711a 100644
--- a/doc/emacs.texi
+++ b/doc/emacs.texi
@@ -38,7 +38,7 @@ used for interacting with the Guile process.
 @end itemize
 
 When it is done, add the following into your init file (@pxref{Init
-File,,, emacs, The Emacs Editor}):
+File,,, emacs, The GNU Emacs Manual}):
 
 @example
 (require 'guix-init nil t)
@@ -47,7 +47,8 @@ File,,, emacs, The Emacs Editor}):
 However there is a chance that @code{load-path} of your Emacs does not
 contain a directory with ``guix.el'' (usually it is
 @file{/usr/share/emacs/site-lisp/}).  In that case you need to add it
-before requiring (@pxref{Lisp Libraries,,, emacs, The Emacs Editor}):
+before requiring (@pxref{Lisp Libraries,,, emacs, The GNU Emacs
+Manual}):
 
 @example
 (add-to-list 'load-path "/path/to/directory-with-guix.el")
@@ -56,7 +57,8 @@ before requiring (@pxref{Lisp Libraries,,, emacs, The Emacs Editor}):
 
 Do not worry about the efficiency of that @code{require} thing.  It will
 not load the whole ``guix.el'' package, it will just autoload the main
-interactive commands (@pxref{Autoload,,, elisp, Emacs Lisp}).
+interactive commands (@pxref{Autoload,,, elisp, The Emacs Lisp Reference
+Manual}).
 
 
 @node Emacs Usage
@@ -129,7 +131,7 @@ of generations.
 @item M-x guix-generations-by-time
 List generations matching time period.  You will be prompted for the
 period using Org mode time prompt based on Emacs calendar (@pxref{The
-date/time prompt,,, org, Org Mode Manual}).
+date/time prompt,,, org, The Org Manual}).
 
 @end table
 
@@ -187,7 +189,7 @@ was restarted, you may want to revert ``list'' buffer (by pressing
 @subsubsection ``List'' buffer
 
 An interface of a ``list'' buffer is similar to the interface provided
-by ``package.el'' (@pxref{Package Menu,,, emacs, The Emacs Editor}).
+by ``package.el'' (@pxref{Package Menu,,, emacs, The GNU Emacs Manual}).
 
 Default key bindings available for both ``package-list'' and
 ``generation-list'' buffers:
@@ -260,11 +262,11 @@ with another marked generation.
 @subsubsection ``Info'' buffer
 
 The interface of an ``info'' buffer is similar to the interface of
-@code{help-mode} (@pxref{Help Mode,,, emacs, The Emacs Editor}).
+@code{help-mode} (@pxref{Help Mode,,, emacs, The GNU Emacs Manual}).
 
 ``Info'' buffer contains some buttons (as usual you may use @key{TAB} /
 @kbd{S-@key{TAB}} to move between buttons---@pxref{Mouse References,,,
-emacs, The Emacs Editor}) which can be used to:
+emacs, The GNU Emacs Manual}) which can be used to:
 
 @itemize @bullet
 @item (in a ``package-info'' buffer)
@@ -294,8 +296,8 @@ emacs, The Emacs Editor}) which can be used to:
 There are many variables you can modify to change the appearance or
 behavior of Emacs use