Re: [BLOG] custom kernel config

[Efraim Flashner]

On Thu, May 16, 2019 at 08:15:16PM -0400, Mark H Weaver wrote:
> Hi Marius,
> 
> Marius Bakke  writes:
> 
> > I just want to point out an (IMO) easier way to provide a custom kernel
> > configuration, that does not involve the "make-linux-libre" procedure:
> >
> > (define-public linux-libre/custom
> >   (package
> > (inherit linux-libre)
> > (native-inputs
> >  `(("kconfig" ,(local-file "kernel.config"))
> >,@(alist-delete "kconfig"
> >(package-native-inputs linux-libre))
> >
> > At the end of the day, Linux-Libre is just a regular package that can be
> > inherited and overridden like any other :-)
> 
> I think this is the approach we should promote for now.  I would prefer
> to leave 'make-linux-libre' as an internal implementation detail, and
> hopefully one with a limited life span.
> 
>   Thanks,
> Mark

I've removed my custom E2140 kernel config example and replaced it with
the above example. I've changed "/custom" to "/E2140". I've also taken
the "Linux-Libre is just a ..." sentence and prepended it to the
example.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
title: Creating and using a custom Linux kernel on Guix System
date: 2019-05-20 00:00
author: Efraim Flashner
tags: kernel, customization
---

Guix is, at its core, a source based distribution with substitutes, and
as such building packages from their source code is an expected part of
regular package installations and upgrades.  Given this starting point,
it makes sense that efforts are made to reduce the amount of time spent
compiling packages, and recent changes and upgrades to the building and
distribution of substitutes continues to be a topic of discussion within
Guix.  One of the packages which I prefer to not build myself is the
Linux-Libre kernel.  The kernel, while not requiring an overabundance of
RAM to build, does take a very long time on my build machine (which my
children argue is actually their Kodi computer), and I will often delay
reconfiguring my laptop while I want for a substitute to be prepared by
the official build farm.  The official kernel configuration, as is the
case with many GNU/Linux distributions, errs on the side of
inclusiveness, and this is really what causes the build to take such a
long time when I build the package for myself.

The Linux kernel, however, can also just be described as a package
installed on my machine, and as such can be customized just like any
other package.  The procedure is a little bit different, although this
is primarily due to the nature of how the package definition is written.

The linux-libre kernel package definition is actually a procedure which
creates a package.

```scheme
(define* (make-linux-libre version hash supported-systems
   #:key
   ;; A function that takes an arch and a variant.
   ;; See kernel-config for an example.
   (extra-version #f)
   (configuration-file #f)
   (defconfig "defconfig")
   (extra-options %default-extra-linux-options)
   (patches (list %boot-logo-patch)))
  ...)
```

The current linux-libre package is for the 5.1.x series, and is
declared like this:

```scheme
(define-public linux-libre
  (make-linux-libre %linux-libre-version
%linux-libre-hash
'("x86_64-linux" "i686-linux" "armhf-linux" "aarch64-linux")
#:patches %linux-libre-5.1-patches
#:configuration-file kernel-config))
```

Any keys which are not assigned values inherit their default value from
the make-linux-libre definition.  When comparing the two snippets above,
you may notice that the code comment in the first doesn't actually refer
to the extra-version keyword; it is actually for configuration-file.
Because of this, it is not actually easy to include a custom kernel
configuration from the definition, but don't worry, there are other ways
to work with what we do have.

There are two ways to create a kernel with a custom kernel configuration.
The first is to provide a standard '.config' file during the build
process by including an actual '.config' file as a native-input to our
custom kernel.  The following is a snippet from the custom 'configure
phase of the make-linux-libre package definition:

```scheme
(let ((build  (assoc-ref %standard-phases 'build))
  (config (assoc-ref (or native-inputs inputs) "kconfig")))

  ;; Use a custom kernel configuration file or a default
  ;; configuration file.
  (if config
  (begin
(copy-file config ".config")
(chmod ".config" #o666))
  (invoke "make" ,defconfig))
```

Below is a sample kernel package for one of my computers.  Linux-Libre
is just like other regular packa

More progress with the Guix Data Service

[Christopher Baines]

Hey,

In summary, I think the Guix Data Service might be getting useful enough
that setting it up properly might be a good next step, and I'd be
interested in what others think?

A bit over a month ago, I sent out an update about one of the things
I've been working on, something I've been calling the "Guix Data
Service" [1].

1: https://lists.gnu.org/archive/html/guix-devel/2019-04/msg00094.html

Since then, I've made some more progress. There's a new statistics page
[2]. I've got used to using Sqitch [3] to help manage the database
schema, and I've added some basic tests.

2: https://prototype-guix-data-service.cbaines.net/statistic
3: http://guix.gnu.org/packages/sqitch-0./

The error handling for loading new revisions is also more resilient now.

As well as listening to the Guix Commits mailing list for emails about
new revisions, more of the information in these emails is now stored, in
particular, the time they were sent, and the branch the email applies
to. This can be seen on the new Branches page [4].

4: https://prototype-guix-data-service.cbaines.net/branches

The content negotiation a little bit, at least in terms of the code, and
JSON output support has been added to more pages.

There's now a basic search function on the packages page [5], and the
location, and the licenses for packages is now being stored (which can
be seen on the page for a package, for example [6]).

5: 
https://prototype-guix-data-service.cbaines.net/revision/f52e83470b05b2473ea13feb2842a1330c316a00/packages?search_query=Guile&field=version&field=synopsis&after_name=&limit_results=1000
6: 
https://prototype-guix-data-service.cbaines.net/revision/f52e83470b05b2473ea13feb2842a1330c316a00/package/0ad/0.0.23b-alpha

The location and license information is something I added specifically,
as I noticed the Repology [7] service scraped [8] these from the Guix
website.

7: https://repology.org/
8: 
https://github.com/repology/repology/blob/master/repology/fetchers/fetchers/guix.py

While the Guix Data Service started as something to enable better
understanding patches in an automated way, I think there are more uses
for it, and initially, it's probably better to focus on the simple ones.

The Repology use case is pretty simple, I think ideally there would be
some machine readable data about the current state of packages in Guix
available over the internet, and Repology would be able to download that
on a regular basis.

The URL is a bit long, but I think that is now close to being possible
with the Guix data service. I haven't got something working yet to
easily access data for the latest revision, but for a particular
revision, you can request a JSON file containing all the information I
think Repology currently gets about all packages. For example:

  
https://prototype-guix-data-service.cbaines.net/revision/f52e83470b05b2473ea13feb2842a1330c316a00/packages.json?field=version&field=synopsis&field=description&field=home-page&field=location&field=licenses&limit_results=9

This is just the software side of the problem though. If this was to be
used by Repology, it would have to be a more permanent thing, similar to
the Cuirass and Mumi services that are currently setup around Guix. Does
anyone have any thoughts on this?

Thanks,

Chris


signature.asc
Description: PGP signature

Re: postgresql vs sqlite for Cuirass (was Re: Hackathon: Mumi and Cuirass)

[Gábor Boskovits]

Hello,

Giovanni Biscuolo  ezt írta (időpont: 2019. máj. 16., Cs,
16:23):

> Hello Björn,
>
> Björn Höfling  writes:
>
> [...]
>
> >> 2) Cuirass
> >
> > On Guix days, we discussed the idea of using Postgresql as a backend.
>
> Please do you remember the rationale behind this idea?
>
>
This was just an idea to test if we can make the database scalability
problem we
currently have solved.


> What is the issue with using sqlite?
>

Currently the database response times on sqlite are not acceptable.
Any suggestions to overcome this would be appreciated.


> Why a client/server approach vs an embedded database?
>
> I don't have much experience with web applications backed by sqlite, but
> AFAIU sqlite is sometime "misunderstood"
>
> Some interesting arguments from sqlite developer:
> https://sqlite.org/whentouse.html#website
> --8<---cut here---start->8---
>
> Dynamic content uses about 200 SQL statements per webpage. This setup
> runs on a single VM that shares a physical server with 23 others and yet
> still keeps the load average below 0.1 most of the time.
>
> --8<---cut here---end--->8---
>
> https://sqlite.org/np1queryprob.html
> --8<---cut here---start->8---
>
> 200 SQL statements per webpage is excessive for client/server database
> engines like MySQL, PostgreSQL, or SQL Server.
>
> But with SQLite, 200 or more SQL statement per webpage is not a problem.
>
> SQLite can also do large and complex queries efficiently, just like
> client/server databases. But SQLite can do many smaller queries
> efficiently too. Application developers can use whichever technique
> works best for the task at hand.
>
> [...]
>
> N+1 Queries Are Not A Problem With SQLite
>
> --8<---cut here---end--->8---
>
> [...]
>
> Thanks! Gio'
>
> --
> Giovanni Biscuolo
>
> Xelera IT Infrastructures
>
Best regards,
g_bor

Re: Update on 1.0.1

[Ludovic Courtès]

Hi Florian,

"pelzflorian (Florian Pelz)"  skribis:

> On Thu, May 16, 2019 at 01:38:39PM +0200, Ludovic Courtès wrote:
>> I’ll create a ‘version-1.0.1’ branch with the aim of releasing the whole
>> thing maybe tomorrow or at least by Tuesday.
>> 
>
> If this does not go through the TP, can we send a download link for a
> newer PO file adapted to current doc/guix.texi?

You can send it right now if you want.  But I think the PO files are
rather up-to-date, no?

> Also it would be good if you could make sure
> http://guix.info/manual/en/html_node/Binary-Installation.html#Binary-Installation
> will mention Guix version 1.0.1 instead of telling users to download
> version UNKNOWN, but maybe this only happened because of the 1.0.0 
> %base-packages
> warning added to the manual.

guix.info is maintained separately, I guess something went wrong.

I worked on a Guix program to automate the generation of on-line copies
of the manual, so we should be able to avoid such issues in the future.

Thanks,
Ludo’.

Re: Update on 1.0.1

[Ludovic Courtès]

Hi Florian,

"pelzflorian (Florian Pelz)"  skribis:

> Please include this updated German PO file:
> https://pelzflorian.de/guix-manual.de.po

Applied, thank you!

> It would be nice if a 1.0.1 POT file were published on the TP even if
> it is not in time, so that the TP can again harbor the most current
> translations.

Julien, WDYT?  I’d really like to go ahead with the release though.

Note that, at worst, we can update the on-line copy of the manual later
if new translations arrive.

Perhaps in the future we should use a different workflow if the TP
doesn’t work well for us.  Thoughts?

Thanks,
Ludo’.

Re: Update on 1.0.1

[pelzflorian (Florian Pelz)]

On Fri, May 17, 2019 at 11:19:30AM +0200, Ludovic Courtès wrote:
> Hi Florian,
> 
> "pelzflorian (Florian Pelz)"  skribis:
> 
> > Please include this updated German PO file:
> > https://pelzflorian.de/guix-manual.de.po
> 
> Applied, thank you!
>

:)


> Perhaps in the future we should use a different workflow if the TP
> doesn’t work well for us.  Thoughts?
> 

In GNOME string freezes are introduced to give translators enough
time.  I guess this is not necessary for Guix; by now the only
unstable part of the manual that is noticeable is the list of
languages in which the manual is available, because the Russian
translation appeared just before release.

Regards,
Florian

Fingerprint GUI

[Raghav Gururajan]

Hello Guix!

I came across this Fingerprint GUI application 
(http://www.ullrich-online.cc/fingerprint/index.php 
(http://www.ullrich-online.cc/fingerprint/index.php)). Is this completely free 
of blobs and will it be compatible with Guix?

Thank you!

Regards,
RG.

Re: Update on 1.0.1

[Ricardo Wurmus]

Ludovic Courtès  writes:

>> Also it would be good if you could make sure
>> http://guix.info/manual/en/html_node/Binary-Installation.html#Binary-Installation
>> will mention Guix version 1.0.1 instead of telling users to download
>> version UNKNOWN, but maybe this only happened because of the 1.0.0 
>> %base-packages
>> warning added to the manual.
>
> guix.info is maintained separately, I guess something went wrong.

Sorry.  I’ll update this after the release of 1.0.1.  Or point it to
gnu.org/s/guix until I get around to fully automating this.

-- 
Ricardo

Re: More progress with the Guix Data Service

[Amirouche]

On 2019-05-17 09:56, Christopher Baines wrote:

Hey,

In summary, I think the Guix Data Service might be getting useful 
enough

that setting it up properly might be a good next step, and I'd be
interested in what others think?


Yeah. And it looks good :)


A bit over a month ago, I sent out an update about one of the things
I've been working on, something I've been calling the "Guix Data
Service" [1].

1: https://lists.gnu.org/archive/html/guix-devel/2019-04/msg00094.html

Since then, I've made some more progress. There's a new statistics page
[2]. I've got used to using Sqitch [3] to help manage the database
schema, and I've added some basic tests.


statistic page is a 404. I am very interested to learn how you use 
sqitch.




2: https://prototype-guix-data-service.cbaines.net/statistic
3: http://guix.gnu.org/packages/sqitch-0./

The error handling for loading new revisions is also more resilient 
now.


As well as listening to the Guix Commits mailing list for emails about
new revisions, more of the information in these emails is now stored, 
in

particular, the time they were sent, and the branch the email applies
to. This can be seen on the new Branches page [4].

4: https://prototype-guix-data-service.cbaines.net/branches


Here when I click on a commit, I would expect the message of the commit
and the build status of the impacted softwares, e.g.

https://prototype-guix-data-service.cbaines.net/revision/d59c90a5bfdd6b723bea939b8538c7c9b3c1b2a6



The content negotiation a little bit, at least in terms of the code, 
and

JSON output support has been added to more pages.

There's now a basic search function on the packages page [5], and the
location, and the licenses for packages is now being stored (which can
be seen on the page for a package, for example [6]).

5:
https://prototype-guix-data-service.cbaines.net/revision/f52e83470b05b2473ea13feb2842a1330c316a00/packages?search_query=Guile&field=version&field=synopsis&after_name=&limit_results=1000
6:
https://prototype-guix-data-service.cbaines.net/revision/f52e83470b05b2473ea13feb2842a1330c316a00/package/0ad/0.0.23b-alpha

The location and license information is something I added specifically,
as I noticed the Repology [7] service scraped [8] these from the Guix
website.

7: https://repology.org/
8:
https://github.com/repology/repology/blob/master/repology/fetchers/fetchers/guix.py

While the Guix Data Service started as something to enable better
understanding patches in an automated way, I think there are more uses
for it, and initially, it's probably better to focus on the simple 
ones.


It is not clear right now that it is related to patches, there is no 
patch

anywhere to see.


The Repology use case is pretty simple, I think ideally there would be
some machine readable data about the current state of packages in Guix
available over the internet, and Repology would be able to download 
that

on a regular basis.


Repology is nice, but I would prefer wikidata support.



The URL is a bit long, but I think that is now close to being possible
with the Guix data service. I haven't got something working yet to
easily access data for the latest revision, but for a particular
revision, you can request a JSON file containing all the information I
think Repology currently gets about all packages. For example:


https://prototype-guix-data-service.cbaines.net/revision/f52e83470b05b2473ea13feb2842a1330c316a00/packages.json?field=version&field=synopsis&field=description&field=home-page&field=location&field=licenses&limit_results=9


FWIW it is very slow.


Does anyone have any thoughts on this?


It seems to me it would be useful to have that informations somewhere. 
Like you
explain having the correct build information is a must have IMO along 
the logs.


Where is the code?


Thanks for sharing!

Re: postgresql vs sqlite for Cuirass (was Re: Hackathon: Mumi and Cuirass)

[Aljosha Papsch]

Hi,

Am Freitag, den 17.05.2019, 10:26 +0200 schrieb Gábor Boskovits:
> Any suggestions to overcome this would be appreciated.

I would go with the client/server database. It helps scaling in the
long term and Guix must take over the world, no? With SQLite you'll be
stuck with the single file on a single server. You could implement your
custom replication using rsync or whatever, but you'll have to ensure
that the receivers do not write to the file (readonly "slaves"). In the
end it will be a problem already solved by Postgres and other
server/client databases.

I don't know about multi-master replication in Postgres, with MySQL it
would be possible.

> 200 SQL statements per webpage is excessive for client/server
> database like MySQL [...] But with SQLite [it's] not a problem.

The main problem the author sees is the roundtrip of the message to the
DB server. It's a common problem that you will get into when moving
from single machine to cluster. IMHO you shouldn't shy away by sticking
to the single machine, but optimize the application to get the benefits
that a cluster provides you (mainly availability).

Best regards
Aljosha
(checking Guix out for web development)


signature.asc
Description: This is a digitally signed message part

Re: Fingerprint GUI

[Raghav Gururajan]

> The upek folder in the source I downloaded seems to contain compiled shared 
> libraries in the lib
> and lib64 subfolders, so that's a bad sign.

I see.

Re: gold linker and collect2: fatal error: cannot find 'ld'

[Pierre Neidhardt]

So it seems that the following change to make-ld-wrapper triggers a
rebuild of the world on every "guix build".  Any idea why?  Ludo?

--8<---cut here---start->8---
@@ -537,14 +537,15 @@ included.")
   binutils
   (guile (canonical-package guile-2.2))
   (bash (canonical-package bash))
-  (guile-for-build guile))
-  "Return a package called NAME that contains a wrapper for the 'ld' program
-of BINUTILS, which adds '-rpath' flags to the actual 'ld' command line.  The
-wrapper uses GUILE and BASH.
+  (guile-for-build guile)
+  (linker-name "ld"))
+  "Return a package called NAME that contains a wrapper for the linker program,
+('ld' of BINUTILS by default), which adds '-rpath' flags to the actual linker
+command line.  The wrapper uses GUILE and BASH.
 
 TARGET must be a one-argument procedure that, given a system type, returns a
 cross-compilation target triplet or #f.  When the result is not #f, make a
-wrapper for the cross-linker for that target, called 'TARGET-ld'."
+wrapper for the cross-linker for that target, called 'TARGET-LINKER-NAME'."
   ;; Note: #:system->target-triplet is a procedure so that the evaluation of
   ;; its result can be delayed until the 'arguments' field is evaluated, thus
   ;; in a context where '%current-system' is accurate.
@@ -569,8 +570,8 @@ wrapper for the cross-linker for that target, called 
'TARGET-ld'."
  (let* ((out (assoc-ref %outputs "out"))
 (bin (string-append out "/bin"))
 (ld  ,(if target
-  `(string-append bin "/" ,target "-ld")
-  '(string-append bin "/ld")))
+  `(string-append bin "/" ,target "-" 
,linker-name)
+  `(string-append bin "/" ,linker-name)))
 (go  (string-append ld ".go")))
 
(setvbuf (current-output-port) _IOLBF)
@@ -593,8 +594,8 @@ wrapper for the cross-linker for that target, called 
'TARGET-ld'."
   (string-append (assoc-ref %build-inputs "binutils")
  ,(if target
   (string-append "/bin/"
- target "-ld")
-  "/bin/ld"
+ target "-" 
linker-name)
+  (string-append "/bin/" 
linker-name)
(chmod ld #o555)
(compile-file ld #:output-file go)
#t)

--8<---cut here---end--->8---

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


signature.asc
Description: PGP signature

Re: Parameterized packages

[Mark H Weaver]

Hi,

Tobias Geerinckx-Rice  writes:

> Ludovic Courtès wrote:
>> While thinking about  and
>> looking
>> for ways to allow users to install just the locales they need right
>> from
>> ‘guix package’, I realized that “parameterized packages” are a
>> low-hanging fruit
>
> Wow.  Unexpected turn…
>
> I'm still thinking about this, so all this is just me doing it out
> loud:
>
>>   (package
>> (inherit glibc-utf8-locales)
>> (properties `((locales . ("zh_CN.utf8")
>>
>> and tadaam! we have a parameterized package.
>>
>> There’s a couple of gotchas:
>>
>>   • We’d need to store more info in manifest entries so that
>> transformation options are preserved upon ‘guix upgrade’.
>>
>>   • We might need to expose the package parameters somehow, so
>> that if
>> one types ‘--with-argument=foobar=baz’, they get a correct
>> error
>> message saying that “foobar” is not a known parameter.
>
> Interesting idea to piggy-back on the properties field, and it might
> save some code (at least initially), but I don't see the overlap here.
>
> None of the current properties (superseded, upstream-name, *-variant,
> cpe-name, hidden?) make much sense to expose in this way; they're
> semimmutable facts about the package.

Also, at present, the current 'properties' field can be changed without
changing the derivation, and I think that's quite useful.  It's nice to
be able to do things like increase the build timeouts on a core package,
for the sake of a slow architecture, without forcing rebuilds of
everything on top of that package on other architectures.

So, I would prefer to see a different package field used for this.

 Thanks,
   Mark

Re: More progress with the Guix Data Service

[Christopher Baines]

Amirouche  writes:

> On 2019-05-17 09:56, Christopher Baines wrote:
>> Hey,
>>
>> In summary, I think the Guix Data Service might be getting useful
>> enough
>> that setting it up properly might be a good next step, and I'd be
>> interested in what others think?
>
> Yeah. And it looks good :)

Thanks :)

>> A bit over a month ago, I sent out an update about one of the things
>> I've been working on, something I've been calling the "Guix Data
>> Service" [1].
>>
>> 1: https://lists.gnu.org/archive/html/guix-devel/2019-04/msg00094.html
>>
>> Since then, I've made some more progress. There's a new statistics page
>> [2]. I've got used to using Sqitch [3] to help manage the database
>> schema, and I've added some basic tests.
>
> statistic page is a 404. I am very interested to learn how you use
> sqitch.

Sorry, the link is wrong, it's actually:

  https://prototype-guix-data-service.cbaines.net/statistics

As for Sqitch, all I've been doing so far is sqitch add ... to create a
change, sqitch deploy ... to apply changes to a database and sqitch
revert ... to revert changes to a database. It's just some structure and
tooling that I don't have to write :)

>> 2: https://prototype-guix-data-service.cbaines.net/statistic
>> 3: http://guix.gnu.org/packages/sqitch-0./
>>
>> The error handling for loading new revisions is also more resilient
>> now.
>>
>> As well as listening to the Guix Commits mailing list for emails about
>> new revisions, more of the information in these emails is now
>> stored, in
>> particular, the time they were sent, and the branch the email applies
>> to. This can be seen on the new Branches page [4].
>>
>> 4: https://prototype-guix-data-service.cbaines.net/branches
>
> Here when I click on a commit, I would expect the message of the commit
> and the build status of the impacted softwares, e.g.
>
> https://prototype-guix-data-service.cbaines.net/revision/d59c90a5bfdd6b723bea939b8538c7c9b3c1b2a6

I've just realised the table headers on the branches page are the wrong
way around.

Anyway, I've added some information about git repositories to the
database so I could link to cgit for the location of a package, so I'll
have a look at also putting a link to commits on that page.

As for build status information, this is something I talked a little
more about in my last email (link at the top), but in summary, I've done
some initial work, but more needs doing to get the build status
information in to the database.

>> The content negotiation a little bit, at least in terms of the code,
>> and
>> JSON output support has been added to more pages.
>>
>> There's now a basic search function on the packages page [5], and the
>> location, and the licenses for packages is now being stored (which can
>> be seen on the page for a package, for example [6]).
>>
>> 5:
>> https://prototype-guix-data-service.cbaines.net/revision/f52e83470b05b2473ea13feb2842a1330c316a00/packages?search_query=Guile&field=version&field=synopsis&after_name=&limit_results=1000
>> 6:
>> https://prototype-guix-data-service.cbaines.net/revision/f52e83470b05b2473ea13feb2842a1330c316a00/package/0ad/0.0.23b-alpha
>>
>> The location and license information is something I added specifically,
>> as I noticed the Repology [7] service scraped [8] these from the Guix
>> website.
>>
>> 7: https://repology.org/
>> 8:
>> https://github.com/repology/repology/blob/master/repology/fetchers/fetchers/guix.py
>>
>> While the Guix Data Service started as something to enable better
>> understanding patches in an automated way, I think there are more uses
>> for it, and initially, it's probably better to focus on the simple
>> ones.
>
> It is not clear right now that it is related to patches, there is no
> patch
> anywhere to see.

Indeed. What I've been using the Guix Data Service for is working out
what a series of patches does. For example, on my test Patchwork
instance, you can see this series of patches [1], and there's a
corresponding page from the Guix Data Service showing what the effect of
the patches is [2].

1: https://patchwork.cbaines.net/project/guix-patches/list/?series=1048
2: 
https://prototype-guix-data-service.cbaines.net/compare?base_commit=4d46775b1d04f9edb6fd729cfcd4b745be74e03b&target_commit=b3cfde472e5b2e6a9489a1b6c437daa659a977a6

>> The Repology use case is pretty simple, I think ideally there would be
>> some machine readable data about the current state of packages in Guix
>> available over the internet, and Repology would be able to download
>> that
>> on a regular basis.
>
> Repology is nice, but I would prefer wikidata support.

Interesting, I don't know much about wikidata, but taking Guile as an
example, it looks like wikidata is tracking distributions that package
Guile, along with the Free Software Directory [3]

3: https://www.wikidata.org/wiki/Q1486208#identifiers

Linking to other data/representations of packages from the Guix Data
Service has been something I've been thinking about. Especially things
like the Fre

Re: Fingerprint GUI

[Pronaip]

The upek folder in the source I downloaded seems to contain compiled shared 
libraries in the lib and lib64 subfolders, so that's a bad sign.


‐‐‐ Original Message ‐‐‐
On Friday, May 17, 2019 1:52 PM, Raghav Gururajan  wrote:

> Hello Guix!
>
> I came across this Fingerprint GUI application 
> (http://www.ullrich-online.cc/fingerprint/index.php). Is this completely free 
> of blobs and will it be compatible with Guix?
>
> Thank you!
>
> Regards,
> RG.

Some manual @ref @xref @pxref fail when untranslated

[pelzflorian (Florian Pelz)]

Meiyo Peng reports at 


On Tue, May 14, 2019 at 10:29:35AM +0800, Meiyo Peng wrote:
> I just find out that the @pxref{Packages with Multiple Outputs} in
> doc/contributing.texi has to be translated.  Or I will get an error
> while running make:
> 
> #+begin_example
>   doc/contributing.zh_CN.texi:567: @pxref reference to nonexistent node 
> `Packages with Multiple Outputs'
> #+end_example
> 
> I guess it's because the node name is in doc/guix.texi (another file
> than doc/contributing.texi).  Any idea?
> 

The reason appears to be that when not translating (using the first
attached patch that reverts back to @pxref{Packages with Multiple
Outputs}), po4a-translate transforms

@item
Take a look at the profile reported by @command{guix size}
(@pxref{Invoking guix size}).  This will allow you to notice references
to other packages unwillingly retained.  It may also help determine
whether to split the package (@pxref{Packages with Multiple Outputs}),
and which optional dependencies should be used.  In particular, avoid adding
@code{texlive} as a dependency: because of its extreme size, use
@code{texlive-tiny} or @code{texlive-union} instead.

to

@item
看一下@command{guix size}（@pxref{Invoking guix
size}）的分析报告。这会让你注意到对其它软件包无意中的引用。它也可以帮助决定是否要把一个软件包分割成几个输出（@pxref{Packages
with Multiple
Outputs}），以及需要使用哪些可选的依赖。特别地，避免把@code{texlive}添加为依赖：因为它太大了，请使用@code{texlive-tiny}或@code{texlive-union}代替它。

with the pxref split over three lines because the surrounding context
has no space characters.  doc/local.mk’s xref_command can only deal
with two lines however.

The second attached patch makes xref_command grep three-line
references too, so it finds the translation, *however* I cannot get
this multiline sed to actually insert the translation into three line
references.  Perhaps it would be better to just replace this complex
xref_command with Guile code?  I will not do it however.

I am Cc’ing the bug-g...@gnu.org; I hope this is OK.

Regards,
Florian>From 267cc4c506d03ad35bfeead0f45d77bc7d242181 Mon Sep 17 00:00:00 2001
From: Florian Pelz 
Date: Sat, 18 May 2019 00:29:21 +0200
Subject: [PATCH 1/2] THIS IS A TEST: Revert to not translating pxref
 reference.

---
 po/doc/guix-manual.zh_CN.po | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/po/doc/guix-manual.zh_CN.po b/po/doc/guix-manual.zh_CN.po
index c24900da31..d1351ef557 100644
--- a/po/doc/guix-manual.zh_CN.po
+++ b/po/doc/guix-manual.zh_CN.po
@@ -8,7 +8,7 @@ msgstr ""
 "Project-Id-Version: guix-manual 1.0.1-pre1\n"
 "Report-Msgid-Bugs-To: l...@gnu.org\n"
 "POT-Creation-Date: 2019-05-10 20:53+0200\n"
-"PO-Revision-Date: 2019-05-14 14:31+0800\n"
+"PO-Revision-Date: 2019-05-17 17:21+0200\n"
 "Last-Translator: Meiyo Peng \n"
 "Language-Team: Chinese (simplified) \n"
 "Language: zh_CN\n"
@@ -1237,7 +1237,7 @@ msgstr "有时，软件包为了方便用户，捆绑了依赖库的源代码。
 #. type: enumerate
 #: doc/contributing.texi:868
 msgid "Take a look at the profile reported by @command{guix size} 
(@pxref{Invoking guix size}).  This will allow you to notice references to 
other packages unwillingly retained.  It may also help determine whether to 
split the package (@pxref{Packages with Multiple Outputs}), and which optional 
dependencies should be used.  In particular, avoid adding @code{texlive} as a 
dependency: because of its extreme size, use @code{texlive-tiny} or 
@code{texlive-union} instead."
-msgstr "看一下@command{guix size}（@pxref{Invoking guix 
size}）的分析报告。这会让你注意到对其它软件包无意中的引用。它也可以帮助决定是否要把一个软件包分割成几个输出（@pxref{有多个输出的软件包}），以及需要使用哪些可选的依赖。特别地，避免把@code{texlive}添加为依赖：因为它太大了，请使用@code{texlive-tiny}或@code{texlive-union}代替它。"
+msgstr "看一下@command{guix size}（@pxref{Invoking guix 
size}）的分析报告。这会让你注意到对其它软件包无意中的引用。它也可以帮助决定是否要把一个软件包分割成几个输出（@pxref{Packages with 
Multiple 
Outputs}），以及需要使用哪些可选的依赖。特别地，避免把@code{texlive}添加为依赖：因为它太大了，请使用@code{texlive-tiny}或@code{texlive-union}代替它。"
 
 #. type: enumerate
 #: doc/contributing.texi:873
-- 
2.21.0

>From f9c3aae82c940238e6162e16cef0431ce782f5f3 Mon Sep 17 00:00:00 2001
From: Florian Pelz 
Date: Sat, 18 May 2019 00:31:06 +0200
Subject: [PATCH 2/2] doc: Insufficient attempt to fix translation of
 three-line references.

* doc/local.mk (xref_command): Catch three-line translations as well, but the
multiline sed still covers only two lines.
---
 doc/local.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/local.mk b/doc/local.mk
index 336e961c4f..645e571817 100644
--- a/doc/local.mk
+++ b/doc/local.mk
@@ -88,7 +88,7 @@ PO4A_PARAMS += -f texinfo # texinfo format
 # reference name, even in untranslated strings.
 # The last sed is a multiline sed because some references span multiple lines.
 define xref_command
-cat "$@.tmp" | egrep '@p?x?ref' -A1 | sed 'N;s|--\n||g;P;D' | sed 's|^| |g' | \
+cat "$@.tmp" | egrep '@p?x?ref' -A2 | sed 'N;s|--\n||g;P;D' | sed 's|^| |g' | \
 tr -d '\012' | sed 's|\(@p\?x\?ref\)|\n\1|g' | egrep '@p?x?ref' | \
 sed 's|^.*@p\?x\?ref{\

Re: postgresql vs sqlite for Cuirass (was Re: Hackathon: Mumi and Cuirass)

[Ricardo Wurmus]

Aljosha Papsch  writes:

> Am Freitag, den 17.05.2019, 10:26 +0200 schrieb Gábor Boskovits:
>> Any suggestions to overcome this would be appreciated.
>
> I would go with the client/server database. It helps scaling in the
> long term and Guix must take over the world, no? With SQLite you'll be
> stuck with the single file on a single server. You could implement your
> custom replication using rsync or whatever, but you'll have to ensure
> that the receivers do not write to the file (readonly "slaves"). In the
> end it will be a problem already solved by Postgres and other
> server/client databases.

Our current problem is not replication and we’re far from needing it at
this point.  I think there are better ways to improve Cuirass than to
switch to Postgres.

--
Ricardo

Re: [BLOG] custom kernel config

[ison]

On Thu, May 16, 2019, Mark H Weaver wrote:
> Marius Bakke  writes:
> 
> > I just want to point out an (IMO) easier way to provide a custom kernel
> > configuration, that does not involve the "make-linux-libre" procedure:
> >
> > (define-public linux-libre/custom
> >   (package
> > (inherit linux-libre)
> > (native-inputs
> >  `(("kconfig" ,(local-file "kernel.config"))
> >,@(alist-delete "kconfig"
> >(package-native-inputs linux-libre))
> >
> > At the end of the day, Linux-Libre is just a regular package that can be
> > inherited and overridden like any other :-)
> 
> I think this is the approach we should promote for now.  I would prefer
> to leave 'make-linux-libre' as an internal implementation detail, and
> hopefully one with a limited life span.

Is it also possible to leave make-linux-libre out of the 2nd method presented in
the blog? I can't see any way to modify extra-options without it since in the
package it appears deeply nested inside arguments.