Re: shortening the git test suite

[Gábor Boskovits]

Mark H Weaver  ezt írta (időpont: 2018. júl. 2., H, 6:58):

> Ricardo Wurmus  writes:
>
> > git takes a very long time to build, because it has an extensive test
> > suite.  Most of the time is spent in running the SVN interoperability
> > tests, though, which are not really all that interesting for most uses
> > of git.
> >
> > The Makefile says this:
> >
> >   # Define NO_SVN_TESTS if you want to skip time-consuming SVN
> interoperability
> >   # tests.  These tests take up a significant amount of the total test
> time
> >   # but are not needed unless you plan to talk to SVN repos.
> >
> > What do you think about disabling the SVN tests in the git package?
>
> My preference would be to keep the SVN tests enabled, but it's not
> something I feel very strongly about.
>
>   Thanks,
> Mark
>
>
Do we have a way to make running this SVN test suite optional? For example
to run it only before release, or on demand?

Re: preparing the next release v0.15.0

[Ludovic Courtès]

Hello!

Clément Lassieur  skribis:

> I think we need https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30602 to
> be fixed.

Done.   \o/

With Guile 2.2.4 now released, we can go ahead with 0.15.  Could people
build the ISO installation image and give it a try:

  guix system disk-image --file-system-type=iso9660 gnu/system/install.scm

and then boot the resulting image (you can do that in QEMU if you
prefer), and follow the instructions.

Likewise, tests of the binary Guix tarball would be welcome.  You can
build it with:

  make guix-binary.x86_64-linux.tar.xz

For the record, some of the items Ricardo listed are not entirely
addressed either (quoting Ricardo’s previous message):

  * Outstanding patches.  There are many patches in the queue at
guix-patches[1] that we should go through, comment on, and/or apply
before the release.  Who would like to join a task force to do that
together?  Let’s pick 5 patches each and review them so that we can
either comment to ask for changes or to apply them.

[1]: https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix-patches

  * breakage since the last core-updates merge.  Since the long overdue
merge of the “core-updates” branch we have a few serious problems on
i686 (e.g. the gst-plugins-base package) and armhf.  Who would like to
lead an effort to investigate and fix these problems?  (Note: you
obviously don’t need to fix them yourself, just keep track of these
things and coordinate with others who investigate them.)

  * collecting new features and big changes in NEWS.  The NEWS file
already lists some of the changes that the next release would provide
compared to 0.14.0, but we all know that there are more.  Who would
like to take charge of the NEWS file?  This involves asking people for
changes they would really like to be mentioned and coordinating with
other volunteers to search through all commits since v0.14.0 to find
noteworthy changes.

If we all focus on this, we could release by the end of the week or
beginning of next week.  Let’s do that!  :-)

Ludo’.

Re: GNOME 3 screenshot for gnu.org

[Ludovic Courtès]

Hi Amin,

Amin Bandali  skribis:

> The FSF is looking to refresh the screenshot on www.gnu.org, and
> add new ones showcasing Mate and GNOME 3.  I suggested taking the
> GNOME 3 screenshot from GuixSD.
>
> I see there's already a GNOME 3 screenshot [0] on the Guix page.
> Given that the screenshot seems to be from 2016, would you like
> to take a new one, or is it fine if we use the current one?
>
> [0]: https://www.gnu.org/software/guix/screenshots/gnome/

I think it’s fine to use the current one, though maybe we should
consider making new screenshots too…

Thanks for the heads-up!

Ludo’.

Re: guix package is slow

[Ludovic Courtès]

Hello!

Maxim Cournoyer  skribis:

> swedebu...@riseup.net writes:
>
>> Hi
>>
>> I would like guix package -A/s to be faster.
>> There it takes >3s every time I run the command.

It’s at 1.5s for me on an SSD and a hot cache, but I agree that overall
it’s too slow.

> I agree that Guix is rather slow when comparing it to traditional
> package managers such as apt; I think the main reason, as you found, is
> that it has to load all the byte-compiled package definition files.

That, and also it generally has “more work” to do (see ‘apt-get update’
vs. ‘guix pull’, or even ‘guix package -i emacs’ vs. ‘apt-get install
emacs’.)  That’s not meant as an excuse, just a clarification of what’s
going on.

