Re: Policy to remove broken packages

[Leo Famulari]

On Mon, Jun 22, 2020 at 06:06:44PM +0100, Christopher Baines wrote:
> It seems like you got further in understanding this than I did. Given
> that this seems like a test failure, and I don't think there's anything
> to suggest that the actual functionality doesn't work, the course of
> action I see here is to disable either the failing tests, or running the
> test suite entirely.

Not having looked into it closely, I think that, in general, test
failures do indicate that actual functionality is broken. Of course it's
a different story in many cases since the Guix build environment is so
unusual.

Re: Policy to remove broken packages

[Christopher Baines]

Jack Hill  writes:

> On Sat, 20 Jun 2020, Christopher Baines wrote:
>
>> Do you have any examples of packages that are currently broken, and
>> which you'd like to remove?
>
> Perhaps mongo-tools: https://issues.guix.gnu.org/39637
>
> It broke when Go was upgraded to 1.13, and changed the test library. I
> fixed some other Go packages that ran into this issue, but it wasn't
> as easy for mongo-tools. Our version is old, so it should be
> updated. For various reasons, I don't see this package being fixed in
> the short term.

mongo-tools is definitely failing to build, and it has been since the
11th of Feb (2020) I think.

It seems like you got further in understanding this than I did. Given
that this seems like a test failure, and I don't think there's anything
to suggest that the actual functionality doesn't work, the course of
action I see here is to disable either the failing tests, or running the
test suite entirely.

I originally packaged MongoDB and mongo-tools for Guix, but that was
before the licence of MongoDB changed, so I'm not sure about the long
term future of the packages. Keeping the packages we have actually
building though is still useful.

Thanks,

Chris


signature.asc
Description: PGP signature

Re: Policy to remove broken packages

[Jack Hill]

On Sat, 20 Jun 2020, Christopher Baines wrote:


Do you have any examples of packages that are currently broken, and
which you'd like to remove?


Perhaps mongo-tools: https://issues.guix.gnu.org/39637

It broke when Go was upgraded to 1.13, and changed the test library. I 
fixed some other Go packages that ran into this issue, but it wasn't as 
easy for mongo-tools. Our version is old, so it should be updated. For 
various reasons, I don't see this package being fixed in the short term.


Best,
Jack

Derivation is missing output

[Hartmut Goebel]

Hi,

I'm still working on the download and importer for hex.pm and the rebar3
build-system for Erlang. So far I made good progress, but now I stepped
over a curious issue:

The downloader is modeled like the one for git, bzr and hg, creating a
fixed script controlled by environment variables. The script is created
as expected. But the script is never run. After some debugging, I
discovered that the source package's .drv file does not define any output:

Derivce([],[…inputs…])

What can be the reason for this?

