Re: [aur-general] AUR requests not handled anymore?

[Daniel M. Capella via aur-general]

On May 6, 2020 1:55:55 AM EDT, Christoph Gysin via aur-general 
 wrote:
> I have made two deletion requests on my packages 2 weeks ago, that
> were
> never handled:
> 
> https://lists.archlinux.org/pipermail/aur-requests/2020-April/039815.html
> https://lists.archlinux.org/pipermail/aur-requests/2020-April/039825.html
> 
> Has the process changed? What can I do to get these handled?
> 
> Thanks,
> Chris

I'm actually currently trying to take care of a bit of the queue; will look at 
those for you.

The queue has been a bit overloaded. Lately I myself generally focus on tickets 
that have hit the 2 week mark and people will have had time to resolve or argue 
against them.

--
Best,
Daniel 

Re: [aur-general] [aur-requests] [PRQ#4831] Request Accepted

[Maciej Sieczka]

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, not...@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 

Re: [aur-general] AUR Requests

[Jonathan Steel]

On Sun 02 Feb 2014 at 13:24, Rob McCathie wrote:
 On Sun, Feb 2, 2014 at 10:53 AM, Michael Schubert mschu@gmail.com wrote:
  Hi,
 
  (Maintainers, if any, are in CC.)
 
  Could you please merge:
 
  https://aur.archlinux.org/packages/python2-imaging/ -
  https://aur.archlinux.org/packages/python2-imaging-alt/ **
  Reason: PIL is being phased out by pillow; 1st is orphan and 2nd one not to
  be replaced like in [community]
  Maintainer: please add a replaces=() flag, it should replace python2-imaging
  and not python-imaging
 [...]
 I agree python2-imaging should be deleted or merged into
 python2-imaging-alt

I don't agree that this should happen.

 since when a user installs python2-imaging the
 next time they go to system update pacman of course offers to replace
 it with python2-pillow. (Yes I know they /could/ just use IgnorePkg=
 in pacman.conf)

I do agree this is what you should do if you want to continue using it,
rather than upload an incorrectly named, duplicate package. I will remove
python2-imaging-alt.

-- 
Jonathan Steel


pgp7E0otGza6w.pgp
Description: PGP signature

Re: [aur-general] AUR Requests

[Jonathan Steel]

On Sat 01 Feb 2014 at 23:53, Michael Schubert wrote:
 Hi,
 
 (Maintainers, if any, are in CC.)
 
 Could you please merge:
 [...]
 
 https://aur.archlinux.org/packages/python2-socksipy-branch/ -
 https://aur.archlinux.org/packages/python2-socks/
 https://aur.archlinux.org/packages/python-socksipy-branch/ ** -
 https://aur.archlinux.org/packages/python-socks/
 Reason: socksipy and -branch are dead, socks is maintained and has same API
 Maintainer: please let me know if you'd like to maintain the new package/why
 we should keep a dead branch

Merged.
 
 And remove:
 
 https://aur.archlinux.org/packages/sundials25/ **
 Reason: sundials=2.5 current and available, package installs into /usr
 directly and should not be used
 [...]

Removed, thanks.

-- 
Jonathan Steel


pgpjeyyhJOb4v.pgp
Description: PGP signature

Re: [aur-general] AUR Requests

[Rob McCathie]

On Sun, Feb 2, 2014 at 10:53 AM, Michael Schubert mschu@gmail.com wrote:
 Hi,

 (Maintainers, if any, are in CC.)

 Could you please merge:

 https://aur.archlinux.org/packages/python2-imaging/ -
 https://aur.archlinux.org/packages/python2-imaging-alt/ **
 Reason: PIL is being phased out by pillow; 1st is orphan and 2nd one not to
 be replaced like in [community]
 Maintainer: please add a replaces=() flag, it should replace python2-imaging
 and not python-imaging

Hi Michael,

I will just remove the replaces array in python2-imaging-alt. It's not
appropriate/required for the package nowadays anyway.

I agree python2-imaging should be deleted or merged into
python2-imaging-alt, since when a user installs python2-imaging the
next time they go to system update pacman of course offers to replace
it with python2-pillow. (Yes I know they /could/ just use IgnorePkg=
in pacman.conf)

Regards,
Rob McCathie (korrode)