From baggins at pld-linux.org  Mon Aug  8 08:32:05 2022
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Mon, 8 Aug 2022 08:32:05 +0200
Subject: Qt packaging
In-Reply-To: <20220722094316.bwba2bwuldtgnxss@pine.grzadka>
References: <Ytpn+qaJvdDigmkk@starbug>
 <20220722094316.bwba2bwuldtgnxss@pine.grzadka>
Message-ID: <YvCt5ayKY1VDmrlH@starbug.lan>

On Fri, 22 Jul 2022, Jan Palus wrote:

> On 22.07.2022 11:03, Jan R?korajski wrote:
> > Can someone explain why are we using split sources/packages for Qt?
> > 
> > I want to add Qt6 and building from the monolythic source is soooo much
> > easier. No need for bootstrap, no intertwined build dependencies, just
> > configure -> build -> build docs -> install.
> > 
> > And unless there is a _very_ good reason to use split sources I'm just going
> > to add a single qt6 package that builds everything (we can still subpackage
> > bineries as we want them).
> 
> As long as each component is bcondized and there are no "to the exact
> release" dependencies then I guess it's fine. Doing qtwebengine (and all
> the other components) rebuild each time qtbase needs a small packaging
> adjustment would be tough on arm, though I'd understand if nobody cared
> about my use case.

FYI build time on builders is 1.5 hour without qtwebengine and 7 hours
with qtwebengine.

I don't know how it looks on arm, but IMHO no-webengine bcond should be enough?

-- 
Jan R?korajski                    | PLD/Linux
SysAdm | baggins<at>pld-linux.org | http://www.pld-linux.org/


From ngompa13 at gmail.com  Mon Aug  8 09:35:02 2022
From: ngompa13 at gmail.com (Neal Gompa)
Date: Mon, 8 Aug 2022 03:35:02 -0400
Subject: Qt packaging
In-Reply-To: <YvCt5ayKY1VDmrlH@starbug.lan>
References: <Ytpn+qaJvdDigmkk@starbug>
 <20220722094316.bwba2bwuldtgnxss@pine.grzadka>
 <YvCt5ayKY1VDmrlH@starbug.lan>
Message-ID: <CAEg-Je9FEFrCvoS0UM4wxokZz2uMYEGLJw+yTjTAdz+Tts_ETg@mail.gmail.com>

On Mon, Aug 8, 2022 at 2:32 AM Jan R?korajski <baggins at pld-linux.org> wrote:
>
> On Fri, 22 Jul 2022, Jan Palus wrote:
>
> > On 22.07.2022 11:03, Jan R?korajski wrote:
> > > Can someone explain why are we using split sources/packages for Qt?
> > >
> > > I want to add Qt6 and building from the monolythic source is soooo much
> > > easier. No need for bootstrap, no intertwined build dependencies, just
> > > configure -> build -> build docs -> install.
> > >
> > > And unless there is a _very_ good reason to use split sources I'm just going
> > > to add a single qt6 package that builds everything (we can still subpackage
> > > bineries as we want them).
> >
> > As long as each component is bcondized and there are no "to the exact
> > release" dependencies then I guess it's fine. Doing qtwebengine (and all
> > the other components) rebuild each time qtbase needs a small packaging
> > adjustment would be tough on arm, though I'd understand if nobody cared
> > about my use case.
>
> FYI build time on builders is 1.5 hour without qtwebengine and 7 hours
> with qtwebengine.
>
> I don't know how it looks on arm, but IMHO no-webengine bcond should be enough?
>

The reason most distros don't use the monolithic source is that it's a
pain to apply patches to it. Qt doesn't actually get developed that
way, and backporting fixes is more of a pain if you use the monolithic
build.


-- 
?????????/ Always, there's only one truth!


From baggins at pld-linux.org  Mon Aug  8 23:02:58 2022
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Mon, 8 Aug 2022 23:02:58 +0200
Subject: Qt packaging
In-Reply-To: <CAEg-Je9FEFrCvoS0UM4wxokZz2uMYEGLJw+yTjTAdz+Tts_ETg@mail.gmail.com>
References: <Ytpn+qaJvdDigmkk@starbug>
 <20220722094316.bwba2bwuldtgnxss@pine.grzadka>
 <YvCt5ayKY1VDmrlH@starbug.lan>
 <CAEg-Je9FEFrCvoS0UM4wxokZz2uMYEGLJw+yTjTAdz+Tts_ETg@mail.gmail.com>
Message-ID: <YvF6AmOhN63LjIEp@tachikoma.lan>

