accountsservice issueshttps://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues2024-02-03T09:47:55Zhttps://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/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/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/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.https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/101Transactional API2022-02-21T14:40:42ZJanet BlackquillTransactional APIThe accounts service doesn't have an API to do sets of changes atomically; causing issues for us in KDE, where we use the "apply changes" model where we set many changes after hitting a button instead of instantly saving as the user chan...The accounts service doesn't have an API to do sets of changes atomically; causing issues for us in KDE, where we use the "apply changes" model where we set many changes after hitting a button instead of instantly saving as the user changes details. This can cause issues, where the applying of changes can be cancelled/errored out in the middle of this, leading to an inconsistent system state from what the user wanted.https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/98Unable to set profile picture via gnome control center, because /tmp is marke...2022-03-02T17:53:44ZFabian BornscheinUnable to set profile picture via gnome control center, because /tmp is marked private in accountsservice service fileHi. While I'm trying to set a profile picture graphically I hit a conflict in between accountsservice security and gnome-control-center(g-c-c) way to setup the profile picture.
The g-c-c sends a copy of the (possibly cropped) profile pic...Hi. While I'm trying to set a profile picture graphically I hit a conflict in between accountsservice security and gnome-control-center(g-c-c) way to setup the profile picture.
The g-c-c sends a copy of the (possibly cropped) profile picture to /tmp and calls dbus to set the picture. Here it fails with
```
(gnome-control-center:7861): accountsservice-WARNING **: 15:32:07.674: SetIconFile call failed: GDBus.Error:org.freedesktop.Accounts.Error.Failed: file '/tmp/gnome-control-center-user-icon-LR33G1' is not a regular file
```
A manual test confirms this: Copy pic.png to /tmp/pic.png and run
```
file /tmp/pic.png
/tmp/pic.png: PNG image data, 660 x 660, 8-bit/color RGBA, non-interlaced
busctl call org.freedesktop.Accounts /org/freedesktop/Accounts/User${UID} org.freedesktop.Accounts.User SetIconFile s /tmp/pic.png
```
It fails with
```
Call failed: file '/tmp/pic.png' is not a regular file
```
This seemns to be because in https://gitlab.freedesktop.org/accountsservice/accountsservice/-/blob/main/data/accounts-daemon.service.in#L28
```
PrivateTmp=true
```
So the file in /tmp is not reachable to be set by accountsservice.
Now I don't know if this is something that should be changed on the GNOME side, or here in the systemd service file.
* accountsservice 22.04.62-2
* dbus 1.12.20-1
* Arch Linux
Bugreport on GNOME bugtracker: https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/1629https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/96On Debian10/KDE a libvirt-qemu user is added and shown on the login screen2021-12-31T18:41:10ZmYnDstrEAmOn Debian10/KDE a libvirt-qemu user is added and shown on the login screen
I didn't create this user - I think it was added by installing the "Virtual Machine manager" (virt-manager) on Debian10/KDE, or more specifically by `libvirt-daemon-system`.
`grep -E 'libvirt|qemu' /etc/passwd` returns `libvirt-qemu:x...
I didn't create this user - I think it was added by installing the "Virtual Machine manager" (virt-manager) on Debian10/KDE, or more specifically by `libvirt-daemon-system`.
`grep -E 'libvirt|qemu' /etc/passwd` returns `libvirt-qemu:x:6xxxx:1xx:Libvirt Qemu,,,:/var/lib/libvirt:/usr/sbin/nologin`
KDE's User Manager doesn't show the account but it's displayed on the login screen on the left of the actual user account (not when locking the screen but at least after booting). I don't have a file /var/lib/AccountsService/users/libvirt-qemu like described in a solution to [the 2017 question here](https://askubuntu.com/questions/897026/why-do-i-have-a-libvirt-qemu-account-in-lock-switch-account-options-in-ubuntu) and could not find a bug report here.
This useraccount shouldn't be displayed as a normal user if adding it is indeed needed/useful.
If the solution is to not remove the user but to hide it by creating the /users/libvirt-qemu file why isn't that done when the user is set up already? If the user is necessary I'd find it strange that iirc it was only added after installing virt-manager but not after installing and using aqemu.
I asked about it [here](https://unix.stackexchange.com/questions/663829/why-is-there-a-libvirt-qemu-user-showing-on-the-login-screen-and-how-to-remove) where users cas and A.B. made some helpful comments. A.B. suggested that "libvirt-qemu is a system account but with a specific UID not in the default system range ( < 500 or something like this): `grep LIBVIRT_QEMU_UID /var/lib/dpkg/info/libvirt*`" (it's over 60000). Changing the UID or creating that config-file containing `SystemAccount=true` upon installation seem to be two ways of solving this issue.https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/95document accountservice2021-07-30T20:29:03ZCaleb Cushingdocument accountservice... at least a little bit more
https://www.freedesktop.org/wiki/Software/AccountsService/
the links to bugs and fedora are stale. I honestly haven't really been able to figure out via google what this is used for, and why I should enab...... at least a little bit more
https://www.freedesktop.org/wiki/Software/AccountsService/
the links to bugs and fedora are stale. I honestly haven't really been able to figure out via google what this is used for, and why I should enable it. A bit more description would be nice. I'm also confused on whether it interacts with homed.https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/94Accounts service fails to set full name while user has no profile picture or ...2021-01-10T23:36:57ZJanet BlackquillAccounts service fails to set full name while user has no profile picture or ~/.faceIt seems that the accounts service fails to set full name of a user (possibly other data too) whenever the user doesn't have a profile picture or a `.face` file in their home directory.It seems that the accounts service fails to set full name of a user (possibly other data too) whenever the user doesn't have a profile picture or a `.face` file in their home directory.https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/91ERROR: Dependency "gobject-introspection-1.0" not found even when installed ...2021-06-21T05:45:03ZSameer LattannavarERROR: Dependency "gobject-introspection-1.0" not found even when installed gobject-introspection-1.64.0-2 versionHi There,
While compiling accountsservice using meson command: meson --prefix=$PWD build encountering an error:
Build-time dependency gobject-introspection-1.0 found: NO (tried pkgconfig and cmake)
src/libaccountsservice/meson.build:...Hi There,
While compiling accountsservice using meson command: meson --prefix=$PWD build encountering an error:
Build-time dependency gobject-introspection-1.0 found: NO (tried pkgconfig and cmake)
src/libaccountsservice/meson.build:75:2: ERROR: Dependency "gobject-introspection-1.0" not found, tried pkgconfig and cmake
A full log can be found as attachment:[meson-log.txt](/uploads/cd147ba3f5fa124924dc377762fca478/meson-log.txt)
Kindly help to resolve this error. Thanks
-Sameer Lattannavarhttps://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/90accountsservice-0.6.55: docdir for docbook docs cannot be configured2020-05-31T09:18:20ZFrancisco Ramosaccountsservice-0.6.55: docdir for docbook docs cannot be configuredIt seems the installation directory for docbook docs is always /usr/share/doc/accountsservice and it cannot be changed with a --docdir flag as it's hardcoded in meson rules. Maybe it would be interesting to all that to be configurable as...It seems the installation directory for docbook docs is always /usr/share/doc/accountsservice and it cannot be changed with a --docdir flag as it's hardcoded in meson rules. Maybe it would be interesting to all that to be configurable as happens with other docs
Thanks a lothttps://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/89About new systemd's homed2023-10-29T21:58:26ZJavier Jardónjjardon@gnome.orgAbout new systemd's homedIs there any plans to support this?
- https://systemd.io/HOME_DIRECTORY/
- https://www.freedesktop.org/software/systemd/man/homectl.htmlIs there any plans to support this?
- https://systemd.io/HOME_DIRECTORY/
- https://www.freedesktop.org/software/systemd/man/homectl.htmlhttps://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/85Support constructing `ActUserManager` with a specified `GDBusConnection`2020-02-25T13:54:43ZPhilip WithnallSupport constructing `ActUserManager` with a specified `GDBusConnection`As mentioned/motivated in https://gitlab.gnome.org/GNOME/gnome-initial-setup/-/merge_requests/76#note_724166, it would be useful if `ActUserManager` could be constructed with a specified `GDBusConnection` instance provided by the caller,...As mentioned/motivated in https://gitlab.gnome.org/GNOME/gnome-initial-setup/-/merge_requests/76#note_724166, it would be useful if `ActUserManager` could be constructed with a specified `GDBusConnection` instance provided by the caller, rather than using `g_bus_get_sync()` to get its own reference to the global connection.
This would allow callers to more easily provide a shared connection which they could then redirect to a mock system bus for testing purposes (or add their own debugging/monitoring to, or whatever).https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/84Generated enum types are in wrong namespace2020-02-05T12:31:11ZPhilip WithnallGenerated enum types are in wrong namespaceThe generated enum `GType`s in `act-user-enum-types.[ch]` are in the `act_user_` namespace rather than the `act_` namespace. As far as I can tell, nothing else is in the `act_user_` namespace.
For example, the `GType` for `ActUserAccoun...The generated enum `GType`s in `act-user-enum-types.[ch]` are in the `act_user_` namespace rather than the `act_` namespace. As far as I can tell, nothing else is in the `act_user_` namespace.
For example, the `GType` for `ActUserAccountType` is `ACT_USER_TYPE_USER_ACCOUNT_TYPE`, which smells wrong. I think it should be `ACT_TYPE_USER_ACCOUNT_TYPE`.
Unfortunately, fixing this will be an API break, as those symbols are publicly visible.
This was a bug in the autotools version of accountsservice too, so wasn’t introduced in the Meson port.https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/81link to bug tracker on project website needs updating2019-11-21T14:49:34ZMéven Carlink to bug tracker on project website needs updatinghttps://www.freedesktop.org/wiki/Software/AccountsService/ directs users to https://bugs.freedesktop.org/
It should point them to this gitlab instance.https://www.freedesktop.org/wiki/Software/AccountsService/ directs users to https://bugs.freedesktop.org/
It should point them to this gitlab instance.https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/78sandboxing: Restrict SystemCallFilter= further2019-05-07T11:35:27ZPhilip Withnallsandboxing: Restrict SystemCallFilter= furtherThe sandboxing added in !22 sets a very unrestrictive [`SystemCallFilter=`](https://www.freedesktop.org/software/systemd/man/systemd.exec.html#SystemCallFilter=) (just enough to get [`ReadWritePaths=`/`ReadOnlyPaths=`](https://www.freede...The sandboxing added in !22 sets a very unrestrictive [`SystemCallFilter=`](https://www.freedesktop.org/software/systemd/man/systemd.exec.html#SystemCallFilter=) (just enough to get [`ReadWritePaths=`/`ReadOnlyPaths=`](https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ReadWritePaths=) working inescapably). It would be good to tighten this further in `data/accounts-daemon.service.in`.
This could be complicated by the fact that `accounts-service` runs processes like `usermod` as subprocesses, and they might require unusual system calls.