bug#59196: `guix pull` fails on A20-OLinuXino-LIME2-eMMC
Hi Simon, Thanks for diging this one out! Quoting Simon Tournier (2024-09-10 17:44:41) > On Fri, 11 Nov 2022 at 18:53, Tanguy LE CARROUR wrote: > > > /guix pull: error: You found a bug: the program > > '/gnu/store/mbs3lc77zy30nr82lnn2s135i2rvq095-compute-guix-derivation' > > failed to compute the derivation for Guix (version: > > "ba8679fb2452f4466a98a99edf050ea7452c83f4"; system: "armhf-linux"; > > host version: "1.2.0"; pull-version: 1). > > Please report the COMPLETE output above by email to . > > What is the status of this bug report? As I mentioned: "I think I'll redirect my energy to other tasks for the time being…" That’s exactly what I did!… and forgot to close the bug! 😅 Should I just do that? Regards, -- Tanguy
bug#69997: Should ‘guix import pypi’ get dependencies from pyproject files?
Quoting Ludovic Courtès (2024-03-29 10:06:31) > Tanguy LE CARROUR skribis: > > >> PS: I hear more and more long-time Python developers dismayed by the sad > >> state of packaging and code evolution in Python. In Guile land, we > >> say: refugees welcome! Come discover a great language and a great > >> community (together with their own set of problems). > > > > Thanks for the kind invitation, but… I have an acute form of parens-itis. > > Seeing more that a pair of parenthesis on a single line make my eyes bleed! > > 😅 > > And… `#` is for comments, every other use is complete heresy and those > > who go against the creed should suffer! … isn’t that what the parentheses > > are for?! 😉 > > Worry not! As part of our refugees-welcome effort, “we” have put > together tools and guides to help you feel at home: > > https://hg.sr.ht/~arnebab/wisp > https://www.draketo.de/py2guile 😵… 😱… 🤯! -- Tanguy
bug#69997: Should ‘guix import pypi’ get dependencies from pyproject files?
Hi Ludo’, Quoting Ludovic Courtès (2024-03-28 19:09:49) > Tanguy LE CARROUR skribis: > > > Quoting Ludovic Courtès (2024-03-26 17:04:52) > > [...] > > >> But then I mean, we could offer, say, ‘guix import upstream https://…’, > >> and that thing could parse ‘setup.py’ or similar to produce a package > >> definition from that. > > > > I’m not against a good-old-generic-solution®, but this one might be > > a bit… too generic. It contains no mention to Python, so the next logical > > step > > would be `guix import URL`. Not that I would not like it, though! 😁 > > Well, this has been on my mind for a long time. Such a tool could > provide at least a useful package skeleton even for software using CMake > or Autotools. > > > So I would say… let’s wait and see what the others think. In the > > meantime, I’ll have to dive deeper in the PEP and the actual importer > > code. > > Looks like consensus among you Pythonistas has yet to be reached > regarding whether ‘pyproject.toml’ data would be a useful addition. :-) I have to admit that the Zen of Python [1] "There should be one-- and preferably only one -- obvious way to do it." has been recently difficult to follow packaging-wise! [1]: https://peps.python.org/pep-0020 Even Poetry, the one I’ve been using for years, as made questionable decisions [2] and I have to admit that I had a look at the competitors. [2]: https://python-poetry.org/docs/faq/#why-does-poetry-not-adhere-to-semantic-versioning > PS: I hear more and more long-time Python developers dismayed by the sad > state of packaging and code evolution in Python. In Guile land, we > say: refugees welcome! Come discover a great language and a great > community (together with their own set of problems). Thanks for the kind invitation, but… I have an acute form of parens-itis. Seeing more that a pair of parenthesis on a single line make my eyes bleed! 😅 And… `#` is for comments, every other use is complete heresy and those who go against the creed should suffer! … isn’t that what the parentheses are for?! 😉 Any way, thanks again for caring about Python! Regards, -- Tanguy
bug#69997: Should ‘guix import pypi’ get dependencies from pyproject files?
Hi, Quoting Tanguy LE CARROUR (2024-03-26 17:55:23) > Quoting Ludovic Courtès (2024-03-26 17:04:52) > > Tanguy LE CARROUR skribis: > > > So, my answer would be: do not import from PyPI! Yes, I know, it’s > > > radical! 😅 > > > But if you have to, rely on the wheel’s `METADATA` file. > > > > > > I hope this make sense. … I’m not really sure any more! 😅 > > > > It does! > > > > But then I mean, we could offer, say, ‘guix import upstream https://…’, > > and that thing could parse ‘setup.py’ or similar to produce a package > > definition from that. > […] > So I would say… let’s wait and see what the others think. In the > meantime, I’ll have to dive deeper in the PEP and the actual importer > code. According to PEP 427 [1] a.k.a. Binary distribution format [2], if you go for packaged/PyPI then we should go for `METADATA`. [1]: https://peps.python.org/pep-0427/ [2]: https://packaging.python.org/en/latest/specifications/binary-distribution-format/#the-dist-info-directory But, as stated earlier, we should build from source, to make sure we can run the test suite. Active projects should slowly migrate to PEP 517 [3] `pyproject.toml`. But, this is not a solution! 😱 This is actually yet another problem! 😵 [3]: https://peps.python.org/pep-0517/ Each build system relies on it’s own file organization. For instance, Poetry looks for a `[tool.poetry.dependencies]` section in the file. So the importer should be "build system aware", which leads us to… `guix import poetry URL`!? Not really generic any more! 😞 I guess we should sleep on it… -- Tanguy
bug#69997: Should ‘guix import pypi’ get dependencies from pyproject files?
Hi, Quoting Ludovic Courtès (2024-03-26 17:04:52) > Tanguy LE CARROUR skribis: > > So, my answer would be: do not import from PyPI! Yes, I know, it’s radical! > > 😅 > > But if you have to, rely on the wheel’s `METADATA` file. > > > > I hope this make sense. … I’m not really sure any more! 😅 > > It does! > > But then I mean, we could offer, say, ‘guix import upstream https://…’, > and that thing could parse ‘setup.py’ or similar to produce a package > definition from that. I’m not against a good-old-generic-solution®, but this one might be a bit… too generic. It contains no mention to Python, so the next logical step would be `guix import URL`. Not that I would not like it, though! 😁 So I would say… let’s wait and see what the others think. In the meantime, I’ll have to dive deeper in the PEP and the actual importer code. > Maybe that’s what you had in mind: import straight from upstream rather than > via PyPI? I actually had nothing in mind! I blacked out after sending this email. Too many emotions at once, I guess! I had no clue it was such a mess. 😅 -- Tanguy
bug#69997: Should ‘guix import pypi’ get dependencies from pyproject files?
Hi Ludo’, Quoting Ludovic Courtès (2024-03-25 12:06:51) > Should ‘guix import pypi’ attempt to get dependency information from > ‘pyproject.toml’, in addition to ‘requirements.txt’ and wheel ‘METADATA’ > as it already does? > > It might be more complicated than we’d like: in some cases, that file > seems to be used as a “trampoline” to Poetry. For instance, in > python-pypugjs, the ‘requires’ bit delegates everything to Poetry: Short answer: no! 😁 I’m pretty sure you know everything that I’m about to write, but better say it out loud… For a "standard modern" project managed with Poetry, the Python source package contains `PKG-INFO` and `pyproject.toml ` that both contain the run time dependencies. The wheel package only contains `METADATA` that lists the dependencies. The source only contains a `pyproject.toml`. To make the installed package as small as possible, tests files and uncompiled assets are not (should not be) included. >From a Guix stand point, it’s better to build from source to be able to run the test suite. For the `python-pypugjs` you used as an example, we build from source, so I guess the question does not arise. If we were to use the packages available on PyPI, what I said above is *NOT* confirmed 😱: - wheel (`.whl`) only contains `METADATA` with the dependencies; **BUT** - source (`.tar.gz`) contains `PKG-INFO` (without dependency information), `pyproject.toml` (with dep’) and `setup.py` (also with dep’). … "fun" fact, the information in `pyproject.toml` are **NOT** the same as the one in `setup.py`!? 🤯 `pyproject.toml` says that `nose` is a run time dependency (which it is not), but `setup.py` properly lists it in `tests_require`. So, my answer would be: do not import from PyPI! Yes, I know, it’s radical! 😅 But if you have to, rely on the wheel’s `METADATA` file. I hope this make sense. … I’m not really sure any more! 😅 Regards, -- Tanguy
bug#65471: home mcron service overwrites PATH with a GuixSD-only directory
Hi, I've just experienced the problem first hand: https://lists.gnu.org/archive/html/help-guix/2024-01/msg00091.html Nils suggested to set the `PATH` environment variable, but 1) I have no clue how to do that 😅 and 2) it is not exactly the behaviour I would expect from a home service. Has anything been decided? Regards, -- Tanguy
bug#65463: Herd `fport_write: Broken pipe` error when running `guix home reconfigure`
Hi Guix, I think this has been happening for quite a long time, but I never paid attention to it, for everything seemed to be running just fine. When I run `guix home reconfigure`, it completes with the following message: ``` # […] Finished updating symlinks. SSLoading /gnu/store/zbfyaxxigns5lqyxhxzxhm92w54ns1cz-shepherd.conf. herd: error: exception caught while executing 'load' on service 'root': In procedure fport_write: Broken pipe Comparing /gnu/store/2sr90smj33k686394krjx1klhlpipd7z-home/profile/share/fonts and /gnu/store/2sr90smj33k686394krjx1klhlpipd7z-home/profile/share/fonts... done (same) Evaluating on-change gexps. On-change gexps evaluation finished. ``` I don't know if it's related, but since my last `guix pull`, `herd status` has been reporting strange statuses: ``` $ herd status Started: + root Starting: ^ mcron ^ mpd Stopped: - tor - transmission ``` `mcron` and `mpd` (a home service that I will eventually submit) are listed as `starting`, but they are actually started and they work just fine!? I had a look at this morning's log. This is what I see right after logging in: ``` 2023-08-23 08:21:36 Starting service root... 2023-08-23 08:21:36 Service root started. 2023-08-23 08:21:36 Service root running with value #t. 2023-08-23 08:21:36 Service root has been started. 2023-08-23 08:21:36 Daemonizing... 2023-08-23 08:21:36 Restarting signal handler. 2023-08-23 08:21:36 Now running as process 567. 2023-08-23 08:21:36 Starting services... 2023-08-23 08:21:36 Configuration successfully loaded from '/gnu/store/zbfyaxxigns5lqyxhxzxhm92w54ns1cz-shepherd.conf'. 2023-08-23 08:21:36 Starting service mpd... 2023-08-23 08:21:36 Starting service mcron... 2023-08-23 08:21:36 Service mpd has been started. 2023-08-23 08:21:37 [mpd] Aug 23 08:21 : server_socket: bind to '0.0.0.0:6600' failed (continuing anyway, because binding to '[::]:6600' succeeded): Failed to bind socket: Address already in use ``` The last line is strange. It looks like a second instance of `mpd` started, tried to bind to the same port and failed!? After `guix home reconfigure` I get: ``` 2023-08-23 08:31:51 Service mcron has been started. 2023-08-23 08:31:51 SSL2023-08-23 08:31:51 oading /gnu/store/zbfyaxxigns5lqyxhxzxhm92w54ns1cz-shepherd.conf. ``` There is no mention to `mpd` and there's a timestamp right in the middle of the second line?! When I try to `herd stop SOMETHING`, it hangs forever and I have to `ctrl+c` it. Any idea what might be going wrong?! -- Tanguy
bug#59196: guix pull fails on A20-OlinuXino-LIME2-eMMC
Hi, Quoting Tanguy LE CARROUR (2022-11-16 09:13:00) > Quoting Denis 'GNUtoo' Carikli (2022-11-16 04:17:15) > > I've found an idea: guix pull can pull to a precise commit: > > > --commit=COMMITdownload the specified "guix" channel COMMIT > > > > So maybe it works with a commit close to Guix 1.3. If that's the case > > we can probably bisect it to the commit that broke your guix pull. > > Sounds like a good idea! I'll try that later today and let you know! I bought a brand new "microSDHC UHS-1 A1" card and re-installed the latest Armbian on it, and… I couldn't even test your idea, for `guix pull` now fails with the following error message: ``` root@lime2:~# guix pull Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'... guix pull: error: Git error: error inflating zlib stream ``` I tried again, but… it failed again! 😞 … so I tried with [the binary install](https://guix.gnu.org/manual/en/html_node/Binary-Installation.html) of Guix, but it fails to install Guix, for the `/tmp` directory on Armbian is too small! 😱 I thought installing Guix System on my Lime would be less… frustrating! I think I'll redirect my energy to other tasks for the time being… Any way, thanks for your time and help! -- Tanguy
bug#59196: guix pull fails on A20-OlinuXino-LIME2-eMMC
Hi, Quoting Denis 'GNUtoo' Carikli (2022-11-16 04:17:15) > I've found an idea: guix pull can pull to a precise commit: > > --commit=COMMITdownload the specified "guix" channel COMMIT > > So maybe it works with a commit close to Guix 1.3. If that's the case > we can probably bisect it to the commit that broke your guix pull. Sounds like a good idea! I'll try that later today and let you know! Thanks, -- Tanguy
bug#59196: guix pull fails on A20-OlinuXino-LIME2-eMMC
Quoting Denis 'GNUtoo' Carikli (2022-11-13 21:54:49) > On Sun, 13 Nov 2022 11:48:18 +0100 > Tanguy LE CARROUR wrote: > > > Sat, 12 Nov 2022 16:40:20 +0100 > > > Does it also fails with 'guix pull -M 1 -c 1' ? > [...] > > I'll try on a brand new SD card, because the one I used is a bit old. > > > > Any other ideas about what might have gone wrong? > The command I gave sometimes works on 32bit machines with a low > amount of RAM, so it was worth trying. > > Unfortunately here I'm out of ideas, other people with more experience > in Guix might know better. > > Also note that I also do have an A20-OlinuXino-LIME2-eMMC, so I might > be able to run tests too if they are fast to do. Maybe I should try to > cross compile a rootfs and see if it boots. > > Long time ago it booted if I recall well, and then it stopped working > but I didn't take the time to track the regression down or to try again. Good to know. I don't actually need Guix System on my SBC, but you know, I have it on my computer @work, @home, on my laptop… so I thought to myself that it would make more sense to have it everywhere! Today my computers, tomorrow the world! 😎 -- Tanguy
bug#59196: guix pull fails on A20-OlinuXino-LIME2-eMMC
Hi Denis, Thanks for your answer. Strange thing, though… I didn't received your answer!? I came across it by chance while checking [bug-guix](https://lists.gnu.org/archive/html/bug-guix). > Sat, 12 Nov 2022 16:40:20 +0100 > Does it also fails with 'guix pull -M 1 -c 1' ? Thanks for the tip, but unfortunately, I get the same kind of error: ``` building /gnu/store/sq3w2hk9z1va6q2dbjg16mi0afw64q9b-gnutls-3.7.7.drv... substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% \ 'build' phas\Backtrace: 15 (primitive-load "/gnu/store/62r09kg575mg293by6fb83808p9diy3b-compute-guix-derivation") In ice-9/eval.scm: 155:9 14 (_ _) 159:9 13|(_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(# ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?)) In ice-9/boot-9.scm: 152:2 12 (with-fluid* _ _ _) 152:2 11 (with-fluid* _ _ _) In ./guix/store.scm: 2170:24 10 (run-with-store # _ #:guile-for-build _ #:system _ #:target _) 1998:8 9 (_ _) In ./guix/gexp.scm: 299:22 8 (_ _) 1180:2 7 (_ _) 1046:2 6 (_ _) 892:4 5 (_ _) In ./guix/store.scm: 2055:12 4 (_ #) 1403:5 3 (map/accumulate-builds # # ?) 1419:15 2 (_ # _ _) 713:11 1 (process-stderr # _) In ./guix/serialization.scm: 80:6 0 (read-int #) ./guix/serialization.scm:80:6: In procedure read-int: ERROR: 1. &nar-error: file: #f port: # /guix pull: error: You found a bug: the program '/gnu/store/62r09kg575mg293by6fb83808p9diy3b-compute-guix-derivation' failed to compute the derivation for Guix (version: "4f648f6096639427021da378fdfbd0c68d9d2aac"; system: "armhf-linux"; host version: "1.2.0"; pull-version: 1). Please report the COMPLETE output above by email to . ``` I'll try on a brand new SD card, because the one I used is a bit old. Any other ideas about what might have gone wrong? Regards, -- Tanguy
bug#59196: `guix pull` fails on A20-OLinuXino-LIME2-eMMC
Dear Guix, I decided to try to install Guix System on my A20-OLinuXino-LIME2-eMMC. I used the latest Armbian as a base system. I APT-installed Guix and tried to `guix pull`, but it failed with the following message: ```shell $ guix pull # […] building /gnu/store/05k8k43x5k78r0d41xcpw3ivwwr878rl-curl-7.84.0.tar.xz.drv... building /gnu/store/y9svpa7kwv48mpvgl5z9w7skizm93vb1-gnutls-3.7.7.tar.xz.drv... building /gnu/store/mz7ff25ihc77006p964ji5d47rhs2iam-guile-gnutls-3.7.9-checkout.drv... building /gnu/store/sq3w2hk9z1va6q2dbjg16mi0afw64q9b-gnutls-3.7.7.drv... / 'build' phas\Backtrace: 15 (primitive-load "/gnu/store/mbs3lc77zy30nr82lnn2s135i2rvq095-compute-guix-derivation") In ice-9/eval.scm: 155:9 14 (_ _) |159:9 13 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(# ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?)) In ice-9/boot-9.scm: 152:2 12 (with-fluid* _ _ _) 152:2 11 (with-fluid* _ _ _) In ./guix/store.scm: 2170:24 10 (run-with-store # _ #:guile-for-build _ #:system _ #:target _) 1998:8 9 (_ _) In ./guix/gexp.scm: 299:22 8 (_ _) 1180:2 7 (_ _) 1046:2 6 (_ _) 892:4 5 (_ _) In ./guix/store.scm: 2055:12 4 (_ #) 1403:5 3 (map/accumulate-builds # # ?) 1419:15 2 (_ # _ _) 713:11 1 (process-stderr # _) In ./guix/serialization.scm: 80:6 0 (read-int #) ./guix/serialization.scm:80:6: In procedure read-int: ERROR: 1. &nar-error: file: #f port: # /guix pull: error: You found a bug: the program '/gnu/store/mbs3lc77zy30nr82lnn2s135i2rvq095-compute-guix-derivation' failed to compute the derivation for Guix (version: "ba8679fb2452f4466a98a99edf050ea7452c83f4"; system: "armhf-linux"; host version: "1.2.0"; pull-version: 1). Please report the COMPLETE output above by email to . ``` >From the backtrace, I cannot figure out what went wrong! Any idea? Best regards, -- Tanguy
