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
On Sat, Sep 29, 2018 at 7:57 PM Konstantin Gizdov arch@kge.pw wrote:
- 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?).
- 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.
On Sat, 2018-09-29 at 20:57 +0100, Konstantin Gizdov wrote:
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:
- 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.
- '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.
- 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.
- 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.
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?
Why what? Why were they moved? I don't know for sure but if they're moderately popular, there's your reason.
- How many & which will be put into [community]?
Popular packages could be moved to community if a TU wants to maintain them.
- 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.
- 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
On 9/29/18 3:57 PM, Konstantin Gizdov wrote:
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:
- 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.
- '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.
- 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.
- 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.
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:
This is definitely you getting ahead of something. :(
- Why?
- How many & which will be put into [community]?
Whatever we want.
- 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.)
- 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.
On Sun, Sep 30, 2018 at 12:32 PM Eli Schwartz via aur-general aur-general@archlinux.org wrote:
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
On 9/29/18 11:13 PM, Mike Sampson wrote:
On Sun, Sep 30, 2018 at 12:32 PM Eli Schwartz via aur-general aur-general@archlinux.org wrote:
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...
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.
On 9/30/18 3:57 AM, Konstantin Gizdov wrote:
- 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.
- 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 :)
- 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.
- 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.
- 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.
aur-general@lists.archlinux.org