Contributing RPM packaging and SELinux module #54

veitw · 2020-11-13T23:51:39Z

I'd like to contribute the necessary bits to allow RPM packaging and usage on SELinux enabled systems for both python-validity and open-fprintd. Please see my pull requests #53 and uunicorn/open-fprintd#7.

The specfiles have been created close to the RedHat guidelines and tested on Fedora 33. I expect them to work on EL8 (RHEL 8, CentOS 8), too. Other RPM based distros such as openSUSE might need tweaking.

However the python-validity specfile uses a post install scriptlet derived from your Debian scripts, to make them as close as possible. But I expect this to prevent the package to be accepted into the distros, as I think automatically downloading and flashing firmware on package installation conflicts with RedHat's/Fedora's packaging rules.

For fprintd-clients, I decided to NOT use your fork of fprintd, but to use Fedora's fprintd package as template and only rename the package and to simply not package the daemon files. The result, fprintd-clients.spec, along with a patch file to the original fprintd package's fprintd.spec, has been attached: fprintd-clients.zip

Best regards,
// Veit

veitw · 2020-11-14T00:03:27Z

For those who want to try this using the current releases, here are RPMs for Fedora 33 x86_64 and of course the corresponding SRPMs to build yourself for other distros/releases:

Installation instructions for Fedora 33:

Extract the RPMs from the archives above.
Install the packages: sudo dnf install python3-validity-0.12-1.fc33.noarch.rpm open-fprintd-0.6-1.fc33.noarch.rpm fprintd-clients-1.90.1-2.fc33.x86_64.rpm fprintd-clients-pam-1.90.1-2.fc33.x86_64.rpm
Enable and start the service: systemctl enable python3-validity.service; systemctl start python3-validity.service
Profit!

Starting the service should suffice, but maybe better reboot.

RaghavRao · 2020-11-14T00:32:01Z

Amazing work, thank you @veitw

uunicorn · 2020-11-14T03:45:46Z

But I expect this to prevent the package to be accepted into the distros, as I think automatically downloading and flashing firmware on package installation conflicts with RedHat's/Fedora's packaging rules

Yes, I'm not sure that was a very good idea myself. There may not be any real hardware when you install the package, so it is not clear which firmware to download. It is also downloading a piece of software with it's own license without a user's explicit permission.

rodgersan · 2020-11-14T23:15:01Z

For those who want to try this using the current releases, here are RPMs for Fedora 33 x86_64 and of course the corresponding SRPMs to build yourself for other distros/releases:

* [rpms-python-validity.zip](https://github.com/uunicorn/python-validity/files/5539808/rpms-python-validity.zip)

* [rpms-open-fprintd.zip](https://github.com/uunicorn/python-validity/files/5539809/rpms-open-fprintd.zip)

* [rpms-fprintd-clients.zip](https://github.com/uunicorn/python-validity/files/5539811/rpms-fprintd-clients.zip)

Installation instructions for Fedora 33:

1. Extract the RPMs from the archives above.

2. Install the packages: `sudo dnf install python3-validity-0.12-1.fc33.noarch.rpm open-fprintd-0.6-1.fc33.noarch.rpm fprintd-clients-1.90.1-2.fc33.x86_64.rpm fprintd-clients-pam-1.90.1-2.fc33.x86_64.rpm`

3. Enable and start the service: `systemctl enable python3-validity.service; systemctl start python3-validity.service`

4. Profit!

Starting the service should suffice, but maybe better reboot.

You might want to have a look at the RPM packages provided in issue #54.

Thanks for packaging it for Fedora 33! However I am getting almost the same error as @alexjfinch in issue #42 using your RPMs and instructions:

● python3-validity.service - python-validity driver dbus service
Loaded: loaded (/usr/lib/systemd/system/python3-validity.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Sun 2020-11-15 00:08:44 CET; 1s ago
Process: 5293 ExecStart=/usr/lib/python-validity/dbus-service --debug (code=exited, status=1/FAILURE)
Main PID: 5293 (code=exited, status=1/FAILURE)
CPU: 158ms

nov 15 00:08:44 fedora-t470 dbus-service[5293]: Traceback (most recent call last):
nov 15 00:08:44 fedora-t470 dbus-service[5293]: File "/usr/lib/python-validity/dbus-service", line 307, in
nov 15 00:08:44 fedora-t470 dbus-service[5293]: main()
nov 15 00:08:44 fedora-t470 dbus-service[5293]: File "/usr/lib/python-validity/dbus-service", line 260, in main
nov 15 00:08:44 fedora-t470 dbus-service[5293]: backoff()
nov 15 00:08:44 fedora-t470 dbus-service[5293]: File "/usr/lib/python-validity/dbus-service", line 214, in backoff
nov 15 00:08:44 fedora-t470 dbus-service[5293]: with open(backoff_file, 'w') as f:
nov 15 00:08:44 fedora-t470 dbus-service[5293]: PermissionError: [Errno 13] Permission denied: '/usr/share/python-validity/backoff'
nov 15 00:08:44 fedora-t470 systemd[1]: python3-validity.service: Main process exited, code=exited, status=1/FAILURE
nov 15 00:08:44 fedora-t470 systemd[1]: python3-validity.service: Failed with result 'exit-code'.

Any ideas?

bwiercinski · 2020-12-07T23:19:10Z

@rodgersan you can try to sudo mkdir /usr/share/python-validity and start again, but in my case other errors appeared.

@veitw why these packages requires python3.9? any ideas to fix that? sudo dnf install python3.9 didn't worked

Error: 
 Problem 1: conflicting requests
  - nothing provides python(abi) = 3.9 needed by python3-validity-0.12-1.fc33.noarch
  - nothing provides python3.9dist(cryptography) >= 2.1.4 needed by python3-validity-0.12-1.fc33.noarch
  - nothing provides python3.9dist(pyusb) >= 1 needed by python3-validity-0.12-1.fc33.noarch
  - nothing provides python3.9dist(pyyaml) >= 3.12 needed by python3-validity-0.12-1.fc33.noarch
 Problem 2: conflicting requests
  - nothing provides python(abi) = 3.9 needed by open-fprintd-0.6-1.fc33.noarch
(try to add '--skip-broken' to skip uninstallable packages)

rodgersan · 2020-12-08T15:56:47Z

@rodgersan you can try to sudo mkdir /usr/share/python-validity and start again, but in my case other errors appeared.

@veitw why these packages requires python3.9? any ideas to fix that? sudo dnf install python3.9 didn't worked

Error: 
 Problem 1: conflicting requests
  - nothing provides python(abi) = 3.9 needed by python3-validity-0.12-1.fc33.noarch
  - nothing provides python3.9dist(cryptography) >= 2.1.4 needed by python3-validity-0.12-1.fc33.noarch
  - nothing provides python3.9dist(pyusb) >= 1 needed by python3-validity-0.12-1.fc33.noarch
  - nothing provides python3.9dist(pyyaml) >= 3.12 needed by python3-validity-0.12-1.fc33.noarch
 Problem 2: conflicting requests
  - nothing provides python(abi) = 3.9 needed by open-fprintd-0.6-1.fc33.noarch
(try to add '--skip-broken' to skip uninstallable packages)

Thanks @bwiercinski but somehow that folder was already there... concerning python 3.9, it's shipped by default on Fedora 33 if I am not mistaken.

Are you on Fedora 33 by the way?

bwiercinski · 2020-12-08T16:07:06Z

@rodgersan nope... i think it's a good occasion to upgrade

after fixing permission problems with /usr/share/python-validity is the package working?

rodgersan · 2020-12-08T18:53:04Z

@rodgersan nope... i think it's a good occasion to upgrade

after fixing permission problems with /usr/share/python-validity is the package working?

@bwiercinski, sorry but what should be those working permissions? I have drwxr-xr-x, owner is root.

I am not sure this is the problem as it tries to access /usr/share/python-validity/backoff which does not exist and does not seem to be provided by any of the rpm. Did you have the same error before getting python3.9 issues?

bwiercinski · 2020-12-09T13:30:33Z

python-validity is creating backoff file by itself but the /usr/share/python-validity directory must be created and accessible

in my case after creating this directory backoff file was created by itself

i had this issue when i was installing the library manually not via rpm

are u starting python-validary service as --user or root?

rodgersan · 2020-12-09T13:57:52Z

@bwiercinski

Understood! Yet I am running everything as root to rule out any permission errors (and because of python-validity wiki).
If I run validity-sensors-firmware as root, I get this;

`Traceback (most recent call last):
File "/usr/lib/python3.9/site-packages/pkg_resources/init.py", line 582, in _build_master
ws.require(requires)
File "/usr/lib/python3.9/site-packages/pkg_resources/init.py", line 899, in require
needed = self.resolve(parse_requirements(requirements))
File "/usr/lib/python3.9/site-packages/pkg_resources/init.py", line 790, in resolve
raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.VersionConflict: (python-validity 0.12 (/usr/lib/python3.9/site-packages), Requirement.parse('python-validity==0.9'))

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/usr/local/bin/validity-sensors-firmware", line 4, in
import('pkg_resources').run_script('python-validity==0.9', 'validity-sensors-firmware')
File "/usr/lib/python3.9/site-packages/pkg_resources/init.py", line 3257, in
def _initialize_master_working_set():
File "/usr/lib/python3.9/site-packages/pkg_resources/init.py", line 3240, in _call_aside
f(*args, **kwargs)
File "/usr/lib/python3.9/site-packages/pkg_resources/init.py", line 3269, in _initialize_master_working_set
working_set = WorkingSet._build_master()
File "/usr/lib/python3.9/site-packages/pkg_resources/init.py", line 584, in _build_master
return cls._build_from_requirements(requires)
File "/usr/lib/python3.9/site-packages/pkg_resources/init.py", line 597, in _build_from_requirements
dists = ws.resolve(reqs, Environment())
File "/usr/lib/python3.9/site-packages/pkg_resources/init.py", line 785, in resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'python-validity==0.9' distribution was not found and is required by the application`

And if I run (root); python3.9 /usr/share/python-validity/playground/factory-reset.py

Traceback (most recent call last): File "/usr/share/python-validity/playground/factory-reset.py", line 6, in <module> factory_reset() File "/usr/lib/python3.9/site-packages/validitysensor/sensor.py", line 86, in factory_reset assert_status(usb.cmd(b'\x10' + b'\0' * 0x61)) File "/usr/lib/python3.9/site-packages/validitysensor/util.py", line 12, in assert_status raise Exception('Failed: %04x' % s) Exception: Failed: 0404

So I am lost... thanks anyway for your help!

rodgersan · 2020-12-09T14:00:41Z

I am just realising I may have issues because of python-validity 0.9 leftovers!?!?

Although when I run python3.9 -m pip list, I get python-validity 0.12!

bwiercinski · 2020-12-09T22:30:49Z

ok i've upgraded fedora to 33 and install python-validity via provided rpm packages
i had the same error with backoff file, then i've initialized it via sudo touch /usr/share/python-validity/backoff
now i have an error
PermissionError: [Errno 13] Permission denied: '/usr/share/python-validity/calib-data.bin'

rodgersan · 2020-12-09T22:48:05Z

Sorry for the noob question but neither calib-data.bin nor backoff exist on this repo. I am not having better results looking for them on the internet... are they really supposed to be there? or are they just scraps from previous versions?

uunicorn · 2020-12-10T01:27:55Z

neither calib-data.bin nor backoff exist on this repo

Those are runtime files. They are still in use (python-validity creates and uses them), however they probably do not belong in /share.

bwiercinski · 2020-12-10T14:28:25Z

after sudo touch /usr/share/python-validity/calib-data.bin

i have:

gru 10 15:25:50 LT33728 dbus-service[33971]: Traceback (most recent call last):
gru 10 15:25:50 LT33728 dbus-service[33971]:   File "/usr/lib/python-validity/dbus-service", line 307, in <module>
gru 10 15:25:50 LT33728 dbus-service[33971]:     main()
gru 10 15:25:50 LT33728 dbus-service[33971]:   File "/usr/lib/python-validity/dbus-service", line 264, in main
gru 10 15:25:50 LT33728 dbus-service[33971]:     init.open()
gru 10 15:25:50 LT33728 dbus-service[33971]:   File "/usr/lib/python3.9/site-packages/validitysensor/init.py", line 48, in open
gru 10 15:25:50 LT33728 dbus-service[33971]:     open_common()
gru 10 15:25:50 LT33728 dbus-service[33971]:   File "/usr/lib/python3.9/site-packages/validitysensor/init.py", line 29, in open_common
gru 10 15:25:50 LT33728 dbus-service[33971]:     init_flash()
gru 10 15:25:50 LT33728 dbus-service[33971]:   File "/usr/lib/python3.9/site-packages/validitysensor/init_flash.py", line 113, in init_flash
gru 10 15:25:50 LT33728 dbus-service[33971]:     info = get_flash_info()
gru 10 15:25:50 LT33728 dbus-service[33971]:   File "/usr/lib/python3.9/site-packages/validitysensor/flash.py", line 41, in get_flash_info
gru 10 15:25:50 LT33728 dbus-service[33971]:     assert_status(rsp)
gru 10 15:25:50 LT33728 dbus-service[33971]:   File "/usr/lib/python3.9/site-packages/validitysensor/util.py", line 12, in assert_status
gru 10 15:25:50 LT33728 dbus-service[33971]:     raise Exception('Failed: %04x' % s)
gru 10 15:25:50 LT33728 dbus-service[33971]: Exception: Failed: 0315

the same error i have when i do
sudo python3 /usr/share/python-validity/playground/factory-reset.py

bwiercinski · 2020-12-10T15:02:11Z

ok sorry for spamming but happy news! i've managed to make it work! 🎉

all you have to do is:

sudo touch /usr/share/python-validity/backoff
sudo touch /usr/share/python-validity/calib-data.bin

# now you have to follow the instructions here: https://github.com/uunicorn/python-validity#error-situations and then:

cd /usr/share/python-validity && ls -la
# find driver file. in my case there is driver named: 6_07f_lenovo_mis_qm.xpfwext so:
sudo chmod 755 6_07f_lenovo_mis_qm.xpfwext

and the best part: i had to repeat these steps few times and in the end i've managed to enroll my finder ✌️

best wishes!

rodgersan · 2020-12-10T23:29:47Z

ok sorry for spamming but happy news! i've managed to make it work! tada

all you have to do is:
sudo touch /usr/share/python-validity/backoff
sudo touch /usr/share/python-validity/calib-data.bin

# now you have to follow the instructions here: https://github.com/uunicorn/python-validity#error-situations and then:

cd /usr/share/python-validity && ls -la
# find driver file. in my case there is driver named: 6_07f_lenovo_mis_qm.xpfwext so:
sudo chmod 755 6_07f_lenovo_mis_qm.xpfwext
and the best part: i had to repeat these steps few times and in the end i've managed to enroll my finder v

best wishes!

Good news indeed!
Thanks it helped going through the permission errors and service is now enabled and started but having then a "list_devices failed:" error I still get that python-validity==0.9 message... :(

bwiercinski · 2020-12-10T23:58:01Z

try to disable the service, pip uninstall python-validity (with or w/o sudo idk), uninstall python3-validity python-validity open-fprintd fprintd-clients fprintd-clients-pam, remove this folder sudo rm -rf /usr/share/python-validity.

after that install rpms and follow my instructions. i think You are close. list_devices failed: is the last error i saw before the born of my fingerprint sensor

rodgersan · 2020-12-11T00:45:47Z

ok sorry for spamming but happy news! i've managed to make it work! tada

all you have to do is:
sudo touch /usr/share/python-validity/backoff
sudo touch /usr/share/python-validity/calib-data.bin

# now you have to follow the instructions here: https://github.com/uunicorn/python-validity#error-situations and then:

cd /usr/share/python-validity && ls -la
# find driver file. in my case there is driver named: 6_07f_lenovo_mis_qm.xpfwext so:
sudo chmod 755 6_07f_lenovo_mis_qm.xpfwext
and the best part: i had to repeat these steps few times and in the end i've managed to enroll my finder v

best wishes!

Good news indeed!
Thanks it helped going through the permission errors and service is now enabled and started but having then a "list_devices failed:" error I still get that python-validity==0.9 message... :(

ok sorry for spamming but happy news! i've managed to make it work! tada

all you have to do is:
sudo touch /usr/share/python-validity/backoff
sudo touch /usr/share/python-validity/calib-data.bin

# now you have to follow the instructions here: https://github.com/uunicorn/python-validity#error-situations and then:

cd /usr/share/python-validity && ls -la
# find driver file. in my case there is driver named: 6_07f_lenovo_mis_qm.xpfwext so:
sudo chmod 755 6_07f_lenovo_mis_qm.xpfwext
and the best part: i had to repeat these steps few times and in the end i've managed to enroll my finder v

best wishes!

Thanks that all worked! I still had issues with validity-sensors-firmware trying to run from there: /usr/local/bin
So I created a symlink from /usr/bin/ and made it through a finger enrollment. But now I don't know how to use it! :(

bwiercinski · 2020-12-11T01:20:46Z

fprintd-verify works? if yes then follow manual of yours window manager

i've got lightdm with i3 and its automatically asking me about fingers.

make sure to have auth sufficient pam_fprintd.so in your pam config. see: https://wiki.archlinux.org/index.php/Fprint#Login_configuration for details.

rodgersan · 2020-12-11T09:06:07Z

fprintd-verify works? if yes then follow manual of yours window manager

i've got lightdm with i3 and its automatically asking me about fingers.

make sure to have auth sufficient pam_fprintd.so in your pam config. see: https://wiki.archlinux.org/index.php/Fprint#Login_configuration for details.

Ouch, no it does not!

Running fprintd-verify or fprintd-list MYUSERNAME, I get:

found 1 devices Device at /net/reactivated/Fprint/Device/0 Using device /net/reactivated/Fprint/Device/0 ListEnrolledFingers failed: Traceback (most recent call last): File "/usr/lib64/python3.9/site-packages/dbus/service.py", line 711, in _message_cb retval = candidate_method(self, *args, **keywords) File "/usr/lib/python-validity/dbus-service", line 90, in ListEnrolledFingers raise e File "/usr/lib/python-validity/dbus-service", line 81, in ListEnrolledFingers usr = self.user2record(user) File "/usr/lib/python-validity/dbus-service", line 64, in user2record return db.lookup_user(self.user2identity(user)) File "/usr/lib/python3.9/site-packages/validitysensor/db.py", line 163, in lookup_user stg = self.get_user_storage(name='StgWindsor') File "/usr/lib/python3.9/site-packages/validitysensor/db.py", line 149, in get_user_storage return parse_user_storage(tls.cmd(pack('<BHH', 0x4b, dbid, len(name)) + name)) File "/usr/lib/python3.9/site-packages/validitysensor/tls.py", line 122, in cmd rsp = self.app(cmd) File "/usr/lib/python3.9/site-packages/validitysensor/tls.py", line 152, in app return self.parse_tls_response(self.usb.cmd(self.make_app_data(b))) File "/usr/lib/python3.9/site-packages/validitysensor/tls.py", line 351, in parse_tls_response raise Exception('Unexpected TLS version %d %d' % (mj, mn)) Exception: Unexpected TLS version 4 0

Any ideas? I am using gnome/gdm by the way.

bwiercinski · 2020-12-11T18:34:30Z

restart the service, delete all fingers and reenroll, verify? maybe a bug in this project

rodgersan · 2020-12-21T22:25:04Z

restart the service, delete all fingers and reenroll, verify? maybe a bug in this project

bug report #61 was the solution, thanks. Finger enrolled for my user and verify is working.

Still not able to use the fingerprint reader neither in gdm nor su.

I first added my user to the input group without any luck, I am not seeing any option on the login screen or in gnome settings.
Then I added these lines to a bunch of files (login, su, system-auth, gdm-fingerprint) in /etc/pam.d:

auth sufficient pam_unix.so try_first_pass likeauth nullok
auth sufficient pam_fprintd.so

Yet nothing worked even after restarting the computer. Lost again! :|

alexjfinch · 2021-01-27T23:07:25Z

restart the service, delete all fingers and reenroll, verify? maybe a bug in this project

bug report #61 was the solution, thanks. Finger enrolled for my user and verify is working.

Still not able to use the fingerprint reader neither in gdm nor su.

I first added my user to the input group without any luck, I am not seeing any option on the login screen or in gnome settings.
Then I added these lines to a bunch of files (login, su, system-auth, gdm-fingerprint) in /etc/pam.d:

auth sufficient pam_unix.so try_first_pass likeauth nullok
auth sufficient pam_fprintd.so

Yet nothing worked even after restarting the computer. Lost again! :|

Are you using Fedora and have you managed to get this sorted? I finally got it all working tonight.

Instead of using Arch Wiki to edit those files in /etc/pam.d use "authselect" - I would remove any changes you've made to those files and then run;

$ sudo authselect current

This should be your output;
$ Profile ID: sssd
$ Enabled features: None

Then run the following;

$ sudo authselect enable-feature with-fingerprint
$ sudo authselect apply-changes

This worked for me as I was having the same issues as you. This is the output of my authselect current;

$ sudo authselect current
$ Profile ID: sssd
$ Enabled features:
$ - with-fingerprint
$ - with-silent-lastlog

Please note that once you reboot and have a registered fingerprint and log in with that fingerprint, gnome keyring still asks for your password straight afterwards as it sits outside of pam and therefore on first login with fingerprints you need to unlock it.

I find after suspend, you can log in with your fingerprint and not have to enter your password again.

Finally I did have the issue per #61 and #59 where by I needed to enable the resume and suspend services in systemd

rodgersan · 2021-01-28T16:58:25Z

restart the service, delete all fingers and reenroll, verify? maybe a bug in this project

bug report #61 was the solution, thanks. Finger enrolled for my user and verify is working.
Still not able to use the fingerprint reader neither in gdm nor su.
I first added my user to the input group without any luck, I am not seeing any option on the login screen or in gnome settings.
Then I added these lines to a bunch of files (login, su, system-auth, gdm-fingerprint) in /etc/pam.d:
auth sufficient pam_unix.so try_first_pass likeauth nullok
auth sufficient pam_fprintd.so
Yet nothing worked even after restarting the computer. Lost again! :|

Are you using Fedora and have you managed to get this sorted? I finally got it all working tonight.

Instead of using Arch Wiki to edit those files in /etc/pam.d use "authselect" - I would remove any changes you've made to those files and then run;

$ sudo authselect current

This should be your output;
$ Profile ID: sssd
$ Enabled features: None

Then run the following;

$ sudo authselect enable-feature with-fingerprint
$ sudo authselect apply-changes

This worked for me as I was having the same issues as you. This is the output of my authselect current;

$ sudo authselect current
$ Profile ID: sssd
$ Enabled features:
$ - with-fingerprint
$ - with-silent-lastlog

Please note that once you reboot and have a registered fingerprint and log in with that fingerprint, gnome keyring still asks for your password straight afterwards as it sits outside of pam and therefore on first login with fingerprints you need to unlock it.

I find after suspend, you can log in with your fingerprint and not have to enter your password again.

Finally I did have the issue per #61 and #59 where by I needed to enable the resume and suspend services in systemd

Hi,

Thanks! Followed your instructions from getting all configuration files to defaults and then ran the autoselect commands.
Thanks as well for updating your instruction, got confused with autoselect status! ;)
So now as you stated, it seems to works from gdm except for the gnome-keyring.
Hope this get "official" somehow.

Regards,

veitw mentioned this issue Nov 14, 2020

RPM package #42

Open

Plamper mentioned this issue Dec 5, 2020

Support for Synaptics 06cb:00e7 #60

Open

bwiercinski mentioned this issue Dec 12, 2020

[fedora] after suspending or hibernating service stops bringing functionalities #61

Closed

rmeissn mentioned this issue Jun 16, 2021

added Fedora installation items #82

Merged

sudopluto mentioned this issue Jul 6, 2021

06cb:009a can't start validity service #89

Open

mircsicz mentioned this issue Apr 9, 2022

Can't enroll my finger #119

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Contributing RPM packaging and SELinux module #54

Contributing RPM packaging and SELinux module #54

veitw commented Nov 13, 2020

veitw commented Nov 14, 2020 •

edited

Loading

RaghavRao commented Nov 14, 2020

uunicorn commented Nov 14, 2020

rodgersan commented Nov 14, 2020

bwiercinski commented Dec 7, 2020

rodgersan commented Dec 8, 2020 •

edited

Loading

bwiercinski commented Dec 8, 2020 •

edited

Loading

rodgersan commented Dec 8, 2020

bwiercinski commented Dec 9, 2020 •

edited

Loading

rodgersan commented Dec 9, 2020 •

edited

Loading

rodgersan commented Dec 9, 2020 •

edited

Loading

bwiercinski commented Dec 9, 2020

rodgersan commented Dec 9, 2020

uunicorn commented Dec 10, 2020

bwiercinski commented Dec 10, 2020 •

edited

Loading

bwiercinski commented Dec 10, 2020 •

edited

Loading

rodgersan commented Dec 10, 2020

bwiercinski commented Dec 10, 2020

rodgersan commented Dec 11, 2020

bwiercinski commented Dec 11, 2020

rodgersan commented Dec 11, 2020

bwiercinski commented Dec 11, 2020

rodgersan commented Dec 21, 2020

alexjfinch commented Jan 27, 2021 •

edited

Loading

rodgersan commented Jan 28, 2021

Contributing RPM packaging and SELinux module #54

Contributing RPM packaging and SELinux module #54

Comments

veitw commented Nov 13, 2020

veitw commented Nov 14, 2020 • edited Loading

RaghavRao commented Nov 14, 2020

uunicorn commented Nov 14, 2020

rodgersan commented Nov 14, 2020

bwiercinski commented Dec 7, 2020

rodgersan commented Dec 8, 2020 • edited Loading

bwiercinski commented Dec 8, 2020 • edited Loading

rodgersan commented Dec 8, 2020

bwiercinski commented Dec 9, 2020 • edited Loading

rodgersan commented Dec 9, 2020 • edited Loading

rodgersan commented Dec 9, 2020 • edited Loading

bwiercinski commented Dec 9, 2020

rodgersan commented Dec 9, 2020

uunicorn commented Dec 10, 2020

bwiercinski commented Dec 10, 2020 • edited Loading

bwiercinski commented Dec 10, 2020 • edited Loading

rodgersan commented Dec 10, 2020

bwiercinski commented Dec 10, 2020

rodgersan commented Dec 11, 2020

bwiercinski commented Dec 11, 2020

rodgersan commented Dec 11, 2020

bwiercinski commented Dec 11, 2020

rodgersan commented Dec 21, 2020

alexjfinch commented Jan 27, 2021 • edited Loading

rodgersan commented Jan 28, 2021

veitw commented Nov 14, 2020 •

edited

Loading

rodgersan commented Dec 8, 2020 •

edited

Loading

bwiercinski commented Dec 8, 2020 •

edited

Loading

bwiercinski commented Dec 9, 2020 •

edited

Loading

rodgersan commented Dec 9, 2020 •

edited

Loading

rodgersan commented Dec 9, 2020 •

edited

Loading

bwiercinski commented Dec 10, 2020 •

edited

Loading

bwiercinski commented Dec 10, 2020 •

edited

Loading

alexjfinch commented Jan 27, 2021 •

edited

Loading