Re: [core-updates] Setting SSL_CERT_FILE in the build environment

[Ricardo Wurmus]

Zheng Junjie  writes:

> Ricardo Wurmus  writes:
>
>> Zheng Junjie  writes:
>>
>>> This patch should fix it.
>>
>> Thank you for the patch!
>>
>>> From f41bf905cfb1395a53cfc0d79315148ac9ba0a79 Mon Sep 17 00:00:00 2001
>>> Message-ID: 
>>> 
>>> From: Zheng Junjie 
>>> Date: Tue, 16 Jul 2024 00:06:39 +0800
>>> Subject: [PATCH] gnu: python-requests-next: Fix build.
>>>
>>> * gnu/packages/python-web.scm (python-requests-next): Fix build.
>>> [native-inputs]: Add nss-certs.
>>> [arguments]: Add set-SSL_CERT_FILE phase.
>>> <#:modules>: Adjust it.
>>
>> This seems rather complicated for something that may have to be added to
>> a number of packages.  Would it make sense to create a package
>> containing this bundle file, set a search path specification, and add
>> that to the packages needing it?
>
> Indeed, please try these patches
>
> From 0ad24103d82147eece6bd546fc31a9f81e2d17fd Mon Sep 17 00:00:00 2001
> Message-ID: 
> <0ad24103d82147eece6bd546fc31a9f81e2d17fd.1721063765.git.zhengjun...@iscas.ac.cn>
> From: Zheng Junjie 
> Date: Tue, 16 Jul 2024 01:13:35 +0800
> Subject: [PATCH 1/2] gnu: Add nss-certs-for-test.
>
> * gnu/packages/certs.scm (nss-certs-for-test): New variable.
[...]
> From 5417197e22dd7efa6732ea8de188f2f94bfc3ccc Mon Sep 17 00:00:00 2001
> Message-ID: 
> <5417197e22dd7efa6732ea8de188f2f94bfc3ccc.1721063765.git.zhengjun...@iscas.ac.cn>
> In-Reply-To: 
> <0ad24103d82147eece6bd546fc31a9f81e2d17fd.1721063765.git.zhengjun...@iscas.ac.cn>
> References: 
> <0ad24103d82147eece6bd546fc31a9f81e2d17fd.1721063765.git.zhengjun...@iscas.ac.cn>
> From: Zheng Junjie 
> Date: Tue, 16 Jul 2024 00:06:39 +0800
> Subject: [PATCH 2/2] gnu: python-requests-next: Fix build.
>
> * gnu/packages/python-web.scm (python-requests-next): Fix build.
> [native-inputs]: Add nss-certs-for-test.

I have applied them.  Thank you!

-- 
Ricardo

Re: Should we document how to detect if build machines are reachable before trying to offload?

[Simon Tournier]

Hi Ludo,

On Sun, 21 Jul 2024 at 14:56, Ludovic Courtès  wrote:

> I guess this is probably what we should permit: building locally when we
> cannot offload.
>
> Does that make sense?

Yes! This feature seems wanted. ;-)

Aside it would satisfy requests [1,2] randomly picked up :-) it would
help in closing this old report, I guess.

bug#24496: offloading should fall back to local build after n tries
ng0 
Wed, 21 Sep 2016 09:39:48 +
id:8760ppr3q3@we.make.ritual.n0.is
https://issues.guix.gnu.org/24496
https://issues.guix.gnu.org/msgid/8760ppr3q3@we.make.ritual.n0.is
https://yhetil.org/guix/8760ppr3q3@we.make.ritual.n0.is

Cheers,
simon

1: How to offload builds only when some of the offload build servers are 
available
Kyle Andrews 
Sun, 01 May 2022 16:01:21 +
id:875ympmdqw@posteo.net
https://lists.gnu.org/archive/html/help-guix/2022-05
https://yhetil.org/guix/875ympmdqw@posteo.net

2: guix offload
Aleksandr Vityazev 
Wed, 20 Dec 2023 14:02:27 +0300
id:87o7el9lx8@gmail.com
https://lists.gnu.org/archive/html/help-guix/2023-12
https://yhetil.org/guix/87o7el9lx8@gmail.com

Re: Question about changing versioning for TeX Live packages

[Simon Tournier]

Hi,

On Fri, 19 Jul 2024 at 18:38, Nicolas Goaziou via "Development of GNU Guix and 
the GNU System distribution."  wrote:

> I'm only changing the `version' field. For the record, "core-updates"
> currently contains all TeX Live packages with their version switched to
> "2024.2".

Cool!  Nice it’s updated. :-)


>   In the worst case, maybe a notice in the guix news will be
> sufficient.

Hum, I am not convinced “guix news” would be enough.  Maybe we could
provide something that display a warning when upgrading a profile.

Cheers,
simon

Re: Reducing "You found a bug" reports

[Simon Tournier]

Hi,

On Sun, 21 Jul 2024 at 15:16, Ludovic Courtès  wrote:

>>> I’m fine removing the “report a bug” message, maybe replacing it with
>>> some clearer diagnostic and suggestion?  WDYT?
>>
>> Could we detect if it comes from networking?  Somehow catch the error
>> and run some code that checks stuff and so report more “accurate”
>> messages?
>
> Someone™ would need to analyze some of the reports we have (some of them
> have already been commented on) to determine what happened and whether
> that is something we could diagnose differently.

