So I decided to look into tracer.
When I did my system build I did a 'dnf list > dnf.lst' to get a listing of all rpms in the repos (at least at that point it time). I have found this an easy way to go look for things of interest. So I did:
# grep tracer dnf.lst traceroute.x86_64 3:2.1.0-6.fc28 @fedora accumulo-tracer.noarch 1.8.1-9.fc28 fedora dnstracer.x86_64 1.9-19.fc28 fedora golang-github-rubyist-tracerx-devel.noarch paris-traceroute.x86_64 0.92-13.fc28 fedora python2-dnf-plugin-tracer.noarch 2.0.5-3.fc28 fedora python2-tracer.noarch 0.7.0-1.fc28 updates python3-dnf-plugin-tracer.noarch 2.0.5-3.fc28 fedora python3-tracer.noarch 0.7.0-1.fc28 updates tracer-common.noarch 0.7.0-1.fc28 updates
There is a python2 and 3 tracer. Which one to use on F28? What is the difference between the command line tracer and the dnf plugin?
thanks
On 06/03/18 11:37, Robert Moskowitz wrote:
So I decided to look into tracer.
When I did my system build I did a 'dnf list > dnf.lst' to get a listing of all rpms in the repos (at least at that point it time). I have found this an easy way to go look for things of interest. So I did:
# grep tracer dnf.lst traceroute.x86_64 3:2.1.0-6.fc28 @fedora accumulo-tracer.noarch 1.8.1-9.fc28 fedora dnstracer.x86_64 1.9-19.fc28 fedora golang-github-rubyist-tracerx-devel.noarch paris-traceroute.x86_64 0.92-13.fc28 fedora python2-dnf-plugin-tracer.noarch 2.0.5-3.fc28 fedora python2-tracer.noarch 0.7.0-1.fc28 updates python3-dnf-plugin-tracer.noarch 2.0.5-3.fc28 fedora python3-tracer.noarch 0.7.0-1.fc28 updates tracer-common.noarch 0.7.0-1.fc28 updates
There is a python2 and 3 tracer. Which one to use on F28? What is the difference between the command line tracer and the dnf plugin?
python3-tracer is the one that will get installed if you type "dnf install tracer" on an F28 system.
Functionally, there is no difference between the command line and the plugin. The difference is that the plugin will be run automatically after dnf transactions which make changes to the system.
Thanks
On 06/03/2018 12:13 AM, Ed Greshko wrote:
On 06/03/18 11:37, Robert Moskowitz wrote:
So I decided to look into tracer.
When I did my system build I did a 'dnf list > dnf.lst' to get a listing of all rpms in the repos (at least at that point it time). I have found this an easy way to go look for things of interest. So I did:
# grep tracer dnf.lst traceroute.x86_64 3:2.1.0-6.fc28 @fedora accumulo-tracer.noarch 1.8.1-9.fc28 fedora dnstracer.x86_64 1.9-19.fc28 fedora golang-github-rubyist-tracerx-devel.noarch paris-traceroute.x86_64 0.92-13.fc28 fedora python2-dnf-plugin-tracer.noarch 2.0.5-3.fc28 fedora python2-tracer.noarch 0.7.0-1.fc28 updates python3-dnf-plugin-tracer.noarch 2.0.5-3.fc28 fedora python3-tracer.noarch 0.7.0-1.fc28 updates tracer-common.noarch 0.7.0-1.fc28 updates
There is a python2 and 3 tracer. Which one to use on F28? What is the difference between the command line tracer and the dnf plugin?
python3-tracer is the one that will get installed if you type "dnf install tracer" on an F28 system.
Functionally, there is no difference between the command line and the plugin. The difference is that the plugin will be run automatically after dnf transactions which make changes to the system.
After this morning's update that included a new kernel:
# tracer You should restart: * These applications manually: (sd-pam) Thunar audacity firefox oosplash soffice.bin tumblerd virt-manager xfce4-panel xfce4-terminal xfdesktop xfwm4
Additionally to those process above, there are: - 7 processes requiring restart of your session (i.e. Logging out & Logging in again) - 4 processes requiring reboot
I have to finish what I have open in audacity before I reboot. Then I will see if any of the fixes address the cdrom problem, which I suspect not as there has not been any bug update...
On 06/03/18 21:27, Robert Moskowitz wrote:
I have to finish what I have open in audacity before I reboot. Then I will see if any of the fixes address the cdrom problem, which I suspect not as there has not been any bug update...
https://bugzilla.redhat.com/show_bug.cgi?id=1583845%C2%A0 has not been addressed. So, I wouldn't expect it is fixed.