Re: Guile-SQLite3 0.1.1 released

[Aleix Conchillo Flaqué]

On Tue, Jun 9, 2020 at 2:20 PM Danny Milosavljevic 
wrote:

> I’m pleased to announce Guile-SQLite3 version 0.1.1:
>
>   git clone https://notabug.org/guile-sqlite3/guile-sqlite3.git
>   cd guile-sqlite3
>   git checkout v0.1.1
>   git tag -v v0.1.1
>
> The ‘git tag -v’ command checks the authenticity of your checkout.
> You may need to retrieve the signing key first:
>
>   gpg --keyserver keys.gnupg.net
>   --recv-keys 76CEC6B17274B465C02DB3D9E71A35542C30BAA5
>
> Guile-SQLite3 provides Guile 2.x and Guile 3.x bindings to the SQLite
> database
> engine.
> It was originally written by Andy Wingo, with contributions from several
> people.
>
> Changes to the previous release are:
>
> * sqlite-finalize: Reset statement when called on cached statement.
> * Fix memory management of retrieved blob values.
>
> Danny.
>

Great! This is now available from Guile Homebrew Tap:

$ brew tap aconchillo/guile
$ brew install guile-sqlite3

Aleix

Guile-SQLite3 0.1.1 released

[Danny Milosavljevic]

I’m pleased to announce Guile-SQLite3 version 0.1.1:

  git clone https://notabug.org/guile-sqlite3/guile-sqlite3.git
  cd guile-sqlite3
  git checkout v0.1.1
  git tag -v v0.1.1

The ‘git tag -v’ command checks the authenticity of your checkout.
You may need to retrieve the signing key first:

  gpg --keyserver keys.gnupg.net
  --recv-keys 76CEC6B17274B465C02DB3D9E71A35542C30BAA5

Guile-SQLite3 provides Guile 2.x and Guile 3.x bindings to the SQLite database
engine.
It was originally written by Andy Wingo, with contributions from several
people.

Changes to the previous release are:

* sqlite-finalize: Reset statement when called on cached statement.
* Fix memory management of retrieved blob values.

Danny.


pgpbp3NlYZDsL.pgp
Description: OpenPGP digital signature

Re: Manual consistency

[George Clemmer]

zimoun  writes:

