Apply Guix patches from debbugs

[Pierre Neidhardt]

Hi,

Question for Emacs users: how do you apply patches directly from the debbugs
interface?

From the summary view, I can press M-m (debbugs-gnu-apply-patch).
It asks me for a directory, I point to guix, and then I get the error

--8<---cut here---start->8---
cd: No such directory found via CDPATH environment variable
--8<---cut here---end--->8---

which after some investigation turns out to be because the command
expects a "lisp" folder (this is made for Emacs development indeed).

There must be some other way then.
I remember doing it in the past, so my memory must be failing me...

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


signature.asc
Description: PGP signature

Re: Apply Guix patches from debbugs

[swedebugia]

On 2019-07-15 12:54, Pierre Neidhardt wrote:

Hi,

Question for Emacs users: how do you apply patches directly from the debbugs
interface?

 From the summary view, I can press M-m (debbugs-gnu-apply-patch).
It asks me for a directory, I point to guix, and then I get the error

--8<---cut here---start->8---
cd: No such directory found via CDPATH environment variable
--8<---cut here---end--->8---

which after some investigation turns out to be because the command
expects a "lisp" folder (this is made for Emacs development indeed).

There must be some other way then.
I remember doing it in the past, so my memory must be failing me...



You can ignore that error.
The patches apply fine (silently).

--
Cheers
Swedebugia

Re: Apply Guix patches from debbugs

[Efraim Flashner]

Not exactly the same thing, but I read my mail in mutt and only because
I'm subscribed to the guix-patches maillinglist can I interact with them
nicely.

Does anyone know if it's possible to point mutt at debbugs, or even
specific bugs, as though they were remote mailboxes?


-- 
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: 01/01: guix: node-build-system: Use guile-json instead of a custom parser.

[Ludovic Courtès]

Hi,

Robert Vollmert  skribis:

> It’s a bit my fault, for remarking on the fact that the cargo build
> system does use guile-json. I suppose that’s not worth fixing either
> at this point?

Indeed, ‘cargo-build-system’ has the same problem:

--8<---cut here---start->8---
(define %cargo-build-system-modules
  ;; Build-side modules imported by default.
  `((guix build cargo-build-system)
(json parser)
,@%cargo-utils-modules))
--8<---cut here---end--->8---

We should definitely fix it, or we’ll run into discrepancies like I
described.

For now, the easiest option would be to use (guix build json) as well.

Could you look into it, Robert?

Thanks,
Ludo’.

Re: Website translation

[Ludovic Courtès]

"pelzflorian (Florian Pelz)"  skribis:

> On Sun, Jul 14, 2019 at 04:12:41PM +0200, Ludovic Courtès wrote:
>> Note that “lego translation” is what we should _not_ do because it gives
>> translators fragments of sentences, which does not allow them to
>> correctly translate text.
>>
>
> Format strings are something we can try.  If they are too fragmented
> for translators, we can still use a custom tool to convert them and
> their fragments to a single string which gets passed to gettext.

Yes.

Another option would be to locally use XML in strings, along these
lines:

--8<---cut here---start->8---
(use-modules (sxml simple)
 (ice-9 match))

(define (X_ str)
  (match (xml->sxml (string-append ""
   (gettext str)
   ""))
(('*TOP* ('BODY . lst)) lst)))

`(div
   ,@(X_ "This is a link."))
--8<---cut here---end--->8---

That would allow us to remain string-oriented while still enjoying the
benefits of SXML (info "(guile) Types and the Web").

Maybe we’ll need a combination of format strings and stuff like that.

Thanks,
Ludo’.

Re: We reached 10.000 package

[Ludovic Courtès]

Hello Guix!

Jesse Gibbons  skribis:

> On Sun, 14 Jul 2019 23:21:37 +0200
> Hartmut Goebel  wrote:
>
>> Hurrah!
>> 
>> GNU Guix now provides 10,026 packages (updated July 12, 2019).
>> 
>> Congratulations!
>> 
>> And many thanks to everybody who contributed to this great project!
>> 
>
> This is big news for Guix. Very much worth a small slice of banana
> bread in celebration.

Yay, congrats everyone!  \o/

> Yet there is still a lot to do. How many of these packages work as
> intended? Some of them have an error when guix builds them, some of
> them immediately crash, and some of them take so long to build that it
> is impractical to try to install them with guix.
>
> If you show me a list of packages that don't build correctly or
> immediately crash on startup, I will work on fixing them. I have no
> doubt some volunteers are willing to do the same. If I had access to a
> good server I would be willing to work on packages that take more than
> a day to build like guile-emacs.

There are both build errors and packaging issues reported at
, so you won’t run out of ideas of packages
to work on.

If you do (!), you can also look at failing builds at
.

:-)

Thanks,
Ludo’.

Re: Fixing evolution-data-server on core-updates

[Ludovic Courtès]

Hello Timothy,

Timothy Sample  skribis:

