Discussion:
[aur-general] Questions about some of my packages being adopted in [community]
Konstantin Gizdov
2018-09-29 19:57:12 UTC
Permalink
Hi all,

I'm writing to hopefully get some clarity on some packages that I
maintained in AUR (python-awkward-array, unuran), but have been overtaken
now in [community]. Also one other package that I have not maintained
'libafterimage', but dear to me.

Firstly, thanks to Felix Yan for picking them up and sorry if the following
questions have been asked before and obvious to everyone.

This is what I know:

1. Nothing in the core repos depends on them and they are libraries. I've
not seen requests to add them before.
2. 'libafterimage' includes a bug that has been reported to AUR, but has
not been fixed. I've had to include a patch in my local chain.
3. The packages do not provide the same functionality as before, but
conflict with the AUR ones.
4. I wasn't told anything - my AUR package was deleted with a 'thanks for
maintaining it' message.
5. I've reported a few bugs FS#6024{6,7,8}, but have been denied resolution.

The reason I'm asking is because over the years I've added and been
maintaining some professional software and these packages are part of that
chain. Colleagues in the field have become accustomed to me for packaging
with care and updating with new features. But now, obviously that is
changing and people are going to flock if something doesn't work as
expected. So this is sort of me getting ahead of the wind and basically
asking the question:

- Why?
- How many & which will be put into [community]?
- How can I effectively communicate the nuts & bolts to the new
maintenaners so to say, to make sure users still get what's expected?
- Is there anything I can do if new packages do not meet what the original
intention was - apart from making a conflicting AUR package?

Thanks in advance.

--
Regards,
Konstantin
Daniel Capella via aur-general
2018-09-29 20:41:11 UTC
Permalink
Post by Konstantin Gizdov
- How can I effectively communicate the nuts & bolts to the new
maintenaners so to say, to make sure users still get what's expected?
There's precedence for maintainers of specialized software in the AUR to be
sponsored to become a Trusted User (though it seems there's a preexisting
relationship?).
Post by Konstantin Gizdov
- Is there anything I can do if new packages do not meet what the original
intention was - apart from making a conflicting AUR package?
The other option would be to host your own repo for these packages.
--
Best,
polyzen
Filipe Laíns via aur-general
2018-09-29 21:44:43 UTC
Permalink
Post by Konstantin Gizdov
Hi all,
I'm writing to hopefully get some clarity on some packages that I
maintained in AUR (python-awkward-array, unuran), but have been overtaken
now in [community]. Also one other package that I have not maintained
'libafterimage', but dear to me.
Firstly, thanks to Felix Yan for picking them up and sorry if the following
questions have been asked before and obvious to everyone.
1. Nothing in the core repos depends on them and they are libraries. I've
not seen requests to add them before.
That is not required.
Post by Konstantin Gizdov
2. 'libafterimage' includes a bug that has been reported to AUR, but has
not been fixed. I've had to include a patch in my local chain.
3. The packages do not provide the same functionality as before, but
conflict with the AUR ones.
Check my comments below.
Post by Konstantin Gizdov
4. I wasn't told anything - my AUR package was deleted with a 'thanks for
maintaining it' message.
I try to ask before moving packages but that isn't always that easy. It
ends up delaying releases of a few packages. Besides, not everyone had
the same free time I do, so it's very reasonable that felix didn't
contact you first.
Post by Konstantin Gizdov
5. I've reported a few bugs FS#6024{6,7,8}, but have been denied resolution.
Regarding FS#60246
What did you do to reproduce this? Did you build in a clean chroot?
Right now the header files are being packaged and this should be
reproducible. If you can't reproduce this inside a clean chroot, then
open a bug report.

Regarding FS#60247
I left a comment there - https://bugs.archlinux.org/task/60247

Regarding FS#60248
Just release the python2 version of the package in the AUR.
Post by Konstantin Gizdov
The reason I'm asking is because over the years I've added and been
maintaining some professional software and these packages are part of that
chain. Colleagues in the field have become accustomed to me for packaging
with care and updating with new features. But now, obviously that is
changing and people are going to flock if something doesn't work as
expected. So this is sort of me getting ahead of the wind and
basically
- Why?
Why what? Why were they moved? I don't know for sure but if they're
moderately popular, there's your reason.
Post by Konstantin Gizdov
- How many & which will be put into [community]?
Popular packages could be moved to community if a TU wants to maintain
them.
Post by Konstantin Gizdov
- How can I effectively communicate the nuts & bolts to the new
maintenaners so to say, to make sure users still get what's expected?
The maintainers should be able to properly package the software on
their own. What users expect might not be the proper way to do it. If
you have a problem, you open a bug report or you send a mail to the
mailing list like you did, depending on the nature of the problem.
Post by Konstantin Gizdov
- Is there anything I can do if new packages do not meet what the original
intention was - apart from making a conflicting AUR package?
What original intention? Packages don't need to meet any intention.
They should be packaged acording to the guidelines


Thanks,
Filipe Laíns
3DCE 51D6 0930 EBA4 7858 BA41 46F6 33CB B0EB 4BF2
Eli Schwartz via aur-general
2018-09-30 02:32:41 UTC
Permalink
Post by Konstantin Gizdov
Hi all,
I'm writing to hopefully get some clarity on some packages that I
maintained in AUR (python-awkward-array, unuran), but have been overtaken
now in [community]. Also one other package that I have not maintained
'libafterimage', but dear to me.
Firstly, thanks to Felix Yan for picking them up and sorry if the following
questions have been asked before and obvious to everyone.
1. Nothing in the core repos depends on them and they are libraries. I've
not seen requests to add them before.
As mentioned above, this isn't a requirement, if a Dev/TU wishes to add
them simply as a useful library this is fine.
Post by Konstantin Gizdov
2. 'libafterimage' includes a bug that has been reported to AUR, but has
not been fixed. I've had to include a patch in my local chain.
https://bugs.archlinux.org/task/60246 was incorrectly closed then,
especially as my first attempt to build it with extra-x86_64-build
resulted in

