Re: Extending Guix without using the Guile load path

[Ricardo Wurmus]

Ludovic Courtès  writes:

> What if an extension could instead be a package installed next to Guix
> and its channels in ~/.config/guix/current, and we use
> ‘package-path-entries’ as is done in (gnu packages) to augment
> ‘%load-path’ and ‘%load-compiled-path’?

I’m not sure if that would complicate installation too much.  Installing
a package in the “guix pull” profile suggests to me that it is installed
when “guix pull” is run, and not by “guix package -p
~/.config/guix/current -i my-extension”.

I suppose it would help with propagated inputs, because they would also
end up in the “guix pull” profile, but perhaps that’s not really
desirable as an extension probably should not be able to accidentally
break Guix just because it uses a different version of a Guile library
that Guix also happens to use.

Keeping the directory tree of the extension separate from the “guix
pull” profile would ensure that the core features of Guix keep working,
no matter how badly broken an extension might be.

So I’m thinking that we should instead define GUIX_EXTENSIONS_PATH as a
list of directories containing merely the *entry points* for additional
Guix commands.  For example, the GWL would provide a script “workflow”
in a directory $prefix/share/guix/extensions/ (or whatever), and that
script is a wrapped executable that sets its own %load-path and
%load-compiled-path as needed (and determined at build time).  All Guix
does is search for matching executables on GUIX_EXTENSIONS_PATH when
asked for an unknown command.

This is disappointingly simple, but I think it’s one of the safest
things to do.

An incidental side effect of doing things this way is that extensions
could, in theory, be written in languages other than Guile (stretching
the meaning of “extension” to its limits).

-- 
Ricardo

Re: Getting rid of the mandb profile hook?

[Ricardo Wurmus]

Ludovic Courtès  writes:

> I’m thinking we could get rid of the mandb hook.

Yes, please!

>   1. Provide a ‘man’ wrapper or modify the ‘man-db’ package such that
>  the database gets built on the first use of ‘man -k’, unless it’s
>  already up-to-date.
>
>   2. Add a phase in gnu-build-system.scm that creates a per-package
>  database.  Change the mandb profile hook such that all it needs to
>  do is “concatenate” all these GDBM databases (which should be much
>  faster than browsing all the man pages as it currently does).

Either of these seem fine to me.  I think option 2 would be nicer as we
don’t need to modify “man” and most of the work is done ahead of time.
I don’t know if these individual mandb database *can* simply be
concatenated.  If this turns out to be much more complicated I think we
should just go with option 1.

-- 
Ricardo

Re: December 2020 (old) bugs squashing!

[Ricardo Wurmus]

Bonface M. K.  writes:

> Just curious, how do you get debbugs to show
> forgotten patches. I'm only beginning to use it
> now ...

Debbugs doesn’t have a built-in mechanism to query forgotten issues.
Mumi implements “forgotten-bug-numbers”, which has the following
docstring:

  "Return the numbers of issues that are open but haven't seen any
activity for a while.  The duration is given by SECONDS-AGO, which
defaults to 30 days."

-- 
Ricardo

Re: Questionable "cosmetic changes" commits

[Bengt Richter]

Hi Christopher and Raghav,

On +2020-12-05 21:54:36 +, Christopher Baines wrote:
> 
> Raghav Gururajan  writes:
> 
> > Hi Mark!
> >
> >> Meanwhile, you've only provided a rationale for 1 out of 3 of the kinds
> >> of changes made in these commits.
> >> 
> >> Do you have an explanation for why you are removing comments in your
> >> "cosmetic changes" commits? For example, the following two commits
> >> remove comments that explain why 'propagated-inputs' are needed:
> >> 
> >> https://git.sv.gnu.org/cgit/guix.git/commit/?id=c3264f9e100ad6aefe5216002b68f3bfdcf6be95
> >> https://git.sv.gnu.org/cgit/guix.git/commit/?id=416b1b9f56b514677660b56992cea1c78e00f519
> >> 
> >> What's your rationale for doing this? Am I the only one here who finds
> >> this practice objectionable? It's not even mentioned in the commit logs.
> >
> > I think the comments are useful for non-trivial cases. In these
> > definitions, the inputs were propagated because they were mentioned in
> > .pc files. Propagation because of pkg-config is trivial. So I removed
> > the comments.
>
┌──┐
│ "So I removed the comments." │
└──┘
Raghav, I think you may not grok the social signalling of a statement like that 
:)

It sounds like you are overlooking the _social_ need for consensus
in modifying a shared environment.

Taking a picture off the wall of a shared living room is different
from taking the same picture off the wall in your private room.