On Mon, 08 Aug 2022, Neal Gompa wrote:

> On Mon, Aug 8, 2022 at 2:32 AM Jan R?korajski <baggins at pld-linux.org> wrote:
> >
> > On Fri, 22 Jul 2022, Jan Palus wrote:
> >
> > > On 22.07.2022 11:03, Jan R?korajski wrote:
> > > > Can someone explain why are we using split sources/packages for Qt?
> > > >
> > > > I want to add Qt6 and building from the monolythic source is soooo much
> > > > easier. No need for bootstrap, no intertwined build dependencies, just
> > > > configure -> build -> build docs -> install.
> > > >
> > > > And unless there is a _very_ good reason to use split sources I'm just going
> > > > to add a single qt6 package that builds everything (we can still subpackage
> > > > bineries as we want them).
> > >
> > > As long as each component is bcondized and there are no "to the exact
> > > release" dependencies then I guess it's fine. Doing qtwebengine (and all
> > > the other components) rebuild each time qtbase needs a small packaging
> > > adjustment would be tough on arm, though I'd understand if nobody cared
> > > about my use case.
> >
> > FYI build time on builders is 1.5 hour without qtwebengine and 7 hours
> > with qtwebengine.
> >
> > I don't know how it looks on arm, but IMHO no-webengine bcond should be enough?
> >
> 
> The reason most distros don't use the monolithic source is that it's a
> pain to apply patches to it. Qt doesn't actually get developed that
> way, and backporting fixes is more of a pain if you use the monolithic
> build.

Well, we don't have resources to play with backporting changes.
Besides I saw have ex. Fedora packages qt and it is IMO a joke. They don't
build docs, they don't build internal deps, so yeah, it's easy, but it's
half of the functionality.

I'd rather have a package without the backports, but with all bells and
whistles, that is easy to build, rather than either build pain on half
baked.

-- 
Jan R?korajski                    | PLD/Linux
SysAdm | baggins<at>pld-linux.org | http://www.pld-linux.org/


From atler at pld-linux.org  Mon Aug  8 23:10:13 2022
From: atler at pld-linux.org (Jan Palus)
Date: Mon, 8 Aug 2022 23:10:13 +0200
Subject: Qt packaging
In-Reply-To: <YvCt5ayKY1VDmrlH@starbug.lan>
References: <Ytpn+qaJvdDigmkk@starbug>
 <20220722094316.bwba2bwuldtgnxss@pine.grzadka>
 <YvCt5ayKY1VDmrlH@starbug.lan>
Message-ID: <20220808211013.cze3jh4o4reny5np@pine.grzadka>

On 08.08.2022 08:32, Jan R?korajski wrote:
> On Fri, 22 Jul 2022, Jan Palus wrote:
> 
> > On 22.07.2022 11:03, Jan R?korajski wrote:
> > > Can someone explain why are we using split sources/packages for Qt?
> > > 
> > > I want to add Qt6 and building from the monolythic source is soooo much
> > > easier. No need for bootstrap, no intertwined build dependencies, just
> > > configure -> build -> build docs -> install.
> > > 
> > > And unless there is a _very_ good reason to use split sources I'm just going
> > > to add a single qt6 package that builds everything (we can still subpackage
> > > bineries as we want them).
> > 
> > As long as each component is bcondized and there are no "to the exact
> > release" dependencies then I guess it's fine. Doing qtwebengine (and all
> > the other components) rebuild each time qtbase needs a small packaging
> > adjustment would be tough on arm, though I'd understand if nobody cared
> > about my use case.
> 
> FYI build time on builders is 1.5 hour without qtwebengine and 7 hours
> with qtwebengine.
> 
> I don't know how it looks on arm, but IMHO no-webengine bcond should be enough?

Multiply it by ~4 and it's roughly result for arm. The first part I
mean, qtwebengine is so heavy that I build it in AWS.

Anyway no worries, if needed I can add more bconds myself. And thanks a
lot for working on qt6!


From baggins at pld-linux.org  Mon Aug  8 23:34:36 2022
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Mon, 8 Aug 2022 23:34:36 +0200
Subject: Qt packaging
In-Reply-To: <20220808211013.cze3jh4o4reny5np@pine.grzadka>
References: <Ytpn+qaJvdDigmkk@starbug>
 <20220722094316.bwba2bwuldtgnxss@pine.grzadka>
 <YvCt5ayKY1VDmrlH@starbug.lan>
 <20220808211013.cze3jh4o4reny5np@pine.grzadka>