/usr/bin/mkdir /build/libafterimage/pkg/libafterimage/usr/include
/usr/bin/mkdir: cannot create directory
‘/build/libafterimage/pkg/libafterimage/usr/include’: No such file or
directory
failed to create include directory:
/build/libafterimage/pkg/libafterimage/usr/include

Followed by this terrible build system *incorrectly* continuing to
package the libs and binaries only.
Post by Konstantin Gizdov
3. The packages do not provide the same functionality as before, but
conflict with the AUR ones.
4. I wasn't told anything - my AUR package was deleted with a 'thanks for
maintaining it' message.
This is fairly common -- while it is nice to get in touch with the AUR
maintainer, we hardly need *permission* to package something for the
repos. As always, you can report bugs with the official packages.
Post by Konstantin Gizdov
5. I've reported a few bugs FS#6024{6,7,8}, but have been denied resolution.
Denied resolution?

One bug was improperly closed and I've reopened it (that's why you can
request this)

One bug was simply completely wrong -- we don't have to provide the
python2 version and it's 100% legitimate to maintain that in the AUR. If
you think about it, you essentially *complained* that we only moved one
of two packages to the official repos. How is that a legitimate complaint?

One bug isn't even a bug, it's a feature request and moreover it's still
open *and* it's assigned, pending resolution.

I fail to see how you're being "denied" anything.
Post by Konstantin Gizdov
The reason I'm asking is because over the years I've added and been
maintaining some professional software and these packages are part of that
chain. Colleagues in the field have become accustomed to me for packaging
with care and updating with new features. But now, obviously that is
changing and people are going to flock if something doesn't work as
expected. So this is sort of me getting ahead of the wind and basically
This is definitely you getting ahead of something. :(
Post by Konstantin Gizdov
- Why?
- How many & which will be put into [community]?
Whatever we want.
Post by Konstantin Gizdov
- How can I effectively communicate the nuts & bolts to the new
maintenaners so to say, to make sure users still get what's expected?
A well-maintained PKGBUILD that gets added to [community] will naturally
come with whatever well-written fixes were in that PKGBUILD.

Apparently libafterimage was not well-maintained...

Also python-awkward-array is not very well maintained either, judging by
its erroneous use of completely invalid PKGBUILD syntax. I'd like to
observe that while package_*() exists for split packages, there is no
such thing as build_*() and we will reject any attempt at adding such
functionality to makepkg. Your PKGBUILD therefore has no build function
at all -- it goes right from prepare to package, and has the additional
misfortune of not having the vitally required makedepends.

You don't get to act as some sort of concerned citizen here to protect
your packages from the incompetent Devs/TUs when your PKGBUILD contains
this junk.

(Sorry for being harsh, but this is the reaction you invite when you set
yourself up as the superior packager.)
Post by Konstantin Gizdov
- Is there anything I can do if new packages do not meet what the original
intention was - apart from making a conflicting AUR package?
No, and you don't get to make duplicate packages either. Submit a
bugreport instead. If the package in question legitimately contains
additional compile-time dependencies, then and only then may you make an
AUR package called, for example, libfoo-optionalfeaturename.

The actual package name that exists in the repos will be automatically
blacklisted by the aurweb server.
--
Eli Schwartz
Bug Wrangler and Trusted User
Mike Sampson
2018-09-30 03:13:54 UTC
Permalink
On Sun, Sep 30, 2018 at 12:32 PM Eli Schwartz via aur-general
Post by Eli Schwartz via aur-general
Apparently libafterimage was not well-maintained...
I think I was the maintainer of libafterimage. I'm not using Arch
Linux at the moment so have been very slack with my AUR packages. I'll
make an announcement somewhere in case anyone wants to adopt any of
them. I have some iSCSI related stuff that needs updating at the
moment.

Regards,

Mike
Eli Schwartz via aur-general
2018-09-30 03:33:28 UTC
Permalink
Post by Mike Sampson
On Sun, Sep 30, 2018 at 12:32 PM Eli Schwartz via aur-general
Post by Eli Schwartz via aur-general
Apparently libafterimage was not well-maintained...
I think I was the maintainer of libafterimage. I'm not using Arch
Linux at the moment so have been very slack with my AUR packages.
Given the package base in question is now deleted, no one can see the
comments, and I cannot tell when this was mentioned.

So I guess your not using Arch anymore is a fairly decent reason for not
fixing something that you were maybe only made aware of recently...
Post by Mike Sampson
I'll make an announcement somewhere in case anyone wants to adopt any of
them. I have some iSCSI related stuff that needs updating at the
moment.
This announcement would be a good idea, thanks. :)

More generally, if you anticipate returning to Arch and want to still
maintain those packages for the future, you could consider finding
comaintainers. Comaintainers are a fantastic feature and I'm a big fan
of collaboration in the packaging ecosystem. :D

This applies to anyone who is afraid they cannot devote lots of
attention to a package they maintain, for any reason.
--
Eli Schwartz
Bug Wrangler and Trusted User
Felix Yan via aur-general
2018-09-30 05:16:49 UTC
Permalink
Post by Konstantin Gizdov
3. The packages do not provide the same functionality as before, but
conflict with the AUR ones.
I believe that is not true. I even enabled more functionality in
libafterimage, actually.
Post by Konstantin Gizdov
4. I wasn't told anything - my AUR package was deleted with a 'thanks for
maintaining it' message.
That's a message I entered manually each time, with respect :)
Post by Konstantin Gizdov
5. I've reported a few bugs FS#6024{6,7,8}, but have been denied resolution.
I do not intend to package the python2 variant. For the other two, I
have replied in the tasks.
Post by Konstantin Gizdov
- Why?
- How many & which will be put into [community]?
I actually want to move the whole "root" tree, but considering its
number I just started with the easier "leaf" ones.
Post by Konstantin Gizdov
- How can I effectively communicate the nuts & bolts to the new
maintenaners so to say, to make sure users still get what's expected?
By opening bugs or send me an email directly if it's urgent.

