Re: Package Maintainer Application - Carl Smedstad
On 3/3/24 16:27, Carl Smedstad wrote: Hi everyone, My name is Carl, or carsme on AUR/IRC, and this is my application to become a Package Maintainer. I started my Linux journey in 2016, while studying engineering mathematics at Chalmers University here in Gothenburg, Sweden. At the time, I was struggling with motivation and direction in my studies, but things took a positive turn when my friend group introduced me to Linux. I started out on Ubuntu but quickly transitioned to Arch Linux as there was a strong "btw, I use arch" atmosphere in our group :) With this new discovery, technology suddenly started making sense and became understandable. I had tinkered with computers since I was a child, but this was the first time I felt that anything was doable, given some time and dedication. As such, tinkering with my system became my new favorite pastime. Shortly after this formative moment, I got a part-time job as a developer, which eventually became full-time and made me drop out of university. This put me on a path which I'm very happy to be on, and which led me to today, where I'm leading a team developing route optimization solutions for commercial aviation. I still tinker a lot, but now with a broader scope that includes the processes, technologies and tools me and my team use in our daily work. Arch Linux has been my daily driver for around eight years now, and I have since 2021 tried to get more involved in the project, mainly by maintaining packages in the AUR. This has been a learning experience and I've tried to continuously improve my process and my packages. Examples include: fixing namcap warnings, migrating to standards based Python packaging (PEP 517), migrating to SPDX license identifiers, and most recently, using nvchecker to check for new versions. Outside of tech, I really enjoy traveling and try to do so as often as possible. Specifically, hiking through new landscapes and sampling local cuisine. Most recent trips were to the Bavarian Alps and to Sardinia in Italy, both of which were fantastic experiences (with great food!). For reference, PKGBUILDs for all packages I maintain in the AUR are available here: https://github.com/carlsmedstad/aurpkgs I've also published some helper scripts I use: https://github.com/carlsmedstad/aurutils-extra For my other OSS-contributions, primarily bug reports and minor patches, my GitHub profile is most likely the best place to get an overview. As package maintainer, I intend to initially bring the following packages (+deps) into [extra], provided no one has any objections: * espanso * opentofu * powershell * protonmail-bridge * rdiff-backup * watchman Regarding (co-)maintenance of what's already in [extra], I'd like to adopt some of the currently orphaned Python and Ruby packages, for example: * python-joblib * python-oscrypto * ruby-treetop Additionally, I did a quick search for packages with only one maintainer among those I regularly use, and ended up with the following candidates for potential co-maintainership: * aerc * handlr * istio * python-black * sqlfluff Hopefully that gives a good picture of who I am and where I'd like to start my journey as a package maintainer, if accepted. My sponsors are Levente Polyak (anthraxx) and Christian Heusel (gromit) and I'm very thankful for their feedback and encouragement so far. Thank you for taking the time to read this, cheers! Hi all, I hereby confirm my sponsorship of Carl. He seems to be very motivated and has a good understanding of packaging while always strives to be on top of the latest packaging guidelines and tooling (like nvchecker configs). It was always nice to cooperate together with Carl and during our Jitsi session he seems like a very social and friendly person. I believe we will make a great package maintainer and addition to our distro. Sincerely, Levente OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Removal of Jonas Witschel (diabonas) as Package Maintainer
On 10/29/23 18:39, Levente Polyak wrote: On 10/17/23 01:43, Levente Polyak wrote: Hi all, I'd like to start a "Special Removal of an Inactive Package Maintainer" [0] for Jonas Witschel (diabonas) based on prolonged inactivity. Jonas has not executed any packaging or AUR maintenance duties since a very long time. Due to this I tried to reach Jonas since quite a while over various channels. Finally I was able to get a response via Signal mid of January 2023. He promised to try to catch up with things that neglected, which unfortunately still didn't happen for his Arch responsibilities. Afterwards I've also tried to get a response in March, May, June and August, without success. Furthermore, gromit has also reached out independently while trying to reach all package maintainers that missed multiple votes, also without success. Hence we also started replacing Jonas as main key holder and I hereby start the Package Maintainer removal with this thread. The discussion period will last for three days, after which there will be a voting period of five days. Cheers, Levente [0]: https://package-maintainer-bylaws.aur.archlinux.org/#_special_removal_of_an_inactive_package_maintainer The discussion period is over, I have started a vote [0] that lasts 5 days. Please vote at your earliest convenience. Cheers, anthraxx [0] https://aur.archlinux.org/package-maintainer/149 The voting period is over. The proposal has been accepted. Yes No Abstain Total Participation 46 1 451 79.69% Cheers, Levente OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Removal of Jonas Witschel (diabonas) as Package Maintainer
On 10/17/23 01:43, Levente Polyak wrote: Hi all, I'd like to start a "Special Removal of an Inactive Package Maintainer" [0] for Jonas Witschel (diabonas) based on prolonged inactivity. Jonas has not executed any packaging or AUR maintenance duties since a very long time. Due to this I tried to reach Jonas since quite a while over various channels. Finally I was able to get a response via Signal mid of January 2023. He promised to try to catch up with things that neglected, which unfortunately still didn't happen for his Arch responsibilities. Afterwards I've also tried to get a response in March, May, June and August, without success. Furthermore, gromit has also reached out independently while trying to reach all package maintainers that missed multiple votes, also without success. Hence we also started replacing Jonas as main key holder and I hereby start the Package Maintainer removal with this thread. The discussion period will last for three days, after which there will be a voting period of five days. Cheers, Levente [0]: https://package-maintainer-bylaws.aur.archlinux.org/#_special_removal_of_an_inactive_package_maintainer The discussion period is over, I have started a vote [0] that lasts 5 days. Please vote at your earliest convenience. Cheers, anthraxx [0] https://aur.archlinux.org/package-maintainer/149 OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Removal of Jonas Witschel (diabonas) as Package Maintainer
On 10/17/23 01:43, Levente Polyak wrote: Hi all, I'd like to start a "Special Removal of an Inactive Package Maintainer" [0] for Jonas Witschel (diabonas) based on prolonged inactivity. Jonas has not executed any packaging or AUR maintenance duties since a very long time. Due to this I tried to reach Jonas since quite a while over various channels. Finally I was able to get a response via Signal mid of January 2023. He promised to try to catch up with things that neglected, which unfortunately still didn't happen for his Arch responsibilities. Afterwards I've also tried to get a response in March, May, June and August, without success. Furthermore, gromit has also reached out independently while trying to reach all package maintainers that missed multiple votes, also without success. Hence we also started replacing Jonas as main key holder and I hereby start the Package Maintainer removal with this thread. The discussion period will last for three days, after which there will be a voting period of five days. Cheers, Levente [0]: https://package-maintainer-bylaws.aur.archlinux.org/#_special_removal_of_an_inactive_package_maintainer The discussion period is over, I have started a vote [0] that lasts 5 days. Please vote at your earliest convenience. Cheers, David [0] https://aur.archlinux.org/package-maintainer/149 OpenPGP_signature.asc Description: OpenPGP digital signature
Removal of Jonas Witschel (diabonas) as Package Maintainer
Hi all, I'd like to start a "Special Removal of an Inactive Package Maintainer" [0] for Jonas Witschel (diabonas) based on prolonged inactivity. Jonas has not executed any packaging or AUR maintenance duties since a very long time. Due to this I tried to reach Jonas since quite a while over various channels. Finally I was able to get a response via Signal mid of January 2023. He promised to try to catch up with things that neglected, which unfortunately still didn't happen for his Arch responsibilities. Afterwards I've also tried to get a response in March, May, June and August, without success. Furthermore, gromit has also reached out independently while trying to reach all package maintainers that missed multiple votes, also without success. Hence we also started replacing Jonas as main key holder and I hereby start the Package Maintainer removal with this thread. The discussion period will last for three days, after which there will be a voting period of five days. Cheers, Levente [0]: https://package-maintainer-bylaws.aur.archlinux.org/#_special_removal_of_an_inactive_package_maintainer OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Applying for maintainer role
On 7/24/23 18:38, Giancarlo Razzolini wrote: Another important thing to mention is, I have discussed with Levente how the voting will work, and given we don't have things established yet, I think we will need to use aurweb itself for the voting procedure, but given it's for a maintainer role, all maintainers should vote, not just former TU's. This would entail giving voting rights to non TU devs on the aurweb (like myself). I agree here, the current way things are implemented just hasn't fully caught up with the new structures. I think the easiest solution for now would be to hand out the old "TU" permission to all devs in aurweb until the platform is adjusted. Cheers, Levente OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Applying for maintainer role
Dear Tomaz and fellow community members, I wanted to take a moment to address the recent discussion on the mailing list regarding Tomaz's application as a package maintainer for our distro (First of all, thank you Tomaz for your interest). As I have followed the conversation closely, I believe it is important to approach this matter from a neutral standpoint that encourages constructive dialogue and reinforces the values we uphold as a community. First and foremost, I want to emphasize that we are a community of individuals with diverse perspectives and opinions. It is only natural that we encounter situations where different viewpoints arise. However, it is crucial that we maintain a respectful tone throughout our discussions, even when faced with conflicting ideas. Responding in a snarky and passive-aggressive manner does not contribute positively to our collective growth no matter who used such a language first. While it is exemplary to seek clarification and avoid blindly following procedures, it is equally important to recognize the value of our established processes. When applicants deviate from these procedures, it can lead to unnecessary conflicts and consume significant time and energy from our dedicated volunteers. Considering the cumulative effort required to dicuss a deliberate deviation from established processes on list, it is instead advisable to consult with the sponsors first to ensure a smoother experience for everyone involved. Regarding the PGP aspect of the application procedure, it is essential to understand that it serves a purpose beyond mere formality. Establishing cryptographic trust through this process enables streamlined authentication for various aspects, such as later on providing service usernames, SSH keys, and secure communication via encrypted emails to receive channel passwords etc. By adhering to this procedure from the outset, we overall simplify the verification process even if it could mean one applicant needs to create a key even when not getting accepted. Let us remember that we are more than just a group of technicians performing individual tasks. We are a social construct, united in our dedication to Arch Linux. As representatives of our distro, it is essential to lead by example, fostering an environment where respectful communication and cooperation thrives. While it is understandable to encounter language that may not align with our personal preferences, it is outmost important to respond with factual information in a friendly manner, trusting that others will recognize the overall tone of one's own message themselves. This does not mean your opinion should be witheld or that you should let everyone in you disagree with, but it means to always approach our discussions with an open mind and empathy. Let's all grab a cool beverage, breath some fresh air and get back to this discussion with a clear mind. Warm regards, Levente OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Application as Trusted User - gromit
Hi there,
I've been talking to Christian off-list and nobody yet seemed to have
posted packaging feedback so I somehow squeezed in a bit of time and
gave him a couple of packaging feedback lately. Just for transparency
find that list here as well:
mdt-git
- should use a better pkgver like the ones from the git packaging
guidelines in the wiki which includes actual version numbers
- needs some depends that the script is using, you should quickly look
at it. f.e. findutils grep awk
pawxel
- you need to declare all submodule sources in the sources array, or
they always get cloned freshly. take a look how "mono" does it, also
note the submodule update command etc
- $pkgdir needs quotes
prometheus-mosquitto-exporter
- you may also want to specify something like -X main.Version=${pkgver}
so the binary reports the correct thing
- prometheus-mosquitto-exporter.service a good start for hardening, but
maybe you can borrow some more options depending on what it needs to
access. things that come to my mind to look up what kind of hardening is
available in the service is umurmur, caddy, tor, postgresql
prometheus-mosquitto-exporter-git
- better pkgver which reflects the version
- same as prometheus-mosquitto-exporter
molly-guard
- you should pull from a https source
- has some unquoted $pkgdir
- printing messages in the install file on every upgrade does not sound
right
google-chrome-beta:
google-chrome-dev
- printing messages in the install file on every upgrade does not sound
right
mdt:
- same as mdt-git: needs some depends that the script is using, you
should quickly look at it. f.e. findutils grep awk
kopia:
- we have tests, lets use them
Good luck,
Cheers,
Levente
OpenPGP_signature
Description: OpenPGP digital signature
Re: AutoUpdateBot harmful
On 4/12/23 20:02, Jingbei Li wrote: Hi, I'm the creator of AutoUpdateBot. This bot is originally designed as a bot for the arch4edu repository to automatically update the packages of the arch4edu maintainers on AUR. Then our build bot will test the new PKGBUILDs and we will fix any found error in a day or two or even downgrade the package on AUR when necessary. Then I decided to open this bot to everyone and I did consider about testing before pushing at that time. However, it's hard to test the PKGBUILD for those packages which have AUR dependencies. So I haven't set up any test yet. I still don't have a solution for package with AUR dependencies. But I'm planning to alleviate this issue by testing packages without AUR dependencies, sending an email to the maintainer when there's an update and adding a pinned comment to inform the users about the automatic updates. If you have any suggestion on how to improve this bot please reply to https://github.com/arch4edu/aur-auto-update/issues/30 . Best regards, Jingbei Li Hi Jingbei Li, Thank you very much for investing time, efforts and resources into Arch Linux and the AUR. Taking the currently described state into account I would like to kindly request that you stop and disable the automatic pushing. Bumping packages without any testing and check() is not a good thing, even when you try to revert afterwards. You can investigate how to setup a custom pacman repository for your AUR packages and make it accessible to your builders (f.e. via https). pacman provides low level tools for creating a database out of packages (repo-add, repo-remove) Then you can provide a custom pacman.conf to makechrootpkg containing the repository. You'd initially need to populate the repository starting from the leaf packages. If you have further questions I'm sure the community is open to help you out. Sincerely, Levente OpenPGP_signature Description: OpenPGP digital signature
Re: Application as Trusted User
On 3/29/23 15:43, Anton Hvornum wrote: On 3/26/23 13:43, Levente Polyak wrote: On 3/22/23 22:34, Anton Hvornum wrote: Furthermore it lacks proper provides/conflicts declaration on the none -git named archinstall package itself (both provide/conflict the same meta declaration, but in terms of correctness it should always conflict on the none git pkgname). I assumed (incorrectly?) that since both have 'provides' that point to 'python-archinstall' they detect the conflict automatically. Would 'conflicts=(python-archinstall-git)' be appropriate in the non -git package or should it be 'conflicts=(archinstall-git)' as the package is called 'archinstall-git' not 'python-archinstall-git'? Theoretically the assumption about `python-archinstall` is correct, but let me shortly explain why it still matters: Such provides are just additional metadata, often also just used to replace a former package name. Such can a lot easier change or vanish. Another reason: using python2 here just to have a simple visualization of the issue (could be anything i reality): `python-archinstall` correctly states it provides a python library part of archinstall. Imagine a scenario where there would by a python2 or whatever version then declaring `python-archinstall` would be wrong as that's not what it provides or conflicts, it conflicts on `usr/bin/archinstall`. A good practice that just solves all the issues is to simply declare provides/conflicts on the canonical none-special variant: In this case `archinstall`. To the second part: I do see cases where the canonical none-special variant does conflict on special purpose variants. That should not be done. It's the responsibility of the special purpose variants to conflict on the canonical variant. Let me also picture this really quickly: Imagine someone would be adding new special purpose variants, that could happen to any arbitrary point in time. If this rule is not followed, that would mean the canonical variant needs to be updated whenever a new special purpose variant materializes. This would not be much fun :) On the other hand, if the rule is followed that special purpose variants must declare its conflict against the canonical variant, then automatically any case is covered at whatever time a new variant materializes. So the take on this should be to always follow those 2 simple rules to be happy and safe : - always (at least additionally) conflict on the actual canonical package in the special purpose variants - never conflict on special purpose variants in the canonical variant package. Notify them instead and let that be the responsibility of the special purpose variants. Thank you for your feedback btw, it's appreicated and served as a good reminder that the PKGBUILD in the AUR had not been updated to reflect the state of the PKGBUILD in the upstream GitHub repo[5]. I've strived to follow the Python package guidelines[4] as closely as I can and hope that's reflected in the PKGBUILD's now. I'm always happy to provide feedback and help each other out. Thank you for being open and reflective and also asking questions you'd like to get an opinion on. I wish you good luck for the vote, Levente OpenPGP_signature Description: OpenPGP digital signature
Re: Application as Trusted User
On 3/22/23 22:34, Anton Hvornum wrote: On 3/22/23 19:37, Jelle van der Waa wrote: Hi, Actually this is a package you co-maintain, any other packages you have maintained in the AUR? [1] It's hard get a feel about your packaging history without any examples to look at. It's a valid question, and my response would be that I don't think my AUR-packaging experience is my super power yet (or at least nothing to brag about). If anything it's my involvement with developing Arch Linux tooling, participate and being involved in projects[1][2][3][4][5][6][7][8][9][10] and helping the community. Those are what made me to apply for a TU role. I have a deep rooted willingness to learn if given the opportunity and I've seen the need and calling from people to help with orphaned packages and every now and then packages pop up that I use, love and would love to help out carry on the packaging of - but can't due to my current role. I see this as an opportunity to gently ease my way into it while still being very familiar with the Arch echo system and how a lot of the packages are packaged in general terms. I honestly also don't have many packages that I would need to put into AUR that I feel others would want or need. As a person I'm a very "hands-on" person. I need practical reasons and examples for doings things - so co-maintaining packages would be the best way for me to learn and gradually shoulder more and more responsibilities. And I hope my involvement in packaging[11] and distributing archinstall releases[12] for the last 2 years (anniversary[13] coming up in the 1:st of April this year) would count for something. Not trying to apply or win sympathy points, but it has been a lot of work and I hope it counts for something. I will mention that I have packaged a few personal projects on AUR >5 years ago: * slimDHCP[14] (Was in AUR ~2018, but quality of the PKGBUILD was not the best) * slimDNS[15] (Also in AUR, a bit older than slimDHCP) * slimSMTP[16] (same here) I think I had a few more but they've been deleted since long ago. Again, they're by no means production worthy examples and quite outdated frankly and I learned a lot back then and since. [1] https://gitlab.archlinux.org/archlinux/archiso/-/merge_requests/251 [2] https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio-archiso/-/merge_requests/24 [3] https://gitlab.archlinux.org/archlinux/archiso/-/issues/65 [4] https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio-archiso/-/merge_requests/10 [5] https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio-archiso/-/merge_requests/13 [6] https://gitlab.archlinux.org/archlinux/repod/-/issues/14 [7] https://gitlab.archlinux.org/archlinux/repod/-/merge_requests/21 [8] https://github.com/Torxed/archoffline [9] https://github.com/archlinux/archweb/pulls?q=is%3Apr+author%3ATorxed [10] https://gitlab.archlinux.org/archlinux/archiso/-/merge_requests/294 [11] https://github.com/archlinux/archinstall/commits/master/PKGBUILD [12] https://github.com/archlinux/archinstall/releases [13] https://archlinux.org/news/installation-medium-with-installer/ [14] https://gist.github.com/Torxed/206a15e5d11b2252c696c32ed394caaf [15] https://gist.github.com/Torxed/5c872cf8b673afc74927cb31a1d4e5e5 [16] https://gist.github.com/Torxed/5a41155a0dd88d518c404e94b56a8a8a [1] https://aur.archlinux.org/packages?K=Torxed=m Greetings, Jelle All the best, //Anton Hi Anton, As there isn't much packages to review anymore, which is unfortunate, I'd like to ask if you can improve the only package you currently co-maintain in the AUR currently: archinstall-git. I'd love to see it being upgraded to the latest python ecosystem standards using (PEP 517 and friends). Furthermore it lacks proper provides/conflicts declaration on the none -git named archinstall package itself (both provide/conflict the same meta declaration, but in terms of correctness it should always conflict on the none git pkgname). On top It lacks `git` as makedepends. It should also provide a pkgver() function as documented in the packaging guidelines, currently different states would yield to the same pkgver which is not good. Cheers, Levente OpenPGP_signature Description: OpenPGP digital signature
Re: TU Application - Antiz
On 1/3/23 22:58, Robin Candau wrote: Le 03/01/2023 à 21:29, Robin Candau a écrit : Yeah, I definitely have an issue with my PGP settings in Thunderbird. I assume this mail will have problems as well. I'm really sorry about that... I'm looking that up for the next messages! It seems like my protonmail address doesn't want to send properly signed mails for some reasons ¯\_(oO)_/¯ I'm switching to my gmail address which, hopefully, will produces a properly signed mail. Regards, Antiz (Robin C.) Can confirm it produced a valid and working signatures :) Thanks for trying to debug this :) Cheers, Levente OpenPGP_signature Description: OpenPGP digital signature
Re: TU Application - Antiz
On 1/3/23 21:16, Robin Candau wrote: Le 03/01/2023 à 20:37, Morten Linderud a écrit : On Tue, Jan 03, 2023 at 07:10:47PM +, Robin Candau wrote: Le 03/01/2023 à 18:40, Morten Linderud a écrit : Note: You sent a clear text email to the list, and an encrypted email to me. It seems like your email client gets confused and produces an invalidly signed email as a result. I'd recommend just disabling encrypted emails when it goes over the mailing list. It's also very annoying to deal with encrypted emails on the reciving end when there is no need for it. Whoops... Didn't mean to. I disabled encrypted emails. First: Good luck :) Hm it looks like you now also disabled signed messages all together, which isn't really desired :D Also I'm not sure if its just my end, but I'm unable to verify any of your signed emails unfortunately. Cheers, Levente OpenPGP_signature Description: OpenPGP digital signature
Re: TU Application - tpkessler
Hi Torsten,
good luck for your application :)
My first question would be how you keep track of
upstream locations and which one has new releases
available?
It looks like the whole stack has version 5.3.1
released.
DCMAKE_BUILD_TYPE=None has already been mentioned, also
also explained equally as I would have -- hence I will
leave that one out of all reviews (while agreeing with
Filipe).
Now, a "little bit" of feedback after reviewing your
current AUR packages.
Please don't feel overwhelmed. I've reviewed now for
nearly 3 hours and will send the current results over :)
comgr
- looks like upstream provides some tests, it would be
useful to always try running tests whenever available:
https://github.com/RadeonOpenCompute/ROCm-CompilerSupport/tree/amd-stg-open/lib/comgr/test
hip-runtime-amd
- I'm not sure how that stacked package really works and
which one its real tests are, but there seem to be
some available in:
https://github.com/ROCm-Developer-Tools/HIP/tree/develop/tests
hip-runtime-nvidia
- same question about testsas hip-runtime-amd
- the nvcc.patch:: prefix for the pull request patch is
not good as its not really a unique name. The reason:
whenever sources are placed into the same dir, like
when setting SRCDEST in makepkg this leads to issues
if any other package may ever specify nvcc.patch.
f.e. hip-runtime-fix-logic-for-finding-nvcc.patch::
Depending on the filename, it sometimes makes sense to
also include the $pkgver into the prefix name
- the pull request #2623 which this patch depends on has
been rejected upstream and it looks like superseded by
#2849. Worth checking out a way that upstream is not
against.
hipblas
- Again wondering a bit about tests, as this time we
even seem to disable them on purpose:
DBUILD_CLIENTS_TESTS=OFF
hipcub
- reference-previous-mention: tests
- The git dependency made me wonder, and actually the
cmake ecosystem seems to clone rocPRIM.git and
doesn't seem to pin it to a specific hash which means
this package isn't reproducible when the repo changes.
Instead we need to specify all downloaded repo in the
sources array with a fixed hash and link the $srcdir
repos into the proper place with a small patch
to the cmake build env to avoid fresh clones. this
also applies to googletest and googlebenchmark.
On top it seems to download cub/thrust as well:
https://github.com/ROCmSoftwarePlatform/hipCUB/blob/develop/cmake/Dependencies.cmake
Some infos about reproducible builds:
https://reproducible-builds.org/
hipfft
- reference-previous-mention: tests
- has similar none reproducible download issues as
hipcub which need to be pinned and passed in sources()
It seems to download rocm-cmake from master
https://github.com/ROCmSoftwarePlatform/hipFFT/blob/develop/cmake/dependencies.cmake#L57-L75
This package should instead depend on rocm-cmake
hipfort
- reference-previous-mention: tests
hipify-clang
- reference-previous-mention: tests
hipsolver
- reference-previous-mention: reproducible
seems to download rocm-cmake and should instead
depend on it
https://github.com/ROCmSoftwarePlatform/hipSOLVER/blob/develop/CMakeLists.txt#L51-L55
hipsparse
- reference-previous-mention: tests
- reference-previous-mention: reproducible / rocm-cmake
hsa-amd-aqlprofile-bin
- doesn't seem to distribute the proprietary license.
hsa-rocr
- CMAKE_CXX_FLAGS='-DNDEBUG' seems to discard our distro
CXXFLAGS
hsakmt-roct
- reference-previous-mention: tests
- wondering if it wouldn't be better to use
BUILD_SHARED_LIBS instead of statically linking?
mathtime-professional
- don't quite understand this package with sources to
local://mtp2fonts.zip.tpm
Does this package make sense for the general public?
migraphx
- reference-previous-mention: tests
- patch in PR #1435 has been merged and should be
replaced by the upstream url:
https://github.com/ROCmSoftwarePlatform/AMDMIGraphX/pull/1435
https://github.com/ROCmSoftwarePlatform/AMDMIGraphX/commit/ba0913b1e9c86e94414c9a71baa31569904cd04e
- some none unique source file prefix, reference
explained in hip-runtime-nvidia
- reference-previous-mention: reproducible
https://github.com/ROCmSoftwarePlatform/AMDMIGraphX/blob/develop/install_deps.cmake#L59-L63
miopen-hip
- reference-previous-mention: tests
- reference-previous-mention: none-deterministic
https://github.com/ROCmSoftwarePlatform/MIOpen/blob/develop/fin/install_deps.cmake#L39-L41
miopen-opencl
- same as miopen-hip
miopengemm
- reference-previous-mention: tests
mivisionx
- reference-previous-mention: tests
pcg-c-git
- missing conflicts=("$_pkgname") for correctness, even
if it doesn't currently exist
python-meshio
- reference-previous-mention: tests
rccl
- reference-previous-mention: tests
BUILD_TESTS=OFF
- reference-previous-mention: reproducible / rocm-cmake
https://github.com/ROCmSoftwarePlatform/rccl/blob/develop/cmake/Dependencies.cmake#L76-L78
cheers,
Levente
Re: [aur-general] TU Application - blakkheim
On 8/16/22 14:30, T.J. Townsend via aur-general wrote: Hello. I'd like to apply to become a trusted user. ... The voting period has ended. Yes 34 No 4 Abstain 15 Total 53 Participation 86.89% Result: Accepted Congratulations, you are now officially accepted as TU. cheers, Levente OpenPGP_signature Description: OpenPGP digital signature
Re: [aur-general] TU Application - blakkheim
@TUs: less than 2 days left, please cast your votes on the new TU application https://aur.archlinux.org/tu/139 cheers, Levente OpenPGP_signature Description: OpenPGP digital signature
Re: [aur-general] TU Application - blakkheim
On 8/25/22 17:40, Konstantin Gizdov via aur-general wrote: On 25/08/2022 18:08, T.J. Townsend via aur-general wrote: It can be a little confusing for new users because the tooling will print warnings about this: openiked W: Dependency glibc included but already satisfied openiked W: Dependency openssl included but already satisfied But Arch's packaging policy says "Do not rely on transitive dependencies in any of the PKGBUILD#Dependencies, as they might break if one of the dependencies is updated." These two things seem to be in conflict with each other, so I went with the policy statement as the deciding rule. Sure, but the issue is that 'glibc' is in the 'base' group that will exist on any Arch Linux install. There is a bit of debate whether we include these or not. Most people normally do not as it's a given on any system. In any case, 'glibc' is not really a transitive dependency in that sense. I'd disagree here. I do not like to threat a hand full of packages any special just because its virtually impossible to run a system without. Its a much easier and better model to declare all primary runtime dependencies. Glibc is only special because its glibc, not because its in base. The 'base' meta package is a meta package for a reason. It can change at any point in time reflecting what we currently declare as a base minimum for a system to be called "Arch Linux". It's quite a bad trade trying to spend a couple of less characters in an depends array when this base package may theoretically change at any point in time -- which should not lead to any packaged need any adjustments. In that sense glibc is only special because you won't in fact run a system without glibc. Either way my stance is easy: There is no reason trying to declare any packages as special in terms of not needing to declare them. It brings up the burden to remember or argue while in fact it brings absolutely no advantages to omit it -- but on the other hand potential scenarios where it creates issues. Hence just declare whatever the package actually needs and call it a day. I'd say that sounds more like keeping is simple stupid. cheers, Levente OpenPGP_signature Description: OpenPGP digital signature
Re: [aur-general] TU Application - blakkheim
On 8/16/22 14:30, T.J. Townsend via aur-general wrote: Hello. I'd like to apply to become a trusted user. I started using Arch around 2009 when we still had the curses installer, rc.conf, hal... the good old days. I left at some point and came back as a full-time user about three years ago. You can find me on IRC under the name blakkheim, usually in #archlinux-security since that's my main area of interest. I'm the maintainer or co-maintainer for a few OpenBSD-derived packages in the AUR: openiked, rpki-client, and openbgpd. I've been involved with OpenBSD since 2014 and became a project committer there in early 2016. In the last two years I've submitted just over 150 patches to the Arch bug tracker: https://bugs.archlinux.org/index.php?opened=32638[]= Some community packages I'd like to co-maintain are openntpd, opensmtpd, libressl, sndio, mandoc, signify, dnscrypt-proxy, bmake, scrot, firejail, xcalib, mktorrent, parallel, ncmpcpp... And more (frankly, lots more) in the core/extra repos if that option opens up in the future. I keep up with many software projects via their mailing lists and RSS/atom feeds. If I'm accepted, one of my goals will be to get missing security fixes into Arch's repository shortly after their upstream release. The sponsors of my application are dvzrv, kpcyrd, and anthraxx. (yep, three) > I also confirming my sponsorship. A race condition lead to the off by one :p cheers, Levente OpenPGP_signature Description: OpenPGP digital signature
Re: [aur-general] TU application - Segaja
On 11/15/21 19:18, Andreas 'Segaja' Schleifer via aur-general wrote: Hi everyone, My name is Andreas Schleifer, in the internet also known as Segaja, and I would like to apply to the position of a Trusted User. My sponsors are Levente Polyak and Jelle van der Waa, thanks for that ;) Our hardworking code has counted the ballots: Yes No Abstain Total Participation 42 2 10 54 90.00% We would like to happily welcome Andreas aka 'Segaja' among the Trusted Users. cheers, Levente OpenPGP_signature Description: OpenPGP digital signature
Re: [aur-general] TU application - Segaja
On 11/15/21 19:18, Andreas 'Segaja' Schleifer via aur-general wrote: Hi everyone, My name is Andreas Schleifer, in the internet also known as Segaja, and I would like to apply to the position of a Trusted User. My sponsors are Levente Polyak and Jelle van der Waa, thanks for that ;) I'm a 34 years old DevOps engineer in the same company as Levente is currently working in. I have started as a (PHP) developer and have over time migrated to also doing devops work. My Linux "career" started around 2005/2006 during my university time with Ubuntu. A few years later a friend of mine kindly pointed me to Arch Linux. At the beginning it was a bit uncomfortable for me but I quickly embraced the fact that there was no UI to configure anything and that you have to work directly on the configuration files. In the past year I have started to become more interested in packaging for Arch which made me adopt two orphaned AUR packages ([1] and [2]) and upload one new package [3]) to AUR. Some packages I started as AUR packages were later moved by Levente into the official community repository: [4], [5] At some point I also got interested in the reproducible builds topic and helped out there a bit [6]. This is also where I got in contact with Jelle and we talked a few times on IRC back then. When I got interested in becoming a TU I talked with Levente about this and he suggested that I should try to get some more packaging experience, so he suggested me to try to (re-)package schleuder [8] which was in a very old and broken version in AUR back then. It took me quiet a while and I learned a lot, but in the end I eneded up packaging schleuder [9] and schleuder-cli [10]. The biggest learning from that for me was 1) that packaging is much more then "dumping" an upstream tool into a PKGBUILD file to be installed on a users system and 2) that the ruby ecosystem can be very annoying to deal with. A lot of inconsistent tools to be used for testing and a lot of cyclic dependencies which makes writing PKGBUILD files with check() functions very difficult. In the process of packaging the schleuder packages I also ended up with a host of other ruby packages which were needed [11]. In order to be able to package the schleuder packages I also worked closely with the upstream maintainers to resolve issues that came up in the Arch Linux build environment. I have some devops experience from my daily work and I would like to also offer this to Arch Linux over time. I already talked with Jelle and Levente about some of the devops projects that were going on in the past. I'm currently also working on an ansible role to install schleuder on Arch Linux infrastructure [12] in order to handlesecur...@archlinux.org [13]. As TU I would also like to help out Levent and other package maintainers to keep their awesome packages up to date with upstream changes/releases (e.g. [4], [5], [7]). I would also like to migrate hss [1] and stern [2] to the official repositories, as I believe they are both very useful tools for people who work with servers (hss) and kubernetes (stern) often. If you have any questions or want to know more you can also reach me on IRC in #archlinux Best regards Segaja [1]https://aur.archlinux.org/packages/hss/ [2]https://aur.archlinux.org/packages/stern/ [3]https://aur.archlinux.org/packages/prometheus-dnsmasq-exporter-git/ [4]https://archlinux.org/packages/community/x86_64/aliyun-cli/ [5]https://archlinux.org/packages/community/x86_64/alicloud-vault/ [6]https://reproducible-builds.org/reports/2020-06/ [7]https://archlinux.org/packages/community/any/ls++/ [8]https://schleuder.org/ [9]https://aur.archlinux.org/packages/schleuder/ [10]https://aur.archlinux.org/packages/schleuder-cli/ [11]https://aur.archlinux.org/packages/?K=Segaja=m [12]https://gitlab.archlinux.org/archlinux/infrastructure/-/merge_requests/497 [13]https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/178 Hey ho everyone, I hereby confirm my sponsorship of Segaja. I believe he would be a good addition to our team and I also see potential growth in the devops area. It was always pleasant to work together with him. cheers, Levente > > GET | 200 | 709 ms | cloudflare > POST | 418 | 0 ms | localhost OpenPGP_signature Description: OpenPGP digital signature
Re: [aur-general] TU application - artafinde
Hey Leonidas,
I wish you good like as well. May the force be with you :D
For now I just have a tiny bit after reading through your mail:
On 10/31/21 19:24, Leonidas Spyropoulos via aur-general wrote:
AUR packages (I maintain) interested in moving to Community
...
- intellij-idea-{ce,ue}-eap (Provided their license is allowing that)
Those are early access programs. We should not by default endorse a
bleeding edge set in the official repos that are deemed purely for
testing and feedback purpose rather than production usage.
JetBrains also marks them with a specific warning:
# This is an early access version of the product
# You expressly acknowledge that this version of the product may not be
# reliable, may not work as intended and may contain errors. Any use of
# the EAP product is at your own risk.
I'm not really fond of the idea to put them into our repos, the AUR is a
quite good fit for it. Both are also just re-packaging the JetBrains
dists so build time isn't really something to be concerned about. On top
I see problems doing that with the JetBrains license issued for those
two dists.
cheers,
Levente
OpenPGP_signature
Description: OpenPGP digital signature