>> Would it be possible to populate an index or something when pulling so
>> that we have the information in a sqlite-db instead of traversing 40
>> go-files with guile?
>
> I remember asking Ludovic in #guix if Guile would be able to compete
> with database software in terms of performance, and he said there are
> ways we can make it faster.

I think we could easily optimize package lookups by name.  Instead of
traversing the whole list of package modules to build up a name/package
table, we could have a pre-built cache containing that mapping.  That
way, when typing “guix build emacs”, we could essentially translate that
to “guix build -e '(@ (gnu packages emacs) emacs)'”, which is a little
bit faster.

We could arrange for the cache to be enough for operations such as “guix
package -A”, so that we don’t need to load a single package module.

> I'm not very knowledgeable myself about Guile but if we could make it
> support static linking, to load only one binary rather than hundreds
> in the case of Guix, that would be one way to speed things. Next thing
> might be to implement native compilation.

You might like this:

  https://lists.gnu.org/archive/html/guile-devel/2018-06/msg00026.html

:-)

>> On an older guixsd with about 4k packages the delay was noticeably
>> shorter. 
>
> I guess the time it takes grows linearly (I hope!) with the number of
> packages/modules it has to load. We're now at double that amount of
> packages (IIRC), so Guix might take double the time it used to.

Yeah, that’s why the cache is probably unavoidable.

Thanks,
Ludo’.

‘package-transitive-supported-systems’ is slow

[Ludovic Courtès]

(+Cc: Mark, who’s looked at this part of the code before.)

swedebu...@riseup.net skribis:

> I would like guix package -A/s to be faster.
> There it takes >3s every time I run the command.

On closer inspection, ‘package-transitive-supported-systems’ is
responsible for most of the overhead you’re seeing here.

On my laptop, if I define it like this in (guix packages):

  (define package-transitive-supported-systems
(const '("x86_64-linux")))

then ‘guix package -A’ drops from 1.5s to 0.6s.

The main cost is calling ‘package->bag’, which amounts to doing half of
the work towards computing a package’s derivation.  This particular
change was introduced in 9bf3ced06c42700d6c83ce3a0eda244798104618 so
that ‘package-transitive-supported-systems’ would account for implicit
inputs.

I can’t think of any simple way to optimize it without changing these
semantics.  Mark?

Ludo’.

Re: guix package is slow

[Maxim Cournoyer]

Hi,

Oleg Pykhalov  writes:

> Hello,
>
> Pierre Neidhardt  writes:
>
>> Maxim Cournoyer  writes:
>>
 - Perform transactions (install/remove) over multiple packages.
>>>
>>> To be fair, I think you can already accomplish this using emacs-guix by
>>> separating with commas multiple package names :).
>>
>> Can you explain?  I don't know how to do that.
>>
>> The point of the Helm interface is that it allows to "batch select"
>> multiple packages.  I don't think that emacs-guix can do that.
>
> […]
>
> Another way in ‘M-x guix-all-packages’ or any ‘guix-search-by-*’:
>
>   • Hit ‘i’ on not installed packages.
>   • Hit ‘d’ on installed package.
>   • Hit ‘x’ to apply.

Thanks Oleg! I keep forgetting about this interface; there doesn't seem
to be an entry point from M-x guix for easy discovery.

Maxim

Re: GNOME 3 screenshot for gnu.org

[Amin Bandali]

Hi Ludo,

Ludovic Courtès  writes:

> I think it’s fine to use the current one, though maybe we should
> consider making new screenshots too…

Sounds good!  If you do make new ones and want the one on the
front page updated, feel free to ping me or webmast...@gnu.org.

Thanks,
-amin

Re: preparing the next release v0.15.0

[Nils Gillmann]

Ludovic Courtès transcribed 2.1K bytes:
> Hello!
> 
> Clément Lassieur  skribis:
> 
> > I think we need https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30602 to
> > be fixed.
> 
> Done.   \o/
> 
> With Guile 2.2.4 now released, we can go ahead with 0.15.  Could people
> build the ISO installation image and give it a try:
> 
>   guix system disk-image --file-system-type=iso9660 gnu/system/install.scm
> 
> and then boot the resulting image (you can do that in QEMU if you
> prefer), and follow the instructions.
> 
> Likewise, tests of the binary Guix tarball would be welcome.  You can
> build it with:
> 
>   make guix-binary.x86_64-linux.tar.xz
> 
> For the record, some of the items Ricardo listed are not entirely
> addressed either (quoting Ricardo’s previous message):
> 
>   * Outstanding patches.  There are many patches in the queue at
> guix-patches[1] that we should go through, comment on, and/or apply
> before the release.  Who would like to join a task force to do that
> together?  Let’s pick 5 patches each and review them so that we can
> either comment to ask for changes or to apply them.
> 
> [1]: https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix-patches
> 
>   * breakage since the last core-updates merge.  Since the long overdue
> merge of the “core-updates” branch we have a few serious problems on
> i686 (e.g. the gst-plugins-base package) and armhf.  Who would like to
> lead an effort to investigate and fix these problems?  (Note: you
> obviously don’t need to fix them yourself, just keep track of these
> things and coordinate with others who investigate them.)

mysql is borked, as well as rust, if nothing changes in the last commits.
rust does not really matter since we do not have many depending packages
for it.
Mysql is more grave.

Any takers on mysql?

>   * collecting new features and big changes in NEWS.  The NEWS file
> already lists some of the changes that the next release would provide
> compared to 0.14.0, but we all know that there are more.  Who would
> like to take charge of the NEWS file?  This involves asking people for
> changes they would really like to be mentioned and coordinating with
> other volunteers to search through all commits since v0.14.0 to find
> noteworthy changes.
> 
> If we all focus on this, we could release by the end of the week or
> beginning of next week.  Let’s do that!  :-)

