accountsservice issueshttps://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues2024-02-28T00:06:45Zhttps://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/124Segfault in `daemon_local_set_automatic_login` when trying to enable automati...2024-02-28T00:06:45ZMohammed AnasSegfault in `daemon_local_set_automatic_login` when trying to enable automatic login if no DM is detectedI'm using GNOME on Chimera Linux, and trying to enable automatic login from the Settings app causes `accountsservice` 23.13.9 to segfault. Here's the back trace:
```
* thread #1, name = 'accounts-daemon', stop reason = signal SIGSEGV: a...I'm using GNOME on Chimera Linux, and trying to enable automatic login from the Settings app causes `accountsservice` 23.13.9 to segfault. Here's the back trace:
```
* thread #1, name = 'accounts-daemon', stop reason = signal SIGSEGV: address not mapped to object (fault address: 0x8)
* frame #0: 0x000055555556fdad accounts-daemon`user_change_automatic_login_authorized_cb(daemon=0x00007fffee603db0, user=0x00007fffee100b70, context=0x00007fffeec05f20, data=0x0000000000000001) at user.c:2662:100
frame #1: 0x000055555556959b accounts-daemon`check_auth_cb(authority=<unavailable>, res=<unavailable>, data=0x00007fffef706210) at daemon.c:1681:17
frame #2: 0x00007fffef42cecf libgio-2.0.so.0`g_simple_async_result_complete + 191
frame #3: 0x00007ffff7f72aea libpolkit-gobject-1.so.0`___lldb_unnamed_symbol549 + 378
frame #4: 0x00007fffef4470c3 libgio-2.0.so.0`g_task_return_now.llvm.12815632267297636896 + 35
frame #5: 0x00007fffef445b71 libgio-2.0.so.0`g_task_return.llvm.12815632267297636896 + 289
frame #6: 0x00007fffef4bb2d7 libgio-2.0.so.0`reply_cb + 119
frame #7: 0x00007fffef4470c3 libgio-2.0.so.0`g_task_return_now.llvm.12815632267297636896 + 35
frame #8: 0x00007fffef445b71 libgio-2.0.so.0`g_task_return.llvm.12815632267297636896 + 289
frame #9: 0x00007fffef4ad48d libgio-2.0.so.0`g_dbus_connection_call_done + 317
frame #10: 0x00007fffef447113 libgio-2.0.so.0`complete_in_idle_cb.llvm.12815632267297636896 + 35
frame #11: 0x00007fffef2827b6 libglib-2.0.so.0`g_main_context_dispatch_unlocked + 406
frame #12: 0x00007fffef282d72 libglib-2.0.so.0`g_main_context_iterate_unlocked + 706
frame #13: 0x00007fffef2833cd libglib-2.0.so.0`g_main_loop_run + 413
frame #14: 0x000055555556c6f8 accounts-daemon`main(argc=1, argv=0x00007fffffffecd8) at main.c:283:9
```
The segfault occurs here (when dereferencing `error`, initialized to `NULL`):
```
frame #0: 0x000055555556fdad accounts-daemon`user_change_automatic_login_authorized_cb(daemon=0x00007fffee603db0, user=0x00007fffee100b70, cont
ext=0x00007fffeec05f20, data=0x0000000000000001) at user.c:2662:100
2659 }
2660
2661 if (!daemon_local_set_automatic_login (daemon, user, enabled, &error)) {
-> 2662 throw_error (context, ERROR_FAILED, "failed to change automatic login: %s", error->message);
2663 return;
2664 }
2665
```
I briefly looked into the code, and the only place where `daemon_local_set_automatic_login` returns `FALSE` and therefore causes the `if` statement body to execute is in lines 1907 to 1909 in `src/daemon.c`:
```
if (!save_autologin (daemon, user_get_user_name (user), enabled, error)) {
return FALSE;
}
```
So I went and checked `save_autologin`, and indeed, at the end of the function, `FALSE` is returned without modifying `error`.
Now, I'm using GDM, so I wasn't quite sure why `get_current_system_dm_type` (called in `save_autologin`) fails to detect that I'm using GDM. It didn't take me long to realize that it does that by checking what file the `/etc/systemd/system/display-manager.service` symlink points to; however, Chimera Linux doesn't use systemd (it uses dinit as its service manager and init). I'm not quite sure about the right way to adapt `get_current_system_dm_type` to Chimera Linux, I'll check how later (I might also open a separate ticket for this).https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/123Proposal: provide user grammatical gender property for localization2024-02-03T09:47:55ZmainrsProposal: provide user grammatical gender property for localization**Context**
Around 3 billion people speak languages where grammatical constructs - nouns, adjectives or articles - inflict based on the gender of the subject you are talking about. Not knowing the subject's gender results in grammatical...**Context**
Around 3 billion people speak languages where grammatical constructs - nouns, adjectives or articles - inflict based on the gender of the subject you are talking about. Not knowing the subject's gender results in grammatically wrong user interface text. And many gendered languages default to the masculine grammatical gender as their default gender. Examples for such languages are French and German.
**Problem**
Developers require knowledge about the user's preferred grammatical gender to produce correct localization. Imagine an application that lets the user select their job title. In German, you have different words for jobs depending on whether you use the masculine, feminine or neutral grammatical gender.
|English title|German masculine|German feminine|German neutral|
|---|---|---|---|
|Police Officer|Polizist|Polizistin|Polizeikraft|
|Notary|Notar|Notarin|notariell arbeitende Person/(Notariat)|
Another scenario are messages that address the user directly. Depending on the user's choice, the grammatical structure of the sentence changes.
**Current situation**
Applications that want to provide correct localization need to provide the user with a settings page to let them specify their grammatical gender. This has to be configured by the user for every application, since the data cannot currently be shared.
**Solution**
Expose a new property through the interface: `GrammaticalGender`. The property can take four values: `Unspecified/Null`, `Neutral`, `Masculine`, `Feminine`.
**Integration**
DEs can provide the user with an additional field to set their grammatical gender alongside their real name, profile image etc.
**Goal & Potential**
Providing the necessary tools for developers to localize their applications benefits all end-users downstream. Adoption by major DEs would create a unified, user-centric experience on Linux that is still missing compared to other popular platforms like iOS, macOS and Android.
**What others do**
All implementations listed below specify three types of gender: masculine, feminine and neutral. Apple extends this with additional features.
- Android introduced their [Grammatical Infliction API][3] in Android 14. This provides applications with functions to set the user's preferred gender application-wide. The framework does not provide a UI for this task. This is up to the application itself.
- Apple provides [guidelines][1] for properly localizing your application, including a [framework][2] for working with gender and pronoun preferences.
- Windows relies on gender-neutral words. Their [German Style Guide][4] provides more insight into this.
**Additional discussions**
- Apple's [implementation][2] allows adding custom terms of addressing at runtime. It should be discussed if this should be part of a new specification or treated as a potential, future addon/extension to a specification.
**References**
1) https://developer.apple.com/documentation/xcode/supporting-multiple-languages-in-your-app#Internationalize-your-code
2) https://developer.apple.com/documentation/foundation/termofaddress
3) https://developer.android.com/about/versions/14/features/grammatical-inflection
4) https://learn.microsoft.com/en-us/globalization/localization/ministyleguides/mini-style-guide-german
5) [Original GitLab issue on the XDG repository](https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/122)
[1]: https://developer.apple.com/documentation/xcode/supporting-multiple-languages-in-your-app#Internationalize-your-code
[2]: https://developer.apple.com/documentation/foundation/termofaddress
[3]: https://developer.android.com/about/versions/14/features/grammatical-inflection
[4]: https://learn.microsoft.com/en-us/globalization/localization/ministyleguides/mini-style-guide-germanhttps://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/122Proposal: provide fine-grained real user name properties2024-02-02T21:29:08ZmainrsProposal: provide fine-grained real user name properties**Context**
Different locales format names in different ways. Languages like English and German usually display names using the `<given name> <middle names> <family name>` template. Whereas CJK languages put the family name first, follo...**Context**
Different locales format names in different ways. Languages like English and German usually display names using the `<given name> <middle names> <family name>` template. Whereas CJK languages put the family name first, followed by the given name.
**Problem**
Applications might want to display the user's real name in a localized text. Currently, the DBUS interface only exposes a single property named `RealName` that can be set by the user. The property has no notion of given name, middle name(s) or family name. And thus makes it hard to properly localize.
For example, a user's real name might be 佐藤桜 (Satou Sakura). Depending on the user's locale, an application might want to either display 佐藤桜 if the locale is Japanese or in some other way if it is English. This can either be 桜 佐藤 (given name ・ familyname), the original Japanese order or some other format. However, there is no way for applications to decide on a format, since the information is not available to them.
**Solution**
Expose three new properties through the interface: `RealNameGiven`, `RealNameFamily` and `RealNameMiddle`.
**Integration**
DEs can provide the user with a more advanced real name configuration field. Instead of only entering the name inside a single field, the user can specify the parts of their name according to given, middle and family.
**Goal & Potential**
By implementing this enhancement, applications can make better localization choices, providing users with an overall better user experience.
The new properties allow applications to make smarter choices. E-Mail clients could properly format predefined signatures based on the locale or language the E-Mail is written in, applications could address the user by name during on-boarding...
**Additional discussions**
- How to handle the existing `RealName` property?
**References**
- [Apple Person Name Formatting](https://developer.apple.com/documentation/foundation/personnamecomponentsformatter)
- [Original GitLab issue on the XDG repository](https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/122)https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/121Leak shadow user from previous scan, if current not present in shadow.2024-03-03T18:48:42ZAnton PalgunovLeak shadow user from previous scan, if current not present in shadow.TL;DR need to reset the state of *spent to NULL if the user is not found in /etc/shadow (shadow_entry_buffers == NULL) https://gitlab.freedesktop.org/accountsservice/accountsservice/-/blob/main/src/daemon.c?ref_type=heads#L326
In situa...TL;DR need to reset the state of *spent to NULL if the user is not found in /etc/shadow (shadow_entry_buffers == NULL) https://gitlab.freedesktop.org/accountsservice/accountsservice/-/blob/main/src/daemon.c?ref_type=heads#L326
In situations when we have the shadow file, but a distro doesn't use that in real, possible situations when we have a user in passwd, but nothing in shadow.
In that cases![image](/uploads/6eab0a602e0830b80ec94b289f6a0899/image.png) we reach locked in the weird stack, correct user and incorrect previous success read from shadow.
A few more screens to investigate step by step before the screenshot above
![image](/uploads/052266362cc73f4ddc95be2533b55aaf/image.png)
![image](/uploads/0a855f9b448f2c7dd6180e498c1c02f4/image.png)
![image](/uploads/cb2c4deed5f7f6ca8c6f6bc6f791dc61/image.png)
![image](/uploads/92bed688c9837bc3fcffaaa2b23c82bb/image.png)
Possible is closing #10 as well, because I try to find the issue, but a bit more complex, also affect many cases which aware locked state of user. AutoLogin, User in list, Locked user in settings.https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/120accountsservice-23.13.9 fails tests: FAIL: test_languages (__main__.Tests.tes...2023-12-08T20:32:35ZFrancisco Ramosaccountsservice-23.13.9 fails tests: FAIL: test_languages (__main__.Tests.test_languages)As reported downstream at
https://bugs.gentoo.org/903347
If en_IE.UTF-8 is not present, tests fail
```
FAIL: test_languages (__main__.Tests.test_languages)
test that languages are correctly migrated
-------------------------------------...As reported downstream at
https://bugs.gentoo.org/903347
If en_IE.UTF-8 is not present, tests fail
```
FAIL: test_languages (__main__.Tests.test_languages)
test that languages are correctly migrated
----------------------------------------------------------------------
Traceback (most recent call last):
File "/var/tmp/portage/sys-apps/accountsservice-23.13.9/work/accountsservice-23.13.9-build/../accountsservice-23.13.9/tests/test-daemon.py", line 283, in test_languages
self.assertEqual(self.proxy.GetUsersLanguages(), ['en_GB.UTF-8', SIMULATED_SYSTEM_LOCALE])
AssertionError: Lists differ: ['C', 'en_GB.UTF-8'] != ['en_GB.UTF-8', 'en_IE.UTF-8']
First differing element 0:
'C'
'en_GB.UTF-8'
- ['C', 'en_GB.UTF-8']
+ ['en_GB.UTF-8', 'en_IE.UTF-8']
```
Thankshttps://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/119User keeps listed from ActUserManager after unaching2023-11-07T08:59:35ZOndrej HolyUser keeps listed from ActUserManager after unachingThe `ActUserManager` object doesn't emit the `user-removed` signal when a user has been uncached. Such an account also keeps being listed from the `act_user_manager_list_users` function. This was discovered when debugging why an enterpri...The `ActUserManager` object doesn't emit the `user-removed` signal when a user has been uncached. Such an account also keeps being listed from the `act_user_manager_list_users` function. This was discovered when debugging why an enterprise user is still listed in gnome-control-center after its uncaching. I see several issues here:
- The `ActUserManager` relies on the `user-added` and `user-removed` signals from the daemon, but those are not emitted for `explicitly_requested_users` when caching / uncaching and thus the `ActUserManager` may be outdated.
- When a user is cached, it is also added to the `explicitely_requested_users` list over the `daemon_local_find_user_by_name` function (https://gitlab.freedesktop.org/accountsservice/accountsservice/-/blob/42aa71ac99bebe552c26dc03239b88c02fbe37c0/src/daemon.c#L1075).
- Consequently, when the user is uncached, it is not unregistered from D-Bus, and the `user-deleted` signal is not emitted.
- This is also because the `user_set_cached` function is explicitly called from the `daemon_uncache_user_authorized_cb` function (https://gitlab.freedesktop.org/accountsservice/accountsservice/-/blob/42aa71ac99bebe552c26dc03239b88c02fbe37c0/src/daemon.c#L1502) and thus the `user_get_cached (user) && !user_get_cached (refreshed_user)` condition in the `reload_users` function is not `TRUE` (https://gitlab.freedesktop.org/accountsservice/accountsservice/-/blob/42aa71ac99bebe552c26dc03239b88c02fbe37c0/src/daemon.c#L628). Something similar may probably happen with the `user-added` signal as well.
What can probably be done here:
- The `daemon_local_find_user_by_name` resp. `daemon_local_find_user_by_id` could be tweaked to update the `explicitly_requested_users` list only when called from the `daemon_find_user_by_name` resp. `daemon_find_user_by_id` function. This should fix the use-case when a new enterprise account is cached and consequently uncached. But it still doesn't solve the issue when the user is in the `explicitly_requested_users` list for some other reason already.
- Maybe the `user_set_cached` function doesn't have to be called explicitly from the `daemon_uncache_user_authorized_cb` function, but later over the `reload_users` function. But this is perhaps a race condition.
- Instead, it could perhaps be removed from the table when it is being cached. But is it ok unregister it from DBus when uncaching, when it was explicitly requested initially? I am not fully sure about the purpose of the `explicitly_requested_users` list to be honest.
- If it is not ok, then it is probably ok that the `user-removed` is not emitted from the daemon (because the D-Bus object is not going to be unregistered), but it should still be emitted from the `ActUserManager` (because the manager doesn't care about uncached accounts). Consequently it would have to be probably handled similarly to what is done when a normal account becomes a system account (https://gitlab.freedesktop.org/accountsservice/accountsservice/-/blob/42aa71ac99bebe552c26dc03239b88c02fbe37c0/src/libaccountsservice/act-user-manager.c#L897-L917). This is probably the only way to fix the `user-added` signal when the account is already in the `explicitly_requested_users` list.
@halfline, hmm?https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/118Support `--badname` usernames (with capital letters).2024-03-18T23:17:56Z`{third: "Beedell", first: "Roke"}`{.JSON5}hyqjfpci@rokejulianlockhart.addy.ioSupport `--badname` usernames (with capital letters).1. ## **Summary**
Please consider providing support for names with capital letters specifically, ideally with support for `--badnames` as a whole, considering that with the universality of UTF-8, internationalization is expected of all...1. ## **Summary**
Please consider providing support for names with capital letters specifically, ideally with support for `--badnames` as a whole, considering that with the universality of UTF-8, internationalization is expected of all modern software.
1. ## **Context**
1. ##### **https://bugs.kde.org/show_bug.cgi?id=475373#c0**
<blockQuote>
```txt
SUMMARY
I'm unable to use any of the features afforded by the `--allow-badnames` flag in the username field, such as mere capital letters, when creating an account via `kcm_users`.
STEPS TO REPRODUCE
1. Invoke `kcmshell5 kcm_users`.
2. Create a new user.
3. Attempt to type capital letters in the username field.
OBSERVED RESULT
The characters are silently discarded when typed.
EXPECTED RESULT
I should be able to use capital letters, because other OSes have no issue with such a thing. Considering that the reason to disallow them by default is to retain compatibility with literal teletypes (per https://www.reddit.com/r/linuxquestions/comments/2ugpqa/comment/co8goaf/?utm_source=share&utm_medium=web2x&context=3).
Consider the testament of https://www.reddit.com/r/linux/comments/znkxxv/comment/j0jaiup/?utm_source=share&utm_medium=web2x&context=3:
I have – no joke – had a username starting with a capital letter for forever on more than one Linux machine that I used regularly. In 15+ years of doing this, I have never experienced any problems, bugs, or abnormalities that are a direct result of my username starting with a capital letter. Perhaps if you go back in time far enough you might experience some troubles, but in the modern day a username starting with a capital letter is a non-issue.
SOFTWARE/OS VERSIONS
Operating System: openSUSE Tumbleweed 20231005
KDE Plasma Version: 5.27.8
KDE Frameworks Version: 5.110.0
Qt Version: 5.15.10
Kernel Version: 6.5.4-1-default (64-bit)
Graphics Platform: X11
Processors: 12 × AMD Ryzen 5 7600X 6-Core Processor
Memory: 30.5 GiB of RAM
Graphics Processor: AMD Radeon RX 5700
Manufacturer: ASRock
Product Name: X670E Taichi
ADDITIONAL INFORMATION
https://discuss.kde.org/t/why-doesnt-the-users-kcm-allow-creating-a-user-whose-username-contains-capitals/5867?u=rokejulianlockhart
```
</blockQuote>
1. ##### **https://bugs.kde.org/show_bug.cgi?id=475373#c1**
> We delegate user creation to the accountservice library which has no option for us to invoke to change the behavior even if we wanted to; you'll have to take this up with its developers at https://gitlab.freedesktop.org/groups/accountsservice/-/issues.
1. ## **Prerequisites**
https://gitlab.freedesktop.org/groups/accountsservice/-/issues/?sort=created_date&state=opened&search=badname&first_page_size=20 returned 0 results on +2023-10-14T01:08:39+01:00.https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/117User templates only expand variables with braces2023-09-17T13:47:48Zjonathan-conderUser templates only expand variables with bracesRelates to https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/63
There's a bug in `expand_template_variables` where the length passed to `g_strndup` is off by 1 when `brackets == FALSE`. For example `$HOME` is evalu...Relates to https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/63
There's a bug in `expand_template_variables` where the length passed to `g_strndup` is off by 1 when `brackets == FALSE`. For example `$HOME` is evaluated as `HOM`.
Fix incoming.https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/116API to set the user's background file2023-09-01T09:43:28ZKyle RichardsAPI to set the user's background filehttps://lazka.github.io/pgi-docs/AccountsService-1.0/classes/User.html
There is already an API to set the `IconFile` (e.g. `set_icon_file`), it would be nice if there is one for setting the `BackgroundFile`.https://lazka.github.io/pgi-docs/AccountsService-1.0/classes/User.html
There is already an API to set the `IconFile` (e.g. `set_icon_file`), it would be nice if there is one for setting the `BackgroundFile`.https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/115segfault in free_fetch_user_request2023-08-03T01:20:08ZSid Tsegfault in free_fetch_user_requestThis is on Fedora 38 ( accountsservice-23.11.69-2.fc38.x86_64 ). Keep hitting this almost everyday. Happens only during login.
```
#0 g_type_check_instance_is_fundamentally_a at ../gobject/gtype.c:4166
#1 g_object_set_data at ../gobje...This is on Fedora 38 ( accountsservice-23.11.69-2.fc38.x86_64 ). Keep hitting this almost everyday. Happens only during login.
```
#0 g_type_check_instance_is_fundamentally_a at ../gobject/gtype.c:4166
#1 g_object_set_data at ../gobject/gobject.c:4242
#2 free_fetch_user_request at ../src/libaccountsservice/act-user-manager.c:1720
#3 fetch_user_incrementally at ../src/libaccountsservice/act-user-manager.c:1813
#4 on_find_user_by_name_finished at ../src/libaccountsservice/act-user-manager.c:1198
#5 g_task_return_now at ../gio/gtask.c:1309
#6 g_task_return at ../gio/gtask.c:1378
#8 reply_cb at ../gio/gdbusproxy.c:2571
#9 g_task_return_now at ../gio/gtask.c:1309
#10 g_task_return at ../gio/gtask.c:1378
#12 g_dbus_connection_call_done at ../gio/gdbusconnection.c:5885
#13 g_task_return_now at ../gio/gtask.c:1309
#14 complete_in_idle_cb at ../gio/gtask.c:1323
#18 g_main_context_iterate.isra.0 at ../glib/gmain.c:4276
#20 meta_context_run_main_loop at ../src/core/meta-context.c:482
```
https://bugzilla.redhat.com/show_bug.cgi?id=2189337
I'm not sure if this is the same as https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/113https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/114Valgrind invalid read in indicator messages on logout2023-04-18T23:44:18ZSebastienValgrind invalid read in indicator messages on logoutSimilar to !113 but our accountsservice package include that fix so probably another similar issue
```
==56020== Invalid read of size 8
==56020== at 0x4A70D41: g_type_check_instance (gtype.c:4270)
==56020== by 0x4A63567: g_signal_...Similar to !113 but our accountsservice package include that fix so probably another similar issue
```
==56020== Invalid read of size 8
==56020== at 0x4A70D41: g_type_check_instance (gtype.c:4270)
==56020== by 0x4A63567: g_signal_handlers_disconnect_matched (gsignal.c:3067)
==56020== by 0x4BEF9A7: act_user_manager_finalize (act-user-manager.c:2639)
==56020== by 0x4A59E4B: g_object_unref (gobject.c:3938)
==56020== by 0x112D3A: im_accounts_service_dispose (im-accounts-service.c:80)
==56020== by 0x4A59D9F: g_object_unref (gobject.c:3891)
==56020== by 0x111E52: im_application_list_dispose (im-application-list.c:567)
==56020== by 0x4A59D9F: g_object_unref (gobject.c:3891)
==56020== by 0x11143D: main (messages-service.c:290)
==56020== Address 0x56dc930 is 0 bytes inside a block of size 64 free'd
==56020== at 0x484620F: free (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==56020== by 0x4A6F66B: g_type_free_instance (gtype.c:2062)
==56020== by 0x4A4C00F: g_closure_invoke (gclosure.c:832)
==56020== by 0x4A793D5: signal_emit_unlocked_R.isra.0 (gsignal.c:3802)
==56020== by 0x4A69699: g_signal_emit_valist (gsignal.c:3555)
==56020== by 0x4A69922: g_signal_emit (gsignal.c:3612)
==56020== by 0x4A56DC3: g_object_dispatch_properties_changed.lto_priv.0 (gobject.c:1428)
==56020== by 0x4A5D09E: UnknownInlinedFun (gobject.c:1552)
==56020== by 0x4A5D09E: g_object_notify (gobject.c:1602)
==56020== by 0x4BF85DD: load_seat_incrementally (act-user-manager.c:2271)
==56020== by 0x4AF336E: UnknownInlinedFun (gmain.c:3460)
==56020== by 0x4AF336E: g_main_context_dispatch (gmain.c:4200)
==56020== by 0x4B4E177: g_main_context_iterate.constprop.0 (gmain.c:4276)
==56020== by 0x4AF2BDE: g_main_loop_run (gmain.c:4479)
==56020== Block was alloc'd at
==56020== at 0x4848A13: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==56020== by 0x4AF8550: g_malloc0 (gmem.c:163)
==56020== by 0x4A74B7C: g_type_create_instance (gtype.c:1965)
==56020== by 0x4A5C20F: g_object_new_internal (gobject.c:2246)
==56020== by 0x4A5D7B7: g_object_new_with_properties (gobject.c:2409)
==56020== by 0x4A5E560: g_object_new (gobject.c:2055)
==56020== by 0x4BF1751: create_new_user (act-user-manager.c:738)
==56020== by 0x4BF7564: act_user_manager_get_user (act-user-manager.c:1982)
==56020== by 0x1134CD: on_user_manager_loaded (im-accounts-service.c:149)
==56020== by 0x4A4C00F: g_closure_invoke (gclosure.c:832)
==56020== by 0x4A793D5: signal_emit_unlocked_R.isra.0 (gsignal.c:3802)
==56020== by 0x4A69699: g_signal_emit_valist (gsignal.c:3555)
```https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/113Invalid read valgrind errors leading to client segfault2023-07-02T16:38:12ZSebastienInvalid read valgrind errors leading to client segfaultIn Ubuntu Lunar we started receiving reports of ayatana-indicator-messages segfaulting, which seems to be triggered at logout for most users (but then the reporting utility prompt them at next login).
The package itself and accountsserv...In Ubuntu Lunar we started receiving reports of ayatana-indicator-messages segfaulting, which seems to be triggered at logout for most users (but then the reporting utility prompt them at next login).
The package itself and accountsservice didn't change so maybe changes in the stack are making the problem visible?
Valgrind shows invalid read error, log from the current git master (d603f80c) doing those steps
```
$ valgrind /usr/libexec/ayatana-indicator-messages/ayatana-indicator-messages-service
$ sudo kill -9 `pidof accounts-daemon`
$ gnome-control-center user-accounts
```
the g-c-c call is having for effect to respawn the service, the error are then displayed
```
==50297== Invalid read of size 8
==50297== at 0x4C0B26A: UnknownInlinedFun (act-user-manager.c:1824)
==50297== by 0x4C0B26A: on_user_manager_maybe_ready_for_request (act-user-manager.c:1814)
==50297== by 0x4A6100F: g_closure_invoke (gclosure.c:832)
==50297== by 0x4A8E3D5: signal_emit_unlocked_R.isra.0 (gsignal.c:3802)
==50297== by 0x4A7E699: g_signal_emit_valist (gsignal.c:3555)
==50297== by 0x4A7E922: g_signal_emit (gsignal.c:3612)
==50297== by 0x4A6BDC3: g_object_dispatch_properties_changed.lto_priv.0 (gobject.c:1428)
==50297== by 0x4A7209E: UnknownInlinedFun (gobject.c:1552)
==50297== by 0x4A7209E: g_object_notify (gobject.c:1602)
==50297== by 0x4C05A34: UnknownInlinedFun (act-user-manager.c:1321)
==50297== by 0x4C05A34: on_name_owner_changed (act-user-manager.c:2525)
==50297== by 0x4A6100F: g_closure_invoke (gclosure.c:832)
==50297== by 0x4A8E3D5: signal_emit_unlocked_R.isra.0 (gsignal.c:3802)
==50297== by 0x4A7E699: g_signal_emit_valist (gsignal.c:3555)
==50297== by 0x4A7E922: g_signal_emit (gsignal.c:3612)
==50297== Address 0x5800e68 is 56 bytes inside a block of size 64 free'd
==50297== at 0x484620F: free (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==50297== by 0x4C0405F: on_user_destroyed (act-user-manager.c:733)
==50297== by 0x4A6A4E6: weak_refs_notify (gobject.c:3286)
==50297== by 0x4AE84FB: g_data_set_internal (gdataset.c:410)
==50297== by 0x4A6BE14: g_object_real_dispose.lto_priv.0 (gobject.c:1364)
==50297== by 0x4A6ED9F: g_object_unref (gobject.c:3891)
==50297== by 0x4A6100F: g_closure_invoke (gclosure.c:832)
==50297== by 0x4A8E3D5: signal_emit_unlocked_R.isra.0 (gsignal.c:3802)
==50297== by 0x4A7E699: g_signal_emit_valist (gsignal.c:3555)
==50297== by 0x4A7E922: g_signal_emit (gsignal.c:3612)
==50297== by 0x4A6BDC3: g_object_dispatch_properties_changed.lto_priv.0 (gobject.c:1428)
==50297== by 0x4A7209E: UnknownInlinedFun (gobject.c:1552)
==50297== by 0x4A7209E: g_object_notify (gobject.c:1602)
==50297== Block was alloc'd at
==50297== at 0x4843828: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==50297== by 0x4B0C948: g_malloc (gmem.c:130)
==50297== by 0x4C0B444: UnknownInlinedFun (act-user-manager.c:1888)
==50297== by 0x4C0B444: act_user_manager_get_user (act-user-manager.c:1994)
==50297== by 0x1134CD: on_user_manager_loaded (im-accounts-service.c:149)
==50297== by 0x4A6100F: g_closure_invoke (gclosure.c:832)
==50297== by 0x4A8E3D5: signal_emit_unlocked_R.isra.0 (gsignal.c:3802)
==50297== by 0x4A7E699: g_signal_emit_valist (gsignal.c:3555)
==50297== by 0x4A7E922: g_signal_emit (gsignal.c:3612)
==50297== by 0x4A6BDC3: g_object_dispatch_properties_changed.lto_priv.0 (gobject.c:1428)
==50297== by 0x4A7209E: UnknownInlinedFun (gobject.c:1552)
==50297== by 0x4A7209E: g_object_notify (gobject.c:1602)
==50297== by 0x4C05A34: UnknownInlinedFun (act-user-manager.c:1321)
==50297== by 0x4C05A34: on_name_owner_changed (act-user-manager.c:2525)
==50297== by 0x4A6100F: g_closure_invoke (gclosure.c:832)
==50297==
==50297== Invalid read of size 1
==50297== at 0x4849CA6: strlen (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==50297== by 0x4C86317: __printf_buffer (vfprintf-process-arg.c:435)
==50297== by 0x4CA85F3: __vasprintf_internal (vasprintf.c:102)
==50297== by 0x4B5D8C1: UnknownInlinedFun (stdio2.h:169)
==50297== by 0x4B5D8C1: g_vasprintf (gprintf.c:340)
==50297== by 0x4B2ABE0: g_strdup_vprintf (gstrfuncs.c:553)
==50297== by 0x4B0C2F6: UnknownInlinedFun (gmessages.c:3363)
==50297== by 0x4B0C2F6: g_logv (gmessages.c:1318)
==50297== by 0x4B0C7A2: g_log (gmessages.c:1460)
==50297== by 0x4C0B279: UnknownInlinedFun (act-user-manager.c:1824)
==50297== by 0x4C0B279: on_user_manager_maybe_ready_for_request (act-user-manager.c:1814)
==50297== by 0x4A6100F: g_closure_invoke (gclosure.c:832)
==50297== by 0x4A8E3D5: signal_emit_unlocked_R.isra.0 (gsignal.c:3802)
==50297== by 0x4A7E699: g_signal_emit_valist (gsignal.c:3555)
==50297== by 0x4A7E922: g_signal_emit (gsignal.c:3612)
==50297== Address 0x5800f00 is 0 bytes inside a block of size 14 free'd
==50297== at 0x484620F: free (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==50297== by 0x4C03F90: free_fetch_user_request (act-user-manager.c:1780)
==50297== by 0x4C0405F: on_user_destroyed (act-user-manager.c:733)
==50297== by 0x4A6A4E6: weak_refs_notify (gobject.c:3286)
==50297== by 0x4AE84FB: g_data_set_internal (gdataset.c:410)
==50297== by 0x4A6BE14: g_object_real_dispose.lto_priv.0 (gobject.c:1364)
==50297== by 0x4A6ED9F: g_object_unref (gobject.c:3891)
==50297== by 0x4A6100F: g_closure_invoke (gclosure.c:832)
==50297== by 0x4A8E3D5: signal_emit_unlocked_R.isra.0 (gsignal.c:3802)
==50297== by 0x4A7E699: g_signal_emit_valist (gsignal.c:3555)
==50297== by 0x4A7E922: g_signal_emit (gsignal.c:3612)
==50297== by 0x4A6BDC3: g_object_dispatch_properties_changed.lto_priv.0 (gobject.c:1428)
==50297== Block was alloc'd at
==50297== at 0x4843828: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==50297== by 0x4CA8677: __vasprintf_internal (vasprintf.c:116)
==50297== by 0x4B5D8C1: UnknownInlinedFun (stdio2.h:169)
==50297== by 0x4B5D8C1: g_vasprintf (gprintf.c:340)
==50297== by 0x4B2ABE0: g_strdup_vprintf (gstrfuncs.c:553)
==50297== by 0x4B2AC9C: g_strdup_printf (gstrfuncs.c:583)
==50297== by 0x4C0B49A: UnknownInlinedFun (act-user-manager.c:1895)
==50297== by 0x4C0B49A: act_user_manager_get_user (act-user-manager.c:1994)
==50297== by 0x1134CD: on_user_manager_loaded (im-accounts-service.c:149)
==50297== by 0x4A6100F: g_closure_invoke (gclosure.c:832)
==50297== by 0x4A8E3D5: signal_emit_unlocked_R.isra.0 (gsignal.c:3802)
==50297== by 0x4A7E699: g_signal_emit_valist (gsignal.c:3555)
==50297== by 0x4A7E922: g_signal_emit (gsignal.c:3612)
==50297== by 0x4A6BDC3: g_object_dispatch_properties_changed.lto_priv.0 (gobject.c:1428)
==50297== Invalid read of size 2
==50297== at 0x484DAC0: memmove (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==50297== by 0x4C7CB67: __printf_buffer_write (Xprintf_buffer_write.c:39)
==50297== by 0x4C84CD4: __printf_buffer (vfprintf-process-arg.c:501)
==50297== by 0x4CA85F3: __vasprintf_internal (vasprintf.c:102)
==50297== by 0x4B5D8C1: UnknownInlinedFun (stdio2.h:169)
==50297== by 0x4B5D8C1: g_vasprintf (gprintf.c:340)
==50297== by 0x4B2ABE0: g_strdup_vprintf (gstrfuncs.c:553)
==50297== by 0x4B0C2F6: UnknownInlinedFun (gmessages.c:3363)
==50297== by 0x4B0C2F6: g_logv (gmessages.c:1318)
==50297== by 0x4B0C7A2: g_log (gmessages.c:1460)
==50297== by 0x4C0B279: UnknownInlinedFun (act-user-manager.c:1824)
==50297== by 0x4C0B279: on_user_manager_maybe_ready_for_request (act-user-manager.c:1814)
==50297== by 0x4A6100F: g_closure_invoke (gclosure.c:832)
==50297== by 0x4A8E3D5: signal_emit_unlocked_R.isra.0 (gsignal.c:3802)
==50297== by 0x4A7E699: g_signal_emit_valist (gsignal.c:3555)
==50297== Address 0x5800f08 is 8 bytes inside a block of size 14 free'd
==50297== at 0x484620F: free (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==50297== by 0x4C03F90: free_fetch_user_request (act-user-manager.c:1780)
==50297== by 0x4C0405F: on_user_destroyed (act-user-manager.c:733)
==50297== by 0x4A6A4E6: weak_refs_notify (gobject.c:3286)
==50297== by 0x4AE84FB: g_data_set_internal (gdataset.c:410)
==50297== by 0x4A6BE14: g_object_real_dispose.lto_priv.0 (gobject.c:1364)
==50297== by 0x4A6ED9F: g_object_unref (gobject.c:3891)
==50297== by 0x4A6100F: g_closure_invoke (gclosure.c:832)
==50297== by 0x4A8E3D5: signal_emit_unlocked_R.isra.0 (gsignal.c:3802)
==50297== by 0x4A7E699: g_signal_emit_valist (gsignal.c:3555)
==50297== by 0x4A7E922: g_signal_emit (gsignal.c:3612)
==50297== by 0x4A6BDC3: g_object_dispatch_properties_changed.lto_priv.0 (gobject.c:1428)
==50297== Block was alloc'd at
==50297== at 0x4843828: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==50297== by 0x4CA8677: __vasprintf_internal (vasprintf.c:116)
==50297== by 0x4B5D8C1: UnknownInlinedFun (stdio2.h:169)
==50297== by 0x4B5D8C1: g_vasprintf (gprintf.c:340)
==50297== by 0x4B2ABE0: g_strdup_vprintf (gstrfuncs.c:553)
==50297== by 0x4B2AC9C: g_strdup_printf (gstrfuncs.c:583)
==50297== by 0x4C0B49A: UnknownInlinedFun (act-user-manager.c:1895)
==50297== by 0x4C0B49A: act_user_manager_get_user (act-user-manager.c:1994)
==50297== by 0x1134CD: on_user_manager_loaded (im-accounts-service.c:149)
==50297== by 0x4A6100F: g_closure_invoke (gclosure.c:832)
==50297== by 0x4A8E3D5: signal_emit_unlocked_R.isra.0 (gsignal.c:3802)
==50297== by 0x4A7E699: g_signal_emit_valist (gsignal.c:3555)
==50297== by 0x4A7E922: g_signal_emit (gsignal.c:3612)
==50297== by 0x4A6BDC3: g_object_dispatch_properties_changed.lto_priv.0 (gobject.c:1428)
```https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/112meson finds `dbusmock` python module even if not installed on the system2023-04-30T12:04:57ZPierre Labastiemeson finds `dbusmock` python module even if not installed on the systemOn a system without dbusmock installed, the exit code is 0 when running `run_command(python3, '-c', 'import @0@'.format(module), check: false)` (in `tests/meson.build`) for module = 'dbusmock'. The reason is that the directory `tests` co...On a system without dbusmock installed, the exit code is 0 when running `run_command(python3, '-c', 'import @0@'.format(module), check: false)` (in `tests/meson.build`) for module = 'dbusmock'. The reason is that the directory `tests` contains a subdirectory `dbusmock`, which is enough to allow the import to succeed (sys.path contains the current directory).
Meson then fails later when running unittest_inspector.
I guess it would be enough to change the subdirectory name to something else, but I am not sure whether some paths would have to be changed or not.https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/111Include subprojects in release tarball2023-03-17T14:37:56ZMatt TurnerInclude subprojects in release tarballWithout mocklibc included in the tarball, the build fails if automatic downloads of subprojects are disabled (as they are likely to be in distro build systems):
````
[...]
Program msginit found: YES (/usr/bin/msginit)
Program msgmerge f...Without mocklibc included in the tarball, the build fails if automatic downloads of subprojects are disabled (as they are likely to be in distro build systems):
````
[...]
Program msginit found: YES (/usr/bin/msginit)
Program msgmerge found: YES (/usr/bin/msgmerge)
Program xgettext found: YES (/usr/bin/xgettext)
Program check-format.sh found: YES (/var/tmp/portage/sys-apps/accountsservice-23.11.69/work/accountsservice-23.11.69/tests/check-format.sh)
tests/meson.build:3:0: ERROR: Automatic wrap-based subproject downloading is disabled
````
Meson docs about including subprojects in the release tarball: https://mesonbuild.com/Creating-releases.html#include-subprojects-in-your-releasehttps://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/110Add support for setting an account as Local in the users file2023-03-15T15:27:57ZJonathan BillingsAdd support for setting an account as Local in the users fileWe have our laptops set up to use IPA for authentication, but the account is set up with a sssd cached password for when off the net, which makes it very much like a local account. Part of our provisioning sets up the account file in /v...We have our laptops set up to use IPA for authentication, but the account is set up with a sssd cached password for when off the net, which makes it very much like a local account. Part of our provisioning sets up the account file in /var/lib/AccountsService/users/ but it seems that you can't set LocalAccount=true in that file.
The reason why we want to allow setting a local account is because if it is not set as local, the Fingerprint settings don't appear in GNOME settings:
https://gitlab.gnome.org/GNOME/gnome-control-center/-/blob/main/panels/user-accounts/cc-user-panel.c#L911
We would like to be able to override the LocalAccount settings in the user config file in /var/lib/AccountsService/users/.
The fix will require adding support for a LocalAccount https://gitlab.freedesktop.org/accountsservice/accountsservice/-/blob/main/src/user.c#L588 passing local here https://gitlab.freedesktop.org/accountsservice/accountsservice/-/blob/main/src/daemon.c#L539 and populating local_users here https://gitlab.freedesktop.org/accountsservice/accountsservice/-/blob/main/src/daemon.c#L332https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/109Segfault calling SetRealName on 32-bit ARM2023-02-08T01:10:27ZSimon McVittieSegfault calling SetRealName on 32-bit ARMI added [an integration test](https://salsa.debian.org/freedesktop-team/accountsservice/-/blob/debian/22.08.8-4/debian/tests/integration.py) to Debian's accountsservice packaging, to validate our backports of !118 and !119. This is a des...I added [an integration test](https://salsa.debian.org/freedesktop-team/accountsservice/-/blob/debian/22.08.8-4/debian/tests/integration.py) to Debian's accountsservice packaging, to validate our backports of !118 and !119. This is a destructive "as-installed" test, designed to be run inside an expendable container or virtual machine (it creates and destroys users), so it is not necessarily suitable for upstream inclusion.
This passed on most of our architectures that provide as-installed testing facilities, but failed on armel (ARMv5 EABI softfloat) and armhf (ARMv7 EABI hardfloat) with a segmentation fault in accounts-daemon while handling a call to `SetRealName()`.
On investigation, it looks like this was a format string issue: accounts-daemon uses format `%d` to print a 64-bit integer, resulting in the stack contents not matching what was expected on the two 32-bit ARM architectures. For whatever obscure ABI reason, this didn't crash on i386.
Fixed by !120.Simon McVittieSimon McVittiehttps://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/108Caching a system (non-human) user causes it to be considered not a system acc...2023-02-06T14:50:06ZSimon McVittieCaching a system (non-human) user causes it to be considered not a system accountWhile adding an integration test to Debian's accountsservice packaging (mainly to verify my backports of !116 and !118), I noticed this behaviour:
* Start with an account that accountsservice considers to be a local system account. I us...While adding an integration test to Debian's accountsservice packaging (mainly to verify my backports of !116 and !118), I noticed this behaviour:
* Start with an account that accountsservice considers to be a local system account. I used `_apt`, a reserved system user that is part of our upgrade mechanism:
```
# grep _apt /etc/passwd
_apt:x:100:65534::/nonexistent:/usr/sbin/nologin
```
* Call `user = AccountsService.UserManager.get_default().cache_user("_apt")` using GObject-Introspection
* Look at its properties with `user.is_system_account()` and so on
* What I expected: `user.is_local_account()` is true, `user.is_system_account()` is also true
* Actual result: `user.is_local_account()` is true (after !116), but `user.is_system_account()` is false
Is this intended?https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/107gets confused about local/remote status of users that are considered non-human2023-02-18T00:11:00ZSimon McVittiegets confused about local/remote status of users that are considered non-humanhttps://bugs.debian.org/1030262
To reproduce:
* Be a user with administrative privileges
* Create a new (local, /etc/passwd + /etc/shadow) user account via gnome-control-center, but arrange through devious means for the user account to...https://bugs.debian.org/1030262
To reproduce:
* Be a user with administrative privileges
* Create a new (local, /etc/passwd + /etc/shadow) user account via gnome-control-center, but arrange through devious means for the user account to return false from `user_classify_is_human()`
* In Debian this happened by mistake because we apply patches to use Debian `adduser` instead of `useradd`, and there was a behaviour change in `adduser` causing our accountsservice to be wrongly creating users with `/usr/sbin/nologin`. That's a Debian-specific bug and a fix is in progress, but it demonstrates that this is something that can happen by mistake.
* Upstream, you can probably make this happen by creating a user account with one of the names in `default_excludes[]`. `pvm` is an example of one that is not reserved on my Debian system.
* Upstream, I think you could also make this happen by having 50+ local user accounts already.
* Try to remove the newly-created user via gnome-control-center
* Inspect `/etc/passwd` and `/etc/shadow`
* Log out
* Try to log in as the newly-created-and-then-deleted user using gdm
Expected result:
* accountsservice thinks the user is a local user, because it ... is
* gnome-control-center implements its "Remove User" button as genuinely deleting the local user
* The user is removed from `/etc/passwd` and `/etc/shadow`
* You can't log in as it
Actual result:
* accountsservice thinks the user is a remote user (from LDAP or similar)
* gnome-control-center implements its "Remove User" button as merely removing the user from the cached list of "interesting" users, with an ambiguous message that doesn't make it particularly clear that the user account is not actually being deleted
* The user remains present in `/etc/passwd` and `/etc/shadow`
* gdm doesn't list the user in the shortlist of known users, because accountsservice doesn't list non-human local users unless they're cached
* You can still use "Not listed?" to log in by specifying the user's username
* Potentially a security problem if the reason you were deleting the account is because someone malicious knows its password
I'm reporting this as non-confidential (sorry!) because it's already non-confidential in the Debian bug tracking system.https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/106Crash when opening Settings > Users in GNOME OS Nightly2023-03-27T19:38:42ZGhost UserCrash when opening Settings > Users in GNOME OS NightlyHere is the backtrace:
```
(gdb) bt full
#0 g_type_check_instance_is_fundamentally_a (type_instance=type_instance@entry=0x5562fac0ff80, fundamental_type=fundamental_type@entry=0x50 [GObject]) at ../gobject/gtype.c:4152
node = <...Here is the backtrace:
```
(gdb) bt full
#0 g_type_check_instance_is_fundamentally_a (type_instance=type_instance@entry=0x5562fac0ff80, fundamental_type=fundamental_type@entry=0x50 [GObject]) at ../gobject/gtype.c:4152
node = <optimized out>
#1 0x00007fb9ac731334 in g_object_set_data (object=0x5562fac0ff80, key=0x7fb9ab2522bd "fetch-user-request", data=0x0) at ../gobject/gobject.c:4213
_g_boolean_var_152 = <optimized out>
__func__ = "g_object_set_data"
#2 0x00007fb9ab2423d3 in free_fetch_user_request (request=0x5562f8188c80) at ../accountsservice-22.08.8/src/libaccountsservice/act-user-manager.c:1708
manager = 0x5562f7d609b0 [ActUserManager]
priv = 0x5562f7d60900
#3 0x00007fb9ab24314b in fetch_user_incrementally (request=<optimized out>) at ../accountsservice-22.08.8/src/libaccountsservice/act-user-manager.c:1802
priv = <optimized out>
__func__ = "fetch_user_incrementally"
#4 0x00007fb9ab24347e in on_find_user_by_id_finished (object=<optimized out>, result=<optimized out>, data=0x5562f8188c80) at ../accountsservice-22.08.8/src/libaccountsservice/act-user-manager.c:1217
proxy = <optimized out>
request = 0x5562f8188c80
error = 0x0
user = 0x5562fa88b970 "/org/freedesktop/Accounts/User1000"
#5 0x00007fb9ac83241b in g_task_return_now (task=0x5562f8187630 [GTask]) at ../gio/gtask.c:1291
#6 0x00007fb9ac83321b in g_task_return (type=<optimized out>, task=0x5562f8187630 [GTask]) at ../gio/gtask.c:1360
source = 0x7fb998022590
#7 g_task_return (task=0x5562f8187630 [GTask], type=<optimized out>) at ../gio/gtask.c:1317
#8 0x00007fb9ac89e0eb in reply_cb (connection=<optimized out>, res=<optimized out>, user_data=0x5562f8187630) at ../gio/gdbusproxy.c:2578
data = <optimized out>
task = 0x5562f8187630 [GTask]
value = 0x7fb99803f720
error = 0x0
fd_list = 0x0
#9 0x00007fb9ac83241b in g_task_return_now (task=0x5562f8159ec0 [GTask]) at ../gio/gtask.c:1291
#10 0x00007fb9ac83321b in g_task_return (type=<optimized out>, task=0x5562f8159ec0 [GTask]) at ../gio/gtask.c:1360
source = 0x7fb998022590
#11 g_task_return (task=0x5562f8159ec0 [GTask], type=<optimized out>) at ../gio/gtask.c:1317
#12 0x00007fb9ac89168a in g_dbus_connection_call_done (source=<optimized out>, result=0x5562f8166bc0, user_data=0x5562f8159ec0) at ../gio/gdbusconnection.c:5883
connection = <optimized out>
task = 0x5562f8159ec0 [GTask]
state = 0x7fb9900cee20
error = 0x0
reply = 0x7fb99803ebb0 [GDBusMessage]
value = <optimized out>
#13 0x00007fb9ac83241b in g_task_return_now (task=0x5562f8166bc0 [GTask]) at ../gio/gtask.c:1291
#14 0x00007fb9ac832455 in complete_in_idle_cb (task=0x5562f8166bc0) at ../gio/gtask.c:1305
#15 0x00007fb9ac628a21 in g_main_dispatch (context=<optimized out>) at ../glib/gmain.c:3444
dispatch = 0x7fb9ac624790 <g_idle_dispatch>
prev_source = 0x0
begin_time_nsec = 889363081821
was_in_call = 0
user_data = 0x5562f8166bc0
callback = 0x7fb9ac832440 <complete_in_idle_cb>
cb_funcs = 0x7fb9ac70d2e0 <g_source_callback_funcs>
cb_data = 0x5562f7bf9500
need_destroy = <optimized out>
source = 0x7fb998022590
current = 0x5562f7b9c550
i = 0
__func__ = "g_main_dispatch"
#16 g_main_context_dispatch (context=<optimized out>) at ../glib/gmain.c:4162
#17 0x00007fb9ac628f78 in g_main_context_iterate (context=context@entry=0x5562f7b8b830, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4238
max_priority = 0
timeout = 0
some_ready = 1
nfds = 4
allocated_nfds = <optimized out>
fds = <optimized out>
begin_time_nsec = 889363062769
#18 0x00007fb9ac629013 in g_main_context_iteration (context=context@entry=0x5562f7b8b830, may_block=may_block@entry=1) at ../glib/gmain.c:4303
retval = <optimized out>
#19 0x00007fb9ac8632ed in g_application_run (application=application@entry=0x5562f7b86fa0 [CcApplication], argc=argc@entry=1, argv=argv@entry=0x7ffe98195038) at ../gio/gapplication.c:2571
arguments = 0x5562f7b4a760
status = 0
context = 0x5562f7b8b830
acquired_context = <optimized out>
__func__ = "g_application_run"
#20 0x00005562f6b27515 in main (argc=1, argv=0x7ffe98195038) at ../shell/main.c:62
application = 0x5562f7b86fa0
```
## Additional info
It was oriented to file the issue here, see: https://gitlab.gnome.org/GNOME/gnome-build-meta/-/issues/581#note_1608685https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/105You can update Spanish translation for accountsservice2023-09-28T07:56:16ZFrancisco SerradorYou can update Spanish translation for accountsserviceHi, I have updated Spanish translation. Mustieles said me to inform you to update es.po.Hi, I have updated Spanish translation. Mustieles said me to inform you to update es.po.