Re: Guix scheme code being recompiled when target ARCH changes

[raingloom]

On Fri, 15 May 2020 10:33:14 +0200
Vincent Legoll  wrote:

> And as an additionnal question, are the ./pre-inst-envs needed on
> all the CLIs above ?

No, only the guix invocations need it.
make, ./configure, ./bootstrap, those don't need it.
But guix always does.

Re: “guix --help” should point to https://guix.gnu.org/help/

[Bengt Richter]

Hi zimoun, et al,

On +2020-05-15 13:00:58 +0200, zimoun wrote:
> Hi Ricardo,
> 
> On Fri, 15 May 2020 at 12:20, Ricardo Wurmus  wrote:
> 
> > annoyed by the fact that people turn to Reddit for help with Guix — a
> > venue only very few of us frequent — I wondered if our help channels are
> > visible enough.
> 
> Maybe it is "cultural" or/and "generational" thing and we cannot do
> really better. Maybe some people prefer channels as Reddit because
> they are a bit "afraid" by email and/or IRC, especially maybe on
> official channels.  Maybe because when someone has a problem, the
> first thing they does is a query to popular search engines and then

Habits are habits, but I don't think people specifically needing guix info
would go to popular search engines if they had an obvious better alternative.

I suspect people e.g. go to https://duckduckgo.com/ and type
"site:gnu.org some clues 2020" in the slot because it can be faster
that way to get a good selection of URLS to choose from.

I.e., faster than navigating from the top of http://www.gnu.org/gethelp/
(BTW wondering why the link is not
   https://www.gnu.org/software/gethelp.html
which works fine).

So, shame at having been outperformed in a search? Or an opportunity to extend 
the
cooperative FLOSS ethos, and maybe contact duckduckgo.com so as to help them
suceed well in helping us, and creating a mesh benefiting all?

Likewise with Arch and Debian and other wikis or forums that can have
useful search capability that it would be helpful for guix.gnu.org to point to.

You may say that users usually know about their own distros' help sites,
but sometimes it can help to know e.g. that a sibling debian descendant does
not have the problem you are experiencing.

> browse some Reddit-kind of channels, so maybe they feels like it is a
> good entry point.  Maybe some people appreciate the voting system
> (upvote, Discourse, etc.) to be "rewarded". Etc..
>

Good point, I definitely think some kind of rating system would help.
Especially if tied into the search data base so that you can easily
sift out information authored by people who typically post the
final authoritative and correct "fixes" with nice succinct rationale :)

> Well, I am not convinced it is an issue about visibility. :-(
>
Well, I am :)
At least visible things are easier to find when you need them.
Of course, in the dark, audible things may be easier to find,
which may be very important to some.

Of course, in a familiar room, touch may be sufficient to
keep your mental model of the room in sync with reality,
and to navigate through it. Touch is easy to overlook, but
really important, whether typing, reading braille,
playing an instrument, or just playing around :)

So an accessible site map, to build that mental model that
makes it a familiar room, is probably a good thing.

> 
> > “guix --help” prints this:
> >
> >   Report bugs to: bug-g...@gnu.org.
> >   GNU Guix home page: 
> >   General help using GNU software: 

Some people might not like to click on http[^s] and wonder why gnu
is not practicing what it preaches, or suspect that their isp is playing
surveillance middle man^H^H^Hperson^H^H^H^H^H^Hagent for some reason?

I'll repeat from above:
(BTW wondering why the link is not
   https://www.gnu.org/software/gethelp.html
which works fine).

> >
> > I think it should explicitly point to https://guix.gnu.org/help/, maybe
> > right before “General help using GNU software”.
>
+1 :)

Also, I think it would be nice if there were a link from 
https://guix.gnu.org/help/
to a search page with some category checkboxes and radio buttons, so that
you could get rapidly to the _kind_ of search you need or want. E.g.,

"[x] Troubleshooting" ought to be one check-box IMO, for me the most important 
:)
I think with that checked searches should lead to info re recent regressions
and "popular" troubleshooting topics, and notices of security issues and 
realease news.
NOT 2017 bikeshed threads or fixes for problems of long-gone generations :)
(unless of course they sadly are still dead-on relevant ;-/ )

Also, ISTM guix.gnu.org should not try to be the only source of information, 
but rather
help people to get to other GNU-friendly sources of info that may have extra 
relevant
info for their particular distribution and use case. Links for pursuing that 
would help.

Sometimes going to duckduckgo.com and typing "site:gnu.org what you want" in 
the slot
can get you useful urls faster than navigating down from 
https://guix.gnu.org/help/

I don't think there's any shame in suggesting that :)

 > Yes, it cost nothing and could improve.

I think that's way too unassertive :)

> 
> 
> All the best,
> simon
> 

-- 
Regards,
Bengt Richter

Kernel module configuration service

[Brice Waegeneire]

Hello Guix,

I'm working on the future 'kernel-module-configuration-service-type'[0]
(KMCS) and I need some guidance. This service will be a one stop shop 
for

