Hey, thanks for the patch, but we needed a little more than that to make
the file translated: Makefile.am had to be changed too, that was a
little tricky. See http://git.gnome.org/browse/gnome-system-
tools/commit/?id=4b3806048a0e0913b78615c85db6c43853151d1f.
Feel free to suggest other patches in
Thanks for the report, but in 2.29.2 (in Lucid) we don't allow selecting
any other setting than Real name and login when creating and user. You
can only change the main group after that. So that bug is obsolete.
** Changed in: gnome-system-tools (Ubuntu)
Status: New = Invalid
--
This is fixed with 2.29.2.
--
[users-admin]cannot create user when the /home directory already exist
https://bugs.launchpad.net/bugs/190815
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gnome-system-tools in ubuntu.
--
desktop-bugs
Since 2.29.1 in Lucid we no longer use the unlock button, so that's
obsolete.
** Changed in: gnome-system-tools (Ubuntu)
Status: New = Fix Released
** Changed in: gnome-system-tools (Ubuntu)
Importance: Undecided = Low
--
users-admin doesn't fully update UI after unlock
No news on that bug?
** Changed in: gnome-system-tools (Ubuntu)
Importance: Undecided = Medium
** Changed in: gnome-system-tools (Ubuntu)
Status: New = Incomplete
--
Cannot unlock user priveledges.
https://bugs.launchpad.net/bugs/282065
You received this bug notification because you
Since Karmic we show all system groups by default, regardless of system
users being hidden.
** Changed in: gnome-system-tools (Ubuntu)
Importance: Undecided = Wishlist
** Changed in: gnome-system-tools (Ubuntu)
Status: New = Fix Released
--
users-admin should have a 'show all groups'
** 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
Too bad, that's generally the problem with such major bugs - they happen
only once, else we would have fixed that for a long time. As I said, I
can't happen anymore in Lucid, at least not with such harsh
consequences. For the rest (group memberships), I let you follow
progress on bug 240437 if you
Yeah, that's it. Sorry for the short comment, that was mainly a
technical note for reference when we will be able to close it after the
upload.
But don't hope for a SRU, that fix relies on a whole series of
architectural changes that are being introduced in Lucid.
--
[users-admin]cannot create
Well, we respect the settings from /etc/adduser.conf and
/etc/login.defs/. Just change the min value to 500, and you're good. We
can't guess that number for you.
--
Creating users with UID under 1000 creates account but it is hidden in GUI
https://bugs.launchpad.net/bugs/99265
You received this
If that can save you a failed attempt, you'll need liboobs 2.29.2.1 to
build gnome-system-tools. The original 2.9.2 release was broken.
--
Update gnome-system-tools, liboobs and system-tools-backends
https://bugs.launchpad.net/bugs/506365
You received this bug notification because you are a
Yeah, I thought first we might also choose a UID which would also be a
free GID. Anyway, that's fixed another way now: with the default
profiles configuration file (/etc/gnome-system-tools/user-
profiles.conf), we only force group memberships. UID, Home prefix and
shells are now determined by
Still doesn't work?
--
users-admin don't start - segmentation fault
https://bugs.launchpad.net/bugs/505902
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gnome-system-tools in ubuntu.
--
desktop-bugs mailing list
Thanks, so that's a problem with gnome-about-me.
** Package changed: gnome-system-tools (Ubuntu) = gnome-control-center
(Ubuntu)
** Changed in: gnome-control-center (Ubuntu)
Status: Incomplete = Confirmed
** Summary changed:
- [users-admin] Changing Password to different case causes
OK, so it seems there's a problem when the scripts are not running
(first and third times). Error messages from D-Bus are really not
expected, that would explain the bug.
Xande, could you reproduce that test too? I'd like to see what this
looks like in Karmic, I'm really more familiar with that
All of this is fixed with the System Tools Backends 2.9.0 and liboobs
2.29.2.
** Also affects: system-tools-backends
Importance: Undecided
Status: New
** Changed in: system-tools-backends
Status: New = Fix Released
--
problem with big uids in Users and Groups tool
Thanks! Right, that took quite a long time - I first started to think
about that about two years ago... But LTS is what matters.
lumbricus: could you open a report about the configuration bug you
describe, and post the link here? I'm not sure that will be an easy one
to fix, but better keep track
Hmm, why exactly did you file a duplicate report?
--
Can't access GDM's power menu with keyboard
https://bugs.launchpad.net/bugs/505323
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gdm in ubuntu.
--
desktop-bugs mailing list
Still not? I've rarely experienced so long periods of failure.
The .crash file was removed because it's of no use to developers until
Launchpad processes it, which is best done by sending a new report. Of
course, only when that works... Hope it comes back soon.
--
users-admin don't start -
I've updated a little the description since the feature is only
officially available in Lucid, so no need to disturb people with Karmic
issues.
I guess one way of fixing this would be, as you say, to show the options
before an user is chosen. Not sure that fits well in the code's design.
**
You will want to package directly the System Tools Backends 2.8.1 which
I have just released, they bring a few interesting fixes.
--
Update gnome-system-tools, liboobs and system-tools-backends
https://bugs.launchpad.net/bugs/506365
You received this bug notification because you are a member of
Telling us what version you're using would obviously have helped
debugging.
Anyway, this kind of behavior is not possible not in Lucid, the new
version only changes groups, and will never remove them when
creating/modifying an user. It would have been interesting to find out
what's going on, but
Actually I had a little forgotten this bug, but I've just tested it in
Karmic, and it works like a charm. Marking as fixed.
era: This bug was not really a paper cut since it required some
knowledge of how configuration is updated in time-admin. That was not
really complex once you have understood
For the record, this bug is a duplicate of bug 229169, which is fixed in
final Karmic.
--
[time-admin] must be restarted in order to use ntp, but it doesn't say so.
https://bugs.launchpad.net/bugs/11560
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is
OK, this seems to be actually NetworkManager. Can you explain precisely
with what program you configure your network card? Network tools
doesn't mean anything here, they are a set of tools to carry out
technical tests like ping, traceroute... Nothing that sets up your
network connection.
**
Regarding your comments on bug 379944: I'm not sure how Edubuntu people
work, but you're working on a fix based on the release in Karmic! In
Lucid the column headers are gone, so that can't be fixed that way.
Could you explain what's the main use case that justifies we need
sorting users? I think
*** This bug is a duplicate of bug 477324 ***
https://bugs.launchpad.net/bugs/477324
Agreed with Will. 1) is duplicate of bug 477324.
2) is fixed in Lucid since we no longer require people to unlock the dialog to
show/change settings.
3) would be a whishlist bug, which should be handled
The problem is known upstream and will be fixed at some point, hope this
can be in Lucid. Some files aren't read correctly with the current
GStreamer libs, developers upstream plan to move to decodebin2 for
metadata, which is known to fix the problem.
--
Rhythmbox tries to find a codec for a
The new users-admin is not really best designed for systems with
hundreds of users, since it takes more vertical space than the old one:
see the column on the left of the dialog at [1]. I'm not sure that's a
real problem, though. What we could do is sort users by login, and use
So if you don't have more proposals about this bug, I'll try to find the
time to sort the list by login name. Other ideas to help managing many
users are also welcome, as well as patches (this one isn't too hard)!
;-)
** Changed in: gnome-system-tools (Ubuntu)
Status: Confirmed = Triaged
I see. The backends are not really good at reporting errors to the GUI,
but we should simply block changing home dir for active users.
** Summary changed:
- users-admin lies about changing home directory
+ users-admin lies about changing home directory for active users
** Changed in:
** Changed in: gnome-system-tools (Ubuntu)
Status: Fix Released = Triaged
--
users-admin lies about changing home directory for active users
https://bugs.launchpad.net/bugs/484501
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to
Any chance you get more informations by following the procedure for
time-admin at https://wiki.ubuntu.com/DebuggingGnomeSystemTools? As I
really don't see how the gnome-system-tools could be at fault here, you
may first check that 'sudo restart ntp' doesn't trigger the same issues.
--
Computer
If you are OK to spend some time on it, you can also get traces manually:
install the package for your version and architecture from:
http://ddebs.ubuntu.com/pool/main/libo/liboobs/
And see whether the gdb trace is good, i.e. instead of lines like
#16 0x006e1cb5 in ?? ()
lines at the top are of
Oh, sorry, I thought you did because of the trace you attached.
Actually, you can simply get it the way you did in your comment #8,
using Apport, and paste it here again.
--
users-admin don't start - segmentation fault
https://bugs.launchpad.net/bugs/505902
You received this bug notification
Hmm, looks like the services are not correctly loaded, which can
actually lead to this kind of trouble. I've reproduced the problem once
here in Karmic, but I'm not able to get it in a Lucid virtual box.
Could you reproduce the bug once again, running the commands:
sudo killall /usr/bin/perl
*** This bug is a duplicate of bug 90524 ***
https://bugs.launchpad.net/bugs/90524
Thanks for the report, but this is precisely what bug 90524 is asking
about. This is relatively tricky, though.
** This bug has been marked a duplicate of bug 90524
Time-admin's synchronize now is disabled
** Summary changed:
- time settings: no warning on NTP errors
+ [time-admin] No warning on ntpdate errors
--
[time-admin] No warning on ntpdate errors
https://bugs.launchpad.net/bugs/351559
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed
No news on this bug?
** Changed in: gnome-system-tools (Ubuntu)
Status: Confirmed = Incomplete
--
time-admin does not update time
https://bugs.launchpad.net/bugs/400130
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to
Maybe we can go with the brutal solution to stop ntp, run ntpdate and
restart ntp. This is relatively easy to do from the backends. But it
seems to me that ntp should be able to handle those problems better on
its own.
** Summary changed:
- Time-admin's synchronize now is disabled
+ Time-admin's
This could be solved with the same changes as what bug 62745 requires:
stopping ntp, running ntpdate, and restarting ntp. This simply needs
some thought since the NTP backend doesn't know anything about services,
so we need to make the GUI do the work for it in tight integration.
** Changed in:
Nice! Sadly, I'm not allowed to access that report since it's marked as
Private. You may either subscribe me to it (Subscribe someone else on
the right), or make it public (if there aren't sensitive data there).
Thanks again!
--
users-admin don't start - segmentation fault
Absolutely empty? Even with the -v option? I can't believe it, I've just
checked twice here, at least there's always an init output. Just check it
manually by running
sudo /usr/share/system-tools-backends-2.0/scripts/SystemToolsBackends.pl -m
ServicesConfig -v
Anyway, the new time-admin.log
Thanks for the report. I'd like you to test the upcoming version 2.29.3
(released tonight) which should enter Lucid in some time, and confirm it
fixes the problem. The release you tested was a work in progress that
has really changed as regards password management, so there's little
point
OK, thanks for going though that painful process! Do you have an user
called jnih on your system? From the debugging I could perform, it
seems that the first argument we're passing to strcmp() is wrong, and
leads to crash while we're iterating on user jnih. If it doesn't
exist, it's likely that
That bug may very well be random, we've already seen this with the gst.
The halt is logical since the backends are stopping all services one by
one, which happens when the GUI sends them a kind of empty list.
Be careful when testing this bug, doing so in a real machine will make
your init scripts
Interesting, I was fearing that string was just random text... ;-)
Don't worry, I don't think you're private information was exposed at any
point, and now that the core dump is gone, nothing left is sensitive
data.
It doesn't seem to me the KDE4 problem is linked at all, what happens
here is
Charlie, this has nothing to do with network-admin if you say you're
using NetworkManager (but I think in Hardy it does not support static
IPs). Your comment is far to vague to be helpful as-is, I guess you
should open a new report.
Anyway, about this bug report, you should try NetworkManager in
Sorry that bug was left open for such a long time. Charlie, as I said in
the other report, your comment is not really related to a bug in
network-admin.
Could somebody tell me whether this bug happens in version more recent
than Hardy? It's really too late to fix it there anyway, but we could
See https://blueprints.launchpad.net/ecryptfs/+spec/ecryptfs-desktop-
ui/.
--
Default folders inside Home Folder (e.g. Documents, Music) should have special
icons/emblems
https://bugs.launchpad.net/bugs/126103
You received this bug notification because you are a member of Ubuntu
Desktop Bugs,
I think I'm going to fix this the right way instead of wasting time to
find the precise cause of this bug. We shouldn't commit changes to all
scripts each time we change one of them, here ntp. That won't enter
Lucid before GNOME 2.29.90, but that should definitely prevent this mess
to happen.
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-
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
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
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
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
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
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
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
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
** 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
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
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
*** 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
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
801 - 900 of 1655 matches
Mail list logo