Hi,
My name is Daniel Bermond and my alias on the AUR and forums is dbermond[1][3].
Bruno Pagani (alias: ArchangeGabriel) is sponsoring my Trusted User application. I would like to highly thank Bruno for accepting to be my sponsor.
I'm a Brazilian doctor (physician). Yes, my job and profession are not related to the computing world, but since childhood I'm an enthusiast of the computing and software world. I've beeing using Linux since many years ago, and it's difficult to tell when I started, but it has been a long time. By searching in the middle of some old things here I could find some old Ubuntu CD-ROMs of the 7.04 (2007) version from the time they still shipped free disks worldwide, so I can for sure say that I have 11 years of Linux usage at minimum. But my initial Linux usage starts even before this, with some old RedHat distribution that didn't run very well on my poor graphics card, at a time that I cannot tell precisely. For many years I did the famous distro-hopping and have used many major distributions: openSUSE, Fedora, Mandrake/Mandriva (when they still existed), PCLinuxOS, Ubuntu and variants, Mint and probably others.
I have started to use Arch in 2015. At that time I was at Linux Mint and feel the need for something better and different. I found myself in need of more recent software, being disappointed with the Mint/Ubuntu outdated ones. I was also very tired to reinstall the system every one (or two) year(s). When Mint went for shipping LTS-only releases, I decided that a rolling release distribution should be my new place. By already having many years of Linux usage and experience in the background, Arch was everything that I was looking for. Added the fact of being able to fully customize my system by building packages that could be easily integrated in the system with pacman.
After felling confident with Arch itself, I've started to contribute packages to the AUR. I can perfectly remember my first one: ffmpeg-full-git. It was, and still is, a pleasure to maintain it, firstly because I was in need for it, and, secondly, because I was contributing back to the community something that was useful for me. Things evolved quickly, I started to maintain more and more packages that I was also in need for, while adopting other orphaned ones, and currently I'm the maintainer of 170+ packages[2].
Some of the packages that I maintained were already brought into the official repositories: - ffnvcodec-headers - intel-gmmlib (formerly named gmmlib on the AUR, adopted by my sponsor Bruno) - intel-media-driver (adopted by my sponsor Bruno Pagani) - libraqm - nccl - pybind11* (TU Santiago announced me that he will bring it into [community])
Among the years, I've studied C, x86 assembly, Python and shellscript. I'm trying to add C++ to the list, already started it, but still need to find more time to dedicate to it. I've made some contributions to the open source world. I have a project of my own called screencast[4], which is a command line interface to record a X11 desktop using FFmpeg, having support for offline recording, live streaming and the capability of adding some effects. It's written in pure POSIX/portable shellscript. Besides this, I've made a few commits here and there into the following open source projects: caffe2[5] (now on pytorch github repository), intel gstreamer media SDK[6][7] and intel media sdk[8]. So I also try to contribute back to some upstream projects when my not-so-wide programming skills allow me. I also report bugs to the upstream open source projects for packages which I maintain on the AUR if I encounter some that affects the building process or my direct usage.
I would like to become a Trusted User to be able to contribute to the Arch community as much as I can.
I would like to bring the following packages into [community]: - advancecomp - kvazaar - intel-media-sdk - libmysofa - openh264 - shine - vmaf
I'm also willing to co-maintain my already mentioned old AUR packages. It would be a pleasure.
I think that's all. Thanks to everyone that is reading and analysing my application.
Best regards, Daniel Bermond
[1] https://aur.archlinux.org/account/dbermond [2] https://aur.archlinux.org/packages/?SeB=M&K=dbermond [3] https://github.com/dbermond/ [4] https://github.com/dbermond/screencast/ [5] https://github.com/pytorch/pytorch/commits?author=dbermond [6] https://github.com/intel/gstreamer-media-SDK/commits?author=dbermond [7] https://github.com/intel/gstreamer-media-SDK/commits/topic_linux_and_window?... [8] https://github.com/Intel-Media-SDK/MediaSDK/commits?author=dbermond
Hi,
I hereby confirm my sponsorship of Daniel.
Let the (new 14 days format) discussion period begin!
Regards, Bruno
P.S.: Please excuse the absence of line wrapping in Daniel e-mail, that’s my fault for having attempted to fix the reverse problem (text editor + TB line wrapping).
Le 14/10/2018 à 21:49, Daniel Bermond via aur-general a écrit :
Hi,
My name is Daniel Bermond and my alias on the AUR and forums is dbermond[1][3].
Bruno Pagani (alias: ArchangeGabriel) is sponsoring my Trusted User application. I would like to highly thank Bruno for accepting to be my sponsor.
I'm a Brazilian doctor (physician). Yes, my job and profession are not related to the computing world, but since childhood I'm an enthusiast of the computing and software world. I've beeing using Linux since many years ago, and it's difficult to tell when I started, but it has been a long time. By searching in the middle of some old things here I could find some old Ubuntu CD-ROMs of the 7.04 (2007) version from the time they still shipped free disks worldwide, so I can for sure say that I have 11 years of Linux usage at minimum. But my initial Linux usage starts even before this, with some old RedHat distribution that didn't run very well on my poor graphics card, at a time that I cannot tell precisely. For many years I did the famous distro-hopping and have used many major distributions: openSUSE, Fedora, Mandrake/Mandriva (when they still existed), PCLinuxOS, Ubuntu and variants, Mint and probably others.
I have started to use Arch in 2015. At that time I was at Linux Mint and feel the need for something better and different. I found myself in need of more recent software, being disappointed with the Mint/Ubuntu outdated ones. I was also very tired to reinstall the system every one (or two) year(s). When Mint went for shipping LTS-only releases, I decided that a rolling release distribution should be my new place. By already having many years of Linux usage and experience in the background, Arch was everything that I was looking for. Added the fact of being able to fully customize my system by building packages that could be easily integrated in the system with pacman.
After felling confident with Arch itself, I've started to contribute packages to the AUR. I can perfectly remember my first one: ffmpeg-full-git. It was, and still is, a pleasure to maintain it, firstly because I was in need for it, and, secondly, because I was contributing back to the community something that was useful for me. Things evolved quickly, I started to maintain more and more packages that I was also in need for, while adopting other orphaned ones, and currently I'm the maintainer of 170+ packages[2].
Some of the packages that I maintained were already brought into the official repositories:
- ffnvcodec-headers
- intel-gmmlib (formerly named gmmlib on the AUR, adopted by my sponsor Bruno)
- intel-media-driver (adopted by my sponsor Bruno Pagani)
- libraqm
- nccl
- pybind11* (TU Santiago announced me that he will bring it into [community])
Among the years, I've studied C, x86 assembly, Python and shellscript. I'm trying to add C++ to the list, already started it, but still need to find more time to dedicate to it. I've made some contributions to the open source world. I have a project of my own called screencast[4], which is a command line interface to record a X11 desktop using FFmpeg, having support for offline recording, live streaming and the capability of adding some effects. It's written in pure POSIX/portable shellscript. Besides this, I've made a few commits here and there into the following open source projects: caffe2[5] (now on pytorch github repository), intel gstreamer media SDK[6][7] and intel media sdk[8]. So I also try to contribute back to some upstream projects when my not-so-wide programming skills allow me. I also report bugs to the upstream open source projects for packages which I maintain on the AUR if I encounter some that affects the building process or my direct usage.
I would like to become a Trusted User to be able to contribute to the Arch community as much as I can.
I would like to bring the following packages into [community]:
- advancecomp
- kvazaar
- intel-media-sdk
- libmysofa
- openh264
- shine
- vmaf
I'm also willing to co-maintain my already mentioned old AUR packages. It would be a pleasure.
I think that's all. Thanks to everyone that is reading and analysing my application.
Best regards, Daniel Bermond
[1] https://aur.archlinux.org/account/dbermond [2] https://aur.archlinux.org/packages/?SeB=M&K=dbermond [3] https://github.com/dbermond/ [4] https://github.com/dbermond/screencast/ [5] https://github.com/pytorch/pytorch/commits?author=dbermond [6] https://github.com/intel/gstreamer-media-SDK/commits?author=dbermond [7] https://github.com/intel/gstreamer-media-SDK/commits/topic_linux_and_window?... [8] https://github.com/Intel-Media-SDK/MediaSDK/commits?author=dbermond
Decided to take a quick look at your PKGBUILDs, and just a few spot checks makes me wonder. The first one I click on is apache-flex-sdk, I see that you aren't the original submitter, so I look at the git log and see that the first thing you did when taking over this was to remove pgp checks from the source. WTF. Look at the PKGBUILD, see a totally useless prepare function, ok, not a big thing. Let's check another one, clicked on flif, see msg2s being used for no reason and bad conflicts. Click on a couple more, see that those issues aren't mistakes, they're a fundamental misunderstanding.
Maybe my perception was colored by that really bad decision to remove the pgp checks, and while the PKGBUILDs are mostly fine, there seems to be things about packaging that you don't understand yet. Is it time to become a TU already?
On 10/14/18 5:03 PM, Doug Newgard via aur-general wrote:
Decided to take a quick look at your PKGBUILDs, and just a few spot checks makes me wonder. The first one I click on is apache-flex-sdk, I see that you aren't the original submitter, so I look at the git log and see that the first thing you did when taking over this was to remove pgp checks from the source. WTF. Look at the PKGBUILD, see a totally useless prepare function, ok, not a big thing. Let's check another one, clicked on flif, see msg2s being used for no reason and bad conflicts. Click on a couple more, see that those issues aren't mistakes, they're a fundamental misunderstanding.
Maybe my perception was colored by that really bad decision to remove the pgp checks, and while the PKGBUILDs are mostly fine, there seems to be things about packaging that you don't understand yet. Is it time to become a TU already?
I usually don't use pgp on my aur packages because people tend to complain a lot about building issues. They fail to handle the keys and start complaining to the packager, and this is a big stress. When dealing with repository packages this is another story, of course. Since this was raised as a main issue, I'll be adding the pgp checks back again.
I know that we should not use msg2 because it's makepkg internal. But it helps to diagnose user problems by helping to identify at which stage a build error is happening. For sure I can remove it if required to. ;)
Regarding the conflicts situation, now I better understand it. I will start to fix it my packages as soon as possible! :)
On 10/14/18 5:35 PM, Daniel Bermond via aur-general wrote:
I usually don't use pgp on my aur packages because people tend to complain a lot about building issues. They fail to handle the keys and start complaining to the packager, and this is a big stress. When dealing with repository packages this is another story, of course. Since this was raised as a main issue, I'll be adding the pgp checks back again.
It's very simple to handle people who refuse to learn how the AUR works: refuse to acknowledge anything they say, and simply respond with "learn how to makepkg".
Removing pgp checks in the general case is not okay, even if "it's just an AUR package, so no one cares about security because it's all garbage, right?"
I know that we should not use msg2 because it's makepkg internal. But it helps to diagnose user problems by helping to identify at which stage a build error is happening. For sure I can remove it if required to. ;)
I've yet to come across a single justified case of using msg2, anyone who knows how to read an error message in the first place doesn't need this help.
There's no rule against it per se, but I regard it as... messy. Especially in the example Doug indicated, it seems to be wildly overcomplicating the build and package functions.
On 10/14/18 7:14 PM, Eli Schwartz via aur-general wrote:
On 10/14/18 5:35 PM, Daniel Bermond via aur-general wrote:
I usually don't use pgp on my aur packages because people tend to complain a lot about building issues. They fail to handle the keys and start complaining to the packager, and this is a big stress. When dealing with repository packages this is another story, of course. Since this was raised as a main issue, I'll be adding the pgp checks back again.
It's very simple to handle people who refuse to learn how the AUR works: refuse to acknowledge anything they say, and simply respond with "learn how to makepkg".
Removing pgp checks in the general case is not okay, even if "it's just an AUR package, so no one cares about security because it's all garbage, right?"
Thanks for the suggestions. I'll use pgp whenever possible on aur packages then.
I know that we should not use msg2 because it's makepkg internal. But it helps to diagnose user problems by helping to identify at which stage a build error is happening. For sure I can remove it if required to. ;)
I've yet to come across a single justified case of using msg2, anyone who knows how to read an error message in the first place doesn't need this help.
There's no rule against it per se, but I regard it as... messy. Especially in the example Doug indicated, it seems to be wildly overcomplicating the build and package functions.
Ok, I'll be removing msg2 from all my packages, or use printf/echo instead like mentioned by Doug in his message.
On 10/14/18 11:35 PM, Daniel Bermond via aur-general wrote:
I usually don't use pgp on my aur packages because people tend to complain a lot about building issues. They fail to handle the keys and start complaining to the packager, and this is a big stress. When dealing with repository packages this is another story, of course. Since this was raised as a main issue, I'll be adding the pgp checks back again.
So let me summarize what you are saying, correct me if im wrong:
You fully know whats all the gizzle with gpg. Instead of acting like a trustable user who follows best practice and spreads good advice and helps teaching people about how all this works properly you prefere to pull the lazy card because its what? big stress? Serious? I don't even find words to describe how untrustworthy this is to the community to prefer to remove GPG signatures instead of educating users?
PS: Did you hear of pinned comments?
WOW I'm speechless at best.
On 15-10-18, Levente Polyak via aur-general wrote:
On 10/14/18 11:35 PM, Daniel Bermond via aur-general wrote:
I usually don't use pgp on my aur packages because people tend to complain a lot about building issues. They fail to handle the keys and start complaining to the packager, and this is a big stress. When dealing with repository packages this is another story, of course. Since this was raised as a main issue, I'll be adding the pgp checks back again.
So let me summarize what you are saying, correct me if im wrong:
You fully know whats all the gizzle with gpg. Instead of acting like a trustable user who follows best practice and spreads good advice and helps teaching people about how all this works properly you prefere to pull the lazy card because its what? big stress? Serious? I don't even find words to describe how untrustworthy this is to the community to prefer to remove GPG signatures instead of educating users?
What a warm way to welcome people. A bit of fact-checking doesn't hurt:
$ pkgver=4.16.1 $ wget "https://www.apache.org/dist/flex/$%7Bpkgver%7D/binaries/apache-flex-sdk-$%7B... $ gpg --verify apache-flex-sdk-4.16.1-bin.tar.gz.asc gpg: assuming signed data in 'apache-flex-sdk-4.16.1-bin.tar.gz' gpg: Signature made mer. 15 nov. 2017 09:44:37 CET gpg: using RSA key 44998F3E242727E94C4BADEB6B0A7EC905061FC8 gpg: Can't check signature: No public key
$ gpg --search-keys 44998F3E242727E94C4BADEB6B0A7EC905061FC8 gpg: data source: http://192.146.137.99:11371 (1) Piotr Zarzycki (CODE SIGNING KEY) piotrz@apache.org 4096 bit RSA key 6B0A7EC905061FC8, created: 2017-06-17 (revoked) Keys 1-1 of 1 for "44998F3E242727E94C4BADEB6B0A7EC905061FC8". Enter number(s), N)ext, or Q)uit >
Baptiste
On 10/15/18 12:27 AM, Baptiste Jonglez wrote:
On 15-10-18, Levente Polyak via aur-general wrote:
On 10/14/18 11:35 PM, Daniel Bermond via aur-general wrote:
I usually don't use pgp on my aur packages because people tend to complain a lot about building issues. They fail to handle the keys and start complaining to the packager, and this is a big stress. When dealing with repository packages this is another story, of course. Since this was raised as a main issue, I'll be adding the pgp checks back again.
So let me summarize what you are saying, correct me if im wrong:
You fully know whats all the gizzle with gpg. Instead of acting like a trustable user who follows best practice and spreads good advice and helps teaching people about how all this works properly you prefere to pull the lazy card because its what? big stress? Serious? I don't even find words to describe how untrustworthy this is to the community to prefer to remove GPG signatures instead of educating users?
What a warm way to welcome people. A bit of fact-checking doesn't hurt:
$ pkgver=4.16.1 $ wget "https://www.apache.org/dist/flex/$%7Bpkgver%7D/binaries/apache-flex-sdk-$%7B... $ gpg --verify apache-flex-sdk-4.16.1-bin.tar.gz.asc gpg: assuming signed data in 'apache-flex-sdk-4.16.1-bin.tar.gz' gpg: Signature made mer. 15 nov. 2017 09:44:37 CET gpg: using RSA key 44998F3E242727E94C4BADEB6B0A7EC905061FC8 gpg: Can't check signature: No public key
$ gpg --search-keys 44998F3E242727E94C4BADEB6B0A7EC905061FC8 gpg: data source: http://192.146.137.99:11371 (1) Piotr Zarzycki (CODE SIGNING KEY) piotrz@apache.org 4096 bit RSA key 6B0A7EC905061FC8, created: 2017-06-17 (revoked) Keys 1-1 of 1 for "44998F3E242727E94C4BADEB6B0A7EC905061FC8". Enter number(s), N)ext, or Q)uit >
Baptiste
Fact checkin what? I didn't respond to a specific case, I responded to a general statement:
"I usually don't use pgp on my aur packages because people tend to complain a lot about building issues."
And that statement applies to parts of your comment as well... no I frankly don't understand that someone would not like to because its stress. We then better add base-devel to makedepends as well, right?
On 10/14/18 7:16 PM, Levente Polyak via aur-general wrote:
On 10/14/18 11:35 PM, Daniel Bermond via aur-general wrote:
I usually don't use pgp on my aur packages because people tend to complain a lot about building issues. They fail to handle the keys and start complaining to the packager, and this is a big stress. When dealing with repository packages this is another story, of course. Since this was raised as a main issue, I'll be adding the pgp checks back again.
So let me summarize what you are saying, correct me if im wrong:
You fully know whats all the gizzle with gpg. Instead of acting like a trustable user who follows best practice and spreads good advice and helps teaching people about how all this works properly you prefere to pull the lazy card because its what? big stress? Serious? I don't even find words to describe how untrustworthy this is to the community to prefer to remove GPG signatures instead of educating users?
PS: Did you hear of pinned comments?
WOW I'm speechless at best.
Sorry then. I'll be using gpg checks whenever it's available from now on.
On Sun, 14 Oct 2018 18:35:53 -0300 Daniel Bermond via aur-general aur-general@archlinux.org wrote:
I usually don't use pgp on my aur packages because people tend to complain a lot about building issues. They fail to handle the keys and start complaining to the packager, and this is a big stress. When dealing with repository packages this is another story, of course. Since this was raised as a main issue, I'll be adding the pgp checks back again.
I know that we should not use msg2 because it's makepkg internal. But it helps to diagnose user problems by helping to identify at which stage a build error is happening. For sure I can remove it if required to. ;)
You're not helping your case. The pgp issue has well been covered, so I'll skip that for now.
For msg2, the response that you know you're not supposed to use it but decided to anyway doesn't inspire confidence. printf or echo would have done the job just as well, but you used something you knew you weren't supposed to?
To clarify, as I originally said, your PKGBUILDs that I spot checked are generally good and I think you could make a good TU. You seem to be willing to work with people, and that's a good sign. There's just some things that make me wonder if now is the time.
Doug
On 10/14/18 7:36 PM, Doug Newgard via aur-general wrote:
On Sun, 14 Oct 2018 18:35:53 -0300 Daniel Bermond via aur-general aur-general@archlinux.org wrote:
I usually don't use pgp on my aur packages because people tend to complain a lot about building issues. They fail to handle the keys and start complaining to the packager, and this is a big stress. When dealing with repository packages this is another story, of course. Since this was raised as a main issue, I'll be adding the pgp checks back again.
I know that we should not use msg2 because it's makepkg internal. But it helps to diagnose user problems by helping to identify at which stage a build error is happening. For sure I can remove it if required to. ;)
You're not helping your case. The pgp issue has well been covered, so I'll skip that for now.
For msg2, the response that you know you're not supposed to use it but decided to anyway doesn't inspire confidence. printf or echo would have done the job just as well, but you used something you knew you weren't supposed to?
Ok, I'll not be using msg2 anymore from now on and will remove it from packages.
To clarify, as I originally said, your PKGBUILDs that I spot checked are generally good and I think you could make a good TU. You seem to be willing to work with people, and that's a good sign. There's just some things that make me wonder if now is the time.
Doug
I understand.
Hi,
On 14-10-18, Doug Newgard via aur-general wrote:
Decided to take a quick look at your PKGBUILDs, and just a few spot checks makes me wonder. The first one I click on is apache-flex-sdk, I see that you aren't the original submitter, so I look at the git log and see that the first thing you did when taking over this was to remove pgp checks from the source. WTF. Look at the PKGBUILD, see a totally useless prepare function, ok, not a big thing. Let's check another one, clicked on flif, see msg2s being used for no reason and bad conflicts. Click on a couple more, see that those issues aren't mistakes, they're a fundamental misunderstanding.
Maybe my perception was colored by that really bad decision to remove the pgp checks, and while the PKGBUILDs are mostly fine, there seems to be things about packaging that you don't understand yet. Is it time to become a TU already?
Well, as always, you could start by not being immediately aggressive towards people.
Judging from the handful of PKGBUILDs I've read, the quality is really high overall, they don't even have most of the "classical" small mistakes (there is source renaming when needed, etc). We don't require new TUs to do everything perfectly, and nothing is ever perfect anyway. There's always something new to learn.
Regarding the PGP checks, there is no question that they are very useful and desirable for packages in our repositories. I am sure that Daniel will make efforts to add PGP checks wherever possible when he moves packages to [community]. But for the AUR, the situation is a bit different (in my opinion) because I know it throws some people off when they don't know that they have to import a PGP key to build the package. I tend to include them anyway now, but I would understand that somebody would like not to.
Anyway, for the specific case of apache-flex-sdk, look at the comments: the signing key simply seemed to have expired.
Baptiste
On Sun, 14 Oct 2018 23:38:54 +0200 Baptiste Jonglez baptiste@bitsofnetworks.org wrote:
Hi,
On 14-10-18, Doug Newgard via aur-general wrote:
Decided to take a quick look at your PKGBUILDs, and just a few spot checks makes me wonder. The first one I click on is apache-flex-sdk, I see that you aren't the original submitter, so I look at the git log and see that the first thing you did when taking over this was to remove pgp checks from the source. WTF. Look at the PKGBUILD, see a totally useless prepare function, ok, not a big thing. Let's check another one, clicked on flif, see msg2s being used for no reason and bad conflicts. Click on a couple more, see that those issues aren't mistakes, they're a fundamental misunderstanding.
Maybe my perception was colored by that really bad decision to remove the pgp checks, and while the PKGBUILDs are mostly fine, there seems to be things about packaging that you don't understand yet. Is it time to become a TU already?
Well, as always, you could start by not being immediately aggressive towards people.
Please read my email again, it was not aggressive in any way. My response to your candidate would be aggressive, I'm still deciding if I want to actually send that.
Judging from the handful of PKGBUILDs I've read, the quality is really high overall, they don't even have most of the "classical" small mistakes (there is source renaming when needed, etc). We don't require new TUs to do everything perfectly, and nothing is ever perfect anyway. There's always something new to learn.
I'm not talking about expecting perfection, I'm seeing consistent issues that point to a possible misunderstanding on how packaging is handled. That is a cause for concern and worth being brought up.
Regarding the PGP checks, there is no question that they are very useful and desirable for packages in our repositories. I am sure that Daniel will make efforts to add PGP checks wherever possible when he moves packages to [community]. But for the AUR, the situation is a bit different (in my opinion) because I know it throws some people off when they don't know that they have to import a PGP key to build the package. I tend to include them anyway now, but I would understand that somebody would like not to.
The situation in the AUR is no different at all. Downgrading PKGBUILDs to appease users who don't want to learn anything is is a serious problem and is a cause for grave concerns.
Anyway, for the specific case of apache-flex-sdk, look at the comments: the signing key simply seemed to have expired.
Baptiste
Hi,
On 14-10-18, Daniel Bermond via aur-general wrote:
My name is Daniel Bermond and my alias on the AUR and forums is dbermond[1][3].
Bruno Pagani (alias: ArchangeGabriel) is sponsoring my Trusted User application. I would like to highly thank Bruno for accepting to be my sponsor.
Welcome here!
I see that you maintain a fair number of useful and popular packages, thanks for the work it represents.
I had a look at some of your packages (including the ones you mention below), and they are in pretty good shape.
I would like to bring the following packages into [community]:
- advancecomp
- kvazaar
- intel-media-sdk
- libmysofa
- openh264
- shine
- vmaf
Out of curiosity, do you plan to only bring these 7 packages to [community], or is it just a highlight? Out of those 7, only 4 are currently maintained by you (unless I'm being tricked by the new co-maintainer feature), and they are not the most popular packages you have.
Baptiste
On 10/14/18 6:12 PM, Baptiste Jonglez wrote:
Hi,
On 14-10-18, Daniel Bermond via aur-general wrote:
My name is Daniel Bermond and my alias on the AUR and forums is dbermond[1][3].
Bruno Pagani (alias: ArchangeGabriel) is sponsoring my Trusted User application. I would like to highly thank Bruno for accepting to be my sponsor.
Welcome here!
Thank you! :)
I see that you maintain a fair number of useful and popular packages, thanks for the work it represents.
I had a look at some of your packages (including the ones you mention below), and they are in pretty good shape.
Thanks again. I'm trying my best to give good packages to aur users.
I would like to bring the following packages into [community]:
- advancecomp
- kvazaar
- intel-media-sdk
- libmysofa
- openh264
- shine
- vmaf
Out of curiosity, do you plan to only bring these 7 packages to [community], or is it just a highlight? Out of those 7, only 4 are currently maintained by you (unless I'm being tricked by the new co-maintainer feature), and they are not the most popular packages you have.
Baptiste
That package list was an initial one and I can bring more packages later. But please note that a significant amount of my packages are either development ones (-git, -hg, etc) or modified packages that already exist on the repos, and those ones are not eligible for [community]. I think the following packages are another good ones to bring into [community], and I'm maintaining:
- firetools - fs-uae - fs-uae-launcher - htmldoc - laptop-mode-tools - libemf - libilbc - mujs
On 10/14/18 3:49 PM, Daniel Bermond via aur-general wrote:
Hi,
My name is Daniel Bermond and my alias on the AUR and forums is dbermond[1][3].
Bruno Pagani (alias: ArchangeGabriel) is sponsoring my Trusted User application. I would like to highly thank Bruno for accepting to be my sponsor.
I'm a Brazilian doctor (physician). Yes, my job and profession are not related to the computing world, but since childhood I'm an enthusiast of the computing and software world. I've beeing using Linux since many years ago, and it's difficult to tell when I started, but it has been a long time. By searching in the middle of some old things here I could find some old Ubuntu CD-ROMs of the 7.04 (2007) version from the time they still shipped free disks worldwide, so I can for sure say that I have 11 years of Linux usage at minimum. But my initial Linux usage starts even before this, with some old RedHat distribution that didn't run very well on my poor graphics card, at a time that I cannot tell precisely. For many years I did the famous distro-hopping and have used many major distributions: openSUSE, Fedora, Mandrake/Mandriva (when they still existed), PCLinuxOS, Ubuntu and variants, Mint and probably others.
I have started to use Arch in 2015. At that time I was at Linux Mint and feel the need for something better and different. I found myself in need of more recent software, being disappointed with the Mint/Ubuntu outdated ones. I was also very tired to reinstall the system every one (or two) year(s). When Mint went for shipping LTS-only releases, I decided that a rolling release distribution should be my new place. By already having many years of Linux usage and experience in the background, Arch was everything that I was looking for. Added the fact of being able to fully customize my system by building packages that could be easily integrated in the system with pacman.
After felling confident with Arch itself, I've started to contribute packages to the AUR. I can perfectly remember my first one: ffmpeg-full-git. It was, and still is, a pleasure to maintain it, firstly because I was in need for it, and, secondly, because I was contributing back to the community something that was useful for me. Things evolved quickly, I started to maintain more and more packages that I was also in need for, while adopting other orphaned ones, and currently I'm the maintainer of 170+ packages[2].
$ package-query -As --maintainer dbermond -f %b | sort -u| wc -l 171
*tries to think how he'll manage to review all these*
Some of the packages that I maintained were already brought into the official repositories: - ffnvcodec-headers - intel-gmmlib (formerly named gmmlib on the AUR, adopted by my sponsor Bruno) - intel-media-driver (adopted by my sponsor Bruno Pagani) - libraqm - nccl - pybind11* (TU Santiago announced me that he will bring it into [community])
Among the years, I've studied C, x86 assembly, Python and shellscript. I'm trying to add C++ to the list, already started it, but still need to find more time to dedicate to it. I've made some contributions to the open source world. I have a project of my own called screencast[4], which is a command line interface to record a X11 desktop using FFmpeg, having support for offline recording, live streaming and the capability of adding some effects. It's written in pure POSIX/portable shellscript.
That's a rather... intimidatingly complex Makefile, by the way. If I might ask, what is the purpose of splitting apart the source files then recombining them like this? It is slightly similar to how makepkg is developed, except we loop through and source a library in /usr/share/makepkg ...
Carving apart the headers with sed and relying on the *order* they are combined, seems to be defeating the purpose at any rate.
...
The Makefile specifies various targets using e.g. PREFIX := /usr/local, surely you meant to use ?= for this? BCOMPDIR should properly be derived from $(shell pkg-config bash-completion --variable completionsdir)
Your other loops here and there could take advantage of *not* being loops, like for make clean, just using rm's builtin -v to print the files being removed.
I also find it rather odd that you take pains to single-quote your static strings in sh snippets like [ -f '$(NAME)' ] and [ -d './test/output' ] But, you don't quote things that need quoting, like: install -Dm755 ... '$(DESTDIR)'...
(Because DESTDIR can have spaces depending on the makepkg BUILDDIR, hence why we always quote "$srcdir" and "$pkgdir", at least until the Makefile mangles it for us.)
Don't feel bad though, you're nowhere near the only offender at this -- GNU autotools does it too, so most Makefiles in the world have this issue.
You probably should not be opinionated in your Makefile, about gzipping the manpage. Packaging tools like makepkg already do this (and maybe make it configurable). I would say it breaks reproducible builds, but you did add the -n flag so at least that is alright.
Besides this, I've made a few commits here and there into the following open source projects: caffe2[5] (now on pytorch github repository), intel gstreamer media SDK[6][7] and intel media sdk[8]. So I also try to contribute back to some upstream projects when my not-so-wide programming skills allow me. I also report bugs to the upstream open source projects for packages which I maintain on the AUR if I encounter some that affects the building process or my direct usage.
I would like to become a Trusted User to be able to contribute to the Arch community as much as I can.
I would like to bring the following packages into [community]: - advancecomp
Too late -- I said I would do that back in my TU application: https://lists.archlinux.org/pipermail/aur-general/2017-December/033719.html
And you've reminded me to do so. :p
- kvazaar - intel-media-sdk - libmysofa - openh264 - shine - vmaf
I'm also willing to co-maintain my already mentioned old AUR packages. It would be a pleasure.
I think that's all. Thanks to everyone that is reading and analysing my application.
Best regards, Daniel Bermond
On 10/14/18 7:06 PM, Eli Schwartz via aur-general wrote:
That's a rather... intimidatingly complex Makefile, by the way. If I might ask, what is the purpose of splitting apart the source files then recombining them like this? It is slightly similar to how makepkg is developed, except we loop through and source a library in /usr/share/makepkg ...
Carving apart the headers with sed and relying on the *order* they are combined, seems to be defeating the purpose at any rate.
The purpose is to have a single script as the final result, instead of an executable with installed modules. And yes, using 'source' (the dot command) was discarded by me during development, so a makefile with split sources was the choice, being it complex or not. ;) Since the final script is huge, this make it easier to use and distribute it (it's just a single file), while making it possible to split the source code into separated parts for easier maintenance in the future, specially if the code keeps growing up. When having such a large script in a single file, it keeps harder and harder to maintain/fix/improve the code, so I decided to make this way.
...
The Makefile specifies various targets using e.g. PREFIX := /usr/local, surely you meant to use ?= for this? BCOMPDIR should properly be derived from $(shell pkg-config bash-completion --variable completionsdir)
Thanks for the suggestions. :)
Your other loops here and there could take advantage of *not* being loops, like for make clean, just using rm's builtin -v to print the files being removed.
Make clean just erases a single file (screencast) if it is present, without looping. Even if it was looping, in this way a get a personalized output message instead of the standard rm message, which I like ;). And this is not a critical part to worry about loops :)
I also find it rather odd that you take pains to single-quote your static strings in sh snippets like [ -f '$(NAME)' ] and [ -d './test/output' ]
I like to quote things in shell code (the part you mentioned are shell ones). That's just my personal approach. You can see this on the .sh sources too.
But, you don't quote things that need quoting, like: install -Dm755 ... '$(DESTDIR)'...
(Because DESTDIR can have spaces depending on the makepkg BUILDDIR, hence why we always quote "$srcdir" and "$pkgdir", at least until the Makefile mangles it for us.)
Ah yes, forgot it there. Thanks for pointing this out! :)
Don't feel bad though, you're nowhere near the only offender at this -- GNU autotools does it too, so most Makefiles in the world have this issue.
I also see this out there ;)
You probably should not be opinionated in your Makefile, about gzipping the manpage. Packaging tools like makepkg already do this (and maybe make it configurable). I would say it breaks reproducible builds, but you did add the -n flag so at least that is alright.
The purpose of this makefile was to present the regular user with a proper and well suited installation. If you check the readme it has an installation section with very basic instructions. Being such, for the regular user perspective it's better to install a gzipped manpage. Packagers can modify this at their will.
I would like to bring the following packages into [community]: - advancecomp
Too late -- I said I would do that back in my TU application: https://lists.archlinux.org/pipermail/aur-general/2017-December/033719.html
And you've reminded me to do so. :p
Oh sorry, I missed you saying this about advancecomp :)
Hi Daniel,
On 10/14/18 9:49 PM, Daniel Bermond via aur-general wrote:
I have a project of my own called screencast[4], which is a command line interface to record a X11 desktop using FFmpeg, having support for offline recording, live streaming and the capability of adding some effects. It's written in pure POSIX/portable shellscript.
Just took some seconds of reading screencast and i noticed the following that you may want to fix as i didn't spot in a 10sec lookup what would mitigate the following:
https://github.com/dbermond/screencast/blob/HEAD/src/settings_general.sh#L31
You are using /tmp here, you should replace processing with a safe user owned directory aquired by `mktemp`.
The reason:
Its vulnerable to symlink attacks, you can delete arbitrary user owned files via: https://github.com/dbermond/screencast/blob/HEAD/src/system.sh#L31
Or steal secret data like ssh or gnipg secret keys by moving it outside of a user-only accessable folder via a `mv` gadget:
https://github.com/dbermond/screencast/blob/HEAD/src/system.sh#L40
cheers, Levente
On 10/14/18 7:10 PM, Levente Polyak via aur-general wrote:
Hi Daniel,
On 10/14/18 9:49 PM, Daniel Bermond via aur-general wrote:
I have a project of my own called screencast[4], which is a command line interface to record a X11 desktop using FFmpeg, having support for offline recording, live streaming and the capability of adding some effects. It's written in pure POSIX/portable shellscript.
Just took some seconds of reading screencast and i noticed the following that you may want to fix as i didn't spot in a 10sec lookup what would mitigate the following:
https://github.com/dbermond/screencast/blob/HEAD/src/settings_general.sh#L31
You are using /tmp here, you should replace processing with a safe user owned directory aquired by `mktemp`.
The reason:
Its vulnerable to symlink attacks, you can delete arbitrary user owned files via: https://github.com/dbermond/screencast/blob/HEAD/src/system.sh#L31
Or steal secret data like ssh or gnipg secret keys by moving it outside of a user-only accessable folder via a `mv` gadget:
https://github.com/dbermond/screencast/blob/HEAD/src/system.sh#L40
cheers, Levente
Hi Levente,
Thank you for pointing this!
Although mktemp is not defined by the POSIX specification, it passes the shellcheck POSIX test with /bin/sh. I think it will not defeat the POSIX purpose of the script. Googling for it suggests that it's present everywhere nowadays. I can check for it's presence on the system and use it if available, otherwise fallback to the poor /tmp or something else.
I'll be implementing this as soon as I can, and also some Eli suggestions.
Hey Daniel,
out of curiosity, what is you tool of choice to keep track of upstream releases? something like urlwatch?
cheers, Levente
Hi Levente,
I use urlwatch and an Android app named Web Alert. The cell phone app is useful for me to receive update notifications on-the-go when the computer(s) is(are) turned off.
But I do not have that much rules listed on them.
On 26/10/2018 15:37, Levente Polyak via aur-general wrote:
Hey Daniel,
out of curiosity, what is you tool of choice to keep track of upstream releases? something like urlwatch?
cheers, Levente
Hi everyone,
Le 14/10/2018 à 21:49, Daniel Bermond via aur-general a écrit :
Hi,
My name is Daniel Bermond and my alias on the AUR and forums is dbermond[1][3].
Bruno Pagani (alias: ArchangeGabriel) is sponsoring my Trusted User application.
The discussion period is over here too, the vote is thus open:
https://aur.archlinux.org/tu/?id=111
Ending next Monday as well. ;)
Bruno
Le 29/10/2018 à 13:22, Bruno Pagani a écrit :
Hi everyone,
Le 14/10/2018 à 21:49, Daniel Bermond via aur-general a écrit :
Hi,
My name is Daniel Bermond and my alias on the AUR and forums is dbermond[1][3].
Bruno Pagani (alias: ArchangeGabriel) is sponsoring my Trusted User application.
The discussion period is over here too, the vote is thus open:
https://aur.archlinux.org/tu/?id=111
Ending next Monday as well. ;)
Bruno
The voting period is over since 10 minutes ago, and here are the results:
– Yes: 33 – No: 8 – Abstain: 6
So, with an awesome 94 % participation and a large majority, congratulations on your new promotion to TU! :D
I’ve upgraded your AUR account to TU, please now proceed with the TODO list at this address:
https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines#TODO_list_f...
And keep up the great work! ;)
Cheers, Bruno
On 05/11/2018 10:29, Bruno Pagani wrote:
Le 29/10/2018 à 13:22, Bruno Pagani a écrit :
Hi everyone,
Le 14/10/2018 à 21:49, Daniel Bermond via aur-general a écrit :
Hi,
My name is Daniel Bermond and my alias on the AUR and forums is dbermond[1][3].
Bruno Pagani (alias: ArchangeGabriel) is sponsoring my Trusted User application.
The discussion period is over here too, the vote is thus open:
https://aur.archlinux.org/tu/?id=111
Ending next Monday as well. ;)
Bruno
The voting period is over since 10 minutes ago, and here are the results:
– Yes: 33 – No: 8 – Abstain: 6
So, with an awesome 94 % participation and a large majority, congratulations on your new promotion to TU! :D
I’ve upgraded your AUR account to TU, please now proceed with the TODO list at this address:
https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines#TODO_list_f...
And keep up the great work! ;)
Cheers, Bruno
I receive this news with great happiness! Amazing! :)
I would like to thank everyone who participated in my application: thanks to the voters (independently of the vote), to the TUs that replied to my application and to everyone involved here! Thank you! :)
Thanks to Eli for the extensive package review. I'll be implementing more and more suggested changed as soon as possible.
And very special thanks to my sponsor Bruno Pagani for being my sponsor, for the guidance and for all the kind support that he spent with me. Thank you Bruno! :D
I'll try my best to contribute to the Arch Linux community.
On 10/14/18 3:49 PM, Daniel Bermond via aur-general wrote:
After felling confident with Arch itself, I've started to contribute packages to the AUR. I can perfectly remember my first one: ffmpeg-full-git. It was, and still is, a pleasure to maintain it, firstly because I was in need for it, and, secondly, because I was contributing back to the community something that was useful for me. Things evolved quickly, I started to maintain more and more packages that I was also in need for, while adopting other orphaned ones, and currently I'm the maintainer of 170+ packages[2].
A bit late to a TU review once again, but I've got some reviews for your AUR packages here. I'd also like to acknowledge that some of these you've likely already fixed, especially the provides/conflicts on -git variants... but I cloned your PKGBUILDs at the beginning of the discussion period and haven't pulled your changes. Some packages were very similar to each other but enabled different build options, e.g. the ffmpeg family -- I may not have mentioned each by name but reviews may apply to multiple packages:
adriconf: - should not conflict with the -git variant - inconsistent use of $variable vs. ${variable}
apache-flex-sdk: - Uses prebuilt releases for open-source code, that's the job of -bin packages. At the very, very least, this is basically completely unsuitable for moving to community... - Why does it explicitly disable stripping? - Pointless prepare function creates copy of file instead of doing the exact same thing in package()
autotrace-nomagick: - Pointless provides for libautotrace.so, nothing needs it and the main autotrace package doesn't provide it. - inconsistent use of $variable vs. ${variable}
blackmagic-decklink-sdk: - This package contorts itself in order to download a file that should just be local:// and have the user download it. If you can make a simple DLAGENTS=() downloader to download it properly, even better -- but reinventing makepkg inside the prepare function is just not something that should be done.
caffe2-cuda: - has the ugly "don't run make because it recompiles it in make install anyway" been reported upstream? Why not just patch the makefile to not depend on the default/all target?
caffe2: - url supports https - While most variables are quoted, exclude_dirs and exclude_libs are not. - exclude_dirs and exclude_libs are created by doing word splitting on the output of find -- use print0 and mapfile -t -d ''
caffe: - url supports https - Makefile mangling is ugly, try python -c 'import sys; print("%s.%s" % sys.version_info[0:2])' or better yet, complain loudly to upstream that source code should not need to be manually cofigured in a world where `pkg-config --cflags python3` exists. - Why are checks disabled? If you absolutely want to enforce them as off by default, use BUILDENV+=(!check), then let users opt in by running makepkg --check - provides/conflicts are ugly and backwards -- primary packages should not conflict with git versions, variants need to provide and conflict the primary package
chromaprint-fftw: - chromaprint package in [extra] is LGPL, this package is GPL. Source code is in fact MIT and happens to mention that it's linked to an LGPL library -- that being ffmpeg, which this package does not use. - Why mention the possibility of linking to ffmpeg, when the whole point is to not be like the [extra] package which does so? - should not conflict the -git version of the base chromaprint package - Why does this provide libchromaprint.so, which nothing can depend on since the [extra] package does not provide it? - Eplicitly sets options to the default OFF state, for tests and tools. Would it be possible to enable this testsuite -- which the [extra] package does not.
confu-git: - Why is this command-line tool provided as a split python2/python3 package? What does the python2 version actually benefit?
crossc: - Upstream license is no longer unknown (!!!) and is now Apache. - base package should not conflict the -git version - - Update: current version is fixed
davs2-git: - What is this if ./configure; then make; else cd "$srcdir" && rm -rf build-10bit; fi
davs2: - What is this if ./configure; then make; else cd "$srcdir" && rm -rf build-10bit; fi
deluge-git: - url supports https - no need to conflict the -stable package, everything should provide and conflict the base deluge package - install script should not delete users as that's a potential security hole - create users using sysusers.d, create data directories using tmpfiles.d and avoid reserving a static UID
eglexternalplatform-git: - doesn't install MIT license; adopted but never fixed
egl-wayland-git: - doesn't install MIT license - autoreconf should be run in prepare, then configure in build, instead of autogen.sh in build
fann: - url supports HTTPS - should not conflict the -git version
ffmpeg-decklink: - should not conflict -git version of base package - source supports HTTPS
ffmpeg-full: - url supports HTTPS - conflicts is full of useless things - prepare does some sort of dance around profile.d, but current makepkg versions re-source /etc/profile after installing deps
ffnvcodec-headers-git: - I'd create the LICENSE file during prepare, not package...
firetools: - source url supports HTTPS
flif: - instead of dancing around each install target, why not skip the messaging and simply build/install all targets in one go
flite1-patched: - why does this even exist? I see there was a build error for the actual flite1 package, and every patch there seems to be something the main package should presumably use.
fontconfig-ubuntu: - for patch in $(cat file) is bad shell scripting, why not while read line < file, instead? This is less wasteful than shelling out to cat, and avoids possibly unwanted word splitting
fp16-git: - The commented-out makedepends and build/check functions are obviously in fact checkdepends instead... right? This should be unified in check(), and check should not be commented out since it should be a user choice to run it without requiring tedious modification of the PKGBUILD. Also makepkg has --nocheck/--check for those who want it.
frei0r-plugins-git: - autoreconf should be run in prepare, then configure in build, instead of autogen.sh in build
fs-uae-launcher: - adopted but never fixed many glaring issues, including being generally quite messy - build function does preparatory patching, referencing outside the BUILDDIR -- there's a comment to the effect since June, adopting packages without fixing their issues means no one else can fix them instead.
fs-uae: - adopted, never updated to migrate off of post_install scripts and onto pacman hooks - url supports HTTPS
fxdiv-git: - The commented-out makedepends and build/check functions are obviously in fact checkdepends instead... right? This should be unified in check(), and check should not be commented out since it should be a user choice to run it without requiring tedious modification of the PKGBUILD. Also makepkg has --nocheck/--check for those who want it.
gst-plugins-intel-msdk: - should not conflict with -git variant
gst-plugins-ugly-git: - style: source array indenting is a bit erratic
htmldoc: - url supports https - should not conflict with -git variant
imagemagick-full: - url supports https - should not conflict with -git variant - please add the check() function corresponding to the package in [extra] - why are these directories configured via a variable at the top of the PKGBUILD? I don't think they'll ever be anywhere else.
intel-graphics-compiler-git: - only needs to conflict with one base package for compute-runtime - makedepends on things in base-devel
intel-media-sdk-git: - cloning in build seems unfortunate, and looking at the git-lfs docs it seems like it should be entirely possible to configure the working copy created by makepkg, then run 'git checkout' for git-lfs to re-apply all filters and checkout the real file contents
intel-media-sdk: - sed line in srcver could probably be replaced by bash substring expansion, unless the algorithm "drop the century" is likely to change - should not conflict with -git variant
intel-media-server-studio: - instead of many printf's I suggest using cat << __EOF__ > foo.pc (it replaces variables unless you \escape them)
intel-media-stack-bin: - only needs to conflict with one base package for intel-media-sdk
intel-seapi-git: - only needs to conflict with one base package for intel-ittnotify
intel-seapi: - instead of running 3 commands to get the python major.minor from an unstable --version meant for humans, use the API: python -c 'import sys; print("%s.%s" % sys.version_info[:2])' - should not conflict with -git variant
isobmff-git: - why rename the submodules? If there's ever any reason to clone them for something else, a shared SRCDEST would allow deduplicating the clones.
kde-gtk-config-git: - adopted but never updated; install script is deprecated by pacman hooks
kitematic: - yay, an electron app... have you investigated trying to debundle and build it against the system electron package
kvazaar: - should not conflict with -git variant
laptop-mode-tools: - find command would be more efficient if it used + instead of ; and also prevents the need to quote in order to avoid being treated as a bash syntax token. No need to quote {} either way.
lib32-lame: - sourceforge download supports https
lib32-lzo: - gcc-multilib is deprecated, and was always part of the multilib-devel group. It's currently provided by the gcc package, which cannot actually generate -m32 code without lib32-gcc-libs installed.
lib32-nvidia-utils-beta: - could use less hackish bash/subprocesses by e.g. echo "${_soname%.so.*}.so" to strip the sover, while read -rd '' line < <(find ... -print0), _soname=${_lib##*/}/...
lib32-schroedinger: - source url should use https
libde265-git: - no need to rename source clone, let people with shared SRCDEST only download one copy of a given source repo. - autoreconf should be run in prepare, then configure in build, instead of autogen.sh in build
libemf: - sourceforge source supports https
libfpx: - "avoid download errors when the upstream version is updated and this package is not yet updated." -- this package updates itself by curling the version every time you execute makepkg, pls revert immediately.
libheif-git: - autoreconf should be run in prepare, then configure in build, instead of autogen.sh in build
libilbc: - provides itself, conflicts with itself minus lib prefix, seems to be a mistake - no need to conflict -git variant
libmfx: - prepare step explicitly overrides source extraction in order to strip the pkgver-versioned extracted sources and dump everything directly in srcdir -- why? - no need to enable staticlib, it doesn't strip static libraries unless they correspond to a shared library anyway - should not conflict with -git variant
libmysofa-git: - no need to rename source clone, let people with shared SRCDEST only download one copy of a given source repo.
libmysofa: - should not conflict with -git variant
libopenmpt-svn: - no need to rename source clone, let people with shared SRCDEST only download one copy of a given source repo.
libopenshot-audio-git: - no need to rename source clone, let people with shared SRCDEST only download one copy of a given source repo.
libopenshot-git: - no need to rename source clone, let people with shared SRCDEST only download one copy of a given source repo. - the imagemagick dance in build() seems odd, the package should depend on a specific interface if it's compiled into the package
libpciaccess-git: - no need to rename source clone, let people with shared SRCDEST only download one copy of a given source repo. - autoreconf should be run in prepare, then configure in build, instead of autogen.sh in build - git clone over https to take advantage of TLS verification - url supports https
libquvi0.4: - sourceforge download supports https
libquvi-scripts0.4: - sourceforge download supports https
libraqm-git: - no need to rename source clone, let people with shared SRCDEST only download one copy of a given source repo. - autoreconf should be run in prepare, then configure in build, instead of autogen.sh in build
libreoffice-extension-vero: - url supports https - style: inconsistent use of tabs and spaces - noextract/prepare dance could be moved to package - unquoted srcdir
libsvm: - url supports https - instead of running 3 commands to get the python major.minor from an unstable --version meant for humans, use the API: python -c 'import sys; print("%s.%s" % sys.version_info[:2])' - these scripts and python modules are top-level stuff using some rather generic names, which may not be the best idea...
libtorrent-rasterbar-git: - autotool.sh should be done in prepare, see if it can be replaced by autoreconf
libumem-git: - patch tries to do way too much, including trimming trailing whitespace, editing redhat spec files, etc. - resulting patchwork adds files and causes makepkg's automatic git checkout to not fully restore the incremental build tree to a patchable state. You can use git apply --index to apply the patch and stage it in git, then the next time makepkg resets the source tree to the current upstream HEAD, it will clean up the indexed files at the same time.
libva-git: - no need to rename source clone, let people with shared SRCDEST only download one copy of a given source repo. - arch-meson passes --buildtype=release and a number of custom meson flags, but --prefix=/usr --buildtype=plain should do the trick in 95% of cases -- obviously the script would not exist if everyone agreed with me, but I do still consider it worth thinking about why you are using it. Arch typically does not provide complex wrappers and macros to obscure the fundamental underpinnings of the build system in a PKGBUILD. :)
libva-intel-driver-git: - why does this "replaces" the non-git version??? - no need to rename source clone, let people with shared SRCDEST only download one copy of a given source repo. - arch-meson passes --buildtype=release and a number of custom meson flags, but --prefix=/usr --buildtype=plain should do the trick in 95% of cases -- obviously the script would not exist if everyone agreed with me, but I do still consider it worth thinking about why you are using it. Arch typically does not provide complex wrappers and macros to obscure the fundamental underpinnings of the build system in a PKGBUILD. :)
libva-utils-git: - no need to rename source clone, let people with shared SRCDEST only download one copy of a given source repo. - arch-meson passes --buildtype=release and a number of custom meson flags, but --prefix=/usr --buildtype=plain should do the trick in 95% of cases -- obviously the script would not exist if everyone agreed with me, but I do still consider it worth thinking about why you are using it. Arch typically does not provide complex wrappers and macros to obscure the fundamental underpinnings of the build system in a PKGBUILD. :)
libvpx-full-git: - url supports https - no need to rename source clone, let people with shared SRCDEST only download one copy of a given source repo. - should not conflict with -git variant
libvpx-git: - no need to rename source clone, let people with shared SRCDEST only download one copy of a given source repo. - should not conflict with -git variant
littleutils-full: - no comment, except I was startled to see both bash and dash in the dependencies. Is there really software which requires a bash installation but sometimes doesn't use it in favor of explicitly /bin/dash (and not even /bin/sh ?)
lzma_alone: - both source and url support https
mame-git: - no need to rename source clone, let people with shared SRCDEST only download one copy of a given source repo.
megaglest-data-git: - CCPL license is one of the common licenses, and definitely not custom - no need to rename source clone, let people with shared SRCDEST only download one copy of a given source repo.
midori-bzr: - makedepends on base-devel packages (pkg-config actually does not exist anymore, it's provided by pkgconf) - why does this clean out the build directory, do incremental builds not work? - should not conflict with -git variant - why are there both bzr and git packages? which one has the canonical development? - post_install docs don't seem very useful
mpv-full-git: - url supports https - no need to rename source clone, let people with shared SRCDEST only download one copy of a given source repo. - should not conflict with -git variant
mpv-full: - url supports https - should not conflict with -git variant
mujs: - url supports https - should not conflict with -git variant
mupen64plus-extraplugins-git: - url supports https - if these are all separate repos and you need to find the latest pkgver of the whole set, maybe it makes sense to package them as different PKGBUILDs...
mupen64plus-git: - instead of unsetting _component, consider making that a local too. ;) - url supports https
mupen64plus-gui-git: - no need to rename source clone, let people with shared SRCDEST only download one copy of a given source repo.
ncmpcpp-git: - url supports https - autoreconf should be run in prepare, then configure in build, instead of autogen.sh in build - should not conflict with variants
ndi-sdk: - Just wanted to say I admire your care in deblobbing that giant *.run script in order to extract the contents without running it. +1
nnpack-git: - no need to rename source clone, let people with shared SRCDEST only download one copy of a given source repo. - staticlibs is not needed if the package only has static libs
nvidia-beta: - url and source support https - I'm skeptical of using the deprecated $startdir to add patches to source=(), instead of explicating them... but either way, this breaks on directories with spaces in them. After carefully quoting "$startdir" you pass it through word splitting again via for i in $(...), but you could have just done standard globbing -- for i in "$startdir"/*.patch; do echo "patchfile is ${i##*/}"; done - install script is deprecated by 60-linux.hook which runs depmod for any module no matter who installs it. - users can probably take care of reloading their X session to get a new nvidia blob on their own...
openshot-bzr: - url supports https - why is there both a git version and a bzr version?
openshot-git: - url supports https - why is there both a git version and a bzr version?
pax: - adopted but never updated, PKGBUILD metadata could use some cleaning up of unused things, self-provides, etc. - url and source support https
pdfchain: - sourceforge source supports https
pingo: - This package contorts itself in order to download a file that should just be local:// and have the user download it. If you can make a simple DLAGENTS=() downloader to download it properly, even better -- but reinventing makepkg inside the prepare function is just not something that should be done.
pitivi-git: - package has been broken for a very long time now, cf. https://bbs.archlinux.org/viewtopic.php?id=237173, you adopted but did not fix it.
pkgcacheclean: - you adopted someone else's paccache clone written in C and uploaded straight to the AUR (the AUR is not meant to provide *source code* hosting). I suggest having it be deleted instead...
pngcrush-bundled: - pngcrush with bundled libpng/zlib of "quirky" usefulness doesn't seem like the sort of thing which would produce smaller png files without modifications to zlib/libpng itself, what's up with that?
psimd-git: - no need to rename source clone, let people with shared SRCDEST only download one copy of a given source repo -- okay, I'll concede with this header-only repo it's unlikely to matter
pthreadpool-git: - no need to rename source clone, let people with shared SRCDEST only download one copy of a given source repo. - staticlibs is not needed if the package only has static libs
pybind11: - Why doesn't this package function simply call python setup.py install --root="${pkgdir}" - url supports https - not really necessary to copy python2/python3 copies of the build directory as the setup.py does not use cheap tricks like 2to3 - testsuite should not be disabled by default
python2-vmaf: - no need to rename source clone, let people with shared SRCDEST only download one copy of a given source repo. - _executable loop can just be while read -rd '' executable ... < <(find ... -print0), or really just for executable in scripts/*.py - should not conflict with -git variant - consider submitting pull request upstream for PEP 394 compliance, to use proper python2 shebang
python-glog: - not really necessary to copy python2/python3 copies of the build directory as the setup.py does not use cheap tricks like 2to3 - I notice upstream has a testsuite, this should be run in check()
python-leveldb: - BSD license must be installed - PyPI url contains unpredictable hashes, see https://wiki.archlinux.org/index.php/Python_package_guidelines#Source
python-lmdb: - I notice upstream has tests, these should be run in check() - not really necessary to copy python2/python3 copies of the build directory as the setup.py does not use cheap tricks like 2to3
python-ninja-syntax: - this seems to be some sketchy kitware fork of private implementation details of the community/ninja package, why does its project page just say "UNKNOWN" and point urls at ninja itself - PyPI url contains unpredictable hashes, see https://wiki.archlinux.org/index.php/Python_package_guidelines#Source - not really necessary to copy python2/python3 copies of the build directory as the setup.py does not use cheap tricks like 2to3
python-nvd3: - PyPI url contains unpredictable hashes, see https://wiki.archlinux.org/index.php/Python_package_guidelines#Source - not really necessary to copy python2/python3 copies of the build directory as the setup.py does not use cheap tricks like 2to3
python-opcodes-git: - no need to rename source clone, let people with shared SRCDEST only download one copy of a given source repo.
....
I didn't end up going further than this, but I noticed some common themes that I liked: - you're pretty reliable about quoting - you're pretty reliable about naming sources uniquely - your packages are usually pretty well written to work as expected
And some that I didn't like: - oftentimes, urls and sources could and should be upgraded to use https, something that Devs/TUs are admittedly not historically careful about either, but we are working on it as indicated by this TODO list: https://www.archlinux.org/todo/use-gpg-signatures-and-https-sources/ Of course, the TODO list has been outstanding for like 2 years now, because it's rather boring administrivium to fix (I find it easier to do so when already modifying a PKGBUILD) - you often disable testsuites or don't include them at all, which is probably along the same logic as having previously removed PGP checks. I don't expect this to be a problem for community packages, but I think they're both issues that should be fixed in the AUR too. makepkg has options to disable both, if users don't want to waste time running these, and IMHO they should be opt-out. - personal nitpicks about some of the bash scripting you use to get the job done in exotic cases
On 29/10/2018 20:30, Eli Schwartz via aur-general wrote:
A bit late to a TU review once again, but I've got some reviews for your AUR packages here. I'd also like to acknowledge that some of these you've likely already fixed, especially the provides/conflicts on -git variants... but I cloned your PKGBUILDs at the beginning of the discussion period and haven't pulled your changes. Some packages were very similar to each other but enabled different build options, e.g. the ffmpeg family -- I may not have mentioned each by name but reviews may apply to multiple packages:
....
Hi Eli and thank you for preparing this review about my packages. This was very helpful! As you have already mentioned, I've applied the fixes that were already suggested by the TUs, especially the gpg and provides/conflicts situations. Now that you've made this deep review I'll continue to apply more changes for the remaining issues. Thank you! :)
I didn't end up going further than this, but I noticed some common themes that I liked:
- you're pretty reliable about quoting
- you're pretty reliable about naming sources uniquely
- your packages are usually pretty well written to work as expected
Thanks for also saying things that are positives. :)
And some that I didn't like:
- oftentimes, urls and sources could and should be upgraded to use https, something that Devs/TUs are admittedly not historically careful about either, but we are working on it as indicated by this TODO list: https://www.archlinux.org/todo/use-gpg-signatures-and-https-sources/ Of course, the TODO list has been outstanding for like 2 years now, because it's rather boring administrivium to fix (I find it easier to do so when already modifying a PKGBUILD)
- you often disable testsuites or don't include them at all, which is probably along the same logic as having previously removed PGP checks. I don't expect this to be a problem for community packages, but I think they're both issues that should be fixed in the AUR too. makepkg has options to disable both, if users don't want to waste time running these, and IMHO they should be opt-out.
- personal nitpicks about some of the bash scripting you use to get the job done in exotic cases
Thanks for pointing these areas where I can improve! :)
Regarding the https case, this was already pointed to me for instance in the firetools package by my sponsor Bruno Pagani during the discussion period, which I promptly changed, as you can see here:
https://aur.archlinux.org/cgit/aur.git/commit/?h=firetools&id=3df4424968...
I'll pay attention about using https sources whenever possible when doing package maintenance and upgrade.
Ok, I'll enable the checks/tests in packages when they're applicable, letting users choose if they want to run it or not.
Thanks again.
aur-general@lists.archlinux.org