all kernel module related configuration by doing the following 4 things:
1. Generate a config directory for modrope to use
2. Load loadable kernel module by extending 
'kernel-module-loader-service'

3. Configure built-in module by being a new source for
   'operating-system-kernel-arguments'
4. Add loadable kernel modules to the kernel profile by being a source 
for

   'operating-system-kernel-loadable-modules'

ATM I need help with point number 1 in regard to putting in place the
config directory for modprobe. To do so I need to change
'%modprobe-wrapper' into a procedure to take the configuration directory 
as
an argument, since the directory will now come from '/gnu/store/' 
instead

of '/etc/'. The problem is that the wrapper is currently put in place by
'%linux-bare-metal-service' which is an essential service, so it seems 
that
KMCS will have to become one too. Looking around at some essential 
service

most of them are straight forward and don't extend services like
'kernel-module-loader-service-type' (which itself extend
'shepherd-root-service-type').

What are the guidelines to add a service to the essential-services? Can
KMCS become an essential-service? Any other remarks/idea?

[0]: https://issues.guix.info/40274#18

Have a good day,
- Brice

Re: naming scheme for "compilers" toolsuite?

[Josh Marshall]

Bringing back this necrothread, what you are suggesting is something I
would find intuitive.  Sounds like a good idea to me.

On Thu, Apr 16, 2020, 22:12 zimoun  wrote:

> Dear,
>
> Giving a look to the Arun's patches [1] about improving "guix search",
> I am testing some queries. Well, I am not able to find what I want in
> the jungle of all the packages, independently of the implementation of
> "guix search".
>
>
> For example, what is the package which provides standard libraries and
> tools for Haskell? for OCaml?
>
>
> Does the package named "ghc-toolchain" or "haskell-toolchain" seem a good
> idea?
> Debian provides the package named "haskell-platform" which gives a
> nice batteries included Haskell experience.
>
> Note that Guix already provides "gcc-toolchain" or "clang-toolchain"
> or "gfortran-toolchain". Therefore, it seems consistent to provide
> something similar for Haskell and OCaml, say. Maybe more.
>
> Last, from the "guix search haskell" it is hard to know which packages
> to install and then to have an easy Haskell experience. The package
> "ghc" is the sixth on the list.
>
>
> What do you think?
>
> All the best,
> simon
>
> [1] https://issues.guix.gnu.org/issue/39258#68
>
>

Re: What to do when udpating a package ?

[zimoun]

On Fri, 15 May 2020 at 17:43, Edouard Klein  wrote:

> I could not find the link to the raw log, but having access to the
> "official" build status is a huge relief, as I can stop worrying that
> the build failure is my fault. This is exactly what I was looking for.
> Thank you !

I have cheated a bit because with this example, there is not raw -- I
do not know why.  But you get the principle. :-)


> >>   --> Is there a way to check the graph to make the edges as
> >>   sparse as possible (i.e. remove as many edges as possible without
> >>   changing the reachability) ? Would this be something we want ?
> >>   According to me it would because it would make the packages
> >>   definitions shorter and the computations on the graph faster, but I'm
> >>   not sure.
> >
> > What do you mean by "reachability"?
> > There is a new feature to "guix graph": '--path'.  You can find the
> > shortest path from one package to another, e.g.,
> >
> >   guix graph --path guix-jupyter python
> >
> > What do you mean by "the edges as sparse as possible"?
> >
> >
> So if A depends on B and C, and B also depends on C, which is preferable
> as far as explicit input declarations in the packages code go:
> --

(1)
> A->B;
> B->C;

(2)
> A->B;
> A->C;
> B->C;

If A depends on B *and* C, then (1) should not work.
Well, it depends on how A depends* on C and what C propagates.
If I understand correctly.

*build-time or runtime.


