Re: A real-life test of long-term reproducibility

Hi Konrad, Ludovic Courtès writes: > Konrad Hinsen skribis: > >> The package I want to rebuild and use is "nmoldyn" from Guix commit >> f250a868d8c687df08559682fa68fb4ea2a1ea69. That's the commit referenced >> in my notes, obtained via "guix describe" in early 2018. I am pretty >> sure it worke

Re: GNU Guix on iPad2 (A1395)

Hi Jacob, Jacob Hrbek writes: > The issue is that i can't get libusbmuxd (the daemon used to > communicate with iDevices from Linux) to work on GNU Guix likely due > to a configuration error in guix to perform the exploit and install > guix, can someone help? > https://github.com/libimobiledevic

Preservation of Guix (PoG) report 2023-03-13

b/Archive/DiffBind/ [3] https://bioconductor.org/packages/3.10/bioc/html/ggcyto.html That’s all for now. Enjoy the update and the script! -- Tim ;;; specification-to-swhids.scm ;;; Copyright © 2023 Timothy Sample ;;; ;;; This program is free software: you can redistribute it and/or modify ;;; it

Re: Disarchive database synchronization

Hey Ludo, Ludovic Courtès writes: > I copied over the 12K entries that were missing from > disarchive.guix.gnu.org. (Note that there are currently only two copies > of the database: one at/in [bB]erlin, and one at/in [Bb]ordeaux.) > disarchive.guix.gnu.org now weighs in at 1.8 GiB for 31,839 en

Re: Preservation of Guix (PoG) report 2023-03-13

Hey, Simon Tournier writes: > Well, I do not remember if you consider also the ’origin’ > (fixed-outputs) as ’inputs’ or ’patches’. Do you? I’m quite confident I’m getting everything. I’ll describe my approach, because I’m happy with it. :) The Guix package graph exists twice, essentially.

Re: Preservation of Guix (PoG) report 2023-03-13

Hi Ludo, Ludovic Courtès writes: > Do you think this could be turned into a Guix System service, with an > eye towards making it run on project infrastructure? I need to revisit what you did with Disarchive and Cuirass. The process for the PoG report is very similar. I can’t jump into it righ

Re: disarchive: disassemble then assemble tarball

Hi Simon, Simon Tournier writes: > Discussing in #62153 [1], it is noticed that Disarchive is not working > as expected. To be fair, Oleg is experimenting with reusing some internal Disarchive code in another context. That experiment didn’t go well, and Oleg came to a good (IMO) conclusion: tr

Re: Welcome to Simon as a new committer

Maxim Cournoyer writes: > I'd like to welcome Simon (aka zimoun) as a new committer. They have > made many contributions along the years, both in code and in community > management. For sure! Congrats, Simon, and thank you for all your hard work. :) -- Tim

Guix meetup at FOSSY?

Hi all, The first FOSSY (Free and Open Source Yearly) conference is coming up in two weeks! It’s being hosted in Portland, OR by the Software Freedom Conservancy. I was looking over the schedule and I spotted a few familiar names from the Guix community. Why don’t we plan a little Guix meetup?

Re: Guix meetup at FOSSY?

Vagrant Cascadian writes: > On 2023-06-29, Timothy Sample wrote: >> The first FOSSY (Free and Open Source [Software] Yearly) conference >> is coming up in two weeks! It’s being hosted in Portland, OR by the >> Software Freedom Conservancy. >> >> Why d

Re: Guix meetup at FOSSY?

Vagrant Cascadian writes: > On 2023-07-04, Timothy Sample wrote: > >> What about having a Guix lunch on Friday? I don’t really have strong >> feelings, but I thought I’d propose something concrete to get things >> going. I’ve never been to Portland, so I don’t have th

Re: Guix meetup at FOSSY?

Hi, Vagrant Cascadian writes: > My current best idea is the handful of food carts at pioneer courthouse > square, with a few different carts that cater to various dietary needs > and appetites... about 10-15 minutes on the MAX, with stops right at > both endpoints! This sounds great, but I just

