|Summary:||nano crashed on resize -D_FILE_OFFSET_BITS=64|
|Component:||[OLD] Core system||Assignee:||Gentoo Linux bug wranglers <bug-wranglers>|
|Package list:||Runtime testing required:||---|
Description genbug 2005-10-29 13:39:00 UTC
building nano with -D_FILE_OFFSET_BITS=64 cause it to segfault on resizing the xterm window in which it is running. Reproducible: Always Steps to Reproduce: 1.Add -D_FILE_OFFSET_BITS=64 to CFLAGS 2.emerge nano 3.run nano for CLI in xterm 4.resize the window. Actual Results: segfault, no more nano , return to bash prompt. Expected Results: worked.
Comment 1 Jakub Moc (RETIRED) 2005-10-29 13:40:55 UTC
We don't support such C[XX]FLAGS.
Comment 2 genbug 2005-10-29 13:57:52 UTC
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?
Comment 3 Jakub Moc (RETIRED) 2005-10-29 14:05:21 UTC
(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.
Comment 4 genbug 2005-10-29 14:46:31 UTC
>>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 contribute.
Comment 5 Jakub Moc (RETIRED) 2005-10-29 15:28:48 UTC
(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 > contribute. Feel free to reopen with a patch. Until then, CLOSING.
Comment 6 genbug 2005-10-29 16:07:35 UTC
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 bug." 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 upstream. RESOLVED:CANTFIX. I am not the first to note this increasing dismissive and obstructive attitude to bug reports that will be the death of Gentoo.
Comment 7 genbug 2005-10-29 16:14:01 UTC
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 here.
Comment 8 Jakub Moc (RETIRED) 2005-10-30 01:00:20 UTC
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.
Comment 9 Jakub Moc (RETIRED) 2005-10-30 01:40:14 UTC
(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.
Comment 10 genbug 2005-10-30 08:59:36 UTC
Well, thank you for that. After nine comments we actually get to address this issue. 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 the ebuild. #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 deliberately 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 users. 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. Best regards.
Comment 11 Jakub Moc (RETIRED) 2005-10-30 09:26:51 UTC
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.