A git commit in a jointly developed FLOSS project is modifying a shared living 
room.
(But do what you like in your own git repo ;-)

The social aspect is not about the technical merits of of your changes,
it's about the difference between joint ownership and private ownership,
and the differences in exercising owner rights.

> In the context of writing Guix packages, propagating the necessary
> inputs to support other packages finding the library via pkg-config is a
> serious thing, not trivial. If it breaks, dependent packages will likely
> change in behaviour or stop building entirely.
> 
> As for the comments, personally, I think the reasons behind propagated
> inputs are individual enough and important enough to each package that
> it's useful to write them down, even if that comment is "these things
> are referenced by the .pc file". That way others looking at the package
> definition don't have to wonder or try and dig through the Git history
> to find information about what's going on.
> 
> Anyway, I think the most useful output from this discussion is amending
> or adding to the packaging guilelines to cover this:
> 
>   https://guix.gnu.org/manual/en/html_node/Packaging-Guidelines.html

-- 
Regards,
Bengt Richter

Cosmetic changes commits as a potential security risk (was Re: Questionable "cosmetic changes" commits)

[Mark H Weaver]

Hi Raghav,

I asked:
>> Do you have an explanation for why you are removing comments in your
>> "cosmetic changes" commits?

"Raghav Gururajan"  replied:
> I think the comments are useful for non-trivial cases.  In these
> definitions, the inputs were propagated because they were mentioned in
> .pc files.  Propagation because of pkg-config is trivial.  So I
> removed the comments.

Thanks for the explanation.

Please keep in mind that every comment in Guix was deliberately put
there by a Guix developer, which means that at least one developer
thought the comment was worth including.

I'm concerned that you felt so confident in your assessment that these
comments were superfluous that you felt justified in removing them
without telling anyone, let alone asking your mentors if they agreed.

My larger concern is that these removals were effectively hidden within
a commit that ostensibly only rearranged and reindented code.

* * *

It occurs to me that commits that rearrange or reindent code are a
potential security risk, because they obscure other changes made within
the same commit.  Even developers who try to keep an eye on changes
being made to Guix tend to simply *assume* that commits like these are
what they claim to be, because it's too tedious to verify them.

If we allow unannounced changes to be obscured within "cosmetic changes"
commits without reprimand, we invite the future possibility of
deliberate corruption of our code base via such commits, by attackers
who have compromised our developers' machines or signing keys.

* * *

Having said all of this, I should also say that I truly appreciate your
contributions, Raghav, and I'm glad that you are here.

  Regards,
Mark

Re: Questionable "cosmetic changes" commits

[Christopher Baines]

Raghav Gururajan  writes:

> Hi Mark!
>
>> Meanwhile, you've only provided a rationale for 1 out of 3 of the kinds
>> of changes made in these commits.
>> 
>> Do you have an explanation for why you are removing comments in your
>> "cosmetic changes" commits? For example, the following two commits
>> remove comments that explain why 'propagated-inputs' are needed:
>> 
>> https://git.sv.gnu.org/cgit/guix.git/commit/?id=c3264f9e100ad6aefe5216002b68f3bfdcf6be95
>> https://git.sv.gnu.org/cgit/guix.git/commit/?id=416b1b9f56b514677660b56992cea1c78e00f519
>> 
>> What's your rationale for doing this? Am I the only one here who finds
>> this practice objectionable? It's not even mentioned in the commit logs.
>
> I think the comments are useful for non-trivial cases. In these
> definitions, the inputs were propagated because they were mentioned in
> .pc files. Propagation because of pkg-config is trivial. So I removed
> the comments.

In the context of writing Guix packages, propagating the necessary
inputs to support other packages finding the library via pkg-config is a
serious thing, not trivial. If it breaks, dependent packages will likely
change in behaviour or stop building entirely.

As for the comments, personally, I think the reasons behind propagated
inputs are individual enough and important enough to each package that
it's useful to write them down, even if that comment is "these things
are referenced by the .pc file". That way others looking at the package
definition don't have to wonder or try and dig through the Git history
to find information about what's going on.

Anyway, I think the most useful output from this discussion is amending
or adding to the packaging guilelines to cover this:

  https://guix.gnu.org/manual/en/html_node/Packaging-Guidelines.html


signature.asc
Description: PGP signature

Re: [support-re...@gandi.net: [GANDI] guixsd.org expires in 60 days]

[Tobias Geerinckx-Rice]

zimoun 写道：

Hi Tobias,


Hi!

Guix uses ci.guix.gnu.org by default since May 2019.  No one 
should be running a daemon older than that.


