Re: 02/04: monads, gexp: Prevent redefinition of syntax parameters.

[Ricardo Wurmus]

guix-comm...@gnu.org writes:

> civodul pushed a commit to branch master
> in repository guix.
>
> commit 8245bb74fc7bdcdc2f9d458057cefc9cd982e489
> Author: Ludovic Courtès 
> Date:   Wed Feb 6 21:58:43 2019 +0100
>
> monads, gexp: Prevent redefinition of syntax parameters.
>
> Fixes .
>
> This fixes multi-threaded compilation of this code where syntax
> parameters could end up being redefined and where a race condition could
> lead a thread to see the "wrong" value of the syntax parameter.
>
> * guix/monads.scm (define-syntax-parameter-once): New macro.
> (>>=, return): Use it.
> * guix/gexp.scm (define-syntax-parameter-once): New macro.
> (current-imported-modules, current-imported-extensions): Use it.

Oh yeah!

Thank you so much for squashing this bug (and all of those it was merged
with)!

--
Ricardo

Re: Policy to remove obsolete packages

[Ricardo Wurmus]

swedebugia  writes:

> I like the idea of keeping it simple and now we tried the lumped
> modules approach. I don't like it so much to be honest.
>
> It comes with obvious drawbacks when the package per file grow and
> subcategorization have to be done.
>
> But is it efficient in guile to load hundreds of modules where all
> pull in more or less the same dependencies?
>
> If yes I think your idea is worthwhile Nils.
>
> We might have 3 repos: wip, core, extra
[…]

This is a tangent.  This thread is about removing obsolete packages.
Let’s not discuss moving packages each to their own module here.  This
has been discussed elsewhere and it’s a can of worms (which is fine if
you’re a bird, but not so good if you want to close the can again).

If you’re interested in playing with this you can do this in a local
branch and see how it behaves and what drawbacks it has.  But I don’t
think it’s a good use of our time discussing it (again).

--
Ricardo

Re: Policy to remove obsolete packages

[zimoun]

Hi,

I understand but I am not sure to see the points and/or advantages
about a policy.

>From my opinion, obsolete package is not well-defined and define
cleanly what an obsolete package is will be bikeshedding. :-)
And I think that deprecated should come from upstream.
However, a popcon of the downloaded substitutes should provide which
packages are "important" and which are less; to have a better
"priority list"---if needed.

To me, all the QA dance of the "classic" distros come from two key
points: missing the rollback and the dependency hell. Because it is
hard to rollback if the update/upgrade fails, the user must be sure
that nothing will break.
Since Guix fixes these two points by design, it does not need a strong
QA, I guess.

But, I do agree with you that it should not be possible that `guix
pull [options]' then `guix build ' fail. Never. :-)
And maybe the "CI" should have a mechanism such that: pull from
branch-unstable, refresh and eval then automatically push to
branch-stable if ok, otherwise blame the committer who will manually
fix and will push again to branch-unstable. The regular user can add
the both branches with the channel mechanism and they will be more
sure that `guix pull --commit=' will always work and obtain the last
half baked cutting edge stuffs too.

And I also do agree that it is hard to find the information what it
went wrong. For example, recently I was not able to find what breaks
clang@3.5.


Well, talk does not cook the rice. :-)
(I mean not sure my words are relevant)

All the best,
simon

Re: Policy to remove obsolete packages

[swedebugia]

On 2019-02-06 23:32, Ricardo Wurmus wrote:

This is a tangent.  This thread is about removing obsolete packages.
Let’s not discuss moving packages each to their own module here.  This
has been discussed elsewhere and it’s a can of worms (which is fine if
you’re a bird, but not so good if you want to close the can again).

If you’re interested in playing with this you can do this in a local
branch and see how it behaves and what drawbacks it has.  But I don’t
think it’s a good use of our time discussing it (again).


Thanks for the heads up. I missed the conversation. Its not really that 
important to me anyway.


--
Cheers
Swedebugia

Change syntax of '--with-source' flag to match syntax of '--with-commit' flag?

[pkill9]

The '--with-commit' flag changes the source used to build a package, the syntax 
takes the form of '--with-commit=='.

The '--with-source' flag also changes the source, but uses the syntax 
'--with-source=', but only transforms the top-level package (e.g. 
`guix build ` or `guix environment --ad-hoc ``). It also only works if the new source file has the form '-.', which means if a package source URL isn't 
named in that way, then you have to first download it, rename it to fit that 
template, then use --with-source with that file.

I propose changing the syntax of '--with-source=' to match the syntax of 
'--with-commit='. This would have the following benefits:

 - No need to download and rename files that don't fit the '-.' format.
 - Able to change the source file of a package input of any package in the 
package graph.
 - Makes the syntax consistent with '--with-commit='.

