The page

https://github.com/megous/megatools

says:

Is that reasonable? Why a build problem is accepted from a file downloaded outside Github but not on the official project page there?

And the tar file contains no binary files that could contain malicious hidden code. I quickly checked:

1. github.com/megous/megatools

2. megatools.megous.com/builds/megatools-1.9.98.tar.gz

3. megatools.megous.com/builds/megatools-1.9.98.tar.gz.asc

Although I have not checked existing files for obfuscated programming (I did not open or read them), I find the whole situation rather strange.

May you explain it to me? Maybe there is something I do not know around here.

It looks like it's using autotools (autoconf and automake). The tarball has those steps already done (autoconf generates the configure script from configure.ac, automake generates Makefile.in from Makefile.am).
Probably "official" tarball is to distinguish the automatic tarball links that Github makes per-commit, e.g. https://github.com/megous/megatools/.../master.tar.gz which will not have configure and Makefile.in pre-generated.

I guess the developer doesn't want to spend time answering issues of the form "I downloaded the code, and it says configure is not found". And looking at the issue list I see

https://github.com/megous/megatools/issues/19
https://github.com/megous/megatools/issues/89
https://github.com/megous/megatools/issues/132
https://github.com/megous/megatools/issues/207 <-- looks like the official tarballs also have some of the docs pre-built

Its really up to the developers to decide where to accept bug reports etc from, for instance as a small developer i dont accept bugs from packages prebuilt by 3rd parties only from source code.

Its the devs choice really

why are you asking here?
shouldn't you be asking the megatools devs? like, open an issue?

If that is true, wouldn't it be just a matter of writing in the readme file something like:

Wouldn't it? The situation, as we see now, is kind of rude, a bad thing in an open source project, in my opinion. And I am not a great software writer with all possible skills, sometimes I will have basic problems, and I hope to find help where I decide to ask, or where I report or point my problem - imagining it is a bug or something to be improved. This is exactly what would happen in that project with several people I know.

In my opinion, open source will always have, at least, two groups of people: people who barely know development, but will like to try and feel what it is to "compile the whole thing from source", which is not always easy; and people with more skills, that will probably do complex things in the project, and could be the trigger to more (subjectively!) interesting facts. We should not put bigger and harder barriers for people trying things they are not yet so familiar with.

In the end, I wanted to see what other developers (possibly much better than myself) thought of the situation.

A detail that may not be noted by eventual readers of this thread: project issues are accepted in Github, but some of them will be silently ignored and closed.

@ondodo in #4: hahaha... that could be a fun ironic thing to do. There is a contact email written a few times around those project pages...

Thank you all for your comments. And if someone else has anything else to say about it, please do!

(:

Yes, it seems like the answer is easy, but you can see in #89 that someone managed to generate a wrong 'configure'. Maybe they had the wrong version of autoconf or something. Who knows, they didn't even bother to post their steps.

Actually, I suspect the document generation is the bigger headache, judging by the number of reports asking how to disable it.

Yes, it's a bit rude. On the other hand, expecting that people will just automatically be there to help you over every obstacle you encounter is a bit rude and entitled on your part, no?

Unfortunately, the second group is larger, and helping them all generally takes more time than is available. So some barriers are needed to choose between those who get help and those who don't. Generally that choice is fairly random: just based on who is available and in the mood to help when a question gets asked. Maybe some simple filter will be applied, e.g., don't help those who don't even bother to read the README.

Here's the list of issues that were closed with no comment: https://github.com/megous/megatools/...omments%3A0..0

There are currently just 6, and except for #212 they are all either closed by the issue opener, or the developer just closed it by fixing the bug directly.
#212 seems more like a support request than a bug report, actually I can't even tell if it's really about megatools or not (maybe it is about "seedbox", whatever that is).

PS you can see the thing about using official tarballs was added later: https://github.com/megous/megatools/...38c4e51f72d3c1
Probably due to some frustration on part of the developer.

2 members found this post helpful.

Yes, I have this expectation. But I do not think it is rude in any form. I think this rudeness should not be considered an aspect of anything I do.

We not always have the help we imagine happening, and that is normal. Sometimes we get a better help, although different from the solutions we think. Sometimes we get less help, or no help. All are possibilities, and we should learn how to deal gracefully with them.

For example: In Linux Questions, I consider myself almost newbie, although I have been around here for years. But I eventually help people here too, and I feel good and satisfied about that. In other places, some of them in the real world (i.e., not possibly hidden by things like arbitrary profiles), I am not so newbie. I imagine all of us are (or will be) like that at some point, and each one for different aspects of our lives.

That's an excellent attitude. If only everyone followed that, might save quite a bit of frustration...