Difference between revisions of "User talk:Det"

From ArchWiki
Jump to: navigation, search
(sudo for makepkg -si: interwiki links)
(sudo for makepkg -si: close)
Line 1: Line 1:
== sudo for makepkg -si ==
== <s>sudo for makepkg -si</s> ==
To install the package it needs sudo. It tried to sudo for me just now and because I hadn't set wheel execute all the installation failed. Did I put the remark in the wrong place in the text?
To install the package it needs sudo. It tried to sudo for me just now and because I hadn't set wheel execute all the installation failed. Did I put the remark in the wrong place in the text?

Revision as of 16:23, 21 July 2015

sudo for makepkg -si

To install the package it needs sudo. It tried to sudo for me just now and because I hadn't set wheel execute all the installation failed. Did I put the remark in the wrong place in the text?

Right, you meant that sudo is a dependency of makepkg (pacman). However, sudo's in the base-devel group, which is mentioned across the article to assumed to have been installed when building with makepkg:

  #Getting started

  • Ensure the base-devel package group is installed (pacman -S --needed base-devel).


First ensure that the necessary tools are installed. The package group base-devel should be sufficient; it includes make and other tools needed for compiling from source.
Warning: Packages in the AUR assume the base-devel group is installed, and AUR packages will not list members of this group as dependencies even if the package cannot be built without them. Please ensure this group is installed before complaining about failed builds.
# pacman -S --needed base-devel
--Dettalk 15:00, 11 July 2015 (UTC)
Checking the log I did that. The problem is that the user need to do visudo and get themselves in the sudo-ers or makepkg -si will fail. --Orbifx (talk) 15:47, 11 July 2015 (UTC)
Don't move this, that was me. I added a note about configuring sudo to Makepkg#Usage.
There's already the following note at the end of AUR#Build and install the package to go through it, and we try to duplicate information as little as possible to prevent cross-article changes and outdated pages, even if that means jumping across a few extra articles for the reader:
Note: The above example is only a brief summary of the package build process. It is highly recommended to read the makepkg and ABS pages providing more detail about the build process.
--Dettalk 17:21, 11 July 2015 (UTC)

Editing etiquette

Hi, would you mind explaining why I shouldn't just revert this edit, which has very ugly diff, makes it impossible (for a lazy person like me) to assess what actually happened, and apparently some content has been lost/removed (history shows -1585 bytes in summary)?

Usually edit summary is used to justify edits, and large changes are usually split into multiple smaller edits. FYI, Help:Style#Edit summary makes all this mandatory.

As there is no easy way to subsequently split edits, here is your chance to at least add the missing edit summary.

Thanks, Lahwaacz (talk) 10:38, 1 July 2014 (UTC)

