* Removing the attic package @ 2016-09-04 2:12 Leo Famulari 2016-09-04 13:10 ` ng0 0 siblings, 1 reply; 20+ messages in thread From: Leo Famulari @ 2016-09-04 2:12 UTC (permalink / raw) To: guix-devel The Attic backup program [0] has a serious problem, and I think we should consider removing our package of it. The problem is that Attic appears to be unmaintained since it was forked as "Borg". For almost 11 months, there has been no response from the Attic maintainer to a bug that unrecoverably corrupts the backup repository when the disk becomes full [1]. Of course, this situation is not acceptable for "backup" software. Debian has stopped packaging Attic in response [2]. At the very least, I think we should add a strong warning to the package description and synopsis. [0] https://attic-backup.org/ [1] https://github.com/jborg/attic/issues/356 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802619 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Removing the attic package 2016-09-04 2:12 Removing the attic package Leo Famulari @ 2016-09-04 13:10 ` ng0 2016-09-04 18:44 ` Leo Famulari 0 siblings, 1 reply; 20+ messages in thread From: ng0 @ 2016-09-04 13:10 UTC (permalink / raw) To: Leo Famulari, guix-devel Leo Famulari <leo@famulari.name> writes: > The Attic backup program [0] has a serious problem, and I think we > should consider removing our package of it. > > The problem is that Attic appears to be unmaintained since it was forked > as "Borg". For almost 11 months, there has been no response from the > Attic maintainer to a bug that unrecoverably corrupts the backup > repository when the disk becomes full [1]. Of course, this situation is > not acceptable for "backup" software. > > Debian has stopped packaging Attic in response [2]. > > At the very least, I think we should add a strong warning to the package > description and synopsis. > > [0] > https://attic-backup.org/ > > [1] > https://github.com/jborg/attic/issues/356 > > [2] > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802619 > There has been no update since 2015. Can the current status of the bug (solved? unsolved? wontfix? work in progress?) be requested from the upstream developer(s)? Otherwise the bug reads like we should include it in our package description, pointing out that it is currently limited to 15GB backup (if that's what this was about, I did not read all of it). -- ng0 For non-prism friendly talk find me on http://www.psyced.org ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Removing the attic package 2016-09-04 13:10 ` ng0 @ 2016-09-04 18:44 ` Leo Famulari 2016-09-05 8:20 ` Ludovic Courtès 0 siblings, 1 reply; 20+ messages in thread From: Leo Famulari @ 2016-09-04 18:44 UTC (permalink / raw) To: ng0; +Cc: guix-devel On Sun, Sep 04, 2016 at 01:10:39PM +0000, ng0 wrote: > There has been no update since 2015. Can the current status of the bug > (solved? unsolved? wontfix? work in progress?) be requested from the > upstream developer(s)? The upstream developer has not replied to the bug report [0]. I think we can assume "wontfix" after 11 months. > Otherwise the bug reads like we should include it in our package > description, pointing out that it is currently limited to 15GB backup > (if that's what this was about, I did not read all of it). The bug is that if your disk becomes full, the backup repository will be permanently corrupted, and you will *lose all your backups*. I think the project is abandoned, even though it has only been ~15 months since the last public commit, which is not really that long if the software is working well. But, it's not working well; this is a critical bug. Here is some context: I was following Attic development before it stopped. There were several Attic users who wanted to assist with Attic development, but the Attic author explicitly rejected their help [1]. It appears that the Attic author abandoned Attic after the Borg fork. I don't want to steer new users towards this broken software, and I think removing the package is a safe choice. Current Attic users could continue to use it, because it won't be removed from their profile unless they do `guix package --remove attic`. And Borg can convert Attic repos for users who are interested in moving on, so these users will not lose access to their data even if they do uninstall Attic on their machines. Do we have any guidelines about "retiring" packages? [0] https://github.com/jborg/attic/issues/356 [1] https://github.com/jborg/attic/issues/217#issuecomment-78091278 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Removing the attic package 2016-09-04 18:44 ` Leo Famulari @ 2016-09-05 8:20 ` Ludovic Courtès 2016-09-05 8:34 ` Ricardo Wurmus ` (2 more replies) 0 siblings, 3 replies; 20+ messages in thread From: Ludovic Courtès @ 2016-09-05 8:20 UTC (permalink / raw) To: Leo Famulari; +Cc: guix-devel Hi! Leo Famulari <leo@famulari.name> skribis: > I don't want to steer new users towards this broken software, and I > think removing the package is a safe choice. Current Attic users could > continue to use it, because it won't be removed from their profile > unless they do `guix package --remove attic`. Since, AIUI, Borg is a compatible “continuation” of Attic, it makes sense to remove Attic. I had an idea to use a ‘superseded’ entry in ‘properties’ that would tell ‘guix package’ et al. to upgrade to the new package: (package (name "attic") ;; … (properties `((superseded . ,borg)))) ENOSYS, though. > And Borg can convert Attic repos for users who are interested in > moving on, so these users will not lose access to their data even if > they do uninstall Attic on their machines. > > Do we have any guidelines about "retiring" packages? Not yet! Of course there’s a fine line here: we cannot systematically retire packages “just” because they have bugs (all of them do ;-)). So we have to be cautious. In this case, it can be considered a serious bug in the package’s core functionality, *and* there’s a fix provided by a fork, so I see no obstacle in removing it. What do people think? Thanks, Ludo’. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Removing the attic package 2016-09-05 8:20 ` Ludovic Courtès @ 2016-09-05 8:34 ` Ricardo Wurmus 2016-09-05 9:29 ` Efraim Flashner 2016-09-06 21:36 ` Superseded packages Ludovic Courtès 2 siblings, 0 replies; 20+ messages in thread From: Ricardo Wurmus @ 2016-09-05 8:34 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel Ludovic Courtès <ludo@gnu.org> writes: >> Do we have any guidelines about "retiring" packages? > > Not yet! > > Of course there’s a fine line here: we cannot systematically retire > packages “just” because they have bugs (all of them do ;-)). So we have > to be cautious. In this case, it can be considered a serious bug in the > package’s core functionality, *and* there’s a fix provided by a fork, so > I see no obstacle in removing it. This seems reasonable. ~~ Ricardo ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Removing the attic package 2016-09-05 8:20 ` Ludovic Courtès 2016-09-05 8:34 ` Ricardo Wurmus @ 2016-09-05 9:29 ` Efraim Flashner 2016-09-05 10:05 ` ng0 2016-09-06 21:36 ` Superseded packages Ludovic Courtès 2 siblings, 1 reply; 20+ messages in thread From: Efraim Flashner @ 2016-09-05 9:29 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel [-- Attachment #1: Type: text/plain, Size: 1609 bytes --] On Mon, Sep 05, 2016 at 10:20:36AM +0200, Ludovic Courtès wrote: > Hi! > > Leo Famulari <leo@famulari.name> skribis: > > > > > Do we have any guidelines about "retiring" packages? > > Not yet! > > Of course there’s a fine line here: we cannot systematically retire > packages “just” because they have bugs (all of them do ;-)). So we have > to be cautious. In this case, it can be considered a serious bug in the > package’s core functionality, *and* there’s a fix provided by a fork, so > I see no obstacle in removing it. > > What do people think? > > Thanks, > Ludo’. > I think it makes sense to change the description that this package is slated for eventual removal. Another example is pinentry. We now have 4 pinentry packages, and the original pinentry package just points to pinentry-gtk. I think it would make sense in that case to change the description to something like `the pinentry package in guix is depreciated, please remove it and install pinentry-gtk to retain the same functinality' or something along those lines. In this case something about attic having serious unpatched flaws, is unmaintained, and that borg is a fork & continuation of it, would be a good change. That might keep new people from installing it, but how would we get people who have already installed it to uninstall it? Or to see the message? -- Efraim Flashner <efraim@flashner.co.il> אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Removing the attic package 2016-09-05 9:29 ` Efraim Flashner @ 2016-09-05 10:05 ` ng0 2016-09-05 10:20 ` ng0 0 siblings, 1 reply; 20+ messages in thread From: ng0 @ 2016-09-05 10:05 UTC (permalink / raw) To: Efraim Flashner, Ludovic Courtès; +Cc: guix-devel Efraim Flashner <efraim@flashner.co.il> writes: > [ Unknown signature status ] > On Mon, Sep 05, 2016 at 10:20:36AM +0200, Ludovic Courtès wrote: >> Hi! >> >> Leo Famulari <leo@famulari.name> skribis: >> >> > >> > Do we have any guidelines about "retiring" packages? >> >> Not yet! >> >> Of course there’s a fine line here: we cannot systematically retire >> packages “just” because they have bugs (all of them do ;-)). So we have >> to be cautious. In this case, it can be considered a serious bug in the >> package’s core functionality, *and* there’s a fix provided by a fork, so >> I see no obstacle in removing it. >> >> What do people think? >> >> Thanks, >> Ludo’. >> > > I think it makes sense to change the description that this package is > slated for eventual removal. Another example is pinentry. We now have 4 > pinentry packages, and the original pinentry package just points to > pinentry-gtk. I think it would make sense in that case to change the > description to something like `the pinentry package in guix is > depreciated, please remove it and install pinentry-gtk to retain the > same functinality' or something along those lines. > > In this case something about attic having serious unpatched flaws, is > unmaintained, and that borg is a fork & continuation of it, would be a > good change. > > That might keep new people from installing it, but how would we get > people who have already installed it to uninstall it? Or to see the > message? Gentoo handles this via an internal message system which might or might not be connected to one of their email lists. This way they announce security upgrades, updates, removal notices, etc. Archlinux handles this via an announcement email list as far as I know. Maybe we could implement something similar, maybe file based? I could imagine an mbox/maildir message parser where we could commit message files into the (sub)directory and it gets posted to an announce-guix@gnu.org list AND is also made available via some way associated with the guix package list of current profile or in general via some guix args to be read by everyone, mandatory to keep on track with guix updates etc.. > -- > Efraim Flashner <efraim@flashner.co.il> אפרים פלשנר > GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 > Confidentiality cannot be guaranteed on emails sent or received unencrypted -- ng0 For non-prism friendly talk find me on http://www.psyced.org ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Removing the attic package 2016-09-05 10:05 ` ng0 @ 2016-09-05 10:20 ` ng0 0 siblings, 0 replies; 20+ messages in thread From: ng0 @ 2016-09-05 10:20 UTC (permalink / raw) To: Efraim Flashner, Ludovic Courtès; +Cc: guix-devel ng0 <ng0@we.make.ritual.n0.is> writes: > Efraim Flashner <efraim@flashner.co.il> writes: > >> [ Unknown signature status ] >> On Mon, Sep 05, 2016 at 10:20:36AM +0200, Ludovic Courtès wrote: >>> Hi! >>> >>> Leo Famulari <leo@famulari.name> skribis: >>> >>> > >>> > Do we have any guidelines about "retiring" packages? >>> >>> Not yet! >>> >>> Of course there’s a fine line here: we cannot systematically retire >>> packages “just” because they have bugs (all of them do ;-)). So we have >>> to be cautious. In this case, it can be considered a serious bug in the >>> package’s core functionality, *and* there’s a fix provided by a fork, so >>> I see no obstacle in removing it. >>> >>> What do people think? >>> >>> Thanks, >>> Ludo’. >>> >> >> I think it makes sense to change the description that this package is >> slated for eventual removal. Another example is pinentry. We now have 4 >> pinentry packages, and the original pinentry package just points to >> pinentry-gtk. I think it would make sense in that case to change the >> description to something like `the pinentry package in guix is >> depreciated, please remove it and install pinentry-gtk to retain the >> same functinality' or something along those lines. >> >> In this case something about attic having serious unpatched flaws, is >> unmaintained, and that borg is a fork & continuation of it, would be a >> good change. >> >> That might keep new people from installing it, but how would we get >> people who have already installed it to uninstall it? Or to see the >> message? > > Gentoo handles this via an internal message system which might or might > not be connected to one of their email lists. This way they announce > security upgrades, updates, removal notices, etc. Archlinux handles this > via an announcement email list as far as I know. Maybe we could > implement something similar, maybe file based? > > I could imagine an mbox/maildir message parser where we could commit > message files into the (sub)directory and it gets posted to an > announce-guix@gnu.org list AND is also made available via some way > associated with the guix package list of current profile or in general > via some guix args to be read by everyone, mandatory to keep on track > with guix updates etc.. Immediate solution with even less work: make it part of the website repository, which displays an rss feed "package news" or something like that. > >> -- >> Efraim Flashner <efraim@flashner.co.il> אפרים פלשנר >> GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 >> Confidentiality cannot be guaranteed on emails sent or received unencrypted > > -- > ng0 > For non-prism friendly talk find me on http://www.psyced.org > -- ng0 For non-prism friendly talk find me on http://www.psyced.org ^ permalink raw reply [flat|nested] 20+ messages in thread
* Superseded packages 2016-09-05 8:20 ` Ludovic Courtès 2016-09-05 8:34 ` Ricardo Wurmus 2016-09-05 9:29 ` Efraim Flashner @ 2016-09-06 21:36 ` Ludovic Courtès 2016-09-10 17:25 ` Leo Famulari 2 siblings, 1 reply; 20+ messages in thread From: Ludovic Courtès @ 2016-09-06 21:36 UTC (permalink / raw) To: Leo Famulari; +Cc: guix-devel Hi! ludo@gnu.org (Ludovic Courtès) skribis: > I had an idea to use a ‘superseded’ entry in ‘properties’ that would > tell ‘guix package’ et al. to upgrade to the new package: > > (package > (name "attic") > ;; … > (properties `((superseded . ,borg)))) This is now implemented both at the package lookup level and in ‘guix package -u’ (the code is in 01afdab89c6a91f4cd05d3c4f4ff95a0402703eb and an example is in 967cfd18f666f24ae9cbad14ea8e6921c10cba81): --8<---------------cut here---------------start------------->8--- $ ./pre-inst-env guix build paredit -n guix build: package 'paredit' has been superseded by 'emacs-paredit' The following derivation would be built: /gnu/store/ccrv0j30a7yfs2g1n14p0bh737bcjz0y-emacs-paredit-24.drv The following files would be downloaded: /gnu/store/732iy20nybnrf0kas8zyg3xs6fq30p4d-module-import /gnu/store/15hg2356x0jygwm3359mlxjiyhmls9wy-paredit-24.el /gnu/store/2a1bdv6sby9vsmhjzs1yw8bbhpxmiarh-module-import-compiled /gnu/store/x8w0fxa1w23fsa8x5m8wrvc8i83cxc6f-emacs-minimal-24.5 $ ./pre-inst-env guix package -u paredit -n guix package: package 'paredit' has been superseded by 'emacs-paredit' The following package would be removed: paredit 24 /gnu/store/d2dx7ba1ml4ykl3825df80h64dkqs21i-paredit-24 The following package would be installed: emacs-paredit 24 /gnu/store/nm927dpid524p5zdksga44xf78k3vpc0-emacs-paredit-24 The following derivations would be built: /gnu/store/7mphabn67n0kdl242d4nby34krsf7iba-profile.drv /gnu/store/w0aa524wr0y89pi5l9qj0gjdiwfy451i-info-dir.drv /gnu/store/nlvmpmfmgib6k3y357s391shf0qznx29-fonts-dir.drv /gnu/store/niqnq338ndnf0k2xacd53mwkk43nwycy-ca-certificate-bundle.drv /gnu/store/9a2677pzx58b9vilhn8gmkvlgms19vf1-gtk-icon-themes.drv /gnu/store/5h7lzi5dk4yh5yvx5zkm2hp911x2cgh8-xdg-mime-database.drv /gnu/store/ccrv0j30a7yfs2g1n14p0bh737bcjz0y-emacs-paredit-24.drv The following files would be downloaded: /gnu/store/sppd07krb4w0bbbwyykwg05dcjn9p2kd-module-import-compiled /gnu/store/732iy20nybnrf0kas8zyg3xs6fq30p4d-module-import /gnu/store/15hg2356x0jygwm3359mlxjiyhmls9wy-paredit-24.el /gnu/store/2a1bdv6sby9vsmhjzs1yw8bbhpxmiarh-module-import-compiled /gnu/store/x8w0fxa1w23fsa8x5m8wrvc8i83cxc6f-emacs-minimal-24.5 --8<---------------cut here---------------end--------------->8--- It is still possible to install/build a deprecated package if one insists: --8<---------------cut here---------------start------------->8--- $ ./pre-inst-env guix build -e '(@ (gnu packages emacs) paredit/old-name)' -n The following derivation would be built: /gnu/store/hl48ab4ifjq01id3xpaqv7q0fjdmlx8w-paredit-24.drv The following files would be downloaded: /gnu/store/732iy20nybnrf0kas8zyg3xs6fq30p4d-module-import /gnu/store/2a1bdv6sby9vsmhjzs1yw8bbhpxmiarh-module-import-compiled /gnu/store/x8w0fxa1w23fsa8x5m8wrvc8i83cxc6f-emacs-minimal-24.5 --8<---------------cut here---------------end--------------->8--- The downside of the current implementation of upgrades is that it is in (guix scripts package), so the Emacs UI does not benefit from it. I’d like to see if I can generalize it a bit and move it to (guix profiles). Comments welcome! Ludo’. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Superseded packages 2016-09-06 21:36 ` Superseded packages Ludovic Courtès @ 2016-09-10 17:25 ` Leo Famulari 2016-09-11 13:46 ` Ludovic Courtès 0 siblings, 1 reply; 20+ messages in thread From: Leo Famulari @ 2016-09-10 17:25 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel On Tue, Sep 06, 2016 at 11:36:32PM +0200, Ludovic Courtès wrote: > Hi! > > ludo@gnu.org (Ludovic Courtès) skribis: > > > I had an idea to use a ‘superseded’ entry in ‘properties’ that would > > tell ‘guix package’ et al. to upgrade to the new package: > > > > (package > > (name "attic") > > ;; … > > (properties `((superseded . ,borg)))) > > This is now implemented both at the package lookup level and in ‘guix > package -u’ (the code is in 01afdab89c6a91f4cd05d3c4f4ff95a0402703eb and > an example is in 967cfd18f666f24ae9cbad14ea8e6921c10cba81): This is nice :) In 56ab55d1df I used it to properly replace the old letsencrypt package with certbot. In this case, I had already made letsencrypt inherit from certbot some months ago. I wanted letsencrypt users to get the latest version of the software from the EFF team, and presumably users have since fixed the breakage caused by the executable name change. Now, their profiles will finally stop including a letsencrypt package as they upgrade, and I plan to remove the letsencrypt variable completely after a couple more certbot releases. I think using this mechanism is appropriate in this case because letsencrypt / certbot are from the same team. Basically it's the same software, with 's/letsencrypt/certbot/g' applied to the codebase. I'm not sure about Attic / Borg. Superseding attic will break automation, although I did that when I made letsencrypt inherit from certbot. Also, the authors are different. Advice? ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Superseded packages 2016-09-10 17:25 ` Leo Famulari @ 2016-09-11 13:46 ` Ludovic Courtès 2016-09-11 15:19 ` Leo Famulari 0 siblings, 1 reply; 20+ messages in thread From: Ludovic Courtès @ 2016-09-11 13:46 UTC (permalink / raw) To: Leo Famulari; +Cc: guix-devel Hello! Leo Famulari <leo@famulari.name> skribis: > On Tue, Sep 06, 2016 at 11:36:32PM +0200, Ludovic Courtès wrote: >> Hi! >> >> ludo@gnu.org (Ludovic Courtès) skribis: >> >> > I had an idea to use a ‘superseded’ entry in ‘properties’ that would >> > tell ‘guix package’ et al. to upgrade to the new package: >> > >> > (package >> > (name "attic") >> > ;; … >> > (properties `((superseded . ,borg)))) >> >> This is now implemented both at the package lookup level and in ‘guix >> package -u’ (the code is in 01afdab89c6a91f4cd05d3c4f4ff95a0402703eb and >> an example is in 967cfd18f666f24ae9cbad14ea8e6921c10cba81): > > This is nice :) > > In 56ab55d1df I used it to properly replace the old letsencrypt package > with certbot. > > In this case, I had already made letsencrypt inherit from certbot some > months ago. I wanted letsencrypt users to get the latest version of the > software from the EFF team, and presumably users have since fixed the > breakage caused by the executable name change. Now, their profiles will > finally stop including a letsencrypt package as they upgrade, and I plan > to remove the letsencrypt variable completely after a couple more > certbot releases. > > I think using this mechanism is appropriate in this case because > letsencrypt / certbot are from the same team. Basically it's the same > software, with 's/letsencrypt/certbot/g' applied to the codebase. This is definitely the target use case. > I'm not sure about Attic / Borg. Superseding attic will break > automation, although I did that when I made letsencrypt inherit from > certbot. Also, the authors are different. Advice? I would make Borg supersede Attic. However, if Borg does not provide, say, an ‘attic’ command, which would make it incompatible by default, we may want to change the Borg package to include such a command. WDYT? Ludo’. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Superseded packages 2016-09-11 13:46 ` Ludovic Courtès @ 2016-09-11 15:19 ` Leo Famulari 2016-09-11 20:39 ` Ludovic Courtès 0 siblings, 1 reply; 20+ messages in thread From: Leo Famulari @ 2016-09-11 15:19 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel On Sun, Sep 11, 2016 at 03:46:34PM +0200, Ludovic Courtès wrote: > > I'm not sure about Attic / Borg. Superseding attic will break > > automation, although I did that when I made letsencrypt inherit from > > certbot. Also, the authors are different. Advice? > > I would make Borg supersede Attic. However, if Borg does not provide, > say, an ‘attic’ command, which would make it incompatible by default, we > may want to change the Borg package to include such a command. There are other incompatibilities, for example in the repository format. Borg provides a `borg upgrade` tool that performs a one-way conversion of Attic repos to Borg repos. Just creating an 'attic -> borg' alias would not be enough; any automated backup scripts would still fail. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Superseded packages 2016-09-11 15:19 ` Leo Famulari @ 2016-09-11 20:39 ` Ludovic Courtès 2016-09-20 21:18 ` Leo Famulari 0 siblings, 1 reply; 20+ messages in thread From: Ludovic Courtès @ 2016-09-11 20:39 UTC (permalink / raw) To: Leo Famulari; +Cc: guix-devel Leo Famulari <leo@famulari.name> skribis: > On Sun, Sep 11, 2016 at 03:46:34PM +0200, Ludovic Courtès wrote: >> > I'm not sure about Attic / Borg. Superseding attic will break >> > automation, although I did that when I made letsencrypt inherit from >> > certbot. Also, the authors are different. Advice? >> >> I would make Borg supersede Attic. However, if Borg does not provide, >> say, an ‘attic’ command, which would make it incompatible by default, we >> may want to change the Borg package to include such a command. > > There are other incompatibilities, for example in the repository format. > Borg provides a `borg upgrade` tool that performs a one-way conversion > of Attic repos to Borg repos. Just creating an 'attic -> borg' alias > would not be enough; any automated backup scripts would still fail. Then I don’t know. Either we mark Attic as superseded by Borg anyway, or we need another mechanism to mark a package as “discouraged”? Ludo’. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Superseded packages 2016-09-11 20:39 ` Ludovic Courtès @ 2016-09-20 21:18 ` Leo Famulari 2016-09-24 2:14 ` Ludovic Courtès 0 siblings, 1 reply; 20+ messages in thread From: Leo Famulari @ 2016-09-20 21:18 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel [-- Attachment #1.1: Type: text/plain, Size: 753 bytes --] On Sun, Sep 11, 2016 at 10:39:08PM +0200, Ludovic Courtès wrote: > > There are other incompatibilities, for example in the repository format. > > Borg provides a `borg upgrade` tool that performs a one-way conversion > > of Attic repos to Borg repos. Just creating an 'attic -> borg' alias > > would not be enough; any automated backup scripts would still fail. > > Then I don’t know. Either we mark Attic as superseded by Borg anyway, > or we need another mechanism to mark a package as “discouraged”? I've attached a patch that marks Attic as superseded by Borg. I'd like to put it on core-updates. That way, we can mention it in the release notes of the next Guix release, and hopefully people will notice the change. WDYT? [-- Attachment #1.2: 0001-gnu-attic-Superseded-by-borg.patch --] [-- Type: text/plain, Size: 4207 bytes --] From 374f81963d3ba4ec4a5e48c12848032ca8085aaf Mon Sep 17 00:00:00 2001 From: Leo Famulari <leo@famulari.name> Date: Tue, 20 Sep 2016 16:59:59 -0400 Subject: [PATCH] gnu: attic: Superseded by borg. * gnu/packages/backup.scm (attic): Superseded by borg. * gnu/packages/python.scm (python-llfuse-0.41): Remove variable. --- gnu/packages/backup.scm | 47 +++++------------------------------------------ gnu/packages/python.scm | 16 ---------------- 2 files changed, 5 insertions(+), 58 deletions(-) diff --git a/gnu/packages/backup.scm b/gnu/packages/backup.scm index dcab95f..c5908c8 100644 --- a/gnu/packages/backup.scm +++ b/gnu/packages/backup.scm @@ -321,48 +321,6 @@ to a remote location, and only the differences will be transmitted. Finally, rdiff-backup is easy to use and settings have sensible defaults.") (license license:gpl2+))) -(define-public attic - (package - (name "attic") - (version "0.16") - (source (origin - (method url-fetch) - (uri (string-append - "https://pypi.python.org/packages/source/A/Attic/Attic-" - version ".tar.gz")) - (sha256 - (base32 - "0b5skd36r4c0915lwpkqg5hxm49gls9pprs1b7hc40910wlcsl36")))) - (build-system python-build-system) - (arguments - `(#:phases - (modify-phases %standard-phases - (add-before - 'build 'set-openssl-prefix - (lambda* (#:key inputs #:allow-other-keys) - (setenv "ATTIC_OPENSSL_PREFIX" (assoc-ref inputs "openssl")) - #t))))) - (inputs - `(("acl" ,acl) - ("openssl" ,openssl) - ("python-msgpack" ,python-msgpack) - - ;; Attic is probably incompatible with llfuse > 0.41. - ;; These links are to discussions of llfuse compatibility from - ;; the borg project. Borg is a recent fork of attic, and attic - ;; has not been updated since the fork, so it's likely that - ;; llfuse compatibility requirements are still the same. - ;; https://github.com/borgbackup/borg/issues/642 - ;; https://github.com/borgbackup/borg/issues/643 - ("python-llfuse" ,python-llfuse-0.41))) - (synopsis "Deduplicating backup program") - (description "Attic is a deduplicating backup program. The main goal of -Attic is to provide an efficient and secure way to backup data. The data -deduplication technique used makes Attic suitable for daily backups since only -changes are stored.") - (home-page "https://attic-backup.org/") - (license license:bsd-3))) - (define-public libchop (package (name "libchop") @@ -456,3 +414,8 @@ stored. The authenticated encryption technique makes it suitable for backups to not fully trusted targets. Borg is a fork of Attic.") (home-page "https://borgbackup.github.io/borgbackup/") (license license:bsd-3))) + +(define-public attic + (package (inherit borg) + (name "attic") + (properties `((superseded . ,borg))))) diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm index f6ea28d..557e1d6 100644 --- a/gnu/packages/python.scm +++ b/gnu/packages/python.scm @@ -5516,22 +5516,6 @@ should be stored on various operating systems.") (strip-python2-variant python-llfuse))) (propagated-inputs `(("python2-contextlib2" ,python2-contextlib2))))) -;; For attic-0.16 -(define-public python-llfuse-0.41 - (package (inherit python-llfuse) - (version "0.41.1") - (source (origin - (method url-fetch) - (uri (string-append - "https://bitbucket.org/nikratio/python-llfuse/downloads/" - "llfuse-" version ".tar.bz2")) - (sha256 - (base32 - "1imlqw9b73086y97izr036f58pgc5akv4ihc2rrf8j5h75jbrlaa")))) - ;; Python-LLFUSE < 0.42 includes underscore.js, which is MIT (expat) - ;; licensed. The rest of the package is licensed under LGPL2.0 or later. - (license (list license:expat license:lgpl2.0+)))) - (define-public python-msgpack (package (name "python-msgpack") -- 2.10.0 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: Superseded packages 2016-09-20 21:18 ` Leo Famulari @ 2016-09-24 2:14 ` Ludovic Courtès 2016-09-25 16:42 ` Leo Famulari 0 siblings, 1 reply; 20+ messages in thread From: Ludovic Courtès @ 2016-09-24 2:14 UTC (permalink / raw) To: Leo Famulari; +Cc: guix-devel Leo Famulari <leo@famulari.name> skribis: > On Sun, Sep 11, 2016 at 10:39:08PM +0200, Ludovic Courtès wrote: >> > There are other incompatibilities, for example in the repository format. >> > Borg provides a `borg upgrade` tool that performs a one-way conversion >> > of Attic repos to Borg repos. Just creating an 'attic -> borg' alias >> > would not be enough; any automated backup scripts would still fail. >> >> Then I don’t know. Either we mark Attic as superseded by Borg anyway, >> or we need another mechanism to mark a package as “discouraged”? > > I've attached a patch that marks Attic as superseded by Borg. I'd like > to put it on core-updates. That way, we can mention it in the release > notes of the next Guix release, and hopefully people will notice the > change. > > WDYT? I think it could even go to ‘master’, but yes, we should mention it in the next release notes. > From 374f81963d3ba4ec4a5e48c12848032ca8085aaf Mon Sep 17 00:00:00 2001 > From: Leo Famulari <leo@famulari.name> > Date: Tue, 20 Sep 2016 16:59:59 -0400 > Subject: [PATCH] gnu: attic: Superseded by borg. > > * gnu/packages/backup.scm (attic): Superseded by borg. > * gnu/packages/python.scm (python-llfuse-0.41): Remove variable. [...] > +(define-public attic > + (package (inherit borg) > + (name "attic") > + (properties `((superseded . ,borg))))) I was thinking that we could keep the ‘attic’ recipe as-is, only with this extra ‘properties’ field. That way, “guix package -u” and “guix package -i attic” would install Borg, but people who insist could still run: guix package -e '(@ (gnu packages backup) attic)' Thoughts? Anyway, feel free to push whichever sounds best to you! Thanks, Ludo’. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Superseded packages 2016-09-24 2:14 ` Ludovic Courtès @ 2016-09-25 16:42 ` Leo Famulari 2016-09-26 9:44 ` Efraim Flashner 2016-09-28 8:44 ` Ludovic Courtès 0 siblings, 2 replies; 20+ messages in thread From: Leo Famulari @ 2016-09-25 16:42 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel [-- Attachment #1: Type: text/plain, Size: 2341 bytes --] On Sat, Sep 24, 2016 at 11:14:41AM +0900, Ludovic Courtès wrote: > Leo Famulari <leo@famulari.name> skribis: > > +(define-public attic > > + (package (inherit borg) > > + (name "attic") > > + (properties `((superseded . ,borg))))) > > I was thinking that we could keep the ‘attic’ recipe as-is, only with > this extra ‘properties’ field. > > That way, “guix package -u” and “guix package -i attic” would install > Borg, but people who insist could still run: > > guix package -e '(@ (gnu packages backup) attic)' > > Thoughts? That's a much better idea than what I had proposed. I found that I had to move the attic package definition below borg's, or else the borg variable was unbound when building (gnu packages backup): ------ Compiling Scheme modules... LOAD (gnu packages backup) ;;; note: source file ./gnu/packages/backup.scm ;;; newer than compiled /home/leo/work/guix/gnu/packages/backup.go Backtrace: In ice-9/boot-9.scm: 2401: 19 [save-module-excursion #<procedure 135d800 at ice-9/boot-9.scm:4045:3 ()>] 4052: 18 [#<procedure 135d800 at ice-9/boot-9.scm:4045:3 ()>] 1724: 17 [%start-stack load-stack ...] 1729: 16 [#<procedure 13729c0 ()>] In unknown file: ?: 15 [primitive-load "/home/leo/work/guix/./build-aux/compile-all.scm"] In ice-9/eval.scm: 432: 14 [eval # #] In ice-9/boot-9.scm: 768: 13 [for-each #<procedure load-module-file (a)> ("gnu/packages/backup.scm")] 2864: 12 [resolve-interface (gnu packages backup) #:select ...] 2789: 11 [#<procedure 12ab540 at ice-9/boot-9.scm:2777:4 (name #:optional autoload version #:key ensure)> # ...] 3065: 10 [try-module-autoload (gnu packages backup) #f] 2401: 9 [save-module-excursion #<procedure 171c450 at ice-9/boot-9.scm:3066:17 ()>] 3085: 8 [#<procedure 171c450 at ice-9/boot-9.scm:3066:17 ()>] In unknown file: ?: 7 [primitive-load-path "gnu/packages/backup" ...] In ice-9/eval.scm: 432: 6 [eval # ()] 453: 5 [eval # ()] 411: 4 [eval # #] 387: 3 [eval # #] 387: 2 [eval # #] 393: 1 [eval # #] In unknown file: ?: 0 [memoize-variable-access! #<memoized borg> #<directory # 1736d80>] ERROR: In procedure memoize-variable-access!: ERROR: Unbound variable: borg ------ So the attached patch moves attic after borg and supersedes it. Is it expected that we have to shuffle the package definition around like this? [-- Attachment #2: 0001-gnu-attic-Superseded-by-borg.patch --] [-- Type: text/plain, Size: 4542 bytes --] From 43a18f5c9abb22454c564ac16b2c24bf2766c220 Mon Sep 17 00:00:00 2001 From: Leo Famulari <leo@famulari.name> Date: Fri, 23 Sep 2016 23:36:48 -0400 Subject: [PATCH] gnu: attic: Superseded by borg. * gnu/packages/backup.scm (attic)[properties]: New field. --- gnu/packages/backup.scm | 85 +++++++++++++++++++++++++------------------------ 1 file changed, 43 insertions(+), 42 deletions(-) diff --git a/gnu/packages/backup.scm b/gnu/packages/backup.scm index e77c4f2..c6f1321 100644 --- a/gnu/packages/backup.scm +++ b/gnu/packages/backup.scm @@ -358,48 +358,6 @@ to a remote location, and only the differences will be transmitted. Finally, rdiff-backup is easy to use and settings have sensible defaults.") (license license:gpl2+))) -(define-public attic - (package - (name "attic") - (version "0.16") - (source (origin - (method url-fetch) - (uri (string-append - "https://pypi.python.org/packages/source/A/Attic/Attic-" - version ".tar.gz")) - (sha256 - (base32 - "0b5skd36r4c0915lwpkqg5hxm49gls9pprs1b7hc40910wlcsl36")))) - (build-system python-build-system) - (arguments - `(#:phases - (modify-phases %standard-phases - (add-before - 'build 'set-openssl-prefix - (lambda* (#:key inputs #:allow-other-keys) - (setenv "ATTIC_OPENSSL_PREFIX" (assoc-ref inputs "openssl")) - #t))))) - (inputs - `(("acl" ,acl) - ("openssl" ,openssl) - ("python-msgpack" ,python-msgpack) - - ;; Attic is probably incompatible with llfuse > 0.41. - ;; These links are to discussions of llfuse compatibility from - ;; the borg project. Borg is a recent fork of attic, and attic - ;; has not been updated since the fork, so it's likely that - ;; llfuse compatibility requirements are still the same. - ;; https://github.com/borgbackup/borg/issues/642 - ;; https://github.com/borgbackup/borg/issues/643 - ("python-llfuse" ,python-llfuse-0.41))) - (synopsis "Deduplicating backup program") - (description "Attic is a deduplicating backup program. The main goal of -Attic is to provide an efficient and secure way to backup data. The data -deduplication technique used makes Attic suitable for daily backups since only -changes are stored.") - (home-page "https://attic-backup.org/") - (license license:bsd-3))) - (define-public libchop (package (name "libchop") @@ -497,3 +455,46 @@ stored. The authenticated encryption technique makes it suitable for backups to not fully trusted targets. Borg is a fork of Attic.") (home-page "https://borgbackup.github.io/borgbackup/") (license license:bsd-3))) + +(define-public attic + (package + (name "attic") + (version "0.16") + (source (origin + (method url-fetch) + (uri (string-append + "https://pypi.python.org/packages/source/A/Attic/Attic-" + version ".tar.gz")) + (sha256 + (base32 + "0b5skd36r4c0915lwpkqg5hxm49gls9pprs1b7hc40910wlcsl36")))) + (build-system python-build-system) + (arguments + `(#:phases + (modify-phases %standard-phases + (add-before + 'build 'set-openssl-prefix + (lambda* (#:key inputs #:allow-other-keys) + (setenv "ATTIC_OPENSSL_PREFIX" (assoc-ref inputs "openssl")) + #t))))) + (inputs + `(("acl" ,acl) + ("openssl" ,openssl) + ("python-msgpack" ,python-msgpack) + + ;; Attic is probably incompatible with llfuse > 0.41. + ;; These links are to discussions of llfuse compatibility from + ;; the borg project. Borg is a recent fork of attic, and attic + ;; has not been updated since the fork, so it's likely that + ;; llfuse compatibility requirements are still the same. + ;; https://github.com/borgbackup/borg/issues/642 + ;; https://github.com/borgbackup/borg/issues/643 + ("python-llfuse" ,python-llfuse-0.41))) + (synopsis "Deduplicating backup program") + (description "Attic is a deduplicating backup program. The main goal of +Attic is to provide an efficient and secure way to backup data. The data +deduplication technique used makes Attic suitable for daily backups since only +changes are stored.") + (home-page "https://attic-backup.org/") + (license license:bsd-3) + (properties `((superseded . ,borg))))) -- 2.10.0 ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: Superseded packages 2016-09-25 16:42 ` Leo Famulari @ 2016-09-26 9:44 ` Efraim Flashner 2016-09-27 21:39 ` Leo Famulari 2016-09-28 8:44 ` Ludovic Courtès 1 sibling, 1 reply; 20+ messages in thread From: Efraim Flashner @ 2016-09-26 9:44 UTC (permalink / raw) To: Leo Famulari; +Cc: guix-devel [-- Attachment #1: Type: text/plain, Size: 7799 bytes --] On Sun, Sep 25, 2016 at 12:42:08PM -0400, Leo Famulari wrote: > On Sat, Sep 24, 2016 at 11:14:41AM +0900, Ludovic Courtès wrote: > > Leo Famulari <leo@famulari.name> skribis: > > > +(define-public attic > > > + (package (inherit borg) > > > + (name "attic") > > > + (properties `((superseded . ,borg))))) > > > > I was thinking that we could keep the ‘attic’ recipe as-is, only with > > this extra ‘properties’ field. > > > > That way, “guix package -u” and “guix package -i attic” would install > > Borg, but people who insist could still run: > > > > guix package -e '(@ (gnu packages backup) attic)' > > > > Thoughts? > > That's a much better idea than what I had proposed. > > I found that I had to move the attic package definition below borg's, or > else the borg variable was unbound when building (gnu packages backup): > > ------ > Compiling Scheme modules... > LOAD (gnu packages backup) > ;;; note: source file ./gnu/packages/backup.scm > ;;; newer than compiled /home/leo/work/guix/gnu/packages/backup.go > Backtrace: > In ice-9/boot-9.scm: > 2401: 19 [save-module-excursion #<procedure 135d800 at ice-9/boot-9.scm:4045:3 ()>] > 4052: 18 [#<procedure 135d800 at ice-9/boot-9.scm:4045:3 ()>] > 1724: 17 [%start-stack load-stack ...] > 1729: 16 [#<procedure 13729c0 ()>] > In unknown file: > ?: 15 [primitive-load "/home/leo/work/guix/./build-aux/compile-all.scm"] > In ice-9/eval.scm: > 432: 14 [eval # #] > In ice-9/boot-9.scm: > 768: 13 [for-each #<procedure load-module-file (a)> ("gnu/packages/backup.scm")] > 2864: 12 [resolve-interface (gnu packages backup) #:select ...] > 2789: 11 [#<procedure 12ab540 at ice-9/boot-9.scm:2777:4 (name #:optional autoload version #:key ensure)> # ...] > 3065: 10 [try-module-autoload (gnu packages backup) #f] > 2401: 9 [save-module-excursion #<procedure 171c450 at ice-9/boot-9.scm:3066:17 ()>] > 3085: 8 [#<procedure 171c450 at ice-9/boot-9.scm:3066:17 ()>] > In unknown file: > ?: 7 [primitive-load-path "gnu/packages/backup" ...] > In ice-9/eval.scm: > 432: 6 [eval # ()] > 453: 5 [eval # ()] > 411: 4 [eval # #] > 387: 3 [eval # #] > 387: 2 [eval # #] > 393: 1 [eval # #] > In unknown file: > ?: 0 [memoize-variable-access! #<memoized borg> #<directory # 1736d80>] > > ERROR: In procedure memoize-variable-access!: > ERROR: Unbound variable: borg > ------ > > So the attached patch moves attic after borg and supersedes it. Is it > expected that we have to shuffle the package definition around like > this? > From 43a18f5c9abb22454c564ac16b2c24bf2766c220 Mon Sep 17 00:00:00 2001 > From: Leo Famulari <leo@famulari.name> > Date: Fri, 23 Sep 2016 23:36:48 -0400 > Subject: [PATCH] gnu: attic: Superseded by borg. > > * gnu/packages/backup.scm (attic)[properties]: New field. > --- > gnu/packages/backup.scm | 85 +++++++++++++++++++++++++------------------------ > 1 file changed, 43 insertions(+), 42 deletions(-) > > diff --git a/gnu/packages/backup.scm b/gnu/packages/backup.scm > index e77c4f2..c6f1321 100644 > --- a/gnu/packages/backup.scm > +++ b/gnu/packages/backup.scm > @@ -358,48 +358,6 @@ to a remote location, and only the differences will be transmitted. Finally, > rdiff-backup is easy to use and settings have sensible defaults.") > (license license:gpl2+))) > > -(define-public attic > - (package > - (name "attic") > - (version "0.16") > - (source (origin > - (method url-fetch) > - (uri (string-append > - "https://pypi.python.org/packages/source/A/Attic/Attic-" > - version ".tar.gz")) > - (sha256 > - (base32 > - "0b5skd36r4c0915lwpkqg5hxm49gls9pprs1b7hc40910wlcsl36")))) > - (build-system python-build-system) > - (arguments > - `(#:phases > - (modify-phases %standard-phases > - (add-before > - 'build 'set-openssl-prefix > - (lambda* (#:key inputs #:allow-other-keys) > - (setenv "ATTIC_OPENSSL_PREFIX" (assoc-ref inputs "openssl")) > - #t))))) > - (inputs > - `(("acl" ,acl) > - ("openssl" ,openssl) > - ("python-msgpack" ,python-msgpack) > - > - ;; Attic is probably incompatible with llfuse > 0.41. > - ;; These links are to discussions of llfuse compatibility from > - ;; the borg project. Borg is a recent fork of attic, and attic > - ;; has not been updated since the fork, so it's likely that > - ;; llfuse compatibility requirements are still the same. > - ;; https://github.com/borgbackup/borg/issues/642 > - ;; https://github.com/borgbackup/borg/issues/643 > - ("python-llfuse" ,python-llfuse-0.41))) > - (synopsis "Deduplicating backup program") > - (description "Attic is a deduplicating backup program. The main goal of > -Attic is to provide an efficient and secure way to backup data. The data > -deduplication technique used makes Attic suitable for daily backups since only > -changes are stored.") > - (home-page "https://attic-backup.org/") > - (license license:bsd-3))) > - > (define-public libchop > (package > (name "libchop") > @@ -497,3 +455,46 @@ stored. The authenticated encryption technique makes it suitable for backups > to not fully trusted targets. Borg is a fork of Attic.") > (home-page "https://borgbackup.github.io/borgbackup/") > (license license:bsd-3))) > + > +(define-public attic > + (package > + (name "attic") > + (version "0.16") > + (source (origin > + (method url-fetch) > + (uri (string-append > + "https://pypi.python.org/packages/source/A/Attic/Attic-" > + version ".tar.gz")) > + (sha256 > + (base32 > + "0b5skd36r4c0915lwpkqg5hxm49gls9pprs1b7hc40910wlcsl36")))) > + (build-system python-build-system) > + (arguments > + `(#:phases > + (modify-phases %standard-phases > + (add-before > + 'build 'set-openssl-prefix > + (lambda* (#:key inputs #:allow-other-keys) > + (setenv "ATTIC_OPENSSL_PREFIX" (assoc-ref inputs "openssl")) > + #t))))) > + (inputs > + `(("acl" ,acl) > + ("openssl" ,openssl) > + ("python-msgpack" ,python-msgpack) > + > + ;; Attic is probably incompatible with llfuse > 0.41. > + ;; These links are to discussions of llfuse compatibility from > + ;; the borg project. Borg is a recent fork of attic, and attic > + ;; has not been updated since the fork, so it's likely that > + ;; llfuse compatibility requirements are still the same. > + ;; https://github.com/borgbackup/borg/issues/642 > + ;; https://github.com/borgbackup/borg/issues/643 > + ("python-llfuse" ,python-llfuse-0.41))) > + (synopsis "Deduplicating backup program") > + (description "Attic is a deduplicating backup program. The main goal of > +Attic is to provide an efficient and secure way to backup data. The data > +deduplication technique used makes Attic suitable for daily backups since only > +changes are stored.") > + (home-page "https://attic-backup.org/") > + (license license:bsd-3) > + (properties `((superseded . ,borg))))) > -- > 2.10.0 > shot in the dark, what if you left it in place and added (properties `((superseded . ,(delay borg)))))) -- Efraim Flashner <efraim@flashner.co.il> אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Superseded packages 2016-09-26 9:44 ` Efraim Flashner @ 2016-09-27 21:39 ` Leo Famulari 0 siblings, 0 replies; 20+ messages in thread From: Leo Famulari @ 2016-09-27 21:39 UTC (permalink / raw) To: Efraim Flashner; +Cc: guix-devel [-- Attachment #1: Type: text/plain, Size: 2020 bytes --] On Mon, Sep 26, 2016 at 12:44:41PM +0300, Efraim Flashner wrote: > On Sun, Sep 25, 2016 at 12:42:08PM -0400, Leo Famulari wrote: > > I found that I had to move the attic package definition below borg's, or > > else the borg variable was unbound when building (gnu packages backup): > shot in the dark, what if you left it in place and added > (properties `((superseded . ,(delay borg)))))) A different failure: $ ./pre-inst-env guix build attic Backtrace: In ice-9/boot-9.scm: 157: 17 [catch #t #<catch-closure 1ad9980> ...] In unknown file: ?: 16 [apply-smob/1 #<catch-closure 1ad9980>] In ice-9/boot-9.scm: 63: 15 [call-with-prompt prompt0 ...] In ice-9/eval.scm: 432: 14 [eval # #] In ice-9/boot-9.scm: 2401: 13 [save-module-excursion #<procedure 1af6940 at ice-9/boot-9.scm:4045:3 ()>] 4050: 12 [#<procedure 1af6940 at ice-9/boot-9.scm:4045:3 ()>] 1724: 11 [%start-stack load-stack ...] 1729: 10 [#<procedure 1b0dea0 ()>] In unknown file: ?: 9 [primitive-load "/home/leo/work/guix/scripts/guix"] In guix/ui.scm: 1192: 8 [run-guix-command build "attic"] In ice-9/boot-9.scm: 157: 7 [catch srfi-34 #<procedure 267af20 at guix/ui.scm:423:2 ()> ...] 157: 6 [catch system-error ...] In guix/scripts/build.scm: 661: 5 [#<procedure 2844d20 at guix/scripts/build.scm:650:2 ()>] 626: 4 [options->derivations #<build-daemon 256.15 2845a80> (# # # # ...)] In srfi/srfi-1.scm: 646: 3 [append-map #<procedure 2670ba0 at guix/scripts/build.scm:556:14 (expr)> #] 578: 2 [map #<procedure 2670ba0 at guix/scripts/build.scm:556:14 (expr)> #] In guix/scripts/build.scm: 564: 1 [#<procedure 2670ba0 at guix/scripts/build.scm:556:14 (expr)> #] In gnu/packages.scm: 309: 0 [%find-package "attic" "attic" #f #:fallback? #f] gnu/packages.scm:309:5: In procedure %find-package: gnu/packages.scm:309:5: Throw to key `match-error' with args `("match" "no matching pattern" #<promise #<procedure 3578560 at gnu/packages/backup.scm:402:33 ()>>)'. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Superseded packages 2016-09-25 16:42 ` Leo Famulari 2016-09-26 9:44 ` Efraim Flashner @ 2016-09-28 8:44 ` Ludovic Courtès 2016-09-28 17:58 ` Leo Famulari 1 sibling, 1 reply; 20+ messages in thread From: Ludovic Courtès @ 2016-09-28 8:44 UTC (permalink / raw) To: Leo Famulari; +Cc: guix-devel Leo Famulari <leo@famulari.name> skribis: > On Sat, Sep 24, 2016 at 11:14:41AM +0900, Ludovic Courtès wrote: >> Leo Famulari <leo@famulari.name> skribis: >> > +(define-public attic >> > + (package (inherit borg) >> > + (name "attic") >> > + (properties `((superseded . ,borg))))) >> >> I was thinking that we could keep the ‘attic’ recipe as-is, only with >> this extra ‘properties’ field. >> >> That way, “guix package -u” and “guix package -i attic” would install >> Borg, but people who insist could still run: >> >> guix package -e '(@ (gnu packages backup) attic)' >> >> Thoughts? > > That's a much better idea than what I had proposed. > > I found that I had to move the attic package definition below borg's, or > else the borg variable was unbound when building (gnu packages backup): [...] > So the attached patch moves attic after borg and supersedes it. Is it > expected that we have to shuffle the package definition around like > this? Yes, because ‘properties’ are evaluated eagerly. We could change the ‘superseded’ property to always be a promise, as Efraim suggests; we’ll see later if that’s really necessary. The patch LGTM. Thank you! Ludo’. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Superseded packages 2016-09-28 8:44 ` Ludovic Courtès @ 2016-09-28 17:58 ` Leo Famulari 0 siblings, 0 replies; 20+ messages in thread From: Leo Famulari @ 2016-09-28 17:58 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel On Wed, Sep 28, 2016 at 10:44:26AM +0200, Ludovic Courtès wrote: > Leo Famulari <leo@famulari.name> skribis: > > So the attached patch moves attic after borg and supersedes it. Is it > > expected that we have to shuffle the package definition around like > > this? > > Yes, because ‘properties’ are evaluated eagerly. > > We could change the ‘superseded’ property to always be a promise, as > Efraim suggests; we’ll see later if that’s really necessary. > > The patch LGTM. Okay, pushed. Thanks for the details! ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2016-09-28 17:59 UTC | newest] Thread overview: 20+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-09-04 2:12 Removing the attic package Leo Famulari 2016-09-04 13:10 ` ng0 2016-09-04 18:44 ` Leo Famulari 2016-09-05 8:20 ` Ludovic Courtès 2016-09-05 8:34 ` Ricardo Wurmus 2016-09-05 9:29 ` Efraim Flashner 2016-09-05 10:05 ` ng0 2016-09-05 10:20 ` ng0 2016-09-06 21:36 ` Superseded packages Ludovic Courtès 2016-09-10 17:25 ` Leo Famulari 2016-09-11 13:46 ` Ludovic Courtès 2016-09-11 15:19 ` Leo Famulari 2016-09-11 20:39 ` Ludovic Courtès 2016-09-20 21:18 ` Leo Famulari 2016-09-24 2:14 ` Ludovic Courtès 2016-09-25 16:42 ` Leo Famulari 2016-09-26 9:44 ` Efraim Flashner 2016-09-27 21:39 ` Leo Famulari 2016-09-28 8:44 ` Ludovic Courtès 2016-09-28 17:58 ` 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).