What do other people think?

Spliting a huge package

[Hartmut Goebel]

Hi,

following up a discussion from the GNUne mailinglist about how to slice
the software, I would like to learn about the best practice of packaging
huge packages in guix.

Assume gnuet will be delivered a one big TGZ, inclusing base-libs,
core-services, additional-services, guis for services. For e.g.
RPM-based distros the TGZ would be build once and then sliced into
packages like

- gnunet(-core)
- gnunet-gns-proxy
- gnunet-fs
- gnunet-fs-gui
- gnunet-conversation
- gnunet-conversation-gtk

When packaging with guix, one way would be to create several output (fs,
fs-gui, etc.). This would require uses to install e.g. "gnunet:fs-gui"
which is, well, curious for users.

What is the intened way to solve this in guix?

-- 
Regards
Hartmut Goebel

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




signature.asc
Description: OpenPGP digital signature

Re: New videos: topic daily use.

[Laura Lazzati]

Hi!
On Wed, Feb 6, 2019 at 7:17 PM Ricardo Wurmus  wrote:

> > I was thinking of daily use of guix package, mentioning profile,
> > generations (both the concepts and commands to deal with them)
>
> Sounds good.  “--install”, “--roll-back”, and maybe even “--manifest”
> for stateless installations would be good topics to cover.
What about --list-generaitions, --delete-generations?
-url-substitutes? Or are they too much / go whith gc?

Re: New videos: topic daily use.

[Ricardo Wurmus]

Laura Lazzati  writes:

> On Wed, Feb 6, 2019 at 7:17 PM Ricardo Wurmus  wrote:
>
>> > I was thinking of daily use of guix package, mentioning profile,
>> > generations (both the concepts and commands to deal with them)
>>
>> Sounds good.  “--install”, “--roll-back”, and maybe even “--manifest”
>> for stateless installations would be good topics to cover.
> What about --list-generaitions, --delete-generations?
> -url-substitutes? Or are they too much / go whith gc?

I would skip “--substitute-urls” because it’s not a very common thing to
change.  “--list-generations” and “--delete-generations” could very well
be part of the video on “guix package”.

--
Ricardo

Re: Spliting a huge package

[ng0]

Hartmut Goebel transcribed 2.5K bytes:
> Hi,
> 
> following up a discussion from the GNUne mailinglist about how to slice
> the software, I would like to learn about the best practice of packaging
> huge packages in guix.
> 
> Assume gnuet will be delivered a one big TGZ, inclusing base-libs,
> core-services, additional-services, guis for services. For e.g.
> RPM-based distros the TGZ would be build once and then sliced into
> packages like
> 
> - gnunet(-core)
> - gnunet-gns-proxy
> - gnunet-fs
> - gnunet-fs-gui
> - gnunet-conversation
> - gnunet-conversation-gtk
> 
> When packaging with guix, one way would be to create several output (fs,
> fs-gui, etc.). This would require uses to install e.g. "gnunet:fs-gui"
> which is, well, curious for users.
> 
> What is the intened way to solve this in guix?

i think if you want the direct analogy to the thread, as I understand it,
we'd get separate package definitions and not separate build outputs.
At least my understanding right now is that it could be distributed like
this and that downstreams should be able to build from source various
small pieces of gnunet. Maybe a 'make dist' could separate it already
earlier.

But Canonically I think we'd solve this with outputs in guix, at least
when you look at git and other, similar applications.

The idea is to reduce dependencies, which is then up to Guix to pick the
right way. Outputs seems like the wrong approach here at least from
upstream perspective.

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

Re: Video documentation repository

[Ludovic Courtès]

Hello!

Björn Höfling  skribis:

> On Tue, 05 Feb 2019 00:02:20 +0100
> Ludovic Courtès  wrote:
>
>> Great initiative!  I can’t create it myself but I’ve filed a support
>> request:  (the Savannah
>> hackers usually respond within a couple of days.)
>
> Thank you for filing the request. There you wrote:
>
>> This repository will *not* contain any video.  Instead, it will
>> contains scripts and tools developed as part of an ongoing Outreachy
>> internship to create internationalized videos presenting Guix.
>
> In the current video-repository we at least save the input binaries
> (i.e speech recordings in several languages for several videos). From
> your comment it sounds like that is not intended for the
> savannah-repos, right?

True.  I mostly wanted to reassure them that this would not be a huge
repo containing only binary files.  So I guess it’s OK to save audio
tracks as long as it doesn’t grow too much.

If/when it happens to grow quickly than expected, we’ll ask the Savannah
folks whether it’s still fine with them.

> If so, we need to somehow externalize those. What would be a reliable
> way of doing so? Uploading to some (which?) server? MediaGoblin? Storing
> in IPFS as we do currently with the output videos for distribution among
> us? Is there any stable IPFS node where we can stick them to?

