(f33; gnome)
I just finished upgrading from f32 to f33.
When I click the gnome "Activities", I no longer see "caja". When I use the gnome activities search thing, it does not find "caja". But dnf shows it installed and up-to-date. Before today's update, caja was easily available through the gnome Activities. How do I get caja back into the gnome Activities, and visible to the gnome Activities search?
Thank-you in advance. Bill.
On 09/04/2021 03:51, home user wrote:
I just finished upgrading from f32 to f33.
When I click the gnome "Activities", I no longer see "caja". When I use the gnome activities search thing, it does not find "caja". But dnf shows it installed and up-to-date. Before today's update, caja was easily available through the gnome Activities. How do I get caja back into the gnome Activities, and visible to the gnome Activities search?
I'm neither a regular gnome or mate user. But thought I'd supply this unhelpful observation.
I just installed F32 Workstation in a VM. After install, but before updates, I installed caja. It does not show in Activities.
Of course it was installed from updates. For completeness, I erased caja, disabled updates, and installed the release version. It too didn't show in Activities.
So, I don't know how/why it was showing for you.
On 11/04/2021 10:56, Joe Zeff wrote:
On 4/10/21 7:05 PM, Ed Greshko wrote:
Of course it was installed from updates.
Why should that matter?
Because I don't know the habits of the OP in installing updates.
So, not being in the habit of making assumptions and my not knowing how the Activities search finds applications and since caja is part of MATE, I felt it would be a good idea to check the release version of caja for the potential of a packaging change.
On 4/10/21 9:38 PM, Ed Greshko wrote:
On 11/04/2021 10:56, Joe Zeff wrote:
On 4/10/21 7:05 PM, Ed Greshko wrote:
Of course it was installed from updates.
Why should that matter?
Because I don't know the habits of the OP in installing updates.
So, not being in the habit of making assumptions and my not knowing how the Activities search finds applications and since caja is part of MATE, I felt it would be a good idea to check the release version of caja for the potential of a packaging change.
The upgrade is done mostly by following the instructions in the Fedora web site. These were my steps... * patch and re-boot. * dnf system-upgrade download --refresh --releasever=33 * dnf system-upgrade reboot * have a tall cold one! ...well, several tall cold ones! * dnf upgrade * dnf repoquery --unsatisfied * dnf repoquery --duplicates * symlinks -r /usr | grep dangling * symlinks -r -d /usr * rpm --rebuilddb * dnf distro-sync * fixfiles -B onboot * reboot. * rkhunter --propupd
Ed's first post did suggest things to look at.
Since the upgrade (and patching) keeps the most recent 2 patches, I tried to boot up in each of those last 2 (f32), log in, and check for caja. The application has become "invisible" to gnome in those patches also. 1. Before Thursday's upgrade, in f32, caja was visible in the gnome dash, it was visible in the gnome applications grid, and the gnome activities search would find it. I used it just before doing the pre-upgrade patch. 2. Now, in both of the 2 f32s, caja does not show up in the gnome dash, it does not show up in the gnome applications grid, and the gnome activities search fails to find it. 3. In f33, the behavior is as described in #2 above, I tried that with the root account, the admin account, and both user accounts; no difference. So the upgrade seems to have made caja invisible to gnome, evewn in the 2 old f32s. But, in gnome, I can launch caja from the command line, and when I insert a USB drive into a USB port, a little box slides down below the date-time; it offers to open the drive with caja (and it works).
In f33, I logged in to Mate. Caja is there and it works.
I attached output from "dnf info caja" so you can see what I have.
Those are all the clues and evidence I can think of at the moment.
On 4/10/21 9:38 PM, home user wrote:
Since the upgrade (and patching) keeps the most recent 2 patches, I tried to boot up in each of those last 2 (f32), log in, and check for caja. The application has become "invisible" to gnome in those patches also.
It doesn't actually work like that. Only the kernel is kept, not everything. When you pick a different entry, you're only selecting a different kernel. All the other software is the same.
On Thu, 2021-04-08 at 13:51 -0600, home user wrote:
When I click the gnome "Activities", I no longer see "caja". When I use the gnome activities search thing, it does not find "caja". But dnf shows it installed and up-to-date.
My first guess would be to locate caja.desktop file(s), and check through it (file permissions, typing errors in the file).
On 11/04/2021 12:38, home user wrote:
Those are all the clues and evidence I can think of at the moment.
OK.... I'm going to "dismiss" what you've said for the reason that I don't know why it was working for you in the first place. I went back to installing F31 and the same results. Not there....
But, I can tell you how to "fix" it.
Install "menulibre". This will allow you to add a "launcher". It will then be visible when you search in the search bar in "Activities". And you can add it to your "Favorites" if you wish.
On 11/04/2021 13:36, Tim via users wrote:
On Thu, 2021-04-08 at 13:51 -0600, home user wrote:
When I click the gnome "Activities", I no longer see "caja". When I use the gnome activities search thing, it does not find "caja". But dnf shows it installed and up-to-date.
My first guess would be to locate caja.desktop file(s), and check through it (file permissions, typing errors in the file).
Thanks for that.....
The "other" way to fix it is to edit the file...
/usr/share/applications/caja.desktop
and comment out as shown
#NoDisplay=true #OnlyShowIn=MATE;
Caveat: This file is a "system-wide" file and may get overwritten on updates. This file affects all users The previous "menulibre" solution is a per-user solution which adds a desktop file within the user's directory.
On Sun, 2021-04-11 at 15:47 +0800, Ed Greshko wrote:
The "other" way to fix it is to edit the file...
/usr/share/applications/caja.desktop
and comment out as shown
#NoDisplay=true
#OnlyShowIn=MATE;
Caveat: This file is a "system-wide" file and may get overwritten on updates. This file affects all users
The previous "menulibre" solution is a per-user solution which adds a desktop file within the user's directory.
I wonder if it's supposed to be undisplayed and only in MATE, or was that a goof. The original poster might try filing a bug report and see what the response is.
I'm still on Fedora 32, using MATE with old-school menus, not the pretend it's a tablet interface. Caja is in the Applications - System Tools sub-menu.
My default-installation /usr/share/applications/caja.desktop contains: NoDisplay=true OnlyShowIn=MATE;
My /usr/share/xfce4/helpers/caja.desktop does not.
I can sort of understand it being MATE specific. When I had KDE installed on a system, as well as other interfaces, there were various things that only showed up in it. So I guess various interfaces which have their own file browsers might use theirs instead, or instead of listing all the available ones. But it's a bit user-unfriendly.
I do modify my menus (which actually means *my* menus, which should get left alone by updates). e.g. It makes no sense, to me, for Evolution to be in the Office menu, but not the Internet one. Chiefly, I use it for email, which is an internet thing.
On 2021-04-11 12:47 a.m., Ed Greshko wrote:
The "other" way to fix it is to edit the file...
/usr/share/applications/caja.desktop
and comment out as shown
#NoDisplay=true #OnlyShowIn=MATE;
Caveat: This file is a "system-wide" file and may get overwritten on updates. This file affects all users
To make it not system-wide, copy the file to ~/.local/share/applications/ and edit it there.
2021-04-11 6:38 UTC+02:00, home user mattisonw@comcast.net:
[...]
- symlinks -r -d /usr
This isn't necessarily a good idea, because those dangling symlinks may belong to their respective packages. If so, removing them will compromise the integrity of the package they belong to.
It doesn't actually work like that. Only the kernel is kept, not everything. When you pick a different entry, you're only selecting a different kernel. All the other software is the same.
Do you mean that all the other software is the same as the newest? If I do a weekly patch (dnf upgrade), and that patch includes patches to vim or firefox, and then the next day I boot into one of the older entries in the grub menu, I should get the newer firefox and vim and the the older?
But, I can tell you how to "fix" it.
Install "menulibre". This will allow you to add a "launcher". It will then be visible when you search in the search bar in "Activities". And you can add it to your "Favorites" if you wish.
I'm opting for the more general fix in your later post. But thank-you.
The "other" way to fix it is to edit the file...
/usr/share/applications/caja.desktop
and comment out as shown
#NoDisplay=true #OnlyShowIn=MATE;
Caveat: This file is a "system-wide" file and may get overwritten on updates. This file affects all users The previous "menulibre" solution is a per-user solution which adds a desktop file within the user's directory.
I opted for this fix. It was easy. It works. Thank-you!
2021-04-11 6:38 UTC+02:00, home user <mattisonw(a)comcast.net>:
[...]
This isn't necessarily a good idea, because those dangling symlinks may belong to their respective packages. If so, removing them will compromise the integrity of the package they belong to.
I don't fully understand. Of what use is a link to nowhere?
I did what the instructions said. What you say implies that the upgrade instructions need to be revised. The instructions are here: "https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/". From past experience, I can say the Fedora doc. team wants more than a bug; they want suggested wording. What should the instructions say?
If preferred, this can be split off into a separate thread, and I can close this thread.
On 12/04/2021 04:54, home user wrote:
I wonder if it's supposed to be undisplayed and only in MATE, or was that a goof. The original poster might try filing a bug report and see what the response is.
Ed's suggestion to edit /usr/share/applications/caja.desktop worked. Should I still file a bug?
No. It is most likely they want it this way.
Now, I have a "better" suggestion.
Editing /usr/share/applications/caja.desktop is not really an optimal idea since it may get overwritten.
For a system-wide solution which doesn't get overwritten, copy /usr/share/applications/caja.desktop to /usr/local/share/applications/caja.desktop and edit that file to comment those two lines.
The file in /usr/loca/share/applications won't get overwritten by updates or system upgrades.
FWIW, I use "updates" to mean updates to applications/software at the release being run. While "upgrade" means, to me, going from F3x to F3x+N.
2021-04-11 23:02 UTC+02:00, home user mattisonw@comcast.net:
2021-04-11 6:38 UTC+02:00, home user <mattisonw(a)comcast.net>:
[...]
This isn't necessarily a good idea, because those dangling symlinks may belong to their respective packages. If so, removing them will compromise the integrity of the package they belong to.
I don't fully understand. Of what use is a link to nowhere?
Let me show you an example.
$ rpm -qV hunspell $ symlinks /usr/share/doc/hunspell/ dangling: /usr/share/doc/hunspell/README -> README.md # rm /usr/share/doc/hunspell/README $ rpm -qV hunspell missing d /usr/share/doc/hunspell/README
On Sun, 2021-04-11 at 20:46 +0000, home user wrote:
It doesn't actually work like that. Only the kernel is kept, not everything. When you pick a different entry, you're only selecting a different kernel. All the other software is the same.
Do you mean that all the other software is the same as the newest? If I do a weekly patch (dnf upgrade), and that patch includes patches to vim or firefox, and then the next day I boot into one of the older entries in the grub menu, I should get the newer firefox and vim and the the older?
Yes of course. The GRUB entry only affects the kernel, nothing else.
poc
On 4/11/21 3:03 PM, Ed Greshko wrote:
On 12/04/2021 04:54, home user wrote:
I wonder if it's supposed to be undisplayed and only in MATE, or was that a goof. The original poster might try filing a bug report and see what the response is.
Ed's suggestion to edit /usr/share/applications/caja.desktop worked. Should I still file a bug?
No. It is most likely they want it this way.
ok, no bug.
Now, I have a "better" suggestion.
Editing /usr/share/applications/caja.desktop is not really an optimal idea since it may get overwritten.
For a system-wide solution which doesn't get overwritten, copy /usr/share/applications/caja.desktop to /usr/local/share/applications/caja.desktop and edit that file to comment those two lines.
The file in /usr/loca/share/applications won't get overwritten by updates or system upgrades.
done. tested (after re-boot). works. Thank-you, Ed.
On Mon, 2021-04-12 at 05:03 +0800, Ed Greshko wrote:
It is most likely they want it this way.
I have to wonder how they expected you to browse the file system if they hide the file browser.
On Sun, 2021-04-11 at 20:46 +0000, home user wrote:
Do you mean that all the other software is the same as the newest? If I do a weekly patch (dnf upgrade), and that patch includes patches to vim or firefox, and then the next day I boot into one of the older entries in the grub menu, I should get the newer firefox and vim and the the older?
When you do an update, almost all software is updated by replacing the old with the new (whether that's done from a patch that just updates the bits that needs updating, or a whole package that does everything).
There are a few things, such as the kernel, where an update installs the new version in addition to the old version. At boot time, you get to pick which kernel you'll boot from. This will also include drivers built into the kernel.
What doesn't change, though, are user settings. Any program that stores its settings in your homespace is unaffected by RPM updates. Your configurations carry over. However, some applications change their configuration format over time, and when the application is run, it may update its own configuration files. It's similar with system configuration modifications you've made that are stored in /etc.
This is why (unlike windows) reinstalling something that isn't working right rarely makes anything different in Linux. If the problem was due to a bad configuration, you're back at square one. The only time reinstalling ought to make any difference is when there's something wrong with one of the installed files (e.g. corruption, or you've erroneously removed an ancillary file).
On 12/04/2021 12:59, Tim via users wrote:
On Mon, 2021-04-12 at 05:03 +0800, Ed Greshko wrote:
It is most likely they want it this way.
I have to wonder how they expected you to browse the file system if they hide the file browser.
They expect you to use the file browser of the desktop you're using.
mate=caja kde=dolphin
etc...
On 4/11/21 11:07 PM, Tim via users wrote:
On Sun, 2021-04-11 at 20:46 +0000, home user wrote:
Do you mean that all the other software is the same as the newest? If I do a weekly patch (dnf upgrade), and that patch includes patches to vim or firefox, and then the next day I boot into one of the older entries in the grub menu, I should get the newer firefox and vim and the the older?
When you do an update, almost all software is updated by replacing the old with the new (whether that's done from a patch that just updates the bits that needs updating, or a whole package that does everything).
There are a few things, such as the kernel, where an update installs the new version in addition to the old version. At boot time, you get to pick which kernel you'll boot from. This will also include drivers built into the kernel.
What doesn't change, though, are user settings. Any program that stores its settings in your homespace is unaffected by RPM updates. Your configurations carry over. However, some applications change their configuration format over time, and when the application is run, it may update its own configuration files. It's similar with system configuration modifications you've made that are stored in /etc.
This is why (unlike windows) reinstalling something that isn't working right rarely makes anything different in Linux. If the problem was due to a bad configuration, you're back at square one. The only time reinstalling ought to make any difference is when there's something wrong with one of the installed files (e.g. corruption, or you've erroneously removed an ancillary file).
Now I understand better. Thank-you, Ed.
On 4/11/21 3:46 PM, Andras Simon wrote:
2021-04-11 23:02 UTC+02:00, home user mattisonw@comcast.net:
2021-04-11 6:38 UTC+02:00, home user <mattisonw(a)comcast.net>:
[...]
This isn't necessarily a good idea, because those dangling symlinks may belong to their respective packages. If so, removing them will compromise the integrity of the package they belong to.
I don't fully understand. Of what use is a link to nowhere?
Let me show you an example.
$ rpm -qV hunspell $ symlinks /usr/share/doc/hunspell/ dangling: /usr/share/doc/hunspell/README -> README.md # rm /usr/share/doc/hunspell/README $ rpm -qV hunspell missing d /usr/share/doc/hunspell/README
I've started a new thread "dangling symlinks and upgrades" to continue this.
On 4/8/21 1:51 PM, home user wrote:
(f33; gnome)
I just finished upgrading from f32 to f33.
When I click the gnome "Activities", I no longer see "caja". When I use the gnome activities search thing, it does not find "caja". But dnf shows it installed and up-to-date. Before today's update, caja was easily available through the gnome Activities. How do I get caja back into the gnome Activities, and visible to the gnome Activities search?
Thank-you in advance. Bill.
Ed's "better" suggestion in his April 11, 3:03 PM US Mountain time post works. So I'm marking this thread SOLVED. I thank all who tried to help.
Bill.
On Mon, 2021-04-12 at 14:37 +0930, Tim via users wrote:
What doesn't change, though, are user settings. Any program that stores its settings in your homespace is unaffected by RPM updates. Your configurations carry over. However, some applications change their configuration format over time, and when the application is run, it may update its own configuration files. It's similar with system configuration modifications you've made that are stored in /etc.
Supplemental info: Config files stored in /etc are similar in that they're separate from the application, and unlikely to be removed by a package install or removal, but there are other differences.
Most applications store per-user settings, and those files are in the user's home space. Few applications have system-wide configurations that are stored in /etc.
Applications don't always provide you with a way to modify configuration files in /etc (e.g. you hand-edit configuration files for Apache).
If you modify their /etc configuration files, your modifications are supposed to stay in place if there's any application update. It'll add a .rpmnew file with the latest version's default configuration file, this is for you to manage any changes to your configuration files.
It's possible for an application upgrade to move your old /etc configuration files into a .rpmsave file, as a back-up, and the new update to be the default configuration file.
On 4/13/21 5:02 AM, Tim via users wrote:
On Mon, 2021-04-12 at 14:37 +0930, Tim via users wrote:
What doesn't change, though, are user settings. Any program that stores its settings in your homespace is unaffected by RPM updates. Your configurations carry over. However, some applications change their configuration format over time, and when the application is run, it may update its own configuration files. It's similar with system configuration modifications you've made that are stored in /etc.
Supplemental info: Config files stored in /etc are similar in that they're separate from the application, and unlikely to be removed by a package install or removal, but there are other differences.
Most applications store per-user settings, and those files are in the user's home space. Few applications have system-wide configurations that are stored in /etc.
Applications don't always provide you with a way to modify configuration files in /etc (e.g. you hand-edit configuration files for Apache).
If you modify their /etc configuration files, your modifications are supposed to stay in place if there's any application update. It'll add a .rpmnew file with the latest version's default configuration file, this is for you to manage any changes to your configuration files.
It's possible for an application upgrade to move your old /etc configuration files into a .rpmsave file, as a back-up, and the new update to be the default configuration file.
I do sometimes notice those during my weekly patching, but never really paid attention to them. Now I know what those are.
Thank-you.
-
Andras Simon -
Ed Greshko -
home user -
Joe Zeff -
Patrick O'Callaghan -
Samuel Sieb -
Tim