I think you misunderstood my (and Ludo's) point, which was to 
prevent possible abuse of a name still in common use.  For 
whatever reason, outside of our little echo chamber people say 
GuixSD, not Guix System.  Squatting guixsd.org will attract plenty 
of traffic to whatever message the squatter wishes to spread.  I 
don't have a strong opinion either but don't think the cost 
savings cover that risk.


If Andreas is tired of dealing with renewals (which I'd 
understand) I'm sure we can find a solution.



Note that www.guixsd.org does not redirect.


You're right :-(

guixsd.org isn't managed by GNU, and I don't have access to the 
Gandi hosted DNS interface.


Kind regards,

T G-R


signature.asc
Description: PGP signature

Re: FreeCAD fails to compile

[Ekaitz Zarraga]

On Saturday, December 5, 2020 5:55 PM, John Soo  wrote:

> Nice work Ekaitz!
>
> I worked hard on freecad, it is quite a difficult program to package. That 
> was a weird issue that I asked about on the freecad forums. Perhaps it is 
> fixed upstream now, which would be excellent. Thanks for keeping it up to 
> date!
>
> - John

Hey!
I think I found you post.
I'm hitting against the same wall. The funny thing is the thread says [SOLVED].
I have a couple of ideas but this thing is hard to build...

I'll fight with all my soul, and keep you posted.

Thanks for the support,
Ekaitz

Re: Questionable "cosmetic changes" commits

[Raghav Gururajan]

Hi Mark!

> Meanwhile, you've only provided a rationale for 1 out of 3 of the kinds
> of changes made in these commits.
> 
> Do you have an explanation for why you are removing comments in your
> "cosmetic changes" commits? For example, the following two commits
> remove comments that explain why 'propagated-inputs' are needed:
> 
> https://git.sv.gnu.org/cgit/guix.git/commit/?id=c3264f9e100ad6aefe5216002b68f3bfdcf6be95
> https://git.sv.gnu.org/cgit/guix.git/commit/?id=416b1b9f56b514677660b56992cea1c78e00f519
> 
> What's your rationale for doing this? Am I the only one here who finds
> this practice objectionable? It's not even mentioned in the commit logs.

I think the comments are useful for non-trivial cases. In these definitions, 
the inputs were propagated because they were mentioned in .pc files. 
Propagation because of pkg-config is trivial. So I removed the comments.

Regards,
RG.

Re: [support-re...@gandi.net: [GANDI] guixsd.org expires in 60 days]

[zimoun]

Hi Tobias,

On Sat, 05 Dec 2020 at 17:25, Tobias Geerinckx-Rice  wrote:

> I believe that consistently redirecting[0] these old names to 
> guix.gnu.org makes them much less harmful to keep around, and 
> better than giving up control completely.

Which versions of Guix uses only the old URLs?  Are they reachable with
inferiors?  Are the substitutes still available on Berlin and friends
for these old Guix versions?

Otherwise, I do not see the rationale.  If the Guix code current and
reachable by “guix time-machine” provides the right URL (say ci.guix.gnu.org
instead of berlin.guixsd.org), then I do not see why it matters to keep
the control of berlin.guixsd.org; because nothing will break if the old
URLs are removed.  Do I miss an obvious point?


Note that www.guixsd.org does not redirect.

All the best,
simon

Re: Getting rid of the mandb profile hook?

[Ryan Prior]

On December 5, 2020, "Ludovic Courtès"  wrote:
> many actions should be done lazily, in particular populating caches.

Absolutely.

> I’m thinking we could get rid of the mandb hook.

Please.

>  1. Provide a ‘man’ wrapper or modify the ‘man-db’ package such that
>  the database gets built on the first use of ‘man -k’, unless it’s
>  already up-to-date.

I vote for this one. Anything work we can defer to make package
operations near-instantaneous will help me make Guix a seamless part of
my computing workflows. As things stand, adopting Guix comes along with
regular "pause to wait for Guix to think about something you probably
don't care about" breaks.

Re: Getting rid of the mandb profile hook?

[Pierre Neidhardt]

I think it's a very good idea, I'm all for it!

Cheers!

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


signature.asc
Description: PGP signature

Getting rid of the mandb profile hook?

[Ludovic Courtès]

Hi Guix!

I was inspired by Michael Stapelberg’s talk recently shared on IRC¹
(well worth watching!).  One of the takeaways for me is that many
actions should be done lazily, in particular populating caches.

‘guix install’ & co. spend a significant time populating such caches, in
particular the XDG caches² and the manual page database (mandb).

I’m thinking we could get rid of the mandb hook.  However, the
functionality matters IMO (we need good tools so users can browse local
documentation; mandb is not that good but better than no search
mechanism.)  Here are several options that come to mind:

  1. Provide a ‘man’ wrapper or modify the ‘man-db’ package such that
 the database gets built on the first use of ‘man -k’, unless it’s
 already up-to-date.

  2. Add a phase in gnu-build-system.scm that creates a per-package
 database.  Change the mandb profile hook such that all it needs to
 do is “concatenate” all these GDBM databases (which should be much
 faster than browsing all the man pages as it currently does).

There are crazier option that came to mind but let’s ignore them for
now.

Thoughts?  :-)

