Re: [aur-general] ungoogled-chromium-bin package submission
On Fri, Jul 01, 2022 at 10:18:23AM +0200, networkException via aur-general wrote: > Hello, > > I maintain / administer the ungoogled-chromium project and its Arch Linux > packaging. > > Last year I asked[1] about the submission rules for an > ungoogled-chromium-bin package as previous packages have all been removed. > Since then our GitHub Actions workflow for releases has been adjusted to > hopefully comply with the requirements[2]. > > At the moment updates will be handled manually by me but the code for > automating this already exists. > > Now it has come to my attention that the ungoogled-chromium-bin package is > blacklisted due contentious violations by people not affiliated with the > project itself. Would it be possible to remove this blacklist entry to be > able to submit our binaries? I imagine that providing an official package > will also stop people submitting packages with workaround names. > > Kind regards, > networkException > > 1: The previous conversation regarding this topic > https://lists.archlinux.org/pipermail/aur-general/2021-September/036581.html > > 2: The commit updated our release workflow > https://github.com/ungoogled-software/ungoogled-chromium-archlinux/commit/88138af15f8231ec0f473e423f28cc29ef76f40f Hi, Sorry for the delay. We have removed the package name from the deny list :) Please poke me if someone pick it up before you are able to claim it. -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [aur-general] TU application for sudoforge
After almost 2 months we have the results :) Yes No Abstain Total Voted Participation 39 6 7 52 Yes 85.25% Congratulations on becoming a Trusted User! Start reading the wiki and we'll get you sorted out over the next couple of days :) https://wiki.archlinux.org/title/AUR_Trusted_User_Guidelines#TODO_list_for_new_Trusted_Users -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [aur-general] TU application for sudoforge
Yo! During the voting of this application we experienced something we haven't seen before. Mainly that we did not reach the participation number we need to get a consensus on the application. This has never happened before and we suspected it might had been because of the recent aurweb release. After a bit of mocking around we discovered our mailserver had a queue with 2.7k emails and a *lot* of people expecting vote reminder emails simply did not get them. This resulted in the application being rejected because of a technical issue. This shouldn't happen, and the TU Bylaws doesn't account for errors like this. That means Ben would have to reapply in 3 months time which is silly. After a small discussion on the internal TU list we decided we'll allow a revote on this application and pay a bit more attentio to the email queue so all the emails people expect do get sent out. However, due to an aurweb bug I had issues submitting the new application. This has been fixed :) Please go vote! https://aur.archlinux.org/tu/136 Thanks for your patience. I have included the results of the previous application for the sake of transparency. Yes No Abstain Total Voted Participation 27 4 8 39 Yes 63.93% -- Morten Linderud PGP: 9C02FF419FECBE16
Re: [aur-general] TU application for sudoforge
The discussion period is over, but please do continue discussing if there are any unresolved questions :) Voting has started: https://aur.archlinux.org/tu/135 -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [aur-general] request to make a -libs package
On Sun, Feb 06, 2022 at 04:09:06AM -0800, Sam Mulvey via aur-general wrote: > Hello! > > I maintain the xen package in AUR, and I recently got a merge request on my > private repo to split the libs off into a split package in order to make > building packages for things like ocaml a little easier. Previously, > packages depended on a now outdated xenstore package. > > I have a vague hope of someone picking up the package at some point for > inclusion into [community], or at least to that standard. That said, I do > want to be responsive to people. There aren't many -libs packages out > there, so I'm wondering where the standard is, and searching around hasn't > been fruitful for me so far. > > Any pointers would be welcome. Thanks! Arch doesn't split off libraries and development headers into seperate packages and this is a feature. There are few exceptions to this but generally I don't think there is anything written about this. -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [aur-general] aurweb v6.0.0 Release
Great work and thank you for the effort :) -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [aur-general] TU application for sudoforge
On Sat, Jan 29, 2022 at 03:27:44PM -0700, Ben Denhartog via aur-general wrote: > Hello good people and fellow miscreants, > > My name is Benjamin Denhartog, better known as sudoforge [0], and I'd like to > formally submit an application to become a TU. I've maintained a few AUR > packages for a while now [1], and you've probably seen me around and about in > IRC (_mostly_ `#archlinux-offtopic` these days). Both Felix Yan (felixonmars) > and Morten Linderud (Foxboron) have agreed to sponsor my application. Yo, I confirm my sponsorship of sudoforge :) -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [aur-general] TU application - artafinde
On Wed, Nov 24, 2021 at 04:30:16PM +0100, Sven-Hendrik Haase via aur-general wrote: > On 15.11.21 15:35, Jelle van der Waa via aur-general wrote: > > Hi > > > > On 31/10/2021 19:24, Leonidas Spyropoulos via aur-general wrote: > > > Hello, > > > > > > I'm Leonidas Spyropoulos and I'd like to apply to become a Trusted User. > > > I'm particularly instersted in packaging dependencies which are required > > > for the ongoing python porting of Aurweb and anything related > > > performance. I'm sponsored from Jelle van der Waa and > > > Sven-Hendrik Haase. > > > > > > Discussion period is over! Please vote > > https://aur.archlinux.org/tu/?id=133 > > The voting period is over and with 41 yes votes Leonidas is now our most > recent member. Congratulations! > > I'm going to create an issue for onboarding you on our issue tracker. > This is the complete results if anyone where curious :) Yes No Abstain Total Voted Participation 41 1 9 51 Yes 86.44% -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [aur-general] TU application - artafinde
On Mon, Nov 01, 2021 at 11:29:51AM +, Leonidas Spyropoulos via aur-general wrote: > Hello, > > On 01/11/21, Morten Linderud wrote: > > On Sun, Oct 31, 2021 at 06:24:51PM +, Leonidas Spyropoulos via > > aur-general wrote: > > Good luck with your application :) Some preliminary thoughts. > > > Thank you > > > This isn't as much of an orphan as there is a question what to do with the > > elasticsearch ecosystem in Arch. With the relicensing and subsequent > > release of > > opensearch what are you plans for this package? This also applies to the > > beat > > packages and auxiliary packages to the ELK stack. > > > I think the best thing to do for Arch Linux is to wait to see how this > will evolve. If opensearch gets traction and support from the community > it might be the answer and eventually elasticsearch will not be > important to keep in repos. I must say though I had to educate myself to > the latest in elasticsearch licensing. Please do read the previou discussion regarding SSPL and mongodb. I don't know if there are recent development but it's still not an OSI license. https://lists.archlinux.org/pipermail/arch-dev-public/2019-January/029430.html I do think there is a possible debate still about how we should approach these licenses, but in general people favour dropping them instead of pretending to be a lawyer. This is also why elasticsearch has been updated until the version before the license change and then orphaned. -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [aur-general] TU application - artafinde
On Sun, Oct 31, 2021 at 06:24:51PM +, Leonidas Spyropoulos via aur-general
wrote:
> Hello,
Yo!
Good luck with your application :) Some preliminary thoughts.
> I'd also be interesting in maintaining some Community packages which
> are orphan or co-maintain some:
> orphans:
> - elasticsearch
This isn't as much of an orphan as there is a question what to do with the
elasticsearch ecosystem in Arch. With the relicensing and subsequent release of
opensearch what are you plans for this package? This also applies to the beat
packages and auxiliary packages to the ELK stack.
> packages I use and interested in {co-}maintaining:
> - ansible
> - aurpublish
> - aws-cli
> - ccache
> - cpupower
> - docker
> - docker-compose
> - go
I'd rather not have a co-maintainer for go unless they want to take some
responsibility for the ecosystem and packaging standards as well. It's quite a
bit of work and just updating Go is the simple part of it. So what are you
thoughts here?
> - gradle
> - kotlin
> - kubectl
> - lrzip
> - neomutt (used to be co-maintainer in aur)
> - notmuch
> - profile-sync-daemon
> - alot
> - android-file-transder
> - android-tools
> - android-udev
> - beets
> - bpytop
> - dvdbackup (used to maintain in aur)
> - cuda
> - fstrim
> - gcc10 (required for cuda)
> - handbrake
> - kitty
> - ncmpcpp
> - ninja
> - nextcloud-client
> - nlohmann-json
> - packer
> - pacman-contrib
> - pandoc
> - profile-cleaner
> - python-* (packages required for Aurweb see list from INSTALL)
> - screenfetch
> - spellcheck
> - signal-desktop
> - wxsvg (required from dvdbackup)
> - zsh-completions
There are a few packages in this list that has anywhere between 2 and 3
maintainers already. One maintainer is bad, two is good, but having 3+
maintainers is just painful to communicate if they are not all on the same page.
This applies mostly to docker and docker-compose on my end, but I suspect there
are more?
When we started doing this list it was mostly to highlight packages that need
more maintainers where we just had one, but I don't think it's super useful
listing up every one package you want to maintain which doesn't strictly need
more maintainers? To me this seems like listing up packages for the sake of
listing up packages.
--
Morten Linderud
PGP: 9C02FF419FECBE16
signature.asc
Description: PGP signature
Re: [aur-general] Question about AUR submission rules
On Thu, Sep 23, 2021 at 11:57:03AM +0300, Alexander Epaneshnikov via aur-general wrote: > On Wed, Sep 22, 2021 at 08:37:23PM +0200, networkException via aur-general > wrote: > > Thank your for taking the time to reading, I hope it will be possible to > > find a > > way to submit ungoogled-chromium-bin properly. > > thank you for asking for advice. > > I also thought, why not move ungoogled-chromium to the community > repository, if, of course, the inclusion criteria are met. > I think this is also not a bad solution to the problem. Arch strives to deliver unpatched software. Packaging something like ungoogled-chromium is antithetical to this goal, and I struggle to see why we should make an exception for this package. (This is also from someone that looks at ungoogled-chromium as only a performative thing, it doesn't actually get you anything in terms of security nor privacy. Obviously someones opinion might differ :p) The current situation is clearly not ideal, and I don't see any good solutions. I'd maybe see if we can make an exception for ungoogled-chromium-bin as the pragmatic option, thus allowing it to repackage .pkg.tar.zst. -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [aur-general] Package `pijul` in both AUR and Community-Testing
On Fri, Jul 02, 2021 at 11:05:11AM +0200, alad via aur-general wrote: > On 02/07/2021 01:35, Eli Schwartz via aur-general wrote: > > On 7/1/21 8:34 AM, Morten Linderud via aur-general wrote: > > > runc, which the entire container ecosystem has been depending on the past > > > 7 years, > > > got it's first stable release last week after almost 100 release > > > candidates :) > > > > The very first version of runc in the official repos was 0.1.0, not > > 0.1.0alpha1 or anything of the sort. > > The point is that the official repos had 13 times an 1.0.0rc for runc. Frankly it was just a fun example. -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [aur-general] Package `pijul` in both AUR and Community-Testing
On Wed, Jun 30, 2021 at 09:52:54PM -0400, Eli Schwartz via aur-general wrote: > On 6/30/21 9:35 PM, George Rawlinson via aur-general wrote: > > On 21-06-30 15:05, alad via aur-general wrote: > >> The question if the package will ever make it to community - most people > >> won't have community-testing enabled. It's not very typical for new > >> packages > >> that weren't in the repositories before. My guess it was because an alpha > >> version was packaged, which shouldn't have been packaged in the repos in > >> the > >> first place. > >> > >> Alad > >> > > > > I'm the packager for pijul (in community). > > > > There's a decent chunk of packages in community that have alpha/beta > > releases so I assumed it was OK. Apologies if this is not the case. > > e.g. a notable one that I'm aware of is qt5-webkit which unfortunately > is not very well maintained by Qt and the alpha by annulen provides life > support with e.g. various needed security fixes. runc, which the entire container ecosystem has been depending on the past 7 years, got it's first stable release last week after almost 100 release candidates :) -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [aur-general] TU application for Caleb, aka alerque
On Tue, Jun 15, 2021 at 02:23:56PM +0300, Caleb Maclennan via aur-general wrote: > On 2021-06-15 04:19, George Rawlinson via aur-general wrote: > > What's your package maintenance/procedure like? I'm always interested in > > seeing how people approach this so I can steal ^W borrow ideas. > > I use `aurpublish` to manage AUR repos, plus a couple hand rolled scripts. > One signs and publishes packages I built to my own package repository, the > other steps me through the update/build process. The process starts by > opening my editor (nvim of course) where I bump the version and clean up > anything else that catches my eye. Then it updates checksums and attempts to > build the package (both on the host system and in a chroot). If that works > it installs it (I only build from systems where I actually *use* packages, > so this works. Once installed I do a quick check to make sure nothing broke. > For apps this usually means just running them and making sure they don't > segfault or complain about deps. For system services I restart the service > and make sure it still functions. If that's good then the result gets > committed (aurpublish taking care of updating the .SRCINFO) and I push to > the AUR repo plus my aurpublish repo and run the other script to publish the > package and re-sign my repo. How do you stay on top of package updates? Do you have any hand rolled scripts to check for updates or do you use existing tooling? > P.S. Was it you that approved the mass deletion of anything Google Play > Music related from the AUR recently without checking which projects actually > had been updated to work with YouTube Music even if they still have GPM in > their name or description? Ohh, backfire ! -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [aur-general] TU application: grawlinson
On Mon, Apr 19, 2021 at 06:52:27PM -0700, Brett Cornwall via aur-general wrote: > I also took a look at the packages you maintain and intend on bringing into > [community]. Most of those Go packages download vendor libraries on > buildtime. The Go package guidelines [2] make no mention of vendoring so I'd > like to get some clarification from someone else on whether or not this is > kosher. Go is in the same camp as with other modern languages like Rust. Devendoring libraries is simply (sadly?) too much effort to be reasonably handled by a distribution without spending a *lot* of effort on tooling to deal with it appropriately. It's not a good development but you would be fighting against the ecosystem. Completely kosher in other words :) -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [aur-general] TU application: grawlinson
On Sun, Apr 11, 2021 at 03:21:37AM +, George Rawlinson via aur-general
wrote:
> Hello everyone!
>
> My name is George Rawlinson (grawlinson), and I am applying to be a
> Trusted User. My sponsors are Morten Linderud (Foxboron) and
> Sven-Hendrik Haase (svenstaro). They have evaluated my PKGBUILDs and
> quickly come to the conclusion that they are considered a crime against
> humanity, but feel free to offer your own opinions. Feedback is always
> great! Especially if there's something I've overlooked.
>
> I've been distro hopping too many times to count, but have comfortably
> settled on Arch Linux since circa 2015. I have always loved tinkering
> with software, and Linux provides one of the best ecosystems for that.
> It all started back in 2009 when I started self-hosting my mail
> domain(s) on a Debian VPS, which was migrated over to Arch once I became
> proficient/comfortable enough. My Arch-specific installations have since
> ballooned from that one VPS to an ex-enterprise server at home, running
> a large set of LXD containers that provide a variety of services to make
> my life somewhat easier.
>
> I maintain my own pacman repository for convenience; it is essentially a
> private git repository made up of git submodules (for AUR packages) as
> well as forked/new packages. To make maintenance easier I extensively
> rely on nvchecker, to keep on top of new releases. aurutils/devtools to
> build/test packages in a clean chroot. Additionally, namcap helps me
> figure out when I've invoked Cthulhu.
>
> Contributions:
>
> - Maintainer of some AUR packages since 2016[0]
> - Hosted a Tier-2 mirror from 2017[1] to 2019[2] on a Hetzner VPS
> - Flung some patches at the namcap & infrastructure repos
> - Filed bug reports/patches for various upstream projects and on
> the Arch bug tracker
> - Member of the Arch Testing Team since sometime last year (2020)
>
> Packages to (hopefully) transfer to community:
>
> - distrobuilder (would be co-maintained with Foxboron)
> - promscale & promscale_extension
> - prometheus-apcupsd-exporter
> - prometheus-snmp-exporter
> - prometheus-ipmi-exporter (and its freeipmi dependency, which
> I also co-maintain)
>
> There are some things I'd like to become more involved in:
>
> - Monitoring the bug tracker for issues that I can help with
> - Co-maintaining some LX{C,D} and Prometheus/Timescale related packages
> - Learning more about the overall tasks that TUs perform so I can decide
> where I can best focus my efforts.
>
> It all comes down to Arch having made such a positive impact in my life,
> and I believe it is past due that I start contributing back.
>
> Regards,
> George Rawlinson
>
> [0]: https://aur.archlinux.org/packages/?SeB=M=grawlinson
> [1]: https://bugs.archlinux.org/task/52852
> [2]:
> https://lists.archlinux.org/pipermail/arch-mirrors-announce/2019-May/33.html
I confirm my sponsorship :)
George has helped test lxd when I was doing the original packages for the
repositories and has generally been maintaining several packages in the AUR i
have adopted into the repositories. The overall quality is good and he seems
like a great person.
I'm confident they are going to make a good addition to the team!
--
Morten Linderud
PGP: 9C02FF419FECBE16
signature.asc
Description: PGP signature
Re: [aur-general] Why are orphan requests accepted immediately although wiki says there's a 2 weeks wating period ?
On Sat, Jan 02, 2021 at 07:46:04PM +0100, Lone_Wolf via aur-general wrote: > Hi, > > Recently I received a notification message that a package I was > co-maintainer from had changed ownership. > > I looked at aur-requests archive and saw the orphan request was filed on Sat > Jan 2 09:42:38 UTC 2021. > > The request was accepted on Sat Jan 2 09:42:38 UTC 2021 or within a second ! > > > I checked > https://wiki.archlinux.org/index.php/AUR_submission_guidelines#Requests > which states > > > Orphan requests will be granted after two weeks if the current > > maintainer did not react. > > The immediate acceptance has made it impossible for the maintainer / > co-maintainers to respond. > > > Is the wiki incorrect wrt policy for orphan requests ? > > If so, where is the correct policy described ? Yo, The only exception is with packages that has been flagged out-of-date for months, which was the case here if this is about openrc. > The package base has been flagged out-of-date since 2019-07-27. So with half a year with an OOD flag and no actions the orphan request gets automatically accepted. -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [aur-general] Packages disappearing
On Wed, Dec 30, 2020 at 10:32:26AM -0500, Lukas Fleischer via aur-general wrote: > On Wed, 30 Dec 2020 at 07:41:02, Morten Linderud via aur-general wrote: > > User deleted their account which deleted the packages. > > Are you sure that that's what's happened? All foreign keys on the > PackageBases table are "ON DELETE SET NULL". Additionally, we > programmatically set these fields to NULL before deleting an account. > > If you have evidence that packages were deleted as a direct consequence > of an account deletion, that's most likely unintended. Please open a bug > in the aurweb bug tracker with some more details. > > Thanks! > Lukas I'm actually a bit unsure, I only have surrounding incidents where the same happened. One of the r- package maintainers deleted their account and subsequently removed a bunch of r packages in AUR. My reaction to this was mostly "oh, probably intended!". I wonder if this only happens when the maintainer creates "fresh packages" and deleted their account? -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [aur-general] Packages disappearing
On Wed, Dec 30, 2020 at 01:23:12PM +0100, j.r via aur-general wrote: > Hi, > > I just ran a update of the AUR packages I have installed and noticed that > fprintd-clients, open-fprintd and python-validity just disappeared within a > day or so. I already searched on through the aur-requests@ list but couldn't > find anything about any of those three packages. > > Does somebody know what happened with them / why they where removed? > > Thanks > > j.r User deleted their account which deleted the packages. -- Morten Linderud PGP: 9C02FF419FECBE16
