Hi!
On Thu, 2024-02-15 at 16:48:43 -0800, Steve Langasek wrote:
> Control: forwarded -1 seli...@vger.kernel.org
>
> Patch now forwarded upstream for review.
>
> https://lore.kernel.org/selinux/zc6tzkpsyzric...@homer.dodds.net/T/#t
> On Wed, Feb 14, 2024 at 11:25:26PM -0800, Steve Langasek
Control: forwarded -1 seli...@vger.kernel.org
Patch now forwarded upstream for review.
https://lore.kernel.org/selinux/zc6tzkpsyzric...@homer.dodds.net/T/#t
On Wed, Feb 14, 2024 at 11:25:26PM -0800, Steve Langasek wrote:
> On Wed, Feb 07, 2024 at 09:06:58AM +0100, Helmut Grohne wrote:
> > On
On Wed, Feb 07, 2024 at 09:06:58AM +0100, Helmut Grohne wrote:
> On Wed, Feb 07, 2024 at 04:32:45AM +0100, Guillem Jover wrote:
> > Yes, I'm not sure I understand either. This is what symbol versioning
> > makes possible, even providing different variants for the same symbol,
> > see for example
> "Helmut" == Helmut Grohne writes:
Helmut> pam seems difficult: | extern time_t
Helmut> pam_misc_conv_warn_time; /* time that we should warn user */
Helmut> | extern time_t pam_misc_conv_die_time; /* cut-off time for
Helmut> input */
Helmut> We cannot symbol-version
06.02.2024 12:34, Helmut Grohne:
...
An option I see here is to provide ABI-duality for libselinux:
-extern int matchpathcon_filespec_add(ino_t ino, int specind, const char *file);
+typedef unsigned long libselinux_ino_t;
+typedef uint64_t libselinux_ino64_t;
+extern int
07.02.2024 11:06, Helmut Grohne :
..
pam seems difficult:
| extern time_t pam_misc_conv_warn_time; /* time that we should warn user */
| extern time_t pam_misc_conv_die_time; /* cut-off time for input */
Attached is a sketch to make pam compatible.
I had a more complete and *tested*
Hi Andreas,
On Wed, Feb 07, 2024 at 03:47:37PM +0100, Andreas Metzler wrote:
> Package: libselinux1t64
> Replaces: libselinux1
> Provides: libselinux1 (= 3.5-2.1~exp1)
> Breaks: libselinux1 (<< 3.5-2.1~exp1)
>
> Afaiui libselinux1t64 must not fullfill dpkg 1.22.4's dependency on
> "libselinux1
On 2024-02-06 Helmut Grohne wrote:
> Package: libselinux1t64
[...]> This looks fairly innocuous. We create a minimal sid chroot and install
> libselinux1t64 using apt. What could possibly go wrong? Well, apt thinks
> that it would be a good idea to avoid coinstalling breaking packages and
>
Hi Guillem,
On Wed, Feb 07, 2024 at 04:32:45AM +0100, Guillem Jover wrote:
> Yes, I'm not sure I understand either. This is what symbol versioning
> makes possible, even providing different variants for the same symbol,
> see for example glibc or libbsd.
I think symbol versioning is subtly
Hi!
On Tue, 2024-02-06 at 15:42:33 +0100, Helmut Grohne wrote:
> On Tue, Feb 06, 2024 at 11:34:07AM +0100, Adrien Nader wrote:
> > Providing two APIs makes me quite uneasy due to having core components
> > that would behave differently from the rest of the distribution. It
> > sounds like
On Tue, Feb 06, 2024 at 11:34:07AM +0100, Adrien Nader wrote:
> Providing two APIs makes me quite uneasy due to having core components
> that would behave differently from the rest of the distribution. It
> sounds like something that will come back to bite for a long time.
Can you elaborate?
Hi Helmut,
Thanks for identifying and raising this issue.
After Graham mentioned this to me, I also looked at the reports and came
to the same conclusion: the change is actually LFS due to ino_t in
matchpathcon_filespec_add().
Providing two APIs makes me quite uneasy due to having core
Package: libselinux1t64
Version: 3.5-2.1~exp1
Severity: grave
X-Debbugs-Cc: vor...@debian.org, debian-de...@lists.debian.org
Hi,
I was looking into performing an upgrade test of libselinux1 with
piuparts and that didn't go well. I spare you the piuparts stuff and go
into crafting a minimal
13 matches
Mail list logo