Ludo’.

¹ “distri: researching fast Linux package management”
  
https://media.ccc.de/v/arch-conf-online-2020-6387-distri-researching-fast-linux-package-management

² https://issues.guix.gnu.org/44053#4

Re: [support-re...@gandi.net: [GANDI] guixsd.org expires in 60 days]

[Andreas Enge]

Hello,

On Sat, Dec 05, 2020 at 05:25:58PM +0100, Tobias Geerinckx-Rice wrote:
> If cost is a pain point, note that Gandi's current annual renewal price of
> €19 isn't the lowest around.

cost is not the problem; but I like tidying up and getting rid of cruft,
and I feel that this old domain is some hassle for not much gain: I need to
- pay by credit card;
- make a wire transfer from the Guix Europe account to my own account;
- add an entry to the Guix Europe ledger and check everything is okay.

I was against renewing it already two years ago, but the Solidary
Administrative Council of Guix Europe decided by consensus last year
to keep it for one more year, and to let it run out later.

If you prefer to keep the domain, you should bring it for a discussion
and a new vote of the SAC. I am still against renewing it, but if people
think we should do it, I can live with a renewal as well.

Andreas

Re: December 2020 (old) bugs squashing!

[Bonface M. K.]

zimoun  writes:

> Hi,
>
> Let’s have an Advent calendar effort!  Everybody out there who is not
> familiar with this tradition of an « Advent calendar » and to avoid any
> ambiguity, I am appropriating myself the concept*: all of us try to
> close one or more bug per day from 1rst to 31th December, then 2021 will
> start on new balls as in tennis match. :-)
>
> In priority let pick bugs older than #3 (~Jan. 2018).
>
> 
>
> From Debbugs, I count 151 bugs or forgotten patches, almost 3 years!
> Time to close them or investigate more.
>

Just curious, how do you get debbugs to show
forgotten patches. I'm only beginning to use it
now ...

[...]
-- 
Bonface M. K. 
Humble GNU Emacs User / Bearer of scheme-y parens
Curator:  / Twitter: @BonfaceKilz
GPG Key: D4F09EB110177E03C28E2FE1F5BBAE1E0392253F


signature.asc
Description: PGP signature

Re: FreeCAD fails to compile

[John Soo]

 Nice work Ekaitz! 

 
I worked hard on freecad, it is quite a difficult program to package. That was 
a weird issue that I asked about on the freecad forums. Perhaps it is fixed 
upstream now, which would be excellent. Thanks for keeping it up to date!
 

 
- John
 

Re: FreeCAD fails to compile

[Ekaitz Zarraga]

Looks like this line, inherited from the previous definition, was giving some 
trouble:

>  (string-append "-DCMAKE_INSTALL_LIBDIR=\\"" (assoc-ref %outputs 
> "out") "/lib\\"")


It was creating wrong variables (and wrong syntax too!):


  if(EXISTS 
"$ENV{DESTDIR}/tmp/guix-build-freecad-mine-0.18.5.drv-0/build/"/gnu/store/30rcpcdv7h6ak37wf30ijlbf9x2j6jyz-freecad-mine-0.18.5/lib"/libSMDS.so"
 AND
 NOT IS_SYMLINK 
"$ENV{DESTDIR}/tmp/guix-build-freecad-mine-0.18.5.drv-0/build/"/gnu/store/30rcpcdv7h6ak37wf30ijlbf9x2j6jyz-freecad-mine-0.18.5/lib"/libSMDS.so")


I think I'll manage to solve this myself.

Re: [support-re...@gandi.net: [GANDI] guixsd.org expires in 60 days]

[Tobias Geerinckx-Rice]

Guix,

I believe that consistently redirecting[0] these old names to 
guix.gnu.org makes them much less harmful to keep around, and 
better than giving up control completely.


If cost is a pain point, note that Gandi's current annual renewal 
price of €19 isn't the lowest around.


Ludovic Courtès 写道：
Interestingly, we received bug reports for 1.2.0 where people 
referred
to the system as “GuixSD”.  The name is still often used in 
fora.


