the latest version available is sys-fs/encfs-1.7.2 current v version on http://www.arg0.net/encfs is 1.7.4 1.7.2 has a bud that makes --reverse to store files incorrectly. Please update the ebuild to the latest version. Reproducible: Always Steps to Reproduce: n/a
(In reply to comment #0) > 1.7.2 has a bud that makes --reverse to store files incorrectly. A look at the change log confirms this. Do I understand correctly that this bug in 1.7.2 may cause data loss? Raising to severity to major.
As it turns out the data is recoverable: this is a comment from the original bug report. I've checked in the fix and packaged as 1.7.3 I did confirm that using --forcedecode allows correctly decoding files which were stored with the broken version. To complicate things, the code is only broken when reading an EXISTING filesystem. If you create a new filesystem, copy files, then mount that the files will read normally. If you re-mount the reverse filesystem, then new files are stored incorrectly, but can be read by passing --forcedecode (this only works with the BROKEN version of encfs). Hope that helps. As I understand it the data is recoverable only by using --forcedecode with 1.7.2
Any development on this one?
The latest ebuild with an additional upstream patch can be found here: http://trac.pentoo.ch/browser/portage/trunk/sys-fs/encfs Let me know if any suggestions.
+*encfs-1.7.4 (22 Nov 2011) + + 22 Nov 2011; Sebastian Pipping <sping@gentoo.org> +encfs-1.7.4.ebuild, + +files/encfs-1.7.4-r68:69.patch: + Bump to 1.7.4, looks trivial. Post-release upstream bugfix patch included. + Turning into stabilization request, adding arches...
Tony, ok to stabilize it?
(In reply to comment #6) > Tony, ok to stabilize it? Yes. Stabilize 1.7.4. @Sebastian. There was a second post-release commit to their svn, but it was just an optional feature, not a bug fix, according to their ChangeLog. That ebuild 1.7.4-r1 is on my dev overlay but I don't think I'll add it to the tree since its not urgent.
@blueness Missing zlib as RDEPEND amd64 ok
(In reply to comment #8) > @blueness > Missing zlib as RDEPEND While zlib is part of @system in base (see /usr/portage/profiles/base/packages), I just learned that profile "embedded" does not inherit from base, so I guess zlib indeed needs listing as an explicit dependency: http://devmanual.gentoo.org/general-concepts/dependencies/index.html#implicit-system-dependency (In reply to comment #7) > @Sebastian. There was a second post-release commit to their svn, but it was > just an optional feature, not a bug fix, according to their ChangeLog. That > ebuild 1.7.4-r1 is on my dev overlay but I don't think I'll add it to the tree > since its not urgent. I'm fine with either way.
(In reply to comment #9) > (In reply to comment #8) > > @blueness > > Missing zlib as RDEPEND > > While zlib is part of @system in base (see > /usr/portage/profiles/base/packages), I just learned that profile "embedded" > does not inherit from base, so I guess zlib indeed needs listing as an explicit > dependency: > I didn't know that about embedded. I've never added zlib to RDEPEND because I assumed every profile had it in @system. I'll add it.
(In reply to comment #10) > I didn't know that about embedded. I've never added zlib to RDEPEND because I > assumed every profile had it in @system. I'll add it. On the other hand I am wondering: @system of profile embedded has a single package only: busybox. That would mean we have to add gcc and the likes anywhere because of embedded. That doesn't feel right. Maybe that's something to bring up to the attention of QA, the maintainers of the devmanual: http://www.gentoo.org/proj/en/qa/devmanual.xml Do you have a bit of time to go for this?
(In reply to comment #11) > (In reply to comment #10) > > I didn't know that about embedded. I've never added zlib to RDEPEND because I > > assumed every profile had it in @system. I'll add it. > > On the other hand I am wondering: @system of profile embedded has a single > package only: busybox. That would mean we have to add gcc and the likes > anywhere because of embedded. That doesn't feel right. > > Maybe that's something to bring up to the attention of QA, the maintainers of > the devmanual: > http://www.gentoo.org/proj/en/qa/devmanual.xml > > Do you have a bit of time to go for this? 1) I already added sys-libs/zlib to encfs. A quick grep of the tree shows lots of packages have it in their R/DEPENDS. I've never added it for the reasons stated above. I don't think this one is critical though. 2) This issue has always bothered me. We are not to add R/DEPENDS which are in @system, but @system is different for different profiles while our ebuilds should work for every profile. We could define it as @system for base, but then what if base is changed? Maybe an issue to be discussed on gentoo-dev@g.o?
x86 stable
amd64 ok
amd64 done. Thanks Michael
