Re: Failed to build in QA

[reza.housse...@gmail.com]

On October 5, 2023 10:49:06 AM GMT+02:00, Christopher Baines  
wrote:
>
>"reza.housse...@gmail.com"  writes:
>
>> I submitted an issue to guix. But QA refuses to build it [1]. I have
>> no clue what the problem is, can anyone shed light on a possible
>> resolution?
>
>You pretty much found the problem, the relevant line on the page you
>linked to is:
>
>[  6/ 50] loading...24.0% of 25 filesbuilder for 
>`/gnu/store/qhvpjfn3d9cwz5zxadblbnbqa92a8i27-guix-cli-core.drv' failed due to 
>signal 11 (Segmentation fault)
>
>So the data service wasn't able to build Guix. This probably isn't due
>to your changes, and it doesn't happen very often, so the thing to do
>here is just retry.
>
>I've triggered QA to reapply the patches now (by deleting the
>issue-66262 branch), so hopefully things will work better this time.
>
>Thanks,
>
>Chris

Thanks very much, it seems to have worked, but now it's stuck with paraview 
undefined symbol, although the necessary module (gnu/packages/image-processing) 
is imported?
-- Sent from /e/ Mail.

Re: GUI for Guix

[Suhail Singh]

Ludovic Courtès  writes:

> The only thing broken for me is completion in shell-mode

FWIW, as an alternative, emacs-bash-completion
() works quite well
for completion in shell-mode. I unintern pcomplete/guix and use it in
its stead.

-- 
Suhail

Re: [RFC]: Skipping rust crate tests by default

[Nathan Dehnel]

As a developer, the majority of the package build failures I encounter
are from failed tests, so I agree with this proposal.

I also like the idea of clients testing their own packages instead of
trusting the substitute server.

And if the new tests would catch more packaging bugs, that would be great too.

Re: New section to easily reference Debbugs URLs within Emacs Debbugs

[Maxim Cournoyer]

Hi,

Mekeor Melire  writes:

> Thanks, Maxim, for implementing some of my suggestions in commit
> 06dc36ffb7cde821a4762b299d1c95b3788ba110, as I coincidentally found
> out when reading the commit log.
>
> By the way, I still believe it's less off-putting for average people
> to see two lines of regular expressions instead of 28 lines of
> symbolic expressions.
>
> I'd now like to make another suggestion, appended as patch, that
> allows for URLs like https://issues.guix.gnu.org/12345 to be opened in
> debbugs-mode within Emacs.

I think you meant "https://issues.guix.gnu.org/issue/12345; instead,
right? Otherwise, it already works that way.  This was brought up by
Simon.  I had argued that we should perhaps just not use that variant of
/issue/ in the URL, but maybe there's a good reason to have it?

Anyway, I won't loose sleep on it.  Applied :-).

-- 
Thanks,
Maxim

Re: [RFC]: Skipping rust crate tests by default

[Development of GNU Guix and the GNU System distribution.]

Hi Ephraim,

On Thu, Oct 05 2023, Efraim Flashner wrote:

> I propose changing the cargo-build-system to have '#:tests? #f' by
> default

At first sight, it appears improper to turn off tests because they
fail. Please allow me to remind everyone that build-time tests cover
only a small proportion of problems actually encountered by users.

Most packaging errors, like improper permissions or the installation of
components in a wrong path, usually go undetected.

One of Debian's solutions to that realization is autopkgtest [1] which
allows maintainers to specify a test bed that tests the *installed*
versions and not the versions in the build trees.

A common strategy for Debian maintainers is to convert the build-time
tests to an autopkgtest suite. That way, folks get the benefit of both.

Unfortunately, the setup of test beds is complicated in Debian, as the
installation of the packages being tested has to take place in
containers. In Guix, package installations are decoupled from the
running system. Guix would make that process a lot easier, faster and
more reliable!

In summary, I believe that #:test? should be turned off for all build
systems. Guix should instead test installed versions like Debian's
autopkgtest.

It would be an extra burden on contributors because such a
'test-installed phase would require more attention. It may be
worthwhile, however, because than packages could be built without
testing them---as Ephraim would like to do here.

In addition, pre-built substitutes could be tested by consumers on their
own systems. The substitutes could even be tested before they become
part of any Guix profile.

For Debian's QA tool Lintian, which I maintained for several years, the
speed-up in the development process was remarkable. As a Perl script,
the build toook seven minutes, while the build-time tests took seven
hours.

The builds were initiated with each commit in Salsa (in an online runner
sponsored by a large company).

Lintian was extreme because thousands of tests replicated much of what
happens daily in Debian. The extreme duration of build-time the tests
also took up further resources in downstream distributions. The tests
ran for each backport and for each derivative, such as Ubuntu.

For Guix, which relies on frequent rebuilds, the speed benefit could be
remarkable. Substitutes could become available for testing in perhaps
half the time.

That being said, old habits die hard. The attachment to build-time tests
is formidable. The people who maintained Lintian after me enabled them
again.

Kind regards
Felix

[1] 
https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/doc/README.package-tests.rst

Upgrading Guix's security team

[John Kehayias]

Hi Guixers!

In light of the several high profile CVEs this month, which were/are being 
handled and more coming (curl joins the chat) some of us were discussing 
improving and systematizing our security team and responses. My thanks to 
Tobias for quick review to help finalize the XOrg CVE grafts, to Liliana for 
the pending glibc fix (see ) and updating 
curl in preparation for a critical CVE update, and Ludo for getting this 
discussion started.

Here are some quick thoughts/ideas that came up for comment:

- current security email/people can be found here, which is nicely visible 
 yet probably in need of a hand and new 
faces for an important but often thankless job; no fault to them or Guix as a 
whole, merely a good time to see how we can keep improving

- currently we are not on the OS security distribution contact list: 
; this had been 
discussed before but we will need commitment from people

- clear roles will be helpful; to me this includes at least a couple of people 
to coordinate (the majority of security issues will be handled through package 
upgrades/grafts) and people to help review and/or contact needed experts, like 
for Guix internal issues; we should make this more precise

- likewise, a clear fixed timeframe for who is on this team; keeping people 
fresh and engaged for what can suddenly be a time sensitive and critical job; I 
think this will also help spread institutional knowledge for better security 
practices in general

- members need not be experts but should be active in the community as 
committers (already a round of vetting), familiar with what issues and 
processes may arise, and willing to learn; perhaps we need a list of experts to 
consult though the current teams are a good starting point

- what are your thoughts? what are the goals and outcomes we as a distro want 
in security?

- finally, I think an internal discussion with maintainers and long time active 
committers would be helpful to get the improvements started and moving, in 
addition to this wider discussion here

And to get things started, I'm happy to volunteer myself to help coordinate on 
security, if deemed okay by our current security team, maintainers, and anyone 
else that's been helping to handle security. A coordinating role with a term of 
say 6 months to a year? Happy to provide more information and discuss here or 
privately; in short I'm not a security expert but have time and bandwidth to 
keep things moving and want to learn.

Thanks everyone, and here's to hoping the spooky season is full of fun and 
candy and less CVEs!

John Kehayias

[RFC]: Skipping rust crate tests by default

[Efraim Flashner]

Currently for for rust crates we build the crates, run the tests, and
then in %output we only have the license files and a repackaged version
of the source.

The build system goes:
unpack source
unpack crates
patch shebangs
patch checksums of the crates
'build
'package
'check
'install

'install is clear, it does whatever the install command is.

'package repacks the source crate, after we've done any changes to it in
the snippet and later if we've gone and patched paths to binaries or
libraries. In theory this is useful with using these crates in a
GUIX_ENVIRONMENT

'check runs the test suite, which fairly often seems to need some
massaging to skip the odd test which fails or to try to skip the doc
tests, which fail far too often.

'build sounds like it just builds the package. The first thing it does
it makes sure that all the necessary crates are included in the build
environment.

IMO the 'build phase is the most important one, it's the one that lets
us know if all the cargo-inputs and cargo-development-inputs are
correct. We don't care if rust-rand-0.6 or rust-nb-connect-1 builds, we
only care that it has the correct inputs so that when we pull it in for
an actual binary or library everything builds correctly.

I propose changing the cargo-build-system to have '#:tests? #f' by
default and then enable them for packages which have a "clear output".
It will keep the benefits of knowing we have the correct inputs without
worrying about test errors we don't care about. If it fails to build
during its own 'build phase that's actually worth looking into. It will
also cut down the amount of time the CI spends building unneeded rust
crates, and lets us see which ones are actually broken.


-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: [bug#66343] Add more setups to Guix docs

[Ekaitz Zarraga]

Thank you all for the collaboration!

Re: [bug#66343] Add more setups to Guix docs

[Efraim Flashner]

On Wed, Oct 04, 2023 at 08:55:32PM +, Ekaitz Zarraga wrote:
> 
> It looks good to me.
> 
> Commit?

Looks good to me too. Patch pushed!

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: Failed to build in QA

[Development of GNU Guix and the GNU System distribution.]

On 2023-10-05 at 09:49+01:00, Christopher Baines wrote:
> I've triggered QA to reapply the patches now (by deleting the
> issue-66262 branch), so hopefully things will work better this time.

Could you try the same for https://qa.guix.gnu.org/issue/64222?
It's stuck at unknown and that's why everyone ghosted it
despite me pinging on IRC every other week in the last few months.


signature.asc
Description: PGP signature

Re: Failed to build in QA

[Christopher Baines]

"reza.housse...@gmail.com"  writes:

> I submitted an issue to guix. But QA refuses to build it [1]. I have
> no clue what the problem is, can anyone shed light on a possible
> resolution?

You pretty much found the problem, the relevant line on the page you
linked to is:

[  6/ 50] loading... 24.0% of 25 filesbuilder for 
`/gnu/store/qhvpjfn3d9cwz5zxadblbnbqa92a8i27-guix-cli-core.drv' failed due to 
signal 11 (Segmentation fault)

So the data service wasn't able to build Guix. This probably isn't due
to your changes, and it doesn't happen very often, so the thing to do
here is just retry.

I've triggered QA to reapply the patches now (by deleting the
issue-66262 branch), so hopefully things will work better this time.

Thanks,

Chris


signature.asc
Description: PGP signature

Failed to build in QA

[reza.housse...@gmail.com]

Hi list

I submitted an issue to guix. But QA refuses to build it [1]. I have no clue 
what the problem is, can anyone shed light on a possible resolution?

Best,
Reza

[1] https://data.qa.guix.gnu.org/job/49591#bottom
-- Sent from /e/ Mail.