Sorry for the confusion and late reply, it was very late in my TZ when I
work on the packages.
--
Regards,
Felix Yan
Konstantin Gizdov
2018-09-30 18:51:47 UTC
Permalink
Hi all,

Thanks for the comments and explanations.

Firstly, I wanna say that I am not asking for special treatment or
anything. Just wanted to discuss in detail what is going on. Secondly, a
few comments stood out to me (in no particular order).

I actually want to move the whole "root" tree, but considering its
Post by Felix Yan via aur-general
number I just started with the easier "leaf" ones.
This is what I suspected to be honest. The packages that were pulled were
way too specific. Well, if you're going to do this, then I'd like to have a
conversation about it. (below)

Regarding FS#60248
Post by Felix Yan via aur-general
Just release the python2 version of the package in the AUR.
Sure, just wanted to be sure that's the expected approach.

What original intention? Packages don't need to meet any intention.
Post by Felix Yan via aur-general
They should be packaged acording to the guidelines
Of course, they do - packages exist for a reason and the way they are
packaged expresses the intention - feature support, type of build,
structure, etc. All of that is beyond scope of packaging standards.

This is fairly common -- while it is nice to get in touch with the AUR
Post by Felix Yan via aur-general
maintainer, we hardly need *permission* to package something for the
repos. As always, you can report bugs with the official packages.
I was not implying *permission* is needed, this is not the point - the
point is letting people, who put their time in, know what's up. In any
case, I listed this as an observation, hence the reason my email was
prompted.

Denied resolution?
Post by Felix Yan via aur-general
...
I fail to see how you're being "denied" anything.
Call it what you want, I tried to re-open all 3 bugs but was denied with
little to no comment/explanation. I wanted to know if python2 is going to
be added by Felix or not - instead I was scolded at the bug and here in
emails. The other bug is a bug as confirmed - also denied to re-open
without explanation/investigation. The third bug was re-opened by Filipe
after my initial email - no need to bash me further about it. So all bugs
were closed & denied to re-open until I made a fuss about it here. That to
me is 'denied'.

Whatever we want.

Of course, but not helpful. I'll explain.

You don't get to act as some sort of concerned citizen here to protect
Post by Felix Yan via aur-general
your packages from the incompetent Devs/TUs when your PKGBUILD contains
this junk.
(Sorry for being harsh, but this is the reaction you invite when you set
yourself up as the superior packager.)
I am not pertaining to be a superior packager and I am not calling anyone
incompetent. This is completely beside the point. I will explain below. But
to address the state of this particular package - it was added 2 weeks ago
in a rush to push a new version upstream, because I maintain my packages
well. This package and another from same time around need a complete
rewrite, which I'm aware of. And this particular style of package was
copied from another [community] package a long time ago, things have
changed as it was pointed out to me here in the AUR. I had intentions to
fix it as soon as I had time. Picking out one package out of the whole
stack, which I have not had time to properly deal with, proves nothing, but
that you aim to shame, rather than to understand where I'm coming from, why
I am worried and that I'm actually looking to be heard and help.

That's a message I entered manually each time, with respect :)

This was not a complaint. Thanks, that's actually the only clue I had my
packages were going somewhere and not just randomly deleted.

I believe that is not true. I even enabled more functionality in
Post by Felix Yan via aur-general
libafterimage, actually.
You mean when you removed `--disable-svg` flag? I might be wrong, but I
think there was a reason to leave it disabled. You'd have to check comments
or Gentoo/Fedora package to be sure.

I do not intend to package the python2 variant. For the other two, I
Post by Felix Yan via aur-general
have replied in the tasks.
Thanks for making that clear.

So to make all of this more clear to everyone. I took on the task to
maintain CERN's ROOT a couple of years ago and since then I've involved
myself heavily, I'm a contributor to the project and I use it daily in my
work. Colleagues at CERN that use Arch Linux have been depending on me for
this. I have enabled a lot of new features and worked with upstream to make
even more functionality, bug fixes, etc. Currently, I am working on two new
features with upstream, namely to allow for full build without internal
dependencies, only external, and secondly for python2 and python3
simultaneous support. This is semi possible at the moment, but depends on
me having the time to debug fully 3 packages - Pythia, XRootD & ROOT
itself. On top of that I have shipped several other projects related to
this for people that work on Arch Linux to be able to enjoy - Docker
images, GitLab CIs, SciKit-HEP packages like uproot and so on.

All of this is not a brag, it's not to say I am a better packager, and I am
not asking for special attention. But what I want to make something clear -
not all things can be said in a PKGBUILD. Packaging intentions matter and
simply taking over packages without looking for/listening to the
maintainer's comments may be detrimental. For example, the new features I
worked to bring to the ROOT ecosystem and ones which I plan to work on in
the future are obviously not part of my PKGBUILD.

There's precedence for maintainers of specialized software in the AUR to be

sponsored to become a Trusted User (though it seems there's a preexisting

relationship?).

I am not sure how much this applies to me in this case, but if it does I
can say the following. I am willing to apply for a Trusted User to maintain
ROOT's stack for Arch. I use the ROOT software on a daily basis. I take
great care of the package (the whole stack actually) as my work depends on
it. I have a test bench and people in my professional area use it and
depend on me to bring improvements and new possibilities. I have involved
myself and consider it an on-going duty. I have the skills and know-how to
maintain the ROOT stack and I can say with certainty that AUR's ROOT
package is only second to Fedora's package across other distros. But I also
understand it is not perfect and am interested in making it better as I've
shown previously here and to its users.