Some background (the whole source can be found at
https://gitlab.digitalcourage.de/htgoebel/guix/-/tree/HG-rebar-build-system):

    (source
 (origin
   (method hexpm-fetch)
   (uri "https://repo.hex.pm/tarballs/getopt-1.0.1.tar;)
   (sha256
    (base32 "1fhqnn4dvcil12cmqmzkmlk14lq5rn7ingld2380i6nl8v2dvm48"

and hexpm-fetch returns

  (mlet %store-monad ((guile (package->derivation guile system)))
    (gexp->derivation (pk (or name file-name)) build
   … more arguments))

-- 
Regards
Hartmut Goebel

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

Re: Jami bug source investigation #4

[Pierre Neidhardt]

Jan Wielkiewicz  writes:

> I'm not sure whether I should fetch from git or use a tarball after
> doing all this work. Fetching from git adds more complexity to the
> packages, but it gives me more control over it plus I'm not sure if I
> can trust the tarballs anymore, after two cases where some files/folders
> were missing.

Then it seems reasonable to fetch from Git.

> Once I'll send the patches, would be cool if someone tested it.

Will do, thanks again for your work!

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


signature.asc
Description: PGP signature

Re: Jami bug source investigation #4

[Jan Wielkiewicz]

On Mon, 22 Jun 2020 09:32:50 +0200
Pierre Neidhardt  wrote:

> Great!  Does this fix any other issue?
> Does it warrant a package upgrade in Guix?
> 

This alone didn't fix the problem, but as no other possibility was left
than broken pjproject, I tried to fix it and succeeded.
It is mandatory to pass "-DNDBUG" flag to turn off assertion.
https://trac.pjsip.org/repos/wiki/FAQ#Performance
https://trac.pjsip.org/repos/wiki/FAQ#assert

"Release mode. Don't forget to set the appropriate compiler
optimization flag, and disable assertion with -DNDEBUG."

This surely fixes the bug the reason of I was chasing for several
months, where after disconnecting from audio call, the daemon
"crashed" (asserted).
It is also possible this fixes some other issues with SIP, I didn't
test, because I was uninterested.

I'll prepare my messy code for committing once I have more time.

I'm not sure whether I should fetch from git or use a tarball after
doing all this work. Fetching from git adds more complexity to the
packages, but it gives me more control over it plus I'm not sure if I
can trust the tarballs anymore, after two cases where some files/folders
were missing.

Once I'll send the patches, would be cool if someone tested it.



Jan Wielkiewicz

Re: backtrace when building os

[Jan Synacek]

Ludovic Courtès  writes:

> Hi,
>
> Jan Synacek  skribis:
>
>> $ cat guix-os.scm
>> (use-modules (gnu bootloader)
>>   (gnu bootloader grub)
>>   (gnu system file-systems))
>>
>> (operating-system
>>   (host-name "jsynacek-guix-os")
>>   (timezone "Europe/Prague")
>>   (locale "en_US.utf8")
>>   (bootloader
>> (bootloader-configuration
>>   (bootloader grub-efi-bootloader)
>>   (target "/dev/sdx")))
>>   (file-systems
>> (list (file-system (mount-point "/home")
>>(device "/dev/sda33")
>>(type "ext4")
>
> This OS lacks a root file system (which is no excuse for throwing a
> backtrace, though!).

Thank you for the explanation. And I agree about the backtrace part.
I have already filed a bug report, although I accidentaly filed it
against guile, instead of guix. Sorry for the mess.

Regards,
-- 
Jan Synacek
Software Engineer, Red Hat

Re: “Reproducible research articles, from source code to PDF”

[Ludovic Courtès]

Hi Konrad,

Konrad Hinsen  skribis:

> Konrad Hinsen  writes:
>
>> Sounds fine. I am not much of a hackathon expert, so I don't propose
>> myself for organizing this, but I can make a preselection of suitable
>> submissions to the ReScience challenge (no proprietary software etc.)
>> with comments about the specific challenges.
>
> Here is my list of candidate projects. There are three general
> categories:
>
> 1) Package old software that is of sufficiently wide interest
>(i.e. add to guix-past)
> - g77 (used in https://github.com/ReScience/submissions/issues/41)
> - SciPy ecosystem from 2007 (at least Python, NumPy, matplotlib)
>   (used in https://github.com/ReScience/submissions/issues/14)

Makes sense.

> 2) Package highly specialized research software
>
>These programs are too specialized for the Guix distribution, so
>"packaging" means writing a guix.scm. The long-term goal is to learn how
>to make this kind of packaging easier, to the point that scientists are
>willing to do it themselves. This means it must be doable with minimal
>Guile competence, ideally by modifying templates provided by experts.
>
>I have picked four cases, listed by increasing level of difficulty:
>
>a) https://github.com/ReScience/submissions/issues/42
>
>A rather standard Fortran code, with only the popular BLAS and LAPACK
>libraries as dependencies. Instructions are given for manual
>compilation.
>
>b) https://github.com/ReScience/submissions/issues/36
>
>A medium-sized Fortran program with a Makefile.
>
>c) https://github.com/ReScience/submissions/issues/41
>
>A mixed C-Fortran code from 2008, built with autotools. Looks simple,
>but the author did not succeed in compiling it on a modern machine
>because it requires the abandoned g77 compiler.
>
>d) https://github.com/ReScience/submissions/issues/20
>
>A medium-sized Fortran library with a Makefile. Tricky because it adds
>its own wrappers around the Fortran compiler.

That’s going to be less fun but I agree it’s important to do something
for this use case.

> 3) Fully automated reproductions of results (typically figures)
>
>There is only one case (other than Ludo's which already uses Guix):
>
>- https://github.com/ReScience/submissions/issues/39
>
>A fully reproducible reproduction of two Open Source simulation software
>packages (C/C++), based on Debian and its debuerreotype system. The
>challenge is to demonstrate how Guix can do it better!

Heh, nice!   is
interesting.

Thanks for sharing this overview, I guess we have enough on our plate now!
:-)

Ludo’.