2:51 p.m.
(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.
8:05 p.m.
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.
--
Remind me to ignore comments which aren't germane to the thread.
10:38 p.m.
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.
--
Remind me to ignore comments which aren't germane to the thread.
11:38 p.m.
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.
12:22 a.m.
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.
3:46 p.m.
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?
4:56 p.m.
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
12:07 a.m.
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).
--
uname -rsvp
Linux 3.10.0-1160.21.1.el7.x86_64 #1 SMP Tue Mar 16 18:28:22 UTC 2021 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.
12:13 p.m.
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.
6:02 a.m.
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.
--
uname -rsvp
Linux 3.10.0-1160.21.1.el7.x86_64 #1 SMP Tue Mar 16 18:28:22 UTC 2021 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.
12:19 p.m.
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.
2:03 a.m.
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.
--
Remind me to ignore comments which aren't germane to the thread.
3:47 p.m.
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.
4:29 a.m.
2021-04-11 6:38 UTC+02:00, home user <mattisonw(a)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.
4:02 p.m.
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.
4:46 p.m.
2021-04-11 23:02 UTC+02:00, home user <mattisonw(a)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
12:14 p.m.
On 4/11/21 3:46 PM, Andras Simon wrote:
2021-04-11 23:02 UTC+02:00, home user <mattisonw(a)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.
12:36 a.m.
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).
--
uname -rsvp
Linux 3.10.0-1160.21.1.el7.x86_64 #1 SMP Tue Mar 16 18:28:22 UTC 2021 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.
2:47 a.m.
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.
--
Remind me to ignore comments which aren't germane to the thread.
3:05 a.m.
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.
4:03 p.m.
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.
--
Remind me to ignore comments which aren't germane to the thread.
5:52 p.m.
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.
11:59 p.m.
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.
--
uname -rsvp
Linux 3.10.0-1160.21.1.el7.x86_64 #1 SMP Tue Mar 16 18:28:22 UTC 2021 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.
12:37 a.m.
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...
--
Remind me to ignore comments which aren't germane to the thread.
3:53 a.m.
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.
3:49 p.m.
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!
12:19 p.m.
New subject: invisible application after upgrade. [SOLVED]
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.
1102
days inactive
1107
days old
29 comments
7 participants
participants (7)
-
Andras Simon -
Ed Greshko -
home user -
Joe Zeff -
Patrick O'Callaghan -
Samuel Sieb -
Tim