If that is not an option, however, then I would like to say to Felix thanks
for taking over and to take `root-extra` as the template for his package
and drop all other variants. This was always the plan after a few things
finally got merged upstream. I can go into detail privately.

Regards,
Konstantin
Post by Felix Yan via aur-general
Hi all,
Thanks for the comments and explanations.
Firstly, I wanna say that I am not asking for special treatment or
anything. Just wanted to discuss in detail what is going on. Secondly, a
few comments stood out to me (in no particular order).
I actually want to move the whole "root" tree, but considering its
Post by Felix Yan via aur-general
number I just started with the easier "leaf" ones.
This is what I suspected to be honest. The packages that were pulled were
way too specific. Well, if you're going to do this, then I'd like to have a
conversation about it. (below)
Regarding FS#60248
Post by Felix Yan via aur-general
Just release the python2 version of the package in the AUR.
Sure, just wanted to be sure that's the expected approach.
What original intention? Packages don't need to meet any intention.
Post by Felix Yan via aur-general
They should be packaged acording to the guidelines
Of course, they do - packages exist for a reason and the way they are
packaged expresses the intention - feature support, type of build,
structure, etc. All of that is beyond scope of packaging standards.
This is fairly common -- while it is nice to get in touch with the AUR
Post by Felix Yan via aur-general
maintainer, we hardly need *permission* to package something for the
repos. As always, you can report bugs with the official packages.
I was not implying *permission* is needed, this is not the point - the
point is letting people, who put their time in, know what's up. In any
case, I listed this as an observation, hence the reason my email was
prompted.
Denied resolution?
Post by Felix Yan via aur-general
...
I fail to see how you're being "denied" anything.
Call it what you want, I tried to re-open all 3 bugs but was denied with
little to no comment/explanation. I wanted to know if python2 is going to
be added by Felix or not - instead I was scolded at the bug and here in
emails. The other bug is a bug as confirmed - also denied to re-open
without explanation/investigation. The third bug was re-opened by Filipe
after my initial email - no need to bash me further about it. So all bugs
were closed & denied to re-open until I made a fuss about it here. That to
me is 'denied'.
Whatever we want.
Of course, but not helpful. I'll explain.
You don't get to act as some sort of concerned citizen here to protect
Post by Felix Yan via aur-general
your packages from the incompetent Devs/TUs when your PKGBUILD contains
this junk.
(Sorry for being harsh, but this is the reaction you invite when you set
yourself up as the superior packager.)
I am not pertaining to be a superior packager and I am not calling anyone
incompetent. This is completely beside the point. I will explain below. But
to address the state of this particular package - it was added 2 weeks ago
in a rush to push a new version upstream, because I maintain my packages
well. This package and another from same time around need a complete
rewrite, which I'm aware of. And this particular style of package was
copied from another [community] package a long time ago, things have
changed as it was pointed out to me here in the AUR. I had intentions to
fix it as soon as I had time. Picking out one package out of the whole
stack, which I have not had time to properly deal with, proves nothing, but
that you aim to shame, rather than to understand where I'm coming from, why
I am worried and that I'm actually looking to be heard and help.
That's a message I entered manually each time, with respect :)
This was not a complaint. Thanks, that's actually the only clue I had my
packages were going somewhere and not just randomly deleted.
I believe that is not true. I even enabled more functionality in
Post by Felix Yan via aur-general
libafterimage, actually.
You mean when you removed `--disable-svg` flag? I might be wrong, but I
think there was a reason to leave it disabled. You'd have to check comments
or Gentoo/Fedora package to be sure.
I do not intend to package the python2 variant. For the other two, I
Post by Felix Yan via aur-general
have replied in the tasks.
Thanks for making that clear.
So to make all of this more clear to everyone. I took on the task to
maintain CERN's ROOT a couple of years ago and since then I've involved
myself heavily, I'm a contributor to the project and I use it daily in my
work. Colleagues at CERN that use Arch Linux have been depending on me for
this. I have enabled a lot of new features and worked with upstream to make
even more functionality, bug fixes, etc. Currently, I am working on two new
features with upstream, namely to allow for full build without internal
dependencies, only external, and secondly for python2 and python3
simultaneous support. This is semi possible at the moment, but depends on
me having the time to debug fully 3 packages - Pythia, XRootD & ROOT
itself. On top of that I have shipped several other projects related to
this for people that work on Arch Linux to be able to enjoy - Docker
images, GitLab CIs, SciKit-HEP packages like uproot and so on.
All of this is not a brag, it's not to say I am a better packager, and I
am not asking for special attention. But what I want to make something
clear - not all things can be said in a PKGBUILD. Packaging intentions
matter and simply taking over packages without looking for/listening to the
maintainer's comments may be detrimental. For example, the new features I
worked to bring to the ROOT ecosystem and ones which I plan to work on in
the future are obviously not part of my PKGBUILD.
There's precedence for maintainers of specialized software in the AUR to be
sponsored to become a Trusted User (though it seems there's a preexisting
relationship?).
I am not sure how much this applies to me in this case, but if it does I
can say the following. I am willing to apply for a Trusted User to maintain
ROOT's stack for Arch. I use the ROOT software on a daily basis. I take
great care of the package (the whole stack actually) as my work depends on
it. I have a test bench and people in my professional area use it and
depend on me to bring improvements and new possibilities. I have involved
myself and consider it an on-going duty. I have the skills and know-how to
maintain the ROOT stack and I can say with certainty that AUR's ROOT
package is only second to Fedora's package across other distros. But I also
understand it is not perfect and am interested in making it better as I've
shown previously here and to its users.
If that is not an option, however, then I would like to say to Felix
thanks for taking over and to take `root-extra` as the template for his
package and drop all other variants. This was always the plan after a few
things finally got merged upstream. I can go into detail privately.
Regards,
Konstantin
Post by Felix Yan via aur-general
Post by Konstantin Gizdov
3. The packages do not provide the same functionality as before, but
conflict with the AUR ones.
I believe that is not true. I even enabled more functionality in
libafterimage, actually.
Post by Konstantin Gizdov
4. I wasn't told anything - my AUR package was deleted with a 'thanks
for
Post by Konstantin Gizdov
maintaining it' message.
That's a message I entered manually each time, with respect :)
Post by Konstantin Gizdov
5. I've reported a few bugs FS#6024{6,7,8}, but have been denied
resolution.
I do not intend to package the python2 variant. For the other two, I
have replied in the tasks.
Post by Konstantin Gizdov
- Why?
- How many & which will be put into [community]?
I actually want to move the whole "root" tree, but considering its
number I just started with the easier "leaf" ones.
Post by Konstantin Gizdov
- How can I effectively communicate the nuts & bolts to the new
maintenaners so to say, to make sure users still get what's expected?
By opening bugs or send me an email directly if it's urgent.
Sorry for the confusion and late reply, it was very late in my TZ when I
work on the packages.
--
Regards,
Felix Yan
Doug Newgard via aur-general
2018-09-30 18:59:28 UTC
Permalink
On Sun, 30 Sep 2018 19:51:47 +0100
Post by Eli Schwartz via aur-general
Denied resolution?
Post by Eli Schwartz via aur-general
...
I fail to see how you're being "denied" anything.
Call it what you want, I tried to re-open all 3 bugs but was denied with
little to no comment/explanation. I wanted to know if python2 is going to
be added by Felix or not - instead I was scolded at the bug and here in
emails. The other bug is a bug as confirmed - also denied to re-open
without explanation/investigation. The third bug was re-opened by Filipe
after my initial email - no need to bash me further about it. So all bugs
were closed & denied to re-open until I made a fuss about it here. That to
me is 'denied'.
This entire paragraph is false. You tried to re-open all 3 tickets when only 2
were closed? On the two that you *did* request re-open, was was never denied.

