* Release 1.2.1: status @ 2021-03-18 14:28 zimoun 2021-03-19 6:37 ` Chris Marusich ` (3 more replies) 0 siblings, 4 replies; 16+ messages in thread From: zimoun @ 2021-03-18 14:28 UTC (permalink / raw) To: Guix Devel Hi, First, thanks to Chris and folks, powerpc64le-linux will be [1] in the next release, great! Isn’t it? :-) Then, ~95% of packages for x86_64 are substituables which is really great too. Even, maybe more could be available. Well, if you want to help, simply run: guix weather --display-missing \ | grep '/gnu/store/' | cut -d'-' -f2- | sort and check your favorite packages. Especially, please report if the package builds but is not substituable. If it is broken, fixes are very welcome! ;-) What annoys me a bit is some scientific packages are broken, as OpenFoam or FreeCAD. Other as mpich-3.3.2, mumps-metis-openmpi-5.2.1, gmsh-4.6.0, etc. are missing, but for instance Gmsh builds. Well, It could be nice if someone could have a look. :-) Note that fixing these prefix could really help on the coverage. - cl-, ecl- and sbcl- - emacs- - java- - maven- - ocaml4.07- - perl6- - python- (python2- but please consider the removal of these 25 ones: <http://issues.guix.gnu.org/issue/47165>) - rust- (THE thing to work on) However, the story is a bit different for other architectures. For aarch64-linux, I get ~85% of substitutes. But I have not looked to see if these ~15% are broken or simply missing. For the other ones, I am still waiting after “guix weather” to complete. And there is 246 packages available for i586-gnu. \o/ We are still missing a good story to monitor what is archived on Software Heritage and what is not. Because for now there is rate limit, I am not able to automate… Well, it is a long WIP. :-) To help and avoid this rate limit, if all of us simply run: for pkg in $(guix package -I | cut -f1); do guix lint -c archival $pkg done for all our profiles, it will ensure at least a coverage for the packages using git-fetch that we individually care. Note the option --manifest for “guix lint” is missing… should happen soon if no one beats me. :-) Last, in the last month, I count 20 “new“ grafts and no remove. That’s really cool, some packages are fixed. The downside is these 20 grafted packages on master: --8<---------------cut here---------------start------------->8--- $ ag --scheme '\(replacement' gnu/packages --no-filename --no-break |sort (replacement (and=> (package-replacement p) (replacement cairo/fixed) (replacement c-ares/fixed) (replacement cyrus-sasl/fixed) (replacement gdk-pixbuf/fixed) (replacement glib/fixed) (replacement gnutls/fixed) (replacement imagemagick/fixed) (replacement libcroco/fixed) (replacement libtiff/fixed) (replacement libx11/fixed) (replacement openldap-2.4.57) (replacement openssl/fixed) (replacement postgresql-13.2) (replacement python-2.7/fixed) (replacement python-3.8/fixed) (replacement python-pygments/fixed) (replacement python-urllib3/fixed) (replacement unzip/fixed) (replacement zstd-1.4.9) (replacement zziplib/fixed) --8<---------------cut here---------------end--------------->8--- and other are waiting (for instance sqlite and others). The branch wip-next-release is totally ungrafted but I am doubtful it is buildable. I mean, it looks like a small core-updates. :-) BTW, I have started to rebuild on my own all the dependants of ’zstd’ with 1.4.9. For example, it seems to break MariaDB. Has the build farm started to build this branch wip-next-release? Having an ungrafted release really depends on that. If we do not know which packages are broken, the Ungraftathon on March 27-28 will not be so much useful. IMHO. On a side note, having 20 grafts for a release is not a big deal, v1.2.0 contains these 16 grafts: --8<---------------cut here---------------start------------->8--- (replacement (and=> (package-replacement p) (replacement curl-7.71.0) (replacement dbus/fixed) (replacement fontconfig/font-dejavu) (replacement freetype/fixed) (replacement glib-with-gio-patch) (replacement gnutls-3.6.14) (replacement json-c/fixed) (replacement libjpeg-turbo/fixed) (replacement libsndfile-1.0.30) (replacement libspiro-20200505) (replacement libx11/fixed) (replacement mesa-20.0.8) (replacement nghttp2-1.41) (replacement openldap-2.4.50) (replacement openssl-1.1.1g) (replacement xorg-server/fixed) --8<---------------cut here---------------end--------------->8--- 1: <https://yhetil.org/guix/878s6n7nk7.fsf_-_@gmail.com> Cheers, simon ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Release 1.2.1: status 2021-03-18 14:28 Release 1.2.1: status zimoun @ 2021-03-19 6:37 ` Chris Marusich 2021-03-19 8:27 ` Christopher Baines 2021-03-19 8:50 ` zimoun 2021-03-19 18:31 ` Andreas Enge ` (2 subsequent siblings) 3 siblings, 2 replies; 16+ messages in thread From: Chris Marusich @ 2021-03-19 6:37 UTC (permalink / raw) To: zimoun; +Cc: Guix Devel [-- Attachment #1: Type: text/plain, Size: 714 bytes --] Hi simon, zimoun <zimon.toutoune@gmail.com> writes: > First, thanks to Chris and folks, powerpc64le-linux will be [1] in the > next release, great! Isn’t it? :-) I'm very excited about this! Efraim was able to rework our patches so they could be applied to master without rebuilding the entire world. The patches are currently under review here: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=47182 More review is welcome, but unless some unforeseen issues are discovered, I agree that we can go ahead with adding support for powerpc64le-linux. Where is the release work happening? Where can I merge or apply these changes to ensure they get included in the next release? -- Chris [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 861 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Release 1.2.1: status 2021-03-19 6:37 ` Chris Marusich @ 2021-03-19 8:27 ` Christopher Baines 2021-03-19 8:50 ` zimoun 1 sibling, 0 replies; 16+ messages in thread From: Christopher Baines @ 2021-03-19 8:27 UTC (permalink / raw) To: Chris Marusich; +Cc: Guix Devel [-- Attachment #1: Type: text/plain, Size: 961 bytes --] Chris Marusich <cmmarusich@gmail.com> writes: > Hi simon, > > zimoun <zimon.toutoune@gmail.com> writes: > >> First, thanks to Chris and folks, powerpc64le-linux will be [1] in the >> next release, great! Isn’t it? :-) > > I'm very excited about this! Efraim was able to rework our patches so > they could be applied to master without rebuilding the entire world. > The patches are currently under review here: > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=47182 > > More review is welcome, but unless some unforeseen issues are > discovered, I agree that we can go ahead with adding support for > powerpc64le-linux. > > Where is the release work happening? Where can I merge or apply these > changes to ensure they get included in the next release? In the past, a branch might appear for the release, but that hasn't happened yet. Merging to master is the next step I believe, and as you say, I think the patches are ready. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 987 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Release 1.2.1: status 2021-03-19 6:37 ` Chris Marusich 2021-03-19 8:27 ` Christopher Baines @ 2021-03-19 8:50 ` zimoun 2021-03-20 18:09 ` Leo Famulari 1 sibling, 1 reply; 16+ messages in thread From: zimoun @ 2021-03-19 8:50 UTC (permalink / raw) To: Chris Marusich; +Cc: Guix Devel Hi Chris, On Thu, 18 Mar 2021 at 23:37, Chris Marusich <cmmarusich@gmail.com> wrote: > More review is welcome, but unless some unforeseen issues are > discovered, I agree that we can go ahead with adding support for > powerpc64le-linux. Great! > Where is the release work happening? Where can I merge or apply these > changes to ensure they get included in the next release? The release work happens on master. The branch wip-next-release contains fixes, but AFAIK, it is not built by the CI, and these fixes are ’core-updates’-like changes; I do not know if it is doable to merge on time. Well, maybe the patches could be directly applied to master, IMHO. Quote the proposed Release timeline [1]: A draft of the timeline is: - until April 1rst: fixes, check substitute availability, etc. - as soon as possible: start to build wip-next-release - merge branch wip-next-release when ready - on Monday 12th April, string freeze - couple of days after, branch the release and write the materials (ChangeLog and posts) - release Cheers, simon PS: Sorry if the release process appears unclear. Based on the experiences of 1.2.0 and now this one, the idea is to propose then a clear documented timeline for the next releases. Basically, some technical items are described in maintenance/doc/release.org [2] and from my point of view, some items describing the (timeline) process should be added. Maybe in the manual so that we all know what we can «expect». 1: <https://yhetil.org/guix/867dmcifii.fsf@gmail.com> 2: <https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/release.org> ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Release 1.2.1: status 2021-03-19 8:50 ` zimoun @ 2021-03-20 18:09 ` Leo Famulari 2021-03-20 22:56 ` zimoun 0 siblings, 1 reply; 16+ messages in thread From: Leo Famulari @ 2021-03-20 18:09 UTC (permalink / raw) To: zimoun; +Cc: Guix Devel On Fri, Mar 19, 2021 at 09:50:55AM +0100, zimoun wrote: > The release work happens on master. The branch wip-next-release > contains fixes, but AFAIK, it is not built by the CI, and these fixes > are ’core-updates’-like changes; I do not know if it is doable to merge > on time. I agree. The scope of ungrafting has grown way too large, and we need to spend the rest of the time fixing bugs. Maybe there are some things we could ungraft in time, or that are failing to work properly as grafts (ImageMagick / broken Inkscape?) and should thus be ungrafted or somehow adjusted. From the wip-next-release branch, we should cherry-pick the tzdata updates and Qt 4 removal. I'll rewrite the branch with those commits today, and then see about getting it built on CI. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Release 1.2.1: status 2021-03-20 18:09 ` Leo Famulari @ 2021-03-20 22:56 ` zimoun 2021-03-20 23:21 ` Leo Famulari 0 siblings, 1 reply; 16+ messages in thread From: zimoun @ 2021-03-20 22:56 UTC (permalink / raw) To: Leo Famulari; +Cc: Guix Devel Hi Leo, On Sat, 20 Mar 2021 at 14:09, Leo Famulari <leo@famulari.name> wrote: > On Fri, Mar 19, 2021 at 09:50:55AM +0100, zimoun wrote: >> The release work happens on master. The branch wip-next-release >> contains fixes, but AFAIK, it is not built by the CI, and these fixes >> are ’core-updates’-like changes; I do not know if it is doable to merge >> on time. > > I agree. The scope of ungrafting has grown way too large, and we need to > spend the rest of the time fixing bugs. I agree. For instance, I have started to see if zstd could be ungrafted and with my knowledge, my time available considering the other parts to check, and my CPU available to build a lot, IMHO, it is not possible to be on time. > Maybe there are some things we could ungraft in time, or that are > failing to work properly as grafts (ImageMagick / broken Inkscape?) and > should thus be ungrafted or somehow adjusted. I have not check at ImageMagick specifically. My feeling about the recent grafts is that they are more than security fixes because they are often version upgrades. And version upgrade often implies breakage here or there. Therefore, I agree they need to be adjusted and maybe, IMHO, we could have a gratf freeze starting on April 1rst in order to have time to check that everything is fine, AFAWCT. > From the wip-next-release branch, we should cherry-pick the tzdata > updates and Qt 4 removal. > > I'll rewrite the branch with those commits today, and then see about > getting it built on CI. Do you mean cherry-pick and then push them to master? Cheers, simon ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Release 1.2.1: status 2021-03-20 22:56 ` zimoun @ 2021-03-20 23:21 ` Leo Famulari 0 siblings, 0 replies; 16+ messages in thread From: Leo Famulari @ 2021-03-20 23:21 UTC (permalink / raw) To: zimoun; +Cc: Guix Devel On Sat, Mar 20, 2021 at 11:56:57PM +0100, zimoun wrote: > > From the wip-next-release branch, we should cherry-pick the tzdata > > updates and Qt 4 removal. > > > > I'll rewrite the branch with those commits today, and then see about > > getting it built on CI. > > Do you mean cherry-pick and then push them to master? We can remove Qt 4 on master, but tzdata cannot be changed on the master branch (too many dependents). We need to build it on CI, on its own branch, and then deploy the change on master. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Release 1.2.1: status 2021-03-18 14:28 Release 1.2.1: status zimoun 2021-03-19 6:37 ` Chris Marusich @ 2021-03-19 18:31 ` Andreas Enge 2021-03-19 21:59 ` Luis Felipe 2021-03-20 23:03 ` zimoun 2021-03-19 22:26 ` Luis Felipe 2021-03-20 20:01 ` Leo Famulari 3 siblings, 2 replies; 16+ messages in thread From: Andreas Enge @ 2021-03-19 18:31 UTC (permalink / raw) To: zimoun; +Cc: Guix Devel Hello, Am Thu, Mar 18, 2021 at 03:28:38PM +0100 schrieb zimoun: > guix weather --display-missing I am giving it a try, but after about one hour at 100% CPU on one core it is still only half way through. Is this normal? I think I will stop it to at least redirect the output into a file... Andreas ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Release 1.2.1: status 2021-03-19 18:31 ` Andreas Enge @ 2021-03-19 21:59 ` Luis Felipe 2021-03-20 23:03 ` zimoun 1 sibling, 0 replies; 16+ messages in thread From: Luis Felipe @ 2021-03-19 21:59 UTC (permalink / raw) To: Andreas Enge; +Cc: zimoun, Guix Devel ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, March 19, 2021 6:31 PM, Andreas Enge <andreas@enge.fr> wrote: > Hello, > > Am Thu, Mar 18, 2021 at 03:28:38PM +0100 schrieb zimoun: > > > guix weather --display-missing > > I am giving it a try, but after about one hour at 100% CPU on one core it > is still only half way through. Is this normal? I think I will stop it to > at least redirect the output into a file... In my case, after ~20 minutes, it progressed about 20-30%, and then the progress bar got reset and started again. Later, an hour and ten minutes have passed since I ran the command, it reached around 30% again, progressing very, very slowly. Then, a gnu-tls error occurred: ★★★★★★★★★★★★★★★ Backtrace: 11 (primitive-load "/home/yo/.config/guix/current/bin/guix") In guix/ui.scm: 2164:12 10 (run-guix-command _ . _) In ice-9/boot-9.scm: 1736:10 9 (with-exception-handler _ _ #:unwind? _ # _) 1731:15 8 (with-exception-handler #<procedure 7f5c27e2af30 at ic…> …) In guix/scripts/weather.scm: 552:9 7 (_) In guix/build/utils.scm: 569:23 6 (every* #<procedure 7f5c12f23990 at guix/scripts/weath…> …) In guix/scripts/weather.scm: 553:19 5 (_ "https://ci.guix.gnu.org") 116:17 4 (report-server-coverage _ _ #:display-missing? _) In unknown file: 3 (_ #<procedure 7f5c00deb3c0 at guix/scripts/weather.…> . #) In guix/substitutes.scm: 315:31 2 (lookup-narinfos _ _ #:open-connection _ # _) 238:26 1 (fetch-narinfos _ _ #:open-connection _ # _) In ice-9/boot-9.scm: 1669:16 0 (raise-exception _ #:continuable? _) ice-9/boot-9.scm:1669:16: In procedure raise-exception: Throw to key `gnutls-error' with args `(#<gnutls-error-enum Error en la función empuje.> read_from_session_record_port)'. ★★★★★★★★★★★★★★★ The text in #<gnutls-error-enum Error en la función empuje.> is Spanish, meaning something like: Error in the push function. This is my system information: OS: Guix System 1ab03fb74505458e7754dce338a5da29dc754d80 x86_64 Kernel: 5.11.7-gnu CPU: Intel i3-8100 (4) @ 3.600GHz GPU: Intel 8th Gen Core Processor Gaussian Mixture Model Memory: 1804MiB / 3766MiB ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Release 1.2.1: status 2021-03-19 18:31 ` Andreas Enge 2021-03-19 21:59 ` Luis Felipe @ 2021-03-20 23:03 ` zimoun 1 sibling, 0 replies; 16+ messages in thread From: zimoun @ 2021-03-20 23:03 UTC (permalink / raw) To: Andreas Enge; +Cc: Guix Devel Hi Andreas, On Fri, 19 Mar 2021 at 19:31, Andreas Enge <andreas@enge.fr> wrote: > Am Thu, Mar 18, 2021 at 03:28:38PM +0100 schrieb zimoun: >> guix weather --display-missing > > I am giving it a try, but after about one hour at 100% CPU on one core it > is still only half way through. Is this normal? I think I will stop it to > at least redirect the output into a file... I sympathise. It depends the architecture from my experience. Some are not responding at all. Which one are you “guix weather”ing? If your machine is always up, you can try: until guix weather; do echo ok; done even it is not really reliable. Cheers, simon ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Release 1.2.1: status 2021-03-18 14:28 Release 1.2.1: status zimoun 2021-03-19 6:37 ` Chris Marusich 2021-03-19 18:31 ` Andreas Enge @ 2021-03-19 22:26 ` Luis Felipe 2021-03-21 0:16 ` zimoun 2021-03-20 20:01 ` Leo Famulari 3 siblings, 1 reply; 16+ messages in thread From: Luis Felipe @ 2021-03-19 22:26 UTC (permalink / raw) To: zimoun; +Cc: Guix Devel Hi zimoun :) ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, March 18, 2021 2:28 PM, zimoun <zimon.toutoune@gmail.com> wrote: [...] > We are still missing a good story to monitor what is archived on > Software Heritage and what is not. Because for now there is rate limit, > I am not able to automate… Well, it is a long WIP. :-) > > To help and avoid this rate limit, if all of us simply run: > > for pkg in $(guix package -I | cut -f1); > do > guix lint -c archival $pkg > done > > for all our profiles, it will ensure at least a coverage for the > packages using git-fetch that we individually care. Note the option > --manifest for “guix lint” is missing… should happen soon if no one > beats me. :-) I tried this with my user profile and the script hit the Software heritage limit after reporting the status of 33 packages (most of which are not archived). So, for the rest of the packages, you are asked to try again later (I have 95 packages in my profile). Is "guix lint -c archival $pkg" supposed to poke Software Heritage to archive the $pkg if it is not archived yet? I ask because I ran the script later and I got the same output from the first run, i.e., packages reported to be missing from Software Heritage were still reported as such, instead of being planned for archive. Also, I got a backtrace when checking icecat: ★★★★★★★★★★★★★★★ gnu/packages/virtualization.scm:1070:5: libvirt@5.8.0: Software Heritage rate limit reached; try again later Backtrace:cecat@78.8.0-guix0-preview1 [archival]... 12 (primitive-load "/home/yo/.config/guix/current/bin/guix") In guix/ui.scm: 2164:12 11 (run-guix-command _ . _) In ice-9/boot-9.scm: 1736:10 10 (with-exception-handler _ _ #:unwind? _ # _) 1731:15 9 (with-exception-handler #<procedure 7f6dc61fc9f0 at ic?> ?) In srfi/srfi-1.scm: 634:9 8 (for-each #<procedure 7f6dc61ab800 at guix/scripts/lin?> ?) In guix/scripts/lint.scm: 65:4 7 (run-checkers #<package icecat@78.8.0-guix0-preview1 g?> ?) In srfi/srfi-1.scm: 634:9 6 (for-each #<procedure 7f6dbecd3300 at guix/scripts/lin?> ?) In guix/scripts/lint.scm: 74:21 5 (_ _) In guix/lint.scm: 1225:4 4 (check-archival _) 1092:2 3 (call-with-networking-fail-safe _ _ _) In ice-9/boot-9.scm: 1736:10 2 (with-exception-handler _ _ #:unwind? _ # _) 1669:16 1 (raise-exception _ #:continuable? _) 1667:16 0 (raise-exception _ #:continuable? _) ice-9/boot-9.scm:1667:16: In procedure raise-exception: In procedure bv-length: Wrong type argument in position 1 (expecting bytevector): #f ★★★★★★★★★★★★★★★ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Release 1.2.1: status 2021-03-19 22:26 ` Luis Felipe @ 2021-03-21 0:16 ` zimoun 2021-03-21 14:13 ` Luis Felipe 0 siblings, 1 reply; 16+ messages in thread From: zimoun @ 2021-03-21 0:16 UTC (permalink / raw) To: Luis Felipe; +Cc: Guix Devel Hi Luis, Thanks for testings and reporting. On Fri, 19 Mar 2021 at 22:26, Luis Felipe <luis.felipe.la@protonmail.com> wrote: > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Thursday, March 18, 2021 2:28 PM, zimoun <zimon.toutoune@gmail.com> wrote: > > [...] > >> We are still missing a good story to monitor what is archived on >> Software Heritage and what is not. Because for now there is rate limit, >> I am not able to automate… Well, it is a long WIP. :-) >> >> To help and avoid this rate limit, if all of us simply run: >> >> for pkg in $(guix package -I | cut -f1); >> do >> guix lint -c archival $pkg >> done >> >> for all our profiles, it will ensure at least a coverage for the >> packages using git-fetch that we individually care. Note the option >> --manifest for “guix lint” is missing… should happen soon if no one >> beats me. :-) > > I tried this with my user profile and the script hit the Software > heritage limit after reporting the status of 33 packages (most of > which are not archived). So, for the rest of the packages, you are > asked to try again later (I have 95 packages in my profile). There is 2 rate limit: one for saving and one for requesting. Each time you do “guix lint -c archival <foo>”, Guix requests to SWH via their API [1] if the package is already in. AFAIR, it is 120 requests per hour. Then if it is not, Guix saves to SWH via their API. And this rate is very low, maybe 10 per hour. Well, if I remember correctly. 1: <https://archive.softwareheritage.org/api/> > Is "guix lint -c archival $pkg" supposed to poke Software Heritage to > archive the $pkg if it is not archived yet? I ask because I ran the > script later and I got the same output from the first run, i.e., > packages reported to be missing from Software Heritage were still > reported as such, instead of being planned for archive. Currently, the request/save via “guix lint -c archival” is not optimal. For instance, the source of the package “libvirt“ is url-fetch so requesting for it is not necessary because it cannot be saved via their API. And I not remember exactly how the ‘tarball’ request is counted. BTW, the packages using ’url-fetch’ should be ingested by SWH via their nixguix loader reading the sources.json [2]. And for example: --8<---------------cut here---------------start------------->8--- $ guix lint -c archival libvirt gnu/packages/virtualization.scm:1070:5: libvirt@5.8.0: source not archived on Software Heritage $ guix download -H sha256 -f base64 https://libvirt.org/sources/libvirt-5.8.0.tar.xz Starting download of /tmp/guix-file.XWwdFj From https://libvirt.org/sources/libvirt-5.8.0.tar.xz... libvirt-5.8.0.tar.xz 12.5MiB 678KiB/s 00:19 [##################] 100.0% /gnu/store/1pgi1bl8p7jv2mhk83kv7raak2b4k1w5-libvirt-5.8.0.tar.xz 4jMoKJsYve3B6Wb2wmQCspgxScZg7YvVLNpv6rDCDFU= --8<---------------cut here---------------end--------------->8--- and in the same time, the sources.json contains: --8<---------------cut here---------------start------------->8--- { "type": "url", "urls": [ "https://libvirt.org/sources/libvirt-5.8.0.tar.xz" ], "integrity": "sha256-4jMoKJsYve3B6Wb2wmQCspgxScZg7YvVLNpv6rDCDFU=" }, --8<---------------cut here---------------end--------------->8--- Well, 2 possible explanations: 1) The tarball is not in SWH; because their loader fails on it or for whatever else reasons 2) Or the tarball is archived by SWH but they use another hashing (SWH-ID) than the NAR. Well, with the information in the package, Guix is not able to ask to SWH with the correct hash. That’s the main motivation behind disarchive [3]. Last, Guix is not able to deal with hg-fetch or svn-fetch. In this message [4] and the 2 follow-up in the thread, there is some explanation to implement ‘lookup-subversion-revision’ in (guix swh). Maybe for the next release on Nov. ;-) Well, the dance SWH needs some love. :-) Thanks for trying! It really helps to have this kind of feedback. 2: <http://guix.gnu.org/sources.json> 3: <https://git.ngyro.com/disarchive> 4: <http://issues.guix.gnu.org/43442#9> > Also, I got a backtrace when checking icecat: > > ★★★★★★★★★★★★★★★ > Backtrace:cecat@78.8.0-guix0-preview1 [archival]... [...] > ice-9/boot-9.scm:1667:16: In procedure raise-exception: > In procedure bv-length: Wrong type argument in position 1 (expecting bytevector): #f > ★★★★★★★★★★★★★★★ Indeed, there is a bug. Because the source of ’icecat’ raises a case that is not handled by ’check-archival’ in (guix lint). Basically in the snippet: --8<---------------cut here---------------start------------->8--- (match (lookup-content (content-hash-value hash) (symbol->string (content-hash-algorithm hash))) --8<---------------cut here---------------end--------------->8--- ’lookup-content’ expect a bytevector for ’content-hash’ and in the case of ’icecat’, it returns #f. Then raises the backtrace. Could you open a bug report for that? Just to not forget to fix it. :-) For the record, compare ’icecat’ with ’hello’: --8<---------------cut here---------------start------------->8--- $ guix repl GNU Guile 3.0.5 Copyright (C) 1995-2021 Free Software Foundation, Inc. Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'. This program is free software, and you are welcome to redistribute it under certain conditions; type `,show c' for details. Enter `,help' for help. scheme@(guix-user)> ,use(guix packages) scheme@(guix-user)> ,use(guix swh) scheme@(guix-user)> ,use(gnu packages gnuzilla) scheme@(guix-user)> (content-hash-value (origin-hash (package-source icecat))) $1 = #f scheme@(guix-user)> (lookup-content (content-hash-value (origin-hash (package-source icecat))) "sha256") ice-9/boot-9.scm:1669:16: In procedure raise-exception: In procedure bv-length: Wrong type argument in position 1 (expecting bytevector): #f Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue. scheme@(guix-user) [1]> ,q scheme@(guix-user)> ,use(gnu packages base) scheme@(guix-user)> (content-hash-value (origin-hash (package-source hello))) $3 = #vu8(49 224 102 19 122 150 38 118 232 159 105 209 182 83 130 222 149 167 239 125 145 75 140 185 86 244 30 167 46 15 81 107) scheme@(guix-user)> (lookup-content (content-hash-value (origin-hash (package-source hello))) "sha256") $2 = #<<content> checksums: (("sha1" . #vu8(247 190 191 111 156 98 162 41 94 136 159 102 224 92 233 191 174 217 172 227)) ("blake2s256" . #vu8(4 255 253 50 132 65 210 22 201 36 146 173 114 211 115 136 216 199 120 137 136 11 6 145 81 41 135 134 253 72 216 137)) ("sha1_git" . #vu8(202 230 179 60 195 63 170 253 45 107 216 108 107 66 115 249 51 140 105 194)) ("sha256" . #vu8(49 224 102 19 122 150 38 118 232 159 105 209 182 83 130 222 149 167 239 125 145 75 140 185 86 244 30 167 46 15 81 107))) data-url: "https://archive.softwareheritage.org/api/1/content/sha256:31e066137a962676e89f69d1b65382de95a7ef7d914b8cb956f41ea72e0f516b/raw/" file-type-url: "https://archive.softwareheritage.org/api/1/content/sha256:31e066137a962676e89f69d1b65382de95a7ef7d914b8cb956f41ea72e0f516b/filetype/" language-url: "https://archive.softwareheritage.org/api/1/content/sha256:31e066137a962676e89f69d1b65382de95a7ef7d914b8cb956f41ea72e0f516b/language/" length: 725946 license-url: "https://archive.softwareheritage.org/api/1/content/sha256:31e066137a962676e89f69d1b65382de95a7ef7d914b8cb956f41ea72e0f516b/license/"> --8<---------------cut here---------------end--------------->8--- Cheers, simon ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Release 1.2.1: status 2021-03-21 0:16 ` zimoun @ 2021-03-21 14:13 ` Luis Felipe 0 siblings, 0 replies; 16+ messages in thread From: Luis Felipe @ 2021-03-21 14:13 UTC (permalink / raw) To: zimoun; +Cc: Guix Devel Thanks for the details, zimoun. On Sunday, March 21, 2021 12:16 AM, zimoun <zimon.toutoune@gmail.com> wrote: [...] > > Also, I got a backtrace when checking icecat: > > ★★★★★★★★★★★★★★★ > > Backtrace:cecat@78.8.0-guix0-preview1 [archival]... > > [...] > > > ice-9/boot-9.scm:1667:16: In procedure raise-exception: > > In procedure bv-length: Wrong type argument in position 1 (expecting bytevector): #f > > ★★★★★★★★★★★★★★★ > > Indeed, there is a bug. Because the source of ’icecat’ raises a case > that is not handled by ’check-archival’ in (guix lint). [...] > Could you open > a bug report for that? Just to not forget to fix it. :-) Done: https://issues.guix.gnu.org/47293 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Release 1.2.1: status 2021-03-18 14:28 Release 1.2.1: status zimoun ` (2 preceding siblings ...) 2021-03-19 22:26 ` Luis Felipe @ 2021-03-20 20:01 ` Leo Famulari 2021-03-20 23:00 ` zimoun 3 siblings, 1 reply; 16+ messages in thread From: Leo Famulari @ 2021-03-20 20:01 UTC (permalink / raw) To: zimoun; +Cc: Guix Devel I suggest we use debbugs to keep track of tasks for the release. We can create a new bug called "1.2.1 release checklist". This bug can be made to depend on other bugs using the "block" feature of debbugs: https://debbugs.gnu.org/server-control.html Concretely, this means we send email to debbugs with messages like "block NNN with YYY", which means that NNN cannot be closed until YYY is closed. What do you think? Should I create a new bug ticket for this? ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Release 1.2.1: status 2021-03-20 20:01 ` Leo Famulari @ 2021-03-20 23:00 ` zimoun 2021-03-21 17:54 ` Leo Famulari 0 siblings, 1 reply; 16+ messages in thread From: zimoun @ 2021-03-20 23:00 UTC (permalink / raw) To: Leo Famulari; +Cc: Guix Devel Hi Leo, On Sat, 20 Mar 2021 at 16:01, Leo Famulari <leo@famulari.name> wrote: > I suggest we use debbugs to keep track of tasks for the release. > > We can create a new bug called "1.2.1 release checklist". > > This bug can be made to depend on other bugs using the "block" feature > of debbugs: > > https://debbugs.gnu.org/server-control.html > > Concretely, this means we send email to debbugs with messages like > "block NNN with YYY", which means that NNN cannot be closed until YYY is > closed. > > What do you think? Should I create a new bug ticket for this? We discussed that and I agree. We also discussed some tagging and Maxim did some tests, IIRC. Please go ahead and let try if it helps to synchronize. :-) Cheers, simon ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Release 1.2.1: status 2021-03-20 23:00 ` zimoun @ 2021-03-21 17:54 ` Leo Famulari 0 siblings, 0 replies; 16+ messages in thread From: Leo Famulari @ 2021-03-21 17:54 UTC (permalink / raw) To: zimoun; +Cc: Guix Devel On Sun, Mar 21, 2021 at 12:00:20AM +0100, zimoun wrote: > We discussed that and I agree. We also discussed some tagging and Maxim > did some tests, IIRC. Please go ahead and let try if it helps to > synchronize. :-) Here is the checklist: https://bugs.gnu.org/47297 I've added a few items, but everyone should add the other tasks they know about. ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2021-03-21 17:55 UTC | newest] Thread overview: 16+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2021-03-18 14:28 Release 1.2.1: status zimoun 2021-03-19 6:37 ` Chris Marusich 2021-03-19 8:27 ` Christopher Baines 2021-03-19 8:50 ` zimoun 2021-03-20 18:09 ` Leo Famulari 2021-03-20 22:56 ` zimoun 2021-03-20 23:21 ` Leo Famulari 2021-03-19 18:31 ` Andreas Enge 2021-03-19 21:59 ` Luis Felipe 2021-03-20 23:03 ` zimoun 2021-03-19 22:26 ` Luis Felipe 2021-03-21 0:16 ` zimoun 2021-03-21 14:13 ` Luis Felipe 2021-03-20 20:01 ` Leo Famulari 2021-03-20 23:00 ` zimoun 2021-03-21 17:54 ` Leo Famulari
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/guix.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).