Message-ID: <YvGBbBc7MSVpg4Zl@tachikoma.lan>

On Mon, 08 Aug 2022, Jan Palus wrote:

> On 08.08.2022 08:32, Jan R?korajski wrote:
> > On Fri, 22 Jul 2022, Jan Palus wrote:
> > 
> > > On 22.07.2022 11:03, Jan R?korajski wrote:
> > > > Can someone explain why are we using split sources/packages for Qt?
> > > > 
> > > > I want to add Qt6 and building from the monolythic source is soooo much
> > > > easier. No need for bootstrap, no intertwined build dependencies, just
> > > > configure -> build -> build docs -> install.
> > > > 
> > > > And unless there is a _very_ good reason to use split sources I'm just going
> > > > to add a single qt6 package that builds everything (we can still subpackage
> > > > bineries as we want them).
> > > 
> > > As long as each component is bcondized and there are no "to the exact
> > > release" dependencies then I guess it's fine. Doing qtwebengine (and all
> > > the other components) rebuild each time qtbase needs a small packaging
> > > adjustment would be tough on arm, though I'd understand if nobody cared
> > > about my use case.
> > 
> > FYI build time on builders is 1.5 hour without qtwebengine and 7 hours
> > with qtwebengine.
> > 
> > I don't know how it looks on arm, but IMHO no-webengine bcond should be enough?
> 
> Multiply it by ~4 and it's roughly result for arm. The first part I
> mean, qtwebengine is so heavy that I build it in AWS.
> 
> Anyway no worries, if needed I can add more bconds myself. And thanks a
> lot for working on qt6!

Thanks, it's a slow and painful process, and we'll end up with less
granularity, at least at the beginning. What I want now, is a MVP to be able
to build current calibre :/

Out of curiosity, would webengine even build on arm? What I see it
building is full blown blink/chromium engine. And this thing has lots
of fancy dependencies, both software and hardware.

-- 
Jan R?korajski                    | PLD/Linux
SysAdm | baggins<at>pld-linux.org | http://www.pld-linux.org/


From atler at pld-linux.org  Mon Aug  8 23:55:22 2022
From: atler at pld-linux.org (Jan Palus)
Date: Mon, 8 Aug 2022 23:55:22 +0200
Subject: Qt packaging
In-Reply-To: <YvGBbBc7MSVpg4Zl@tachikoma.lan>
References: <Ytpn+qaJvdDigmkk@starbug>
 <20220722094316.bwba2bwuldtgnxss@pine.grzadka>
 <YvCt5ayKY1VDmrlH@starbug.lan>
 <20220808211013.cze3jh4o4reny5np@pine.grzadka>
 <YvGBbBc7MSVpg4Zl@tachikoma.lan>
Message-ID: <20220808215522.mksqfvji7cfqb6tl@kalarepa.grzadka>

On 08.08.2022 23:34, Jan R?korajski wrote:
> On Mon, 08 Aug 2022, Jan Palus wrote:
> 
> > On 08.08.2022 08:32, Jan R?korajski wrote:
> > > On Fri, 22 Jul 2022, Jan Palus wrote:
> > > 
> > > > On 22.07.2022 11:03, Jan R?korajski wrote:
> > > > > Can someone explain why are we using split sources/packages for Qt?
> > > > > 
> > > > > I want to add Qt6 and building from the monolythic source is soooo much
> > > > > easier. No need for bootstrap, no intertwined build dependencies, just
> > > > > configure -> build -> build docs -> install.
> > > > > 
> > > > > And unless there is a _very_ good reason to use split sources I'm just going
> > > > > to add a single qt6 package that builds everything (we can still subpackage
> > > > > bineries as we want them).
> > > > 
> > > > As long as each component is bcondized and there are no "to the exact
> > > > release" dependencies then I guess it's fine. Doing qtwebengine (and all
> > > > the other components) rebuild each time qtbase needs a small packaging
> > > > adjustment would be tough on arm, though I'd understand if nobody cared
> > > > about my use case.
> > > 
> > > FYI build time on builders is 1.5 hour without qtwebengine and 7 hours
> > > with qtwebengine.
> > > 
> > > I don't know how it looks on arm, but IMHO no-webengine bcond should be enough?
> > 
> > Multiply it by ~4 and it's roughly result for arm. The first part I
> > mean, qtwebengine is so heavy that I build it in AWS.
> > 
> > Anyway no worries, if needed I can add more bconds myself. And thanks a
> > lot for working on qt6!
> 
> Thanks, it's a slow and painful process, and we'll end up with less
> granularity, at least at the beginning. What I want now, is a MVP to be able
> to build current calibre :/
> 
> Out of curiosity, would webengine even build on arm? What I see it
> building is full blown blink/chromium engine. And this thing has lots
> of fancy dependencies, both software and hardware.