We can access the history in the bug tracker, don't try to pass lies off as
facts.
Doug Newgard via aur-general
2018-09-30 19:02:50 UTC
Permalink
On Sun, 30 Sep 2018 13:59:28 -0500
Post by Doug Newgard via aur-general
On Sun, 30 Sep 2018 19:51:47 +0100
Post by Eli Schwartz via aur-general
Denied resolution?
Post by Eli Schwartz via aur-general
...
I fail to see how you're being "denied" anything.
Call it what you want, I tried to re-open all 3 bugs but was denied with
little to no comment/explanation. I wanted to know if python2 is going to
be added by Felix or not - instead I was scolded at the bug and here in
emails. The other bug is a bug as confirmed - also denied to re-open
without explanation/investigation. The third bug was re-opened by Filipe
after my initial email - no need to bash me further about it. So all bugs
were closed & denied to re-open until I made a fuss about it here. That to
me is 'denied'.
This entire paragraph is false. You tried to re-open all 3 tickets when only 2
were closed? On the two that you *did* request re-open, was was never denied.
That should read "one was never denied". Also Filipe never played a part in
anything here other than commenting on the one ticket that was never closed.
Post by Doug Newgard via aur-general
We can access the history in the bug tracker, don't try to pass lies off as
facts.
Eli Schwartz via aur-general
2018-09-30 19:16:33 UTC
Permalink
Post by Konstantin Gizdov
Hi all,
Thanks for the comments and explanations.
Firstly, I wanna say that I am not asking for special treatment or
anything. Just wanted to discuss in detail what is going on. Secondly, a
few comments stood out to me (in no particular order).
I actually want to move the whole "root" tree, but considering its
Post by Felix Yan via aur-general
number I just started with the easier "leaf" ones.
This is what I suspected to be honest. The packages that were pulled were
way too specific. Well, if you're going to do this, then I'd like to have a
conversation about it. (below)
Regarding FS#60248
Post by Felix Yan via aur-general
Just release the python2 version of the package in the AUR.
Sure, just wanted to be sure that's the expected approach.
What original intention? Packages don't need to meet any intention.
Post by Felix Yan via aur-general
They should be packaged acording to the guidelines
Of course, they do - packages exist for a reason and the way they are
packaged expresses the intention - feature support, type of build,
structure, etc. All of that is beyond scope of packaging standards.
This is fairly common -- while it is nice to get in touch with the AUR
Post by Felix Yan via aur-general
maintainer, we hardly need *permission* to package something for the
repos. As always, you can report bugs with the official packages.
I was not implying *permission* is needed, this is not the point - the
point is letting people, who put their time in, know what's up. In any
case, I listed this as an observation, hence the reason my email was
prompted.
Denied resolution?
Post by Felix Yan via aur-general
...
I fail to see how you're being "denied" anything.
Call it what you want, I tried to re-open all 3 bugs but was denied with
little to no comment/explanation. I wanted to know if python2 is going to
be added by Felix or not - instead I was scolded at the bug and here in
emails.
Because again, it's hardly a bug, and I'd say the fact that he didn't
add one demonstrates that he *won't*?
Post by Konstantin Gizdov
The other bug is a bug as confirmed - also denied to re-open
without explanation/investigation.
It was not denied to reopen. It was reopened as soon as you asked for
the first time.
Post by Konstantin Gizdov
The third bug was re-opened by Filipe
after my initial email - no need to bash me further about it. So all bugs
were closed & denied to re-open until I made a fuss about it here. That to
me is 'denied'.
The third bug was never reopened, by Filipe or anyone else, since it was
never closed to begin with.
Post by Konstantin Gizdov
Whatever we want.
Of course, but not helpful. I'll explain.
You don't get to act as some sort of concerned citizen here to protect
Post by Felix Yan via aur-general
your packages from the incompetent Devs/TUs when your PKGBUILD contains
this junk.
(Sorry for being harsh, but this is the reaction you invite when you set
yourself up as the superior packager.)
I am not pertaining to be a superior packager and I am not calling anyone
incompetent. This is completely beside the point. I will explain below. But
to address the state of this particular package - it was added 2 weeks ago
in a rush to push a new version upstream, because I maintain my packages
well. This package and another from same time around need a complete
rewrite, which I'm aware of. And this particular style of package was
copied from another [community] package a long time ago, things have
changed as it was pointed out to me here in the AUR. I had intentions to
fix it as soon as I had time. Picking out one package out of the whole
stack, which I have not had time to properly deal with, proves nothing, but
that you aim to shame, rather than to understand where I'm coming from, why
I am worried and that I'm actually looking to be heard and help.
Offtopic: I don't really understand this logic, copying something from a
template like that if you know it's wrong, does not save any time. It's
actually more work to do it wrongly like that.

