On 27/1/19 11:27 pm, Eli Schwartz via aur-general wrote:

On 1/27/19 6:13 AM, Hagar wrote:

...

On 27/1/19 7:01 pm, stefan-husmann@t-online.de wrote:

...

Hello,

Can someone please have a look on what happens on server side?

I want to update gtkhtml4 in AUR adding a long proposed (in the comments) patch.

This fails with

fatal: unable to access 'https://aur.archlinux.org/gtkhtml4.git/': The requested URL returned error: 403

I maybe do not see the obvious, but I can update my other packages without problems, but not thi one, which I newly adopted.

Best Regards

Stefan

Its not well documented - but edit the .git/config file an change the url from https to ssh:

look at the aur page for the package for the exact url.

I hit this problem just last week.

It is pretty well documented.

• We repeatedly document the use of ssh cloning everywhere in the wiki page describing the submission process, and make no mention of using https://

• When logged into the AUR and viewing a package that you maintain, it lists two clone urls: https:// and ssh:// -- and right after the https:// link it specifies in parentheses, "read-only". Read-only means you cannot write to it.

• When viewing a package that you do not maintain or when not even logged into the AUR, only the https:// clone url is referenced, and it still states "read-only".

• Other websites which support pushing over https:// will require you to type in your username and password every time you do, which is unfriendly and I don't understand why anyone would ever want to do so in the first place if they could just use ssh.

True to an extent.

You never specifically say to use ssh to check out the package.

It seems to be just implied. Your examples use both https and ssh.

The problem lies with the section - Acquire build files.

in this section you use http://...

Then later on the instructions for publishing make there is no mention of checking the .git.config to ensure that the correct url is in use.

That simple bit of information is missing.

Those of us who are unfamiliar with git need to know these simple things.

It would be nice if it was specifically mentioned in the instructions -eg.

Please check the .git/.config file of your repository to ensure that your url

is of the form ssh://... .If you get a 403 error you have the wrong url configured.

On 28/1/19 7:57 am, Mark Weiman wrote:

On Mon, 2019-01-28 at 07:42 +0800, hagar wrote:

...

On 27/1/19 11:27 pm, Eli Schwartz via aur-general wrote:

...

On 1/27/19 6:13 AM, Hagar wrote:

...

On 27/1/19 7:01 pm, stefan-husmann@t-online.de wrote:

...

Hello,

Can someone please have a look on what happens on server side?

I want to update gtkhtml4 in AUR adding a long proposed (in the comments) patch.

This fails with

fatal: unable to access ' https://aur.archlinux.org/gtkhtml4.git/': The requested URL returned error: 403

I maybe do not see the obvious, but I can update my other packages without problems, but not thi one, which I newly adopted.

Best Regards

Stefan

Its not well documented - but edit the .git/config file an change the url from https to ssh:

look at the aur page for the package for the exact url.

I hit this problem just last week.

It is pretty well documented.

• We repeatedly document the use of ssh cloning everywhere in the

wiki page describing the submission process, and make no mention of using https://

• When logged into the AUR and viewing a package that you maintain,

it lists two clone urls: https:// and ssh:// -- and right after the https:// link it specifies in parentheses, "read-only". Read- only means you cannot write to it.

• When viewing a package that you do not maintain or when not even logged into the AUR, only the https:// clone url is referenced,

and it still states "read-only".

• Other websites which support pushing over https:// will require

you to type in your username and password every time you do, which is unfriendly and I don't understand why anyone would ever want to do so in the first place if they could just use ssh.

True to an extent.

You never specifically say to use ssh to check out the package.

It seems to be just implied. Your examples use both https and ssh.

The problem lies with the section - Acquire build files.

in this section you use http://...

Then later on the instructions for publishing make there is no mention of checking the .git.config to ensure that the correct url is in use.

That simple bit of information is missing.

Those of us who are unfamiliar with git need to know these simple things.

It would be nice if it was specifically mentioned in the instructions -eg.