It's quite common on #guix as well.  I wish we could configure 
sneek to react to certain keywords.  No one enjoys playing the 
broken record, and people tolerate more pedantry from bots than 
from humans.


Kind regards,

T G-R

[0]: 
https://git.savannah.gnu.org/cgit/guix/maintenance.git/commit/?id=c85e128e11d3ba060ae3a6e01da20f531b42d6ef


signature.asc
Description: PGP signature

Re: [support-re...@gandi.net: [GANDI] guixsd.org expires in 60 days]

[Ludovic Courtès]

Hi!

Andreas Enge  skribis:

> just for your information, our domain name guixsd.org will expire soon
> (how many out there still remember that we own it?). We decided last year
> to renew it for just one more year and to let it run out. 
>
> So if we still have anything pointing there, it would be good to change
> it now.

Interestingly, we received bug reports for 1.2.0 where people referred
to the system as “GuixSD”.  The name is still often used in fora.

So I guess the main argument in favor of keeping it would be to avoid
squatting and phishing.

No strong opinion from me though.

Ludo’.

Re: Poetry upgrade and related packages

[Ludovic Courtès]

Hello!

Tanguy LE CARROUR  skribis:

> It's not yet clear to me how to handle (python) package updates:
> - when to update;
> - when not to update;
> - when to introduce "versionned" (`-x.y` suffix) package definitions;
> - when to introduce "next" (`/next` suffix) package definitions;
> - when to remove the two above suffixes;
> - …
>
> So I'm looking forward to reading the answers to this thread! :-)

When a change introduces too many rebuilds, the convention is to make
that change on a branch that will be merged “later” rather than on
‘master’; this is bullet 8 here:

  https://guix.gnu.org/manual/devel/en/html_node/Submitting-Patches.html

Yet, sometimes we want to introduce new versions that people can get in
their profile, even if the “default” one remains the older version to
avoid world rebuilds.

One example is GDB: gdb@8 has 1,671 dependents, but we added gdb@10 on
the side such that “guix install gdb” gives you version 10.

I hope this helps!

Ludo’.

Re: December 2020 (old) bugs squashing!

[Ludovic Courtès]

Hey ho!

zimoun  skribis:

> Let’s have an Advent calendar effort!  Everybody out there who is not
> familiar with this tradition of an « Advent calendar » and to avoid any
> ambiguity, I am appropriating myself the concept*: all of us try to
> close one or more bug per day from 1rst to 31th December, then 2021 will
> start on new balls as in tennis match. :-)
>
> In priority let pick bugs older than #3 (~Jan. 2018).
>
> 
>
> From Debbugs, I count 151 bugs or forgotten patches, almost 3 years!
> Time to close them or investigate more.

Great initiative!  Go go bug fixers!

Nitpick: I’d call it “month of the forgotten bugs”, or “Northern
hemisphere winter of bugs”, or “the advent of fixed bugs” (lowercase).

For an immersive experience, participants may consider running:

  guix environment --ad-hoc xsnow -- xsnow

Ludo’.

FreeCAD fails to compile

[Ekaitz Zarraga]

Hi,

I solved most of the compilation issue with freecad.

Now my package version compiles but install phase fails with this error:


``` 

CMake Error at 
src/3rdParty/salomesmesh/cmake_install.cmake:41 (if):   

  if given arguments:   




  "EXISTS" "/tmp/guix-build-freecad-mine-0.18.5.drv-0/build/" 
"/gnu/store/injf0n8qja607qswa5cyxz1dpzqia21p-freecad-mine-0.18.5/lib\"/libSMDS.so\""
 "AND" "NOT" "IS_SYMLINK" "/tmp/guix-build-freecad-mine-0.18.5.drv-0/build/" 
"/gnu/store/injf0n8qja607qswa5cyxz1dpzqia21p-freecad-mine-0.18.5/lib\"/libSMDS.so\""



  Unknown arguments specified   

   Call Stack (most recent 
call first):

 src/3rdParty/cmake_install.cmake:42 (include)  

src/cmake_install.cmake:43 (include)

   
cmake_install.cmake:46 (include)
```


Did anyone see something like this before?

Right now I have no idea how to tackle this but I'll keep researching.

If anyone wants to be able to reach this point, the only changes I applied to 
the project are configure-flags suggested in this bug report with some extra 
more because the header files were not found in subdirectories. These are the 
configure flags I added (mostly copied from Nix package[^nix]):

