Difference between revisions of "User talk:Lahwaacz"

From ArchWiki
Jump to: navigation, search
(Undo to “Making a DE/WM choice”)
m (AMDGPU license edit: remove closed discussion)
 
(218 intermediate revisions by 30 users not shown)
Line 1: Line 1:
== Fork Bomb ==
+
== PodCastXDL ==
  
[[Fork_Bomb]]: This new article worries me a bit, as it provides an example of how to do one. [[User:Carlduff|Carlduff]] ([[User talk:Carlduff|talk]]) 21:04, 30 November 2013 (UTC)
+
About [https://wiki.archlinux.org/index.php?title=List_of_applications/Internet&diff=prev&oldid=323048] (and [https://wiki.archlinux.org/index.php?title=List_of_applications/Internet&diff=next&oldid=323048]) [[User:Levi0x0x]], who should have indeed provided an edit summary, appears to be the developer of the application and the maintainer of the PKGBUILD. I would keep his edit. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 00:45, 5 July 2014 (UTC)
  
:But it also contains some information regarding prevention, so I'm fine with its existence. I can't comment on the factual accuracy though. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:46, 2 December 2013 (UTC)
+
:I know - I've seen also [https://wiki.archlinux.org/index.php?title=MPlayer&diff=next&oldid=322278 bash-player] removed, both from wiki and Github (it seems the repo has been recreated from scratch). PodCastXDL has always been available upstream. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:20, 5 July 2014 (UTC)
  
== Openbox ==
+
::Didn't he add it to the list one week ago? [https://wiki.archlinux.org/index.php?title=List_of_applications/Internet&diff=prev&oldid=322258] Maybe he's found some bug and doesn't want people to use it until he fixes it? Anyway I'm not that interested, we can as well see if/how Levi0x0x reacts. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:32, 6 July 2014 (UTC)
RE: Revision [https://wiki.archlinux.org/index.php?title=Openbox&oldid=286926]
+
  
A dependency of [[Thunar]] is {{pkg|libxfce4ui}}. A sub-package of {{pkg|libxfce4ui}} is '''xfce4-about'''. For confirmation see: [https://apps.fedoraproject.org/packages/xfce4-about/]. So I would not describe my work as being "useless" or "inaccurate". There are however many useless and inaccurate articles on this wiki, which seem to be ignored in favour of putting my contributions under a microscope instead.
+
== bot AUR to Official Repository edit ==
  
:OK, there has been a slight misunderstanding with the ''xfce4-about'' - it is not a (sub)package in Arch terms, I'd say it is a binary/executable that is part of {{Pkg|libxfce4ui}}. I was looking for an Arch package under that name.
+
A recent bot edit ([https://github.com/lahwaacz/wiki-scripts/blob/master/update-package-templates.py update Pkg/AUR templates]) by [[User:Lahwaacz.bot]] on the [[Gitolite]] page correctly changed the AUR template to Pkg but left the [[Arch User Repository]] link
:First of all, why recommend some application when the user is discouraged from installing it in next sentence? Also, I'd say that an average Arch user knows about the dependency chain, and checks which dependencies are installed if he cares.
+
:You are not under a microscope, it just happened that [[Openbox]] is in my watchlist. Believe me that I check all pages from my watchlist equally. True, I don't check all new edits in [[Special:RecentChanges]], that's just beyond my powers...
+
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:43, 7 December 2013 (UTC)
+
:: I am trying not to allow personal bias get too much in the way of contributions, which is why I listed a range of FMs without specifically recommending any of them, including those without their own wiki pages. A warning was placed about Thunar as although it is an excellent FM (I personally prefer SpaceFM), the exo and xfce4-about menu entries can irritate users like myself who want a "harmonious"-looking desktop. Experienced users would know this; I'm just trying to be helpful for others like myself who want to learn.
+
:: Of course I understand being corrected when I neglect to adhere to the guidelines, but sometimes the amendments do seem a bit over-critical. It has seemed at times as if it is being done of out irritation than anything else (as apparently evidenced by being called "usless"). Personally, I would rather just be told to go away if I am considered as being provocative in some way. [[User:Carlduff|Carlduff]] ([[User talk:Carlduff|talk]]) 17:01, 7 December 2013 (UTC)
+
  
== Undo ==
+
I fixed this, but would it be possible to modify the bot to take this into consideration?
Lahwaacz, why do you undo my change about vconsole.conf in Beginner's Guide? I tried what was written there, and that's not working, but change that I does solved this problem
+
  
[[User:Kycok|Kycok]] ([[User talk:Kycok|talk]])
+
I can imagine that blanket changing AUR links to Official Repository links in any given page could be dangerous - but for common phrasing or possibly word distance it would seem to be relatively safe
  
:See {{ic|man vconsole.conf}}, it clearly says that the path is {{ic|/etc/vconsole.conf}} and not {{ic|/etc/fonts/vconsole.conf}}. I don't know what's your problem, please use [https://bbs.archlinux.org/ the forums] to solve it. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:14, 24 December 2013 (UTC)
+
Or is there some sort of post-run manual inspection that I am unaware of that handles this situation?
  
::Ok, thnx. Maybe it's not working only on my system
+
Specifically this [https://wiki.archlinux.org/index.php?title=Gitolite&diff=next&oldid=366859 edit]
  
== Undo to “Making a DE/WM choice” ==
+
From:
 +
<pre>
 +
{{AUR|gitolite}} is available in the [[Arch User Repository]]
 +
</pre>
  
Hi Lahwaacz,
+
To:
 +
<pre>
 +
{{Pkg|gitolite}} is available in the [[Arch User Repository]]
 +
</pre>
  
    > ### Latest revision as of 2013-12-27T12:41:21 (edit) (undo) ###
 
    > Lahwaacz (Talk | contribs)
 
    > (Undo revision 290591 by Montague (talk) - why do you use 'xinit exec startxfce'
 
    > instead of 'xinit startxfce' (resp. the shorter 'xinit xfce', if available)?)
 
  
I do use the short version, i.e. 'xinit xfce', and I do not use 'xinit exex startxfce'
 
More precisely, I use the the even shorter 'xinit' (since I launch the default).
 
  
I don't think I was very clear in my first edit of the wiki article :-)
+
[[User:Tido.com|Tido.com]] ([[User talk:Tido.com|talk]]) 01:50, 1 April 2015 (UTC)
What I meant was that in the following code, when you launch the default
+
(in this case xfce) by simply typing 'xinit', the code will first do 'exec $1',
+
but since '$1' is defined as {1:-xfce}, when it reaches that statement the code
+
will then do 'exec startxfce4', the end result being that by typing 'xinit' in
+
the console, what is actually being executed is 'exec exec startxfce4'.
+
  
That's why I thought the last exec (in the line '*) exec $1;;') had to
+
By "word distance" above what I _meant_ was [[Wikipedia:Edit Distance|Edit Distance]] ;)
be removed.
+
  
What was causing problems on my system was that if I tried to add more
+
I was initially thinking of Hamming distance - but apparently that is for strings of equal length.
commands before the 'exec' of the default, e.g. 'xfce) urxvt & exec startxfce4;;'
+
what would actually be executed is 'exec urxvt & exec startxfce4'
+
  
I don't know if I am making any sense ?
+
What looks more promising is the Levenshtein distance - specifically "Comparing a list of strings" from the Python [https://pypi.python.org/pypi/Distance/0.1.3 Distance] package.
  
 +
Example shamelessly ripped from that page:
  
    # Here Xfce is kept as default
+
(mainly because I couldn't link directly to the relevant section)
    session=${1:-xfce}
+
   
+
    case $session in
+
            enlightenment) exec enlightenment_start;;
+
            fluxbox) exec startfluxbox;;
+
            gnome) exec gnome-session;;
+
            lxde) exec startlxde;;
+
            kde) exec startkde;;
+
            openbox) exec openbox-session;;
+
            xfce) exec startxfce4;;