Please check the .git/.config file of your repository to ensure that your url

is of the form ssh://... .If you get a 403 error you have the wrong url configured.

A 403 does not mean you have an incorrect URL. A 403 means the server understood the request and it exists, but you do not have permission to use that resource. It is rather clear that the https URLs are read only on the AUR and a 403 error is the correct error to state that you cannot push over that protocol as you made a request that you do not have permission to do.

The AUR section you're talking about that mentions acquiring build files is just that, for building. Not pushing updates to the PKGBUILD. It is understood that if you read the wiki and follow the directions on how to publish changes to the AUR, you use the SSH protocol and if you see a 403 error on HTTP if you make a mistake and use that, that you will be capable to interpreting that as you made a mistake.

Just my $0.02.

Mark

Thank you for clearing that up - I found no reference to what a 403 error actually was.

All I wish is for the editing of .git.config to be documented with the note to use the ssh://

url to checkout if you wish to push  changes back.

This was the first time I had used git for this purpose and had to debug it the hard way.

As I mentioned a couple of months back - Not everyone has the same communication skills.

What may be clear to you may not be to someone else. I learned the hard way that -

"There is no such thing as common sense."

All I wish to do is help improve the AUR.

Thanks

Macca

On 28/1/19 8:46 am, Mark Weiman wrote:

On Mon, 2019-01-28 at 08:09 +0800, hagar wrote:

...

As I mentioned a couple of months back - Not everyone has the same

...

communication skills.

What may be clear to you may not be to someone else. I learned the hard way that -

"There is no such thing as common sense."

All I wish to do is help improve the AUR.

Thanks

Macca

HTTP 403 is an HTTP code and is therefore documented with the HTTP RPC.

.git/config is a file part of a git repository and is documented with the git application. The use of git especially is understood to be, well, understood before using the AUR.

Arch Linux, as far as I'm aware, assumes you know about how to use tools like git and I would also assume that you are capable of figuring out what an HTTP error code means based on something simple like the Wikipedia page that discusses HTTP status codes in detail.

If you feel otherwise though, the Arch Wiki can be edited by any Arch user that creates an account on the Wiki, but that's not something the TUs or others like me in this channel are responsible for since its kinda assumed to be at least familiar with git before using it (which the AUR uses it).

Mark

I am concerned that the experienced users of tgis list dont seem to want to help "newbies"

Any time they feel a question is in the realm of "Common Sense" they seem to make "Assumptions"

then the user is summarily "told off".

A general question to the community.

Do you want new users or not?

You cant just make assumptions.

You cant just tell people that the it is well documented.

Why don't you just help them along in the first place. Build them up and actually point them to helpful pages first.

Then actually check the documentation from a new users point of view to see if it -

1. Has missing information.

2. Can be misinterpreted. (Not everyone has good language skills.)

I am experienced in Linux, from LTFS, to Ubuntu. But have never had to use git until now. I missed a simple thing that I managed to fix myself.

But I never make the assumption that others can do what I do.

Please rather than flame new users, can we nurture and train them instead. Give them specific help rather than a general "Read the docs."

I have found that for every person who has a problem and asks the question there are hundreds of people who have the same problem But don't ask.

If anyone has watched Sesame Street you will be familiar with -

Asking questions is a good way of getting answers.

Please, Please, can the experienced users here help rather than flame.

Just my 0.02 cents worth.

On 1/27/19 8:04 PM, hagar wrote:

...

HTTP 403 is an HTTP code and is therefore documented with the HTTP RPC.

.git/config is a file part of a git repository and is documented with the git application. The use of git especially is understood to be, well, understood before using the AUR.

Arch Linux, as far as I'm aware, assumes you know about how to use tools like git and I would also assume that you are capable of figuring out what an HTTP error code means based on something simple like the Wikipedia page that discusses HTTP status codes in detail.

