*** This bug is a duplicate of bug 400830 ***
https://bugs.launchpad.net/bugs/400830
This is not a duplicate. 400830 has to do with creating a new folder
of the same name, which WILL also be shared (although it shouldn't
be). This bug has to do with renaming an existing folder, which WILL
NOT
Public bug reported:
Binary package hint: nautilus-share
What happens:
Renaming a shared folder from Nautilus stops the file from being shared
but keeps the sharing emblem.
What I expected to happen:
If you rename a shared folder, from either within Nautilus or from any
other program, it shoul
Public bug reported:
Binary package hint: nautilus-share
nautilus-share only allows two ways to access a given shared folder:
either as a guest (with no password) or with the credentials of the
owner of the folder. This is a problem. The user should be able to share
a folder with an arbitrary use
I assume that this is still a problem, as the libdeskbar-tracker package
is apparently unavailable on the amd64 platform on an up-to-date Jaunty
system. Synatpic, aptitude, and apt-get simply report that it doesn't
exist, while it installs fine for i386. This seems odd, since it is in
Python and sh
This is apparently due to the fact that this file is missing under
Karmic:
/etc/X11/Xsession.d/55gnome-session_gnomerc
Under Jaunty, it was present, and had the following content:
# If we are running the GNOME session, source ~/.gnomerc
BASESTARTUP=`basename "$STARTUP" | cut -d\ -f1`
if [ "$BA
** Attachment added: "Dependencies.txt"
http://launchpadlibrarian.net/29202584/Dependencies.txt
** Attachment added: "ProcMaps.txt"
http://launchpadlibrarian.net/29202585/ProcMaps.txt
** Attachment added: "ProcStatus.txt"
http://launchpadlibrarian.net/29202586/ProcStatus.txt
--
.gnome
Public bug reported:
Binary package hint: gnome
GNOME under Karmic apparently ignores my .gnomerc file. With Jaunty, the
contents of my .gnomerc were
executed during login, which was a handy way to start stuff; certainly more
convenient than the Startup Programs control panel. This no longer wo
Update:
It seems that the /etc/devfs/conf.d/ directory isn't used by anyone at
all (at least not my system) and therefore /etc/devfs/conf.d/tpb has no
effect. How did it even get into the release? From what I can tell (and
I repeat that I'm very new at this and welcome correction) the Ubuntish
way
Hi. I believe this change doesn't make any sense. At this point, I'm not
sure if I should put this comment here or in a separate bug. I'm new to
LaunchPad, but I'll tell you what I've discovered:
1. Adding the call to tpb in the init.d script still won't load tpb. I
believe this is because it's an
Hi. I believe this change doesn't make any sense. At this point, I'm not
sure if I should put this comment here or in a separate bug. I'm new to
LaunchPad, but I'll tell you what I've discovered:
1. Adding the call to tpb in the init.d script still won't load tpb. I
believe this is because it's an
10 matches
Mail list logo