Re: Adding GNAT/GCC-Ada to Guix

r Ada 95, too, but I can’t remember if it is freely licensed. It could be used to bridge the gap between Ada-Ed and old GNAT (maybe). -- Tim ;;; Copyright © 2018 Timothy Sample ;;; SPDX-License-Identifier: GPL-3.0-or-later (use-modules (gnu packages bootstrap) (gnu packages elf)

Re: Bump stackage LTS

Hi John, I’m just catching up on the list after a long hiatus, so sorry for the wait. John Soo writes: > Hi Guix, > > Stackage and ghc have moved quite a bit since our stackage and ghc > versions. Would it be ok to start work on bumping our package set to > a newer set of working packages and

Re: Bump stackage LTS

Hi, Timothy Sample writes: > AFAIK, we are OK to use the wip-haskell branch. I will reset it to > master and get started today or tomorrow. I just pushed GHC 8.8 to wip-haskell-updates, which I reset to core-updates. (I’m betting that core-updates will be merged before the Haskell u

Re: core-updates call for testing

Hi Marius, Marius Bakke writes: > The "core-updates" branch is ready for testing! [...] > > Please try upgrading your profiles and systems and file bugs for > anything that does not work for you. GNOME users in particular are > encouraged to try the new GNOME 3.34 and report any regressions.

Re: “Grafts, continued”

Hello, What an interesting read. Well done, Ludo! Nicolò Balzarotti writes: > Interesting blog post, thanks! > I found a typo: > /remove-eval/remote-eval/ Me too: s/more of hint/more of a hint/ -- Tim

Re: merge wip-haskell?

Hi John and Ricardo, John Soo writes: > I believe there was also some work being done to de-duplicate flags > sent to gcc sent by ghc (this was the only thing keeping stack from > building). > I hope that can make it in, too! I agree, and sorry to you John for the delay. I’m not using much Has

Re: merge wip-haskell?

Hi Ricardo, Ricardo Wurmus writes: > Timothy Sample writes: > >> Also, it looks like “wip-haskell-updates” is no longer being built by >> the CI infrastructure. Since the branch triggers a rebuild of all the >> Haskell packages, it should be built before merging, rig

Re: merge wip-haskell?

Hey Ricardo, Ricardo Wurmus writes: > Ricardo Wurmus writes: > >> Timothy Sample writes: >> >>> I just pushed “wip-haskell-updates-2” which integrates my work from >>> <https://issues.guix.gnu.org/39309>. I left the original branch intact >>&g

Re: merge wip-haskell?

Hi John, John Soo writes: > Does anyone know why idris, agda, and purescript are failing? The really short version is that we now use shared libraries for Haskell dependencies, which mostly works, except for some of the more complicated builds. I did fix Agda a little while ago, so I think it’

Re: merge wip-haskell?

Hi again, Timothy Sample writes: > I‘ll take a look at PureScript and check Elm, since maybe the Agda fix > will work for them. I’m not sure about Idris – it needs a bit more > effort. Good news! Elm and PureScript are fine, and I just pushed a fix

Re: Etymology of derivation

Hello, Ludovic Courtès writes: > Arun Isaac skribis: > >> The original Nix publication was helpful. On page 22 of the full thesis, >> it says: >> >> Derivation is Nix-speak for a component build action, which derives >> the component from its inputs. > > Not sure if it helps, but I struggled a

Re: Guile 2.0 in make-bootstrap.scm

Hi all, Jan Nieuwenhuizen writes: >> What’s surprising is that >> does use >> 2.2. > > Oh, that's weird. Well, we used gule-2.2 until almost the very last > moment, I remember. I am cc'ing Timothy, as he helped make the > guile-2.0 b

Re: wip-full-source-bootstrap: from a 357-byte `hex0' to 'hello'

Hi janneke, Jan Nieuwenhuizen writes: > I have reset Guix' wip-full-source-bootstrap branch with a first working > implementation of the, well, "Full Source Bootstrap" for x86-linux (and > x86_64-linux). This bootstrap is rooted in the 357-byte hex0-seed from > the Stage0 project (https://savan

Graft hooks

Hi Guix, I just submitted a patch for , but now I’m wondering if there isn’t a more general way to solve the problem. The bug has to do with grafting and checksums. I know three bugs that follow this theme: the one above (Racket), (GDB), a

Re: Graft hooks

l...@gnu.org (Ludovic Courtès) writes: > Hello Timothy, > > Timothy Sample skribis: > >> The basic idea would be to add a field (or use a property) to the >> package record. Let’s call it “graft-hook”. It would be Scheme code >> that gets run after grafting take

Re: Graft hooks

Hi Ludo, l...@gnu.org (Ludovic Courtès) writes: > Hello Timothy, > > Timothy Sample skribis: > >> l...@gnu.org (Ludovic Courtès) writes: >> >>> Hello Timothy, >>> >>> Timothy Sample skribis: >>> >>>> The basic idea would

Re: git-annex: problematic shebangs in .git/hooks/pre-commit?

Hi Kyle, Kyle Meyer writes: > Hello, > > Thanks for packaging git-annex, Tim! I'm excited to see it in Guix. You’re welcome! > I'm wondering whether the shebang patching in .git/hooks/pre-commit will > cause a problem. Using the patched shellPath_portable, 'git annex init' > generates a hook

Re: git-annex: problematic shebangs in .git/hooks/pre-commit?

Hi Kyle, Kyle Meyer writes: > Timothy Sample writes: > > [...] > >>> I'm wondering whether the shebang patching in .git/hooks/pre-commit >>> will >>> cause a problem. Using the patched shellPath_portable, 'git annex >>> init' &

Re: Help needed: Updating GHC to 8.4.3

Hi Ricardo, Ricardo Wurmus writes: > Hi Ludo, > >> Hello, >> >> Ricardo Wurmus skribis: >> >>> GHC 8.0 had been patched with >>> "ghc-dont-pass-linker-flags-via-response-files.patch" to avoid using >>> response files with the linker, because our ld-wrapper doesn’t seem to >>> behave right in so

Re: Help needed: Updating GHC to 8.4.3

Hi Again, I’ve attached an updated patch that builds a working GHC 8.4.3 (that is, it compiles “hello.hs” in a pure environment). It might need a bit more work yet. See notes below. Timothy Sample writes: > Hi Ricardo, > > Ricardo Wurmus writes: > >> Hi Ludo, >> &g

Re: Help needed: Updating GHC to 8.4.3

Hello, Timothy Sample writes: > Hi Again, > > I’ve attached an updated patch that builds a working GHC 8.4.3 (that is, > it compiles “hello.hs” in a pure environment). It might need a bit more > work yet. See notes below. It turns out that it wasn’t a pure environment. I was

Haskel LTS 12.8.

Hi Ricardo (and Guix), To avoid duplicating work, I wanted to let you know that I am working on updating the Haskell packages to their LTS 12.8 versions. This will go nicely with the new GHC 8.4.3. I am keeping the work on a WIP branch that I have here:

Re: Haskel LTS 12.8.

Hello, Ricardo Wurmus writes: > Hi Tim, > >> To avoid duplicating work, I wanted to let you know that I am working on >> updating the Haskell packages to their LTS 12.8 versions. This will go >> nicely with the new GHC 8.4.3. > > Excellent! I have a couple of new package definitions and a few

Re: Haskel LTS 12.8.

Hi Again, Timothy Sample writes: > Hello, > > Ricardo Wurmus writes: > >> Hi Tim, >> >>> To avoid duplicating work, I wanted to let you know that I am working on >>> updating the Haskell packages to their LTS 12.8 versions. This will go >>>

GHC 8.4.3

Hi all, Some of you may recall that I started work on updating all of our Haskell packages to their LTS 12 versions, and making sure they all build with GHC 8.4.3. I think this work is ready to be included now (on a WIP branch, at least). The commits exist at

Re: GHC 8.4.3

Hi Joe, Joe Hillenbrand writes: > I'm not a guix expert yet, so I looked at updating GHC and I got way > out of my depth real fast. > > I just wanted to say thanks. You are very welcome. >> Some of you may recall that I started work on updating all of our >> Haskell packages to their LTS 12 ve

Re: GHC 8.4.3

Hi, Ricardo Wurmus writes: > ghc-regex has had its last release in 2017, so this is an upstream > problem, I think. ghc-regex-tdfa-rc probably fails just because > ghc-regex cannot be built. The impression that I got is that ghc-regex-tdfa-rc was a prerelease package for ghc-regex-tdfa, and th

Re: cabal-install fail

Hi Brett, Brett Gilio writes: > Hi, all. I am attempting to install cabal-install to my guix > profile. I > am getting a build error. > > build of > /gnu/store/4rh26abgx8k0vkwsf57n4igp1mcrsfqg-cabal-install-1.22.6.0.drv > failed > > I tried to look at the build log indicated in the error, but it

Punch cards (was Preparing the reduced bootstrap tarballs)

Hi, Ricardo Wurmus writes: > jerem...@pdp10.guru writes: > >>> for the lazyer like me, what about a punched card? :-) >> If someone is willing to figure out how to read a deck of punched cards >> without software, I'd be interested in learning more. > > Now that’s a project for a free hardware d

Re: Preparing the reduced bootstrap tarballs

Hi Jan, Jan Nieuwenhuizen writes: > The plan is to have Guile and Gash initially replace all coreutils&co > and build them from source early in the bootstrap phase, right after > having built tcc and GNU make. We have managed to build GNU make > without any dependency on any of the tool you men

Re: Preparing the reduced bootstrap tarballs

Hi Jan, Jan Nieuwenhuizen writes: > Timothy Sample writes: > >> I wanted to let you know that I’ve been doing more work on the little >> Shell backend that we were talking about earlier. It’s kind of like the >> worse-is-better version of Gash: it is certai

Guile-JSON now seems to be a required dependency

Hello all, I just tried to build Guix from source and got an error: ERROR: no code for module (json) It looks like the new “swh.scm” module (which is really cool!) makes Guile-JSON a required dependency. I’m not sure if this is intentional. If it is, the “Requirements” section of the manual

Re: Guile-JSON now seems to be a required dependency

Hi Eric, Eric Bavier writes: > On Fri, 30 Nov 2018 23:45:04 -0500 > Timothy Sample wrote: > >> Hello all, >> >> I just tried to build Guix from source and got an error: >> >> ERROR: no code for module (json) >> >> It looks like the

Building Bash with Geesh

Hi Guix, Over the last year, I built Geesh , which is a simple Shell interpreter written in Guile Scheme. As of the other day, it is capable enough to build Bash! (That’s the main point of this message. Everything that follows is just details.) Geesh is very s

Re: Building Bash with Geesh

Hi Ludo, Ludovic Courtès writes: > ... > > Which parts of 2.2 that 2.0 lacks does it need? PEG? For Geesh, I think it is mostly just trivialities like “peek-char” vs. “lookahead-char”. I started adapting it once, and fixing one or two small things like that would make the front-end (lexer and

Re: Building Bash with Geesh

Hi Jan, Jan Nieuwenhuizen writes: > Timothy Sample writes: > > Hi Timothy! > > ... > > Just yesterday, I managed to build a minimal bash and make using Gash > and a very simple boot script, so without coreutils&co. A Scheme-only > bootstrap is coming closer...

Re: Building Bash with Geesh

Hi Jan, Jan Nieuwenhuizen writes: > Timothy Sample writes: > > Hello, > > Attached are two small patches that allow me to run the Gash test suite > with Geesh, like so > > PATH=$PATH:bin SHELL='../geesh/pre-inst-env geesh' ./check.sh > > assuming th

Gash and Geesh together at last

Hi Guix, I am very happy to announce that Gash and Geesh are merging into a single project. Jan and I discussed this earlier today, and decided that the time has come. We worked out a list of goodies from each project that we should be able to zip together into an even greater whole. (A quick b

New Gash build Bash without Bash, Coreutils, and a few others

Hi Guix, Here’s an update about bootstrapping for you. I am very pleased to announce that Gash (having absorbed Geesh) is now capable of building Bash without Bash, Coreutils, Grep, Sed, or Tar. That is, Gash provides alternatives, written in Scheme, to all the utilities needed by the “gnu-build-

GDM future work

Hi Guix, I have been using GDM on GuixSD for the past few days, and I am quite happy with it. A few patches that make it usable just landed on master. Now, there is a lot of room left for cleaning it up, but I need some advice. The main issue is the way that GDM launches the session bus (the in

Re: GDM future work

Hi Ludo, Ludovic Courtès writes: > [...] > > Option #2 looks reasonable to me (for the reasons you wrote, “static > binding” and all.) Thanks for confirming my intuition. > > [...] > >> Besides this, there are few straight-forward things to do. We need to >> make a “libgdm” package that does

Re: Packaging Jami (ex GNU Ring)

Hi Pierre, Pierre Neidhardt writes: > Hey, > > I'd like to package Jami. Has anyone given it a shot yet? I did some work on this about eight months ago, but wasn’t able to finish it. AFAIK, my work is the most recent and complete attempt. IIRC, I could install and run Ring, but it was not ent

Re: Packaging Jami (ex GNU Ring)

Hi Pierre, Pierre Neidhardt writes: > Hi Tim! > > Thanks for sharing! > Adonay Felipe Nogueira initial patch is now 2 years old, but it's already been > very helpful. > > I've noticed the thing about the ring-specific patches. I'm not sure but it > seems that beside pjproject, none of them are

Re: GNOME 3.30: help needed!

Hi Ricardo, Ricardo Wurmus writes: > [...] > > Now the only remaining question is: what files on my system cause this > failure to start GNOME? I’ll be playing with this some more and hope to > identify the files that are responsible, so that we can either work > around this or document it. Cu

Re: GDM future work

Hi Ludo, Ludovic Courtès writes: > Hello Timothy! > > Timothy Sample skribis: > >> It should be okay for testing as it is. It will not work unless >> “gnome-desktop-service” is included in your services. It does work with >> other window managers, but the sessio

Re: git-annex: problematic shebangs in .git/hooks/pre-commit?

Hi Kyle, Kyle Meyer writes: > Timothy Sample writes: > >> Kyle Meyer writes: > > [...] > >>> Perhaps I'm just missing something, but to spell out my concern a >>> little >>> more: I have /gnu/store/A/git-annex and /gnu/store/X/bash-min

Re: GDM update!

Hi Ludo, Ludovic Courtès writes: > Hello Guix! > > I’m happy to report that GDM basically works, including choosing among X > session… and it has a neat Guix theme! Woohoo! I like the background! I have some changes that are more-or-less ready. It’s mostly just cleaning up, but it makes it s

Re: GDM update!

Hi Danny, Danny Milosavljevic writes: > Hi Ludo, > > https://github.com/GNOME/gdm/commit/0bb8a777cfc0a3bc53c2c2830dd7e6e2baeeef38#diff-9b802b1ffb5f0ff95bfaa85046d262e7 > says: > >>custom is a magic name we used to allow for having the user decide >> their session by a ~/.xsession file. We no l

Re: Haskell dependencies for custom cabal builds

Hi John, John Soo writes: > Hi Guix, > > I’ve been working on some Haskell packages and got stuck recently and I > didn’t know why until I realized the cabal files have `build-type: Custom` > (http://hackage.haskell.org/package/termonad-1.1.0.0/termonad.cabal). I > always get missing dependenc

Re: GDM update!

Hi Ludo, Ludovic Courtès writes: > Hello! > > Timothy Sample skribis: > >> Maybe the GDM folks expect that we write a custom “.desktop” file that >> runs a custom script that checks for “~/.xsession” and runs it. It >> could use “TryExec” to figure out if “~/.

Re: Haskell dependencies for custom cabal builds

Hi John, John Soo writes: > I’ll check out git-annex as a start. Custom Cabal builds would be a > nice feature to add to the haskell-build-system. Would it be > sufficient to add some extra argument to the build system? At this point, I don’t know what the argument would do. :) The solution I

Re: Haskell dependencies for custom cabal builds

Hi John, John Soo writes: > Hi there, > > I did a little digging this morning and it seems like runhaskell is > probably deprecated in favor of runghc. Do we expect anyone to be > using hugs or jhc? Runghc also supports ghc flags. I still need to do > some more research here but the Haskell con

Re: GDM update!

Hi Pierre, Pierre Neidhardt writes: > While supporting Xsession and xinitrc is important for backward compatibility, > Guix could also have its own way with shepherd user services (see the recent > discussion on Guix-devel), which would supersede most "initialization > dotfiles". I agree, but

Re: Haskell dependencies for custom cabal builds

Hi John, John Soo writes: > Hi there, > > I did a little digging this morning and it seems like runhaskell is > probably deprecated in favor of runghc. Do we expect anyone to be > using hugs or jhc? Runghc also supports ghc flags. I still need to do > some more research here but the Haskell con

Upgrading packages with substitutes only (bug #26608)

Hi Guix, I’ve been using GuixSD for a couple of months now, and it is super cool. Thanks for all your hard work! There is one little thing, though. :) There’s a feature request (bug #26608) about adding an “--only-substitutes” flag to “guix package -u”, which would only upgrade packages that have

Re: Upgrading packages with substitutes only (bug #26608)

Leo Famulari writes: > On Sun, Jun 18, 2017 at 11:38:45AM +0200, Ricardo Wurmus wrote: >> >> Ludovic Courtès writes: >> >> > BTW, should --only-substitutes filter out packages without a substitute, >> > or should it simply stop and report the list of missing substitutes >> > (after which the u

Re: Upgrading packages with substitutes only (bug #26608)

l...@gnu.org (Ludovic Courtès) writes: > In the future I was also thinking that the build farm could tag Git > commits that it has fully built, and thus ‘guix pull’ could be told to > pull to the latest fully-built commit. I like this quite a bit. In fact, this is more in the spirit of what I wan

GDM status (again)

Hi Guix, Two months ago, Andy Wingo did a bunch of work on getting GDM working as a display manager for Guix [1]. Unfortunately, Andy had to step away from the task before getting everything working. I’ve been looking at this a bit, and have made some progress. Currently, GDM starts, lists users,

Re: GDM status (again)

Andy Wingo writes: >> Do we really need a compile-time dependency (GDM in master doesn’t >> depend on gnome-shell, after all), or can we just have a hard-coded >> /run/current-system/bin/gnome-shell somewhere? Granted, that’s not very >> elegant, but it might be good enough? >> >> Also, one can

Re: heads-up: Haskell updates

Ricardo Wurmus writes: > I think that’s a misunderstanding. The cause for the error is earlier > when it complains that some packages depend on different versions of the > “transformers” package. “StateT” is a monad transformer. For what it’s worth, I fixed this error on my machine by adding “

Re: heads-up: Haskell updates

Hi Ricardo, Ricardo Wurmus writes: > I have just rebuilt ghc-resourcet with a modified ghc-mtl, which I > suspect is the source of the problem, because it pulls in a newer > version of ghc-transformers. I’m going to push this to core-updates and > master in a moment. Based on your earlier sugg

Re: heads-up: Haskell updates

Ricardo Wurmus writes: >> Based on your earlier suggestion, I played around with removing all the >> packages that GHC provides. I made the same change to ghc-mtl on >> core-updates, and it allows me to build ghc-resourcet. > […] >> Is this too drastic? I could rebase on top of your ghc-mtl cha

Re: heads-up: Haskell updates

Hi Danny, Danny Milosavljevic writes: > I don't see where the diamond depenency is... GHC includes “transformers”, which is what most packages use, but “ghc-mtl” includes a different version (it has the same version number, so it is hard to see from the warnings). > But Timothy has a patchset

Re: Will 2021 be the year of build systems on gexps?

Hi Ludo, Ludovic Courtès writes: > So this is it, 2021 *is* the year of build systems on gexps! Wow! Congratulations! I am very happy to see this finally come together. > It’s crazy that it took 6 years (six!) to get past the finish line. I think I’ve only known what a gexp is for three yea

Re: Disarchive update

! I feel bad that I left you holding the bag on this one, though. Sorry. I’ve been a little adrift this summer. Thanks for picking it up! > Where to go from here? Timothy Sample had already set up a Disarchive > database at <https://disarchive.ngyro.com>, which (guix download) uses

Preservation of Guix Report

Hi everyone! Early this summer I did a bunch of work trying to figure out which Guix sources are preserved by the SWH archive. I’m finally ready to share some preliminary results! https://ngyro.com/pog-reports/2021-10-20/ This report is already quite outdated, though. It only covers commit

Re: Preservation of Guix Report

Hi again, Rereading this a few hours later, I found an error. Timothy Sample writes: > It’s surprising to me that SWH is not already getting these from > “sources.json”. I picked an arbitrary one, “rust-quote-0.6”, and it’s > simply not in “sources.json”. It is in fact there!

Re: Preservation of Guix Report

Hi zimoun, zimoun writes: > 2. For still unknown reasons, the bridge between SWH and Disarchive has > some holes. For instance, > > $ guix lint -c archive znc > gnu/packages/messaging.scm:996:12: znc@1.8.2: Disarchive entry refers > to non-existent SWH directory '33a3b509b

Re: Preservation of Guix Report

Hey, Ludovic Courtès writes: > Timothy Sample skribis: > >> Early this summer I did a bunch of work trying to figure out which Guix >> sources are preserved by the SWH archive. I’m finally ready to share >> some preliminary results! >> >> http

Re: Preservation of Guix Report

Hi again, Timothy Sample writes: > Yes, but I have another trick. The “known” endpoint [1]. If you > already know the SWHIDs you want to check, you can check 1,000 per call. > With the anonymous rate limit, I can check 120,000 every hour, which is > plenty. >

Preservation of Guix 2021-10-22

Hey all, As promised, here is the updated Preservation of Guix Report: https://ngyro.com/pog-reports/2021-10-22/ It takes into account the as yet unreleased Disarchive fix. The results are quite a bit better! Note especially that for the most recent commit, of the 72.8% that I could check,

Re: Preservation of Guix 2021-10-22

Hello, zimoun writes: > How can I get the list of these 376+217 packages? Because it appears to > me easy to send a save request for them. :_) Download the database (there’s a button at the bottom of the report), and use SQLite to run the following queries. For the 376: SELECT fod_id,

Re: Preservation of Guix 2021-10-22

Hi zimoun, zimoun writes: >>> How can I get the list of these 376+217 packages? Because it appears to >>> me easy to send a save request for them. :-) > > Done. :-) Nice! > I have not checked one per one but I guess the 217 are included in the > 376 ones. As I said earlier, many of them are

Re: Software Heritage fifth anniversary event

Ludovic Courtès writes: > I gave a 10–15mn talk on how Guix uses SWH, what Disarchive is, what > the current status of the “preservation of Guix” is, and what remains > to be done: > > > https://git.savannah.gnu.org/cgit/guix/maintenance.git/plain/talks/swh-unesco-2021/talk.20211130.pdf Wow –

Preservation of Guix Report 2021-11-30

Hi Guix! Here’s a new version of the Preservation of Guix Report: I actually made one a month ago but my message about it never made it to the list somehow. The most important part of that message was to highlight how well we are doing for Git sou

Re: Software Heritage fifth anniversary event

Hi, zimoun writes: > Timothy, could you provide again the entry point you use? https://docs.softwareheritage.org/devel/swh-web/uri-scheme-api.html#post--api-1-known- -- Tim

Re: Preservation of Guix Report 2021-11-30

Timothy Sample writes: > [W]e are starting to lose sources! If you look at the graph of > commits, you can see a sharp increase in missing sources for recent > commits. It looks like a problem on the SWH side. Visiting [1] and > selecting “Show all visits”, you can see that the ni

Re: [core-updates-frozen] Haskell for i686-linux: report

Hi, zimoun writes: > After some Cuirass monitoring and restarted some unexpected failures, > the situation for ghc-* on i686-linux is the same as the one from > current master. I took a few minutes to triage these. Most of them are fixable. > Two packages are broken in core-updates-frozen and

Re: How to compute SWHID? (with Guix/Disarchive)

Hi, Ludovic Courtès writes: > zimoun skribis: > >> Giving a look at Disarchive, I found how to compute Git-based >> serialization hash and somehow serialization methods of "guix hash" >> needs some clearning; considering '--recursive' is 'nar' serialization >> which is a better name. Anyway, s

Preservation of Guix Report 2021-12-06

Hi Guix, This is an update to the preservation of Guix report. There are no new commits or fixed-output derivations in this report, but I spent some time cleaning up the results, and I think the improvements are worth sharing. The last report generated a lot of questions. This one doesn’t answe

Re: core-updates-frozen branch merged

Hi Maxim, Maxim Cournoyer writes: > In case you hadn't taken notice, the core-update-frozen branch was > finally merged into master. So please reconfigure your remotes to avoid > uploading any further work there :-). > > [...] > > That's it! Enjoy the latest additions and improvements, and rep

Re: On raw strings in commit field

Hi all, Liliana Marie Prikler writes: > Am Freitag, dem 31.12.2021 um 20:41 -0500 schrieb Mark H Weaver: > >> If upstream later indicates that version "1.2.3" is now commit YYZ, I >> don't think that invalidates our basis for continuing to associate >> version "1.2.3" with commit XYZ.  The afore

Re: On raw strings in commit field

em 01.01.2022 um 12:45 -0500 schrieb Timothy Sample: > >> Given what I wrote above, maybe we could start by updating the linter >> so that ‘check-source’ actually checks that it gets the right result. >> Right now it uses a few heuristics to check that the result looks >> ok

Re: ImageMagick from 2020?

Hi zimoun, zimoun writes: > We probably do not have this item. Since it is 'xz', it is somehow > expected because it is works in progress. XZ support is working in Disarchive now. I’m hosting quite a few XZ specifications at . > Can someone confirm we do not eff

Preservation of Guix report 2022-01-16

Hi all, I’ve published a new preservation of Guix report: https://ngyro.com/pog-reports/latest/ Actually, the URL is , but I thought having a way to reference the latest report would be helpful. There’s no big news in the report. I’ve tracked down

Re: Preservation of Guix report 2022-01-16

Hi, Vagrant Cascadian writes: > On 2022-01-18, Ludovic Courtès wrote: >> Timothy Sample skribis: >>> A really important thing to do at this point is to verify that some >>> reasonable looking computation is covered by what we are doing already. >>> For ins

Re: ImageMagick from 2020?

Hey, zimoun writes: > On Wed, 19 Jan 2022 at 11:36, Ludovic Courtès wrote: > >> Oh right, so we’ll need to feed them historical ‘sources.json’ files >> eventually, I think Timothy was planning to do that eventually. > > From my side, what I would like to achieve soon: > > [...] > > Then what is

Re: missing patch for texlive-bin (e77412362f)

Hi zimoun, zimoun writes: > But the question is if Disarchive dissambles and preserves external > patches. Timothy? I have good news and bad news. :) The good news is that some versions of this patch are in the PoG database. There’s two versions of 0.76 and one of 0.72. Of those three, onl

  1   2   >