Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 260941 - sys-fs/zfs-fuse: uses -Werror during build; fails with _FORTIFY_SOURCE=2
Summary: sys-fs/zfs-fuse: uses -Werror during build; fails with _FORTIFY_SOURCE=2
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Christian Parpart (RETIRED)
: 281350 303623 (view as bug list)
Depends on:
Blocks: werror fortify-source
  Show dependency tree
Reported: 2009-03-02 14:52 UTC by Diego Elio Pettenò (RETIRED)
Modified: 2010-06-05 22:23 UTC (History)
9 users (show)

See Also:
Package list:
Runtime testing required: ---

A patch that removes the -Werror lines from the SConstruct build file. (fix_no_Werror.patch,1.04 KB, patch)
2009-03-18 12:38 UTC, Navid Zamani
Details | Diff
Build log (zfs-fuse-0.5.0:20090707-124609.log,2.48 KB, text/plain)
2009-07-07 13:13 UTC, Diego Elio Pettenò (RETIRED)

Note You need to log in before you can comment on or make changes to this bug.
Description Diego Elio Pettenò (RETIRED) gentoo-dev 2009-03-02 14:52:38 UTC

you're receiving this canned bug because the package in summary uses the flag -Werror during build, which transforms warnings in errors, and is prone to break software when new GCC releases are added to Gentoo.

Please make sure your package does not use -Werror during build, so that it can be more future-proof for the new GCC releases.

Comment 1 Navid Zamani 2009-03-18 11:06:53 UTC
And I just fell right into that problem. Here, with gcc 4.3.3, I can’t emerge zfs-fuse. I will try to modify the ebuild to not use Werror, and see how it works out. Maintainer: Please fix your *in tree* *unmasked* ebuild! Thank you. ^^
Comment 2 Navid Zamani 2009-03-18 12:38:59 UTC
Created attachment 185424 [details, diff]
A patch that removes the -Werror lines from the SConstruct build file.

Ok, I created a patch myself, and just installed zfs-fuse with my gcc 4.3.3. I can’t of course guarantee, that the “-Werror” was not there for a reason. So use at it your own risk.

Oh, and, maintainer: Contact me, if you want the ebuild or related stuff. But the ebuild just has the following line added to the patches:
> epatch "${FILESDIR}/${PV}/fix_no_Werror.patch"
and is renamed to “zfs-fuse-0.5.0-r1.ebuild”.
So that should suffice, to put it in the official portage tree.
Comment 3 Charlie Gehlin 2009-04-16 13:19:00 UTC
Patch verified to work fine here, thanks alot!
Feel free to commit to tree any time ;)

Comment 4 Navid Zamani 2009-05-16 22:29:06 UTC
(In reply to comment #3)
> Feel free to commit to tree any time ;)

Unfortunately I have no idea how to do this.
Also, it seems I did not get your comment mailed. This is why it took me so long to answer.
Comment 5 Diego Elio Pettenò (RETIRED) gentoo-dev 2009-07-07 13:13:55 UTC
Created attachment 197060 [details]
Build log
Comment 6 Julian Stecklina 2009-12-03 15:21:19 UTC
I just hit this bug again. Please commit the. It obviosly does not break anything.
Comment 7 Julian Stecklina 2009-12-03 15:22:25 UTC
(In reply to comment #6)
> I just hit this bug again. Please commit the. It obviosly does not break
> anything.

It should have spelled: "Please, commit the fix."
Comment 8 Diego Elio Pettenò (RETIRED) gentoo-dev 2009-12-27 13:33:52 UTC
*** Bug 281350 has been marked as a duplicate of this bug. ***
Comment 9 Diego Elio Pettenò (RETIRED) gentoo-dev 2009-12-27 13:34:44 UTC
Somebody willing to keep this in tree or should I simply kill it?
Comment 10 Navid Zamani 2009-12-27 17:58:23 UTC
Well, of course, as ZFS is the only really trustworthy FS, and this fuse implementation is the only hope of using it, it’s somehow very important.

On the other hand, if nobody continues to develop or maintain it (assuming no maintainer being the reason not to keep it), there’s no point in keeping a buggy version that will never get fixed in Portage. :)

I think you will agree, that if we (do not have a maintainer right now, but) can find a maintainer, and development itself continues too, we should keep it. :)

I, for one, lost 120GB of data, which was half my archive, even with all usual precautions, because of corruption that the disk controller did not report at all. Even backups do not help, as you are silently copying the corruption on the backups too. The only workaround to that is something like ZFS’s constant scrubbing plus some error correction (CIRC) data.
And if I ever lose so much important data again, I can as well just shoot myself on the spot. :/

(A workaround is, to switch to Solaris. Perhaps in a virtual machine. And then perhaps export that drive over the internal tun/tap connection.)
Comment 11 Ian Ballantyne 2009-12-27 18:24:06 UTC
As far as I can tell, upstream has not produced anything new for more than a year now. I tried package, but it failed miserably. I, like Navid, think this is an important package, however if there is no upstream activity in a package that is very buggy, and apparently no attempts to implement zfs for the kernel, then I see little point in keeping the package in the tree. I would like to do something but I don't have the time. I suggest masking it for removal for a period of three months, with a comment pointing to this bug.  If no one complains, then remove it from the tree.
Comment 12 Navid Zamani 2009-12-27 18:41:52 UTC
(In reply to comment #11)
For a year? Well in that case, I second your suggestion. It’s a great idea.

Comment 13 Stelian Ionescu 2009-12-27 18:46:23 UTC
Looking on, I can see that 0.6.0 was released 3 weeks ago
Comment 14 Navid Zamani 2009-12-27 19:13:25 UTC
(In reply to comment #13)
> Looking on, I can see that 0.6.0 was released 3 weeks ago.

I should have asked for a [citation needed] for the “one year” statement. ;)

Sounds great... but what does “independent” mean. Can we expect development to continue?

Also one thing is very important for this package: Only unmask *reliable* versions. As one needs to be able to rely on it for very important data.

Comment 15 Navid Zamani 2009-12-27 20:27:19 UTC
Hey, we should close this, and link this bug to bug 291540.
Comment 16 Ian Ballantyne 2009-12-27 23:25:19 UTC
I was looking at , it was the first thing that came up under google when I searched for "zfs fuse", and I didn't look much further as I had seen nothing new since about October last year.  I therefore stand corrected.  It does look like development is continuing, as such I believe it should remain in the tree.

I second navid's comment that we should close this bug and link to bug 291540.
Comment 17 Thomas Sachau gentoo-dev 2010-03-11 20:31:13 UTC
*** Bug 303623 has been marked as a duplicate of this bug. ***
Comment 18 Samuli Suominen (RETIRED) gentoo-dev 2010-06-05 22:21:35 UTC