In the standard installation of Fedora, I don't see any issues. If you have file /var/lib/yum/plugins/langpacks/installed_langpacks then just do "dnf langlist" and you can see this command showing contents from that file. If file does not exist then "No Langpacks installed" message.

Running `dnf langlist` is broken if running as non-root user:

$ dnf langlist
Adding [language code] to language list
Unable to create file : /var/lib/yum/plugins/langpacks/installed_langpacks
Error reading file : /var/lib/yum/plugins/langpacks/installed_langpacks as it does not exist
Unable to create file : /var/lib/yum/plugins/langpacks/installed_langpacks
Error reading file : /var/lib/yum/plugins/langpacks/installed_langpacks as it does not exist
No langpacks installed

But the "No Langpacks installed" output is wrong, I have langpacks installed. When running as root it correctly tells me the languages I have installed.
File creation fails because /var/lib/yum/plugins is owned by root:root and has permissions drwx------ (700). It should have something like drwxr-xr-x (755) instead. Same is true for its subfolders.

Oh, I should add that this only happens if umask is non-standard if you run `dnf langinstall` or dnf with plugin langpacks for the first time. Once it is created with correct permissions it will work fine.

In the standard installation of Fedora Workstation, I do not see this problem.

Also, I got another bug where I have been asked to move some print messages to debug log messages so in next update dnf-langpacks-0.12.0 you will not see that error message.

If you have langpacks installed show me the contents of /var/lib/yum/plugins/langpacks/installed_langpacks file.

(In reply to Christian Stadelmann from comment #3)
> Oh, I should add that this only happens if umask is non-standard if you run
> `dnf langinstall` or dnf with plugin langpacks for the first time. Once it
> is created with correct permissions it will work fine.

If you have dnf-plugins-core package installed on your system then you will see
$ dnf langinstall hi
Error: This command has to be run under the root user.

That command needs root user access to run.

I know that you need to run `dnf langinstall` as root. But you shouldn't have to run dnf as root when just having the langpacks plugin enabled. You should not have to run `dnf langlist` as root either.

The /var/lib/yum/plugins/langpacks/installed_langpacks file is fine. It works when running dnf as root. It is not about the file contents, it is about the permissions in filesystem.
I know that this is no problem in the standard installation of Fedora Workstation. This is why I wrote that I set umask to 0077. With this setting it is a problem, and it should not be.

I don't see "dnf langlist" need to be run as root. See in the sourcecode https://github.com/pnemade/dnf-langpacks/blob/master/langpacks.py#L503

That command is marked as to allow by non-root users as well. Same for langinfo and langavailable command. So, only langinstall and langremove needs root user access.

Yes, `dnf langlist` doesn't need to be run as root. But it is not related to this issue. Seems like I have been unable to explain this problem in a way that you understand. I'll try again:



Steps to reproduce:
1. You need a Fedora installation without dnf-langpacks ever run. Alternatively you could delete the /var/lib/yum/plugins folder.
2. set your umask to 0077
3. run dnf with dnf-langpacks plugin installed. No matter what command you will run, it will try to mkdir /var/lib/yum/plugins/langpacks/ and create /var/lib/yum/plugins/langpacks/installed_langpacks.

3.a) If you run step 3 as non-root user first, the command will fail (print errors) because you don't have permission to mkdir and create as noted above.

3.b) If you run step 3 as root, mkdir and create will work, but with wrong file permissions:
drwx------ /var/lib/yum/plugins/
drwx------ /var/lib/yum/plugins/langpacks/
-rw------- /var/lib/yum/plugins/langpacks/installed_packages

3.c) If you run step 3 as non-root user after running as root, the langpacks plugin will always fail to read those files. It will be unable to determine which langpacks are installed. It does not have to write the files, just read them. This is what I described in comment #2.



To fix this problem I suggest these steps:

1. add /var/lib/yum/plugins/langpacks with permissions 755 to the rpm package (spec file). This way you guarantee that the folder exists once your plugin is installed. Besides: Why is it not /var/lib/dnf/plugins/langpacks ?

2. In langpacks.py, line 83ff you create the path /var/lib/yum/plugins/langpacks/installed_langpacks if it does not exist. This must always fail if dnf is run as a user. If you did fix 1, you could remove the line `os.makedirs(self.conffile_dir)` entirely. Otherwise you need to run this line only if you are root.

3. (If you decide not to do 1) To fix permissions on the /var/lib/yum/plugins/langpacks folder, you have to set umask before running `os.makedirs(self.conffile_dir)`. Permissions have to be 755 (rwxr-xr-x), so umask should be set to 0022, e.g. using `os.umask()`. Please reset umask after creating this folder.

