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
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.
Re: [aur-general] AUR Comment for white_dune
On 12/27/19 9:26 AM, J. Scheurich wrote: > $ git remote set-url origin a...@aur.archlinux.org:white_dune.git > $ git pull white_dune master > ssh: Could not resolve hostname 2a01: Name or service not known > fatal: Could not read from remote repository. > > Please make sure you have the correct access rights > and the repository exists. Why did you set the remote url for "origin", then try to pull from "white_dune"? What is the "white_dune" remote? Consider deleting your clone, re-cloning, and redoing your changes. It might help you avoid confusing configurations. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [aur-general] Dropping official gitlab packages
Hi On Fri, Dec 27, 2019 at 4:19 AM Sven-Hendrik Haase wrote: > > > > 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. Got it. Sven-Hendrik, I am actually interested to learn more about gitlab product and its internals. I see that our package uses the old version of ruby. Updating the package to ruby-2.6/2.7 and fixing some of the bugs you mentioned will be a great opportunity for me to learn gitlab and help community at the same time. But as we do not plan to use this package at out site then I do not want to invest too much time into it. What do you think if I take the ownership over the packages you mentioned then port it to newer ruby and later (around spring 2020) drop it to AUR?
Re: [aur-general] Dropping official gitlab packages
On Fri, Dec 27, 2019 at 01:19:08PM +0100, Sven-Hendrik Haase via aur-general wrote: > 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. I'm greatly behind the idea of dogfooding, but I understand the technical limitations and its practical scope. We may perhaps need to take on this beyond a packaging challenge but something we can pick up as a project... Have we been able to talk with upstream and air our concerns? maybe we could start a more closely-knit collaboration with them and improve the state of their build toolchain? Cheers, -Santiago signature.asc Description: PGP signature
Re: [aur-general] AUR Comment for white_dune
git makes strange things 8-( $ git add .SRCINFO PKGBUILD $ git commit [master c25bda5] white_dune 1.654 rollback 2 files changed, 6 insertions(+), 4 deletions(-) $ git push To aur.archlinux.org:white_dune.git ! [rejected] master -> master (non-fast-forward) error: failed to push some refs to 'a...@aur.archlinux.org:white_dune.git' hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. Integrate the remote changes (e.g. hint: 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details. [mufti@archlinux archlinux_white_dune]$ git pull There is no tracking information for the current branch. Please specify which branch you want to merge with. See git-pull(1) for details. git pull If you wish to set tracking information for this branch you can do so with: git branch --set-upstream-to=/ master $ git pull white_dune master ssh: Could not resolve hostname 2a01: Name or service not known fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. $ git remote set-url origin a...@aur.archlinux.org:white_dune.git $ git pull white_dune master ssh: Could not resolve hostname 2a01: Name or service not known fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. I have no idea what you are trying to do here. What modifications have you made to https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=white_dune ? I change the pkgver to 1.654 and removed the . from the J. Scheurich comment Have you fixed your ssh issue yet? I uploaded .ssh/id_rsa.pub to the aur website so long MUFTI
Re: [aur-general] AUR Comment for white_dune
On 12/27/19 3:46 AM, J. Scheurich wrote: > Hi, > > I dont understand the following: > > # Maintainer: J Scheurich > pkgname=white_dune > pkgver=1.654 > pkgrel=1 > epoch= > pkgdesc="white_dune X3D/VRML97 tool" > arch=() > url="ftp://ftp.ourproject.org/pub/wdune/$pkgname-$pkgver.tar.bz2"; > ... > $ pkgname=white_dune > $ pkgver=1.654 > $ wget "ftp://ftp.ourproject.org/pub/wdune/$pkgname-$pkgver.tar.bz2"; > --2019-12-27 09:36:02-- > ftp://ftp.ourproject.org/pub/wdune/white_dune-1.654.tar.bz2 > => 'white_dune-1.654.tar.bz2' > Resolving ftp.ourproject.org (ftp.ourproject.org)... 80.81.122.49 > Connecting to ftp.ourproject.org > (ftp.ourproject.org)|80.81.122.49|:21... connected. > Logging in as anonymous ... Logged in! > ==> SYST ... done. ==> PWD ... done. > ==> TYPE I ... done. ==> CWD (1) /pub/wdune ... done. > ==> SIZE white_dune-1.654.tar.bz2 ... 24429987 > ==> PASV ... done. ==> RETR white_dune-1.654.tar.bz2 ... done. > Length: 24429987 (23M) (unauthoritative) > > white_dune-1.654.ta 100%[===>] 23.30M 1.35MB/s in 15s > > 2019-12-27 09:36:19 (1.58 MB/s) - 'white_dune-1.654.tar.bz2' saved > [24429987] > > $ rm white_dune-1.654.tar.bz2 > $ updpkgsums > ==> Retrieving sources... > ==> ERROR: white_dune-1.654.tar.bz2 was not found in the build directory > and is not a URL. > ==> ERROR: Failed to generate new checksum > > The URL exists, but updpkgsums refuses to read it... Because "url" shows the homepage of the software, and has nothing to do with the "source" to be downloaded. I have no idea what you are trying to do here. What modifications have you made to https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=white_dune ? Have you fixed your ssh issue yet? -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
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] AUR Comment for white_dune
Hi, I dont understand the following: # Maintainer: J Scheurich pkgname=white_dune pkgver=1.654 pkgrel=1 epoch= pkgdesc="white_dune X3D/VRML97 tool" arch=() url="ftp://ftp.ourproject.org/pub/wdune/$pkgname-$pkgver.tar.bz2"; ... $ pkgname=white_dune $ pkgver=1.654 $ wget "ftp://ftp.ourproject.org/pub/wdune/$pkgname-$pkgver.tar.bz2"; --2019-12-27 09:36:02-- ftp://ftp.ourproject.org/pub/wdune/white_dune-1.654.tar.bz2 => 'white_dune-1.654.tar.bz2' Resolving ftp.ourproject.org (ftp.ourproject.org)... 80.81.122.49 Connecting to ftp.ourproject.org (ftp.ourproject.org)|80.81.122.49|:21... connected. Logging in as anonymous ... Logged in! ==> SYST ... done. ==> PWD ... done. ==> TYPE I ... done. ==> CWD (1) /pub/wdune ... done. ==> SIZE white_dune-1.654.tar.bz2 ... 24429987 ==> PASV ... done. ==> RETR white_dune-1.654.tar.bz2 ... done. Length: 24429987 (23M) (unauthoritative) white_dune-1.654.ta 100%[===>] 23.30M 1.35MB/s in 15s 2019-12-27 09:36:19 (1.58 MB/s) - 'white_dune-1.654.tar.bz2' saved [24429987] $ rm white_dune-1.654.tar.bz2 $ updpkgsums ==> Retrieving sources... ==> ERROR: white_dune-1.654.tar.bz2 was not found in the build directory and is not a URL. ==> ERROR: Failed to generate new checksum The URL exists, but updpkgsums refuses to read it... so long MUFTI
Re: [aur-general] Dropping official gitlab packages
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.
Re: [aur-general] AUR Comment for white_dune
Hmmm... May I know whether you've actually uploaded your public key to https://aur.archlinux.org/account//edit/? And what about the file permissions of your key files? IIRC it should be something stricter than or equal to 600 for the private key. Output from `ssh -Tv aur.archlinux.org` may help us further identify the issue. Btw ~/.ssh/config actually doesn't need the first level of indentation. Sorry that my email was a bit confusing. I remember this file should be indentation- insensitive tho. Best regards, Frederick Zhang --- Email: frederick...@tsundere.moe Blog: https://blog.onee3.org > On 27 Dec 2019, at 5:33 pm, J. Scheurich wrote: > > Hi, > > Are you able to successfully run this command: > > ssh -t...@aur.archlinux.org > > If not, you will need to fix your ssh setup until this works. > > $ ssh -T a...@aur.archlinux.org > The authenticity of host 'aur.archlinux.org (2a01:4f8:160:3033::2)' > can't be established. > ECDSA key fingerprint is SHA256:L71Q91yHwmHPYYkJMDgj0xmUuw16qFOhJbBr1mzsiOI. > Are you sure you want to continue connecting (yes/no/[fingerprint])? yes > Warning: Permanently added 'aur.archlinux.org,2a01:4f8:160:3033::2' > (ECDSA) to the list of known hosts. > a...@aur.archlinux.org: Permission denied (publickey). > > How to fix the ssh setup ? > > ssh-keygen do not help 8-( > > $ cat .ssh/config > > Host aur.archlinux.org > User aur > PreferredAuthentications publickey > IdentityFile ~/.ssh/id_rsa > $ ssh -T a...@aur.archlinux.org > a...@aur.archlinux.org: Permission denied (publickey). > $ > > > so long > MUFTI signature.asc Description: Message signed with OpenPGP