+
            # No known session, try to run it as command
+
            *) exec $1;;               
+
    esac
+
  
[[User:Montague|Montague]] ([[User talk:Montague|talk]]) 06:17, 29 December 2013 (UTC)
+
<pre>
 +
>>> sent1 = ['the', 'quick', 'brown', 'fox', 'jumps', 'over', 'the', 'lazy', 'dog']
 +
>>> sent2 = ['the', 'lazy', 'fox', 'jumps', 'over', 'the', 'crazy', 'dog']
 +
>>> distance.levenshtein(sent1, sent2)
 +
3
 +
</pre>
 +
[[User:Tido.com|Tido.com]] ([[User talk:Tido.com|talk]]) 04:07, 1 April 2015 (UTC)
  
:Hi, the original is IMO perfectly fine, I don't see a way how {{ic|exec exec startxfce4}} might be executed.
+
:Hi,
:Your problem seems to be the bash syntax, I'll try to make a short explanation of the script above:
+
:the bot currently does not touch the surrounding text at all, it only modifies the package templates or appends [[Template:Broken package link]] when the package is not found. This is obviously not perfect, this behaviour may lead to some incorrect combinations as you noticed, but blindly fixing the package links and not the surrounding text is still considered to be an improvement. Checking the surrounding text manually would require a lot of manpower, which we don't have, so it is currently not done systematically. Feel free to ask for further details or see the most recent discussion: [[ArchWiki:Requests#Strategy_for_updating_package_templates]].
:The first command {{ic|1=session=${1:-xfce} }} is an assignment through [http://www.tldp.org/LDP/abs/html/parameter-substitution.html parameter substitution], which takes {{ic|$1}} if it is defined (i.e. the first parameter passed to {{ic|xinit}}), but defaults to {{ic|xfce}} (i.e. you run {{ic|xinit}} without any argument).
+
:Regarding automatic updates of the surrounding text, the edit distance gives a clue about whether given edit should be performed or not, but it does not define how an edit should be performed. It can be useful in cases where there are multiple feasible substitutions in text and the strategy to select the optimal substitution is e.g. to minimize the Levenshtein distance. But we don't have any algorithm to generate feasible substitutions yet, so this technique fails. The surrounding text substitution is also very context sensitive and wiki bots must be designed in a way to minimize (ideally avoid completely) the [[wikipedia:Error_of_the_first_kind|error of the first kind]], which in this case is modifying correct text to be incorrect. This makes defining general rules for the text substitution really hard, on the other hand many rules would be necessary to cover even the basic form of standard wording, so in the end both ways may be comparably hard. Anyway, if you have some ideas, I'm all ears :)
:The {{ic|case}} statement chooses the right command, it does not do any assignment.
+
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:51, 1 April 2015 (UTC)
:The most important thing is that {{ic|exec}} does not return to the shell (see {{ic|man 1 exec}}), the script exits with the executed command (with the same exit code). When the value of {{ic|session}} is {{ic|xfce}}, there is no way the line {{ic|*) exec $1;;}} could get executed.
+
:I also hope this makes sense :)
+
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:52, 29 December 2013 (UTC)
+
  
 +
== bot checking links after move  ==
  