Anyway, I get that not everyone truly understands how PKGBUILDs work and
sometimes fall prey to terrible examples (though really, you're saying a
community package did this??? which one, I don't think I've seen that
before). Maybe I was too harsh there. On the other hand, this email
thread did not predispose me to being especially generous, what with its
accusations about how we close bugs and don't care about your input even
though this is patently untrue.
Post by Konstantin Gizdov
So to make all of this more clear to everyone. I took on the task to
maintain CERN's ROOT a couple of years ago and since then I've involved
myself heavily, I'm a contributor to the project and I use it daily in my
work. Colleagues at CERN that use Arch Linux have been depending on me for
this. I have enabled a lot of new features and worked with upstream to make
even more functionality, bug fixes, etc. Currently, I am working on two new
features with upstream, namely to allow for full build without internal
dependencies, only external, and secondly for python2 and python3
simultaneous support. This is semi possible at the moment, but depends on
me having the time to debug fully 3 packages - Pythia, XRootD & ROOT
itself. On top of that I have shipped several other projects related to
this for people that work on Arch Linux to be able to enjoy - Docker
images, GitLab CIs, SciKit-HEP packages like uproot and so on.
All of this is not a brag, it's not to say I am a better packager, and I am
not asking for special attention. But what I want to make something clear -
not all things can be said in a PKGBUILD. Packaging intentions matter and
simply taking over packages without looking for/listening to the
maintainer's comments may be detrimental. For example, the new features I
worked to bring to the ROOT ecosystem and ones which I plan to work on in
the future are obviously not part of my PKGBUILD.
That's fine, and you are cordially invited to engage in dialogue to
suggest things to the Devs/TUs. I don't see how this is particularly
special just because you once maintained them in the AUR either -- you
can submit feature requests, or directly email the maintainer for a
lengthy chat, for *any* package. Many of us are also on IRC, and can be
reached in realtime.
Post by Konstantin Gizdov
I am not sure how much this applies to me in this case, but if it does I
can say the following. I am willing to apply for a Trusted User to maintain
ROOT's stack for Arch. I use the ROOT software on a daily basis. I take
great care of the package (the whole stack actually) as my work depends on
it. I have a test bench and people in my professional area use it and
depend on me to bring improvements and new possibilities. I have involved
myself and consider it an on-going duty. I have the skills and know-how to
maintain the ROOT stack and I can say with certainty that AUR's ROOT
package is only second to Fedora's package across other distros. But I also
understand it is not perfect and am interested in making it better as I've
shown previously here and to its users.
If that is not an option, however, then I would like to say to Felix thanks
for taking over and to take `root-extra` as the template for his package
and drop all other variants. This was always the plan after a few things
finally got merged upstream. I can go into detail privately.
No one here is going to say it is or isn't an option (because we are a
consensus so it doesn't entirely work that way), but if you want to
apply, then the general process is described here:
https://wiki.archlinux.org/index.php/Trusted_Users#How_do_I_become_a_TU.3F

It essentially boils down to:

- find an existing TU who is willing to advocate on your behalf by
sponsoring you"
- convince a voting majority of TUs that you're sufficiently capable and
trustworthy to package things as a TU
--
Eli Schwartz
Bug Wrangler and Trusted User
Konstantin Gizdov
2018-09-30 20:16:50 UTC
Permalink
Post by Eli Schwartz via aur-general
It was not denied to reopen. It was reopened as soon as you asked for
the first time.
Yes, by you after I send this email, unless I am mistaken.

The third bug was never reopened, by Filipe or anyone else, since it was
Post by Eli Schwartz via aur-general
never closed to begin with.
Sure, had it wrong in memory. Emails check out.

That's fine, and you are cordially invited to engage in dialogue to
Post by Eli Schwartz via aur-general
suggest things to the Devs/TUs. I don't see how this is particularly
special just because you once maintained them in the AUR either -- you
can submit feature requests, or directly email the maintainer for a
lengthy chat, for *any* package. Many of us are also on IRC, and can be
reached in realtime.
I'd have to say ROOT is unlike your regular software. I was preempting what
proved to be the case and not really too worried about the small python
packages and the smallest lib.
Post by Eli Schwartz via aur-general
Anyway, I get that not everyone truly understands how PKGBUILDs work and
sometimes fall prey to terrible examples (though really, you're saying a
community package did this??? which one, I don't think I've seen that
before). Maybe I was too harsh there.
I was referring to an email exchange that happened 13-16 Oct on this list
(you included) about me using python-scikit-learn as template and then
people said there were major problems. I went and checked my emails this
time to be very correct. But I think the `build_*()` thing maybe came from
another package as commits don't match. But it's a long time ago and don't
remember everything.