> (from: http://issues.guix.gnu.org/issue/41253#10)
>
> On Fri, 5 Jun 2020 at 18:36, Ludovic Courtès  wrote:
>
>> > There are many examples in guix.texi with $, and also many without. Plus
>> > some with # as the command line prompt.

>> I’ve come to the conclusion that snippets that contain only input should
>> be written without a prompt, for easier copy/pasting.

> I propose to do a pass on that:
>  - apply this rule: no-$ for only input and $ to distinguish between
> inputs and outputs.

+1.

For examples w/ outputs, how about also removing the $ and commenting
the outputs with '# ', or '# > '?

HTH - George

[PATCH] sql: Add a couple of indexes.

[Christopher Baines]

Remove the Builds_index from the schema, as it would have been removed in
error by the upgrade-6 upgrade.  Add a specific index on the Builds status
field, as this helps with db-get-builds queries, and add an index on the
Outputs derivation field, as this helps with the db-get-outputs part of
db-get-builds.

* src/sql/upgrade-7.sql: New file.
* src/schema.sql: Update accordingly.
---
 src/schema.sql| 3 ++-
 src/sql/upgrade-7.sql | 7 +++
 2 files changed, 9 insertions(+), 1 deletion(-)
 create mode 100644 src/sql/upgrade-7.sql

diff --git a/src/schema.sql b/src/schema.sql
index 1104551..60d250a 100644
--- a/src/schema.sql
+++ b/src/schema.sql
@@ -74,7 +74,8 @@ CREATE TABLE Events (
 
 -- Create indexes to speed up common queries, in particular those
 -- corresponding to /api/latestbuilds and /api/queue HTTP requests.
-CREATE INDEX Builds_index ON Builds(job_name, system, status ASC, timestamp 
ASC, derivation, evaluation, stoptime DESC);
+CREATE INDEX Builds_status_index ON Builds (status);
+CREATE INDEX Outputs_derivation_index ON Outputs (derivation);
 CREATE INDEX Inputs_index ON Inputs(specification, name, branch);
 
 COMMIT;
diff --git a/src/sql/upgrade-7.sql b/src/sql/upgrade-7.sql
new file mode 100644
index 000..1be3470
--- /dev/null
+++ b/src/sql/upgrade-7.sql
@@ -0,0 +1,7 @@
+BEGIN TRANSACTION;
+
+CREATE INDEX Builds_status_index ON Builds (status);
+
+CREATE INDEX Outputs_derivation_index ON Outputs (derivation);
+
+COMMIT;
-- 
2.26.2

Re: Manual consistency

[Julien Lepiller]

Le 9 juin 2020 13:13:31 GMT-04:00, Ricardo Wurmus  a écrit :
>
>Ludovic Courtès  writes:
>
>> Hi,
>>
>> Ricardo Wurmus  skribis:
>>
>>> Julien Lepiller  writes:
>>>
 If there is a way to mark a sentence to wrap it into a class, we
>could
 also do some CSS magic with :before.
>>>
>>> Texinfo puts all examples inside div.example pre.example, but the
>>> individual lines are not wrapped in spans, so we cannot style each
>line
>>> individually.  A :before rule would thus only change the first line,
>>> which is not enough.
>>
>> What about adding some more post-processing in doc/build.scm?  :-)
>
>If we’re okay with wrapping individual lines in @code{…} that won’t be
>necessary.  Having each logical line of code within @code results in
>
>  
>this line
>that line
>  
>
>and that’s something we *can* style with CSS.

But we can't differentiate root commands and user commands that way.

Re: Manual consistency

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Hi,
>
> Ricardo Wurmus  skribis:
>
>> Julien Lepiller  writes:
>>
>>> If there is a way to mark a sentence to wrap it into a class, we could
>>> also do some CSS magic with :before.
>>
>> Texinfo puts all examples inside div.example pre.example, but the
>> individual lines are not wrapped in spans, so we cannot style each line
>> individually.  A :before rule would thus only change the first line,
>> which is not enough.
>
> What about adding some more post-processing in doc/build.scm?  :-)

If we’re okay with wrapping individual lines in @code{…} that won’t be
necessary.  Having each logical line of code within @code results in

  
this line
that line
  

and that’s something we *can* style with CSS.

-- 
Ricardo

Re: Canonical-packages restoration.

[Ludovic Courtès]

Hi,

Mathieu Othacehe  skribis:

> With f30d84d32db0f4f6cb84e139868e1727a7dc0a51 and
> dfc8ccbf5da96a67eb1cade499f0def21e7fdb02, I did remove most of the
> "canonical-package" calls because they were breaking system
> cross-compilation.
>
> Now, I'd like to somehow restore them, using the new "let-system". 

What if, instead, we removed those “canonical” packages entirely from
the reference graph?  Do you think that’s an option?