I’d say we can think about that later if it becomes a problem.

>> I guess we could give Laura access to the repo (that gives access to
>> all the project repos so one has to be cautious, but that’s probably
>> OK.) Thoughts?
>
> I think we gave permissions to all former GSoC/Outreachy students,
> right? So I'm fine with it.

Alright!

Laura, could you please upload the OpenPGP key that you will be using to
sign commits to , and then reply
to this message signed with that same key?  (If you need help setting
that up, we can discuss it off-list.)

Please read the ‘HACKING’ file as well.  Technically you’ll have access
to all the Guix repositories, but for now I’d prefer you to restrict
pushes to the video repo (once it has been created, that is :-)).  That
said, you’re of course welcome to contribute to the other repos, but
please email guix-devel or guix-patches beforehand.

Thanks!

Ludo’.


signature.asc
Description: PGP signature

News from the Guix Days!

[Ludovic Courtès]

Hello Guix!

Efraim kindly wrote about a session he participated in at the Guix Days:

  https://gnu.org/software/guix/blog/2019/qa-on-non-intel-at-guix-days/

Congrats on fixing Go on ARM!  \o/

I’d like to invite the other participants :-) to either prepare a
Markdown-formatted summary of their session to publish on the blog¹
(make sure it’s understandable by outsiders too!), or to send their
notes or memories of the discussions on this list.

That way, those of us who didn’t make it in Brussels can still learn
about what we discussed and possibly continue the discussion on-line.

Thanks!  :-)

Ludo’.

¹ See what the Markdown files look like at
  .

Re: [PATCH] gnu: Add ungoogled-chromium.

[Christopher Lemmer Webber]

Ludovic Courtès writes:

> Hi bill-auger,
>
> bill-auger  skribis:
>
>> re: https://lists.gnu.org/archive/html/guix-devel/2019-02/msg9.html
>>
>> i would like to remind readers of the guix-devel list that it was
>> discussed some months ago, why no FSDG distros currently distribute
>> chromium[1] - it appeared at that time, that most people in that
>> discussion were in agreement that chromium should not be included in
>> guix; and marius was instead hosting it in a private repo, as not to
>> taint the main guix repos with dubious software - has there been a
>> notable break-through since then?
>
> It’s not entirely clear to me what the problems are, to be honest.
> Marius listed specific issues that were addressed by the patches; others
> then pointed out at additional issues that ungoogled-chromium fixes,
> which Marius took into account; what’s left now?
>
> I understand you’re skeptical about Chromium, but we cannot base
> decisions based on vague skepticism.  If you know of issues that are
> still unaddressed, please do list them.
>
> I’d also like to stress that, if Chromium is eventually included in
> Guix, we are committed to fixing it or removing it should someone later
> discover that it does not comply with the FSDG (that’s the “Commitment
> to Correct Mistakes” section of FSDG.)

+1 ... If concrete problems are found, by all means those should be
raised and addressed.  Otherwise I really think we ought to merge this
work.

Re: [GNU-linux-libre] [PATCH] gnu: Add ungoogled-chromium.

[Julie Marchant]

On 02/07/2019 06:52 PM, Christopher Lemmer Webber wrote:
> Ludovic Courtès writes:
> 
>> Hi bill-auger,
>>
>> bill-auger  skribis:
>>
>>> re: https://lists.gnu.org/archive/html/guix-devel/2019-02/msg9.html
>>>
>>> i would like to remind readers of the guix-devel list that it was
>>> discussed some months ago, why no FSDG distros currently distribute
>>> chromium[1] - it appeared at that time, that most people in that
>>> discussion were in agreement that chromium should not be included in
>>> guix; and marius was instead hosting it in a private repo, as not to
>>> taint the main guix repos with dubious software - has there been a
>>> notable break-through since then?
>>
>> It’s not entirely clear to me what the problems are, to be honest.
>> Marius listed specific issues that were addressed by the patches; others
>> then pointed out at additional issues that ungoogled-chromium fixes,
>> which Marius took into account; what’s left now?
>>
>> I understand you’re skeptical about Chromium, but we cannot base
>> decisions based on vague skepticism.  If you know of issues that are
>> still unaddressed, please do list them.
>>
>> I’d also like to stress that, if Chromium is eventually included in
>> Guix, we are committed to fixing it or removing it should someone later
>> discover that it does not comply with the FSDG (that’s the “Commitment
>> to Correct Mistakes” section of FSDG.)
> 
> +1 ... If concrete problems are found, by all means those should be
> raised and addressed.  Otherwise I really think we ought to merge this
> work.

Yes, exactly.

-- 
Julie Marchant
http://onpon4.github.io

Encrypt your emails with GnuPG:
https://emailselfdefense.fsf.org