On the other hand, this email
Post by Eli Schwartz via aur-general
thread did not predispose me to being especially generous, what with its
accusations about how we close bugs and don't care about your input even
though this is patently untrue.
Well, I wasn't trying to be confrontational. I felt I was being shunned and
tried to be explicit in why I'm writing the email and what bothered me.
Sorry, if someone was offended.
Post by Eli Schwartz via aur-general
- find an existing TU who is willing to advocate on your behalf by
sponsoring you"
I've had a look at that list before and did again just now. I don't know
any TUs personally and beyond asking here if someone is willing to sponsor
me, I don't know what else to do.

Regards,
Konstantin

On Sun, Sep 30, 2018 at 8:16 PM Eli Schwartz via aur-general <
Post by Eli Schwartz via aur-general
Post by Konstantin Gizdov
Hi all,
Thanks for the comments and explanations.
Firstly, I wanna say that I am not asking for special treatment or
anything. Just wanted to discuss in detail what is going on. Secondly, a
few comments stood out to me (in no particular order).
I actually want to move the whole "root" tree, but considering its
Post by Felix Yan via aur-general
number I just started with the easier "leaf" ones.
This is what I suspected to be honest. The packages that were pulled were
way too specific. Well, if you're going to do this, then I'd like to
have a
Post by Konstantin Gizdov
conversation about it. (below)
Regarding FS#60248
Post by Felix Yan via aur-general
Just release the python2 version of the package in the AUR.
Sure, just wanted to be sure that's the expected approach.
What original intention? Packages don't need to meet any intention.
Post by Felix Yan via aur-general
They should be packaged acording to the guidelines
Of course, they do - packages exist for a reason and the way they are
packaged expresses the intention - feature support, type of build,
structure, etc. All of that is beyond scope of packaging standards.
This is fairly common -- while it is nice to get in touch with the AUR
Post by Felix Yan via aur-general
maintainer, we hardly need *permission* to package something for the
repos. As always, you can report bugs with the official packages.
I was not implying *permission* is needed, this is not the point - the
point is letting people, who put their time in, know what's up. In any
case, I listed this as an observation, hence the reason my email was
prompted.
Denied resolution?
Post by Felix Yan via aur-general
...
I fail to see how you're being "denied" anything.
Call it what you want, I tried to re-open all 3 bugs but was denied with
little to no comment/explanation. I wanted to know if python2 is going to
be added by Felix or not - instead I was scolded at the bug and here in
emails.
Because again, it's hardly a bug, and I'd say the fact that he didn't
add one demonstrates that he *won't*?
Post by Konstantin Gizdov
The other bug is a bug as confirmed - also denied to re-open
without explanation/investigation.
It was not denied to reopen. It was reopened as soon as you asked for
the first time.
Post by Konstantin Gizdov
The third bug was re-opened by Filipe
after my initial email - no need to bash me further about it. So all bugs
were closed & denied to re-open until I made a fuss about it here. That
to
Post by Konstantin Gizdov
me is 'denied'.
The third bug was never reopened, by Filipe or anyone else, since it was
never closed to begin with.
Post by Konstantin Gizdov
Whatever we want.
Of course, but not helpful. I'll explain.
You don't get to act as some sort of concerned citizen here to protect
Post by Felix Yan via aur-general
your packages from the incompetent Devs/TUs when your PKGBUILD contains
this junk.
(Sorry for being harsh, but this is the reaction you invite when you set
yourself up as the superior packager.)
I am not pertaining to be a superior packager and I am not calling anyone
incompetent. This is completely beside the point. I will explain below.
But
Post by Konstantin Gizdov
to address the state of this particular package - it was added 2 weeks
ago
Post by Konstantin Gizdov
in a rush to push a new version upstream, because I maintain my packages
well. This package and another from same time around need a complete
rewrite, which I'm aware of. And this particular style of package was
copied from another [community] package a long time ago, things have
changed as it was pointed out to me here in the AUR. I had intentions to
fix it as soon as I had time. Picking out one package out of the whole
stack, which I have not had time to properly deal with, proves nothing,
but
Post by Konstantin Gizdov
that you aim to shame, rather than to understand where I'm coming from,
why
Post by Konstantin Gizdov
I am worried and that I'm actually looking to be heard and help.
Offtopic: I don't really understand this logic, copying something from a
template like that if you know it's wrong, does not save any time. It's
actually more work to do it wrongly like that.
Anyway, I get that not everyone truly understands how PKGBUILDs work and
sometimes fall prey to terrible examples (though really, you're saying a
community package did this??? which one, I don't think I've seen that
before). Maybe I was too harsh there. On the other hand, this email
thread did not predispose me to being especially generous, what with its
accusations about how we close bugs and don't care about your input even
though this is patently untrue.
Post by Konstantin Gizdov
So to make all of this more clear to everyone. I took on the task to
maintain CERN's ROOT a couple of years ago and since then I've involved
myself heavily, I'm a contributor to the project and I use it daily in my
work. Colleagues at CERN that use Arch Linux have been depending on me
for
Post by Konstantin Gizdov
this. I have enabled a lot of new features and worked with upstream to
make
Post by Konstantin Gizdov
even more functionality, bug fixes, etc. Currently, I am working on two
new
Post by Konstantin Gizdov
features with upstream, namely to allow for full build without internal
dependencies, only external, and secondly for python2 and python3
simultaneous support. This is semi possible at the moment, but depends on
me having the time to debug fully 3 packages - Pythia, XRootD & ROOT
itself. On top of that I have shipped several other projects related to
this for people that work on Arch Linux to be able to enjoy - Docker
images, GitLab CIs, SciKit-HEP packages like uproot and so on.
All of this is not a brag, it's not to say I am a better packager, and I
am
Post by Konstantin Gizdov
not asking for special attention. But what I want to make something
clear -
Post by Konstantin Gizdov
not all things can be said in a PKGBUILD. Packaging intentions matter and
simply taking over packages without looking for/listening to the
maintainer's comments may be detrimental. For example, the new features I
worked to bring to the ROOT ecosystem and ones which I plan to work on in
the future are obviously not part of my PKGBUILD.
That's fine, and you are cordially invited to engage in dialogue to
suggest things to the Devs/TUs. I don't see how this is particularly
special just because you once maintained them in the AUR either -- you
can submit feature requests, or directly email the maintainer for a
lengthy chat, for *any* package. Many of us are also on IRC, and can be
reached in realtime.
Post by Konstantin Gizdov
I am not sure how much this applies to me in this case, but if it does I
can say the following. I am willing to apply for a Trusted User to
maintain
Post by Konstantin Gizdov
ROOT's stack for Arch. I use the ROOT software on a daily basis. I take
great care of the package (the whole stack actually) as my work depends
on
Post by Konstantin Gizdov
it. I have a test bench and people in my professional area use it and
depend on me to bring improvements and new possibilities. I have involved
myself and consider it an on-going duty. I have the skills and know-how
to
Post by Konstantin Gizdov
maintain the ROOT stack and I can say with certainty that AUR's ROOT
package is only second to Fedora's package across other distros. But I
also
Post by Konstantin Gizdov
understand it is not perfect and am interested in making it better as
I've
Post by Konstantin Gizdov
shown previously here and to its users.
If that is not an option, however, then I would like to say to Felix
thanks
Post by Konstantin Gizdov
for taking over and to take `root-extra` as the template for his package
and drop all other variants. This was always the plan after a few things
finally got merged upstream. I can go into detail privately.
No one here is going to say it is or isn't an option (because we are a
consensus so it doesn't entirely work that way), but if you want to
https://wiki.archlinux.org/index.php/Trusted_Users#How_do_I_become_a_TU.3F
- find an existing TU who is willing to advocate on your behalf by
sponsoring you"
- convince a voting majority of TUs that you're sufficiently capable and
trustworthy to package things as a TU
--
Eli Schwartz
Bug Wrangler and Trusted User
Felix Yan via aur-general
2018-10-14 21:19:22 UTC
Permalink
Post by Felix Yan via aur-general
I believe that is not true. I even enabled more functionality in
Post by Felix Yan via aur-general
libafterimage, actually.
You mean when you removed `--disable-svg` flag? I might be wrong, but I
think there was a reason to leave it disabled. You'd have to check comments
or Gentoo/Fedora package to be sure.
Yes I did check the comments, which turned out to be a very old comment
about extra dependencies in rxvt-unicode-afterimage if enabled. Since
the mentioned package doesn't even exist today, I believe it's not an
issue anymore.
Post by Felix Yan via aur-general
Post by Felix Yan via aur-general
There's precedence for maintainers of specialized software in the AUR to be
sponsored to become a Trusted User (though it seems there's a preexisting
relationship?).
I am not sure how much this applies to me in this case, but if it does I
can say the following. I am willing to apply for a Trusted User to maintain
ROOT's stack for Arch. I use the ROOT software on a daily basis. I take
great care of the package (the whole stack actually) as my work depends on
it. I have a test bench and people in my professional area use it and
depend on me to bring improvements and new possibilities. I have involved
myself and consider it an on-going duty. I have the skills and know-how to
maintain the ROOT stack and I can say with certainty that AUR's ROOT
package is only second to Fedora's package across other distros. But I also
understand it is not perfect and am interested in making it better as I've
shown previously here and to its users.
Glad to see your TU application, it would be great if you will maintain
the related software in the official repositories instead, as you are
definitely more familiar and I have too many packages already :)

