** Changed in: gnome-system-tools (Ubuntu)
Importance: Undecided = Wishlist
** Changed in: gnome-system-tools (Ubuntu)
Status: Confirmed = Triaged
--
in users-admin the name 'root' is checked instead of uid 0
https://bugs.launchpad.net/bugs/255980
You received this bug notification
In 2.29.2 we hide root, and don't allow the last admin to be removed. If
user is about to lose its own admin rights, we warn him. For home
directory, there will be more improvements to come, like making user the
owner of the dir.
** Also affects: gst
Importance: Undecided
Status: New
** Summary changed:
- Unexpected display of /etc/group nfs entry in the user setting interface.
+ [users-admin] Unexpected display of /etc/group NIS entry
--
[users-admin] Unexpected display of /etc/group NIS entry
https://bugs.launchpad.net/bugs/107422
You received this bug notification
Confirmed for the power menu part. But you can choose language (Alt+L)
and log in right after, just type the password and hit Return.
** Summary changed:
- karmic gnome login requires mouse
+ Can't access GDM's power menu with keyboard
** Package changed: gnome-system-tools (Ubuntu) = gdm
Good catch indeed! That's the button used to change password when the
selected user is the current one. Does the bug appear only with that
user? In other cases, it should be hidden.
Anyway, this hack should go away in the next release, with a more
generic dialog from upstream.
--
Users-admin
/usr/share/system-tools-backends-2.0/scripts/SystemToolsBackends.pl -m U$
This is a bad copy/paste: U$ can't work, obviously, that should be UsersConfig.
/usr/sbin/system-tools-backends
Should be /usr/bin/system-tools-backends in 8.04.
Anyway, you don't need to run those to perform the test I
Chris, you said you were able to reproduce the problem too? So that
wouldn't be specific to the reporter's configuration... I'm absolutely
not able to see this, maybe I'll have to get the package form Lucid.
--
Users-admin password-password confirm requires 2 Tab keys
OK, sorry for the delay Roger. So if I understand correctly, the only
way to reproduce this problem is to create a new user when the users
list appears empty? That would be logical, since we commit the data we
have, which would be empty if it could not be loaded.
But do you mean that the second
This Debian bug is not related at all.
** Changed in: debian
Importance: Unknown = Undecided
** Changed in: debian
Status: Fix Released = New
** Changed in: debian
Remote watch: Debian Bug tracker #470123 = None
** Changed in: debian
Status: New = Invalid
** Also affects:
What I asked Xande to test should be interesting for you too:
One interesting test (for both of you) would be to start the scripts before
starting users-admin, and to compare the startup times: start users-admin once,
run it again and see the time it needs, then wait for 5 minutes so that the
Thanks for your report. Actually, you're not using network-admin from
the gnome-network-admin package, but network-manager. Reassigning.
I think you should tell us what kind of encryption is using your
network: WEP or WPA? And what type of password authentication too.
** Package changed:
Good news, I've just finished a future patch that allows us to stop
creating the main group ourselves. When creating an user, the backends
can now omit the --gid option, and we let adduser (and equivalents) do
the work. This is simpler for everyone. Should be in the next release.
Now I need to
** Changed in: gst
Status: Fix Committed = Fix Released
--
[network-admin] Modem connection types not listed
https://bugs.launchpad.net/bugs/485641
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gnome-system-tools in ubuntu.
--
If you are willing to help debugging this, then please run 'sudo ntpd
-q' and report its output, and whether that fixes the problem. Is your
clock highly different from the real hour, i.e. by hours as the title of
the bug says?
--
[jaunty] Synchronizing with a time server does not work when time
ceciliavergara: Please don't open new tasks against upstream projects
without any explanation. Why do you think this bug is still valid? I've
just tried to reproduce it, and it seems be fixed.
** Changed in: gst
Status: New = Invalid
--
[network-admin] Gtk-WARNING **: Unknown property:
So by first time you mean first time from fresh boot; there's no
package installation involved then. I think you're slightly wrong about
memory usage, because the fact that every SystemToolsBackends perl
process uses 10MB doesn't mean you can sum up those values to get the
total: there's shared
In Karmic, I can confirm that the -m Platform script does not die after
3 minutes, consuming 10MB until reboot. I'll give a look at this
problem.
Though, you mention in the description that there's a 90MB usage on
first launch. I guess this comes from the package installation, isn't
it? If that
Pjotr12345: please report your problem separately against the package
'passwd', this has nothing to do with the present bug. BTW, when
changing your own password, you should use 'passwd' instead of 'sudo
passwd'. The latter won't update your eCryptfs Private dir and your main
keyring password.
It's not unlikely that users-admin itself has introduced those broken
settings, but we can't really be sure. I'd need a list of all programs
that may change this file (maybe there aren't at all). But that doesn't
mean there isn't something broken here. I've checked our code, and
everything seems
*** This bug is a duplicate of bug 210710 ***
https://bugs.launchpad.net/bugs/210710
Hmm, seems a duplicate of bug 210710. Please follow the instructions I
gave in my latest comment there, and I'll have a look. So far, your
/etc/passwd file looks right to me. And AFAICT the root account is
You could just try changing in /etc/login.defs
UID_MAX 6
I think that should do the trick. Then it would mean the bug is in the
program that set this value...
--
System Admin Users and Groups: only root available
https://bugs.launchpad.net/bugs/210710
You received this bug notification
Could you follow the procedure at
https://wiki.ubuntu.com/DebuggingGnomeSystemTools#For%20Users%20[users-
admin] to provide more information? This way we would be able to find
out what's going on. Thanks!
** Changed in: gnome-system-tools (Ubuntu)
Status: Incomplete = Confirmed
** Changed
** Changed in: gnome-system-tools (Ubuntu)
Status: Incomplete = Fix Released
--
[hardy] Unlock button not in dialog
https://bugs.launchpad.net/bugs/245809
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is a bug assignee.
--
desktop-bugs mailing
Thanks for your report. This was indeed a silly detail that I've just
fixed. It will be available in the next minor release.
Please continue to report bugs about the gnome-system-tools, especially
the next version that should land in Lucid in a month or so. Not many
people do this, which makes
If it's just for reviewing purposes, the only changes I added are in:
about_me_path = g_find_program_in_path (gnome-about-me);
show_passwd = (user != oobs_self_config_get_user
(OOBS_SELF_CONFIG
(GST_USERS_TOOL
The rationale behind this feature vs. the standard nullok_secure way is
that *you actually have a password*. This means users can be admins,
type their password to use sudo, PolicyKit or lock their screen, but
they are not asked to type it on login. They can additionally connect
over local SSH for
jxparo: are you sure you are in Manual mode? I've reinstalled the gnome-
system-tools and I can still see this button in this mode. And I don't
see the patch that used to hide it in Ubuntu.
--
time-admin does not update time
https://bugs.launchpad.net/bugs/400130
You received this bug
I've no personal problem with that, but if we don't respect what we
write on the Wiki, we may as well change it instead of using
inconsistent statuses. Don't worry about the wrong upstream status for
that, I always go over all bugs registered in the GNOME System Tools
Launchpad project (i.e. for
That's tightly related to bug 484559. If you don't mind losing the
improvement brought by fixing bug 307019, I think you can commit the
debdiff that is available on the former. Anyway the goal is to get rid
of this hack and do all the work right by ourselves, i.e. without
dependencies.
--
This is not committed in Ubuntu. It's committed upstream, waiting for a
release upstream (2.29.2) to be committed on Ubuntu's Baazar repository,
and then released in Lucid. See https://wiki.ubuntu.com/Bugs/Status.
Thanks for helping, though! ;-)
** Changed in: gnome-system-tools (Ubuntu)
I think we could add this option to the new Advanced Settings dialog,
but we won't move home dir and other things: just rename the user in
/etc/passwd. Not sure our architecture allows for this easily.
** Changed in: gnome-system-tools (Ubuntu)
Status: Confirmed = Triaged
--
Can not
Any trace of this bug in Karmic (or at least Jaunty)? I really can't
afford going through our code in Hardy to check where this was coming
from, we have already enough bugs to tackle in recent versions. The
trace upstream is too old, I'll have to close the report there without
more information.
Sorry, it's been a long time since you reported this bug. Sadly, we need
more information to work on it. The chances are low we can actually do
anything about it, since it's kind of late to get the details... :-(
First, did it happen after you had changed user settings via
Development version upstream has a GConf option to show root, which
means its hidden by default.
** Also affects: gst
Importance: Undecided
Status: New
** Changed in: gst
Status: New = Fix Committed
** Changed in: gnome-system-tools (Ubuntu)
Status: Confirmed = Triaged
Thanks for your report. Could you report each problem separately?
There's absolutely no chance that a developer will try to fix all those
bugs at once, you're discouraging people from reading your report. And
feature requests such as please write a GUI for XXX are completely
useless: we know this
Thanks for your report. I'm not able to reproduce your problem. Can you
confirm it still exists in Karmic? Thanks!
** Changed in: gnome-system-tools (Ubuntu)
Importance: Undecided = Medium
** Changed in: gnome-system-tools (Ubuntu)
Status: New = Incomplete
--
[users-admin] adding new
That's a problem with the installer that does not add the user to all
the privilege groups used in Ubuntu. Have a look at /etc/gnome-system-
tools/profiles for a list of them.
** Package changed: gnome-system-tools (Ubuntu) = user-setup (Ubuntu)
** Changed in: user-setup (Ubuntu)
Importance:
** Package changed: gnome-system-tools (Ubuntu) = network-manager
(Ubuntu)
--
Network manager deletes eth1 default gw when eth0 has Static IP
https://bugs.launchpad.net/bugs/223575
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to
Fixed in Karmic AFAICS.
** Package changed: gnome-system-tools (Ubuntu) = language-selector
(Ubuntu)
** Changed in: language-selector (Ubuntu)
Importance: Undecided = Low
** Changed in: language-selector (Ubuntu)
Status: New = Fix Released
--
[intrepid][gnome-language-support]
Thanks for your report. I think the problem you describe is an intended
feature: developers upstream have considered this option was not useful
for enough users, and it makes our control center more complex for
everyone.
Though, you can start 'gconf-editor' and tune the key
** Package changed: gnome-system-tools (Ubuntu) = human-theme (Ubuntu)
--
Bug in human-theme_0.18_all.deb prevents upgrade
https://bugs.launchpad.net/bugs/222330
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gnome-system-tools in
Oh, sorry, your problem wasn't clear to me. I'm not very familiar with
gnome-network-properties, since it's not actually part of the gnome-
system-tools, as you originally reported it (I know, it's confusing...).
So the issue is that you are using different proxies for various
protocols, the
I'd avise you to report that upstream before you start working on it.
It's possible that the problem is known, maybe even already fixed.
Unfortunately, bugzilla.gnome.org is down for the week-end... Maybe it
would be worth waiting monday - that's up to you. Else, sure, you can
attach the patch
Thanks for your report. I don't think the problem you describe is a bug,
rather an intended feature. There's no Cancel button: you can't close it
without applying the changes you've performed, because they are applied
on the go. I don't see how this behavior could hurt anybody: you can
always
*** This bug is a duplicate of bug 393854 ***
https://bugs.launchpad.net/bugs/393854
David: what's your problem exactly? You can set up a password for root
in Karmic too, it's just that PolicyKit won't allow you to enter the
root password to authenticate. I fail to see how upgrading from
Development version 2.29.1 contains the fix for the GID is 0 on start
problem, and also prevents you from choosing already used GIDs when
creating/editing groups.
** Changed in: gst
Status: Fix Committed = Fix Released
--
[users-admin] Group Properties dialog sets GID to 0 on first
Hm, silly: the latter is actually not in 2.29.1, but will be in the next
release. Anyway, that's for Lucid.
--
[users-admin] Group Properties dialog sets GID to 0 on first launch
https://bugs.launchpad.net/bugs/475974
You received this bug notification because you are a member of Ubuntu
Desktop
This is now fixed upstream. Since deluser does not remove active users,
we simply refuse to delete them, showing a dialog: John Doe is
currently using this computer. Please ensure the user has logged out
before deleting this account.
Feel free to suggest a better formulation if you find one...
This is now fixed upstream, will be included in 2.29.2.
** Also affects: gst
Importance: Undecided
Status: New
** Changed in: gst
Status: New = Fix Committed
--
users-admin fakes adding groups with existing gid
https://bugs.launchpad.net/bugs/491434
You received this bug
That won't happen, as explained by Chris in the previous comment. It's
far too late now, that will be for Lucid.
--
System Administration Services (services-admin) missing (Karmic)
https://bugs.launchpad.net/bugs/437905
You received this bug notification because you are a member of Ubuntu
Are people actually watching liboobs development?! ;-)
I've tried using before, but I was getting strange results because when
converting the constant value to signed int, something was going wrong and I
was getting -GMAX_INT32. I've tried again with your solution, and that does not
work
*** This bug is a duplicate of bug 490093 ***
https://bugs.launchpad.net/bugs/490093
Yeah, that was a little hard to find, but that's actually bug 490093,
which was spotted recently. The problem is that we're starting another
tool (about-me) to change the password, and that when you have
Hmm... Charlie, I did not notice your step:
3. enter sudo passwd expiry USER1
Is there a specific reason why you didn't use the standard 'passwd' command?
Could you post the log when using it? Don't even use 'sudo passwd', as it
doesn't work the same way. Does it work then?
Anyway, the
That doesn't work because you're passing the '-e' option, which means:
mark the password for expiration to force the user changing it on next
login. That operation requires admin rights. BUT please simply use
'passwd', without anything else.
(This is the best way of changing passwords in the
That's not a workaround, that's the normal procedure. Why would you use
'passwd -e' in the first place, if you want ot change your own password?
The only bug I can see here is that PolicyKit should allow users to
authenticate even if their password is marked for expiration until they
log change
** Bug watch added: freedesktop.org Bugzilla #25461
https://bugs.freedesktop.org/show_bug.cgi?id=25461
** Also affects: policykit via
https://bugs.freedesktop.org/show_bug.cgi?id=25461
Importance: Unknown
Status: Unknown
--
Changing your password does not allow admin
OK, I've just committed a fix that allows IDs to be handled correctly as
long as they don't go beyond G_MAXINT32 when the system supports it,
which means on Ubuntu you can go up to 2,147,483,647. I guess that's
enough for most people, but I'll see if we can guarantee we support the
full range for
** Changed in: system-tools-backends (Ubuntu)
Status: Confirmed = Triaged
--
ecryptfs Private directory not mounted after changing password in users-admin
https://bugs.launchpad.net/bugs/307019
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is
Please don't bother installing Jaunty - if that's failing in Karmic,
that's enough for me. So to sum up, it seems that both PolicyKit and
gksu authentications fail. Does a simple sudo echo test works? I guess
not, but I'd like to be sure. A log that you could also post here is
/var/log/auth.log
** Bug watch added: GNOME Bug Tracker #602110
https://bugzilla.gnome.org/show_bug.cgi?id=602110
** Also affects: gst via
https://bugzilla.gnome.org/show_bug.cgi?id=602110
Importance: Unknown
Status: Unknown
--
No easy way to make passwordless account
Thanks for the report, I agree the present situation is not optimal. But
don' t believe we wan't to fix this because password-less accounts are
unsecure, and we don't want to encourage users to work as in Windows. If
you want to perform administrative tasks, having a password is
essential.
OTOH,
** Changed in: gdm (Ubuntu)
Status: Confirmed = Triaged
--
Update PAM policy to allow password-less logins set up via users-admin
https://bugs.launchpad.net/bugs/393854
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gdm in
So thanks for providing the details now. This bug was not Triaged, it
was merely Confirmed. Sure, you had in mind the details, but nobody else
did. So, what was not mentioned in the report or the comments is:
changing your password does not allow you to authenticate via sudo.
You're really not
** This bug is no longer a duplicate of bug 315002
Changing your password does not take effect before session is restarted
--
Administer the system for new user requires reboot
https://bugs.launchpad.net/bugs/418337
You received this bug notification because you are a member of Ubuntu
Desktop
Sorry, it was not clear to me whether your report was a duplicate or
not, partly because I didn't have much information about the other
report. So yours is about the fact that new administrator users cannot
authenticate until the computer is rebooted. That may well come from the
same problem as
Do you have any idea of were this problem comes from? Are you able to
reproduce it in Karmic? I'm not able to reproduce the problem here, so
I'd need somebody to answer these questions. In particular, whether this
also happens when changing password using 'passwd', rather than using
users-admin.
Again... Tricky issue. Considering the precise bug you found, it comes
from the fact that the max [GU]ID was statically defined as 65,535. I'll
fix that easily, but I lack a generic way of detecting the actual system
maximum for gid_t. I guess I've found a hack that will work, though.
That will be
Yeah, that's bug 484559. But does changing your password from the
console using 'passwd' bring the same bug as the present report
describes? If that's the case, that's a bug in PAM or sudo, and we
should move it if we want it to be fixed some day.
--
Changing your password does not take effect
Sadly gdb doesn't seem to find the source file, which does not allow us
to get details about the crash. From what I see in the code, we could
crash if libhal returns an array without telling us its real size. We
could check that the code in libhal is not buggy in that regard, but
anyway HAL is now
OK, I've finally found http://bugs.gentoo.org/278760 which explains that
libhal returns NULL when no devices are found, not even setting the
number of devices to 0. So we should check that before trying to add
them to our internal list.
I don't know why shares-admin needs the list of network
Here's a patch that you can apply against the liboobs package if you
want to check that it works. It seems to work here, but I never get the
crash, even if the error was set.
** Package changed: gnome-system-tools (Ubuntu) = liboobs (Ubuntu)
** Changed in: liboobs (Ubuntu)
Status: Triaged
Yeah, that's already been spotted several times. See bug 475974 for the
GID = 0 issue.
I'll fix that for the next release.
** Changed in: gnome-system-tools (Ubuntu)
Importance: Undecided = Medium
** Changed in: gnome-system-tools (Ubuntu)
Status: New = Triaged
--
users-admin fakes
** Changed in: gnome-system-tools (Ubuntu)
Status: Confirmed = Triaged
--
[users-admin] Group Properties dialog sets GID to 0 on first launch
https://bugs.launchpad.net/bugs/475974
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to
Closing because of lack of information. I'll try to make this kind of
bug impossible in the next release by redesigning the way we commit
changes to the system, so this should disappear anyway.
** Changed in: gnome-system-tools (Ubuntu)
Status: Incomplete = Invalid
--
user privileges
wierdlmate: You're not the original reporter, are you? The problem you
describe seems to be linked with bug 490093. Please comment on that bug,
not here - are you able to change your password from the console using
'passwd'?
Closing this report by lack of feedback since august. Please reopen if
About the hang problem: do you get the hang even when the new password
is completely different from the old one? I thought we were always using
strong encryption methods that did not have the problem you describe
(which occurred when using 3DES).
** Summary changed:
- Cannot change password with
Charlie Kravetz: You said you were able to reproduce the bug. Could you
give me details on that? I can keep it open indefinitely, but that won't
help, while cluttering my TODO list. I don't think your policy is to
keep reports open disregarding the fact that we can't reproduce them.
There have
Thanks for your report. I'd need more debugging to find the precise line that
triggers the crash, since the stacktrace seems to have changed the line numbers
a bit. Could you install debug package from [1] and run shared-admin in gdb?
The procedure is:
gdb shares-admin
[crash]
ba
q
And then
Ah, from your description I thought was occurring all the time. So I'm
forced to close the report, since the stacktrace we have is very
strange: the reported line is not in the function it's said to be, and I
am to believe the line number, I can't really find what could have lead
to a crash, apart
Interesting! Could you simply try the steps I described in my first
comment? We must find out what's going on before reporting this against
HAL. I may well be that liboobs is doing something bad here.
** Changed in: gnome-system-tools (Ubuntu)
Status: Invalid = Incomplete
** Summary
Now I can see what's the problem. You shouln't have to authenticate when
closing the first dialog. If it does so, that's because it wants to
commit your user configuration - and since there are two separate
programs here, the first one (users-admin) overwrites the changes that
were made since it
Yeah, that's not completely trivial, that's why I don't say you: OK,
I'll fix that in two hours for the next release. I'm not sure I'll have
the time to try implementing this for Lucid.
perl is not very hard to understand when you have priori knowledge of C
or another similar language. You'd need
Thales MG: If it's *your* password that you can't change, then the
problem is not the really in the gnome-system-tools, since they start
the About Me program to do that. Could you try to change your password
using that program (from System-Preferences), and if that fails report
a bug against that
Do you think you could try to implement the support for adduser profiles
in the system-tools-backends? I'm currently reworking the D-Bus
protocol, so it would be the time to make these changes if we want. They
are written in perl.
--
users-admin profiles default to force [GU]ID, home dir, shell
I fail to see why it would be a problem with the gst. Wouldn't a line in
/etc/adduser.conf be enough? Even if we handle profiles manually, that
won't prevent new users from being added to the users group if adduser
wants to.
** Package changed: gnome-system-tools (Ubuntu) = adduser (Ubuntu)
**
Sure, that would make sense. But that's not really high priority to me,
as most people won't tweak the group settings without knowing how this
works. Maybe one day...
--
users-admin should leave adduser handle main group creation
https://bugs.launchpad.net/bugs/488158
You received this bug
** Changed in: gnome-system-tools (Ubuntu)
Status: Confirmed = Triaged
** Changed in: gnome-system-tools (Ubuntu)
Importance: Undecided = Low
--
Fix sort order in Group Settings.
https://bugs.launchpad.net/bugs/477324
You received this bug notification because you are a member of
Could you open a new report against the gnome-system-tools? I'd like to
investigate this further.
--
[users-admin] Modifying user has no effect
https://bugs.launchpad.net/bugs/463353
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to
How funny: you linked the wiki spec to the blueprint I had written a few
years ago, without knowing how to implement it precisely.
The information from the wiki page would be nice to show from users-
admin's help, but 1) our help is pretty outdated now, we should rewrite
it from scratch using
Actually, now that I think of it, we can't avoid forcing the UID because
we implement user profiles in users-admin. Those allow the
distribution/admin to present users with typical account types, which
set sensible default values for home dir, shell, groups membership (esp.
admin), and UID.
It's
I'll use this bug to track the issue of not adding users to their main
groups. I should be able to fix this soon.
** Changed in: gnome-system-tools (Ubuntu)
Status: Confirmed = Triaged
--
users-admin should leave adduser handle main group creation
https://bugs.launchpad.net/bugs/488158
Maybe I should precise that [GU]ID ranges set in /etc/adduser.conf are
still honored, it's only that users-admin chooses the ID itself in that
range. So no real problem in that regard. We should just allow profiles
not to be used if wanted.
(About services form adduser.local.conf, they don't seem
Funny way of reporting a bug... How can you suspect there's a problem if
you don't know whether adduser/deluser are used? ;-)
Can you explain the differences you've spotted with adduser? I'm aware
of a few issues that we'd like to fix for the next release, namely that
we set the password using
Yeah, let's close it since no answer from the reported has happened in
more than a year. Anyway, this would require a large rework that nobody
will do. Moving to NetworkManager is the only solution.
** Changed in: gnome-system-tools (Ubuntu)
Status: Incomplete = Invalid
--
network
Seriously, exactly as you write I was seeing the user being added to his
primary private group.
adduser tester produces this group entry: tester:x:1006:
where users-admin produced: test:x:1005:test
So I'm happy to find somebody knowing what we should do. I've reported bug
545714 [1] in
Thanks. So that's a bug with dhclient, I hope somebody more aware of its
behavior will be able to help.
** Package changed: gnome-system-tools (Ubuntu) = dhcp3 (Ubuntu)
** Changed in: dhcp3 (Ubuntu)
Status: Incomplete = Confirmed
--
/etc/resolv.conf inserts commas between Search Domains
James: Hmm... For some reason I've received only now the mail with your
above comment, which I've completely missed when posting and working on
the patch.
Anyway, AFAICS there's still a problem with depending on gnome-about-me:
it's in the gnome-control-center package, which would pull in gnome-
Rationale for SRU: this bug prevents people from setting up PPP
connections. network-admin is not included on the default install, but
it's really useful for users with traditional modems (not sure
ModemManager works in every case). The fix has been committed upstream
and only adds a
I got it: the combo box is always empty because there's no cell renderer
in it. Quite astonishing that you're the first to report this problem!
;-)
** Changed in: gnome-system-tools (Ubuntu)
Importance: Low = High
** Changed in: gnome-system-tools (Ubuntu)
Status: Incomplete =
And the fix is at
1:
http://git.gnome.org/cgit/gnome-system-tools/commit/?id=ffac0be4b5f1636a03990b8dc4416ed792f20cc4
** Summary changed:
- unable to find settings for modem conection
+ [network-admin] Modem connection types not listed
** Changed in: gnome-system-tools (Ubuntu)
Status:
801 - 900 of 1345 matches
Mail list logo