> The reachability (in the graph theoretical sense
> https://en.wikipedia.org/wiki/Reachability) is the same, but one graph
> has one edge less and is thus "minimal". If I understood Julien correctly he 
> seems to think
> that the fully connected case is better (easier maintainability).

Well, does "guix graph --path" cover your expectation about reachability?
Because "guix graph --path" computes the shortest path -- graph theory
meaning -- from s to t.  So if the path is not empty, then t is
reachable from s.


All the best,
simon

Re: “guix --help” should point to https://guix.gnu.org/help/

[Diego Nicola Barbato]

Hey,

zimoun  writes:

> Hi Ricardo,
>
> On Fri, 15 May 2020 at 12:20, Ricardo Wurmus  wrote:
>
>> annoyed by the fact that people turn to Reddit for help with Guix — a
>> venue only very few of us frequent — I wondered if our help channels are
>> visible enough.
>
> Maybe it is "cultural" or/and "generational" thing and we cannot do
> really better. Maybe some people prefer channels as Reddit because
> they are a bit "afraid" by email and/or IRC, especially maybe on
> official channels.  Maybe because when someone has a problem, the
> first thing they does is a query to popular search engines and then
> browse some Reddit-kind of channels, so maybe they feels like it is a
> good entry point.  Maybe some people appreciate the voting system
> (upvote, Discourse, etc.) to be "rewarded". Etc..
>
> Well, I am not convinced it is an issue about visibility. :-(

If the main issue is people turning to the subreddit for help, we could
also kindly ask the moderators to advertise the official help channels
in a sticky post.  After all some people might turn to Reddit before
even thinking of running `guix --help'.

[...]

Regards,

Diego

Re: What to do when udpating a package ?

[Julien Lepiller]

Le 15 mai 2020 11:32:31 GMT-04:00, Edouard Klein  a écrit 
:
>Hi Julien,
>
>Thank you for your answer.
>
>Julien Lepiller writes:
>
>> Le 15 mai 2020 03:20:06 GMT-04:00, Edouard Klein
> a écrit :
>>>Dear Guix Developers,
>>>
>>>I have a few beginner questions.
>>>Attached to this email you will find the "reverse-package" graph of
>>>python-prompt-toolkit.
>>
>> Hi,
>>
>> In general, some packages on master may fail to build. We try to fix
>these, but it's not always easy.
>>
>> When updating a package, you should make sure that its dependents all
>> build or did not build before your changes. Fix those who now fail to
>> build.
>
>OK, got it. I'll avoid touching those that fail to build on the build
>farm.
>
>>
>> I don't think having both versions is a good thing because it will
>create conflicts when installing (have you tried to install a package
>that propagates both to a profile?). It would be ok if they had no file
>in common but I doubt it is the case. For any package that requires
>version 2, make sure its dependencies only use version 2, or update the
>package if the newer version can support version 3. It's not always
>easy to find the right order of upgrades, as you should make sure
>nothing is broken in between patches.
>>
>I did not try to install them, and you were correct, here is what I get
>when I try to install python-iml:
>
>guix install: error: profile contains conflicting entries for
>python-prompt-toolkit
>guix install: error:   first entry: python-prompt-toolkit@3.0.5
>/gnu/store/80lzvbzvfp4226ic7czhch4p0mlsdwlv-python-prompt-toolkit-3.0.5
>guix install: error:... propagated from python-ipython@7.9.0
>guix install: error:... propagated from python-iml@0.6.2
>guix install: error:   second entry: python-prompt-toolkit@2.0.7
>/gnu/store/0k7a0yp3b2sqqj8jhl7vp3cabb0x2mwd-python-prompt-toolkit-2.0.7
>guix install: error:... propagated from python-iml@0.6.2
>hint: You cannot have two different versions or variants of
>`python-iml' in the same profile.
>
>The problem is that python-iml depends on both python-ipython (which
>accepts python-prompt-toolkit 3) and python-prompt-toolkit-2. Looking
>at
>the github repo, the last update was in 2018, I don't think we'll see
>an
>update soon.
>
>I could pin python-ipython to python-prompt-toolkit-2, but that would
>just delay the problem and put it on somebody else's lap to let
>python-ipython move to python-prompt-toolkit 3.
>
>As I was typing a question I ctrl-Fed for 'variants' in the doc and
>ended up learning about package-input-rewriting. I will try to make
>python-iml depend on python-ipython, but with the prompt-toolkit input
>replaced with its version 2 on the fly. I think it makes sense. Is it
>the correct
>way to do what needs to be done ?

Sounds like a plan. Anotger possiblity is to introduce a patch to have 
python-iml support the latest version and send it upstream too.

>
>> Relying on propagated inputs to provide a dependency is going to
>> simplify the graphs, but not the work of other maintainers who will
>> have to investigate how the dependency is provided, so I don't think
>> it's a good idea.
>
>I understood your sentence as saying that relying on propagated inputs
>of propagated inputs is not a good idea and that dependencies are
>better
>explicitly stated in the guix package. Is that correct ?

Yes, that's what I meant. If the package explicitely requires something, we 
should provide it in the recipe, even if that's superfluous. If it's not listed 
as a dependency, then it's not necessary. I don't think this is an established 
rule, but this is what makes more sense to me.

>
>>
>> You should rebuild every dependent, even those who only depend on the
>> package for native-inputs, since there can be an error an any point
>> (though less likely).
>
>OK, I'll try that next when I'll have gotten python-iml to build.
>
>>
>> I hope I answered your questions. Your message was split into two
>> multipart sections and my client wasn't able to cite the interesting
>> part, which makes it hard for me to check what your questions were
>> while typing my answer.
>
>You have indeed answered a lot of them, thank you very much :) Sorry
>about the multipart stuff, I don't know how to configure my client
>(mu4e) not to do that. I'll look into it.

Don't worry too much about it, it's only inconvenient when I'm on my phone :)

>
>Cheers,
>
>Edouard.

Re: What to do when udpating a package ?

[Edouard Klein]

zimoun writes:

> Dear Edouard,
>
> In complement to what Julien said. :-)
>
>
> On Fri, 15 May 2020 at 13:36, Edouard Klein  wrote:
>
>> - Some packages would not build, for reasons unrelated to the update of
>>   python-prompt-toolkit. Namely:
>>   - fdroidserver@1.1.1  will not build because of a failure of
>>   python-apache-libcloud@2.4.0
>>   - python-matplotlib-documentation@3.1.2 and
>>   python-ipython-documentation@7.9.0 will not build because of a failure
>>   of texlive-union-51265
>>   - python-rpy2@3.0.4-1.19868a8 would not build
>>   All those failure also happen on origin/master on my machine, and are
>>   therefore unrelated to the changes I made.
>>   --> Is any failure to build expected on origin/master ?
>
> No, it is not expected.
> As Forrest Gump says: "It happens, sometimes." :-)
>

