Re: [aur-general] TU resignation
On 20/12/2020 11:17, Baptiste Jonglez wrote: Hi, I have been less active in Arch for some time. I'm involved in many other projects that end up taking lots of time, and as a result I don't have the required time / energy / interest for Arch anymore. When my last Arch machine died recently after 10 years of loyal Arch service, it was a good sign that I should make this official. With that being said, I am resigning as a TU. I've had some, let's say, "disagreements" with a few members of the team over the years, but overall it was a positive experience. Keep up the good work, and take care of this delicate balance between technical excellence and community-minded approach. Thank you Baptiste for your work through these years and for caring about how Arch Linux should be conducted. I wish you all the best in your life journey and also hope that you can come back some day. -- Best regards, Daniel Bermond OpenPGP_signature Description: OpenPGP digital signature
Re: [aur-general] updated AUR intel-opencl-runtime, needs gmm/igc updates
On 08/07/2020 17:06, Nick Black wrote: > Daniel Bermond via aur-general left as an exercise for the reader: >> This package seems to be a pre-compiled variant (-bin) of repository >> intel-compute-runtime. If so, it should be renamed to >> intel-compute-runtime-bin. > Great point; thanks for the heads-up. I'll see if the source can > be grabbed, and if so, move to that. If it's unavailable, or I > can't get it packaged up, I'll execute the rename (this was my > first update of a package I took over). > >> There is a known bug in gcc 10.1 that prevents us from updating igc. The >> bug is already fixed in gcc git master, and the fix is marked to be >> included in gcc 10.2, which in turn most likely will be released in late >> july or august if we consider the historical gcc release schedule. > Thanks for the information. I'm not sure how much the obsolete > version of the package was being used; if it was in wide use, > I'm sure I'll get some bugreports, and I'll back up to a release > from earlier this year. Otherwise, I'm inclined to wait for the > gcc update. > >> For the time being, if you really need updated versions of gmmlib and >> igc, you can try to use intel-gmmlib-git and intel-graphics-compiler-bin >> from the AUR. > Thanks for the pointer, Daniel! Hopefully I'll be able to > rebuild the sources against the Arch community versions of > libgmm/libigc, and that'll fix things up. > > I personally don't need any particular version; I'm just trying > to pitch in on Arch, and as an HPC guy, the unloved Intel OpenCL > packages seemed a good place to start =]. Nice. Welcome to the Arch Linux community! :) -- Best regards, Daniel Bermond signature.asc Description: OpenPGP digital signature
Re: [aur-general] updated AUR intel-opencl-runtime, needs gmm/igc updates
On 08/07/2020 15:34, Nick Black wrote: > (i sent this to arch-dev originally by mistake; apologies for > any duplicates you might receive) > > I took over the quite out-of-date intel-opencl-runtime, and > updated it from 1:18.1.0.013-2 to the current (released > 2020-06-04) 1:20.26.17199 from > https://github.com/intel/compute-runtime/releases/tag/20.26.17199. > Along the way, I cleaned up the packaging a good deal (IMHO). This package seems to be a pre-compiled variant (-bin) of repository intel-compute-runtime. If so, it should be renamed to intel-compute-runtime-bin. > > Unfortunately, this is not going to fly without an update to two > packages in community: > > https://www.archlinux.org/packages/community/x86_64/intel-gmmlib/ > https://www.archlinux.org/packages/community/x86_64/intel-graphics-compiler/ > > gmmlib needs 20.1.1 -> 20.2.2 > igc needs 1.0.3899 -> 1.0.4241 > > Until these two are updated, use of intel-opencl-runtime 20.X is > likely to fail, with errors like the following: > > [grimes](0) $ clinfo > Abort was called at 42 line in file: > ../neo/shared/source/built_ins/built_ins.cpp > Aborted (core dumped) > [grimes](134) $ > > When I hand-built the newer gmmlib and IGC, however, clinfo once > again works fine, and reflects the current version. I'm happy to > prepare the necessary patches, but have never contributed to > community before, and thought I ought post here first. > There is a known bug in gcc 10.1 that prevents us from updating igc. The bug is already fixed in gcc git master, and the fix is marked to be included in gcc 10.2, which in turn most likely will be released in late july or august if we consider the historical gcc release schedule. For the time being, if you really need updated versions of gmmlib and igc, you can try to use intel-gmmlib-git and intel-graphics-compiler-bin from the AUR. -- Best regards, Daniel Bermond signature.asc Description: OpenPGP digital signature
Re: [aur-general] AUR VCS cleanup
On 07/12/2019 12:02, Lukas Fleischer via aur-general wrote: > Here's a list of VCS duplicates reported by `aurdupes -V`. I did not > check for false positives. Maybe somebody can go through that list and > either delete all obsolete packages or file deletion requests: > > > pythonqt (VCS) > * pythonqt-git http://aur.archlinux.org/packages/pythonqt-git/ > * pythonqt-svn http://aur.archlinux.org/packages/pythonqt-svn/ pythonqt development moved from sourceforge svn to github. Filing a deletion request on pythonqt-svn. -- Best regards, Daniel Bermond signature.asc Description: OpenPGP digital signature
Re: [aur-general] AUR cleanup
On 07/12/2019 11:59, Lukas Fleischer via aur-general wrote: > Here's an up-to-date list of duplicates reported by `aurdupes -A`. I did > not check for false positives. Maybe somebody can go through that list > and either remove duplicate packages or file deletion requests. I'll > post a separate list with VCS duplicates. > > svt-vp9 > * svt-vp9 [community] > * svt-vp9 http://aur.archlinux.org/packages/svt-vp9/ It was recently moved to [community]. Filing a deletion request. -- Best regards, Daniel Bermond signature.asc Description: OpenPGP digital signature
Re: [aur-general] Results for TU Application: Daniel Bermond (dbermond)
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_for_new_Trusted_Users > > 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. -- Best regards, Daniel Bermond signature.asc Description: OpenPGP digital signature
[aur-general] TU Application: Daniel Bermond (dbermond)
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=3df44249680150a9a8bce4dd80b41809dcef061f 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. -- Best regards, Daniel Bermond signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU Application: Daniel Bermond (dbermond)
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 > -- Best regards, Daniel Bermond signature.asc Description: OpenPGP digital signature
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: 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
[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
