Removing the attic package

Removing the attic package

[Leo Famulari]

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

Re: Removing the attic package

[ng0]

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

Re: Removing the attic package

[Leo Famulari]

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

Re: Removing the attic package

[Ludovic Courtès]

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’.

Re: Removing the attic package

[Ricardo Wurmus]

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

Re: Removing the attic package

[Efraim Flashner]

[-- 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 --]

Re: Removing the attic package

[ng0]

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

Re: Removing the attic package

[ng0]

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

Superseded packages

[Ludovic Courtès]

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’.

Re: Superseded packages

[Leo Famulari]

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?

Re: Superseded packages

[Ludovic Courtès]

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’.

Re: Superseded packages

[Leo Famulari]

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.

Re: Superseded packages

[Ludovic Courtès]

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’.

Re: Superseded packages

[Leo Famulari]

[-- 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 --]

Re: Superseded packages

[Ludovic Courtès]

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’.

Re: Superseded packages

[Leo Famulari]

[-- 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

Re: Superseded packages

[Efraim Flashner]

[-- 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 --]

Re: Superseded packages

[Leo Famulari]

[-- 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 --]

Re: Superseded packages

[Ludovic Courtès]

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’.

Re: Superseded packages

[Leo Famulari]

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!