I was worried I had misconfigured my local version of guix.

>
>>   --> If so, where can I check the official build success/fail status of
>>   a package ?
>
> Well, the link is ci.guix.gnu.org then top right, for example the query:
>
>spec:guix-master system:x86_64-linux python-apache-libcloud
>
> But personally I do not always understand what Cuirass reports.
> Therefore, I prefer to use data.guix.gnu.org then for example:
>
> http://data.guix.gnu.org/repository/1/branch/master/package/fdroidserver/output-history
>
> I do not know the correct way to reach this webpage so I type directly
> the URL -- well to be exact, I have an Emacs interactive function so I
> type M-x my/guix-data fdroidserver RET and it opens the above webpage.
>
> Then I click to one "Failed dependency" and I arrive to:
>
> http://data.guix.gnu.org/build-server/1/build?derivation_file_name=/gnu/store/ccrk10g4vpzf6nk7x8j1a36s0b4z0w2l-fdroidserver-1.1.1.drv
>
> and I can click to the failing derivation and then I arrive to
> ci.guix.gnu.org and I can give a look to the raw log.
>
I could not find the link to the raw log, but having access to the
"official" build status is a huge relief, as I can stop worrying that
the build failure is my fault. This is exactly what I was looking for.
Thank you !


>
> Well, I do not know if it is the correct way, but it is how I am doing
> time to time to see what happens on the build farm.  Be careful of
> your current Guix version and the Guix version on ci you are
> examining.
>
>
>>   --> If not, how can I check that my master version of guix is correct
>>and is building everything it should build ?
>
> I do not understand what you mean.
> "guix weather" to see if the substitute is available.
> "guix challenge" to compare your own builds to the builds on substitutes.
>
>

I was asking how to make sure that my local guix is OK (I had trouble
getting it to work).

>>   --> In any case, how can I check that my change does not negatively
>>affect these packages ?
>
> Which packages?  The ones which do not currently build?

Yeah, I'm worried maybe once the current build failure cause is addressed, my
change will prevent them from building.

>
>
>> - Some of the failing-in-master packages do not depend directly on
>>   python-prompt toolkit, but they depend on a package that depends on
>>   etc.
>>   e.g. fdroidserver@1.1.1 depends on python-androguard@3.2.1 which
>>   depends on python-ipython@7.9.0.
>>   --> fdroidserver@1.1.1 fails to build for reasons unrelated to
>>   python-prompt-toolkit, but both python-androguard@3.2.1 and
>>   python-ipython@7.9.0. both build with the new version of
>>   python-prompt-toolkit. Would I be correct in assuming that
>>   frdoidserver would build with the new version ? I assume not, but I
>>   would like to be sure
>
> I miss something about what depends on what. :-)
> I do not have really the graph under my eyes. ;-)
>
>
>> - python-iml@0.6.2 does not build with prompt-toolkit in version 3 (the
>>   version is explicitly stated as >=2.0 and <2.1 in the Python files), but
>>   when I add prompt-toolkit-2 to its propagated-inputs, it does.
>>   Given that python-ipython has prompt-toolkit (implicitly in version
>>   3) installed in its propagated inputs, this means that any environment
>>   with python-iml will have prompt-toolkit in both its version 2 and 3
>>   installed at the same time. I feel uneasy about this.
>>   --> Is this a problem ?
>>   --> Should I just trust that if it builds, then everything is
>>   allright ?
>
> No, it should pass the tests too.  If there is tests. :-)
> If not, you should install it locally and try it.

Yeah, installing does not work :D See my answer to Julien

> Because the package could build but should have runtime issues.
>
>
>>   --> Is there a way to check the graph to make the edges as
>>   sparse as possible (i.e. remove as many edges as possible without
>>   changing the reachability) ? Would this be something we want ?
>>   According to me it would because it would make the packages
>>   definitions shorter and the computations on the graph faster, but I'm
>>   not sure.

Re: Some packages failing to build

[Guillaume Le Vaillant]

Guillaume Le Vaillant  skribis:

> Guillaume Le Vaillant  skribis:
>
>> Vagrant Cascadian  skribis:
>>
>>> On 2020-05-10, Marius Bakke wrote:
 Guillaume Le Vaillant  writes:

> Guillaume Le Vaillant  skribis:
>
>> Hi,
>>
>> After pulling guix with the merged core updates (guix at commit
>> 95ffdfe86cb1b8a8e4fff1386a147718400b76e0), I found a few packages
>> failing to build:
>>
>>  - fbreader
>>  - gnubg
>>  - gnubik
>>  - postgis
>>  - python-cheetah
>>  - python-trezor
>>
>> I have not yet had the time to try and fix them, so I just list them
>> here in case someone wants to take a look at them.
>
> Update: postgis and python-cheetah fixed.

 fbreader, gnubg and gnubik fixed.
>>>
>>> Updating python-trezor to 0.12.0 fixed it; pushed to master.
>>
>> Hi, thanks for the fixes.
>>
>> I found a few other build failures:
>>
>>  - bitcoin-abc
>>  - bitcoin-core
>>  - bitcoin-unlimited
>>
>>
>> There is also the wsjtx package that builds fine but starting the
>> program fails with:
>>
>> --8<---cut here---start->8---
>> /home/guillaume/.guix-profile/bin/wsjtx: symbol lookup error:
>> /home/guillaume/.guix-profile/bin/wsjtx: undefined symbol: fmodf,
>> version GLIBCXX_3.4.3
>> --8<---cut here---end--->8---
>>
>> However, doing a "ldd $(guix build wsjtx)/bin/.wsjtx-real" shows that
>> the libm.so.6 library that contains the fmodf function is in the
>> dependencies. Do you have an idea what could cause the symbol lookup to
>> fail?
>
> I pushed a workaround for wsjtx as
> b79794a7630a04668d2769aee50ebc25e0d7c3d2. I'm not fully satisfied by
> it as I don't yet know why the libraries would get in the wrong order
> when linking the program. But well, at least it starts now.

Update: bitcoin-abc and bitcoin-unlimited updated/fixed.


signature.asc
Description: PGP signature

Re: What to do when udpating a package ?

[Edouard Klein]

Hi Julien,

Thank you for your answer.

Julien Lepiller writes:

> Le 15 mai 2020 03:20:06 GMT-04:00, Edouard Klein  a 
> écrit :
>>Dear Guix Developers,
>>
>>I have a few beginner questions.
>>Attached to this email you will find the "reverse-package" graph of
>>python-prompt-toolkit.
>
> Hi,
>
> In general, some packages on master may fail to build. We try to fix these, 
> but it's not always easy.
>
> When updating a package, you should make sure that its dependents all
> build or did not build before your changes. Fix those who now fail to
> build.

OK, got it. I'll avoid touching those that fail to build on the build farm.

>
> I don't think having both versions is a good thing because it will create 
> conflicts when installing (have you tried to install a package that 
> propagates both to a profile?). It would be ok if they had no file in common 
> but I doubt it is the case. For any package that requires version 2, make 
> sure its dependencies only use version 2, or update the package if the newer 
> version can support version 3. It's not always easy to find the right order 
> of upgrades, as you should make sure nothing is broken in between patches.
>
I did not try to install them, and you were correct, here is what I get
when I try to install python-iml:

guix install: error: profile contains conflicting entries for 
python-prompt-toolkit
guix install: error:   first entry: python-prompt-toolkit@3.0.5 
/gnu/store/80lzvbzvfp4226ic7czhch4p0mlsdwlv-python-prompt-toolkit-3.0.5
guix install: error:... propagated from python-ipython@7.9.0
guix install: error:... propagated from python-iml@0.6.2
guix install: error:   second entry: python-prompt-toolkit@2.0.7 
/gnu/store/0k7a0yp3b2sqqj8jhl7vp3cabb0x2mwd-python-prompt-toolkit-2.0.7
guix install: error:... propagated from python-iml@0.6.2
hint: You cannot have two different versions or variants of `python-iml' in the 
same profile.

The problem is that python-iml depends on both python-ipython (which
accepts python-prompt-toolkit 3) and python-prompt-toolkit-2. Looking at
the github repo, the last update was in 2018, I don't think we'll see an
update soon.

I could pin python-ipython to python-prompt-toolkit-2, but that would
just delay the problem and put it on somebody else's lap to let
python-ipython move to python-prompt-toolkit 3.

As I was typing a question I ctrl-Fed for 'variants' in the doc and
ended up learning about package-input-rewriting. I will try to make
python-iml depend on python-ipython, but with the prompt-toolkit input
replaced with its version 2 on the fly. I think it makes sense. Is it the 
correct
way to do what needs to be done ?

> Relying on propagated inputs to provide a dependency is going to
> simplify the graphs, but not the work of other maintainers who will
> have to investigate how the dependency is provided, so I don't think
> it's a good idea.

I understood your sentence as saying that relying on propagated inputs
of propagated inputs is not a good idea and that dependencies are better
explicitly stated in the guix package. Is that correct ?


>
> You should rebuild every dependent, even those who only depend on the
> package for native-inputs, since there can be an error an any point
> (though less likely).

OK, I'll try that next when I'll have gotten python-iml to build.

>
> I hope I answered your questions. Your message was split into two
> multipart sections and my client wasn't able to cite the interesting
> part, which makes it hard for me to check what your questions were
> while typing my answer.

You have indeed answered a lot of them, thank you very much :) Sorry
about the multipart stuff, I don't know how to configure my client
(mu4e) not to do that. I'll look into it.

Cheers,

Edouard.

Re: What to do when udpating a package ?

[zimoun]

Dear Edouard,

In complement to what Julien said. :-)


On Fri, 15 May 2020 at 13:36, Edouard Klein  wrote:

> - Some packages would not build, for reasons unrelated to the update of
>   python-prompt-toolkit. Namely:
>   - fdroidserver@1.1.1  will not build because of a failure of
>   python-apache-libcloud@2.4.0
>   - python-matplotlib-documentation@3.1.2 and
>   python-ipython-documentation@7.9.0 will not build because of a failure
>   of texlive-union-51265
>   - python-rpy2@3.0.4-1.19868a8 would not build
>   All those failure also happen on origin/master on my machine, and are
>   therefore unrelated to the changes I made.
>   --> Is any failure to build expected on origin/master ?

No, it is not expected.
As Forrest Gump says: "It happens, sometimes." :-)


>   --> If so, where can I check the official build success/fail status of
>   a package ?

Well, the link is ci.guix.gnu.org then top right, for example the query:

   spec:guix-master system:x86_64-linux python-apache-libcloud

But personally I do not always understand what Cuirass reports.
Therefore, I prefer to use data.guix.gnu.org then for example:

http://data.guix.gnu.org/repository/1/branch/master/package/fdroidserver/output-history

I do not know the correct way to reach this webpage so I type directly
the URL -- well to be exact, I have an Emacs interactive function so I
type M-x my/guix-data fdroidserver RET and it opens the above webpage.

Then I click to one "Failed dependency" and I arrive to:

http://data.guix.gnu.org/build-server/1/build?derivation_file_name=/gnu/store/ccrk10g4vpzf6nk7x8j1a36s0b4z0w2l-fdroidserver-1.1.1.drv

and I can click to the failing derivation and then I arrive to
ci.guix.gnu.org and I can give a look to the raw log.


Well, I do not know if it is the correct way, but it is how I am doing
time to time to see what happens on the build farm.  Be careful of
your current Guix version and the Guix version on ci you are
examining.


>   --> If not, how can I check that my master version of guix is correct
>and is building everything it should build ?

I do not understand what you mean.
"guix weather" to see if the substitute is available.
"guix challenge" to compare your own builds to the builds on substitutes.


>   --> In any case, how can I check that my change does not negatively
>affect these packages ?

Which packages?  The ones which do not currently build?


> - Some of the failing-in-master packages do not depend directly on
>   python-prompt toolkit, but they depend on a package that depends on
>   etc.
>   e.g. fdroidserver@1.1.1 depends on python-androguard@3.2.1 which
>   depends on python-ipython@7.9.0.
>   --> fdroidserver@1.1.1 fails to build for reasons unrelated to
>   python-prompt-toolkit, but both python-androguard@3.2.1 and
>   python-ipython@7.9.0. both build with the new version of
>   python-prompt-toolkit. Would I be correct in assuming that
>   frdoidserver would build with the new version ? I assume not, but I
>   would like to be sure

I miss something about what depends on what. :-)
I do not have really the graph under my eyes. ;-)


> - python-iml@0.6.2 does not build with prompt-toolkit in version 3 (the
>   version is explicitly stated as >=2.0 and <2.1 in the Python files), but
>   when I add prompt-toolkit-2 to its propagated-inputs, it does.
>   Given that python-ipython has prompt-toolkit (implicitly in version
>   3) installed in its propagated inputs, this means that any environment
>   with python-iml will have prompt-toolkit in both its version 2 and 3
>   installed at the same time. I feel uneasy about this.
>   --> Is this a problem ?
>   --> Should I just trust that if it builds, then everything is
>   allright ?

No, it should pass the tests too.  If there is tests. :-)
If not, you should install it locally and try it.
Because the package could build but should have runtime issues.


>   --> Is there a way to check the graph to make the edges as
>   sparse as possible (i.e. remove as many edges as possible without
>   changing the reachability) ? Would this be something we want ?
>   According to me it would because it would make the packages
>   definitions shorter and the computations on the graph faster, but I'm
>   not sure.

What do you mean by "reachability"?
There is a new feature to "guix graph": '--path'.  You can find the
shortest path from one package to another, e.g.,

  guix graph --path guix-jupyter python

What do you mean by "the edges as sparse as possible"?



All the best,
simon

Re: Guix Christmas

[Josh Marshall]

I hope to get where you are before too long!

On Fri, May 15, 2020, 08:03 Ben Sturmfels  wrote:

> Hi Folks,
>
> Between the continuous improvements in speed, the high availability of
> substitutes, the arrival of PostGIS, QGIS and Geary and now Gnome 3.34,
> Python 3.8 and IceDove... it feels to me like Guix Christmas!
>
> Guix System has been my primary OS for a year or two now, but in the
> last few months it really has become the only system I need.
>
> Thanks again! I really appreciate the enormous amount of time and effort
> that goes into this project. :)
>
> Regards,
> Ben
>
>

Re: What to do when udpating a package ?

[Julien Lepiller]

Le 15 mai 2020 03:20:06 GMT-04:00, Edouard Klein  a écrit 
:
>Dear Guix Developers,
>
>I have a few beginner questions.
>Attached to this email you will find the "reverse-package" graph of
>python-prompt-toolkit.

Hi,

In general, some packages on master may fail to build. We try to fix these, but 
it's not always easy.

When updating a package, you should make sure that its dependents all build or 
did not build before your changes. Fix those who now fail to build.

I don't think having both versions is a good thing because it will create 
conflicts when installing (have you tried to install a package that propagates 
both to a profile?). It would be ok if they had no file in common but I doubt 
it is the case. For any package that requires version 2, make sure its 
dependencies only use version 2, or update the package if the newer version can 
support version 3. It's not always easy to find the right order of upgrades, as 
you should make sure nothing is broken in between patches.

Relying on propagated inputs to provide a dependency is going to simplify the 
graphs, but not the work of other maintainers who will have to investigate how 
the dependency is provided, so I don't think it's a good idea.

You should rebuild every dependent, even those who only depend on the package 
for native-inputs, since there can be an error an any point (though less 
likely).

I hope I answered your questions. Your message was split into two multipart 
sections and my client wasn't able to cite the interesting part, which makes it 
hard for me to check what your questions were while typing my answer.

Guix Christmas

[Ben Sturmfels]

Hi Folks,

Between the continuous improvements in speed, the high availability of
substitutes, the arrival of PostGIS, QGIS and Geary and now Gnome 3.34,
Python 3.8 and IceDove... it feels to me like Guix Christmas!

Guix System has been my primary OS for a year or two now, but in the
last few months it really has become the only system I need.

Thanks again! I really appreciate the enormous amount of time and effort
that goes into this project. :)

Regards,
Ben

What to do when udpating a package ?

[Edouard Klein]

Dear Guix Developers,

I have a few beginner questions.
Attached to this email you will find the "reverse-package" graph of
python-prompt-toolkit.


reverse.pdf
Description: Adobe PDF document

I am updating it from version 2.0.7 to version 3.0.5 because
python-questionary (which I'm trying to add to guix) depends on version 3.

After writing the new package definition for version 3.0.5, I tried
building the packages listed by
./pre-inst-env guix refresh --list-dependent python-prompt-toolkit
which if I understand correctly are the leafs of the attached DAG.

This is where I ran into different problems. Here are the questions I
have:

- Some packages would not build, for reasons unrelated to the update of
  python-prompt-toolkit. Namely:
  - fdroidserver@1.1.1  will not build because of a failure of
  python-apache-libcloud@2.4.0
  - python-matplotlib-documentation@3.1.2 and
  python-ipython-documentation@7.9.0 will not build because of a failure
  of texlive-union-51265
  - python-rpy2@3.0.4-1.19868a8 would not build
  All those failure also happen on origin/master on my machine, and are
  therefore unrelated to the changes I made.
  --> Is any failure to build expected on origin/master ?
  --> If so, where can I check the official build success/fail status of
  a package ?
  --> If not, how can I check that my master version of guix is correct
   and is building everything it should build ?
  --> In any case, how can I check that my change does not negatively
   affect these packages ?

- Some of the failing-in-master packages do not depend directly on
  python-prompt toolkit, but they depend on a package that depends on
  etc.
  e.g. fdroidserver@1.1.1 depends on python-androguard@3.2.1 which
  depends on python-ipython@7.9.0.
  --> fdroidserver@1.1.1 fails to build for reasons unrelated to
  python-prompt-toolkit, but both python-androguard@3.2.1 and
  python-ipython@7.9.0. both build with the new version of
  python-prompt-toolkit. Would I be correct in assuming that
  frdoidserver would build with the new version ? I assume not, but I
  would like to be sure

- python-iml@0.6.2 does not build with prompt-toolkit in version 3 (the
  version is explicitly stated as >=2.0 and <2.1 in the Python files), but
  when I add prompt-toolkit-2 to its propagated-inputs, it does.
  Given that python-ipython has prompt-toolkit (implicitly in version
  3) installed in its propagated inputs, this means that any environment
  with python-iml will have prompt-toolkit in both its version 2 and 3
  installed at the same time. I feel uneasy about this.
  --> Is this a problem ?
  --> Should I just trust that if it builds, then everything is
  allright ?

- Same question on a larger scale with r-irkernel@1.1:
  - it depends on python-jupyter-console (failing) which depends on
  python-prompt-toolkit.
  If I pin python-jupyter-console's dependency on python-prompt-toolkit
  to version 2, python-jupyter-console builds.
  The next dependency to fail is then python-widgetsnbextension@3.4.2,
  whose Python files explicitly requires 2.0 <= python-prompt-toolkit <2.1,
  but whose guix package does not (it relies on python-prompt-toolkit
  being a propagated input of a propagated input of a propagated etc.).
  Same for python-ipywidgets@5.2.2.
  Those packages build when I explicitly add python-prompt-toolkit-2 as a
  propagated input.
  Now I feel uneasy about two things:
  --> Is the concurrent presence in the environment of
  python-prompt-toolkit both in version 2 and 3 a problem ?
  --> Is the fact that the graph is now much more connected (2 extra
  edges) a problem ?
  --> Is there a way to check the graph to make the edges as
  sparse as possible (i.e. remove as many edges as possible without
  changing the reachability) ? Would this be something we want ?
  According to me it would because it would make the packages
  definitions shorter and the computations on the graph faster, but I'm
  not sure.
  
I'm sorry if this is addressed in the documentation, I did not find the
relevant parts.

guix graph is awesome, it makes working with the dependencies much more
intuitive. This email is a mess to anyone not looking at the graph at
the same time, but I hope is quite understandable to somebody following
along on the graph at the same time.

Last question:
--> Should I also check the build status of the packages for which
python-prompt-toolkit or its dependents are native-inputs ? Why, why not
?

Thanks in advance,

Cheers,

Edouard

Re: “guix --help” should point to https://guix.gnu.org/help/

[zimoun]

Hi Ricardo,

On Fri, 15 May 2020 at 12:20, Ricardo Wurmus  wrote:

> annoyed by the fact that people turn to Reddit for help with Guix — a
> venue only very few of us frequent — I wondered if our help channels are
> visible enough.

Maybe it is "cultural" or/and "generational" thing and we cannot do
really better. Maybe some people prefer channels as Reddit because
they are a bit "afraid" by email and/or IRC, especially maybe on
official channels.  Maybe because when someone has a problem, the
first thing they does is a query to popular search engines and then
browse some Reddit-kind of channels, so maybe they feels like it is a
good entry point.  Maybe some people appreciate the voting system
(upvote, Discourse, etc.) to be "rewarded". Etc..

Well, I am not convinced it is an issue about visibility. :-(


> “guix --help” prints this:
>
>   Report bugs to: bug-g...@gnu.org.
>   GNU Guix home page: 
>   General help using GNU software: 
>
> I think it should explicitly point to https://guix.gnu.org/help/, maybe
> right before “General help using GNU software”.

Yes, it cost nothing and could improve.


All the best,
simon

“guix --help” should point to https://guix.gnu.org/help/

[Ricardo Wurmus]

Hi Guix,

annoyed by the fact that people turn to Reddit for help with Guix — a
venue only very few of us frequent — I wondered if our help channels are
visible enough.

“guix --help” prints this:

  Report bugs to: bug-g...@gnu.org.
  GNU Guix home page: 
  General help using GNU software: 

I think it should explicitly point to https://guix.gnu.org/help/, maybe
right before “General help using GNU software”.

What do you think?

-- 
Ricardo

Guix scheme code being recompiled when target ARCH changes

[Vincent Legoll]

Hello,

I'm wondering if the following is expected:

I'm build the guix binary tarball for i686 & x86_64 (without changing
any scheme code) and the whole guix codebase gets recompiled for each
of the builds.

I'm doing this:

  ./pre-inst-env make update-guix-package
  git add gnu/packages/package-management.scm
  git commit -m NOT_FOR_UPSTREAM \
gnu/packages/package-management.scm

  SYSTEM=x86_64-linux
  ./pre-inst-env guix build -s "${SYSTEM}" guix
  ./pre-inst-env guix pack -s "${SYSTEM}" --localstatedir \
--profile-name=current-guix guix

  SYSTEM=i686-linux
  ./pre-inst-env guix build -s "${SYSTEM}" guix
  ./pre-inst-env guix pack -s "${SYSTEM}" --localstatedir \
--profile-name=current-guix guix

I intended to run the:

  ./pre-inst-env make "guix-binary.${SYSTEM}.tar.xz"

afterwards.

Are the .scm files recompilations needed ?
What for ?

And as an additionnal question, are the ./pre-inst-envs needed on
all the CLIs above ?

I still have a TODO to put everything I gathered about building the
binary tarballs in the doc.

I also still cannot test on foreign arches, see:
https://lists.gnu.org/archive/html/guix-devel/2020-05/msg00213.html

Thanks

--
Vincent Legoll