Re: [aur-general] TU application - orhun
And thusly ends this tumultuous discussion period. The time has come to vote: https://aur.archlinux.org/tu/?id=127 xoxo, Sven OpenPGP_signature Description: OpenPGP digital signature
[aur-general] Anyone want to have netdata?
Hey, I don't really use netdata anymore. Does anyone want to pick it up? I'd drop it to AUR otherwise. Cheers, Sven OpenPGP_signature Description: OpenPGP digital signature
Re: [aur-general] TU application - orhun
Hello, I have no idea who this is and I haven't talked to this user before. However, considering they maintain a lot of Rust software, I think they're safe and would make a great addition to the team. Just kidding. I talked to Orhun a fair bit, went over the majority of their packages and I think they'd make a great addition to the team. I hereby confirm my sponsorship. Since Levente already gave his confirmation, let the discussion period begin! Cheers, Sven OpenPGP_signature Description: OpenPGP digital signature
Re: [aur-general] AUR migration
On 23.07.20 22:09, Giancarlo Razzolini via aur-general wrote: > Hi All, > > In continuing with the improvements being done to our infrastructure, we're > planning to migrate the AUR to another machine. This means that, during > the migration, > there *will* be downtime of the whole AUR. > > I expect the migration to take around two hours and happen either > tomorrow (Friday) > or on Saturday, depending on availability. > > Regards, > Giancarlo Razzolini Thanks for taking the time! I hope there won't be any weird unforeseen problems. signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU application; freswa
On 06.05.20 23:19, Frederik Schwan via aur-general wrote: > Hi everyone, > my name is Frederik aka freswa and I'm applying to become a Trusted User with > svenstaro's and grazzolini's sponsorship. > > I started using Linux around 2004 with some live images of Ubuntu. In 2010, > Debian became my main OS. Only a year later I switched to Arch after I > screwed up Debian/sid while hunting for the latest kernel. > I'm interested in DevOps topics, mail server, C, Rust, Go and newer JVM > languages such as Kotlin. > > Thanks to svenstaro I've been a bug wrangler since February. You mostly hear > from me when I assign bugs to the wrong people from time to time :P > > OS contributions: > - working on the dovecot-xaps code, providing native Mail.app Apple Push for > iOS devices > - maintaining and writing PKGBUILDs for the AUR > - bug reporting and fixing for several projects > > My AUR packages got reviewed recently by eschwartz, svenstaro and alad - > thanks :) > > If I become a TU, I'd like to focus on the bug tracker until we have a better > solution. I'd also like to help out bug fixing when maintainers are busy, > away or on vacation. > > Packages which I would like to move to [Community], some of which are not > mine: > docker-credential-pass > i3status-rust > intel-undervolt > ispin > mysqltuner > pdfposter > pinentry-rofi > protobuf-go > sha3sum > spin > talosctl > thermald > unifi > woeusb > > I'm aware though that some of these packages do not meet the criteria of 10 > votes yet. I'll reevaluate whether they meet this criteria from time to time. > I'd also like to go on helping Eli with maintenance of zfs-dkms and zfs-utils > in the AUR. > > In case JetBrains is okay with us packaging their IDE's, I'd also maintain > them. But so far all requests I found resulted in a negative response from JB. > > I am looking forward to working with you! > Frederik > I'm confirming my sponsorship! Let the discussions begin. Well, continue, I suppose, since it already kinda started while I slept. Discussion period shall last until 2020-05-12. Sven signature.asc Description: OpenPGP digital signature
Re: [aur-general] Dropping official gitlab packages
On Fri, Dec 27, 2019, 23:41 Anatol Pomozov wrote: > Hi > > Per discussion with Sven-Hendrik I am going to become maintainer for > these packages. > > Aaand the first batch of changes (switching gitlab to ruby 2.6) has > landed [community-testing]. Please give it a try and send feedback if > you see any issues. > Thanks a lot! Good to see these going to a loving home. Don't forget to assign yourself all the bugs. >
Re: [aur-general] Dropping official gitlab packages
On Fri, Dec 27, 2019, 09:26 Anatol Pomozov wrote: > Hello Sven-Hendrik > > On Thu, Dec 26, 2019 at 11:47 AM Sven-Hendrik Haase > wrote: > > On Thu, Dec 26, 2019, 18:14 Sébastien Luttringer > wrote: > >> > >> On Thu, 2019-12-26 at 01:51 +0100, Sven-Hendrik Haase via aur-general > wrote: > >> > On Thu, 26 Dec 2019 at 01:43, Anatol Pomozov < > >> > Because Docker+EE works flawlessly and reliably while upstream breaks > the > >> > packages we have every other release. Upstream _needs_ their Docker EE > >> > image to work as there's tons of money to be lost there but they > don't care > >> > about our downstream packages. Also, I didn't see any way to package > their > >> > EE at the time. I lost too much time maintaining these fruitless > packages > >> > and it's time to cut those losses. > >> > >> Hello, > >> > >> Both Docker images work flawlessly since years (they are officially > supported). > >> I guess the question was more about EE vs CE. > >> I recently noticed than well known opensource distro now use the CE. > >> > >> Regards, > >> > >> Sébastien "Seblu" Luttringer > > > > Let's not go further in this direction please. This thread is about > dropping/passing on maintenance of the gitlab packages. Hopefully some > other TU can show these packages some love. > > I think that the question of maintaining 'gitlab' package in > [community] is relevant to our future plans. If we want to go with > gitlab to manage our repos then I propose to use the Arch package > instead of a Docker image. The advantage of using the Arch package is: > - we show that we trust our own packaging abilities > - we put ourselves into our user's shoes. Using 'gitlab' package at > our server will help us understand how other users deal with such > systems. What are their pain points. Maybe it will force us to rethink > how do we manage ruby releases or maybe we come up with better bundler > integration or something else. > > So we need to decide whether we want to use the Arch package or the > docker image. If Arch package is the preferable option then it should > stay in the repo. > The whole point of this is that we don't trust our gitlab packages. I wouldn't build our arch code hosting on those packages from what I've seen in the past. In fact, even if those packages found a maintainer again, I'd be opposed to actually using them ourselves in the short term. One example of why I don't trust them: sometimes gitlab tags a security release which would in theory need to be released quickly but then fails to build so it stays vulnerable for a few days until I can get the build fixed. This doesn't happen with the docker images. I think the docker image is by far the preferable option for the time being. >
Re: [aur-general] Dropping official gitlab packages
On Thu, Dec 26, 2019, 18:14 Sébastien Luttringer wrote: > On Thu, 2019-12-26 at 01:51 +0100, Sven-Hendrik Haase via aur-general > wrote: > > On Thu, 26 Dec 2019 at 01:43, Anatol Pomozov < > > Because Docker+EE works flawlessly and reliably while upstream breaks the > > packages we have every other release. Upstream _needs_ their Docker EE > > image to work as there's tons of money to be lost there but they don't > care > > about our downstream packages. Also, I didn't see any way to package > their > > EE at the time. I lost too much time maintaining these fruitless packages > > and it's time to cut those losses. > > Hello, > > Both Docker images work flawlessly since years (they are officially > supported). > I guess the question was more about EE vs CE. > I recently noticed than well known opensource distro now use the CE. > > Regards, > > Sébastien "Seblu" Luttringer > Let's not go further in this direction please. This thread is about dropping/passing on maintenance of the gitlab packages. Hopefully some other TU can show these packages some love. >
Re: [aur-general] Dropping official gitlab packages
On Thu, 26 Dec 2019 at 01:43, Anatol Pomozov wrote: > Thanks for the reply. > > On Wed, Dec 25, 2019 at 2:20 PM Sven-Hendrik Haase > wrote: > >> > I maintain the official gitlab packages gitlab, gitlab-gitaly, > >> > gitlab-runner, gitlab-shell, gitlab-workhorse and python-gitlab. Out > of > >> > these, I'll be dropping gitlab, gitlab-gitaly, gitlab-shell and > >> > gitlab-workhorse because they are way too much work to maintain and I > can't > >> > keep up and the result isn't great. > >> > >> I remember discussions about using gitlab to manage our (future) git > >> repos. If we want to go this route then we need to keep gitlab in our > >> repos. > > > > > > That is entirely orthogonal because we're using Docker for that > currently anyway as we'll use their Enterprise Edition offering which we > didn't package. > > I probably missed this discussion so I am out of context. But what is > the reason we prefer Docker+EE versus using a plain Arch package for > GitLab community edition? > Because Docker+EE works flawlessly and reliably while upstream breaks the packages we have every other release. Upstream _needs_ their Docker EE image to work as there's tons of money to be lost there but they don't care about our downstream packages. Also, I didn't see any way to package their EE at the time. I lost too much time maintaining these fruitless packages and it's time to cut those losses.
Re: [aur-general] Dropping official gitlab packages
On Wed, 25 Dec 2019 at 23:47, Giancarlo Razzolini wrote: > Em dezembro 25, 2019 19:36 Karol Babioch via aur-general escreveu: > > > > Announcing this on main site as dedicated news entry is probably > > overkill? At least it would get some attention and potentially some new > > maintainer could be found this way ;-)? > > > > Not sure how many people are using those packages, but this is seriously > > disruptive. Anyone running on this, would probably appreciate to be > > aware of the situation ... > > > > I think Sven should have used the arch-dev-public mail list, but it does > not > change the fact the current packages are hard to maintain and if no other > developer > or trusted user wants to pick it up, it will be dropped. > I thought aur-general for [community] and AUR and arch-dev-public for [extra] and [core] discussion? This way, non-TU users will get a chance to speak up here in case they want to aspire to be maintainers for the packages to be dropped for when they land in AUR.
Re: [aur-general] Dropping official gitlab packages
On Wed, 25 Dec 2019 at 23:30, Karol Babioch via aur-general < aur-general@archlinux.org> wrote: > Hi, > > Am 25.12.19 um 23:18 schrieb Anatol Pomozov via aur-general: > > I remember discussions about using gitlab to manage our (future) git > > repos. If we want to go this route then we need to keep gitlab in our > > repos. > > So is the recommendation for anyone currently using the packaged version > to migrate to the Docker image? > > Maybe this can be communicated accordingly, when no other maintainer can > be found. > > Best regards, > Karol Babioch > > We don't really have any system for communication for things like that in place except for this mailing list. What other mechanism do you imagine?
Re: [aur-general] Dropping official gitlab packages
On Wed, 25 Dec 2019 at 23:18, Anatol Pomozov wrote: > Hi > > On Tue, Dec 24, 2019 at 11:00 PM Sven-Hendrik Haase via aur-general > wrote: > > > > Hi guys, > > > > I maintain the official gitlab packages gitlab, gitlab-gitaly, > > gitlab-runner, gitlab-shell, gitlab-workhorse and python-gitlab. Out of > > these, I'll be dropping gitlab, gitlab-gitaly, gitlab-shell and > > gitlab-workhorse because they are way too much work to maintain and I > can't > > keep up and the result isn't great. > > I remember discussions about using gitlab to manage our (future) git > repos. If we want to go this route then we need to keep gitlab in our > repos. > That is entirely orthogonal because we're using Docker for that currently anyway as we'll use their Enterprise Edition offering which we didn't package.
[aur-general] Dropping official gitlab packages
Hi guys, I maintain the official gitlab packages gitlab, gitlab-gitaly, gitlab-runner, gitlab-shell, gitlab-workhorse and python-gitlab. Out of these, I'll be dropping gitlab, gitlab-gitaly, gitlab-shell and gitlab-workhorse because they are way too much work to maintain and I can't keep up and the result isn't great. Currently known bugs: https://bugs.archlinux.org/task/62837 https://bugs.archlinux.org/task/63679 https://bugs.archlinux.org/task/63688 https://bugs.archlinux.org/task/63935 https://bugs.archlinux.org/task/63950 https://bugs.archlinux.org/task/64337 https://bugs.archlinux.org/task/64887 Unless any other masochistic TU really wants to feel the pain, I'll be dropping them in about two weeks. Sven
Re: [aur-general] TU removal: Ray Rashif
On 08.10.19 14:35, David Runge wrote: > Hi all, > > I would like to start the discussion period for a Trusted User removal > of Ray 'schiv' Rashif on the grounds of 'Special Removal of an Inactive > TU' [1]. Note, that this is separate from any motion in regards to Ray's > developer status. > > Currently Ray is the maintainer of 60 packages in [community] and > [extra], of which none are actively maintained by him (for years). > Ray's last action as a community member (in archweb) has been on > '2019-03-12 12:50'. > The account 'schivmeister' doesn't maintain any packages in the AUR and > the last login in aurweb was on '2019-03-12'. > However, the last counted Trusted User vote is number 117 (current vote: > 118). > > The voting procedure will commence after seven days of discussion > period, in which Ray can state his case. > > Bests, > David > > [1] > https://aur.archlinux.org/trusted-user/TUbylaws.html#_special_removal_of_an_inactive_tu > +1 signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU membership application
On Sat, 17 Aug 2019 at 01:35, Josef Miegl wrote: > On August 16, 2019 10:05:54 PM GMT+02:00, "Balló György via aur-general" < > aur-general@archlinux.org> wrote: > >anydesk, reaper, spotify, teamviewer, unity-editor and unityhub are > >proprietary software with restrictive license. I don't think that you > >can legally distribute them > > Even if we could, is there a reason to flood arch repositories with these > proprietary programs? In my opinion proprietary programs should be an > exception, not the norm. > Josef Miegl > Whether they are proprietary or not has never been a large concern for Arch. What concerns us is whether they are useful or not and whether they'd actually be used by any amount of people. Arch is all about pragmatism. Sometimes, binary blobs are inconvenient for us because if they break we can't fix them. However, that's an entirely separate can of worms which I don't want to open in this thread. Bottom line: If it's legal to package and it's useful and popular software, there's really no reason not to package it.
Re: [aur-general] TU membership application
On Fri, 16 Aug 2019 at 22:35, Oscar wrote: > I'm currently maintaining unity-editor and unityhub and I don't think they > will allow redistribution of binaries. > > They even dropped the official Ubuntu packages in favor of their custom > installers. And honestly it makes more sense to do it this way because the > engine is a big self contained blob and users usually need to have several > different versions installed at the same time to patch old projects etc. > > > > On Fri, Aug 16, 2019, 22:20 Sven-Hendrik Haase via aur-general < > aur-general@archlinux.org> wrote: > >> On Fri, Aug 16, 2019, 22:06 Balló György via aur-general < >> aur-general@archlinux.org> wrote: >> >> > 2019. 08. 16, péntek keltezéssel 15.19-kor Jean Lucas via aur-general >> > ezt írta: >> > > If I were accepted to become a TU, I'd like to adopt and move the >> > > following packages (all having over 10 votes in the AUR) from the AUR >> > > into [community]: >> > > >> > > anydesk, downgrade, exercism, flutter, godot, itch, mattermost- >> > > desktop, >> > > nvm, reaper, spotify, teamviewer, thermald, unity-editor, and >> > > unityhub, >> > > for starters! >> > >> > anydesk, reaper, spotify, teamviewer, unity-editor and unityhub are >> > proprietary software with restrictive license. I don't think that you >> > can legally distribute them. >> > >> > -- >> > György Balló >> > Trusted User >> >> >> Well, you can always ask upstream. So far, we received exceptions for >> redistribution of more software than we got rejections for, I think. >> >> > >> > Never hurts to ask. :) Asking should also be done in the case of all the packages Jean mentioned.
Re: [aur-general] TU membership application
On Fri, Aug 16, 2019, 22:06 Balló György via aur-general < aur-general@archlinux.org> wrote: > 2019. 08. 16, péntek keltezéssel 15.19-kor Jean Lucas via aur-general > ezt írta: > > If I were accepted to become a TU, I'd like to adopt and move the > > following packages (all having over 10 votes in the AUR) from the AUR > > into [community]: > > > > anydesk, downgrade, exercism, flutter, godot, itch, mattermost- > > desktop, > > nvm, reaper, spotify, teamviewer, thermald, unity-editor, and > > unityhub, > > for starters! > > anydesk, reaper, spotify, teamviewer, unity-editor and unityhub are > proprietary software with restrictive license. I don't think that you > can legally distribute them. > > -- > György Balló > Trusted User Well, you can always ask upstream. So far, we received exceptions for redistribution of more software than we got rejections for, I think. >