Just to be clear when I said "arm" I really meant "aarch64", 32-bit
version of qtwebengine is of not much interest to me. And at least
qtwebengine 5.x builds just fine for aarch64 and using it daily as my
primary web browsing engine. I don't expect qt6 to be much different but
haven't tried to build it so far.


From qboosh at pld-linux.org  Tue Aug 16 20:31:18 2022
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Tue, 16 Aug 2022 20:31:18 +0200
Subject: glibc 2.36 *.o files debug extraction broken
Message-ID: <20220816183118.GA6131@stranger.qboosh.pl>

In glibc 2.36 build debuginfo extraction process removes .note.GNU-stack
section:

(before installing)
$ objdump -h ../BUILD/glibc-2.36.debuginfo/builddir/csu/crtn.o

../BUILD/glibc-2.36.debuginfo/builddir/csu/crtn.o:     file format elf32-i386

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00000000  00000000  00000000  00000034  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .data         00000000  00000000  00000000  00000034  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          00000000  00000000  00000000  00000034  2**0
                  ALLOC
  3 .note.gnu.property 00000044  00000000  00000000  00000034  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .init         00000005  00000000  00000000  00000078  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  5 .fini         00000005  00000000  00000000  0000007d  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  6 .note.GNU-stack 00000000  00000000  00000000  00000082  2**0
                  CONTENTS, READONLY
  7 .debug_line   0000005a  00000000  00000000  00000084  2**0
                  CONTENTS, RELOC, READONLY, DEBUGGING, OCTETS
  8 .debug_info   00000022  00000000  00000000  000000d9  2**0
                  CONTENTS, RELOC, READONLY, DEBUGGING, OCTETS
  9 .debug_abbrev 00000012  00000000  00000000  000000fb  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS
 10 .debug_aranges 00000028  00000000  00000000  00000110  2**3
                  CONTENTS, RELOC, READONLY, DEBUGGING, OCTETS
 11 .debug_str    0000004f  00000000  00000000  00000133  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS
 12 .debug_ranges 00000020  00000000  00000000  00000184  2**3
                  CONTENTS, RELOC, READONLY, DEBUGGING, OCTETS

(after)
/home/users/qboosh/tmp/glibc-2.36-i686-root-qboosh.debuginfo/usr/lib/crtn.o:     file format elf32-i386

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00000000  00000000  00000000  00000034  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .data         00000000  00000000  00000000  00000034  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          00000000  00000000  00000000  00000034  2**0
                  ALLOC
  3 .note.gnu.property 00000044  00000000  00000000  00000034  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .init         00000005  00000000  00000000  00000078  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  5 .fini         00000005  00000000  00000000  0000007d  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  6 .gnu_debuglink 00000020  00000000  00000000  00000084  2**2
                  CONTENTS, READONLY


With debuginfo packages disabled, .note.GNU-stack section is still present.

It results in binaries executable stack and linker features misdetection
due to new warning:

/usr/bin/ld: warning: /usr/lib/gcc/i686-pld-linux/11.3.0/../../../crtn.o: missing .note.GNU-stack section implies executable stack
/usr/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker

affecting e.g. gjs:

Compiler for C++ supports link arguments -Bsymbolic-functions: NO

meson.build:78:12: ERROR: Problem encountered: -Bsymbolic-functions not supported, configure with
-Dbsymbolic_functions=false

or gcab:
Compiler for C supports link arguments -Wl,-z,relro: NO
Compiler for C supports link arguments -Wl,-z,now: NO
+ missing symbol versioning

For now only i686 builds are affected because x86_64 and x32 glibc-devel packages
haven't been updated on builders.


Any guesses what changed?


-- 
Jakub Bogusz    http://qboosh.pl/


From atler at pld-linux.org  Tue Aug 16 21:28:58 2022
From: atler at pld-linux.org (Jan Palus)
Date: Tue, 16 Aug 2022 21:28:58 +0200
Subject: glibc 2.36 *.o files debug extraction broken
In-Reply-To: <20220816183118.GA6131@stranger.qboosh.pl>
References: <20220816183118.GA6131@stranger.qboosh.pl>
Message-ID: <20220816192858.75bptyyhgq35olse@pine.grzadka>