(I somehow forgot to reply to the question above, sorry for the late reply!)
--
Regards,
Felix Yan
Konstantin Gizdov
2018-10-14 21:24:11 UTC
Permalink
Post by Felix Yan via aur-general
Yes I did check the comments, which turned out to be a very old comment
about extra dependencies in rxvt-unicode-afterimage if enabled. Since
the mentioned package doesn't even exist today, I believe it's not an
issue anymore.
That's good. I had to recompile `root` to properly link the other day
and can confirm it worked for me, just wasn't sure in general as I
couldn't find the history anymore.
Post by Felix Yan via aur-general
Post by Felix Yan via aur-general
I believe that is not true. I even enabled more functionality in
Post by Felix Yan via aur-general
libafterimage, actually.
You mean when you removed `--disable-svg` flag? I might be wrong, but I
think there was a reason to leave it disabled. You'd have to check comments
or Gentoo/Fedora package to be sure.
Yes I did check the comments, which turned out to be a very old comment
about extra dependencies in rxvt-unicode-afterimage if enabled. Since
the mentioned package doesn't even exist today, I believe it's not an
issue anymore.
Post by Felix Yan via aur-general
Post by Felix Yan via aur-general
There's precedence for maintainers of specialized software in the AUR to be
sponsored to become a Trusted User (though it seems there's a preexisting
relationship?).
I am not sure how much this applies to me in this case, but if it does I
can say the following. I am willing to apply for a Trusted User to maintain
ROOT's stack for Arch. I use the ROOT software on a daily basis. I take
great care of the package (the whole stack actually) as my work depends on
it. I have a test bench and people in my professional area use it and
depend on me to bring improvements and new possibilities. I have involved
myself and consider it an on-going duty. I have the skills and know-how to
maintain the ROOT stack and I can say with certainty that AUR's ROOT
package is only second to Fedora's package across other distros. But I also
understand it is not perfect and am interested in making it better as I've
shown previously here and to its users.
Glad to see your TU application, it would be great if you will maintain
the related software in the official repositories instead, as you are
definitely more familiar and I have too many packages already :)
(I somehow forgot to reply to the question above, sorry for the late reply!)
Loading...