Re: [aur-general] Critique my pkgbuild
Hello again,
It took me a while to have some time, but I believe I have fixed all of the
issues that were pointed out to me, with some help from Scimmia and eschwartz.
I think the package is in much more presentable shape, I have learned plenty,
and I fixed a lot of naive mistakes. Thanks everyone for the help.
I would very much appreciate it if you would all take the time to read the
latest PKGBUILD (from the git version of the package) pasted below and see if
there is anything I missed. Thanks!
# Maintainer: Ethan Rakoff
pkgname=threemawebqt-git
pkgver=r2.079de78
pkgrel=1
pkgdesc="Thin client for Threema Web, an E2E encrypted messaging app."
arch=('i686' 'x86_64')
url="https://github.com/ethanrakoff/${pkgname%-*};
license=('MIT')
depends=('qt5-base' 'qt5-webengine')
makedepends=('git')
source=("git+${url}")
md5sums=('SKIP')
pkgver() {
cd "${pkgname%-*}"
printf "r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short
HEAD)"
}
build() {
cd "${pkgname%-*}"
qmake "PREFIX=/usr"
make
}
package() {
cd "${pkgname%-*}"
make INSTALL_ROOT="${pkgdir}" install
install -Dm644 LICENSE "${pkgdir}/usr/share/licenses/${pkgname%-*}/LICENSE"
}
Ethan Rakoff
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Wednesday, October 10, 2018 2:32 PM, Eli Schwartz via aur-general
wrote:
> On 10/10/18 9:34 AM, Ethan Rakoff wrote:
>
> > I have submitted a package called threemawebqt to the aur (mostly for
> > me, and some friends who use arch). It is a VERY simple thin client for
> > a webapp using Qt. This is my first pkgbuild from scratch (and my first
> > time working with Qt) so even though it is a super simple one, I would
> > like some others to look at it and let me know what I'm doing wrong.
> > Thanks!
> > Here is the pkgbuild for easy reading:
> >
> > Maintainer: Ethan Rakoff et...@ethanrakoff.com
> >
> > ===
> >
> > pkgname=threemawebqt
> > pkgver=0.1
> > pkgrel=1
> > pkgdesc="Thin client for Threema Web, the web client for Threema, an E2E
> > encrypted messaging app."
>
> That's a rather lengthy pkgdesc, what about:
> "thin client for the Threema Web E2E encrypted messaging app"
>
> > arch=('i686' 'x86_64')
> > url="https://github.com/ethanrakoff/${pkgname};
> > license=('MIT')
> > depends=('qt5-base' 'qt5-webengine')
> > makedepends=('make')
>
> You specified "make" as a dependency, which is already in base-devel,
> but not "git", which you need to download sources.
>
> Protip: you can catch issues like this (where your
> coincidentally-installed programs are actually needed to build) by
> checking that your package still builds in a clean chroot using the
> mkarchroot and makechrootpkg commands from [extra]/devtools. Or use the
> extra-x86_64-build convenience wrapper.
>
> > source=("git+${url}")
>
> I like it when people use variables just because they exist, so keep up
> the good work!
>
> Also this underlines the association between the url and the source
> download.
>
> > md5sums=('SKIP')
> > build() {
> > cd "${pkgname}/src"
> > qmake
> > make
> > }
> > package() {
> > cd "${srcdir}/${pkgname}/src"
> > make INSTALL_ROOT="${pkgdir}" install
> > install -Dm644 icon.png "${pkgdir}/usr/share/icons/${pkgname}/icon.png"
> > install -Dm644 ../threemawebqt.desktop
> > "${pkgdir}/usr/share/applications/threemawebqt.desktop"
> > install -Dm644 ../LICENSE
> > "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
> > }
>
> Since you're the upstream developer, you have the opportunity to fix
> your qmake configuration.
>
> It doesn't respect any sort of --prefix option, but hardcodes
> /usr/local/bin/ as the install location. You can have this determined at
> qmake time using e.g.
> https://stackoverflow.com/questions/7106442/qt-project-files-and-prefix-variable/7106823#7106823
>
> It should not require one to install the desktop file and icon by hand,
> but add these as additional "thing.files".
>
> The license file is not required to run, and distributions often have
> different ideas about where to install it for distribution packages...
> so you don't need to install it too.
>
> ...
>
> Correspondingly, the desktop file should not hardcode the Exec path, but
> rely on it being in the system $PATH. Likewise, the Icon should not be
> /usr/share/icons/threemawebqt/icon.png but instead "threemawebqt", and
> you should install icon.png as "threemawebqt.png" to a directory that
> obeys the XDG icon theme specification:
> https://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#directory_layout
>
> e.g. /usr/share/pixmaps/ or /usr/share/icons/hicolor/128x128/apps/
>
> ...
>
> Also your *_DIR setup uses the parent directory but assumes that it is
> run from the src/ folder, look what happens if you try to run
>
> cd /tmp
> git clone https://github.com/ethanrakoff/threemawebqt /tmp/threemawebqt
> cd /tmp/threemawebqt
> qmake
Re: [aur-general] TU Application: Daniel Bermond (dbermond)
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 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. -- Best regards, Daniel Bermond signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU Application: Daniel Bermond (dbermond)
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. -- Best regards, Daniel Bermond signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU Application: Daniel Bermond (dbermond)
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. -- Best regards, Daniel Bermond signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU Application: Daniel Bermond (dbermond)
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. -- Best regards, Daniel Bermond signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU Application: Daniel Bermond (dbermond)
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 :) -- Best regards, Daniel Bermond signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU Application: Daniel Bermond (dbermond)
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 -- Best regards, Daniel Bermond signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU Application - Konstantin Gizdov
On 14/10/2018 23:24, Levente Polyak via aur-general wrote: > Hey Konstantin, > > > On 10/14/18 11:41 PM, Konstantin Gizdov wrote: o llvm50 o llvm50-libs o clang50 > Didn't dig into it myself as its easier to ask, could you maybe > elaborate why we would need those 50 versioned variants? Normally we try > to keep the number of versioned variants to the very minimum and only > throw them in as a last resort because of mayor incompatibilities :) > > cheers, > Levente > Yeah, I know. This is from way back and a core issue. As it stands now, ROOT requires a custom patched version of Clang 5.x.x to build it's Cling interpreter. A year ago, it couldn't even build against an external LLVM. I've been pushing for some patches upstream to make LLVM external. For the moment, ROOT still requires a built-in build of Clang 5.0, but that obviously does not include all latest fixes upstream. So moving to LLVM 5.0.2 external and pushing for more changes to support Clang external too will correct that. And the next step will be to more to more recent LLVM stack versions. Regards, Konstantin signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU Application: Daniel Bermond (dbermond)
On Sun, 14 Oct 2018 18:35:53 -0300 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. > > 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 pgpZqnEYvOlHw.pgp Description: OpenPGP digital signature
Re: [aur-general] TU Application: Daniel Bermond (dbermond)
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/${pkgver}/binaries/apache-flex-sdk-${pkgver}-bin.tar.gz"{,.asc}
> $ 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)
>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?
signature.asc
Description: OpenPGP digital signature
Re: [aur-general] TU Application: Daniel Bermond (dbermond)
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/${pkgver}/binaries/apache-flex-sdk-${pkgver}-bin.tar.gz"{,.asc}
$ 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)
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
signature.asc
Description: PGP signature
Re: [aur-general] TU Application - Konstantin Gizdov
Hey Konstantin, On 10/14/18 11:41 PM, Konstantin Gizdov wrote: >>> o llvm50 >>> o llvm50-libs >>> o clang50 Didn't dig into it myself as its easier to ask, could you maybe elaborate why we would need those 50 versioned variants? Normally we try to keep the number of versioned variants to the very minimum and only throw them in as a last resort because of mayor incompatibilities :) cheers, Levente signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU Application - Konstantin Gizdov
On 10/14/18 11:41 PM, Konstantin Gizdov wrote: > Sure, I can share the load. I've built tensorflow+cuda from scratch a > couple of times and completely understand the struggle. :) > Reminder to always bottom-post on Arch mailinglists ;) signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU Application: Daniel Bermond (dbermond)
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. signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU Application: Daniel Bermond (dbermond)
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. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU Application: Daniel Bermond (dbermond)
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 signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU Application: Daniel Bermond (dbermond)
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
Re: [aur-general] TU Application: Daniel Bermond (dbermond)
On Sun, 14 Oct 2018 23:38:54 +0200 Baptiste Jonglez 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 pgpjvhAnzG3Ge.pgp Description: OpenPGP digital signature
Re: [aur-general] TU Application - Konstantin Gizdov
Sure, I can share the load. I've built tensorflow+cuda from scratch a couple of times and completely understand the struggle. :) On 14/10/2018 22:31, Sven-Hendrik Haase wrote: > On Sun, Oct 14, 2018, 22:34 Konstantin Gizdov wrote: > >> Hello, >> >> I am Konstantin Gizdov [1] [2], >> (`kgizdov`, `a...@kge.pw`, `kgiz...@gmail.com`) >> >> I would like to apply to be a Trusted User under Baptiste Jonglez's >> sponsorship. >> >> A few words about me: >> >> I am currently a Particle Physics PhD at Univerisity of Edinburgh and I >> have used Linux since my early teenage years. After I finished >> high-school, Linux has been my main operating system. I embraced Open >> Source software for a long time ago and contribute to such several >> projects [2][3][4]. I have been with Arch Linux since 4+ years ago, >> although only more active since 2+ years. >> >> My main work is concentrated on Experimental Particle Physics & the LHCb >> Detector at the Large Hadron Collider at CERN. As part of that I have >> been involved in the development, upgrade & maintenance of the >> High-Level Trigger & RICH systems and LHCb's data flow [3]. I also have >> experience with a lot of data processing & analysis - data distillation >> & enrichment, machine learning, statistical analysis, etc - and >> associated tools. Separately, I maintain several machines - a personal >> web server, company server with several VMs, local workhorse server, >> personal workstation & laptop (sprinkle around some RaspberryPis and >> network devices here and there). This put me in a unique position to >> work with many and different kinds of systems and software - ranging >> from ASICs & FPGAs, through localized control systems & end-user devices >> to large clusters & super computers. Daily, I use popular tools such as >> VMs, docker, git, GCC, CUDA, tensorflow, Cern's ROOT, but I also run a >> lot of custom and even-self made software [4][6]. All of this has been a >> breeze on Arch Linux. >> >> Thus, a couple of years ago, I decide to get more involved and >> contribute. I took on the task to maintain CERN's ROOT package [7] and >> since then I've involved myself heavily into that, I'm a contributor to >> the project and I use it daily in my work. I have been providing this >> package for many colleagues in the field, including all of its stack & >> complementary tools (Pythia, XRootD & other Python tools). I have >> enabled a lot of new features and worked with upstream towards new >> functionality, bug fixes, etc. On top of that I have shipped several >> other related projects - machine learning packages, SciKit-HEP packages >> like uproot, Docker images, GitLab CIs and so on. >> >> I have also been able to develop and publish a machine learning project >> me and colleague came up with [4]. This is soon going to be a package in >> SciKit-HEP and I will aim to make it package here too. Arch Linux was a >> great platform for all of this. I was able to install & configure >> up-to-date software easily and what I did not find, I provided for me & >> others on the AUR without too much hassle. >> >> Overall, I have to say Arch Linux (and its community) have played a key >> role in me being able to do all of these things. I have found the OS >> itself to be stable and flexible and the users & maintainers >> approachable and direct, which I appreciate a lot. I have met a lot of >> people through the Arch Linux community - forums, AUR and just saying 'I >> use Arch, too!', haha. >> >> The reason for applying to become a TU is to get even more involved and >> give back to the community. If you accept me, I would like to continue >> maintaining and improving my current packages as well as bring new >> packages. As an AUR maintainer I basically consider it an on-going duty >> already. >> >> I would like to maintain/contribute/adopt the following: >> >> * Packages I would like to co-maintain: >> o python-awkward >> o libafterimage >> o xxhash >> o unuran >> * Packages I already maintain and intend to move from AUR: >> o root & root-extra >> o xrootd >> o simpletools >> o root5 >> o python-root_numpy >> o python-uproot >> o python-uproot-methods >> o python-hep_ml >> o pythia >> o llvm50 >> o llvm50-libs >> o clang50 >> * New packages I would like to add/move from AUR: >> o cern-vdt >> o cvmfs >> o HepDrone [4] >> o python-keras >> o root_pandas (new) >> o histbook (new) >> o decaylanguage (new) >> o pyjet (new) >> o vegascope (new) >> o root_ufunc (new) >> o formulate (new) >> >> I hope to make Arch Linux more versatile and accessible to users in data >> science, high-energy physics & machine learning, and possibly as a whole. >> >> Thank you. >> >> -- >> Regards, >> >> Konstantin >> >> 1. https://keybase.io/kgizdov >> 2. https://github.com/kgizdov >> 3. https://gitlab.cern.ch/kgizdov >> 4.
Re: [aur-general] TU Application: Daniel Bermond (dbermond)
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 signature.asc Description: PGP signature
Re: [aur-general] TU Application: Daniel Bermond (dbermond)
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! :) -- Best regards, Daniel Bermond signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU Application - Konstantin Gizdov
On Sun, Oct 14, 2018, 22:34 Konstantin Gizdov wrote: > Hello, > > I am Konstantin Gizdov [1] [2], > (`kgizdov`, `a...@kge.pw`, `kgiz...@gmail.com`) > > I would like to apply to be a Trusted User under Baptiste Jonglez's > sponsorship. > > A few words about me: > > I am currently a Particle Physics PhD at Univerisity of Edinburgh and I > have used Linux since my early teenage years. After I finished > high-school, Linux has been my main operating system. I embraced Open > Source software for a long time ago and contribute to such several > projects [2][3][4]. I have been with Arch Linux since 4+ years ago, > although only more active since 2+ years. > > My main work is concentrated on Experimental Particle Physics & the LHCb > Detector at the Large Hadron Collider at CERN. As part of that I have > been involved in the development, upgrade & maintenance of the > High-Level Trigger & RICH systems and LHCb's data flow [3]. I also have > experience with a lot of data processing & analysis - data distillation > & enrichment, machine learning, statistical analysis, etc - and > associated tools. Separately, I maintain several machines - a personal > web server, company server with several VMs, local workhorse server, > personal workstation & laptop (sprinkle around some RaspberryPis and > network devices here and there). This put me in a unique position to > work with many and different kinds of systems and software - ranging > from ASICs & FPGAs, through localized control systems & end-user devices > to large clusters & super computers. Daily, I use popular tools such as > VMs, docker, git, GCC, CUDA, tensorflow, Cern's ROOT, but I also run a > lot of custom and even-self made software [4][6]. All of this has been a > breeze on Arch Linux. > > Thus, a couple of years ago, I decide to get more involved and > contribute. I took on the task to maintain CERN's ROOT package [7] and > since then I've involved myself heavily into that, I'm a contributor to > the project and I use it daily in my work. I have been providing this > package for many colleagues in the field, including all of its stack & > complementary tools (Pythia, XRootD & other Python tools). I have > enabled a lot of new features and worked with upstream towards new > functionality, bug fixes, etc. On top of that I have shipped several > other related projects - machine learning packages, SciKit-HEP packages > like uproot, Docker images, GitLab CIs and so on. > > I have also been able to develop and publish a machine learning project > me and colleague came up with [4]. This is soon going to be a package in > SciKit-HEP and I will aim to make it package here too. Arch Linux was a > great platform for all of this. I was able to install & configure > up-to-date software easily and what I did not find, I provided for me & > others on the AUR without too much hassle. > > Overall, I have to say Arch Linux (and its community) have played a key > role in me being able to do all of these things. I have found the OS > itself to be stable and flexible and the users & maintainers > approachable and direct, which I appreciate a lot. I have met a lot of > people through the Arch Linux community - forums, AUR and just saying 'I > use Arch, too!', haha. > > The reason for applying to become a TU is to get even more involved and > give back to the community. If you accept me, I would like to continue > maintaining and improving my current packages as well as bring new > packages. As an AUR maintainer I basically consider it an on-going duty > already. > > I would like to maintain/contribute/adopt the following: > > * Packages I would like to co-maintain: > o python-awkward > o libafterimage > o xxhash > o unuran > * Packages I already maintain and intend to move from AUR: > o root & root-extra > o xrootd > o simpletools > o root5 > o python-root_numpy > o python-uproot > o python-uproot-methods > o python-hep_ml > o pythia > o llvm50 > o llvm50-libs > o clang50 > * New packages I would like to add/move from AUR: > o cern-vdt > o cvmfs > o HepDrone [4] > o python-keras > o root_pandas (new) > o histbook (new) > o decaylanguage (new) > o pyjet (new) > o vegascope (new) > o root_ufunc (new) > o formulate (new) > > I hope to make Arch Linux more versatile and accessible to users in data > science, high-energy physics & machine learning, and possibly as a whole. > > Thank you. > > -- > Regards, > > Konstantin > > 1. https://keybase.io/kgizdov > 2. https://github.com/kgizdov > 3. https://gitlab.cern.ch/kgizdov > 4. https://github.com/Tevien/HEPDrone > 5. https://github.com/scikit-hep > 6. https://gitlab.cern.ch/kgizdov/pdqa-automation Great stuff. Would you be interested in co-maintaining tensorflow, cuda and pytorch and related packages? They sometimes cost a lot of time to fix up.
Re: [aur-general] Questions about some of my packages being adopted in [community]
> 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. On 14/10/2018 22:19, Felix Yan wrote: > On 10/1/18 2:51 AM, Konstantin Gizdov wrote: >> I believe that is not true. I even enabled more functionality in >>> 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. > >>> 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!) > signature.asc Description: OpenPGP digital signature
Re: [aur-general] Questions about some of my packages being adopted in [community]
On 10/1/18 2:51 AM, Konstantin Gizdov wrote: > I believe that is not true. I even enabled more functionality in >> 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. >> 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 signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU Application: Daniel Bermond (dbermond)
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 signature.asc Description: PGP signature
Re: [aur-general] TU Application - Konstantin Gizdov
Hi, On 14-10-18, Konstantin Gizdov wrote: > I am Konstantin Gizdov [1] [2], > (`kgizdov`, `a...@kge.pw`, `kgiz...@gmail.com`) > > I would like to apply to be a Trusted User under Baptiste Jonglez's > sponsorship. I confirm my sponsorship of Konstantin. Let the discussion period begin, it seems to be a good day to apply to become a TU! Baptiste signature.asc Description: PGP signature
[aur-general] TU Application - Konstantin Gizdov
Hello, I am Konstantin Gizdov [1] [2], (`kgizdov`, `a...@kge.pw`, `kgiz...@gmail.com`) I would like to apply to be a Trusted User under Baptiste Jonglez's sponsorship. A few words about me: I am currently a Particle Physics PhD at Univerisity of Edinburgh and I have used Linux since my early teenage years. After I finished high-school, Linux has been my main operating system. I embraced Open Source software for a long time ago and contribute to such several projects [2][3][4]. I have been with Arch Linux since 4+ years ago, although only more active since 2+ years. My main work is concentrated on Experimental Particle Physics & the LHCb Detector at the Large Hadron Collider at CERN. As part of that I have been involved in the development, upgrade & maintenance of the High-Level Trigger & RICH systems and LHCb's data flow [3]. I also have experience with a lot of data processing & analysis - data distillation & enrichment, machine learning, statistical analysis, etc - and associated tools. Separately, I maintain several machines - a personal web server, company server with several VMs, local workhorse server, personal workstation & laptop (sprinkle around some RaspberryPis and network devices here and there). This put me in a unique position to work with many and different kinds of systems and software - ranging from ASICs & FPGAs, through localized control systems & end-user devices to large clusters & super computers. Daily, I use popular tools such as VMs, docker, git, GCC, CUDA, tensorflow, Cern's ROOT, but I also run a lot of custom and even-self made software [4][6]. All of this has been a breeze on Arch Linux. Thus, a couple of years ago, I decide to get more involved and contribute. I took on the task to maintain CERN's ROOT package [7] and since then I've involved myself heavily into that, I'm a contributor to the project and I use it daily in my work. I have been providing this package for many colleagues in the field, including all of its stack & complementary tools (Pythia, XRootD & other Python tools). I have enabled a lot of new features and worked with upstream towards new functionality, bug fixes, etc. On top of that I have shipped several other related projects - machine learning packages, SciKit-HEP packages like uproot, Docker images, GitLab CIs and so on. I have also been able to develop and publish a machine learning project me and colleague came up with [4]. This is soon going to be a package in SciKit-HEP and I will aim to make it package here too. Arch Linux was a great platform for all of this. I was able to install & configure up-to-date software easily and what I did not find, I provided for me & others on the AUR without too much hassle. Overall, I have to say Arch Linux (and its community) have played a key role in me being able to do all of these things. I have found the OS itself to be stable and flexible and the users & maintainers approachable and direct, which I appreciate a lot. I have met a lot of people through the Arch Linux community - forums, AUR and just saying 'I use Arch, too!', haha. The reason for applying to become a TU is to get even more involved and give back to the community. If you accept me, I would like to continue maintaining and improving my current packages as well as bring new packages. As an AUR maintainer I basically consider it an on-going duty already. I would like to maintain/contribute/adopt the following: * Packages I would like to co-maintain: o python-awkward o libafterimage o xxhash o unuran * Packages I already maintain and intend to move from AUR: o root & root-extra o xrootd o simpletools o root5 o python-root_numpy o python-uproot o python-uproot-methods o python-hep_ml o pythia o llvm50 o llvm50-libs o clang50 * New packages I would like to add/move from AUR: o cern-vdt o cvmfs o HepDrone [4] o python-keras o root_pandas (new) o histbook (new) o decaylanguage (new) o pyjet (new) o vegascope (new) o root_ufunc (new) o formulate (new) I hope to make Arch Linux more versatile and accessible to users in data science, high-energy physics & machine learning, and possibly as a whole. Thank you. -- Regards, Konstantin 1. https://keybase.io/kgizdov 2. https://github.com/kgizdov 3. https://gitlab.cern.ch/kgizdov 4. https://github.com/Tevien/HEPDrone 5. https://github.com/scikit-hep 6. https://gitlab.cern.ch/kgizdov/pdqa-automation signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU Application: Daniel Bermond (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? pgplsmnZ8qVUJ.pgp Description: OpenPGP digital signature
Re: [aur-general] TU Application: Daniel Bermond (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=dbermond > [3] https://github.com/dbermond/ > [4] https://github.com/dbermond/screencast/ > [5] https://github.com/pytorch/pytorch/commits?author=dbermond > [6]
[aur-general] TU Application: Daniel Bermond (dbermond)
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=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?author=dbermond [8] https://github.com/Intel-Media-SDK/MediaSDK/commits?author=dbermond signature.asc Description: OpenPGP digital signature
