From d190ffef52edc6307eed4920a1ae1fc90aa27f8e Mon Sep 17 00:00:00 2001 From: Distix listener Date: Sat, 20 Feb 2016 21:46:30 +0100 Subject: imported mails --- .../cur/.this-dir-not-empty/.empty/empty-file | 0 .../new/.this-dir-not-empty/.empty/empty-file | 0 .../Maildir/new/1456001187.M782655P8737Q40.hrun | 249 +++++++++++++++++++++ .../Maildir/new/1456001187.M838814P8737Q41.hrun | 249 +++++++++++++++++++++ .../tmp/.this-dir-not-empty/.empty/empty-file | 0 .../a5f48a2fdc2b4d8a81ecf85923430f48/ticket.yaml | 4 + 6 files changed, 502 insertions(+) create mode 100644 tickets/a5f48a2fdc2b4d8a81ecf85923430f48/Maildir/cur/.this-dir-not-empty/.empty/empty-file create mode 100644 tickets/a5f48a2fdc2b4d8a81ecf85923430f48/Maildir/new/.this-dir-not-empty/.empty/empty-file create mode 100644 tickets/a5f48a2fdc2b4d8a81ecf85923430f48/Maildir/new/1456001187.M782655P8737Q40.hrun create mode 100644 tickets/a5f48a2fdc2b4d8a81ecf85923430f48/Maildir/new/1456001187.M838814P8737Q41.hrun create mode 100644 tickets/a5f48a2fdc2b4d8a81ecf85923430f48/Maildir/tmp/.this-dir-not-empty/.empty/empty-file create mode 100644 tickets/a5f48a2fdc2b4d8a81ecf85923430f48/ticket.yaml (limited to 'tickets/a5f48a2fdc2b4d8a81ecf85923430f48') diff --git a/tickets/a5f48a2fdc2b4d8a81ecf85923430f48/Maildir/cur/.this-dir-not-empty/.empty/empty-file b/tickets/a5f48a2fdc2b4d8a81ecf85923430f48/Maildir/cur/.this-dir-not-empty/.empty/empty-file new file mode 100644 index 0000000..e69de29 diff --git a/tickets/a5f48a2fdc2b4d8a81ecf85923430f48/Maildir/new/.this-dir-not-empty/.empty/empty-file b/tickets/a5f48a2fdc2b4d8a81ecf85923430f48/Maildir/new/.this-dir-not-empty/.empty/empty-file new file mode 100644 index 0000000..e69de29 diff --git a/tickets/a5f48a2fdc2b4d8a81ecf85923430f48/Maildir/new/1456001187.M782655P8737Q40.hrun b/tickets/a5f48a2fdc2b4d8a81ecf85923430f48/Maildir/new/1456001187.M782655P8737Q40.hrun new file mode 100644 index 0000000..6abe669 --- /dev/null +++ b/tickets/a5f48a2fdc2b4d8a81ecf85923430f48/Maildir/new/1456001187.M782655P8737Q40.hrun @@ -0,0 +1,249 @@ +Return-Path: +X-Original-To: distix@pieni.net +Delivered-To: distix@pieni.net +Received: from bagpuss.pepperfish.net (bagpuss.pepperfish.net [148.251.8.16]) + (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) + (No client certificate requested) + by pieni.net (Postfix) with ESMTPS id B3A5F2139A + for ; Sun, 13 Dec 2015 22:33:53 +0100 (CET) +Received: from platypus.pepperfish.net (unknown [10.112.100.20]) + by bagpuss.pepperfish.net (Postfix) with ESMTP id 55F552DB; + Sun, 13 Dec 2015 21:33:53 +0000 (GMT) +Received: from ip6-localhost ([::1] helo=platypus.pepperfish.net) + by platypus.pepperfish.net with esmtp (Exim 4.80 #2 (Debian)) + id 1a8EHB-0006Dz-7q; Sun, 13 Dec 2015 21:33:53 +0000 +Received: from inmail0 ([10.112.100.10] helo=mx0.pepperfish.net) + by platypus.pepperfish.net with esmtp (Exim 4.80 #2 (Debian)) + id 1a8EH9-0006Dt-OB + for ; Sun, 13 Dec 2015 21:33:51 +0000 +Received: from pieni.net ([95.142.166.37] ident=postfix) + by mx0.pepperfish.net with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) + (Exim 4.80) (envelope-from ) id 1a8EH7-0004tw-DW + for obnam-dev@obnam.org; Sun, 13 Dec 2015 21:33:51 +0000 +Received: from exolobe1.liw.fi (unknown [82.129.76.156]) + (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) + (No client certificate requested) + by pieni.net (Postfix) with ESMTPSA id 8C4352139A + for ; Sun, 13 Dec 2015 22:33:42 +0100 (CET) +Received: from exolobe1.liw.fi (localhost [127.0.0.1]) + by exolobe1.liw.fi (Postfix) with ESMTPS id 1584A4037D + for ; Sun, 13 Dec 2015 22:33:42 +0100 (CET) +Date: Sun, 13 Dec 2015 22:33:41 +0100 +From: Lars Wirzenius +To: Obnam development +Message-ID: <20151213213341.GT2459@exolobe1.liw.fi> +MIME-Version: 1.0 +User-Agent: Mutt/1.5.23 (2014-03-12) +X-Spam-Score: -3.4 +X-Spam-Score-int: -33 +X-Spam-Bar: --- +X-Scanned-By: pepperfish.net, Sun, 13 Dec 2015 21:33:51 +0000 +X-Spam-Report: Content analysis details: (-3.4 points) + pts rule name description + ---- ---------------------- -------------------------------------------------- + -1.0 PPF_USER_AGENT_MUTT User-Agent: contains Mutt (Mutt isn't a spam + tool) -0.5 PPF_USER_AGENT User-Agent: exists + -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% + [score: 0.0000] +X-ACL-Warn: message may be spam +X-Scan-Signature: 2ed25ed186b4a4f6da12919af8e199bc +Subject: Obnam development status update +X-BeenThere: obnam-dev@obnam.org +X-Mailman-Version: 2.1.5 +Precedence: list +List-Id: Obnam development discussions +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +Content-Type: multipart/mixed; boundary="===============7182395716470202758==" +Mime-version: 1.0 +Sender: obnam-dev-bounces@obnam.org +Errors-To: obnam-dev-bounces@obnam.org + + +--===============7182395716470202758== +Content-Type: multipart/signed; micalg=pgp-sha256; + protocol="application/pgp-signature"; boundary="Nx8xdmI2KD3LNVVP" +Content-Disposition: inline + + +--Nx8xdmI2KD3LNVVP +Content-Type: text/plain; charset=iso-8859-1 +Content-Disposition: inline +Content-Transfer-Encoding: quoted-printable + +Hello, people interested in Obnam development. + +A brief status update on Obnam development. There's a request for help +at the end. + +For a long time now, I've mainly concentrated my Obnam development +time on FORMAT GREEN ALBATROSS[0]. with some bug fixing for other +parts of the code base. The green-albatross code is the new repository +format, which is intended to make Obnam much faster than currently, +using the "FORMAT 6" repositry format. For precise details, see the +the NEWS file and the git commit log. + +[0] Yes, that's a Charles Stross Laundry Files reference. + +Format 6 is based on copy-on-write B-trees using the Larch library. +Green-albatross is based on DIR objects that contain all the metadata +of a directory and its contents, but not its sub-directories. + +Would it be useful and welcome, if I wrote about my Obnam development +thoughts more often on obnam-dev, or would that be flooding the list +with too much traffic? I guess I could think out loud in my blog +instead. + +In September I got a grant from the FUUG Foundation, see [1], to buy a +computer for Obnam development. I bought a pile of parts, and +assembled it. It's the first computer I've assembled since 2009. I'll +be writing about the details of this in my blog, later on. Until this +computer, almost all Obnam development has been done on my personal +laptop, which has been somewhat limiting. For example, running +benchmarks meant that I couldn't usefully do much more at the same +time, so I tended to run benchmarks overnight, and that limited the +feedback, making progress slower. Also, I do not have terabytes of +free disk space on laptop. + +[1] http://blog.liw.fi/posts/fuug-grant/ + +Over northern hemisphere summer this year, I used some virtual +machines in the Bytemark BigV cloud, sponsored by Bytemark, which also +worked fine for bencharmking, but a dedicated machine works better. + +The new computer has sped up green albatross development quite nicely. +Results can be viewed at [2]. I've been running two simple benchmarks: +one with a million files, each 1 random byte, and one with a single +file of 10 GiB. The numbers have gone from about 2200 and 1400 +seconds, respectively, to about 1500 and 400 seconds, respectively. +The corresponding numbers for format 6 are about 9300 and 3600 +seconds. + +[2] http://benchmark.obnam.org/e2obbench-v2/html/ + +I'd like green-albatross to get a lot faster still, but this is now +fast enough that I've started running a secondary set of backups using +the green albatross format. + +There's still a lot to do, before the new repository format is ready +for production use. I know of the following: + +* The chunk index data structures, necessary for de-duplication and + for removing chunks that are no longer needed, are currently very + simplistic. They are one encoded as one big blob, and this needs to + be split up into smaller pieces of data that can be re-used across + updates, in a copy-on-write manner. Otherwise, each backup will + upload tens or hundreds of megabytes of mostly duplicate data. + +* Obnam currently doesn't do copy-on-write updates of the + green-albatross DIR objects. This means that a new DIR object is + created for each directory in live data, even if there's been no + changes from the previous backup. This causes further unnecessary + data to be uploaded for every backup. + +* The "obnam forget" operation for green-albatross doesn't actually + remove now-unnecessary chunks. Oops. + +* The FUSE filesystem doesn't do seeks very efficiently, as it needs + to read from the beginning of a file every time. This can be quite + slow. The fix is fairly easy: store the size of a chunk with the + reference to the chunk, and seeking can suddenly be done much + faster. + +* I'd like to add some more filesystem metadata about files that + format 6 doesn't support. + +* It would be nice for people be able to convert existing backups to a + new repository format. I'm sure green-albatross is not the last + repository format for Obnam, either. I'm thinking that something + conceptually similar to git's "fast-export" format would be good. In + other words, an interchange format to represent a backup repository + in a way that's independent of the repository format, and possibly + even independent of the backup program, in which case it could be + used to convert from, say, Obnam to Attic, Attic to bup, or + duplicity to rdiff-backup. + +* There is no "obnam fsck" for green-albatross yet. Someone should + write that. + +* A bunch more benchmarking is needed: different scenarios, and more + types of measurements. For example, I don't currently know how much + memory Obnam is using with green-albatross. Hopefully there's no + unpleasant surprises lurking there. + +So that's what's missing, as far as I currently know. There's a lot of +details and I'm probably not aware of everything that's still needed. + +Which brings me to a request for help: If you have the spare capacity +(CPU, memory, disk space, bandwidth, time), I'd really quite +appreciate if you could try the green-albatross repository format. +However, and I can't stress this enough, it is not stable, it is NOT +READY for production use, and the on-disk repository format WILL +CHANGE in ways that will force you to wipe a repository and back up +everything all over again. Also, see the bulleted list above for +things that aren't done yet. If you don't mind that, then create a new +backup using "--repository-format=3Dgreen-albatross". Everything else +should work as before, except the things that don't work at all yet. +Or the things that are buggy. + +If you do try, please report to obnam-dev, especially if you see any +problems, but also if you don't. + +If you want to do some Obnam hacking, the repository format conversion +and the fsck are the areas where I'd most urgently appreciate help. + +If you are not a developer, or can't take on such large projects, +another way to help is to be on the obnam-support mailing list and +answer questions from people. There aren't that many, but even so the +take time from me that I might otherwise use for writing code for +Obnam. + +Thank you, and happy backups for everyone. + +--=20 +Schr=F6dinger's backup hypothesis: the condition of any backup is +undefined until a restore is attempted. -- andrewsh + +--Nx8xdmI2KD3LNVVP +Content-Type: application/pgp-signature; name="signature.asc" +Content-Description: Digital signature + +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v1 + +iQIcBAEBCAAGBQJWbeQ0AAoJEGwvphbseiAxcj8QAIv4jxqlfVLKVpT80Cc49t/g +5ot4VTj0MBzxwy8D7efApvciEu0U7W5JKTxo4tYuSIjqhjQR4ShvVg2OYqOlaeck +6W8w2vrXCdYEDySCSIA64RC7g9kjXewjWq/2+EUWzkMmB72mg7p2gNBvQBWem0Ea +6v+M1W7R28hUV2oCFgEKgR5u/BQ24aWWvtMSarFK9qsxfA5HAl/Cj2W3lUNCH8J9 +yIrHv9sVzHAI2X/mpIaFjH+4QK5lkCXrBCflRkX1tG1GRpfHShNrfNEb9ASqTNMJ +LMtE1A8/LJnG5ZY6NfN1dT2u97KptCcRTnQJj+m/D9AAQPFy1cgzJE1kG0n2mIdF +Ko8vLlOiC1fEt37KcBRjPUmkEysrDtsshpAN+EfOVJH/8jV8UX3SPpBEgWA6aodk +07ZHsnOjEdZVDCt0CDFbTNbDvoXn3b77pYkDrRBz8QzZYJudcA7ainBIRV94tXfg +FfTnna6A1ieoB/F8re2asXwpiyzUxj4bB170ZHhDWr8U1LXRDKjygv0NCVmLStBI +EH/Iqd3SdrQqCO+QdLPPxNni5vlqBvwAp8QJG0Aql0k5td07XrGJBFH71fOGCvVP +/EgM9EYL1BIj/8YQ3Bh6KIh3g+qZZxopI3g+D3wj0TcE19C+Jxz2Jpi6aT2Qxhkn +jXdngj+wVXCSDLYiUwi5 +=JgOm +-----END PGP SIGNATURE----- + +--Nx8xdmI2KD3LNVVP-- + + +--===============7182395716470202758== +Content-Type: text/plain; charset="us-ascii" +MIME-Version: 1.0 +Content-Transfer-Encoding: 7bit +Content-Disposition: inline + +_______________________________________________ +obnam-dev mailing list +obnam-dev@obnam.org +http://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/obnam-dev-obnam.org + +--===============7182395716470202758==-- + diff --git a/tickets/a5f48a2fdc2b4d8a81ecf85923430f48/Maildir/new/1456001187.M838814P8737Q41.hrun b/tickets/a5f48a2fdc2b4d8a81ecf85923430f48/Maildir/new/1456001187.M838814P8737Q41.hrun new file mode 100644 index 0000000..6abe669 --- /dev/null +++ b/tickets/a5f48a2fdc2b4d8a81ecf85923430f48/Maildir/new/1456001187.M838814P8737Q41.hrun @@ -0,0 +1,249 @@ +Return-Path: +X-Original-To: distix@pieni.net +Delivered-To: distix@pieni.net +Received: from bagpuss.pepperfish.net (bagpuss.pepperfish.net [148.251.8.16]) + (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) + (No client certificate requested) + by pieni.net (Postfix) with ESMTPS id B3A5F2139A + for ; Sun, 13 Dec 2015 22:33:53 +0100 (CET) +Received: from platypus.pepperfish.net (unknown [10.112.100.20]) + by bagpuss.pepperfish.net (Postfix) with ESMTP id 55F552DB; + Sun, 13 Dec 2015 21:33:53 +0000 (GMT) +Received: from ip6-localhost ([::1] helo=platypus.pepperfish.net) + by platypus.pepperfish.net with esmtp (Exim 4.80 #2 (Debian)) + id 1a8EHB-0006Dz-7q; Sun, 13 Dec 2015 21:33:53 +0000 +Received: from inmail0 ([10.112.100.10] helo=mx0.pepperfish.net) + by platypus.pepperfish.net with esmtp (Exim 4.80 #2 (Debian)) + id 1a8EH9-0006Dt-OB + for ; Sun, 13 Dec 2015 21:33:51 +0000 +Received: from pieni.net ([95.142.166.37] ident=postfix) + by mx0.pepperfish.net with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) + (Exim 4.80) (envelope-from ) id 1a8EH7-0004tw-DW + for obnam-dev@obnam.org; Sun, 13 Dec 2015 21:33:51 +0000 +Received: from exolobe1.liw.fi (unknown [82.129.76.156]) + (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) + (No client certificate requested) + by pieni.net (Postfix) with ESMTPSA id 8C4352139A + for ; Sun, 13 Dec 2015 22:33:42 +0100 (CET) +Received: from exolobe1.liw.fi (localhost [127.0.0.1]) + by exolobe1.liw.fi (Postfix) with ESMTPS id 1584A4037D + for ; Sun, 13 Dec 2015 22:33:42 +0100 (CET) +Date: Sun, 13 Dec 2015 22:33:41 +0100 +From: Lars Wirzenius +To: Obnam development +Message-ID: <20151213213341.GT2459@exolobe1.liw.fi> +MIME-Version: 1.0 +User-Agent: Mutt/1.5.23 (2014-03-12) +X-Spam-Score: -3.4 +X-Spam-Score-int: -33 +X-Spam-Bar: --- +X-Scanned-By: pepperfish.net, Sun, 13 Dec 2015 21:33:51 +0000 +X-Spam-Report: Content analysis details: (-3.4 points) + pts rule name description + ---- ---------------------- -------------------------------------------------- + -1.0 PPF_USER_AGENT_MUTT User-Agent: contains Mutt (Mutt isn't a spam + tool) -0.5 PPF_USER_AGENT User-Agent: exists + -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% + [score: 0.0000] +X-ACL-Warn: message may be spam +X-Scan-Signature: 2ed25ed186b4a4f6da12919af8e199bc +Subject: Obnam development status update +X-BeenThere: obnam-dev@obnam.org +X-Mailman-Version: 2.1.5 +Precedence: list +List-Id: Obnam development discussions +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +Content-Type: multipart/mixed; boundary="===============7182395716470202758==" +Mime-version: 1.0 +Sender: obnam-dev-bounces@obnam.org +Errors-To: obnam-dev-bounces@obnam.org + + +--===============7182395716470202758== +Content-Type: multipart/signed; micalg=pgp-sha256; + protocol="application/pgp-signature"; boundary="Nx8xdmI2KD3LNVVP" +Content-Disposition: inline + + +--Nx8xdmI2KD3LNVVP +Content-Type: text/plain; charset=iso-8859-1 +Content-Disposition: inline +Content-Transfer-Encoding: quoted-printable + +Hello, people interested in Obnam development. + +A brief status update on Obnam development. There's a request for help +at the end. + +For a long time now, I've mainly concentrated my Obnam development +time on FORMAT GREEN ALBATROSS[0]. with some bug fixing for other +parts of the code base. The green-albatross code is the new repository +format, which is intended to make Obnam much faster than currently, +using the "FORMAT 6" repositry format. For precise details, see the +the NEWS file and the git commit log. + +[0] Yes, that's a Charles Stross Laundry Files reference. + +Format 6 is based on copy-on-write B-trees using the Larch library. +Green-albatross is based on DIR objects that contain all the metadata +of a directory and its contents, but not its sub-directories. + +Would it be useful and welcome, if I wrote about my Obnam development +thoughts more often on obnam-dev, or would that be flooding the list +with too much traffic? I guess I could think out loud in my blog +instead. + +In September I got a grant from the FUUG Foundation, see [1], to buy a +computer for Obnam development. I bought a pile of parts, and +assembled it. It's the first computer I've assembled since 2009. I'll +be writing about the details of this in my blog, later on. Until this +computer, almost all Obnam development has been done on my personal +laptop, which has been somewhat limiting. For example, running +benchmarks meant that I couldn't usefully do much more at the same +time, so I tended to run benchmarks overnight, and that limited the +feedback, making progress slower. Also, I do not have terabytes of +free disk space on laptop. + +[1] http://blog.liw.fi/posts/fuug-grant/ + +Over northern hemisphere summer this year, I used some virtual +machines in the Bytemark BigV cloud, sponsored by Bytemark, which also +worked fine for bencharmking, but a dedicated machine works better. + +The new computer has sped up green albatross development quite nicely. +Results can be viewed at [2]. I've been running two simple benchmarks: +one with a million files, each 1 random byte, and one with a single +file of 10 GiB. The numbers have gone from about 2200 and 1400 +seconds, respectively, to about 1500 and 400 seconds, respectively. +The corresponding numbers for format 6 are about 9300 and 3600 +seconds. + +[2] http://benchmark.obnam.org/e2obbench-v2/html/ + +I'd like green-albatross to get a lot faster still, but this is now +fast enough that I've started running a secondary set of backups using +the green albatross format. + +There's still a lot to do, before the new repository format is ready +for production use. I know of the following: + +* The chunk index data structures, necessary for de-duplication and + for removing chunks that are no longer needed, are currently very + simplistic. They are one encoded as one big blob, and this needs to + be split up into smaller pieces of data that can be re-used across + updates, in a copy-on-write manner. Otherwise, each backup will + upload tens or hundreds of megabytes of mostly duplicate data. + +* Obnam currently doesn't do copy-on-write updates of the + green-albatross DIR objects. This means that a new DIR object is + created for each directory in live data, even if there's been no + changes from the previous backup. This causes further unnecessary + data to be uploaded for every backup. + +* The "obnam forget" operation for green-albatross doesn't actually + remove now-unnecessary chunks. Oops. + +* The FUSE filesystem doesn't do seeks very efficiently, as it needs + to read from the beginning of a file every time. This can be quite + slow. The fix is fairly easy: store the size of a chunk with the + reference to the chunk, and seeking can suddenly be done much + faster. + +* I'd like to add some more filesystem metadata about files that + format 6 doesn't support. + +* It would be nice for people be able to convert existing backups to a + new repository format. I'm sure green-albatross is not the last + repository format for Obnam, either. I'm thinking that something + conceptually similar to git's "fast-export" format would be good. In + other words, an interchange format to represent a backup repository + in a way that's independent of the repository format, and possibly + even independent of the backup program, in which case it could be + used to convert from, say, Obnam to Attic, Attic to bup, or + duplicity to rdiff-backup. + +* There is no "obnam fsck" for green-albatross yet. Someone should + write that. + +* A bunch more benchmarking is needed: different scenarios, and more + types of measurements. For example, I don't currently know how much + memory Obnam is using with green-albatross. Hopefully there's no + unpleasant surprises lurking there. + +So that's what's missing, as far as I currently know. There's a lot of +details and I'm probably not aware of everything that's still needed. + +Which brings me to a request for help: If you have the spare capacity +(CPU, memory, disk space, bandwidth, time), I'd really quite +appreciate if you could try the green-albatross repository format. +However, and I can't stress this enough, it is not stable, it is NOT +READY for production use, and the on-disk repository format WILL +CHANGE in ways that will force you to wipe a repository and back up +everything all over again. Also, see the bulleted list above for +things that aren't done yet. If you don't mind that, then create a new +backup using "--repository-format=3Dgreen-albatross". Everything else +should work as before, except the things that don't work at all yet. +Or the things that are buggy. + +If you do try, please report to obnam-dev, especially if you see any +problems, but also if you don't. + +If you want to do some Obnam hacking, the repository format conversion +and the fsck are the areas where I'd most urgently appreciate help. + +If you are not a developer, or can't take on such large projects, +another way to help is to be on the obnam-support mailing list and +answer questions from people. There aren't that many, but even so the +take time from me that I might otherwise use for writing code for +Obnam. + +Thank you, and happy backups for everyone. + +--=20 +Schr=F6dinger's backup hypothesis: the condition of any backup is +undefined until a restore is attempted. -- andrewsh + +--Nx8xdmI2KD3LNVVP +Content-Type: application/pgp-signature; name="signature.asc" +Content-Description: Digital signature + +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v1 + +iQIcBAEBCAAGBQJWbeQ0AAoJEGwvphbseiAxcj8QAIv4jxqlfVLKVpT80Cc49t/g +5ot4VTj0MBzxwy8D7efApvciEu0U7W5JKTxo4tYuSIjqhjQR4ShvVg2OYqOlaeck +6W8w2vrXCdYEDySCSIA64RC7g9kjXewjWq/2+EUWzkMmB72mg7p2gNBvQBWem0Ea +6v+M1W7R28hUV2oCFgEKgR5u/BQ24aWWvtMSarFK9qsxfA5HAl/Cj2W3lUNCH8J9 +yIrHv9sVzHAI2X/mpIaFjH+4QK5lkCXrBCflRkX1tG1GRpfHShNrfNEb9ASqTNMJ +LMtE1A8/LJnG5ZY6NfN1dT2u97KptCcRTnQJj+m/D9AAQPFy1cgzJE1kG0n2mIdF +Ko8vLlOiC1fEt37KcBRjPUmkEysrDtsshpAN+EfOVJH/8jV8UX3SPpBEgWA6aodk +07ZHsnOjEdZVDCt0CDFbTNbDvoXn3b77pYkDrRBz8QzZYJudcA7ainBIRV94tXfg +FfTnna6A1ieoB/F8re2asXwpiyzUxj4bB170ZHhDWr8U1LXRDKjygv0NCVmLStBI +EH/Iqd3SdrQqCO+QdLPPxNni5vlqBvwAp8QJG0Aql0k5td07XrGJBFH71fOGCvVP +/EgM9EYL1BIj/8YQ3Bh6KIh3g+qZZxopI3g+D3wj0TcE19C+Jxz2Jpi6aT2Qxhkn +jXdngj+wVXCSDLYiUwi5 +=JgOm +-----END PGP SIGNATURE----- + +--Nx8xdmI2KD3LNVVP-- + + +--===============7182395716470202758== +Content-Type: text/plain; charset="us-ascii" +MIME-Version: 1.0 +Content-Transfer-Encoding: 7bit +Content-Disposition: inline + +_______________________________________________ +obnam-dev mailing list +obnam-dev@obnam.org +http://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/obnam-dev-obnam.org + +--===============7182395716470202758==-- + diff --git a/tickets/a5f48a2fdc2b4d8a81ecf85923430f48/Maildir/tmp/.this-dir-not-empty/.empty/empty-file b/tickets/a5f48a2fdc2b4d8a81ecf85923430f48/Maildir/tmp/.this-dir-not-empty/.empty/empty-file new file mode 100644 index 0000000..e69de29 diff --git a/tickets/a5f48a2fdc2b4d8a81ecf85923430f48/ticket.yaml b/tickets/a5f48a2fdc2b4d8a81ecf85923430f48/ticket.yaml new file mode 100644 index 0000000..1a51628 --- /dev/null +++ b/tickets/a5f48a2fdc2b4d8a81ecf85923430f48/ticket.yaml @@ -0,0 +1,4 @@ +ticket-id: +- a5f48a2fdc2b4d8a81ecf85923430f48 +title: +- Obnam development status update -- cgit v1.2.1