If you feel otherwise though, the Arch Wiki can be edited by any Arch user that creates an account on the Wiki, but that's not something the TUs or others like me in this channel are responsible for since its kinda assumed to be at least familiar with git before using it (which the AUR uses it).

Mark

I am concerned that the experienced users of tgis list dont seem to want to help "newbies"

Any time they feel a question is in the realm of "Common Sense" they seem to make "Assumptions"

then the user is summarily "told off".

This is correct! We do not want to help newbies.

https://wiki.archlinux.org/index.php/Arch_Linux#User_centrality

Arch Linux, the distribution, is "targeted at the proficient GNU/Linux user, or anyone with a do-it-yourself attitude who is willing to read the documentation, and solve their own problems".

It is generally considered that the minimum requirement for running Arch Linux is a willingness and understanding of how to google for error messages before asking for help.

If that is too much for people to handle, that doesn't make them a bad person -- it just means they would be happier with a Linux distribution that was actually designed with the target userbase of newbies who just want things to work and receive help in getting it to work as fast as possible.

A general question to the community.

Do you want new users or not?

No. Arch Linux has never attempted to advertise itself with the goal of acquiring new users. Rather, Arch Linux has attempted to position itself as a useful, advanced technical platform for doing things that existing users wish to happen.

We do not *turn away* new users -- on the contrary, we encourage anyone who wishes to learn more about Arch, to feel welcome in doing so. But we will not change Arch in order to do so.

You cant just make assumptions.

You cant just tell people that the it is well documented.

But it is well documented, as far as I can tell.

For example: https://wiki.archlinux.org/index.php/Git#Protocol_defaults https://wiki.archlinux.org/index.php/Arch_User_Repository#Submitting_package...

as well as the clone urls listed on the aurweb website, which as I said before, explicitly refer to https:// as "read-only".

Why don't you just help them along in the first place. Build them up and actually point them to helpful pages first.

But I find myself more interested in interesting questions, rather than just being here to tell people where the documentation is. Who are you to tell me what I should find more enjoyable?

If you want someone to be available to point people to the documentation, no one is stopping you from fulfilling that role yourself. Which in fact you did. And I have merely stepped in to correct what I felt to be a technical incorrectness: namely, that we do document the process, and I am unaware of any bug in that documentation. (I have selfish interests in caring whether the documentation is in order -- I am one of the aurweb maintainers. But as far as I can tell, the aurweb is doing everything it can, here.)

Then actually check the documentation from a new users point of view to see if it -

1. Has missing information.

2. Can be misinterpreted. (Not everyone has good language skills.)

The documentation is a collaborative effort, *precisely* because it is not obvious when things are missing. It's a wiki for a very good reason.

If I thought there was missing information, obviously I'd fix it.

Obviously I do not think there is missing information, because I understand it just fine. This is a very common problem with knowledgeable people who don't need the documentation, that they think things are so obvious that they don't know what needs to be spelled out to others.

If you think there is documentation missing, why don't you add it, since you're the one who seems to understand what is missing?

I am experienced in Linux, from LTFS, to Ubuntu. But have never had to use git until now. I missed a simple thing that I managed to fix myself.

But I never make the assumption that others can do what I do.

Please rather than flame new users, can we nurture and train them instead. Give them specific help rather than a general "Read the docs."

Who is flaming anyone? https://en.wikipedia.org/wiki/Flaming_(Internet)

I have found that for every person who has a problem and asks the question there are hundreds of people who have the same problem But don't ask.

If anyone has watched Sesame Street you will be familiar with -

Asking questions is a good way of getting answers.

Asking questions is also a good way of:

- getting people to do things so you don't have to, like googling for https://www.google.com/search?q=The+requested+URL+returned+error%3A+403 and using the very first search result

- avoiding the process of actually doing things, by talking about it instead editing the wiki.

Please, Please, can the experienced users here help rather than flame.

Again with the flaming. Who is flaming? Why is it more important to talk about who may be flaming who, than editing the wiki?