On 16.08.2022 20:31, Jakub Bogusz wrote:
> In glibc 2.36 build debuginfo extraction process removes .note.GNU-stack
> section:

...

> For now only i686 builds are affected because x86_64 and x32 glibc-devel packages
> haven't been updated on builders.
> 
> 
> Any guesses what changed?

I believe to be responsible for this, specifically with this debugedit
commit:

commit bd392272c04d608257eb999670d85261d5125d93
Author: Jan Palus <atler at pld-linux.org>
Date:   Tue Jun 7 11:39:01 2022

    bring back patch from rpm 4.16 for no exe bit when searching debuginfo; rel 2

which now considers non-executable object file matching pattern
found in `find-debuginfo`: ^\(.*\):[   ]*.*ELF.*, not stripped.*

Which in turn causes object file to be passed to `eu-strip` directly
responsible for stripping .note.GNU-stack section.

Fix proposals:

1. modify `find-debuginfo` pattern to include ELF.*\(executable\|shared object\)
2. modify macros to invoke `find-debuginfo` with `--keep-section .note.GNU-stack`
3. both 1 and 2

Comments welcome.


From qboosh at pld-linux.org  Tue Aug 16 21:53:40 2022
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Tue, 16 Aug 2022 21:53:40 +0200
Subject: glibc 2.36 *.o files debug extraction broken
In-Reply-To: <20220816192858.75bptyyhgq35olse@pine.grzadka>
References: <20220816183118.GA6131@stranger.qboosh.pl>
 <20220816192858.75bptyyhgq35olse@pine.grzadka>
Message-ID: <20220816195340.GA30327@mail>

On Tue, Aug 16, 2022 at 09:28:58PM +0200, Jan Palus wrote:
> On 16.08.2022 20:31, Jakub Bogusz wrote:
> > In glibc 2.36 build debuginfo extraction process removes .note.GNU-stack
> > section:
> 
> ...
> 
> > For now only i686 builds are affected because x86_64 and x32 glibc-devel packages
> > haven't been updated on builders.
> > 
> > 
> > Any guesses what changed?
> 
> I believe to be responsible for this, specifically with this debugedit
> commit:
> 
> commit bd392272c04d608257eb999670d85261d5125d93
> Author: Jan Palus <atler at pld-linux.org>
> Date:   Tue Jun 7 11:39:01 2022
> 
>     bring back patch from rpm 4.16 for no exe bit when searching debuginfo; rel 2
> 
> which now considers non-executable object file matching pattern
> found in `find-debuginfo`: ^\(.*\):[   ]*.*ELF.*, not stripped.*
> 
> Which in turn causes object file to be passed to `eu-strip` directly
> responsible for stripping .note.GNU-stack section.
> 
> Fix proposals:
> 
> 1. modify `find-debuginfo` pattern to include ELF.*\(executable\|shared object\)
> 2. modify macros to invoke `find-debuginfo` with `--keep-section .note.GNU-stack`
> 3. both 1 and 2

I think it would be safer to revert to not touching *.o files (by
default).