Over the years, I have spent some time in answering to some of these bug
reports; see [1] for one instance of an attempt to be this Someone™ ;-).

More than often, the issue is transient, hard if not impossible to
reproduce and thus hard to analyze.  Even, when it happens for me,
sometimes I say ok let try to collect some information for helping in
debugging that but then just running again “guix pull” makes it pass.

Excluding the bug between the keyboard and the chair, most of the time
it seems coming from either user’s network, or either substitute
servers.  Most of the time the bang is transient.

Bah I do not know exactly what or how – otherwise I would have proposed
a patch or something ;-) – but I think we need to “instrument“ the
command “guix pull” in order to collect a trace for then diagnosing.

Somehow, maybe it could be a good application of Maxim’s proposal for
logging [2].

Well, instead of an “useless” backtrace, it would be more helpful to
have a kind of log or coredump; maybe something under /var/log/guix/.

I think the next step is not « Someone™ would need to analyze some of
the reports » because the reports often provide only the same “useless“
backtrace, so instead the next step seems: « Someone™ would need to
implement a better way for generating good reports ». ;-)

Cheers,
simon

1: collection of “guix pull“ bug reports
Simon Tournier 
Wed, 23 Aug 2023 18:17:20 +0200
id:86jztl20of@gmail.com
https://lists.gnu.org/archive/html/guix-devel/2023-08
https://yhetil.org/guix/86jztl20of@gmail.com

2: [bug#68946] [RFC PATCH 0/1] Add logging capability to Guix
Maxim Cournoyer 
Mon, 05 Feb 2024 23:12:00 -0500
id:cover.1707192720.git.maxim.courno...@gmail.com
https://issues.guix.gnu.org/68946
https://issues.guix.gnu.org/msgid/cover.1707192720.git.maxim.courno...@gmail.com
https://yhetil.org/guix/cover.1707192720.git.maxim.courno...@gmail.com

Re: Reducing "You found a bug" reports

[Suhail Singh]

Simon Tournier  writes:

> More than often, the issue is transient, hard if not impossible to
> reproduce and thus hard to analyze.  Even, when it happens for me,
> sometimes I say ok let try to collect some information for helping in
> debugging that but then just running again “guix pull” makes it pass.

Doesn't that suggest, that it may help to reword the below:

#+caption: 
#+begin_quote
  guix pull: error: You found a bug: the program 
'/gnu/store/mpfp9nrzifhp3r5s3bv05b8xal5aa44f-compute-guix-derivation'
  failed to compute the derivation for Guix (version: 
"e32cc011bbe899fda432906776702f74fa6b1450"; system: "x86_64-linux";
  host version: "eb34ff16cc9038880e87e1a58a93331fca37ad92"; pull-version: 1).
  Please report the COMPLETE output above by email to .
#+end_quote

So that we encourage users to try a few times (perhaps possibly with
--fallback), and in case of repeat failures to then submit a bug report
to .  What about something like:

#+begin_example
  guix pull: error: An error occurred: the program 
'/gnu/store/mpfp9nrzifhp3r5s3bv05b8xal5aa44f-compute-guix-derivation'
  failed to compute the derivation for Guix (version: 
"e32cc011bbe899fda432906776702f74fa6b1450"; system: "x86_64-linux";
  host version: "eb34ff16cc9038880e87e1a58a93331fca37ad92"; pull-version: 1).

  Please try running "guix pull" again.  In case of repeated failure,
  please try passing "--fallback" to "guix pull".  In case that still
  doesn't resolve the error, please report the COMPLETE output above by
  email to .
#+end_example

I.e., perhaps the first step is simply to reword above so that we don't
recommend that users submit a bug report on their first (possibly
transient) failure.

-- 
Suhail

Re: Reducing "You found a bug" reports

[Attila Lendvai]

> Just a quick side note that some members in our community (not I) are
> offended by the word "bug" to describe software defects.


welcome to the internet of billions of people, where the cost of expressing 
one's offence doesn't cost anything anymore, and there are dozens of offended 
people even for the most innocent of statements.

and with the advent of LLMs, it can soon become a kind of a security hole for 
intellectual DoS attacks -- if not already.

not sure how to keep the SNR high, but the communities will need to adapt.

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Knowledge will forever govern ignorance: And a people who mean to be their own 
Governors, must arm themselves with the power which knowledge gives.”
— James Madison (1751–1836), 'Epilogue: Securing the Republic' (1822)

Indication of build failure from substitute servers?

[Jonathan Frederickson]

Hi folks - I had a thought I wanted to bring up to you all.

I frequently end up with Guix attempting to build packages on my lower-powered 
machines when there are no substitutes available. However, a common reason that 
substitutes aren't available for a package is that the package failed to build 
in CI! And I usually discover this when the package fails to build locally, 
usually for the same reason, and usually after a relatively long build process.

Would it make sense to have some mechanism for substitute servers to be able to 
provide a sort of "non-existence proof" for a given package? Something that the 
CI system could publish to indicate that its build attempt for that package 
failed, and that clients could use to optionally abort without attempting a 
local build?

My reasoning for this is that, especially on some of my smaller ARM systems, a 
build attempt for some of these larger packages can take several hours, and if 
it's likely to fail I'd really prefer to know that ahead of time.