Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.bugs.dist > #1137243 > unrolled thread

Bug#1030998: [PATCH] dietlibc: Drop hppa/parisc specific MADV_* constants

Started byHelge Deller <deller@gmx.de>
First post2023-02-10 11:00 +0100
Last post2023-02-10 16:50 +0100
Articles 8 — 2 participants

Back to article view | Back to linux.debian.bugs.dist


Contents

  Bug#1030998: [PATCH] dietlibc: Drop hppa/parisc specific MADV_* constants Helge Deller <deller@gmx.de> - 2023-02-10 11:00 +0100
    Bug#1030998: [PATCH] dietlibc: Drop hppa/parisc specific MADV_* constants Thorsten Glaser <tg@mirbsd.de> - 2023-02-10 15:40 +0100
      Bug#1030998: [PATCH] dietlibc: Drop hppa/parisc specific MADV_* constants Helge Deller <deller@gmx.de> - 2023-02-10 16:00 +0100
        Bug#1030998: [PATCH] dietlibc: Drop hppa/parisc specific MADV_* constants Thorsten Glaser <tg@mirbsd.de> - 2023-02-10 16:10 +0100
    Bug#1030998: [PATCH] dietlibc: Drop hppa/parisc specific MADV_* constants Helge Deller <deller@gmx.de> - 2023-02-10 16:10 +0100
      Bug#1030998: [PATCH] dietlibc: Drop hppa/parisc specific MADV_* constants Thorsten Glaser <tg@mirbsd.de> - 2023-02-10 16:30 +0100
        Bug#1030998: [PATCH] dietlibc: Drop hppa/parisc specific MADV_* constants Helge Deller <deller@gmx.de> - 2023-02-10 16:30 +0100
          Bug#1030998: [PATCH] dietlibc: Drop hppa/parisc specific MADV_* constants Thorsten Glaser <tg@mirbsd.de> - 2023-02-10 16:50 +0100

#1137243 — Bug#1030998: [PATCH] dietlibc: Drop hppa/parisc specific MADV_* constants

FromHelge Deller <deller@gmx.de>
Date2023-02-10 11:00 +0100
SubjectBug#1030998: [PATCH] dietlibc: Drop hppa/parisc specific MADV_* constants
Message-ID<FXymd-4PdT-25@gated-at.bofh.it>

[Multipart message — attachments visible in raw view] — view raw

Package: dietlibc
Tags: hppa, patch
Version:  0.34~cvs20160606-14

