[pacman-dev] Road to 5.1
Hi all, We have not had a release in a long, long time. Lets fix that! There is a substantial number of bugs tagged for a 5.1 release [1]. These were added when we were all younger and more optimistic about the world... I have added a 5.2 target, so we can start bumping some to a future release. Please reply here with anything you think is essential to the next release - even better if you provide a patch! Cheers, Allan [1] https://bugs.archlinux.org/roadmap/proj3
On Mon, Jan 08, 2018 at 03:26:49PM +1000, Allan McRae wrote:
Hi all,
We have not had a release in a long, long time. Lets fix that!
There is a substantial number of bugs tagged for a 5.1 release [1]. These were added when we were all younger and more optimistic about the world... I have added a 5.2 target, so we can start bumping some to a future release.
Please reply here with anything you think is essential to the next release - even better if you provide a patch!
Cheers, Allan
Can we fix extraction based on lookups of user/group so that the nonsense that Arch has been subjected to via systemd-sysusers can be fixed? This should be a simple matter of calling archive_read_disk_set_standard_lookup(archive) prior to extraction. I think agregory has a branch that he's been working on to do this. d
On 01/09/18 at 09:00am, Dave Reisner wrote:
On Mon, Jan 08, 2018 at 03:26:49PM +1000, Allan McRae wrote:
Hi all,
We have not had a release in a long, long time. Lets fix that!
There is a substantial number of bugs tagged for a 5.1 release [1]. These were added when we were all younger and more optimistic about the world... I have added a 5.2 target, so we can start bumping some to a future release.
Please reply here with anything you think is essential to the next release - even better if you provide a patch!
Cheers, Allan
Can we fix extraction based on lookups of user/group so that the nonsense that Arch has been subjected to via systemd-sysusers can be fixed? This should be a simple matter of calling archive_read_disk_set_standard_lookup(archive) prior to extraction. I think agregory has a branch that he's been working on to do this.
I do have a branch to use user/group names, but the change is not simple. It breaks alternate rootdir usage hard. I haven't noticed the systemd-sysusers nonsense myself and only caught bits of IRC discussions, can you elaborate on exactly what the problem is? apg
On 01/10/2018 09:29 AM, Andrew Gregory wrote:
On 01/09/18 at 09:00am, Dave Reisner wrote:
On Mon, Jan 08, 2018 at 03:26:49PM +1000, Allan McRae wrote:
Hi all,
We have not had a release in a long, long time. Lets fix that!
There is a substantial number of bugs tagged for a 5.1 release [1]. These were added when we were all younger and more optimistic about the world... I have added a 5.2 target, so we can start bumping some to a future release.
Please reply here with anything you think is essential to the next release - even better if you provide a patch!
Cheers, Allan
Can we fix extraction based on lookups of user/group so that the nonsense that Arch has been subjected to via systemd-sysusers can be fixed? This should be a simple matter of calling archive_read_disk_set_standard_lookup(archive) prior to extraction. I think agregory has a branch that he's been working on to do this.
I do have a branch to use user/group names, but the change is not simple. It breaks alternate rootdir usage hard. I haven't noticed the systemd-sysusers nonsense myself and only caught bits of IRC discussions, can you elaborate on exactly what the problem is?
users/groups work absolutely fine... just as long as we hardcode uids for any files that need to be packaged with a specific user ownership. And systemd-sysusers isn't really different from useradd in that respect (we still hardcode uids in sysusers files). But while trying to move to sysusers, we've hit "interesting" issues like this: https://bugs.archlinux.org/task/56818 It did not used to be a problem, until we started relying on systemd's own basic.conf to create the "lp" user rather than hardcoding an id in filesystem's /etc/group But if we define our own sysuser with a hardcoded uid, then it will clash with basic.conf... -- Eli Schwartz
On 01/10/18 at 09:58am, Eli Schwartz wrote:
On 01/10/2018 09:29 AM, Andrew Gregory wrote:
On 01/09/18 at 09:00am, Dave Reisner wrote:
On Mon, Jan 08, 2018 at 03:26:49PM +1000, Allan McRae wrote:
Hi all,
We have not had a release in a long, long time. Lets fix that!
There is a substantial number of bugs tagged for a 5.1 release [1]. These were added when we were all younger and more optimistic about the world... I have added a 5.2 target, so we can start bumping some to a future release.
Please reply here with anything you think is essential to the next release - even better if you provide a patch!
Cheers, Allan
Can we fix extraction based on lookups of user/group so that the nonsense that Arch has been subjected to via systemd-sysusers can be fixed? This should be a simple matter of calling archive_read_disk_set_standard_lookup(archive) prior to extraction. I think agregory has a branch that he's been working on to do this.
I do have a branch to use user/group names, but the change is not simple. It breaks alternate rootdir usage hard. I haven't noticed the systemd-sysusers nonsense myself and only caught bits of IRC discussions, can you elaborate on exactly what the problem is?
users/groups work absolutely fine... just as long as we hardcode uids for any files that need to be packaged with a specific user ownership.
And systemd-sysusers isn't really different from useradd in that respect (we still hardcode uids in sysusers files).
But while trying to move to sysusers, we've hit "interesting" issues like this: https://bugs.archlinux.org/task/56818 It did not used to be a problem, until we started relying on systemd's own basic.conf to create the "lp" user rather than hardcoding an id in filesystem's /etc/group
But if we define our own sysuser with a hardcoded uid, then it will clash with basic.conf...
So Arch used a static GID, then accidentally switched to a dynamic GID without the necessary install script update? Seems easy enough to fix by adding the relevant chown calls like every other package with dynamic UIDs/GIDs.
participants (4)
-
Allan McRae
-
Andrew Gregory
-
Dave Reisner
-
Eli Schwartz