> From bcd753f777687c52bba6b9bf4184879e69990118 Mon Sep 17 00:00:00 2001
> From: Timothy Sample 
> Date: Sun, 14 Jul 2019 23:47:44 -0400
> Subject: [PATCH] gnu: evolution-data-server: Fix locale issue.
>
> * gnu/packages/gnome.scm (evolution-data-server)[arguments]: Add a phase
> that patches the source code to fix a locale issue.
> ---
>  gnu/packages/gnome.scm | 15 +++
>  1 file changed, 15 insertions(+)
>
> diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
> index eb251498e9..a34adc4006 100644
> --- a/gnu/packages/gnome.scm
> +++ b/gnu/packages/gnome.scm
> @@ -5168,6 +5168,21 @@ Exchange, Last.fm, IMAP/SMTP, Jabber, SIP and 
> Kerberos.")
> "tests/libedata-cal/test-cal-cache-utils.c")
>(("/bin/rm") (which "rm")))
>  #t))
> + ;; This phase fixes locale canonicalization and prevents a few test
> + ;; failures.  The bug has been reported upstream:
> + ;; 
> .
> + (add-after 'unpack 'patch-locale-canonicalization
> +   (lambda _
> + (substitute* "src/libedataserver/e-collator.c"
> +   (("len = uloc_canonicalize \\(posix_locale,.*" x)
> +((lambda (xs) (string-join xs "\n" 'suffix))
> + (list
> +  "if (g_ascii_strcasecmp(posix_locale, \"C\") == 0 ||"
> +  "g_ascii_strcasecmp(posix_locale, \"POSIX\") == 0) {"
> +  "  posix_locale = \"en_US_POSIX\";"
> +  "}"
> +  x

LGTM, thanks for fixing it!

Ludo’.

Re: Can we increase the print width/column in daemon backtraces

[Ricardo Wurmus]

Hi Pierre,

> Quite often when packaging and iterating, the daemon produces backtraces
> on errors, which could be very useful to understand what's wrong, but
> unfortunately the output is truncated to some 80-ish column.

Set the COLUMNS environment variable to some large value.

-- 
Ricardo

Re: We should disable dmesg for unprivileged users by default

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Hi,
>
> Alex Vong  skribis:
>
>> I think we should set /proc/sys/kernel/dmesg_restrict to 1 by default to
>> prevent unprivileged users from reading the kernel ring buffer (since it
>> could expose sensitive information about the system).
>
> We could have a ‘dmesg-restrict’ service that would write to that file
> as part of system activation, and we’d add it to ‘%base-packages’.
> WDYT?

This sounds good!

-- 
Ricardo

Re: Can we increase the print width/column in daemon backtraces

[Pierre Neidhardt]

Ricardo Wurmus  writes:

> Set the COLUMNS environment variable to some large value.

Hmm... I use Eshell (in Emacs), in which the COLUMNS env variable is 
automatically
set to the Emacs window width.  For instance right now I have 190.  And
the daemon still displays truncated message (i.e. way shorter than 190).

Is there something else to do then?
I'll also try with a (more) regular shell.

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


signature.asc
Description: PGP signature

Re: Can we increase the print width/column in daemon backtraces

[swedebugia]

On 2019-07-15 14:47, Ricardo Wurmus wrote:


Hi Pierre,


Quite often when packaging and iterating, the daemon produces backtraces
on errors, which could be very useful to understand what's wrong, but
unfortunately the output is truncated to some 80-ish column.


Set the COLUMNS environment variable to some large value.


This should be added to the manual I think.

--
Cheers
Swedebugia

Re: Website translation

[Ricardo Wurmus]

Ludovic Courtès  writes:

> As long as we use xgettext, we have to stick to a format-string-like
> approach like what sirgazil proposes.
>
> Writing a custom xgettext kind of tool wouldn’t help much because
> gettext is fundamentally text oriented: you give it a string and it
> returns a string.
>
> So I think the alternative is:
>
>   • use gettext, and in that case stick to a format-string-like
> mechanism, or:
>
>   • use a completely new tool that would be able to consume and produce
> sexps (trees).
>
> The latter doesn’t seem reasonable to me.  :-)

I’m not sure I understand the problem well enough, but there seems to be
a middle way: using itstool with XML.  When you squint really hard XML
is close to S-exprs.

--
Ricardo

Re: Fixing evolution-data-server on core-updates

[Kei Kebreau]

Ludovic Courtès  writes:

> Hello Timothy,
>
> Timothy Sample  skribis:
>
>> From bcd753f777687c52bba6b9bf4184879e69990118 Mon Sep 17 00:00:00 2001
>> From: Timothy Sample 
>> Date: Sun, 14 Jul 2019 23:47:44 -0400
>> Subject: [PATCH] gnu: evolution-data-server: Fix locale issue.
>>
>> * gnu/packages/gnome.scm (evolution-data-server)[arguments]: Add a phase
>> that patches the source code to fix a locale issue.
>> ---
>>  gnu/packages/gnome.scm | 15 +++
>>  1 file changed, 15 insertions(+)
>>
>> diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
>> index eb251498e9..a34adc4006 100644
>> --- a/gnu/packages/gnome.scm
>> +++ b/gnu/packages/gnome.scm
>> @@ -5168,6 +5168,21 @@ Exchange, Last.fm, IMAP/SMTP, Jabber, SIP and 
>> Kerberos.")
>> "tests/libedata-cal/test-cal-cache-utils.c")
>>(("/bin/rm") (which "rm")))
>>  #t))
>> + ;; This phase fixes locale canonicalization and prevents a few test
>> + ;; failures.  The bug has been reported upstream:
>> + ;; 
>> .
>> + (add-after 'unpack 'patch-locale-canonicalization
>> +   (lambda _
>> + (substitute* "src/libedataserver/e-collator.c"
>> +   (("len = uloc_canonicalize \\(posix_locale,.*" x)
>> +((lambda (xs) (string-join xs "\n" 'suffix))
>> + (list
>> +  "if (g_ascii_strcasecmp(posix_locale, \"C\") == 0 ||"
>> +  "g_ascii_strcasecmp(posix_locale, \"POSIX\") == 0) {"
>> +  "  posix_locale = \"en_US_POSIX\";"
>> +  "}"
>> +  x
>
> LGTM, thanks for fixing it!
>
> Ludo’.

Just FYI, I can confirm that this patch allows me to re-enable tests
that previously failed on core-updates!  I've re-enabled the relevant
failing tests on my own core-updates branch in anticipation of this
patch.  Thanks from me, too!

Kei

Re: [PATCH] gnu: Add elm-compiler 0.19.0

[Robert Vollmert]

> On 15. Jul 2019, at 15:47, Robert Vollmert  wrote:
> 
> This adds the elm compiler, version 0.19.0. This provides the
> `elm` command, with the exception of the `elm reactor` subcommand.
> 
> Named `elm-compiler`, to leave space for `elm` as the full elm
> including reactor.

I have some working but unfinished follow-up patches to this which add an
elm build system and which build the full elm including the reactor; compare

elm build systems:
  https://github.com/robx/guix/commit/95b2c1adba30bf000f85e85184fb04756591b1c9
guix import elm:
  https://github.com/robx/guix/commit/25e9b6e07242ccb4ef9c615df02b3f6571f334c8
full elm package:
  https://github.com/robx/guix/commit/20abbe7f2fe67cdb14e1ecaf7f55793e9467a1ea

Re: Website translation

[Julien Lepiller]

Le 15 juillet 2019 14:33:25 GMT+02:00, "Ludovic Courtès"  a écrit 
:
>"pelzflorian (Florian Pelz)"  skribis:
>
>> On Sun, Jul 14, 2019 at 04:12:41PM +0200, Ludovic Courtès wrote:
>>> Note that “lego translation” is what we should _not_ do because it
>gives
>>> translators fragments of sentences, which does not allow them to
>>> correctly translate text.
>>>
>>
>> Format strings are something we can try.  If they are too fragmented
>> for translators, we can still use a custom tool to convert them and
>> their fragments to a single string which gets passed to gettext.
>
>Yes.
>
>Another option would be to locally use XML in strings, along these
>lines:
>
>--8<---cut here---start->8---
>(use-modules (sxml simple)
> (ice-9 match))
>
>(define (X_ str)
>  (match (xml->sxml (string-append ""
>   (gettext str)
>   ""))
>(('*TOP* ('BODY . lst)) lst)))
>
>`(div
>   ,@(X_ "This is a link."))
>--8<---cut here---end--->8---
>
>That would allow us to remain string-oriented while still enjoying the
>benefits of SXML (info "(guile) Types and the Web").
>
>Maybe we’ll need a combination of format strings and stuff like that.
>
>Thanks,
>Ludo’.

Fyi, I sent a patch a few months ago to do exactly that, but I can't find it 
anymore…

Re: Can we increase the print width/column in daemon backtraces

[P]

> Hi Pierre,
>
> > Quite often when packaging and iterating, the daemon produces backtraces
> > on errors, which could be very useful to understand what's wrong, but
> > unfortunately the output is truncated to some 80-ish column.
>
> Set the COLUMNS environment variable to some large value.
>
> 
>
> Ricardo

Can't it just not truncate them? This is a very brutish way of condensing log 
output and breaks some workflows. I for one often use Acme because I can just 
right click on paths in it and it opens them with the plumber. If a path is 
split across lines, Acme can't pick that up.

Re: Can we increase the print width/column in daemon backtraces

[Ricardo Wurmus]

P  writes:

>> Hi Pierre,
>>
>> > Quite often when packaging and iterating, the daemon produces backtraces
>> > on errors, which could be very useful to understand what's wrong, but
>> > unfortunately the output is truncated to some 80-ish column.
>>
>> Set the COLUMNS environment variable to some large value.
>>
> Can't it just not truncate them? This is a very brutish way of
> condensing log output and breaks some workflows.

I also don’t like it, but that’s what Guile does.  (It’s not Guix that
truncates the output.)

> I for one often use
> Acme because I can just right click on paths in it and it opens them
> with the plumber. If a path is split across lines, Acme can't pick
> that up.

Same here with Emacs (M-x ffap).

--
Ricardo

Re: Website translation

[pelzflorian (Florian Pelz)]

On Mon, Jul 15, 2019 at 02:33:25PM +0200, Ludovic Courtès wrote:
> `(div
>,@(X_ "This is a link."))

For such things I prefer XML like Ricardo proposed

or like the __ on my
 rather than
cryptic HTML a elements and href.

However, this would again look even nicer when passing sexps to a
custom tool that converts them to a string that can get used with a
custom PO file writer or MO reader, wouldn’t it?

Should Guix just try with format strings for now?

Regards,
Florian

Testing changes on Berlin before pushing changes? (Was: Re: bug#35521: Mariadb test suite failures on x86_64-linux)

[Chris Marusich]

Hi Marius,

Thank you for your work on Mariadb in bug 35521.  You are a hero!  Well,
my hero at least, since this was blocking me from upgrading things.  :-)

Marius Bakke  writes:

> I was about to push this patch to core-updates:
>
> diff --git a/gnu/packages/databases.scm b/gnu/packages/databases.scm
> index 6bfeaad9a2..5d256b1af2 100644
> --- a/gnu/packages/databases.scm
> +++ b/gnu/packages/databases.scm
> @@ -706,9 +706,6 @@ Language.")
>;; 2030-12-31.  See  for 
> details.
>"main.mysqldump"
>  
> -  ;; XXX: Fails sporadically.
> -  "innodb_fts.crash_recovery"
> -
>;; FIXME: This test fails on i686:
>;; -myisampack: Can't create/write to file (Errcode: 
> 17 "File exists")
>;; +myisampack: Can't create/write to file (Errcode: 
> 17 "File exists)
> @@ -753,7 +750,10 @@ Language.")
>   (with-directory-excursion "mysql-test"
> (invoke "./mtr" "--verbose"
> "--retry=3"
> -   "--testcase-timeout=40"
> +   ;; On x86_64 we need a long timeout because of the
> +   ;; TokuDB engine, whose individual test cases 
> often
> +   ;; require more than 1 hour to complete on busy 
> hosts.
> +   "--testcase-timeout=90"
> "--suite-timeout=600"
> "--parallel" (number->string (parallel-job-count))
> "--skip-test-list=unstable-tests"))
>
>
> Lo and behold, tokudb_bugs.mdev4533 failed when I tried it on Berlin.

Perhaps I'm misunderstanding what you said, but it sounds like you were
able to test a change on Berlin without committing it to the
core-updates branch in Savannah.  Is that right?  If so, how did you do
it?  Being able to quickly test changes on better hardware than my puny
X200 could prove useful, and I'm sure others would find it useful, too.

-- 
Chris


signature.asc
Description: PGP signature

Re: Installing custom kernel on Intel NUC using USB and no network(newbie question)

[swedebugia]

Hi Will

I never played with guix archive so I will just comment on what I advise 
you to do.


On 2019-07-13 18:41, Will Schenk wrote:
I'm playing around with guixsd and am really impressed with the work so 
far!  I've been unpacking the installer and configuration trying to 
understand how it works.  so if there's a more straightforward way to do 
this that would be great also, but I have some questions on how guix 
itself works.


I'm trying to install guix on a IntelNUC where I don't have access to a 
wired connection.  This requires me to use the iwlwifi-firmware.


I never used guix with wifi. Is there a free iwl driver in linux-libre? 
If not I advise you to buy a free software compatible wifi-stick. See 
h-node.org.




I have a docker container on my OSX machine that installs guix on a 
debian image, and from there I add another channel to guix that has the 
standard linux kernel.  From there I build an installation iso that I 
copy to USB key, boot the nuc off of, and am able to install the system 
over WiFi and everything is great.


This sounds overly complicated if all you want to do is try guix system 
on the NUC.




My plan was to then change my /etc/config.scm file to include the 
packages that I built in the docker container to provision the system 
with a different kernel.  What I can't figure out is how to copy the 
package over in a way that guix system reconfigure can see them just 
using a USB stick.


Building a custom kernel is not something I would recommend beginners of 
Guix System. I have only seen a few do it and they had many months of 
experience.


...


Question 3:

It seems crazy to me that I'm downloading everything over and over.  At 
the office (where I was playing with this) we have fiber, but right here 
we have a terrible network connection so downloading multiple times is 
painful.  Is there a way to setup a local mirror of the builds (I'm 
waiting for ipfs backing for this obvious.)


It seems you have access to fast wired internet. I advise you to take 
the NUC somewhere and plug it in and wait for it to download everything. 
Guix is somewhat (maybe 25% compared to parabola and 35% compared to 
Debian) more bandwidth hungry than your average distribution from my 
experience.


Anyway, what I really dont understand is the guix archive behavior and 
why that didn't work, and how to reference the packages once they've 
been imported into either my profile and especially the config.scm.


Guix archive is not used a lot to my knowledge. I would avoid it as a 
beginner. Running guix publish to move packages is much more user friendly.




Thanks, and I'm very excited to be playing with guix!


Cool! Hope you find a solution that works for you.

--
Cheers
Swedebugia

Re: Organizing packages

[Jesse Gibbons]

On Sun, 14 Jul 2019 15:54:10 +0200
Ludovic Courtès  wrote:

> Hello!
> 
> Jesse Gibbons  skribis:
> 
> > I noticed that a few files have only one package definition and are
> > named for that package. I think these packages can be organized
> > better. Might I suggest the following rules:
> >
> > 1. if a package is a library for a particular language $LANG (like
> > Python, Perl, etc.) it goes in ${LANG}-xyz.scm. If it is a library
> > built for a particular PURPOSE, it may go into LANG-PURPOSE.scm
> > with those packages.
> >
> > 2. If the package defines a compiler or interpreter for a language
> > $LANG, it may go into ${LANG}.scm
> >
> > 3. If the package is part of a large divisible project $PROJ like
> > gcc or texlive, it may go into ${PROJ}.scm
> >
> > 4. If the package is maintained a part of a large desktop
> > environment $DE like GNOME or KDE, it may be put in ${DE}.scm
> >
> > 5. When in doubt, the package must go into a file named after its
> > $PURPOSE, ${PURPOSE}.scm. For example, if the package is a game
> > (like supertuxracer), it goes into games.scm; if it is for
> > undirected fun (like sl), it goes into toys.scm; if it is for audio
> > control or audio production, it goes into audio.scm; if it is for
> > drawing or producing graphics, it goes into graphics.scm; etc.
> > Projects that can be described with multiple purposes (like
> > fortune) may go into any of those files.  
> 
> I had experience with Nixpkgs, which has a decision tree for where to
> put packages:
> 
>   https://nixos.org/nixpkgs/manual/#sec-hierarchy
> 
> In the end I didn’t find it to be helpful in any way: you’d always
> have to open ‘top-level/all-packages’, a file that lists all the
> packages, to find out where the package you’re looking for lives.
> 
> I believe ‘guix edit’ greatly solves that (along with Helm or similar
> editor support for grepping.)
> 
Interesting. So is it worth trying to organize the guix packages or do
you think it will get too complicated? I'm primarily bothered by the
number of small files with only one package definition and the
inconsistency in how packages are organized. I would rather a file have
multiple package definitions that make sense together than a hundred
files with only one package definition.

> > I think this will make searching easier because not everything has
> > an obvious name, and when I `guix search` for a purpose (like
> > drawing) I often get unrelated results.  
This was an afterthought.

> 
> I don’t think the module hierarchy should be thought of as a tool for
> users to search for packages.
> 
> So really, ‘guix search’ is the tool that should be improved.  It’s
> been discussed many times, and improving it turns out to be difficult
> without resorting to external sources of information (e.g., list of
> command names, popularity database, etc.)
I was thinking this would help `guix search`. For example, if I try
`guix search game` a lot of the leaf packages in games.scm are ranked
with relevance level 1 because they do not have the word "game" in
their synopsis or description. I would expect them to have a higher
relevance (8 at the very minimum) because of their placement in
games.scm. I do not think these packages would be listed at all if they
were not in games.scm.

Hypothetically, if someone decided to define a package for the tuxemon
RPG in a new file "tuxemon.scm" and did not mention the word "game" in
the summary or description, it would not be listed in the `guix search
game` results at all. If it was placed into games.scm, then it would at
least come up in the results.

> 
> What we can do is look at specific examples to see if there’s
> something we can improve on the current scoring system (with the
> understanding that sometimes the answer is that we cannot do any
> better.)
> 
> For example, ‘guix search drawing program’ shows Tux Paint as the
> first result, which is good; but ‘guix search drawing’ and ‘guix
> search drawing application’ are much less useful.  In this particular
> example, it’s not clear to me what can be done.
> 
> One suggestion that was made before and that might help here is to
> increase the score of leaf packages (applications).
> 
> Food for thought!
> 
> Ludo’.
I have ideas about how to resolve this and other issues regarding `guix
search`, but perhaps they are best explained in bug reports or other
guix-devel discussions.

-Jesse

Re: Organizing packages

[Robert Vollmert]

> On 15. Jul 2019, at 19:21, Jesse Gibbons  wrote:
> 
> On Sun, 14 Jul 2019 15:54:10 +0200
> Ludovic Courtès  wrote:
> 
>> Hello!
>> 
>> Jesse Gibbons  skribis:
>> 
>>> I noticed that a few files have only one package definition and are
>>> named for that package. I think these packages can be organized
>>> better. Might I suggest the following rules:
>>> 
>>> 1. if a package is a library for a particular language $LANG (like
>>> Python, Perl, etc.) it goes in ${LANG}-xyz.scm. If it is a library
>>> built for a particular PURPOSE, it may go into LANG-PURPOSE.scm
>>> with those packages.
>>> 
>>> 2. If the package defines a compiler or interpreter for a language
>>> $LANG, it may go into ${LANG}.scm
>>> 
>>> 3. If the package is part of a large divisible project $PROJ like
>>> gcc or texlive, it may go into ${PROJ}.scm
>>> 
>>> 4. If the package is maintained a part of a large desktop
>>> environment $DE like GNOME or KDE, it may be put in ${DE}.scm
>>> 
>>> 5. When in doubt, the package must go into a file named after its
>>> $PURPOSE, ${PURPOSE}.scm. For example, if the package is a game
>>> (like supertuxracer), it goes into games.scm; if it is for
>>> undirected fun (like sl), it goes into toys.scm; if it is for audio
>>> control or audio production, it goes into audio.scm; if it is for
>>> drawing or producing graphics, it goes into graphics.scm; etc.
>>> Projects that can be described with multiple purposes (like
>>> fortune) may go into any of those files.  
>> 
>> I had experience with Nixpkgs, which has a decision tree for where to
>> put packages:
>> 
>>  https://nixos.org/nixpkgs/manual/#sec-hierarchy
>> 
>> In the end I didn’t find it to be helpful in any way: you’d always
>> have to open ‘top-level/all-packages’, a file that lists all the
>> packages, to find out where the package you’re looking for lives.
>> 
>> I believe ‘guix edit’ greatly solves that (along with Helm or similar
>> editor support for grepping.)
>> 
> Interesting. So is it worth trying to organize the guix packages or do
> you think it will get too complicated? I'm primarily bothered by the
> number of small files with only one package definition and the
> inconsistency in how packages are organized. I would rather a file have
> multiple package definitions that make sense together than a hundred
> files with only one package definition.

Just to voice some support for a consistent approach. It would be beneficial
in a similar way that a consistent indentation style helps: Less decisions to
make, less opportunity for bike-shedding discussions.

(Personally, one file per package sounds fine, too. No confusion about why
which module imports what. No overhead deciding where to file a package. No
need to grep around for where a package might be defined.)

Revisiting optional runtime dependencies

[P]

Has there been any progress on this front since 2015?

There should be a way to communicate to the user the existence of optional 
runtime-only dependencies.

For example, I installed Gajim recently and it pulled in Gnome's keyring, which 
is completely unncessary for me, as I already use KeepassXC.

The package manager should also have a way to query this information, because 
packages that were installed as optional dependencies should not have to be 
manually deleted when their reverse dependency is removed.

qt4 packages

[Efraim Flashner]

./pre-inst-env guix refresh -l qt@4
Building the following 9 packages would ensure 11 dependent packages are 
rebuilt: tipp10@2.1.0 qucs-s@0.0.20 lmms@1.1.3 poppler-qt4@0.72.0 
avogadro@1.2.0 pybitmessage@0.6.3.2 mumble@1.2.19 texmacs@1.99.9 uim-qt@1.8.8

tipp10 Debian continues to build with qt-4
qucs-s demands qt-4
lmms has a new release which may build with qt-5
poppler-qt4 has no packages depending on it
avogadro Debian continues to build with qt-4
pybitmessage looks like it has qt5 support about to be merged in
mumble looks like it can be built with qt5 after their 1.3.0 release
texmacs Debian dropped 2(?) versions ago
uim-qt looks like it supports building with qt-5

It looks like we can drop poppler-qt4 as it is.


-- 
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: Can we increase the print width/column in daemon backtraces

[Robert Vollmert]

> On 15. Jul 2019, at 17:40, Ricardo Wurmus  wrote:
> 
> 
> P  writes:
> 
>>> Hi Pierre,
>>> 
 Quite often when packaging and iterating, the daemon produces backtraces
 on errors, which could be very useful to understand what's wrong, but
 unfortunately the output is truncated to some 80-ish column.
>>> 
>>> Set the COLUMNS environment variable to some large value.
>>> 
>> Can't it just not truncate them? This is a very brutish way of
>> condensing log output and breaks some workflows.
> 
> I also don’t like it, but that’s what Guile does.  (It’s not Guix that
> truncates the output.)

It’s open source, though, isn’t it? Let’s fix it!

Re: qt4 packages

[Tobias Geerinckx-Rice]

Efraim, Guix,

Efraim Flashner 写道：

tipp10 Debian continues to build with qt-4


In cases like this one (where the software has been unmaintained 
for years), is the plan simply to remove them altogether?


(Fine by me,)

T G-R


signature.asc
Description: PGP signature

Re: Testing changes on Berlin before pushing changes? (Was: Re: bug#35521: Mariadb test suite failures on x86_64-linux)

[Marius Bakke]

Chris Marusich  writes:

> Hi Marius,
>
> Thank you for your work on Mariadb in bug 35521.  You are a hero!  Well,
> my hero at least, since this was blocking me from upgrading things.  :-)

Glad it worked for you :-)

>
> Marius Bakke  writes:
>
>> I was about to push this patch to core-updates:
>>
>> diff --git a/gnu/packages/databases.scm b/gnu/packages/databases.scm
>> index 6bfeaad9a2..5d256b1af2 100644
>> --- a/gnu/packages/databases.scm
>> +++ b/gnu/packages/databases.scm
>> @@ -706,9 +706,6 @@ Language.")
>>;; 2030-12-31.  See  for 
>> details.
>>"main.mysqldump"
>>  
>> -  ;; XXX: Fails sporadically.
>> -  "innodb_fts.crash_recovery"
>> -
>>;; FIXME: This test fails on i686:
>>;; -myisampack: Can't create/write to file (Errcode: 
>> 17 "File exists")
>>;; +myisampack: Can't create/write to file (Errcode: 
>> 17 "File exists)
>> @@ -753,7 +750,10 @@ Language.")
>>   (with-directory-excursion "mysql-test"
>> (invoke "./mtr" "--verbose"
>> "--retry=3"
>> -   "--testcase-timeout=40"
>> +   ;; On x86_64 we need a long timeout because of 
>> the
>> +   ;; TokuDB engine, whose individual test cases 
>> often
>> +   ;; require more than 1 hour to complete on busy 
>> hosts.
>> +   "--testcase-timeout=90"
>> "--suite-timeout=600"
>> "--parallel" (number->string 
>> (parallel-job-count))
>> "--skip-test-list=unstable-tests"))
>>
>>
>> Lo and behold, tokudb_bugs.mdev4533 failed when I tried it on Berlin.
>
> Perhaps I'm misunderstanding what you said, but it sounds like you were
> able to test a change on Berlin without committing it to the
> core-updates branch in Savannah.  Is that right?  If so, how did you do
> it?  Being able to quickly test changes on better hardware than my puny
> X200 could prove useful, and I'm sure others would find it useful, too.

I recently added myself as a sysadmin on Berlin at Ludovics request:

https://git.savannah.gnu.org/cgit/guix/maintenance.git/commit/?id=aefeccaae06027e0d03563b24fd1f9ac6855edaf

Contact guix-sysadmin@ if you would like to join.  Note that being
sysadmin on Berlin comes with a certain amount of responsibility in
terms of troubleshooting build failures and watching the CI system ;-)


signature.asc
Description: PGP signature

Re: 01/01: guix: node-build-system: Use guile-json instead of a custom parser.

[Robert Vollmert]

> On 15. Jul 2019, at 14:25, Ludovic Courtès  wrote:
> 
> Hi,
> 
> Robert Vollmert  skribis:
> 
>> It’s a bit my fault, for remarking on the fact that the cargo build
>> system does use guile-json. I suppose that’s not worth fixing either
>> at this point?
> 
> Indeed, ‘cargo-build-system’ has the same problem:
> 
> --8<---cut here---start->8---
> (define %cargo-build-system-modules
>  ;; Build-side modules imported by default.
>  `((guix build cargo-build-system)
>(json parser)
>,@%cargo-utils-modules))
> --8<---cut here---end--->8---
> 
> We should definitely fix it, or we’ll run into discrepancies like I
> described.
> 
> For now, the easiest option would be to use (guix build json) as well.
> 
> Could you look into it, Robert?

Done: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36676

(Was the cargo-build-system not even working a known issue? I don’t
see a bug report…)

Re: qt4 packages

[Andreas Enge]

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

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

Andreas

Re: Organizing packages

[Jesse Gibbons]

On Mon, 15 Jul 2019 19:38:34 +0200
Robert Vollmert  wrote:

> > On 15. Jul 2019, at 19:21, Jesse Gibbons 
> > wrote:
> > 
> > On Sun, 14 Jul 2019 15:54:10 +0200
> > Ludovic Courtès  wrote:
> >   
> >> Hello!
> >> 
> >> Jesse Gibbons  skribis:
> >>   
> >>> I noticed that a few files have only one package definition and
> >>> are named for that package. I think these packages can be
> >>> organized better. Might I suggest the following rules:
> >>> 
> >>> 1. if a package is a library for a particular language $LANG (like
> >>> Python, Perl, etc.) it goes in ${LANG}-xyz.scm. If it is a library
> >>> built for a particular PURPOSE, it may go into LANG-PURPOSE.scm
> >>> with those packages.
> >>> 
> >>> 2. If the package defines a compiler or interpreter for a language
> >>> $LANG, it may go into ${LANG}.scm
> >>> 
> >>> 3. If the package is part of a large divisible project $PROJ like
> >>> gcc or texlive, it may go into ${PROJ}.scm
> >>> 
> >>> 4. If the package is maintained a part of a large desktop
> >>> environment $DE like GNOME or KDE, it may be put in ${DE}.scm
> >>> 
> >>> 5. When in doubt, the package must go into a file named after its
> >>> $PURPOSE, ${PURPOSE}.scm. For example, if the package is a game
> >>> (like supertuxracer), it goes into games.scm; if it is for
> >>> undirected fun (like sl), it goes into toys.scm; if it is for
> >>> audio control or audio production, it goes into audio.scm; if it
> >>> is for drawing or producing graphics, it goes into graphics.scm;
> >>> etc. Projects that can be described with multiple purposes (like
> >>> fortune) may go into any of those files.
> >> 
> >> I had experience with Nixpkgs, which has a decision tree for where
> >> to put packages:
> >> 
> >>  https://nixos.org/nixpkgs/manual/#sec-hierarchy
> >> 
> >> In the end I didn’t find it to be helpful in any way: you’d always
> >> have to open ‘top-level/all-packages’, a file that lists all the
> >> packages, to find out where the package you’re looking for lives.
> >> 
> >> I believe ‘guix edit’ greatly solves that (along with Helm or
> >> similar editor support for grepping.)
> >>   
> > Interesting. So is it worth trying to organize the guix packages or
> > do you think it will get too complicated? I'm primarily bothered by
> > the number of small files with only one package definition and the
> > inconsistency in how packages are organized. I would rather a file
> > have multiple package definitions that make sense together than a
> > hundred files with only one package definition.  
> 
> Just to voice some support for a consistent approach. It would be
> beneficial in a similar way that a consistent indentation style
> helps: Less decisions to make, less opportunity for bike-shedding
> discussions.
> 
> (Personally, one file per package sounds fine, too. No confusion
> about why which module imports what. No overhead deciding where to
> file a package. No need to grep around for where a package might be
> defined.)
> 

I too wouldn't mind a one-package-per-file approach as long as it is
consistent. But consider packages that have multiple parts like gcc and
texlive, as well as the dictionaries packages that are generated with
non-public syntax like the french dictionaries in libreoffice.scm, not
to mention the packages for both python2 and python3. I think there's a
good reason to cluster them into groups. But the one-package-per-file
approach would affect guix search in a significant negative way, as I
pointed out unless something is done to change how guix search works.

Re: Can we increase the print width/column in daemon backtraces

[Robert Vollmert]

On 15. Jul 2019, at 20:38, Robert Vollmert  wrote:
> 
>> On 15. Jul 2019, at 17:40, Ricardo Wurmus  wrote:
>> 
>> P  writes:
>> 
 Hi Pierre,
 
> Quite often when packaging and iterating, the daemon produces backtraces
> on errors, which could be very useful to understand what's wrong, but
> unfortunately the output is truncated to some 80-ish column.
 
 Set the COLUMNS environment variable to some large value.
 
>>> Can't it just not truncate them? This is a very brutish way of
>>> condensing log output and breaks some workflows.
>> 
>> I also don’t like it, but that’s what Guile does.  (It’s not Guix that
>> truncates the output.)
> 
> It’s open source, though, isn’t it? Let’s fix it!

I sent a patch against guile: 
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36677

If you’d like to try it in guix, here’s a patch to apply the patch to 
guile-next,
though I guess to make it apply to the build daemon you’d have to apply it to
gnu/packages/guile.scm:guile/fixed.

Happy to submit a patch to do that.

Re: Organizing packages

[Ricardo Wurmus]

Jesse Gibbons  writes:

> Interesting. So is it worth trying to organize the guix packages or do
> you think it will get too complicated? I'm primarily bothered by the
> number of small files with only one package definition and the
> inconsistency in how packages are organized. I would rather a file have
> multiple package definitions that make sense together than a hundred
> files with only one package definition.

I think it doesn’t matter much, but in some cases having separate
modules even if they only contain one package definition can be really
important because it reduces the “module closure” of certain packages.
Our modules are heavily interdependent and that’s bad as we cannot
easily split up the work that has to be done by “guix pull”.

We shouldn’t have to evaluate all or most modules just to build the
derivations for core packages.  In those cases smaller modules can be
used to cut inter-module references.

(In many other cases, however, that’s just how package definitions were
organized in the early days of Guix.  Moving them around is fine if the
move is a clear improvement.)

--
Ricardo

Re: qt4 packages

[Hartmut Goebel]

Am 15.07.19 um 20:54 schrieb Tobias Geerinckx-Rice:
> Efraim, Guix,
>
> Efraim Flashner 写道：
>> tipp10 Debian continues to build with qt-4
>
> In cases like this one (where the software has been unmaintained for
> years), is the plan simply to remove them altogether? 


Why drop a package which is still okay, just because it it unmaintained?


-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: qt4 packages

[Efraim Flashner]

On Mon, Jul 15, 2019 at 09:48:36PM +0200, Andreas Enge wrote:
> On Mon, Jul 15, 2019 at 09:17:02PM +0300, Efraim Flashner wrote:
> > texmacs Debian dropped 2(?) versions ago
> 
> I just added it during the Guile/Guix days at Strasbourg, please do not
> drop it... Also, it is a GNU project. It may have been removed from Debian
> because it depends on guile-1.8; but there is hope they will eventually
> move to a more recent version.
> 

Sorry, this is my bad. On IRC yestday it was mentioned that
javascriptcore in qt-4 wasn't building on core-updates and the
suggestion was made to drop it. I should've mentioned it in my original
post. Seeing as Debian aparently still supports (most of) qt-4 it may be
worth looking at how they do that.

-- 
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