BTW, why find-debuginfo removes .note.GNU-stack from *.o and doesn't remove
from *.a/*.so?


-- 
Jakub Bogusz    http://qboosh.pl/


From atler at pld-linux.org  Tue Aug 16 23:01:23 2022
From: atler at pld-linux.org (Jan Palus)
Date: Tue, 16 Aug 2022 23:01:23 +0200
Subject: glibc 2.36 *.o files debug extraction broken
In-Reply-To: <20220816195340.GA30327@mail>
References: <20220816183118.GA6131@stranger.qboosh.pl>
 <20220816192858.75bptyyhgq35olse@pine.grzadka>
 <20220816195340.GA30327@mail>
Message-ID: <20220816210123.x53arwir3ytwcoqr@pine.grzadka>

On 16.08.2022 21:53, Jakub Bogusz wrote:
> On Tue, Aug 16, 2022 at 09:28:58PM +0200, Jan Palus wrote:
> > On 16.08.2022 20:31, Jakub Bogusz wrote:
> > > In glibc 2.36 build debuginfo extraction process removes .note.GNU-stack
> > > section:
> > 
> > ...
> > 
> > > For now only i686 builds are affected because x86_64 and x32 glibc-devel packages
> > > haven't been updated on builders.
> > > 
> > > 
> > > Any guesses what changed?
> > 
> > I believe to be responsible for this, specifically with this debugedit
> > commit:
> > 
> > commit bd392272c04d608257eb999670d85261d5125d93
> > Author: Jan Palus <atler at pld-linux.org>
> > Date:   Tue Jun 7 11:39:01 2022
> > 
> >     bring back patch from rpm 4.16 for no exe bit when searching debuginfo; rel 2
> > 
> > which now considers non-executable object file matching pattern
> > found in `find-debuginfo`: ^\(.*\):[   ]*.*ELF.*, not stripped.*
> > 
> > Which in turn causes object file to be passed to `eu-strip` directly
> > responsible for stripping .note.GNU-stack section.
> > 
> > Fix proposals:
> > 
> > 1. modify `find-debuginfo` pattern to include ELF.*\(executable\|shared object\)
> > 2. modify macros to invoke `find-debuginfo` with `--keep-section .note.GNU-stack`
> > 3. both 1 and 2
> 
> I think it would be safer to revert to not touching *.o files (by
> default).

For the time being implemented 1. not to regress packages initial fix
was done for.

> BTW, why find-debuginfo removes .note.GNU-stack from *.o and doesn't remove
> from *.a/*.so?

To be precise it's eu-strip that find-debuginfo invokes. Regarding
actual question these are two different things:

object files (*.o) hold information for linker in .note.GNU-stack
section of ELF file. Linker uses this information when creating shared
objects (*.so) or executables to construct GNU_STACK program header in
output ELF file. GNU_STACK is in turn used by kernel. eu-strip does not
touch ELF program headers at all so it's plain copy. It only operates on
ELF sections. So that's why executable/so files are not affected. (note
that mentioned archives (*.a) are not considered for debuginfo
extraction).

I see a comment in elfutils strip code that intention was to keep all
ELF notes, which while implemented, does not affect .note.GNU-stack.
Most notes appear to be of type SHT_NOTE (that's what implementation
relies on) however .note.GNU-stack is of type SHT_PROGBITS (ref elf(5)).
I will raise a question to elfutils whether this is intended.


From j.rekorajski at gmail.com  Wed Aug 31 11:27:46 2022
From: j.rekorajski at gmail.com (=?UTF-8?Q?Jan_R=C4=99korajski?=)
Date: Wed, 31 Aug 2022 11:27:46 +0200
Subject: [packages/rpm-build-tools] builder: don't bother going back to
 original $(pwd) at the end of script
In-Reply-To: <b1e8c12b2d66e7aadd9bb2c0d1acfc612d50aa22_refs_heads_master@pld-linux.org>
References: <26a8e92fe9016c4060d3b7ccca84a02cadd02488_refs_heads_master@pld-linux.org>
 <b1e8c12b2d66e7aadd9bb2c0d1acfc612d50aa22_refs_heads_master@pld-linux.org>
Message-ID: <CAKY5yHwbo2Wtfy9riS1kbuEDTg62MGJZpKvp8a=vV6Gi2dCGGg@mail.gmail.com>

Where will it land now? If you want to protect against landing in
non-existing directory you can use '[ -d "$__PWD" ] && cd "$__PWD"'
I really prefer to be staying in the same directory where I launched
the script in.

On Wed, Aug 31, 2022 at 12:59 AM atler <atler at pld-linux.org> wrote:
>
> commit b1e8c12b2d66e7aadd9bb2c0d1acfc612d50aa22
> Author: Jan Palus <atler at pld-linux.org>
> Date:   Wed Aug 31 00:55:46 2022 +0200
>
>     builder: don't bother going back to original $(pwd) at the end of script
>
>     no real use for it as far as I can tell and ditching it avoids error if
>     original working directory does not exist anymore (because ie it
>     happened to be $RPM_BUILD_ROOT)
>
>  builder.sh | 1 -
>  1 file changed, 1 deletion(-)
> ---
> diff --git a/builder.sh b/builder.sh
> index 058d0de..68bb875 100755
> --- a/builder.sh
> +++ b/builder.sh
> @@ -2756,6 +2756,5 @@ esac
>  if [ -f "`pwd`/.${SPECFILE}_INSTALLED_PACKAGES" -a "$REMOVE_BUILD_REQUIRES" != "" ]; then
>         rm "`pwd`/.${SPECFILE}_INSTALLED_PACKAGES"
>  fi
> -cd "$__PWD"
>
>  # vi:syntax=sh:ts=4:sw=4:noet
> ================================================================
>
> ---- gitweb:
>
> http://git.pld-linux.org/gitweb.cgi/packages/rpm-build-tools.git/commitdiff/b1e8c12b2d66e7aadd9bb2c0d1acfc612d50aa22
>
> _______________________________________________
> pld-cvs-commit mailing list
> pld-cvs-commit at lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit



-- 
Jan R?korajski | SysAdm | PLD/Linux | http://www.pld-linux.org/
baggins<at>pld-linux.org


From atler at pld-linux.org  Wed Aug 31 11:36:40 2022
From: atler at pld-linux.org (Jan Palus)
Date: Wed, 31 Aug 2022 11:36:40 +0200
Subject: [packages/rpm-build-tools] builder: don't bother going back to
 original $(pwd) at the end of script
In-Reply-To: <CAKY5yHwbo2Wtfy9riS1kbuEDTg62MGJZpKvp8a=vV6Gi2dCGGg@mail.gmail.com>
References: <26a8e92fe9016c4060d3b7ccca84a02cadd02488_refs_heads_master@pld-linux.org>
 <b1e8c12b2d66e7aadd9bb2c0d1acfc612d50aa22_refs_heads_master@pld-linux.org>
 <CAKY5yHwbo2Wtfy9riS1kbuEDTg62MGJZpKvp8a=vV6Gi2dCGGg@mail.gmail.com>
Message-ID: <20220831093640.deknalyxzw25pzy2@pine.grzadka>

On 31.08.2022 11:27, Jan R?korajski wrote:
> Where will it land now? If you want to protect against landing in
> non-existing directory you can use '[ -d "$__PWD" ] && cd "$__PWD"'
> I really prefer to be staying in the same directory where I launched
> the script in.

I considered doing `test -d` but since this new old $PWD doesn't affect
any other command I've just dropped it entirely. I will bring it back
with test then.

> On Wed, Aug 31, 2022 at 12:59 AM atler <atler at pld-linux.org> wrote:
> >
> > commit b1e8c12b2d66e7aadd9bb2c0d1acfc612d50aa22
> > Author: Jan Palus <atler at pld-linux.org>
> > Date:   Wed Aug 31 00:55:46 2022 +0200
> >
> >     builder: don't bother going back to original $(pwd) at the end of script
> >
> >     no real use for it as far as I can tell and ditching it avoids error if
> >     original working directory does not exist anymore (because ie it
> >     happened to be $RPM_BUILD_ROOT)
> >
> >  builder.sh | 1 -
> >  1 file changed, 1 deletion(-)
> > ---
> > diff --git a/builder.sh b/builder.sh
> > index 058d0de..68bb875 100755
> > --- a/builder.sh
> > +++ b/builder.sh
> > @@ -2756,6 +2756,5 @@ esac
> >  if [ -f "`pwd`/.${SPECFILE}_INSTALLED_PACKAGES" -a "$REMOVE_BUILD_REQUIRES" != "" ]; then
> >         rm "`pwd`/.${SPECFILE}_INSTALLED_PACKAGES"
> >  fi
> > -cd "$__PWD"
> >
> >  # vi:syntax=sh:ts=4:sw=4:noet
> > ================================================================
> >
> > ---- gitweb:
> >
> > http://git.pld-linux.org/gitweb.cgi/packages/rpm-build-tools.git/commitdiff/b1e8c12b2d66e7aadd9bb2c0d1acfc612d50aa22
> >
> > _______________________________________________
> > pld-cvs-commit mailing list
> > pld-cvs-commit at lists.pld-linux.org
> > http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit
> 
> 
> 
> -- 
> Jan R?korajski | SysAdm | PLD/Linux | http://www.pld-linux.org/
> baggins<at>pld-linux.org
> _______________________________________________
> pld-devel-pl mailing list
> pld-devel-pl at lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


From arekm at maven.pl  Wed Aug 31 11:41:01 2022
From: arekm at maven.pl (=?UTF-8?Q?Arkadiusz_Mi=c5=9bkiewicz?=)
Date: Wed, 31 Aug 2022 11:41:01 +0200
Subject: [packages/rpm-build-tools] builder: don't bother going back to
 original $(pwd) at the end of script
In-Reply-To: <CAKY5yHwbo2Wtfy9riS1kbuEDTg62MGJZpKvp8a=vV6Gi2dCGGg@mail.gmail.com>
References: <26a8e92fe9016c4060d3b7ccca84a02cadd02488_refs_heads_master@pld-linux.org>
 <b1e8c12b2d66e7aadd9bb2c0d1acfc612d50aa22_refs_heads_master@pld-linux.org>
 <CAKY5yHwbo2Wtfy9riS1kbuEDTg62MGJZpKvp8a=vV6Gi2dCGGg@mail.gmail.com>
Message-ID: <d8382f47-070a-f944-9ee7-58f4fc3e2b49@maven.pl>

On 31.08.2022 11:27, Jan R?korajski wrote:
> Where will it land now? If you want to protect against landing in
> non-existing directory you can use '[ -d "$__PWD" ] && cd "$__PWD"'
> I really prefer to be staying in the same directory where I launched
> the script in.

Do you include (via source/dot) this script in some other script?

-- 
Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org )



From j.rekorajski at gmail.com  Wed Aug 31 12:21:19 2022
From: j.rekorajski at gmail.com (=?UTF-8?Q?Jan_R=C4=99korajski?=)
Date: Wed, 31 Aug 2022 12:21:19 +0200
Subject: [packages/rpm-build-tools] builder: don't bother going back to
 original $(pwd) at the end of script
In-Reply-To: <d8382f47-070a-f944-9ee7-58f4fc3e2b49@maven.pl>
References: <26a8e92fe9016c4060d3b7ccca84a02cadd02488_refs_heads_master@pld-linux.org>
 <b1e8c12b2d66e7aadd9bb2c0d1acfc612d50aa22_refs_heads_master@pld-linux.org>
 <CAKY5yHwbo2Wtfy9riS1kbuEDTg62MGJZpKvp8a=vV6Gi2dCGGg@mail.gmail.com>
 <d8382f47-070a-f944-9ee7-58f4fc3e2b49@maven.pl>
Message-ID: <CAKY5yHxsNf8ymZyx6iES2MFcTaYOS3hQaphSi2bEfnXA7ps0DQ@mail.gmail.com>

On Wed, Aug 31, 2022 at 11:41 AM Arkadiusz Mi?kiewicz via pld-devel-en
<pld-devel-en at lists.pld-linux.org> wrote:
>
> On 31.08.2022 11:27, Jan R?korajski wrote:
> > Where will it land now? If you want to protect against landing in
> > non-existing directory you can use '[ -d "$__PWD" ] && cd "$__PWD"'
> > I really prefer to be staying in the same directory where I launched
> > the script in.
>
> Do you include (via source/dot) this script in some other script?

No, command line.
My common workflow is cd $package; hack spec; builder ... (often with
--short-circuit) and back to hacking.

-- 
Jan R?korajski | SysAdm | PLD/Linux | http://www.pld-linux.org/
baggins<at>pld-linux.org


From elan.ruusamae at gmail.com  Wed Aug 31 13:43:35 2022
From: elan.ruusamae at gmail.com (=?utf-8?Q?Elan_Ruusam=C3=A4e?=)
Date: Wed, 31 Aug 2022 14:43:35 +0300
Subject: [packages/rpm-build-tools] builder: don't bother going back to
 original $(pwd) at the end of script
In-Reply-To: <CAKY5yHxsNf8ymZyx6iES2MFcTaYOS3hQaphSi2bEfnXA7ps0DQ@mail.gmail.com>
References: <26a8e92fe9016c4060d3b7ccca84a02cadd02488_refs_heads_master@pld-linux.org>
 <b1e8c12b2d66e7aadd9bb2c0d1acfc612d50aa22_refs_heads_master@pld-linux.org>
 <CAKY5yHwbo2Wtfy9riS1kbuEDTg62MGJZpKvp8a=vV6Gi2dCGGg@mail.gmail.com>
 <d8382f47-070a-f944-9ee7-58f4fc3e2b49@maven.pl>
 <CAKY5yHxsNf8ymZyx6iES2MFcTaYOS3hQaphSi2bEfnXA7ps0DQ@mail.gmail.com>
Message-ID: <F5939C64-58D4-4AB2-A4D0-689ED82C8304@gmail.com>



> On 31. Aug 2022, at 13:21, Jan R?korajski <j.rekorajski at gmail.com> wrote:
> 
> On Wed, Aug 31, 2022 at 11:41 AM Arkadiusz Mi?kiewicz via pld-devel-en
> <pld-devel-en at lists.pld-linux.org> wrote:
>> 
>> On 31.08.2022 11:27, Jan R?korajski wrote:
>>> Where will it land now? If you want to protect against landing in
>>> non-existing directory you can use '[ -d "$__PWD" ] && cd "$__PWD"'
>>> I really prefer to be staying in the same directory where I launched
>>> the script in.
>> 
>> Do you include (via source/dot) this script in some other script?
> 
> No, command line.
> My common workflow is cd $package; hack spec; builder ... (often with
> --short-circuit) and back to hacking.

So the working dir restore is irrelevant. As it?s in builder script, doesn?t affect any external shell.