LQ Suggestions & FeedbackDo you have a suggestion for this site or an idea that will make the site better? This forum is for you.
PLEASE READ THIS FORUM - Information and status updates will also be posted here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I made a newbie mistake a short while ago while compiling a new gcc. I posted a compiler error to the gcc buglist. Now, the posting wasn't the error, I've seen plenty of compile error bugs that required legitament developer fixes. My mistake was using the gcc bugzilla as my notebook for the work I was doing in the compile error. Turns out that those posts all go to the main gcc bugs mailing list, which is probably hundreds of people watching my worthless notes about learning the gcc build system.
But that service was very useful, and I would have continued using it if it wasn't sending emails out to half the world each time I posted. Its nice to have a reliable off-site bugzilla where you can track, well, whatever strange and uncurable linux psycho-bug you happen to be working on at the time. This is with the added bonus that it gets crawled by the web spiders from time to time, improving the chances that someone else will find keywords linking to the solution.
Distribution: Debian, Red Hat, Slackware, Fedora, Ubuntu
Posts: 13,597
Rep:
We used to use Bugzilla, but recently got rid of it for something more integrated with the main site. Do note that it's only for bugs in LQ itself though.
that's for bugs in the LQ site or other LQ associated stuff. I want a bug tracking system for anything linux related. It would make me feel like I'm actually doing a lot more if I had someplace to track all the problems I have with building libraries and kernels.
Distribution: Debian, Red Hat, Slackware, Fedora, Ubuntu
Posts: 13,597
Rep:
You should be reporting them upstream though, where there is a chance the issue will get corrected. A huge generic bug database wouldn't actually be used by the projects.
in my experience, core developers don't worry their important brain cycles on build issues. I'm sure a kernel developer would probably just tell me "well, then just use gcc three point whatever..." That's the way open source works. And I think a "big generic" searchable linux bug database would be of tremendous use. You'd have to limit the scope a little, to say only report bugs you're willing to work on yourself, but I think the general idea would work.
For example: my compilation of gnome just died. I searched the web for the error, and discovered the source of the compile error. The reason was I had what appeared to be broken headers from my 2.6.8 installation. The files linux/videodev.h and linux/videodev2.h have some "__user" strings in them which my compiler can't handle. I removed the strings, as instructed by various posts to buglists, and the compile continued.
I would love to post that to a central bug database, because it looks like a bug to me.
Distribution: Debian, Red Hat, Slackware, Fedora, Ubuntu
Posts: 13,597
Rep:
Structured right, I think the LQ Wiki could possibly be used for such things. In the end though, I think all *bugs* should go upstream. Having compilation errors and other common pitfalls that aren't bugs somewhere searchable could be useful though.
the problem with reporting bugs upstream is, in my experience, most every-day bugs reveal themselves in areas far far removed from the source of the problem. I believe that's why I'm usually ignored when I post compilation errors to bug reports. My previous compilation problem is a perfect example. The error came up in compiling gnome, I found the answer in a gnome mailing list, but the problem itself is with the linux headers. It is in fact a bug with the kernel.
That's why I believe there should be a central USER bug database. The bugzillas I've found are developer ones. And, while those are important, I believe there should be other bug reporting databases which focus on the usability of the whole Linux/OSS system. I don't really care if the loop unrolling of gcc has a minor bug in it, but I really do care if I can't get firefox or kernel source to compile.
This wouldn't be a "My network card doesn't work" database. Its more of a "compile error, gcc-4.0.2 on debian". And, now that I think about it, perhaps it could just be limited to source build issues. That in itself would quickly grow to an impressive size. And very often, real external system bugs are found during compile time.
and yes, the wiki _could_ be used for something like this. But the wiki is just a blank slate. Bug reporting require structure.
my gnome build died because something couldn't find readline headers. I
compiled and installed readline, but the gnome build still dies. I
looked at the configure script and it's compiling it with
no -l library flags. I can't compile the test program without
-lreadline and -lncurses.
This is a bug. I probably caused it, but it's still a bug. I'm
not sure how to fix this. Do I recompile binutils to include
those libs automatically (and how is that even done)? Do I just
set LDFLAGS to include those libraries? i dunno.
here's another one: my compilation now keeps failing because the libraries aren't listed in the right order. if -lreadline is included, -lncurses must be after it, or the linker fails. I'm sure it's a configuratiuon problem on my side, but its a bug as far as I'm concerned.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.