building nano with -D_FILE_OFFSET_BITS=64 cause it to segfault on resizing the
xterm window in which it is running.
Steps to Reproduce:
1.Add -D_FILE_OFFSET_BITS=64 to CFLAGS
3.run nano for CLI in xterm
4.resize the window.
segfault, no more nano , return to bash prompt.
We don't support such C[XX]FLAGS.
So that means the Gentoo does not support ftp with file sizes over 2GB and
cannnot be used to download iso images for example.
AFAIK both Opera and lftp and gftp need this flag to handle large files.
Which "such flags" dont you support ? Is this documented somewhere?
(In reply to comment #2)
> So that means the Gentoo does not support ftp with file sizes over 2GB and
> cannnot be used to download iso images for example.
How's nano related to FTP and ISO downloads?! Submit a patch that fixes nano
crashes or don't complain, this in unsupported upstream.
> Which "such flags" dont you support ? Is this documented somewhere?
Any -Dsomething flags are unsupported.
>>How's nano related to FTP and ISO downloads?!
Until Gentoo supports per package CFLAGS I have to chose between nano
segfaulting and a lack of support for large file ftp. I thought that was clear
from my post.
Should I have posted a bug that my ftp client fails with large files unless I
use "unsupported" flags?
>>Any -Dsomething flags are unsupported.
Again: Is this documented somewhere?
>>Submit a patch that fixes nano crashes or don't complain
I am not _complaining_ , I am trying to contribute to Gentoo as a user who has
found _and diagnosed_ a critical issue with one of the core packages.
If you dont want bug reports , shut down bugzilla and nobody will bug you with
bugs any more. Gentoo can be the first bug-free distribution!!
Otherwise, try to adopt a more positive attitude when users take the time to
(In reply to comment #4)
> Until Gentoo supports per package CFLAGS I have to chose between nano
> segfaulting and a lack of support for large file ftp. I thought that was clear
> from my post.
Once again, we don't support -Dsomething flags set in make.conf. Either the
ebuild officially supports LFS and then it sets the needed flags automatically
or it does not and then don't file bugs when things break, unless you have a patch.
> Should I have posted a bug that my ftp client fails with large files unless I
> use "unsupported" flags?
See above. Such bugs belongs upstream, not to Gentoo bugzilla.
> I am not _complaining_ , I am trying to contribute to Gentoo as a user who has
> found _and diagnosed_ a critical issue with one of the core packages.
Supporting >2GB files in text editor is definitely not a critical issue.
> If you dont want bug reports , shut down bugzilla and nobody will bug you with
> bugs any more. Gentoo can be the first bug-free distribution!!
We don't want bug reports caused by CFLAGS unsupported upstream, these are not
Gentoo-specific issues and developers in general don't have time to fix what
should be fixed usptream.
> Otherwise, try to adopt a more positive attitude when users take the time to
Feel free to reopen with a patch. Until then, CLOSING.
Are you being deliberately obtuce here or are you simply not reading what I post
You have twice refused to answer my direct question "is this policy documented?"
I will take that as a tacit "no, I just made it up to justify dismissing the
I _do not_ require >2GB file editor , what I want is a constistant system that
does not require constant manual frigging of ebuilds into overlay to get the
system to work.
I _do_ require >2GB ftp. That is not exotic and is supported "upstream" by gftp,
lftp and opera which support and work with this flag , so I can hardly post a
bug upstream where there is no issue.
THERE IS AN ISSUE WITH GENTOO: using this flag is supposedly unsupported so
there is no way to ftp large files.
THERE IS A SECOND ISSUE WITH GENTOO: there is no per package cflags so I cannot
use this flag where it is needed without producing _critical_ (as in segfault)
errors in core packages.
THERE IS A THIRD ISSUE WITH GENTOO: declared policy is to "rapidly pass bugs
upstream where necessary". This policy is clearly no longer being applied, since
a correct response would have been : thank you, this bug has been passed
I am not the first to note this increasing dismissive and obstructive attitude
to bug reports that will be the death of Gentoo.
The simplest solution would seem to be filtering this flag in the nano ebuild
until it is resolved upstream. That is gentoo specific and trivial to implement.
It could have been done it in less time than arguing the point.
BTW I have also submitted a report upstream at the same time as my first post
Once again - do NOT put -D_FILE_OFFSET_BITS=64 to your C[XX]FLAGS deliberately,
those bugs will be marked as INVALID. And we won't be filtering such CFLAGS.
Don't use them.
(In reply to comment #6)
> I _do_ require >2GB ftp. That is not exotic and is supported "upstream" by gftp,
> lftp and opera which support and work with this flag , so I can hardly post a
> bug upstream where there is no issue.
*sigh* - you've completely misunderstood or decided to ignore what I've been
repeating several times - we don't support LFS *when it's unsupported
upstream*. If it's supported upstream, file a bug stating that the ebuild
should be compiled with -D_FILE_OFFSET_BITS=64. However, *don't* put such flags
into make.conf yourself and then complain that something crashes because of
them. (BTW, I'm missing your point with Opera here, it's a binary package,
there's zero we could do about it in either case.)
Now, really CLOSING.
Well, thank you for that. After nine comments we actually get to address this
If I understand you correctly you are saying I should post separte bug reports
to each ftp client where I know this to be and issue and suggest that one of
these -Danyflags that are not at all, at all supported on Gentoo is included in
#1 We don't support such C[XX]FLAGS.
#3 Any -Dsomething flags are unsupported
#8 Once again - do NOT put -D_FILE_OFFSET_BITS=64 to your C[XX]FLAGS
If I do submit new bugs as you suggest , will they get looked at or dismissed
out of hand without being understood as happened here?
I do not wish to fight my way up hill if no-one is prepared to listen. I have
fixed my system . The point of filing the bug was to improve Gentoo for other
BTW I have found a solution to the segfault issue but since this bug in
definately INVALID and "really CLOSED" there is clearly no point in posting it.
So should I create new bugs for the affected ftp clients?
Thanks for (finally) seeing what I was getting at.
I guess I've said pretty clearly that
- you should not add -Dbleh C[XX]FLAGS to make.conf
- LFS should be enabled in the ebuilds where possible and supported by upstream
- for other ebuilds (where upstream does not enable LFS), only open bugs when
you have a working patch (should be preferably filed upstream anyway, so that
other users do benefit from that as well, not only Gentoo; and maintainers may
refuse to include such a patch for exactly this reason)
- don't complain when things get broken as a result of using unsupported C[XX]FLAGS
Ranting really won't help in the least.