help-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: program prepared with `guix pack` unusable by end users


From: Wojtek Kosior
Subject: Re: program prepared with `guix pack` unusable by end users
Date: Mon, 17 Oct 2022 15:36:48 +0200

Hello again after a break,

> Well, then I tried to reproduce your failure in order to understand what
> is going wrong but I hit this:
>
> [...]
> 
> That’s because your package ’python-pyopenssl-for-haketilo’ inherit from
> ’python-pyopenssl’ defined in (gnu packages python-crypto).  The issue
> is that the ’origin’ also inherits
> 
>        (origin
>          (inherit (package-source base))
>          
> and thus
> 
>        (patches (search-patches "python2-pyopenssl-openssl-compat.patch"))))
> 
> does not make sense anymore because this patch is against 21.0.0 and
> your variant is about 22.0.0.

Thank you for your time spent on trying this out.

The error is surely a result of us using different Guix versions. In the
version I had the pyOpenSSL version was 20.0.1 and no patch was being
used yet[1].

Another user also had problems building from source under a different
Guix version. I knew this would happen but I didn't have a ready
solution before. I now came up with a Makefile that organizes most
common development tasks in my project into rules that call `guix
time-machine` under the hood[2]. This should be a general solution for
this kind of problems.

> Well, further investigations about what could be wrong for “guix pack”
> needs a way to reproduce. :-)  Could you fix or point a working
> example in your Git repository?

As for troubleshooting the creation of Hydrilla 3.0-beta1 pack, one can
get the same enviroment I was using by pulling Guix from commit
fd00ac7e27c8a6d4b4d4719b4f8797bdce204623. Although most list users here
probably know how to achieve this, I'm putting this here for convenience

> guix time-machine --commit=fd00ac7e27c8a6d4b4d4719b4f8797bdce204623 -- 
> <REST-OF-THE-USUAL-GUIX-COMMAND>

Anyway, the main problem could probably be also troubleshooted by
experimenting with the pack I made available[3] as it is also the one
that is known to have caused problems.

Thank you again,
Wojtek

[1] 
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/python-crypto.scm?id=fd00ac7e27c8a6d4b4d4719b4f8797bdce204623#n650
[2] 
https://git.koszko.org/pydrilla/commit/?h=koszko&id=ed2e14dd6ced4f64b6ac707c5998b38a78e6d7ad
[3] https://hydrillabugs.koszko.org/projects/haketilo/wiki/Releases#Files

-- (sig_start)
website: https://koszko.org/koszko.html
PGP: https://koszko.org/key.gpg
fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A

Meet Kraków saints!           #13: blessed Jan Beyzym
Poznaj świętych krakowskich!  #13: błogosławiony Jan Beyzym
https://pl.wikipedia.org/wiki/Jan_Beyzym
-- (sig_end)


On Fri, 14 Oct 2022 13:00:18 +0200
zimoun <zimon.toutoune@gmail.com> wrote:

> Hi,
> 
> On ven., 14 oct. 2022 at 11:09, Wojtek Kosior via <help-guix@gnu.org> wrote:
> 
> > I accidently just replied to you, Simon, instead of making a "reply
> > all". I'm reposting the same now, sorry for the nuisance...  
> 
> Do not worry. :-)
> 
> > So, I did run `guix shell -L. hydrilla`. First, I got a warning about
> >  
> >> ambiguous package specification `hydrilla'  
> 
> That’s expected because:
> 
> --8<---------------cut here---------------start------------->8---
> (define-public hydrilla
>   (package
>     (name "hydrilla")
> 
> [...]
> 
> (define-public hydrilla-dist-tarball
>   (let ((base hydrilla)
>         (filename (string-append "hydrilla-" %hydrilla-version ".tar.gz")))
>     (package
>       (inherit base)
>       (source (local-file
> --8<---------------cut here---------------end--------------->8---
> 
> It means that the package ’hydrilla’ has the name “hydrilla” and because
> the package ’hydrilla-dist-tarball’ inherits then it also has the name
> “hydrilla”.  Idem for the version field.
> 
> Therefore,
> 
>     guix shell -L . hydrilla
> 
> refers to 2 possible packages.  All Guix CLI commands use “name“ and
> “version” for looking up to packages and not the symbols.
> 
> 
> Well, then I tried to reproduce your failure in order to understand what
> is going wrong but I hit this:
> 
> --8<---------------cut here---------------start------------->8---
> $ guix build -L . python-pyopenssl@22.0.0
> The following derivations will be built:
>   /gnu/store/gyc6sw8a9vq09z6p7plv3k5sjjvrcz9i-python-pyopenssl-22.0.0.drv
>   /gnu/store/rfawn8bnr1vz71gcm6dz171gfpk0fwai-pyOpenSSL-22.0.0.tar.xz.drv
> building 
> /gnu/store/rfawn8bnr1vz71gcm6dz171gfpk0fwai-pyOpenSSL-22.0.0.tar.xz.drv...
> pyOpenSSL-22.0.0/
> 
> [...]
> 
> pyOpenSSL-22.0.0/tox.ini
> patching file src/OpenSSL/SSL.py
> Hunk #1 FAILED at 1421.
> Hunk #2 FAILED at 2449.
> 2 out of 2 hunks FAILED -- saving rejects to file src/OpenSSL/SSL.py.rej
> patching file tests/test_ssl.py
> Hunk #1 FAILED at 1928.
> 1 out of 1 hunk FAILED -- saving rejects to file tests/test_ssl.py.rej
> source is at 'pyOpenSSL-22.0.0'
> applying 
> '/gnu/store/4cd1x970w3jg3rwaiqg174x56mvkihij-python2-pyopenssl-openssl-compat.patch'...
> Backtrace:
> 
> [...]
> 
> ERROR:
>   1. &invoke-error:
>       program: 
> "/gnu/store/z39hnrwds1dgcbpfgj8dnv2cngjb2xbl-patch-2.7.6/bin/patch"
>       arguments: ("--force" "--no-backup-if-mismatch" "-p1" "--input" 
> "/gnu/store/4cd1x970w3jg3rwaiqg174x56mvkihij-python2-pyopenssl-openssl-compat.patch")
> 
> [...]
> 
> builder for 
> `/gnu/store/rfawn8bnr1vz71gcm6dz171gfpk0fwai-pyOpenSSL-22.0.0.tar.xz.drv' 
> failed with exit code 1
> build of 
> /gnu/store/rfawn8bnr1vz71gcm6dz171gfpk0fwai-pyOpenSSL-22.0.0.tar.xz.drv failed
> View build log at 
> '/var/log/guix/drvs/rf/awn8bnr1vz71gcm6dz171gfpk0fwai-pyOpenSSL-22.0.0.tar.xz.drv.gz'.
> cannot build derivation 
> `/gnu/store/gyc6sw8a9vq09z6p7plv3k5sjjvrcz9i-python-pyopenssl-22.0.0.drv': 1 
> dependencies couldn't be built
> guix build: error: build of 
> `/gnu/store/gyc6sw8a9vq09z6p7plv3k5sjjvrcz9i-python-pyopenssl-22.0.0.drv' 
> failed
> --8<---------------cut here---------------end--------------->8---
> 
> That’s because your package ’python-pyopenssl-for-haketilo’ inherit from
> ’python-pyopenssl’ defined in (gnu packages python-crypto).  The issue
> is that the ’origin’ also inherits
> 
>        (origin
>          (inherit (package-source base))
>          
> and thus
> 
>        (patches (search-patches "python2-pyopenssl-openssl-compat.patch"))))
> 
> does not make sense anymore because this patch is against 21.0.0 and
> your variant is about 22.0.0.
> 
> 
> Well, further investigations about what could be wrong for “guix pack”
> needs a way to reproduce. :-)  Could you fix or point a working example
> in your Git repository?
> 
> 
> Thanks,
> simon
> 


Attachment: pgpiEn82pOoKy.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]