> My idea is to define something like:
>
> (define (canonical-package* package)
>   (let ((canonical
>  (module-ref (resolve-interface '(gnu packages base))
>  'canonical-package)))
> (let-system (system target)
>   (if target
>   package
>   (canonical package)

Aren’t there pieces of code that expect these things to be 
records?

> However, it seems that nesting a "let-system" inside "file-append" does
> not work:
>
> (use-modules (guix))
> (use-modules (gnu))
>
> (run-with-store (open-connection)
>   (mlet* %store-monad
>   ((drv (lower-object
>  (computed-file "computed"
> #~(begin
> (mkdir #$output)
> (symlink #$(file-append
> (let-system (s t) glibc) "/bin")
>  (string-append #$output "/ref"))
>(output -> (derivation->output-path drv)))
> (mbegin %store-monad
>   (built-derivations (list drv))
>   (return (format #t "~a~%" output)
>
> and it prevents me from going further. Does this stuff make any sense?
> If yes I can try to fix it, but I just want to be sure first :)

Bah yes, that’s why initially I didn’t push ‘let-system’:

  https://issues.guix.gnu.org/29296#4

Perhaps we could avoid the expander = #f special case.

Thanks,
Ludo’.

Re: Secrets in (generated) configs. How to deal with them?

[Ludovic Courtès]

Hi,

raingloom  skribis:

> I'm trying to package Yggdrasil as a Guix service and I took a look at
> what NixOS does and they actually don't simply generate the config in
> the store, instead it's combined with another input of the service and
> the combined JSON is fed to Yggdrasil on stdin.
>
> Is this how I should do it as well? Or maybe the Guix store can make
> some outputs private?

This is one of the things we discussed at the Guix Days:

  
https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/guix-days-2020/guix-secrets.org

One of the ideas we came up with that could fly is to have a
‘secret-service-type’ (ah ha!), which you could extend with key/value
pairs.  At run time, secrets could be fetched from the local file
system or by querying a daemon.

Food for thought!

Ludo’.

Re: The size of ‘.go’ files

[Ludovic Courtès]

Hello!

Andy Wingo  skribis:

> A few points of information :)

Much appreciated!

> The guile.arities section starts with a sorted array of fixed-size
> headers, then is followed by a sequence of ULEB128 references to local
> variable names, including non-arguments.  The size is a bit perplexing,
> I agree.  I can think of a number of ways to encode that section
> differently but we'd need to understand a bit more about it and why the
> baseline compiler is significantly different.

‘.guile.arities’ size should be proportional to the number of
procedures, right?  Additionally, if there are only/mostly thunks, the
string table for argument names should be small if not empty.  For N
thunks, I would expect roughly N 28-byte headers + NxM UL128, say 100
bytes per thunk; there’s 1000 of them, so we should be ~100,000 bytes.
This is roughly what we get observe with the baseline compiler.

>> “.rtl-text” is 38% smaller and “.guile.arities” is almost a tenth of
>> what it was.
>
> The difference in the text are the new baseline intrinsics,
> e.g. $vector-ref.  It goes in the opposite direction from instruction
> explosion, which sought to (1) make the JIT compiler easier by
> decomposing compound operations into their atomic parts, (2) make the
> optimizer learn more information from flow rather than type-checking
> side effects, and (3) allow the optimizer to eliminate / hoist / move
> the component pieces of macro-operations.
>
> However in the baseline compiler (2) and (3) aren't possible because
> there is no optimizer on that level, and therefore the result is
> actually a lose -- 10 micro-ops cost more than 1 macro-op because of
> stack traffic overhead, which isn't currently mitigated by the JIT (1).
>
> So instruction explosion is residual code explosion, which should pay
> off in theory, but not for the baseline compiler.  So I added new
> intrinsics for e.g. $vector-ref et al.  Thus the smaller code size.

Yes, that makes a lot of sense.  In particular, this file must use the
struct intrinsics a lot.

> There are more possibilities for making code size smaller, e.g. having
> two equivalent encodings for bytecode, where one is smaller:
>
>   https://webkit.org/blog/9329/a-new-bytecode-format-for-javascriptcore/

Like THUMB, but for bytecode.  :-)

I guess we could first analyze the generated code more closely and see
if there are opportunities there.

Thanks for the explanations!

Ludo’.

Re: Advice on package naming

[Ludovic Courtès]

Hi Hartmut,

Hartmut Goebel  skribis:

> I'm still seeking advice on how to name these packages, since the
> original packages have
> quiet uncommon names. Shall I keep the names I'm currently using, or are
> there any other suggestions?
>
> Current names:
>
> pep-engine
> libpepadapter.
> python-pep-adapter
> java-pep-adapter

That LGTM, I think it’s pretty much in line with:

  https://guix.gnu.org/manual/en/html_node/Package-Naming.html

Thanks,
Ludo’.

Re: Manual consistency

[Ludovic Courtès]

Hi,

Ricardo Wurmus  skribis:

> Julien Lepiller  writes:
>
>> If there is a way to mark a sentence to wrap it into a class, we could
>> also do some CSS magic with :before.
>
> Texinfo puts all examples inside div.example pre.example, but the
> individual lines are not wrapped in spans, so we cannot style each line
> individually.  A :before rule would thus only change the first line,
> which is not enough.

What about adding some more post-processing in doc/build.scm?  :-)

Ludo’.

Re: Heads-up: “pre-push” Git hook updated

[Ludovic Courtès]

Hi,

Vagrant Cascadian  skribis:

> On 2020-05-29, Ludovic Courtès wrote:
>> Ludovic Courtès  skribis:
>>
>>> I think we should change our pre-push hook as shown below.
>>
>> I’ve pushed it in e65a44649e8d7698c4a888f1de625a67052520e9.
>> To all committers: please do use it from now on:
>>
>>   cp etc/guix/pre-push .git/hooks/
>>
>> If you never run “make authenticate” before, the first run takes a few
>> minutes.  You might want to run it before your first ‘git push’.
>>
>> Please report any issues, slowness, errors, unhappiness, whatever!
>
> $ guix environment --pure guix --ad-hoc guile git gnupg -- make authenticate
> ...
> configure: checking for guile 3.0
> configure: checking for guile 2.2
> configure: error:
> No Guile development packages were found.
>
> Without --pure i'm getting the same thing.

What does ‘config.log’ say?

The above could happen if ‘guile-3.0.pc’ or ‘guile-2.2.pc’ is not in
$PKG_CONFIG_PATH, but I don’t see why that would happen here:

--8<---cut here---start->8---
$ guix environment --pure guix --search-paths
export 
PATH="/gnu/store/wpizavgr4p8cp8bryxg1dxac4h47xhzh-profile/bin:/gnu/store/wpizavgr4p8cp8bryxg1dxac4h47xhzh-profile/sbin"
export 
PKG_CONFIG_PATH="/gnu/store/wpizavgr4p8cp8bryxg1dxac4h47xhzh-profile/lib/pkgconfig"
export 
GUILE_LOAD_PATH="/gnu/store/wpizavgr4p8cp8bryxg1dxac4h47xhzh-profile/share/guile/site/3.0"
export 
GUILE_LOAD_COMPILED_PATH="/gnu/store/wpizavgr4p8cp8bryxg1dxac4h47xhzh-profile/lib/guile/3.0/site-ccache:/gnu/store/wpizavgr4p8cp8bryxg1dxac4h47xhzh-profile/share/guile/site/3.0"
export 
ACLOCAL_PATH="/gnu/store/wpizavgr4p8cp8bryxg1dxac4h47xhzh-profile/share/aclocal"
export INFOPATH="/gnu/store/wpizavgr4p8cp8bryxg1dxac4h47xhzh-profile/share/info"
export 
C_INCLUDE_PATH="/gnu/store/wpizavgr4p8cp8bryxg1dxac4h47xhzh-profile/include"
export 
CPLUS_INCLUDE_PATH="/gnu/store/wpizavgr4p8cp8bryxg1dxac4h47xhzh-profile/include/c++:/gnu/store/wpizavgr4p8cp8bryxg1dxac4h47xhzh-profile/include"
export LIBRARY_PATH="/gnu/store/wpizavgr4p8cp8bryxg1dxac4h47xhzh-profile/lib"
export 
GUIX_LOCPATH="/gnu/store/wpizavgr4p8cp8bryxg1dxac4h47xhzh-profile/lib/locale"
$ ls 
/gnu/store/wpizavgr4p8cp8bryxg1dxac4h47xhzh-profile/lib/pkgconfig/guile-3.0.pc
/gnu/store/wpizavgr4p8cp8bryxg1dxac4h47xhzh-profile/lib/pkgconfig/guile-3.0.pc
--8<---cut here---end--->8---

Note that you don’t need to explicitly add guile, git, and gnupg.

Thanks,
Ludo’.

Re: GNOME minimal

[Pierre Neidhardt]

Pierre Neidhardt  writes:

> A lighter system has the benefits of:
>
> - being easier on Internet bandwidth,
> - updating faster.

And obviously lighter and disk space! ;)

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

Re: GNOME minimal

[Alexey Abramov]

Pierre Neidhardt  writes:

> Alexey Abramov  writes:
>
>> Do you consider gnome-keyring to be a part of gnome-minimal?
>
> I would say yes, but that's debatable of course :p
>
>> If you do, gcr - gnome keyring prompter should also be added.
>
> Are you saying the gnome-keyring won't work without gcr?  Why?

I think it will, with some low level stuff, but I couldn't use it or even 
unlock it. Maybe there are other SystemPromters out there.

--8<---cut here---start->8---
May 31 20:32:02 localhost gnome-keyring-daemon[2992]: couldn't create system 
prompt: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
org.gnome.keyring.SystemPrompter was not provided by any .service files
May 31 20:32:24 localhost gnome-keyring-daemon[2992]: couldn't create system 
prompt: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
org.gnome.keyring.SystemPrompter was not provided by any .service files
May 31 20:42:19 localhost gnome-keyring-daemon[2992]: couldn't create system 
prompt: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
org.gnome.keyring.SystemPrompter was not provided by any .service files
--8<---cut here---end--->8---

--
Alexey

Re: GNOME minimal

[Alexey Abramov]

Hi Pierre,

Do you consider gnome-keyring to be a part of gnome-minimal? If you do, gcr -
gnome keyring prompter should also be added. 

-- 
Alexey

Re: GNOME minimal

[Pierre Neidhardt]

Thanks, Tobias!

The definition below builds in a system, I haven't tried booting it yet:

--8<---cut here---start->8---
(define-public gnome-minimal
  (package
(inherit gnome)
(name "gnome-minimal")
(propagated-inputs
 ;; Keep nautilus.
 (fold alist-delete (package-propagated-inputs gnome)
   '(;; GNOME-Core-Shell
 "gnome-backgrounds"
 "gnome-themes-extra"
 "gnome-getting-started-docs"
 "gnome-user-docs"
 ;; GNOME-Core-Utilities
 "baobab"
 "cheese"
 "eog"
 "epiphany"
 "evince" ; REVIEW: Keep for gnome-default-applications?
 "file-roller"
 "gedit"
 "gnome-boxes"
 "gnome-calculator"
 "gnome-calendar"
 "gnome-characters"
 "gnome-clocks"
 "gnome-contacts"
 "gnome-disk-utility"
 "gnome-font-viewer"
 "gnome-maps"
 ;; "gnome-music"
 ;; "gnome-photos"
 "gnome-screenshot"
 ;; "gnome-system-monitor" ; Needed for gnome-polkit-settings
 "gnome-terminal"
 "gnome-weather"
 "simple-scan"
 "totem"
 ;; Others
 "gnome-online-accounts")
--8<---cut here---end--->8---

It saves close to 500 MiB in the closure size!  Not bad :)

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

Re: GNOME minimal

[Tobias Geerinckx-Rice]

Jonathan Brielmaier 写道：
So this is basically a plain Gnome shell withouth any programms? 
What is

the use-case for it?


s/without any programmes/with the programmes you actually choose 
to install/


‘gnome-desktop’ is a maximal beast, and is only going to get more 
so as Raghav's work progresses.  I don't think Guix should ship a 
‘gnome-minimal’ package (nor am I fiercely opposed), but it makes 
sense to modify things like gnome-polkit-settings to handle only 
keys that are actually present and ignore #f.


I presume that's what Pierre is doing right now; we'll see :-)

Kind regards,

T G-R


signature.asc
Description: PGP signature

Re: GNOME minimal

[Tobias Geerinckx-Rice]

Pierre,

Pierre Neidhardt 写道：

guix/ui.scm:1945:12: In procedure run-guix-command:
Throw to key `match-error' with args `("match" "no matching 
pattern" #f)'.
--8<---cut 
here---end--->8---


Any idea?


My immediate thought is: #f is what (assoc-ref l 
"non-existent-thing") returns.


And indeed:

(define (gnome-polkit-settings config)
 "Return the list of GNOME dependencies that provide polkit 
 actions and

rules."
 (let ((gnome (gnome-package config)))
   (map (lambda (name)
  ((package-direct-input-selector name) gnome))
'("gnome-settings-daemon"
  "gnome-control-center"
  "gnome-system-monitor"
  "gvfs"


You need to include gnome-system-monitor, or adjust the service 
too.


Kind regards,

T G-R


signature.asc
Description: PGP signature

Re: GNOME minimal

[Jonathan Brielmaier]

On 09.06.20 14:21, Pierre Neidhardt wrote:
> Hi!
>
> I've defined a minimal GNOME this way:
>
> --8<---cut here---start->8---
> (define-public gnome-minimal
>   (package
> (inherit gnome)
> (name "gnome-minimal")
> (propagated-inputs
>  ;; Keep nautilus.
>  (fold alist-delete (package-propagated-inputs gnome)
>'("baobab"
>  "cheese"
>  "eog"
>  "epiphany"
>  "evince"
>  "file-roller"
>  "gedit"
>  "gnome-boxes"
>  "gnome-calculator"
>  "gnome-calendar"
>  "gnome-characters"
>  "gnome-clocks"
>  "gnome-contacts"
>  "gnome-disk-utility"
>  "gnome-font-viewer"
>  "gnome-maps"
>  ;; "gnome-music"
>  ;; "gnome-photos"
>  "gnome-screenshot"
>  "gnome-system-monitor"
>  "gnome-terminal"
>  "gnome-weather"
>  "simple-scan"
>  "totem")
> --8<---cut here---end--->8---

So this is basically a plain Gnome shell withouth any programms? What is
the use-case for it?

gcc-10 toolchain does not include string to numeric conversion functions like std::stoull

[Erik Garrison]

Hello guix-devel,

I've run into a quirk in the various gcc toolchains that seems somewhat
unique to guix builds of them. I'd like to understand if this is
intentional.

Initially, I found that string to numeric conversion functions that are
enabled by _GLIBCXX_USE_C99_STDLIB are not available on guix gcc toolchains
for gcc 8, 9, and 10.

This is a minimal test case to reproduce the problem:

Code:

#include 
#include 

uint64_t _parse_number(std::string::const_iterator& c, const
std::string::const_iterator& end) {
std::string::const_iterator s = c;
while (c != end and isdigit(*c)) ++c;
if (c > s) {
return std::stoull(std::string(s,c));
} else {
return 0;
}
}

int main(int argc, char** argv) {
std::string s(argv[1]);
std::string::const_iterator b = s.begin();
std::string::const_iterator e = s.end();
std::cout << _parse_number(b, e) << std::endl;
return 0;
}

Compiling with (g++ --version == 10.1.0),
/gnu/store/3kvnslc16sy7kwi2c5r7r5k6bbv2p03f-gcc-toolchain-10.1.0/bin/g++

g++ test-stoull.cpp -o test-stoull

Yields this error:

test-stoull.cpp: In function ‘uint64_t
_parse_number(std::__cxx11::basic_string::const_iterator&, const
const_iterator&)’:
test-stoull.cpp:13:33: error: invalid initialization of reference of type
‘const wstring&’ {aka ‘const std::__cxx11::basic_string&’} from
expression of type ‘std::string’ {aka ‘std::__cxx11::basic_string’}
   13 | return std::stoull(std::string(s,c));
  | ^~~
In file included from /home/erikg/.guix-profile/include/c++/string:55,
 from
/home/erikg/.guix-profile/include/c++/bits/locale_classes.h:40,
 from
/home/erikg/.guix-profile/include/c++/bits/ios_base.h:41,
 from /home/erikg/.guix-profile/include/c++/ios:42,
 from /home/erikg/.guix-profile/include/c++/ostream:38,
 from /home/erikg/.guix-profile/include/c++/iostream:39,
 from test-stoull.cpp:1:
/home/erikg/.guix-profile/include/c++/bits/basic_string.h:6697:25: note: in
passing argument 1 of ‘long long unsigned int std::__cxx11::stoull(const
wstring&, std::size_t*, int)’
 6697 |   stoull(const wstring& __str, size_t* __idx = 0, int __base = 10)
  |  ~~~^

I understand that there might be concern about my particular .guix-profile,
but it's possible to reproduce this in containers. I can provide more test
cases if needed, but I just wanted to clarify in general what I'm seeing.

This behavior appears to be similar to this issue:
http://freebsd.1045724.x6.nabble.com/base-gcc-and-GLIBCXX-USE-C99-td5781697.html.
It's also similar to this report,
https://stackoverflow.com/questions/40779611/g-compile-error-invalid-initialization-of-reference-of-type-stdstod
.

It may be more correct to require wstring in these kinds of conversions.
However, I'm concerned that if gcc is built differently in guix than it
typically is in other distributions, we will need to patch many libraries
when building them on guix. It's probably better to match typical
expectations of developers about the behavior of gcc.

Thanks in advance,

Erik

Re: Canonical-packages restoration.

[Mathieu Othacehe]

Hey Jan,

> Just a quick question: why?; would that reduce a system's closure size?

Yes mostly, even if the gains are not huge (~100MiB). However, I feel
like its easier the tackle the system closure size issue if we get rid
of the "noise".

Thanks,

Mathieu

Re: Canonical-packages restoration.

[Jan Nieuwenhuizen]

Mathieu Othacehe writes:

> With f30d84d32db0f4f6cb84e139868e1727a7dc0a51 and
> dfc8ccbf5da96a67eb1cade499f0def21e7fdb02, I did remove most of the
> "canonical-package" calls because they were breaking system
> cross-compilation.
>
> Now, I'd like to somehow restore them

Just a quick question: why?; would that reduce a system's closure size?

Janneke

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

Canonical-packages restoration.

[Mathieu Othacehe]

Hello,

With f30d84d32db0f4f6cb84e139868e1727a7dc0a51 and
dfc8ccbf5da96a67eb1cade499f0def21e7fdb02, I did remove most of the
"canonical-package" calls because they were breaking system
cross-compilation.

Now, I'd like to somehow restore them, using the new "let-system". My
idea is to define something like:

--8<---cut here---start->8---
(define (canonical-package* package)
  (let ((canonical
 (module-ref (resolve-interface '(gnu packages base))
 'canonical-package)))
(let-system (system target)
  (if target
  package
  (canonical package)
--8<---cut here---end--->8---

And then use for instance this way:

--8<---cut here---start->8---
diff --git a/gnu/system/locale.scm b/gnu/system/locale.scm
index 689d238d1a..fd50538e9a 100644
--- a/gnu/system/locale.scm
+++ b/gnu/system/locale.scm
@@ -106,7 +106,8 @@ of LIBC."
 
  ;; 'localedef' executes 'gzip' to access compressed locale sources.
  (setenv "PATH"
- (string-append #+gzip "/bin:" #+libc "/bin"))
+ (string-append #+gzip "/bin:"
+#+(canonical-package* libc) "/bin"))
--8<---cut here---end--->8---

However, it seems that nesting a "let-system" inside "file-append" does
not work:

--8<---cut here---start->8---
(use-modules (guix))
(use-modules (gnu))

(run-with-store (open-connection)
  (mlet* %store-monad
  ((drv (lower-object
 (computed-file "computed"
#~(begin
(mkdir #$output)
(symlink #$(file-append
(let-system (s t) glibc) "/bin")
 (string-append #$output "/ref"))
   (output -> (derivation->output-path drv)))
(mbegin %store-monad
  (built-derivations (list drv))
  (return (format #t "~a~%" output)
--8<---cut here---end--->8---

and it prevents me from going further. Does this stuff make any sense?
If yes I can try to fix it, but I just want to be sure first :)

Thanks,

Mathieu