```
(list
 "-DBUILD_QT5=ON"
 (string-append "-DCMAKE_INSTALL_LIBDIR=\"" (assoc-ref %outputs "out") 
"/lib\"")

 (string-append "-DPYSIDE2UICBINARY="
(assoc-ref %build-inputs "python-pyside-2-tools")
"/bin/uic")
 (string-append "-DPYSIDE2RCCBINARY="
(assoc-ref %build-inputs "python-pyside-2-tools")
"/bin/rcc")

 "-DPYSIDE_LIBRARY=PySide2::pyside2"
 (string-append "-DPYSIDE_INCLUDE_DIR="
(assoc-ref %build-inputs "python-pyside-2") "/include;"
(assoc-ref %build-inputs "python-pyside-2") 
"/include/PySide2;"
(assoc-ref %build-inputs "python-pyside-2") 
"/include/PySide2/QtCore;"
(assoc-ref %build-inputs "python-pyside-2") 
"/include/PySide2/QtWidgets;"
(assoc-ref %build-inputs "python-pyside-2") 
"/include/PySide2/QtGui;")

 "-DSHIBOKEN_LIBRARY=Shiboken2::libshiboken"
 (string-append "-DSHIBOKEN_INCLUDE_DIR="
(assoc-ref %build-inputs "python-shiboken-2")
"/include/shiboken2"))
```


I hope we can have something working soon!



Cheers,
Ekaitz



[^nix]: 
https://github.com/NixOS/nixpkgs/blob/7caa81d8a23f0278e868adf9054ec5409cd81f93/pkgs/applications/graphics/freecad/default.nix

Re: /etc/passwd & co. in Docker images

[Ludovic Courtès]

Danny Milosavljevic  skribis:

> On the other hand, we have this:
>
> (define-public network-manager-openconnect
>   (package
> (name "network-manager-openconnect")
> [...]
> (properties `([...]
>   ;; The 'etc/dbus-1/system.d/nm-openconnect-service.conf'
>   ;; file refers to account "nm-openconnect".  Specify it here
>   ;; so that 'network-manager-service-type' creates it.
>   (user-accounts . ("nm-openconnect"))

Nice, I had forgotten about that.  That’s a very local solution though:
only for NM VPN plugins (see e52b953434b255f53e61125c7fd3653adcebdab8).

I don’t think we’d want to generalize that: that’d be redundant with the
service framework and not the right place to add that info since it’s
only partial information about the kind of resources the service needs.

Ludo’.

Re: More thoughts on Patchwork and Guix patch review/quality assurance

[Ludovic Courtès]

Hi Chris!

Christopher Baines  skribis:

> If you're interested in using this to review patches, the place to start
> is Patchwork, so visit:
>
>   https://patchwork.cbaines.net/
>
> If you want an account, please email me. Unfortunately I had to disable
> registration due to spam.
>
> When you click through to a patch, the thing to look at is the
> checks. These should link you to the relevant bug, Git branch and Guix
> Data Service comparison. For the Guix Data Service comparison, the
> things to note are the lint warnings and then clicking through to the
> "Compare package derivations" page.

Very nice!  This is useful info when reviewing, and it’s much harder to
get this at a glance locally.

> ### Use Patchwork, rather than Debbugs to track patches
>
> So this has been a thing for 4 years now (see [2] for some graphs). I
> think I was there in the bar in Brussels when it was discussed.
>
> 2: https://debbugs.gnu.org/rrd/guix-patches.html

I remember that night in Brussels, it’s been a while!  :-)

> The main disadvantage I see of using Debbugs is that you have to get a
> bug number before you can Git send-email, in the case where you're
> sending multiple patches.
>
> The main advantage I get from Debbugs is that searching via the bug
> number is really useful.
>
> I'm unsure, I think Debbugs was introduced to help keep track of
> patches, and avoid them getting forgotten in guix-devel. Patchwork will
> do this too, but maybe Debbugs is providing more value than the cost of
> multi-patch series being slightly more difficult to submit?

To me, the main advantages of Debbugs are:

  1. the Emacs interface (I use it a lot as a reviewer, no need to open
 a browser);

  2. the clean web interface at , which I
 find less intimidating, less cluttered, and hopefully more familiar
 than that of Patchwork; it also has a useful search interface now;

  3. Having numbers and short URLs to reference issues.

Now, Patchwork “checks” and how you use them are great; simplifying
multi-patch submissions is great too.

If Mumi had hooks that could be used to run and display those checks,
I’d be super happy.  But I don’t know whether it’s reasonable, nor
whether that’s something others would also like.  :-)

All this could be complemented by CLIs to “the official Guix review
services” (Patchwork, Mumi, Data Service, etc.).  You could run:

  guix review 1234

and it’d fetch the patch(es), apply them, and/or display a status
summary based on data published by Patchwork & co.  It’s probably not
that much work if those services have HTTP APIs, and it could facilitate
adoption.

> ### Scheduled and regular collaboration on IRC to review patches
>
> When I can make some time, I'll try this out, but if anyone has some
> time they can set aside, please go ahead!

Yes!  A weekly meeting where committers and submitters are around and
focusing on getting patches merged would be great!

> ### Help users with the submitting part of submitting patches
>
> Using git send-email works well with Patchwork at least, and it's fine
> with Debbugs if you've got a single patch, but a little more time
> consuming if you're got more than one patch.
>
> Attaching a single patch file to an email works OK I think, however
> attaching multiple patch files to the same email confuses git am and
> Patchwork I believe.
>
> I think other approaches like copying the patch in to the body of an
> email, or just copying the output of git diff in to an email are very
> brittle and can make it more time consuming to try and recover or
> recreate the commit(s).
>
> Having the emails for patches is useful for reviewing, but maybe there's
> a way users could push a branch somewhere and then have some service do
> the git send-email thing on their behalf?

Yes, that would be nice.  To me that’s less important than getting the
checks you implemented actually used, though.

> ### Notify interested people about patches
>
> This is something I've been thinking about more generally, supporting
> email subscriptions for things like a new version of a package being
> available, or the package failing to build on
> master/staging/core-updates.
>
> But specifically for patches, maybe there could be a way of subscribing
> so that you're emailed when a patch series upgrades a package you're
> subscribed to, or breaks a package you're subscribed to.
>
> This could help get more people involved in reviewing patches, by making
> it easier for the interested people to find out about patches they're
> interested in.

+1!

> ### Helping people who aren't committers review patches
>
> I don't know how much of this happens, but it might be something to
> better support?
>
> Better supporting it could mean documenting how to get things that have
> passed review merged in, like emailing a list of committers when a patch
> series is ready to merge.

Agreed.  Non-committers do review occasionally and I find it very useful.

> ### Making 

Re: building with JACK 2 by default?

[Ludovic Courtès]

Hi!

Ricardo Wurmus  skribis:

> What are your thoughts on this?

I’m clueless about JACK but I think it’s good to follow upstream
recommendations as well as yours :-), so I’d say go for JACK 2!

Ludo’.

Re: Thank you for participating in the Guix Day!

[Ludovic Courtès]

Hi!

zimoun  skribis:

> On Fri, 27 Nov 2020 at 11:57, Ludovic Courtès  wrote:
>
>> Despite being a first experience, the live event went very smoothly (for
>> me at least, with ungoogled-chromium), it was great to see faces during
>> the break :-), and the discussions were all exciting for me.  I agree
>> it’d be great to have a blog post summarizing the event while it’s
>> fresh, even if it’s concise because we were all busy listening and
>> chatting instead of taking notes.
>
> The blog post is coming…  Writing depends on the materials at hand; for
> now nothing.

Sorry for the delay (don’t hesitate to ping me on IRC when that
happens :-)).

> Could you send your Org file to guix-days? Because I only noted the
> items that interested me.  Well, I volunteer to add words because it is
> worth, IMHO.  Nothing is written on stone but from my point of view, it
> is good to specify where Guix is eager to go more or less and especially
> helpful for the future when looking back. :-)

Attached are my (and Maxim’s) Guix Days notes for the “road map”
session, FWIW.

I agree a blog post with a recap would be/have been nice.

> BTW, initially the idea was to publish in this very blog post the links
> of the talks on audio-video.gnu.org.  But, I am confused how to upload
> them and the GNU folks behind have not answered to my email.  Anyway, it
> is not a blocking and will be added later.

Do you know exactly where it’s blocking?  Did you try filing a “support
request” under ?

Alternatively, we could keep videos on our infrastructure, but we’ll
have to make sure to set up backups and mirrors.  Chris Baines is
looking into that for the web site so that could be part of that effort.

If someone’s willing to help on setting up a web site backup, let’s
talk!

> When preparing, we discussed per-topic sub-room but the implementation
> was vague.  Now, it is clearer, so definitively for the next one. :-)
>
> About not recording, it was a conscientious choice.  We discussed it and
> we agreed that not-recording seems more in the usual “unconference” Guix
> style; especially discussions are freer when the words are not saved for
> eternity and so take the floor should be less impressive.

Alright, makes sense to me; it’s a tradeoff and being able to have
informal off-the-record discussions is nice.  Another option would be to
have a mixture of off-the-record discussions (like the real-life
“hallway track”, coffee breaks, etc.) and recorded Q/panel
discussions.

Thanks,
Ludo’.

#+TITLE: The ways forward
#+STARTUP: hidestars

* tentative road map for 1.2.0

  [[https://lists.gnu.org/archive/html/guix-devel/2020-04/msg00400.html][Medium-term road map (Apr. 2020)]]

* What's Guix?

** dependable
** liberating
*** not just FSDG
*** also helps users master complexity
*** empower users
** hackable
*** no programming language barrier
*** no need for a PhD in category theory
** high quality
*** a curated package distribution
*** community rules and QA
*** requirements not found elsewhere: build from source, unbundle, reproducible builds, bootstrap

* the things that suck
** performance
*** `guix pull' ("Computing guix derivation")
*** substitute downloads
*** broken CI (see Mathieu's talk)
*** UI glitches
 guix shell at last!
 search by file name (Pierre)
*** creating union directories is slow
** easier ways to work on a channel
** package size
*** deal with locales (e.g., coreutils)
** year-old bugs :-)
* the corners we cut
** build system gexp
** daemon in Scheme
** source location maps for staged code
** shepherd on Fibers (?): socket activation, etc.
* the future
** GNU/Hurd (-> janneke)
** substitutes over P2P (-> Chris Webber)
** new package definitions: no labels in inputs fields
** POLA: `guix run', --with-pola-wrapper
** 'guix hack' to work on a package?
** transparent import of packages from third-party repos?
** modularized package collection?
*** easier to hack on them, no longer different from other channels
*** more scalable (build times)
** time travel tested, formalized?
** guix environment --fhs  (file hierarchy standard)
** guix pack --format .deb|.rpm|...
** adding the missing GNU packages to the GNU Guix collection
** scalable workflows, recruiting more contributors (-> Chris Baines)
** outreach: functional deployment for everyone, not just geeks!
*** doc, translated
*** polished UI
*** graphical installer ✓
*** graphical UI (Danny)
*** graphical system UI à la YunoHost
*** blogging, training!
** CPU and power efficiency

Re: Question about Guix on Novena - mainly U-Boot

[Denis 'GNUtoo' Carikli]

On Fri, 4 Dec 2020 19:49:37 +0100
Danny Milosavljevic  wrote:> 
> Now I want to make it boot it from SATA instead.
The question is what "boot from SATA" means here, it could mean
different things:
- Have u-boot on the microSD card and load the rootfs from the SATA
  HDD/SSD.
- Make the bootrom load u-boot from the SATA HDD/SSD.

Luckily the I.MX6 SOC is capable of loading u-boot from a SATA HDD/SSD
but it needs to be configured for that.

However it looks like the novena-eeprom utility only somehow does the
former:
https://github.com/xobs/novena-eeprom/blob/master/novena-eeprom.h

In addition I'm unsure if upstream u-boot can parse the sataroot flag
as I didn't find it but I only looked very rapidely and not on the
latest source code.

To configure the I.MX6 SOC to boot from a SATA HDD/SSD you'll have to
dig in the I.MX6Q reference manual and the schematics of the novena to
see how it is configured.

- You have fuses that select a boot mode
- One of the boot mode selected by the fuses configuration enables GPIO
  overrides (this is what we want here).

So with the reference manual and the schematics depending on the
fuses configurations, you could be able to understand the boot order of
the SOC (which peripherals it tries to load u-boot from and in which
order).

And if it's set in GPIO override mode and that the GPIOs are routed to
some switch or jumpers, you can probably manage to change the way it
boots and make sure it tries to load u-boot from the SATA HDD/SSD.

The u-boot source code also may have documentation about that. Some
boards (like the TBS2910) have some documentation on how they are
configured to boot. Since I didn't find the novena in doc/boards, you
might still have some luck if there is some more generic documentation
about booting devices with I.MX6Q.

If the Novena can't boot from SATA as-is, you could try to see if there
isn't a way through the configuration headers to configure the bootrom
to try to boot on SATA somehow. That configuration header (DCD) will
probably need to be on a peripheral that the bootrom tries to boot on.
Booting of I2C eeproms is possible on I.MX6 but again you'll have to
check the documentation to see if it satisfies all requirements
(including if the eeprom is wired to the proper I2C controller
and/or pads to be able to be read from the bootrom).

If not in the worst case you will probably need some minimal code on a
peripheral the bootrom tries to load code from.

There is probably some resources for the Novena (Forums, IRC channels
etc) that already have all theses answers but in any case understanding
a bit of the context here could help parse the answers.

Denis.


pgp6cEQsdtOka.pgp
Description: OpenPGP digital signature