The Linux kernel upstream commit 71bdea6f798b ("parisc: Align parisc
MADV_XXX constants with all other architectures") dropped the
parisc-specific MADV_* values in favour of the same constants as
other architectures. In the same commit a wrapper was added which
translates the old values to the standard MADV_* values to avoid
breakage of existing programs.
This upstream patch has been downported to all stable kernel trees as
well.

This patch now drops the parisc specific constants from dietlibc to
allow newly compliled programs to use the standard MADV_* constants.

Please apply for next upload.

Signed-off-by: Helge Deller <deller@gmx.de>

---

[toc] | [next] | [standalone]


#1137283

FromThorsten Glaser <tg@mirbsd.de>
Date2023-02-10 15:40 +0100
Message-ID<FXCJb-4S44-5@gated-at.bofh.it>
In reply to#1137243
Helge Deller dixit:

>This upstream patch has been downported to all stable kernel trees as
>well.

>Please apply for next upload.

You know that new kernel features have to be in oldstable before
they can be depended on, right?

bye,
//mirabilos
-- 
(gnutls can also be used, but if you are compiling lynx for your own use,
there is no reason to consider using that package)
	-- Thomas E. Dickey on the Lynx mailing list, about OpenSSL

[toc] | [prev] | [next] | [standalone]


#1137287

FromHelge Deller <deller@gmx.de>
Date2023-02-10 16:00 +0100
Message-ID<FXD2y-4Sbq-3@gated-at.bofh.it>
In reply to#1137283
On 2/10/23 15:27, Thorsten Glaser wrote:
> Helge Deller dixit:
>
>> This upstream patch has been downported to all stable kernel trees as
>> well.
>
>> Please apply for next upload.
>
> You know that new kernel features have to be in oldstable before
> they can be depended on, right?

The kernel patch was backported and is in upstream Linux kernel version 6.2,
alternatively stable kernels from versions 6.1.6, 5.15.87, 5.10.163,
5.4.228, 4.19.270 or 4.14.303.

Is that sufficient?

Helge

[toc] | [prev] | [next] | [standalone]


#1137295

FromThorsten Glaser <tg@mirbsd.de>
Date2023-02-10 16:10 +0100
Message-ID<FXDcd-4SuF-5@gated-at.bofh.it>
In reply to#1137287
Helge Deller dixit:

>> You know that new kernel features have to be in oldstable before
>> they can be depended on, right?
>
> The kernel patch was backported and is in upstream Linux kernel version 6.2,
> alternatively stable kernels from versions 6.1.6, 5.15.87, 5.10.163,
> 5.4.228, 4.19.270 or 4.14.303.
>
> Is that sufficient?

No, it needs to have been in the release.

bye,
//mirabilos
-- 
22:20⎜<asarch> The crazy that persists in his craziness becomes a master
22:21⎜<asarch> And the distance between the craziness and geniality is
only measured by the success 18:35⎜<asarch> "Psychotics are consistently
inconsistent. The essence of sanity is to be inconsistently inconsistent

[toc] | [prev] | [next] | [standalone]


#1137291

FromHelge Deller <deller@gmx.de>
Date2023-02-10 16:10 +0100
Message-ID<FXDcd-4SuF-3@gated-at.bofh.it>
In reply to#1137243
On 2/10/23 15:57, Thorsten Glaser wrote:
> Helge Deller dixit:
>
>>> You know that new kernel features have to be in oldstable before
>>> they can be depended on, right?
>>
>> The kernel patch was backported and is in upstream Linux kernel version 6.2,
>> alternatively stable kernels from versions 6.1.6, 5.15.87, 5.10.163,
>> 5.4.228, 4.19.270 or 4.14.303.
>>
>> Is that sufficient?
>
> No, it needs to have been in the release.

Please help me to understand the dependencies you mention.
That patch is targetted for dietlibc in unstable.
Is dietlibc/unstable shipped backwards into oldstable (in which
case I would understand the dependency) ?

Helge

[toc] | [prev] | [next] | [standalone]


#1137298

FromThorsten Glaser <tg@mirbsd.de>
Date2023-02-10 16:30 +0100
Message-ID<FXDvA-4SBl-3@gated-at.bofh.it>
In reply to#1137291
Helge Deller dixit:

>> No, it needs to have been in the release.
>
> Please help me to understand the dependencies you mention.
> That patch is targetted for dietlibc in unstable.
> Is dietlibc/unstable shipped backwards into oldstable (in which

No, but Debian supports partial upgrades in both directions.
At least in stable, I recall reading oldstable somewhere.
Especially buildds tend to run old kernels, for quite a while,
and releases are the only way Debian has to define boundaries
(even if this isn’t a release arch).

bye,
//mirabilos
-- 
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
	-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)

[toc] | [prev] | [next] | [standalone]


#1137299

FromHelge Deller <deller@gmx.de>
Date2023-02-10 16:30 +0100
Message-ID<FXDvA-4SBl-9@gated-at.bofh.it>
In reply to#1137298
On 2/10/23 16:16, Thorsten Glaser wrote:
> Helge Deller dixit:
>
>>> No, it needs to have been in the release.
>>
>> Please help me to understand the dependencies you mention.
>> That patch is targetted for dietlibc in unstable.
>> Is dietlibc/unstable shipped backwards into oldstable (in which
>
> No, but Debian supports partial upgrades in both directions.> At least in stable, I recall reading oldstable somewhere.
> Especially buildds tend to run old kernels, for quite a while,
> and releases are the only way Debian has to define boundaries
> (even if this isn’t a release arch).

Ok, so we have to wait until at least the oldstable kernels are "new" enough.
Is it ok to keep this bug report open for - let's say -
a year or so, and then apply it.

Helge

[toc] | [prev] | [next] | [standalone]


#1137301

FromThorsten Glaser <tg@mirbsd.de>
Date2023-02-10 16:50 +0100
Message-ID<FXDOV-4SHZ-3@gated-at.bofh.it>
In reply to#1137299
Helge Deller dixit:

> Is it ok to keep this bug report open for - let's say -
> a year or so, and then apply it.

Sure, why not?

bye,
//mirabilos
-- 
15:41⎜<Lo-lan-do:#fusionforge> Somebody write a testsuite for helloworld :-)

[toc] | [prev] | [standalone]


Back to top | Article view | linux.debian.bugs.dist


csiph-web