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 -- 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 wrote: > Hi, > > On ven., 14 oct. 2022 at 11:09, Wojtek Kosior via 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 >