W dniu 22.02.2016 o 15:08, Lukas Fleischer pisze:

On Mon, 22 Feb 2016 at 02:46:56, Maciej Sieczka wrote:

...

W dniu 21.02.2016 o 21:34, notify@aur.archlinux.org pisze: [...] When some time passed, he eventualy implemented most of the bits he previously removed during his "cleanup" (some being hacks, but unavoidable), possibly partly due to other users's comments, but he didn't miss an opportunity to call GRASS developers "lunatics" in regard to Python 2/3 issue. How nice. Thing is that GRASS is not ready for Python 3 as "the python" at its build- and run-time, there's nothing wrong or right about it. This is just how it is. Any approach to this issue is a kind of a hack for now, and the simpler and less intrusive the hack - the better IMO. So when I maintained the GRASS PKGBUILD, I used a python2 symlink instead of patching the sources using sed, which is more effort and can be error-prone.

Maybe you misunderstood Doug here: There is nothing wrong with only supporting Python 2 for the time being but it is wrong to specify an unversioned shebang if you do.

I did not misunderstand anything. He's calling decent people names in public, he's not doing things right and doesn't want to do them right. And everyone has to deal with it, until he changes his mind, which may or may not happen, because he says so.

Patching the source code to use the right Python version really isn't much more effort (3 lines vs. 2 lines) and it is the standard way of fixing this kind of issues in the official repositories.

Fine. But in spite of the patching you still need to add the python2 symlink in a GRASS installation in order to be able to install Python addons (using g.extension module). I assumed that since the symlink was required, the patching could be spared. Anyway, I used to create that python2 symlink in my PKGBUILD, he removed it not knowing what he was doing and refused to bring it back. Finally he did that later when somebody complained about addons not working. And so the story goes. What a waste of time and eneregy, just because a person won't listen. I would be glad that somoene's trying to help me improve my code. For him it's badgering and pestering.

It would be even better to report this upstream and tell them to use the correct headers according to PEP 394.

I'll ask GRASS devs about PEP 394.

...

One of the things still missing in Doug's grass PKGBUILD is liblas dependency. Back in October he just explicitely refused enabling it without any explanation, and apparently hasn't changed his mind since. This means disabling LIDAR functionality in GRASS, which is pointless and a major drawback.

So I uploaded another GRASS 7 PKGBUILD (as "grass7") with liblas dependency enabled (plus enabling OpenMP, LAPACK and BLAS features, going a safe route with wxPython 2.8 vs 3 and using a python2 symlink at buildtime instead of massaging the sources with sed). Then Doug requested grass7 removal, making judgement calls about what qualifies an AUR package, but unwilling to include the missing bits in his package when being asked for it in past. Kindoff catch 22.

I'm trying to appreciate his contribution. But I don't understand his motives and chaotic reactions, I perceive his behavior hostile. Based on the very unpleasent past experience I don't I want to have to try convincing him to do this or that. I'd rather avoid getting involved with him regarding liblas dependency and in future grass PKGBUILD maintenance. But I still want to provide a feature-rich, high quality GRASS 7 package for Arch.

So, please let me know what package name I should use instead of "grass7", and I will gladly play along.

I do not known enough about GRASS to decide whether having this feature enabled is a must-have. However, it's usually up to the maintainer to decide which features are enabled by default. If you want different features, just change the PKGBUILD before building (since we're using Git for AUR packages, you can even put those changes on a separate branch and merge them on every update). Given that GRASS does not seem to be too popular, it probably doesn't make sense to upload another package just to change the set of features enabled by default.

You are missing the point. It's not about me. It's about all Arch GRASS users and about doing things right. Yes, everyone can edit a PKGBUILD, add a configure switch or something (assuming they know what it should be) and spend extra time to rebuild the package. But why deliberately make things harder for everyone like this? LIDAR support is a standard GIS feature. I know about GIS, GRASS and I know what I'm saying. Again, he crippled my PKGBUILD down (breaking addons support and disabling several crucial features) and I had to ask him whether he could fix this or that. He decided to fix some but not all - eg. the LIDAR support. He refused just because he could. I don't get it. And when I'm trying to do things right on my own he stands in my way just because he can, demanding my contribution go down the drain, just because he can. But OK, I tried. I'm not going to argue another person. Sure you can have it your way if you wish so. GRASS Arch users will have to accept this incovience.