::Yes this makes a lot of sense! Thanks for the link; I read it quickly, and you are right, I had the bash syntax completely wrong. Sorry for making an edit to the Wiki with wrong information. Seems my problem was related to something else, but I cannot tell exactly to what right now (I was experimenting with a bunch of WMs/DEs in my {{ic|~/.xinitrc}}, and I probably had some code in there causing havock). Anyway, all is working well now.
+
Hi, re [[Talk:Touchpad Synaptics#adding libinput alternative]]. [[Touchpad Synaptics]] has 100+ backlinks and the more important ones -  a bit tedious task. I was just glancing over your clever github bot scripts. It would be handy to have a script after such moves: walk over the backlinks of [[Touchpad Synaptics]] and just replace "[[Touchpad Synaptics" with "[[Synaptics" from the links. That would leave all links to subsections intact. Leaving out the translations to handle manually, there would not be much to go wrong, or? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 07:36, 26 September 2015 (UTC)
::[[User:Montague|Montague]] ([[User talk:Montague|talk]]) 02:29, 6 January 2014 (UTC)
+
 
 +
:Hi, thanks for the suggestion. It would be indeed handy in this case, but most likely not generally. Imagine that there was a [[UUID]] page, which was later generalized and renamed to [[Persistent block device naming]] and content about UUID is now only a section on the page. In this case using the naive replacement would likely change the meaning of many sentences, and using shorter redirects for convenience is actually encouraged. There would have to be a list of whitelisted "harmless" replacements, which could even help to replace <nowiki>[[pacman|Install]]</nowiki> with <nowiki>[[Install]]</nowiki> etc. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:01, 26 September 2015 (UTC)
 +
 
 +
::Yes, good examples, but you are thinking universal already :) I did not mean it could be that. For example, if you take the time when the bulk of the title case moves were done. With such a script one could avoid a lot of internal redirects as well. E.g. [https://wiki.archlinux.org/index.php/Special:WhatLinksHere/Beginners'_Guide]. But it's ok, just an idea. Please close this, if you think it's too singular cases with a simple enough replacement where it could be applied. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 10:02, 26 September 2015 (UTC)
 +
 
 +
== <s>Parallel ports</s> ==
 +
 
 +
About [https://wiki.archlinux.org/index.php?title=Users_and_groups&diff=next&oldid=437364 this]: How am I supposed to read from or write to my parallel port without being a member of lp? Both {{ic|/dev/lp0}} and {{ic|/dev/parport0}} are owned by root:lp. [[User:Alex Henrie|Alex Henrie]] ([[User talk:Alex Henrie|talk]]) 16:17, 5 June 2016 (UTC)
 +
 
 +
This isn't a theoretical question. Here's what happens when I try:
 +
 
 +
$ ls -l /dev/lp0   
 +
crw-rw---- 1 root lp 6, 0 Jun  5 10:32 /dev/lp0
 +
$ ls -l /dev/parport0
 +
crw-rw-r-- 1 root lp 99, 0 Jun  5 10:32 /dev/parport0
 +
$ echo "Hello world!" > /dev/lp0
 +
bash: /dev/lp0: Permission denied
 +
$ echo "Hello world!" > /dev/parport0
 +
bash: /dev/parport0: Permission denied
 +
 
 +
These commands were run from an LXTerminal. Systemd, D-BUS, and LXDE all started normally. [[User:Alex Henrie|Alex Henrie]] ([[User talk:Alex Henrie|talk]]) 16:35, 5 June 2016 (UTC)
 +
 
 +
:That's the same state as with any USB printer. I admit that I don't have a parallel printer to tinker with, so could you enlighten me how you make use of the printer? If it's [[CUPS]], note that {{ic|cupsd}} runs as root so it will have access to the printer. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:40, 5 June 2016 (UTC)
 +
 
 +
::I'm not using a printer. I'm using a different device connected to a parallel port. [[User:Alex Henrie|Alex Henrie]] ([[User talk:Alex Henrie|talk]]) 19:47, 5 June 2016 (UTC)
 +
 
 +
:::OK, no idea who had the great idea that all parallel ports will get the {{ic|lp}} group belonging to printers... You can override the default with a custom [[udev]] rule, but are {{ic|/dev/lp0}} and {{ic|/dev/parport0}} really the same device? From the output above it does not seem to be a symlink so they should be different devices.
 +
:::For starters, I think that something like this should work:
 +
{{hc|/etc/udev/rules.d/99-parport.rules|2=
 +
ACTION=="add", KERNEL=="parport[0-9]*", GROUP="''group_name''"
 +
}}
 +
:::Pick some {{ic|''group_name''}} better than {{ic|lp}}.
 +
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:19, 5 June 2016 (UTC)
 +
 
 +
::::A physical parallel port can expose multiple virtual parallel ports. {{ic|/dev/lp0}} is the physical parallel port, and {{ic|/dev/parport0}} is the virtual parallel port. Please read the first two sections of "The Linux 2.4 Parallel Port Subsystem" by Tim Waugh: [https://people.redhat.com/twaugh/parport/html/design.html#AEN19] [https://people.redhat.com/twaugh/parport/html/x36.html]
 +
::::As long as systemd assigns all parallel ports to {{ic|lp}} by default, regardless of the type of device connected to it, I don't think we can call this group deprecated. [[User:Alex Henrie|Alex Henrie]] ([[User talk:Alex Henrie|talk]]) 20:52, 5 June 2016 (UTC)
 +
 
 +
:::::I've been wondering about those groups as well before. Reading up on it now, I think the [[Users and groups#Pre-systemd groups]] list is misleading. References: 1. For CUPS [http://www.linuxfromscratch.org/blfs/view/cvs/pst/cups.html #Installation of Cups] section names {{ic|lp}} explicitly and that conforms with [[CUPS/Troubleshooting#Explanation of the GID issue]]. 2. [https://lists.archlinux.org/pipermail/arch-general/2012-October/031808.html tomgun] explains an example for {{ic|scanner}} group, 3. and [https://bbs.archlinux.org/viewtopic.php?pid=1183467#p1183467 Mr. Elendig] sums up my current conclusion perfectly: The groups are not deprecated (maybe some but not {{ic|lp}}) - what is deprecated is to add the user to them, because that part is handled by systemd/udev.
 +
:::::Can that be the case?
 +
:::::--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 21:39, 5 June 2016 (UTC)
 +
 
 +
::::::So there is an additional translation layer between {{ic|/dev/lp0}} and {{ic|/dev/parport0}}. But as per [https://people.redhat.com/twaugh/parport/html/lp.html], the "{{ic|lp}} is a {{ic|parport}} client". Since you're not operating a printer, I assume you're not interested in using the [https://people.redhat.com/twaugh/parport/html/ppdev.html "printer protocol"] via {{ic|/dev/lp0}}. Then since {{ic|/dev/lp0}} and {{ic|/dev/parport0}} are two different files, there is no reason they should have the same GID. Using the {{ic|lp}} group for all {{ic|parport[0-9]*}} devices, which are (almost?) never used to access printers, really is confusing. Maybe not so much until CUPS was invented, but since they chose to abuse the {{ic|lp}} group as the default group for their control files, users operating any parport device will automatically get access to CUPS. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:24, 6 June 2016 (UTC)
 +
 
 +
:::::::Any conclusions on this? Listing the pre-systemd groups as being deprecated seems an odd distinction to make, since they are still used.
 +
:::::::Some of the groups also seem to be in the wrong places; for example, shouldn't {{ic|kvm}} count as a pre-systemd group? To administer printers in CUPS you still need to be in the {{ic|sys}} group, AFAIK, so why is it in the pre-systemd groups category?
 +
:::::::Perhaps it would be sensible to merge the tables into three - ''User'', ''System'', and ''Deprecated''.''User'' would contain groups which you might sensibly add a user to, eg {{ic|rfkill}}; ''System'' would contain groups used "internally" which you would never add a user to (eg {{ic|dbus}}), and ''Deprecated'' would list deprecated groups. Although I don't really think that any of the currently listed groups count as deprecated anyway, with the possible exception of {{ic|stb-admin}}.
 +
::::::: It might also be worthwhile linking to [[Udev]] from near the ''User'' table, as for some cases it would might be better to create a custom group instead.
 +
::::::: Thoughts? -- [[User:Pypi|Pypi]] ([[User talk:Pypi|talk]]) 02:52, 7 July 2016 (UTC)
 +
 
 +
:::::::: How about simply removing groups that are unused in Arch from the article? In most other articles we also remove old options, rather than list them as "deprecated". -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:04, 7 July 2016 (UTC)
 +
 
 +
::::::::: Yes, +1 to removing unused and Pypi's approach. But before we need to get clear which are deprecated/unused. I have added templates for above with my 2ct: [https://wiki.archlinux.org/index.php?title=Users_and_groups&type=revision&diff=440309&oldid=438673]. If noone objects (or is faster:), I'll implement it soon. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 17:21, 7 July 2016 (UTC)
 +
 
 +
::::::::::If we remove the deprecated groups, the first user wondering what all the groups in [https://git.archlinux.org/svntogit/packages.git/tree/trunk/group?h=packages/filesystem core/filesystem] mean would add them back. I'm fine with removing the groups currently in [[Users_and_groups#Software_groups]], but the section should stay as a bridge to [[DeveloperWiki:UID / GID Database]], which lists all (?) groups used in official packages.
 +
::::::::::I've done some [https://wiki.archlinux.org/index.php?title=Users_and_groups&type=revision&diff=440330&oldid=440309 cleanup], mainly to the pre-systemd groups section. What do you say about the exception clause?
 +
::::::::::About moving the pre-systemd groups under "System groups", it doesn't fit with the other groups. If the user is not a member of e.g. audio, the audio group is not used at all, hence "Deprecated or unused groups" is fitting. If the user is member of audio, it fits with the current "User groups" section. Since the "pre-systemd groups" are useful only in a few corner cases, I think that we can leave it under "Deprecated or unused groups" with the exception disclaimer.
 +
::::::::::Now, back to the printers! The problem with the lp group is that it mixes access to devices and all CUPS files, which AFAIK might contain some sensitive information. CUPS does not need the lp group to access the printers since cupsd runs as root anyway and the choice of lp for files is an [https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/cups#n73 Arch thing]. Similarly to [[DeveloperWiki:Security#Service_Isolation]], I think that a separate group specific for CUPS would be much better. As for the sys group, it sounds like just another administration group (there is already adm and wheel). Anybody knows what else is it used for? Any chance of changing the default for the Arch package?
 +
::::::::::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:52, 7 July 2016 (UTC)
 +
 
 +
:::::::::::CUPS uses the lp (lineprinter) group to limit access to the root cupsd in the first place. Same applies for sys/lpadmin to segregate more common printer-configuration rights from other adm tasks (multi-user environment). I'm not saying it is not messy that the system mixes parallel port device access into lp, but that's the legacy of the hen and egg question. Surely we can't call these two "deprecated/unused" at the moment.
 +
:::::::::::To my ears "deprecated" is still misleading as a term for the rest of the pre-systemd bunch - it reads as if those groups could be prunned any time. But ok, I get your reasoning and the exception clause makes it clearer than before. In any case the bunch needs to stay in the article, yes. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 01:12, 8 July 2016 (UTC)
 +
 
 +
::::::::::::Right, removing the pre-systemd groups section would be bad - I just meant the table containing {{ic|stb-admin}}/{{ic|log}}/{{ic|kvm}}. For removing the groups listed in [[Users_and_groups#Software_groups]], what needs to be done for the groups introduced in AUR packages?
 +
::::::::::::What was the thinking behind moving ftp and http ([https://wiki.archlinux.org/index.php?title=Users_and_groups&diff=next&oldid=440329])? Also, why [https://wiki.archlinux.org/index.php?title=Users_and_groups&diff=440318&oldid=440317] - none of those groups are deprecated as far as I am aware?
 +
::::::::::::I agree with Indigo here; keeping the pre-systemd groups under "Deprecated or unused groups" makes it sound like they will disappear, which is not true. The choice of the {{ic|lp}} group appears to be fairly arbitrary, but [https://anonscm.debian.org/cgit/printing/cups.git/tree/debian/rules#n55 Debian] uses {{ic|lp}}, so presumably it is fairly standard; perhaps something to ask the maintainer of the arch package about? I think that {{ic|sys}} should be in the ''User'' table, as it is similar to {{ic|adm}} and {{ic|wheel}}.
 +
::::::::::::Otherwise, looking better :D
 +
::::::::::::-- [[User:Pypi|Pypi]] ([[User talk:Pypi|talk]]) 06:43, 8 July 2016 (UTC)
 +
 
 +
:::::::::::::What about [https://wiki.archlinux.org/index.php?title=Users_and_groups&type=revision&diff=440380&oldid=440333 now]?
 +
:::::::::::::With the ftp/http groups I was thinking about something like [http://www.linuxquestions.org/questions/linux-general-1/make-new-files-in-a-directory-use-pre-defined-permissions-4175484817/#post5065910]. I left lp in "Unused" for now since it's not needed for its main purpose (accessing the printers) - at least I think so, because the {{ic|User}} and {{ic|Group}} directives are commented by default in {{ic|cups-files.conf}}. Am I guessing it right that [[CUPS/Troubleshooting#Printer_.22Paused.22_or_.22Stopped.22_with_Status_.22Rendering_completed.22|this entire section]] is outdated and the lp group is by default not used by CUPS at all? You can start educating me by describing it on the CUPS pages ;)
 +
:::::::::::::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:27, 8 July 2016 (UTC)
 +
 
 +
::::::::::::::I've moved {{ic|lp}} into Software groups for now; it is still used. Although the entries are commented, they are used (try printing something and check the user/group of the process printing). I don't think the {{ic|User}} and {{ic|Group}} directives should be documented in [[CUPS]], as cups-files.conf(5) explains it fairly well, and nobody should need to change them! I've tried to clarify the [[CUPS/Troubleshooting#Permission_issue]]; it's out of date now, so should it perhaps could be completely removed? -- [[User:Pypi|Pypi]] ([[User talk:Pypi|talk]]) 05:18, 9 July 2016 (UTC)
 +
 
 +
:::::::::::::::OK, thanks. Now I'm thinking that perhaps the {{ic|--with-cups-group}} configuration option sets not only the group of CUPS files, but also the default {{ic|Group}} in {{ic|cups-files.conf}}. If the helpers need to access both the printer and CUPS files, there is no way to change the group. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:42, 9 July 2016 (UTC)
 +
 
 +
::::::::::::::::I've opened {{Bug|50009}} for lp. I have seen AndyRTR answer cups udev related questions on the BBS. Changing the default group, if possible, would break an aweful lot of configs; so I'd doubt that will happen quick. But if he has a definite answer, we could at least make safe suggestions in the wiki either way. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 14:11, 10 July 2016 (UTC)
 +
::::::::::::::::Pypi, I disagree with your last move and other above points. In addition: If no other methods come up in the FS#, I think [[CUPS#Connection_Interfaces]] could be used to quickly note the user/group clash with other parallel port devices. It is cups which is grabbing an already existing /dev/parport group, not the other way around.  --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 22:42, 20 July 2016 (UTC)
 +
 
 +
:::::::::::::::::I've [https://wiki.archlinux.org/index.php?title=CUPS&diff=443834&oldid=440644 added a warning] to [[CUPS]]. Any edits to that would be appreciated! I'm not entirely sure exactly what the "sensitive information" in the files owned by lp are; at least {{ic|/var/log/cups/error_log}} seems to include printer URI's which might contain passwords (hmmm; if that is the case, why is{{ic|/etc/cups/printers.conf}} only readable by root, while {{ic|/var/log/cups/error_log}} is readable by lp?), and {{ic|/etc/cups/snmp.conf}} contains a "default password" setting which might (?) be sensitive. The bug report seems to state that ''cups printing queue management'' as something {{ic|lp}} allows; AFAIK, it does not allow changes to {{ic|/etc/cups/printers.conf}}, or modifying print jobs, so it might be worthwhile clarifying that. It appears to only be for things like allowing the snmp backend to read {{ic|snmp.conf}} (and of course accessing printer devices - both usb and parallel). I am unsure why {{ic|/var/log/cups/*}} is readable (but not writeable) by {{ic|lp}} - that doesn't make much sense.
 +
:::::::::::::::::Feel free to revert the move you mentioned if you think that it is wrong. I'm perhaps still unclear as to the meaning of the headers in [[Users_and_groups#Group_list]]; could you please clarify what you think they mean?
 +
::::::::::::::::: -- [[User:Pypi|Pypi]] ([[User talk:Pypi|talk]]) 01:27, 31 July 2016 (UTC)
 +
 
 +
:::::::::::::::::: Great, thanks. I've added my bits to the warning.[https://wiki.archlinux.org/index.php?title=CUPS&type=revision&diff=444323&oldid=443834] In the course of this I tried to assign another group than lp in cups-files.conf, and that did not work (for me). That's the reason I removed the man page reference for cups-files.conf. Please adjust (again:), if I am wrong and cups's group lp is indeed configurable. Maybe it would be helpful, to have your above infos about cups config files access somewhere in [[CUPS]]. Maybe even the note could be moved to a less prominent subsection and enriched with your info. After that then only referenced with a crosslink down, because (I believe) there will not be many non-printer parport devices with multi-user setups. Hence, it may distract the majority of regular cups users as is. Just an idea.
 +
:::::::::::::::::: I also moved the related lp group with [https://wiki.archlinux.org/index.php?title=Users_and_groups&type=revision&diff=444326&oldid=443198] (thanks Lahwaacz re daemon).
 +
:::::::::::::::::: For the {{ic|lp}} group the case is now clear (for me) after we got the link to systemd udev creating it, irrespective of any installed [[CUPS]]. So to me we can close this as per original subject and update accordingly if the FS# gets other info. You are right that the [[Users and groups]] descriptions need updating too, though perhaps we may not want to include that all in this item, but over at [[Talk:Users and groups]] on topic. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 18:57, 2 August 2016 (UTC)
 +
 
 +
:::::::::::::::::::I've started a new topic [[Talk:Users_and_groups#Description_updates_or_clarification]]. Thanks Indigo for your input! -- [[User:Pypi|Pypi]] ([[User talk:Pypi|talk]]) 07:43, 3 August 2016 (UTC)
 +
 
 +
::::::::::::::::::::Alright, let's close this finally. Thank you guys for taking care of the remaining parts. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:08, 3 August 2016 (UTC)

Latest revision as of 08:11, 3 August 2016

PodCastXDL

About [1] (and [2]) User:Levi0x0x, who should have indeed provided an edit summary, appears to be the developer of the application and the maintainer of the PKGBUILD. I would keep his edit. -- Kynikos (talk) 00:45, 5 July 2014 (UTC)

I know - I've seen also bash-player removed, both from wiki and Github (it seems the repo has been recreated from scratch). PodCastXDL has always been available upstream. -- Lahwaacz (talk) 08:20, 5 July 2014 (UTC)
Didn't he add it to the list one week ago? [3] Maybe he's found some bug and doesn't want people to use it until he fixes it? Anyway I'm not that interested, we can as well see if/how Levi0x0x reacts. -- Kynikos (talk) 04:32, 6 July 2014 (UTC)

bot AUR to Official Repository edit

A recent bot edit (update Pkg/AUR templates) by User:Lahwaacz.bot on the Gitolite page correctly changed the AUR template to Pkg but left the Arch User Repository link

I fixed this, but would it be possible to modify the bot to take this into consideration?

I can imagine that blanket changing AUR links to Official Repository links in any given page could be dangerous - but for common phrasing or possibly word distance it would seem to be relatively safe

Or is there some sort of post-run manual inspection that I am unaware of that handles this situation?

Specifically this edit

From:

{{AUR|gitolite}} is available in the [[Arch User Repository]]

To:

{{Pkg|gitolite}} is available in the [[Arch User Repository]]


Tido.com (talk) 01:50, 1 April 2015 (UTC)

By "word distance" above what I _meant_ was Edit Distance ;)

I was initially thinking of Hamming distance - but apparently that is for strings of equal length.

What looks more promising is the Levenshtein distance - specifically "Comparing a list of strings" from the Python Distance package.

Example shamelessly ripped from that page:

(mainly because I couldn't link directly to the relevant section)

>>> sent1 = ['the', 'quick', 'brown', 'fox', 'jumps', 'over', 'the', 'lazy', 'dog']
>>> sent2 = ['the', 'lazy', 'fox', 'jumps', 'over', 'the', 'crazy', 'dog']
>>> distance.levenshtein(sent1, sent2)
3

Tido.com (talk) 04:07, 1 April 2015 (UTC)

Hi,
the bot currently does not touch the surrounding text at all, it only modifies the package templates or appends Template:Broken package link when the package is not found. This is obviously not perfect, this behaviour may lead to some incorrect combinations as you noticed, but blindly fixing the package links and not the surrounding text is still considered to be an improvement. Checking the surrounding text manually would require a lot of manpower, which we don't have, so it is currently not done systematically. Feel free to ask for further details or see the most recent discussion: ArchWiki:Requests#Strategy_for_updating_package_templates.
Regarding automatic updates of the surrounding text, the edit distance gives a clue about whether given edit should be performed or not, but it does not define how an edit should be performed. It can be useful in cases where there are multiple feasible substitutions in text and the strategy to select the optimal substitution is e.g. to minimize the Levenshtein distance. But we don't have any algorithm to generate feasible substitutions yet, so this technique fails. The surrounding text substitution is also very context sensitive and wiki bots must be designed in a way to minimize (ideally avoid completely) the error of the first kind, which in this case is modifying correct text to be incorrect. This makes defining general rules for the text substitution really hard, on the other hand many rules would be necessary to cover even the basic form of standard wording, so in the end both ways may be comparably hard. Anyway, if you have some ideas, I'm all ears :)
-- Lahwaacz (talk) 17:51, 1 April 2015 (UTC)

bot checking links after move

Hi, re Talk:Touchpad Synaptics#adding libinput alternative. Touchpad Synaptics has 100+ backlinks and the more important ones - a bit tedious task. I was just glancing over your clever github bot scripts. It would be handy to have a script after such moves: walk over the backlinks of Touchpad Synaptics and just replace "[[Touchpad Synaptics" with "[[Synaptics" from the links. That would leave all links to subsections intact. Leaving out the translations to handle manually, there would not be much to go wrong, or? --Indigo (talk) 07:36, 26 September 2015 (UTC)

Hi, thanks for the suggestion. It would be indeed handy in this case, but most likely not generally. Imagine that there was a UUID page, which was later generalized and renamed to Persistent block device naming and content about UUID is now only a section on the page. In this case using the naive replacement would likely change the meaning of many sentences, and using shorter redirects for convenience is actually encouraged. There would have to be a list of whitelisted "harmless" replacements, which could even help to replace [[pacman|Install]] with [[Install]] etc. -- Lahwaacz (talk) 08:01, 26 September 2015 (UTC)
Yes, good examples, but you are thinking universal already :) I did not mean it could be that. For example, if you take the time when the bulk of the title case moves were done. With such a script one could avoid a lot of internal redirects as well. E.g. [4]. But it's ok, just an idea. Please close this, if you think it's too singular cases with a simple enough replacement where it could be applied. --Indigo (talk) 10:02, 26 September 2015 (UTC)

Parallel ports

About this: How am I supposed to read from or write to my parallel port without being a member of lp? Both /dev/lp0 and /dev/parport0 are owned by root:lp. Alex Henrie (talk) 16:17, 5 June 2016 (UTC)

This isn't a theoretical question. Here's what happens when I try:

$ ls -l /dev/lp0     
crw-rw---- 1 root lp 6, 0 Jun  5 10:32 /dev/lp0
$ ls -l /dev/parport0
crw-rw-r-- 1 root lp 99, 0 Jun  5 10:32 /dev/parport0
$ echo "Hello world!" > /dev/lp0
bash: /dev/lp0: Permission denied
$ echo "Hello world!" > /dev/parport0
bash: /dev/parport0: Permission denied

These commands were run from an LXTerminal. Systemd, D-BUS, and LXDE all started normally. Alex Henrie (talk) 16:35, 5 June 2016 (UTC)

That's the same state as with any USB printer. I admit that I don't have a parallel printer to tinker with, so could you enlighten me how you make use of the printer? If it's CUPS, note that cupsd runs as root so it will have access to the printer. -- Lahwaacz (talk) 19:40, 5 June 2016 (UTC)
I'm not using a printer. I'm using a different device connected to a parallel port. Alex Henrie (talk) 19:47, 5 June 2016 (UTC)
OK, no idea who had the great idea that all parallel ports will get the lp group belonging to printers... You can override the default with a custom udev rule, but are /dev/lp0 and /dev/parport0 really the same device? From the output above it does not seem to be a symlink so they should be different devices.
For starters, I think that something like this should work:
/etc/udev/rules.d/99-parport.rules
ACTION=="add", KERNEL=="parport[0-9]*", GROUP="group_name"
Pick some group_name better than lp.
-- Lahwaacz (talk) 20:19, 5 June 2016 (UTC)
A physical parallel port can expose multiple virtual parallel ports. /dev/lp0 is the physical parallel port, and /dev/parport0 is the virtual parallel port. Please read the first two sections of "The Linux 2.4 Parallel Port Subsystem" by Tim Waugh: [5] [6]
As long as systemd assigns all parallel ports to lp by default, regardless of the type of device connected to it, I don't think we can call this group deprecated. Alex Henrie (talk) 20:52, 5 June 2016 (UTC)
I've been wondering about those groups as well before. Reading up on it now, I think the Users and groups#Pre-systemd groups list is misleading. References: 1. For CUPS #Installation of Cups section names lp explicitly and that conforms with CUPS/Troubleshooting#Explanation of the GID issue. 2. tomgun explains an example for scanner group, 3. and Mr. Elendig sums up my current conclusion perfectly: The groups are not deprecated (maybe some but not lp) - what is deprecated is to add the user to them, because that part is handled by systemd/udev.
Can that be the case?
--Indigo (talk) 21:39, 5 June 2016 (UTC)
So there is an additional translation layer between /dev/lp0 and /dev/parport0. But as per [7], the "lp is a parport client". Since you're not operating a printer, I assume you're not interested in using the "printer protocol" via /dev/lp0. Then since /dev/lp0 and /dev/parport0 are two different files, there is no reason they should have the same GID. Using the lp group for all parport[0-9]* devices, which are (almost?) never used to access printers, really is confusing. Maybe not so much until CUPS was invented, but since they chose to abuse the lp group as the default group for their control files, users operating any parport device will automatically get access to CUPS. -- Lahwaacz (talk) 07:24, 6 June 2016 (UTC)
Any conclusions on this? Listing the pre-systemd groups as being deprecated seems an odd distinction to make, since they are still used.
Some of the groups also seem to be in the wrong places; for example, shouldn't kvm count as a pre-systemd group? To administer printers in CUPS you still need to be in the sys group, AFAIK, so why is it in the pre-systemd groups category?
Perhaps it would be sensible to merge the tables into three - User, System, and Deprecated.User would contain groups which you might sensibly add a user to, eg rfkill; System would contain groups used "internally" which you would never add a user to (eg dbus), and Deprecated would list deprecated groups. Although I don't really think that any of the currently listed groups count as deprecated anyway, with the possible exception of stb-admin.
It might also be worthwhile linking to Udev from near the User table, as for some cases it would might be better to create a custom group instead.
Thoughts? -- Pypi (talk) 02:52, 7 July 2016 (UTC)
How about simply removing groups that are unused in Arch from the article? In most other articles we also remove old options, rather than list them as "deprecated". -- Alad (talk) 12:04, 7 July 2016 (UTC)
Yes, +1 to removing unused and Pypi's approach. But before we need to get clear which are deprecated/unused. I have added templates for above with my 2ct: [8]. If noone objects (or is faster:), I'll implement it soon. --Indigo (talk) 17:21, 7 July 2016 (UTC)
If we remove the deprecated groups, the first user wondering what all the groups in core/filesystem mean would add them back. I'm fine with removing the groups currently in Users_and_groups#Software_groups, but the section should stay as a bridge to DeveloperWiki:UID / GID Database, which lists all (?) groups used in official packages.
I've done some cleanup, mainly to the pre-systemd groups section. What do you say about the exception clause?
About moving the pre-systemd groups under "System groups", it doesn't fit with the other groups. If the user is not a member of e.g. audio, the audio group is not used at all, hence "Deprecated or unused groups" is fitting. If the user is member of audio, it fits with the current "User groups" section. Since the "pre-systemd groups" are useful only in a few corner cases, I think that we can leave it under "Deprecated or unused groups" with the exception disclaimer.
Now, back to the printers! The problem with the lp group is that it mixes access to devices and all CUPS files, which AFAIK might contain some sensitive information. CUPS does not need the lp group to access the printers since cupsd runs as root anyway and the choice of lp for files is an Arch thing. Similarly to DeveloperWiki:Security#Service_Isolation, I think that a separate group specific for CUPS would be much better. As for the sys group, it sounds like just another administration group (there is already adm and wheel). Anybody knows what else is it used for? Any chance of changing the default for the Arch package?
-- Lahwaacz (talk) 20:52, 7 July 2016 (UTC)
CUPS uses the lp (lineprinter) group to limit access to the root cupsd in the first place. Same applies for sys/lpadmin to segregate more common printer-configuration rights from other adm tasks (multi-user environment). I'm not saying it is not messy that the system mixes parallel port device access into lp, but that's the legacy of the hen and egg question. Surely we can't call these two "deprecated/unused" at the moment.
To my ears "deprecated" is still misleading as a term for the rest of the pre-systemd bunch - it reads as if those groups could be prunned any time. But ok, I get your reasoning and the exception clause makes it clearer than before. In any case the bunch needs to stay in the article, yes. --Indigo (talk) 01:12, 8 July 2016 (UTC)
Right, removing the pre-systemd groups section would be bad - I just meant the table containing stb-admin/log/kvm. For removing the groups listed in Users_and_groups#Software_groups, what needs to be done for the groups introduced in AUR packages?
What was the thinking behind moving ftp and http ([9])? Also, why [10] - none of those groups are deprecated as far as I am aware?
I agree with Indigo here; keeping the pre-systemd groups under "Deprecated or unused groups" makes it sound like they will disappear, which is not true. The choice of the lp group appears to be fairly arbitrary, but Debian uses lp, so presumably it is fairly standard; perhaps something to ask the maintainer of the arch package about? I think that sys should be in the User table, as it is similar to adm and wheel.
Otherwise, looking better :D
-- Pypi (talk) 06:43, 8 July 2016 (UTC)
What about now?
With the ftp/http groups I was thinking about something like [11]. I left lp in "Unused" for now since it's not needed for its main purpose (accessing the printers) - at least I think so, because the User and Group directives are commented by default in cups-files.conf. Am I guessing it right that this entire section is outdated and the lp group is by default not used by CUPS at all? You can start educating me by describing it on the CUPS pages ;)
-- Lahwaacz (talk) 21:27, 8 July 2016 (UTC)
I've moved lp into Software groups for now; it is still used. Although the entries are commented, they are used (try printing something and check the user/group of the process printing). I don't think the User and Group directives should be documented in CUPS, as cups-files.conf(5) explains it fairly well, and nobody should need to change them! I've tried to clarify the CUPS/Troubleshooting#Permission_issue; it's out of date now, so should it perhaps could be completely removed? -- Pypi (talk) 05:18, 9 July 2016 (UTC)
OK, thanks. Now I'm thinking that perhaps the --with-cups-group configuration option sets not only the group of CUPS files, but also the default Group in cups-files.conf. If the helpers need to access both the printer and CUPS files, there is no way to change the group. -- Lahwaacz (talk) 16:42, 9 July 2016 (UTC)
I've opened FS#50009 for lp. I have seen AndyRTR answer cups udev related questions on the BBS. Changing the default group, if possible, would break an aweful lot of configs; so I'd doubt that will happen quick. But if he has a definite answer, we could at least make safe suggestions in the wiki either way. --Indigo (talk) 14:11, 10 July 2016 (UTC)
Pypi, I disagree with your last move and other above points. In addition: If no other methods come up in the FS#, I think CUPS#Connection_Interfaces could be used to quickly note the user/group clash with other parallel port devices. It is cups which is grabbing an already existing /dev/parport group, not the other way around. --Indigo (talk) 22:42, 20 July 2016 (UTC)
I've added a warning to CUPS. Any edits to that would be appreciated! I'm not entirely sure exactly what the "sensitive information" in the files owned by lp are; at least /var/log/cups/error_log seems to include printer URI's which might contain passwords (hmmm; if that is the case, why is/etc/cups/printers.conf only readable by root, while /var/log/cups/error_log is readable by lp?), and /etc/cups/snmp.conf contains a "default password" setting which might (?) be sensitive. The bug report seems to state that cups printing queue management as something lp allows; AFAIK, it does not allow changes to /etc/cups/printers.conf, or modifying print jobs, so it might be worthwhile clarifying that. It appears to only be for things like allowing the snmp backend to read snmp.conf (and of course accessing printer devices - both usb and parallel). I am unsure why /var/log/cups/* is readable (but not writeable) by lp - that doesn't make much sense.
Feel free to revert the move you mentioned if you think that it is wrong. I'm perhaps still unclear as to the meaning of the headers in Users_and_groups#Group_list; could you please clarify what you think they mean?
-- Pypi (talk) 01:27, 31 July 2016 (UTC)
Great, thanks. I've added my bits to the warning.[12] In the course of this I tried to assign another group than lp in cups-files.conf, and that did not work (for me). That's the reason I removed the man page reference for cups-files.conf. Please adjust (again:), if I am wrong and cups's group lp is indeed configurable. Maybe it would be helpful, to have your above infos about cups config files access somewhere in CUPS. Maybe even the note could be moved to a less prominent subsection and enriched with your info. After that then only referenced with a crosslink down, because (I believe) there will not be many non-printer parport devices with multi-user setups. Hence, it may distract the majority of regular cups users as is. Just an idea.
I also moved the related lp group with [13] (thanks Lahwaacz re daemon).
For the lp group the case is now clear (for me) after we got the link to systemd udev creating it, irrespective of any installed CUPS. So to me we can close this as per original subject and update accordingly if the FS# gets other info. You are right that the Users and groups descriptions need updating too, though perhaps we may not want to include that all in this item, but over at Talk:Users and groups on topic. --Indigo (talk) 18:57, 2 August 2016 (UTC)
I've started a new topic Talk:Users_and_groups#Description_updates_or_clarification. Thanks Indigo for your input! -- Pypi (talk) 07:43, 3 August 2016 (UTC)
Alright, let's close this finally. Thank you guys for taking care of the remaining parts. -- Lahwaacz (talk) 08:08, 3 August 2016 (UTC)