4. in langpacks.py:90 you call `open(self.conffile, 'a')`. Why this? If running dnf as non-root user this must always fail since you don't have permission to append (and thus write) to this file. When running as non-root user you should not try to open the file with 'a' or 'w' at all. If the file does not exist, no langpacks are installed.

5. If running `open(self.conffile, 'a')` (langpacks.py:90) as root, you have to set permissions first before creating this file. Permissions on this file have to be 744 (rwxr--r--), so you should set umask to 0033. Please reset umask after creating the file.



There is still another issue left: How do you handle systems with dnf-langpacks plugin already shipped and folders/files with wrong permissions created? I don't have a solution for that. Maybe you need some code to check and fix file permissions.



Besides:
Why are there whitelisted locales? (langpacks.py:43f)
Why are you skipping 'cs_CZ' (langpacks.py:206) – maybe a comment would help.
Isn't setup.py:16ff missing the /var/lib/yum/plugins/langpacks/installed_langpacks file?

Sorry, another correction for comment #9:
In "Steps to reproduce", setting umask to 0077 applies to the root user. It does not matter what your non-root user's umask is¹.

¹ At least if you don't use sudo. I don't know what the effect will be in this case.

one quick comment here, file is actually created by yum-langpacks. To not confuse yum-langpacks to dnf-langpacks users we need to use same list of installed languages /var/lib/yum/plugins/langpacks/installed_langpacks 

We are thinking on adding this file as %ghost in spec file since long time but I did not find any strong reason. Maybe now is a good time to implement this.

Note /var/lib/yum path is owned by yum and we will not be having yum on standard installation media in F23.

Thinking on this more...

The file is not created by yum-langpacks for me. I don't have yum-langpacks installed and I think I never had on F22. This file/folder got created today when I ran dnf for the first time after updating to 0.11.1.

Till Fedora 21 yum-langpacks was part of Standard and Workstation product group. I changed that in Fedora 22 to dnf-langpacks. So when dnf become default we were needed replacement of yum-langpacks with dnf-langpacks but we don't want to miss the existing installed langpack information so dnf-langpacks start using /var/lib/yum/plugins/langpacks/installed_langpacks file. dnf-langpacks is creating that file since last few releases.

note yum-langpacks also not own that file but in runtime checks existence of that file and if not available creates it.

With dnf-langpacks updated to 0.12.0-2.fc22 the error message

Error reading file : /var/lib/yum/plugins/langpacks/installed_langpacks as it 
does not exist

is now gone. The file/directory is still not readable by non-root users.

Also seen this issue imediatelly after installing dnf-langpacks.noarch 0.12.0-2.fc22, when running dnf commands without root.
Would get the error message:
"Unable to create file : /var/lib/yum/plugins/langpacks/installed_langpacks"

One call of dnf with root and the message is gone, and the "installed_langpacks" file is there.

I just upgraded a system from Fedora 21 to 23, and I see this in /var/log/messages* (including lines of context around "dnf: Error reading file : /var/lib/dnf/plugins/langpacks/installed_langpacks as it does not exist"):

Jan  5 08:35:02 servername systemd: Starting dnf makecache...
Jan  5 08:35:02 servername dnf: cachedir: /var/cache/dnf
Jan  5 08:35:02 servername dnf: Loaded plugins: protected_packages, system-upgrade, debuginfo-install, config-manager, langpacks, generate_completion_cache, needs-restarting, reposync, copr, builddep, playground, Query, noroot, download
Jan  5 08:35:02 servername dnf: langpacks: No languages are enabled
Jan  5 08:35:02 servername dnf: Error reading file : /var/lib/dnf/plugins/langpacks/installed_langpacks as it does not exist
Jan  5 08:35:02 servername dnf: initialized Langpacks plugin

I have the following packages installed that I'd expect to satisfy this need:

$ rpm -qa *langpacks*
python3-dnf-langpacks-0.15.1-1.fc23.noarch
dnf-langpacks-0.15.1-1.fc23.noarch
yum-langpacks-0.4.5-2.fc23.noarch
dnf-langpacks-conf-0.15.1-1.fc23.noarch

Thanks Edward for your input here. What you saw is in dnf logs which is fine.

I think this bug now remained only to what is reported in comment#14 and I don't know how to fix this when root user is using non-standard umask. I think we should stick to standard permissions set by system only.

Yes, dnf should support non-standard permissions (umask) too, as does most system software. Simply creating this file with correct permissions does the job.

this is also present in Fedora 23.

Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.