User talk:Lahwaacz

From ArchWiki
Jump to: navigation, search


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 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


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


{{Pkg|gitolite}} is available in the [[Arch User Repository]] (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 (talk) 04:07, 1 April 2015 (UTC)

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:
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)