Difference between revisions of "User talk:Lahwaacz"

From ArchWiki
Jump to: navigation, search
(Double redirects: fixed, closing)
(Parallel ports: re)
 
(241 intermediate revisions by 35 users not shown)
Line 1: Line 1:
== <s>Double redirects</s> ==
+
== <s>Regex for replacing = codes</s> ==
Please have a look at [[Special:DoubleRedirects|this page]]. Some of your recent edits created double redirects. -- [[User:Karol|Karol]] ([[User talk:Karol|talk]]) 21:25, 2 June 2013 (UTC)
+
 
:Thanks for the note, I didn't notice. Will be more careful next time. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:38, 2 June 2013 (UTC)
+
Hi, regarding [[User:Lahwaacz#User:Lahwaacz#Regex_for_replacing_.3D_codes]] do you intend to use a similar expression with the editor assistant or directly with the bot? In the latter case I think it would be pretty dangerous, for example it would break templates that already use a named parameter, e.g. {{ic|<nowiki>{{Template|parameter=value}}</nowiki>}} would be turned into {{ic|<nowiki>{{Template|1=parameter=value}}</nowiki>}}. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:57, 21 March 2014 (UTC)
::No problem :-) -- [[User:Karol|Karol]] ([[User talk:Karol|talk]]) 21:49, 2 June 2013 (UTC)
+
 
 +
:I used it [https://wiki.archlinux.org/index.php?title=Systemd-networkd&diff=prev&oldid=306182 only once] and don't have any specific plans, but I'm quite certain I will need to use it again sometimes... Thanks for the warning, I will be cautious. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:50, 21 March 2014 (UTC)
 +
 
 +
== PodCastXDL ==
 +
 
 +
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)
 +
 
 +
: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)
 +
 
 +
::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)
 +
 
 +
== bot AUR to Official Repository edit ==
 +
 
 +
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
 +
 
 +
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 [https://wiki.archlinux.org/index.php?title=Gitolite&diff=next&oldid=366859 edit]
 +
 
 +
From:
 +
<pre>
 +
{{AUR|gitolite}} is available in the [[Arch User Repository]]
 +
</pre>
 +
 
 +
To:
 +
<pre>
 +
{{Pkg|gitolite}} is available in the [[Arch User Repository]]
 +
</pre>
 +
 
 +
 
 +
 
 +
[[User:Tido.com|Tido.com]] ([[User talk:Tido.com|talk]]) 01:50, 1 April 2015 (UTC)
 +
 
 +
By "word distance" above what I _meant_ was [[Wikipedia:Edit Distance|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 [https://pypi.python.org/pypi/Distance/0.1.3 Distance] package.
 +
 
 +
Example shamelessly ripped from that page:
 +
 
 +
(mainly because I couldn't link directly to the relevant section)
 +
 
 +
<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 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 [[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 :)
 +
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk: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? --[[User:Indigo|Indigo]] ([[User talk: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 <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>AMDGPU license edit</s> ==
 +
 
 +
Hi Lahwaacz,
 +
 
 +
Regarding [https://wiki.archlinux.org/index.php?title=AMDGPU&diff=436532&oldid=435838 this edit]: why should be mentioned explicitly?
 +
There is almost no mention of licenses in the wiki at all, so I'm curious why you would like to have it mentioned in this specific case.
 +
 
 +
If I recall correctly, there is nothing about this in the style guide or similar (which is a good thing IMO).
 +
I would think it this is something that should be mentioned in the PKGBUILD ([[Arch packaging standards#Licenses]]).
 +
 
 +
Thanks! [[User:Lonaowna|Lonaowna]] ([[User talk:Lonaowna|talk]]) 19:21, 30 May 2016 (UTC)
 +
 
 +
:Well, the thing is that the license is not mentioned in the PKGBUILD either. As far as I know, the AMDGPU-PRO driver is proprietary, so at least the word "proprietary" should be mentioned, because describing it along with the open-source AMDGPU driver on the same page is not very clear. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:41, 30 May 2016 (UTC)
 +
 
 +
::Ah sorry, I didn't notice you had already notified the package maintainer.
 +
::I guess he should include [http://support.amd.com/en-us/download/eula this EULA] which is linked at the download page. In the meantime, it remains a case of "documenting AUR package bugs", which is always a bit questionable.
 +
::And I have [https://wiki.archlinux.org/index.php?title=AMDGPU&diff=436762&oldid=436532 added] the word "proprietary" since you are right that that should be mentioned. ;)
 +
::--[[User:Lonaowna|Lonaowna]] ([[User talk:Lonaowna|talk]]) 20:18, 30 May 2016 (UTC)
 +
 
 +
:::Thanks [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:25, 30 May 2016 (UTC)
 +
 
 +
== Parallel ports ==
 +
 
 +
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)

Latest revision as of 22:44, 20 July 2016

Regex for replacing = codes

Hi, regarding User:Lahwaacz#User:Lahwaacz#Regex_for_replacing_.3D_codes do you intend to use a similar expression with the editor assistant or directly with the bot? In the latter case I think it would be pretty dangerous, for example it would break templates that already use a named parameter, e.g. {{Template|parameter=value}} would be turned into {{Template|1=parameter=value}}. -- Kynikos (talk) 16:57, 21 March 2014 (UTC)

I used it only once and don't have any specific plans, but I'm quite certain I will need to use it again sometimes... Thanks for the warning, I will be cautious. -- Lahwaacz (talk) 17:50, 21 March 2014 (UTC)

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)

AMDGPU license edit

Hi Lahwaacz,

Regarding this edit: why should be mentioned explicitly? There is almost no mention of licenses in the wiki at all, so I'm curious why you would like to have it mentioned in this specific case.

If I recall correctly, there is nothing about this in the style guide or similar (which is a good thing IMO). I would think it this is something that should be mentioned in the PKGBUILD (Arch packaging standards#Licenses).

Thanks! Lonaowna (talk) 19:21, 30 May 2016 (UTC)

Well, the thing is that the license is not mentioned in the PKGBUILD either. As far as I know, the AMDGPU-PRO driver is proprietary, so at least the word "proprietary" should be mentioned, because describing it along with the open-source AMDGPU driver on the same page is not very clear. -- Lahwaacz (talk) 19:41, 30 May 2016 (UTC)
Ah sorry, I didn't notice you had already notified the package maintainer.
I guess he should include this EULA which is linked at the download page. In the meantime, it remains a case of "documenting AUR package bugs", which is always a bit questionable.
And I have added the word "proprietary" since you are right that that should be mentioned. ;)
--Lonaowna (talk) 20:18, 30 May 2016 (UTC)
Thanks Lahwaacz (talk) 20:25, 30 May 2016 (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)