I could contribute some time on the NEWS file tomorrow.

> Ludo’.
> 

Re: preparing the next release v0.15.0

[Efraim Flashner]

On Mon, Jul 02, 2018 at 11:44:42AM +0200, Ludovic Courtès wrote:
> Hello!
> 
> Clément Lassieur  skribis:
> 
> > I think we need https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30602 to
> > be fixed.
> 
> Done.   \o/
> 
> With Guile 2.2.4 now released, we can go ahead with 0.15.  Could people
> build the ISO installation image and give it a try:
> 
>   guix system disk-image --file-system-type=iso9660 gnu/system/install.scm

This fails (as expected) on aarch64-linux.

> 
> and then boot the resulting image (you can do that in QEMU if you
> prefer), and follow the instructions.
> 
> Likewise, tests of the binary Guix tarball would be welcome.  You can
> build it with:
> 
>   make guix-binary.x86_64-linux.tar.xz
> 

make guix-binary.aarch64-linux.tar.xz works as exptected



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


signature.asc
Description: PGP signature

Re: guix package is slow

[Maxim Cournoyer]

Hi!

l...@gnu.org (Ludovic Courtès) writes:

> Hello!
>
> Maxim Cournoyer  skribis:
>
>> swedebu...@riseup.net writes:
>>
>>> Hi
>>>
>>> I would like guix package -A/s to be faster.
>>> There it takes >3s every time I run the command.
>
> It’s at 1.5s for me on an SSD and a hot cache, but I agree that overall
> it’s too slow.
>
>> I agree that Guix is rather slow when comparing it to traditional
>> package managers such as apt; I think the main reason, as you found, is
>> that it has to load all the byte-compiled package definition files.
>
> That, and also it generally has “more work” to do (see ‘apt-get update’
> vs. ‘guix pull’, or even ‘guix package -i emacs’ vs. ‘apt-get install
> emacs’.)  That’s not meant as an excuse, just a clarification of what’s
> going on.

True, especially for guix pull ;)

>>> Would it be possible to populate an index or something when pulling so
>>> that we have the information in a sqlite-db instead of traversing 40
>>> go-files with guile?
>>
>> I remember asking Ludovic in #guix if Guile would be able to compete
>> with database software in terms of performance, and he said there are
>> ways we can make it faster.
>
> I think we could easily optimize package lookups by name.  Instead of
> traversing the whole list of package modules to build up a name/package
> table, we could have a pre-built cache containing that mapping.  That
> way, when typing “guix build emacs”, we could essentially translate that
> to “guix build -e '(@ (gnu packages emacs) emacs)'”, which is a little
> bit faster.
>
> We could arrange for the cache to be enough for operations such as “guix
> package -A”, so that we don’t need to load a single package module.
>
>> I'm not very knowledgeable myself about Guile but if we could make it
>> support static linking, to load only one binary rather than hundreds
>> in the case of Guix, that would be one way to speed things. Next thing
>> might be to implement native compilation.
>
> You might like this:
>
>   https://lists.gnu.org/archive/html/guile-devel/2018-06/msg00026.html