I do a lot of cleanups like this and don't always put the edit summary in, as it will almost invariably end up being pretty obvious anyway (the actual page, not the diff, is what looks better).
The Help page doesn't actually mandate this, as that could indeed end up meaning any major edit without a summary can be reverted simply on those grounds. The current guideline only states that bigger edits should be put into smaller pieces and preferably all provided with a summary, and I agree, but since nobody ever mentioned this, I assumed they just didn't care too much. --Dettalk 19:28, 1 July 2014 (UTC)
There are people who care, and those who follow articles' history always use the diff mode to view the changes. The diff mode exists for a reason; examining two different revisions by comparing the rendered HTMLs is not an option, especially after longer period of time, which must be also accounted for.
The linked help page says (emphasis mine):
"The changes made daily to the articles are bravely checked by dedicated and voluntary patrols, whom you must help by making sure that all of your edits are accompanied by an explanatory phrase in the "Summary" field of the editor page."
Filling in the edit summary is the basic rule, but of course there have been much smaller edits reverted and much larger found perfectly valid - I'm just trying to find out which category yours falls in. I will go through your edit thoroughly as soon as I can, but the supplementary edit summary would be really useful. (No, just "cleanup" is not enough.)
And of course, hopefully we can avoid this issue in the future...
-- Lahwaacz (talk) 20:30, 1 July 2014 (UTC)
Well, I wasn't comparing diffs with comparing the actual pages, my point was that the actual page (the result) is what matters, and should be the first priority when reverting something - not just the diff that doesn't look optimal and there's no summary what was done (or maybe that was just my conclusion, when you began with "would you mind explaining why I shouldn't just revert this edit [...]").
I often do a lot of different kinds of cleanups, section moves, simplifications, templateifications, rewrotes, and a lot of other minor things, too, so that's why I assumed people didn't care too much when I didn't split them and provide separate summaries for all of them. In fairness, I didn't say people didn't care at all, I said they didn't care that much. --Dettalk 22:09, 1 July 2014 (UTC)
Fair enough, apologies for my bad start. Having gone through the change more thoroughly, I found nothing serious to revert, I've made only minor changes. Please understand that at first glance such changes look really suspicious and usually take longer to go through than a series of smaller changes (especially when there is movement of sections/paragraphs involved).
I hope that this issue can be avoided in the future. -- Lahwaacz (talk) 22:47, 1 July 2014 (UTC)
I see this is already sort of settled, but I'd like to step in because some things need clarification. I perfectly know that you (Det) have been working in the wiki for many years, even before I started myself, however during this time the wiki has become more and more organized and many rules have been added to improve the collaboration among contributors and help solve any disputes or misunderstandings that may arise. I've never explicitly pointed you to those rules because I've always in a way or another managed to understand your edits, overlooking the absence of summaries or the complexity of the diffs.
> "my point was that the actual page (the result) is what matters, and should be the first priority when reverting something"
Yes, the result is what matters, but you can't force people to always spend their time to compare the two revisions in full, it's like if you provided a single patch for a software that changes 843 lines in 13 files, possibly without even a commit message: nobody would ever check it, let alone applying it, right? ;) You make it much easier and quicker if you show everybody how you reached the final revision step by step, and, please allow me to humbly state this, the only reason not to split edits or write summaries (despite knowing it's recommended) is laziness, isn't it, so I'm sure you can improve this part without much effort :)
> "I assumed people didn't care too much when I didn't split them and provide separate summaries"
It's true, you don't know for sure if somebody will ever check your edits, so you do have to make an assumption; this assumption, however, is that your edits will be checked, simply because this is a wiki, and wikis are designed to create documents in a collaborative way.
I really hope you will understand that I'm writing this with all the respect you deserve, as I really appreciate your contributions: my only intention is to take this opportunity to improve this aspect of your efforts in this project, just like I'd do with any other important contributor, and make this community a better place to work for everyone.
-- Kynikos (talk) 06:23, 2 July 2014 (UTC)
No, it's completely settled. I'll try to be better. --Dettalk 12:54, 3 July 2014 (UTC)

Last supported kernels

Re [1], please keep in mind that 3.14 is supported in Arch via linux-lts. -- Alad (talk) 18:21, 19 August 2014 (UTC)

Indeed it is, and that sectioning is much better, but you also reverted some extra fixes from that revision, so I put those back in there. --Dettalk 21:19, 19 August 2014 (UTC)
Thanks, closing. -- Alad (talk) 21:40, 19 August 2014 (UTC)


Re [2], how is "pkgdir" useless? It's used in nearly every PKGBUILD, make is very common too, unless I'm missing something... -- Alad (talk) 11:57, 5 February 2015 (UTC)

The difference is that pkgdir is not to be defined by the packager, so it does not make sense to describe it among variables defined by the packager. It is still described in Creating_packages#Defining_PKGBUILD_variables though. -- Lahwaacz (talk) 13:12, 5 February 2015 (UTC)
Hm, I see. I'd then suggest to change the introductory sentences,
This article discusses the variables used in PKGBUILDs. For information on the PKGBUILD functions, refer to Creating packages#PKGBUILD functions.
The following are variables that can be filled out in the PKGBUILD file
are ambiguous imo. -- Alad (talk) 13:22, 5 February 2015 (UTC)
Done. Is it good? --Dettalk 17:18, 5 February 2015 (UTC)
Works for me, thanks. But I'm having difficulties understanding [3] ... -- Alad (talk) 20:27, 5 February 2015 (UTC)
Yeah, I know, it was pretty difficult to try to summarize all that in one description, but it's basically changing things like:
It is not necessary to specify the version of the packages required. You do not need to list packages that your software depends on if other packages your software depends on already have those packages listed in their dependency
Dependencies that are provided by other dependencies do not need to be listed.
So, removing repetition, unnecessary chatter, and using phrases like "available options are A and B", instead of "you can do A but you can also go ahead and do B", etc. --Dettalk 20:39, 5 February 2015 (UTC)
No, sorry but much of what you removed wasn't "unnecessary chatter" at all, and it's taken me a long time to restore it all, being forced to compare the original and modified revisions side-by-side, line-by-line, because you completely ignored ArchWiki:Contributing#Do_not_make_complex_edits_at_once again, even though I thought we had settled that in User talk:Det#Editing etiquette. Of course "it was pretty difficult to try to summarize all that in one description", a change like that should have been split in at least 10 edits, which would have made it incredibly easier to write a proper summary for each of them. We all patiently try to make our changes as comprehensible as possible to the other users, why is it so hard to return the favor?
Then, regarding your intentions, trying to make content less verbose is certainly one (good) thing, but trimming details is a different (bad) one, even worse if done by a user, like you, who is supposed to have a lot of editing experience now and be much more trustworthy.
Kynikos (talk) 15:56, 6 February 2015 (UTC)
Hello, Kynikos. I can say this is not yet another good experience for me either, I thought about it only after having saved the whole thing, and when Alad didn't do any follow-up edits (or ask for more input), I honestly thought 'okay, well maybe there was nothing to improve after all..(?)'. Obviously, yes there was.
My last recollection of this was in Wikipedia IRC, where they told me that many prefer seeing one big edit to not clog up the recent changes (same as on another Wiki). I know you spent a lot of time and effort on this, including showing me the references (looking at the history, over 2 hours), but I have to ask, why didn't you ask me: “hey Det, maybe you forgot, but last year in July we agreed that edits like this should be split into multiple smaller ones. Therefore, can I ask you to revert/I reverted your edit so that you can more clearly have it run through us, section-by-section. I simply don't have the time to review this type of big chunk again, but I *would* like to review it. Thank-you.”
I mean, granted, I know a lot of people have had problems with my attitude (including our very own developers; I've even been called out in public in bug reports for dubious reasons, too[4]; when asked to clarify, suddenly there's no response), but I think I've improved on those points, and the effort for me to have gone through my own edit would have been absolutely minuscule compared to all the work you had to put in. I hate having to witness that I've basically been wasting your time.
But now that it's happened, I do apologise.
Dettalk 21:56, 6 February 2015 (UTC)
Well, I admit I appreciate your answer: if this time I've really managed to make you understand and remember the etiquette, it's been two well spent hours.
The fact that Alad didn't reply immediately nor make any follow-up edits didn't necessarily mean that he agreed with you; it's more likely that he just didn't have the time to do so.
In this wiki we collaborate in a different way than Wikipedia or other wikis: we don't encourage users to be that bold, as we don't have the same workforce to rely on the fact that somebodyelse™ will fix bad edits. Users should absolutely not edit articles the way they feel at that moment, thinking "if it's wrong it will get fixed": this approach would be only destructive here; if you're unsure about something, ask first in a discussion page; if you don't have the time to make a proper edit, do it later when you find enough time, possibly marking temporarily the article or section with a status template, which is instead a very quick thing to do. I think this philosophy is reflected pretty well in ArchWiki:Contributing, but we can always improve it if that wasn't the case.
About the recent changes, don't worry at all: the list can be filtered by enabling the Group changes by page in recent changes and watchlist setting under Preferences > Recent changes > Advanced options. Probably in other wikis (including Wikipedia?) they aren't used to visiting their users preferences...
Honestly, if I really asked you to revert your edit and do it again in smaller changes, would have you really done it? I've tried that approach in the past with other users, and the result has always been to only seriously annoy them without them learning anything, sometimes even making them leave the community; not that I regret it at all, getting rid of irritable/stubborn users is always an extremely good result: by reading your answer, and the fact that you're still contributing after many years, I see you're not one of them, so I hope I will really see an improvement in the future, and you will even start setting a good example for inexperienced users, like it should be at this stage.
Kynikos (talk) 04:28, 7 February 2015 (UTC)
I agree, I probably might've been a bit vexed, but as we've already had that discussion, that's the right that was given to you. I think I've learned a lesson over the years, little by little, that when it comes to Wikis, an admin will know best. Don't argue, do what he says, and then you can both have a good smile about your ultimate community efforts.
On an unrelated note, I'd like to preserve this discussion in my talk page. That's probably all right?
Dettalk 05:02, 7 February 2015 (UTC)
Great, you can certainly copy this discussion on your talk page, nobody will touch it there. I've closed it meanwhile, in any case please leave it also here until it will be removed after a few days as usual, together with the other closed discussions. — Kynikos (talk) 06:37, 7 February 2015 (UTC)