| Summary: | sys-fs/zfs-fuse: uses -Werror during build; fails with _FORTIFY_SOURCE=2 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Diego Elio Pettenò (RETIRED) <flameeyes> |
| Component: | New packages | Assignee: | Christian Parpart (RETIRED) <trapni> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bugs, esigra, gentoo-bugzilla, ian, js, qa, Rainmaker526, reagentoo, trapni |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://blog.flameeyes.eu/2009/02/25/future-proof-your-code-dont-use-werror | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 260867, 259417 | ||
| Attachments: |
A patch that removes the -Werror lines from the SConstruct build file.
Build log |
||
|
Description
Diego Elio Pettenò (RETIRED)
2009-03-02 14:52:38 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. ^^ 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. Patch verified to work fine here, thanks alot! Feel free to commit to tree any time ;) BR Charlie (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. Created attachment 197060 [details]
Build log
I just hit this bug again. Please commit the. It obviosly does not break anything. (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." *** Bug 281350 has been marked as a duplicate of this bug. *** Somebody willing to keep this in tree or should I simply kill it? 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.) 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. (In reply to comment #11) For a year? Well in that case, I second your suggestion. It’s a great idea. Looking on http://zfs-fuse.net/, I can see that 0.6.0 was released 3 weeks ago (In reply to comment #13) > Looking on http://zfs-fuse.net/, 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. Hey, we should close this, and link this bug to bug 291540. I was looking at http://zfs-on-fuse.blogspot.com/ , 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. *** Bug 303623 has been marked as a duplicate of this bug. *** fixed |