Interesting developments are coming to Guile, it seems :). I'm happy to
see that Andy is still driving Guile forward. Thanks!

>>> On an older guixsd with about 4k packages the delay was noticeably
>>> shorter. 
>>
>> I guess the time it takes grows linearly (I hope!) with the number of
>> packages/modules it has to load. We're now at double that amount of
>> packages (IIRC), so Guix might take double the time it used to.
>
> Yeah, that’s why the cache is probably unavoidable.

Thanks for sharing your insights on the matter!

Maxim

Fix for teeworlds

[Tim Gesthuizen]

Hi,

I am using GNU Guix now for a little while and since I started using it

teeworlds did not build.

So I invested some time and quickly found out that the package definition

is simply missing a dependency (pkg-config) to build.

You find a script which I used to create my working build as well

as a patch for guix which I have not verified to  be working attached.

It would be very nice if someone could investigate whether the patch

is ok and commit it.


Thanks,

Tim Gesthuizen

(use-modules ((guix licenses) #:prefix license:)
	 (guix utils)
	 (guix packages)	  
	 (guix download)
	 (gnu packages)
	 (gnu packages gl)
	 (gnu packages sdl)
	 (gnu packages audio)
	 (gnu packages build-tools)
	 (gnu packages python)
	 (gnu packages fontutils)
	 (gnu packages compression)
	 (gnu packages pkg-config)
	 (guix build-system gnu))

(package
 (name "my-teeworlds")
 (version "0.6.4")
 (source (origin
  (method url-fetch)
  (uri (string-append "https://github.com/teeworlds/teeworlds/";
  "archive/" version "-release.tar.gz"))
  (file-name (string-append name "-" version ".tar.gz"))
  (sha256
   (base32
"1mqhp6xjl75l49050cid36wxyjn1qr0vjx1c709dfg1lkvmgs6l3"))
  (modules '((guix build utils)))
  (snippet
   '(begin
  (for-each delete-file-recursively
'("src/engine/external/wavpack/"
  "src/engine/external/zlib/"))
  #t))
  (patches
   (search-patches "teeworlds-use-latest-wavpack.patch"
 (build-system gnu-build-system)
 (arguments
  `(#:tests? #f ; no tests included
#:phases
(modify-phases %standard-phases
		   (replace 'configure
			(lambda* (#:key outputs #:allow-other-keys)
			  ;; Embed path to assets.
			  (substitute* "src/engine/shared/storage.cpp"
	   (("#define DATA_DIR.*")
	(string-append "#define DATA_DIR \""
			   (assoc-ref outputs "out")
			   "/share/teeworlds/data"
			   "\"")))

			  ;; Bam expects all files to have a recent time stamp.
			  (for-each (lambda (file)
	  (utime file 1 1))
	(find-files "."))

			  ;; Do not use bundled libraries.
			  (substitute* "bam.lua"
	   (("if config.zlib.value == 1 then")
	"if true then")
	   (("wavpack = .*")
	"wavpack = {}
settings.link.libs:Add(\"wavpack\")\n"))
			  (substitute* "src/engine/client/sound.cpp"
	   (("#include ")
	"#include "))
			  #t))
		   (replace 'build
			(lambda _
			  (zero? (system* "bam" "-a" "-v" "release"
		   (replace 'install
			(lambda* (#:key outputs #:allow-other-keys)
			  (let* ((out  (assoc-ref outputs "out"))
 (bin  (string-append out "/bin"))
 (data (string-append out "/share/teeworlds/data")))
(mkdir-p bin)
(mkdir-p data)
(for-each (lambda (file)
	(install-file file bin))
	  '("teeworlds" "teeworlds_srv"))
(copy-recursively "data" data)
#t))
 ;; FIXME: teeworlds bundles the sources of "pnglite", a two-file PNG
 ;; library without a build system.
 (inputs
  `(("freetype" ,freetype)
("glu" ,glu)
("mesa" ,mesa)
("sdl-union" ,(sdl-union (list sdl
   sdl-mixer
   sdl-image)))
("wavpack" ,wavpack)
("zlib" ,zlib)))
 (native-inputs
  `(("bam" ,bam)
("python" ,python-2)
("pkg-config" ,pkg-config)))
 (home-page "https://www.teeworlds.com";)
 (synopsis "2D retro multiplayer shooter game")
 (description "Teeworlds is an online multiplayer game.  Battle with up to
16 players in a variety of game modes, including Team Deathmatch and Capture
The Flag.  You can even design your own maps!")
 (license license:bsd-3))
From ec193500a2644ddf7db17b2302ebae54342228f3 Mon Sep 17 00:00:00 2001
From: Tim Gesthuizen 
Date: Mon, 2 Jul 2018 17:10:50 +0200
Subject: [PATCH] Fixes missing pkg-config dependency for teeworlds

teeworlds uses bam as a build system which relies
on pkg-config for finding libraries like freetype.
Therefore pkg-config is needed to build this package.

Signed-off-by: Tim Gesthuizen 
---
 gnu/packages/games.scm | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/games.scm b/gnu/packages/games.scm
index 0796e4800..ecca036be 100644
--- a/gnu/packages/games.scm
+++ b/gnu/packages/games.scm
@@ -3880,7 +3880,8 @@ settings.link.libs:Add(\"wavpack\")\n"))
("zlib" ,zlib)))
 (native-inputs
  `(("bam" ,bam)
-   ("python" ,python-2)))
+   ("python" ,python-2)
+   ("pkg-config" ,pkg-config)))
 (home-page "https://www.teeworlds.com";)
 (synopsis "2D retro multiplayer shooter game")
 (description "Teeworlds is an online multiplayer game.  Battle with up to
-- 
2.18.0



signature.asc
Description: OpenPGP digital signature

Re: Fix for teeworlds

[Ricardo Wurmus]

Hi Tim,

thank you for your patch!

I have added a copyright line for you and adjusted the commit message.
Thanks to you, teeworlds now builds since commit e402a66b0.

Thanks again!

-- 
Ricardo

Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.

[Mark H Weaver]

Hi Marius,

mba...@fastmail.com (Marius Bakke) writes:

> mbakke pushed a commit to branch staging
> in repository guix.
>
> commit cb4b508cd68df89bfbd5255a0c5569f8318ad50f
> Author: Marius Bakke 
> Date:   Mon Jul 2 12:07:58 2018 +0200
>
> build-system/meson: Really skip the 'fix-runpath' phase on armhf.
> 
> This follows up commit d5b5a15a4046362377f1a45d466b43bb6e93d4f which 
> doesn't
> work because %current-system etc expands before the actual build.

I'm disappointed by this workaround that simply removes the
'fix-runpath' phase on armhf.  Is that phase needed, or is it truly
optional?  What does the phase accomplish, and how will armhf users be
disadvantaged by the removal of that phase?

This feels like "sweeping the problem under the rug" to me.

> Fixes .

I don't see the connection between that bug and this commit.
How does this commit fix that bug?

  Thanks,
Mark

Cuirass changes

[Clément Lassieur]

Hi,

I'm currently working on Cuirass, so that it looks a bit more like
Hydra.  The changes include:

1. Adding support for multiple inputs.  Currently Cuirass only supports
one input per specification, which has to be the Guix git repository.
But one might want inputs for:
  - a repository containing the 'proc' that returns the jobs,
  - a repository containing extra packages (GUIX_PACKAGE_PATH).
Those inputs would be fetched at INTERVAL as well, and any change would
trigger an evaluation.  This is a follow-up of
https://lists.gnu.org/archive/html/guix-patches/2018-06/msg00311.html.

2. Removing the notion of 'project'.  Cuirass really has no project, and
what is called a 'project' is in fact a 'specification' (which Hydra
calls 'jobset').  And what is called a 'jobset' by Cuirass is in fact
the branch of the Guix input.  So the patch associates to the name
'jobset' what it really is: a specification.  A consequence is that the
'jobset' filtering of the API now filters by specification name, and it
is not possible anymore to filter by branch.  (But it was useless IMHO.)

3. Allowing any input to be in Guile's %load-path when 'proc' is called.
Usually, the only input that is in Guile's %load-path is Guix.  But
someone might want to use a custom library in 'proc'.  The alternative
is to just specify the Guix input that should be appended to Guile's
%load-path.

(I'm unsure about 3., I can't find any real use case.  That would just
make it more flexible I guess.)

Also, some specification fields (#:load-path-inputs,
#:package-path-inputs, #:proc-input) refer to the inputs by their name,
as Hydra does (with nixExprInput).  This makes it easy to do
configuration mistakes, and would ultimately require a configuration
syntax checker.  The only alternative I can think of involves
duplicating the inputs, which isn't good.

I'm sending this email because even though the patches are already done
and they work on my Cuirass instance, there are a few other things to do
before I can send them:
  - add a mechanism to update the database,
  - update the documentation.
So if you think I'm not on the right track, please let me know as soon
as possible :-)

I attached my configuration before those patches and the one after them,
so that you can see how the new configuration would look like.  The work
in progress is available at
https://git.lassieur.org/cgit/cuirass.git/log/.

Clément


old.scm
Description: Binary data


new.scm
Description: Binary data

Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.

[Marius Bakke]

Mark H Weaver  writes:

> Hi Marius,
>
> mba...@fastmail.com (Marius Bakke) writes:
>
>> mbakke pushed a commit to branch staging
>> in repository guix.
>>
>> commit cb4b508cd68df89bfbd5255a0c5569f8318ad50f
>> Author: Marius Bakke 
>> Date:   Mon Jul 2 12:07:58 2018 +0200
>>
>> build-system/meson: Really skip the 'fix-runpath' phase on armhf.
>> 
>> This follows up commit d5b5a15a4046362377f1a45d466b43bb6e93d4f which 
>> doesn't
>> work because %current-system etc expands before the actual build.
>
> I'm disappointed by this workaround that simply removes the
> 'fix-runpath' phase on armhf.  Is that phase needed, or is it truly
> optional?  What does the phase accomplish, and how will armhf users be
> disadvantaged by the removal of that phase?
>
> This feels like "sweeping the problem under the rug" to me.

It *is* sweeping the problem under the rug, no doubt.  The only
alternatives I can see is fixing patchelf on armhf, which is difficult
for me without access to hardware; fixing Meson itself, which may be
easier, but then we may not be able to merge staging in a long time; or
implement patchelf functionality in Guix as Ludovic started with
 and is currently in 'core-updates'.

Do you have other suggestions?

>> Fixes .
>
> I don't see the connection between that bug and this commit.
> How does this commit fix that bug?

Whoops, typo.  It should be .


signature.asc
Description: PGP signature

Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.

[Marius Bakke]

Mark H Weaver  writes:

> Hi Marius,
>
> mba...@fastmail.com (Marius Bakke) writes:
>
>> mbakke pushed a commit to branch staging
>> in repository guix.
>>
>> commit cb4b508cd68df89bfbd5255a0c5569f8318ad50f
>> Author: Marius Bakke 
>> Date:   Mon Jul 2 12:07:58 2018 +0200
>>
>> build-system/meson: Really skip the 'fix-runpath' phase on armhf.
>> 
>> This follows up commit d5b5a15a4046362377f1a45d466b43bb6e93d4f which 
>> doesn't
>> work because %current-system etc expands before the actual build.
>
> I'm disappointed by this workaround that simply removes the
> 'fix-runpath' phase on armhf.  Is that phase needed, or is it truly
> optional?  What does the phase accomplish, and how will armhf users be
> disadvantaged by the removal of that phase?

I'm sorry, I forgot to address your actual concerns.  The (buggy)
workaround was put in place and discussed in
.  The meat of it can be found in (guix
build-system meson):

;; XXX PatchELF fails to build on armhf, so we skip
;; the 'fix-runpath' phase there for now.  It is used
;; to avoid superfluous entries in RUNPATH as described
;; in , so armhf may now
;; have different runtime dependencies from other arches.

Now, I'm not proud of this "workaround", but it's not exactly new, so I
don't see why we should rush to fix it now.  Given how late we are in
this staging cycle, I would prefer delaying any proper fix until the
next round.


signature.asc
Description: PGP signature

Re: guix package is slow

[Alex Kost]

Maxim Cournoyer (2018-07-02 10:55 -0400) wrote:

> Hi,
>
> Oleg Pykhalov  writes:
>
>> Hello,
>>
>> Pierre Neidhardt  writes:
>>
>>> Maxim Cournoyer  writes:
>>>
> - Perform transactions (install/remove) over multiple packages.

 To be fair, I think you can already accomplish this using emacs-guix by
 separating with commas multiple package names :).
>>>
>>> Can you explain?  I don't know how to do that.
>>>
>>> The point of the Helm interface is that it allows to "batch select"
>>> multiple packages.  I don't think that emacs-guix can do that.
>>
>> […]
>>
>> Another way in ‘M-x guix-all-packages’ or any ‘guix-search-by-*’:
>>
>>   • Hit ‘i’ on not installed packages.
>>   • Hit ‘d’ on installed package.
>>   • Hit ‘x’ to apply.
>
> Thanks Oleg! I keep forgetting about this interface;

he-he, it is only one of about 10 different interfaces of this kind (for
packages, profiles, generations, services, etc.).  If you use only "M-x
guix", you miss most of Emacs-Guix features.

> there doesn't seem
> to be an entry point from M-x guix for easy discovery.

"M-x guix" can't be an entry point for this or any other interface, it
is only for "guix" *shell* commands.  Actually I'm very surprised
someone uses "M-x guix", I find it unpractical.  I even plan to rename
it to "M-x guix-command", and to make "M-x guix" a real entry point for
the various Emacs-Guix commands (including "guix-command" and all the
interfaces).

-- 
Alex

Re: guix package is slow

[Alex Kost]

Pierre Neidhardt (2018-07-01 21:41 +0200) wrote:

> Maxim Cournoyer  writes:
>
>>> - Perform transactions (install/remove) over multiple packages.
>>
>> To be fair, I think you can already accomplish this using emacs-guix by
>> separating with commas multiple package names :).
>
> Can you explain?  I don't know how to do that.
>
> The point of the Helm interface is that it allows to "batch select"
> multiple packages.  I don't think that emacs-guix can do that.
>
> For instance, if I want to install all Emacs packages except, say,
> emacs-guix (haha! :p) then I would
>
> - M-x helm-system-packages
> - "emacs"
> - M-a
> - "emacs-guix"
> - C-space
> - 

As Oleg wrote, in Emacs-Guix you can use an interface for packages: "M-x
guix-search-by-name emacs", then mark whatever you want to install with
"i" and press "x" to run the operation.

-- 
Alex

Re: Next steps

[Sahithi Yarlagadda]

Hi

Please review the patch and assign me the what to do next.


On Saturday 30 June 2018 04:21 AM, Sahithi Yarlagadda wrote:
> Hi
>
>
>>> a spinning animation.  For each line the animation could be advanced by
>>> one (so it will spin really fast).
>>>
>>> Danny previously suggested this implementation:
>>>
>>>https://lists.gnu.org/archive/html/guix-patches/2017-07/msg00068.html
> I have tried the Spinner code and it worked fine for me
>
> https://paste.debian.net/1031385/
> I used usleep so that I could to see the characters spinning with a
> little delay to understand the code.
>
>
> I tried to use the same for ui.scm, the  i replaced str with
> spinner-port in handle-string code. I got the following
>  15fb4d0>### 15fb4d0>#
>
>
> I understood that i am working on a softport and unable to figure out
> how to pass the string without invoking the display/write. I took a lot
> of time and failed.
>
>
> Here comes the actual part,
> Later i discussed with #ArneBab in #guile who helped be finish the code.
> I felt that invoking the spinner each time a string is triggered would
> be sufficient and it doesnt matter whatever might be the string apart
> from the expressions which are colorized, so went on to write the code
> which i am submitting as a patch. For this i had to try a lot of new
> syntaxes.
>
>
> Now the spinner is working fine, build messages are colored and the
> whole build process looks understandable to the user.
>
> Actually im a bit excited to see the spinner code working and the
> build output. Just wanted to share that to the community.
>
>
> Please review the patch and push it to wip-sahithi if the progress is
> correct.
>
>> Have fun!
>>
>> --
>> Ricardo
>>
>>

-- 
Regards
Sahithi