Re: heimdal vs mit krb5
On Tue, Aug 27, 2024 at 6:04 PM Jan Rękorajski wrote:
>
> On Tue, 27 Aug 2024, Arkadiusz Miśkiewicz via pld-devel-en wrote:
>
> >
> > Recent postgresql versions require things ("MIT Credential Store") that
> > do not exist in current heimdal 7.8.
> >
> > heimdal 8 is expected to have that (commits are in repository) but I
> > don't see it coming especially that latest heimdal release is from 2022.
> >
> > Should we just switch in Th to maintained implementation - mit krb 5
> > (latest release jun 2024) instead?
>
> The reason we had heimdal instead of MIT was samba 4.0 that needed it.
> Since AFAIR we build samba with internal heimdal for long time I don't
> have anything against switching to MIT.
>
> Queston is - are you going to take care of all rebuilds and deps?
IIRC, these days samba-dc works fine with MIT krb5 too. Samba in
Fedora is built with it and it seems to work okay. You could get away
without using heimdal krb5 entirely.
--
真実はいつも一つ！/ Always, there's only one truth!
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: %_usrlibrpm macro gone
On Mon, Sep 19, 2022 at 6:08 PM Elan Ruusamäe wrote:
>
> rpm-4.17.1.1-1.x86_64
>
> dokuwiki* packages don’t build due that:
>
> ```
>
> + %{_usrlibrpm}/dokuwiki-find-lang.sh
> /home/users/glen/tmp/dokuwiki-20180422c-x86_64-root-glen dokuwiki.lang
> /home/users/glen/tmp/rpm-tmp.oRtxaL[82]: %{_usrlibrpm}/dokuwiki-find-lang.sh:
> inaccessible or not found
> ```
>
> What’s the replacement? Should it be restored instead?
>
%_rpmconfigdir is the official macro that points to /usr/lib/rpm.
--
真実はいつも一つ！/ Always, there's only one truth!
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Qt packaging
On Mon, Aug 8, 2022 at 2:32 AM 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 s 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! ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: systemd vs split /usr
On Mon, Sep 27, 2021 at 12:37 PM Jakub Bogusz wrote: > > meson.build from systemd 249 says: > "split-usr mode is going to be removed" > (and sysusers.d location is already broken/inconsistent in this version, > I'm going to patch it) > > Any plans related to this? > Nobody is maintaining split /usr mode upstream, so I'm not surprised it's going away. If someone still wants that, they should help upstream to maintain the option. -- 真実はいつも一つ！/ Always, there's only one truth! ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm: --nofsync: unknown option
On Thu, Sep 23, 2021 at 7:32 AM Elan Ruusamäe wrote: > > is there equivalent for rpm 4.16? > > > in virtualized environments, like docker build, there's no point calling > fsync after each package installation. > No, it was explicitly removed a long time ago[1], though there are knobs to minimize writes: https://github.com/rpm-software-management/rpm/blob/rpm-4.16.x/macros.in#L750-L762 [1]: https://github.com/rpm-software-management/rpm/issues/1401#issuecomment-760919959 -- 真実はいつも一つ！/ Always, there's only one truth! ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Empty %files file
On Tue, Aug 24, 2021 at 11:59 AM Jakub Bogusz wrote: > > On Tue, Aug 24, 2021 at 11:30:43AM -0400, Neal Gompa wrote: > > On Tue, Aug 24, 2021 at 6:19 AM Elan Ruusamäe wrote: > > > > > > > > > error: Empty %files file > > > /home/users/glen/rpm/packages/BUILD.x86_64-linux/zabbix-5.4.3/debugsourcefiles.list > > > > > > is this something specific to carme? > > > > > > > > > and how to prevent the error and proceed? > > > > > > > That happens when your compilation flags aren't being respected and > > debuginfo isn't getting built properly for -debuginfo and -debugsource > > subpackages to be generated. > > Explaining further: > > - if binary packages don't contain any native code (just scripts, data or some > bytecode), then -debuginfo is empty (and solution is to set > _enable_debug_packages to 0) > > - if there is some native code, -debuginfo is created > > - if there is no enough debug information, -debugsource packages are not > created; the reason can be lack of compiler/linker flags (or binary > stripping in %install stage), but also if binaries are created by > compiler not supported by rpm debuginfo machinery (like golang or > rust); in the last case, solution is to disable debugsource packages > (define _debugsource_packages to 0); in other case, solution is to > properly pass compiler flags or disable stripping in build system > Both Rust and Go are supported by RPM debuginfo machinery, it's just not done by default unless you pass flags for it. In Fedora, for example, those flags are set, so those things do work. If there is no native code, then BuildArch: noarch should be set, which turns off debuginfo stuff too. -- 真実はいつも一つ！/ Always, there's only one truth! ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Empty %files file
On Tue, Aug 24, 2021 at 6:19 AM Elan Ruusamäe wrote: > > > error: Empty %files file > /home/users/glen/rpm/packages/BUILD.x86_64-linux/zabbix-5.4.3/debugsourcefiles.list > > is this something specific to carme? > > > and how to prevent the error and proceed? > That happens when your compilation flags aren't being respected and debuginfo isn't getting built properly for -debuginfo and -debugsource subpackages to be generated. -- 真実はいつも一つ！/ Always, there's only one truth! ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm 4.16 /etc/rpm/sysinfo/Requirename
On Sun, Aug 15, 2021 at 9:11 AM Elan Ruusamäe wrote: > > Does rpm 4.16 have equivalent of /etc/rpm/sysinfo/Requirename? > > it's used to prevent some package being uninstalled: > > - > http://git.pld-linux.org/?p=packages/pld-builder.git;a=commitdiff;h=d37d3a926108b86a52d91a4c78f3bfb647b7b6a2 > No, that's usually something implemented at the higher-level package manager. For example, DNF has a concept of protected packages and packages can install drop-in files to configure packages to be considered protected by default. -- 真実はいつも一つ！/ Always, there's only one truth! ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/php] - drop if clause introduced in commit 20dcadbb (guard clause for rpm 4.16), we have fully transiti
On Sat, May 15, 2021 at 12:08 PM Jan Palus wrote:
>
> On 15.05.2021 11:44, Neal Gompa wrote:
> > On Sat, May 15, 2021 at 10:41 AM Adam Gołębiowski
> > wrote:
> > >
> > >
> > > W dniu 2021-05-15 o 15:26, Neal Gompa pisze:
> > > > On Sat, May 15, 2021 at 6:23 AM Adam Gołębiowski
> > > > wrote:
> > > >>
> > > >> W dniu 2021-05-15 o 11:52, Neal Gompa pisze:
> > > >>> On Sat, May 15, 2021 at 5:38 AM Adam Gołębiowski
> > > >>> wrote:
> > > >>>> W dniu 2021-05-13 o 21:32, Elan Ruusamäe pisze:
> > > >>>>
> > > >>>>> point of that guard was to wait for support to become available or
> > > >>>>> someone implement a solution.
> > > >>>>> (...)
> > > >>>>> but as no such solution as provided, you need to update obsoletes to
> > > >>>>> fill **all** package names that provide that file path.
> > > >>>>>
> > > >>>>> I refuse to do that myself as it's pretty stupid.
> > > >>>> ugly, for sure, but unless we come up with another solution (patching
> > > >>>> rpm to support Obsoletes: /path), we will need to maintain 11
> > > >>>> Obsoletes:
> > > >>>> lines per package ...
> > > >>>>
> > > >>> What problem are you trying to solve here? I'm not sure I understand
> > > >>> why you're doing this.
> > > >> Each of the php*-program packages provide /usr/bin/php symlink:
> > > >>
> > > >> /poldek:/all-avail> install phpcsProcessing
> > > >> dependencies...phpcs-3.4.1-2.noarch: required "/usr/bin/php" is
> > > >> provided by the
> > > >> following packages:a) php4-program-4.4.9-67.x86_64b)
> > > >> php52-program-5.2.17-20130717.35.x86_64c)
> > > >> php53-program-5.3.29-52.x86_64d)
> > > >> php54-program-5.4.45-30.x86_64e)
> > > >> php55-program-5.5.38-22.x86_64f)
> > > >> php56-program-5.6.40-9.x86_64g)
> > > >> php70-program-7.0.33-8.x86_64h)
> > > >> php71-program-7.1.33-3.x86_64i)
> > > >> php72-program-7.2.34-1.x86_64j)
> > > >> php73-program-7.3.24-1.x86_64k)
> > > >> php74-program-7.4.12-2.x86_64l)
> > > >> php80-program-8.0.0-2.x86_64Which one do you want to install ('Q'
> > > >> to abort)?
> > > >> [php4-program-4.4.9-67.x86_64]/
> > > >>
> > > >>
> > > >>
> > > >> Prior to rpm switch, each of those packages also had Obsoletes:
> > > >> /usr/bin/php so that you could easily switch the provider of
> > > >> /usr/bin/php symlinkL
> > > >> /poldek:/all-avail> install php80-program-8.0.0-2.x86_64///
> > > >>
> > > >> /Loading [pndir]th-2020-updates...
> > > >> Loading [pndir]th-2020-updates...
> > > >> Loading [pndir]th-2020...
> > > >> Loading [pndir]th-2020...
> > > >> 29952 packages read
> > > >> Processing dependencies...
> > > >> php80-program-8.0.0-2.x86_64 marks php80-cli-8.0.0-2.x86_64 (cap
> > > >> php80-cli = 4:8.0.0-2)
> > > >>php80-cli-8.0.0-2.x86_64 marks php80-common-8.0.0-2.x86_64 (cap
> > > >> /etc/php80)
> > > >> There are 3 packages to install (2 marked by dependencies):
> > > >> A php80-cli-8.0.0-2.x86_64 php80-common-8.0.0-2.x86_64
> > > >> php80-program-8.0.0-2.x86_64
> > > >> This operation will use 4.6MB of disk space.
> > > >> Need to get 1.4MB of archives (1.4MB to download).
> > > >>
> > > >> [1/3] th-2020::php80-common-8.0.0-2.x86_64.rpm [1.4M (1.4M/s)]
> > > >> [2/3] th-2020::php80-cli-8.0.0-2.x86_64.rpm [51.7K (51.7K/s)]
> > > >> [3/3] th-2020::php80-program-8.0.0-2.x86_64.rpm [5.0K (5.0K/s)]
> > > >> Executing pm-command.sh --upgrade -vh --root / --define
> > > >> _check_dirname_deps 1...
> > > >> error: failed to open /etc/mtab: No such file or directory
> > > >> Preparing... ### [100%]
> > > >> Repackaging...
> > > >> 1:php72-program ###
Re: [packages/php] - drop if clause introduced in commit 20dcadbb (guard clause for rpm 4.16), we have fully transiti
On Sat, May 15, 2021 at 10:41 AM Adam Gołębiowski wrote:
>
>
> W dniu 2021-05-15 o 15:26, Neal Gompa pisze:
> > On Sat, May 15, 2021 at 6:23 AM Adam Gołębiowski
> > wrote:
> >>
> >> W dniu 2021-05-15 o 11:52, Neal Gompa pisze:
> >>> On Sat, May 15, 2021 at 5:38 AM Adam Gołębiowski
> >>> wrote:
> >>>> W dniu 2021-05-13 o 21:32, Elan Ruusamäe pisze:
> >>>>
> >>>>> point of that guard was to wait for support to become available or
> >>>>> someone implement a solution.
> >>>>> (...)
> >>>>> but as no such solution as provided, you need to update obsoletes to
> >>>>> fill **all** package names that provide that file path.
> >>>>>
> >>>>> I refuse to do that myself as it's pretty stupid.
> >>>> ugly, for sure, but unless we come up with another solution (patching
> >>>> rpm to support Obsoletes: /path), we will need to maintain 11 Obsoletes:
> >>>> lines per package ...
> >>>>
> >>> What problem are you trying to solve here? I'm not sure I understand
> >>> why you're doing this.
> >> Each of the php*-program packages provide /usr/bin/php symlink:
> >>
> >> /poldek:/all-avail> install phpcsProcessing
> >> dependencies...phpcs-3.4.1-2.noarch: required "/usr/bin/php" is
> >> provided by the
> >> following packages:a) php4-program-4.4.9-67.x86_64b)
> >> php52-program-5.2.17-20130717.35.x86_64c)
> >> php53-program-5.3.29-52.x86_64d) php54-program-5.4.45-30.x86_64e)
> >> php55-program-5.5.38-22.x86_64f) php56-program-5.6.40-9.x86_64g)
> >> php70-program-7.0.33-8.x86_64h) php71-program-7.1.33-3.x86_64i)
> >> php72-program-7.2.34-1.x86_64j) php73-program-7.3.24-1.x86_64k)
> >> php74-program-7.4.12-2.x86_64l) php80-program-8.0.0-2.x86_64Which
> >> one do you want to install ('Q' to abort)?
> >> [php4-program-4.4.9-67.x86_64]/
> >>
> >>
> >>
> >> Prior to rpm switch, each of those packages also had Obsoletes:
> >> /usr/bin/php so that you could easily switch the provider of /usr/bin/php
> >> symlinkL
> >> /poldek:/all-avail> install php80-program-8.0.0-2.x86_64///
> >>
> >> /Loading [pndir]th-2020-updates...
> >> Loading [pndir]th-2020-updates...
> >> Loading [pndir]th-2020...
> >> Loading [pndir]th-2020...
> >> 29952 packages read
> >> Processing dependencies...
> >> php80-program-8.0.0-2.x86_64 marks php80-cli-8.0.0-2.x86_64 (cap
> >> php80-cli = 4:8.0.0-2)
> >>php80-cli-8.0.0-2.x86_64 marks php80-common-8.0.0-2.x86_64 (cap
> >> /etc/php80)
> >> There are 3 packages to install (2 marked by dependencies):
> >> A php80-cli-8.0.0-2.x86_64 php80-common-8.0.0-2.x86_64
> >> php80-program-8.0.0-2.x86_64
> >> This operation will use 4.6MB of disk space.
> >> Need to get 1.4MB of archives (1.4MB to download).
> >>
> >> [1/3] th-2020::php80-common-8.0.0-2.x86_64.rpm [1.4M (1.4M/s)]
> >> [2/3] th-2020::php80-cli-8.0.0-2.x86_64.rpm [51.7K (51.7K/s)]
> >> [3/3] th-2020::php80-program-8.0.0-2.x86_64.rpm [5.0K (5.0K/s)]
> >> Executing pm-command.sh --upgrade -vh --root / --define
> >> _check_dirname_deps 1...
> >> error: failed to open /etc/mtab: No such file or directory
> >> Preparing... ### [100%]
> >> Repackaging...
> >> 1:php72-program ### [100%]
> >> Upgrading...
> >> 1:php80-common ### [ 33%]
> >> 2:php80-cli ### [ 67%]
> >> 3:php80-program ### [100%]
> >> poldek:/all-avail>/
> >>
> >>
> >> But rpm-4 no longer allows / in Obsoletes:
> >>
> >> /Illegal char '/' (0x2f) in: Obsoletes: /usr/bin/php /
> >>
> >> Which makes this smooth transition no longer possible:
> >>
> >> /poldek:/all-avail> install php73-program-7.3.27-1.x86_64//
> >> //Processing dependencies...//
> >> //php73-program-7.3.27-1.x86_64 marks php73-cli-7.3.27-1.x86_64 (cap
> >> php73-cli = 4:7.3.27-1)//
> >> // php73-cli-7.3.27-1.x86_64 marks php73-common-7.3.27-1.x86_64 (cap
> >> libphp_common-7.3.27.so()(64bit))//
> >>
Re: [packages/php] - drop if clause introduced in commit 20dcadbb (guard clause for rpm 4.16), we have fully transiti
On Sat, May 15, 2021 at 6:23 AM Adam Gołębiowski wrote:
>
>
> W dniu 2021-05-15 o 11:52, Neal Gompa pisze:
> > On Sat, May 15, 2021 at 5:38 AM Adam Gołębiowski
> > wrote:
> >>
> >> W dniu 2021-05-13 o 21:32, Elan Ruusamäe pisze:
> >>
> >>> point of that guard was to wait for support to become available or
> >>> someone implement a solution.
> >>> (...)
> >>> but as no such solution as provided, you need to update obsoletes to
> >>> fill **all** package names that provide that file path.
> >>>
> >>> I refuse to do that myself as it's pretty stupid.
> >> ugly, for sure, but unless we come up with another solution (patching
> >> rpm to support Obsoletes: /path), we will need to maintain 11 Obsoletes:
> >> lines per package ...
> >>
> > What problem are you trying to solve here? I'm not sure I understand
> > why you're doing this.
>
> Each of the php*-program packages provide /usr/bin/php symlink:
>
> /poldek:/all-avail> install phpcsProcessing
> dependencies...phpcs-3.4.1-2.noarch: required "/usr/bin/php" is provided
> by the
> following packages:a) php4-program-4.4.9-67.x86_64b)
> php52-program-5.2.17-20130717.35.x86_64c)
> php53-program-5.3.29-52.x86_64d) php54-program-5.4.45-30.x86_64e)
> php55-program-5.5.38-22.x86_64f) php56-program-5.6.40-9.x86_64g)
> php70-program-7.0.33-8.x86_64h) php71-program-7.1.33-3.x86_64i)
> php72-program-7.2.34-1.x86_64j) php73-program-7.3.24-1.x86_64k)
> php74-program-7.4.12-2.x86_64l) php80-program-8.0.0-2.x86_64Which one
> do you want to install ('Q' to abort)?
> [php4-program-4.4.9-67.x86_64]/
>
>
>
> Prior to rpm switch, each of those packages also had Obsoletes: /usr/bin/php
> so that you could easily switch the provider of /usr/bin/php symlinkL
> /poldek:/all-avail> install php80-program-8.0.0-2.x86_64///
>
> /Loading [pndir]th-2020-updates...
> Loading [pndir]th-2020-updates...
> Loading [pndir]th-2020...
> Loading [pndir]th-2020...
> 29952 packages read
> Processing dependencies...
> php80-program-8.0.0-2.x86_64 marks php80-cli-8.0.0-2.x86_64 (cap
> php80-cli = 4:8.0.0-2)
> php80-cli-8.0.0-2.x86_64 marks php80-common-8.0.0-2.x86_64 (cap
> /etc/php80)
> There are 3 packages to install (2 marked by dependencies):
> A php80-cli-8.0.0-2.x86_64 php80-common-8.0.0-2.x86_64
> php80-program-8.0.0-2.x86_64
> This operation will use 4.6MB of disk space.
> Need to get 1.4MB of archives (1.4MB to download).
>
> [1/3] th-2020::php80-common-8.0.0-2.x86_64.rpm [1.4M (1.4M/s)]
> [2/3] th-2020::php80-cli-8.0.0-2.x86_64.rpm [51.7K (51.7K/s)]
> [3/3] th-2020::php80-program-8.0.0-2.x86_64.rpm [5.0K (5.0K/s)]
> Executing pm-command.sh --upgrade -vh --root / --define
> _check_dirname_deps 1...
> error: failed to open /etc/mtab: No such file or directory
> Preparing... ### [100%]
> Repackaging...
> 1:php72-program ### [100%]
> Upgrading...
> 1:php80-common ### [ 33%]
> 2:php80-cli ### [ 67%]
> 3:php80-program ### [100%]
> poldek:/all-avail>/
>
>
> But rpm-4 no longer allows / in Obsoletes:
>
> /Illegal char '/' (0x2f) in: Obsoletes: /usr/bin/php /
>
> Which makes this smooth transition no longer possible:
>
> /poldek:/all-avail> install php73-program-7.3.27-1.x86_64//
> //Processing dependencies...//
> //php73-program-7.3.27-1.x86_64 marks php73-cli-7.3.27-1.x86_64 (cap
> php73-cli = 4:7.3.27-1)//
> // php73-cli-7.3.27-1.x86_64 marks php73-common-7.3.27-1.x86_64 (cap
> libphp_common-7.3.27.so()(64bit))//
> //There are 3 packages to install (2 marked by dependencies)://
> //A php73-cli-7.3.27-1.x86_64 php73-common-7.3.27-1.x86_64
> php73-program-7.3.27-1.x86_64//
> //This operation will use 4.2MB of disk space.//
> //Need to get 1.2MB of archives.//
> //php73-common-7.3.27-1.x86_64.rpm: digests OK//
> //php73-cli-7.3.27-1.x86_64.rpm: digests OK//
> //php73-program-7.3.27-1.x86_64.rpm: digests OK//
> //Executing pm-command.sh --upgrade -vh --root / --define
> _check_dirname_deps 0...//
> //Verifying... # [100%]//
> //Preparing... # [100%]//
> //file /usr/bin/php from install of
> php73-program-4:7.3.27-1.x86_64 conflicts with file from package
> php74-program-4:7.4.19-1.1.x86_64//
> //file /usr/share/man/man1/php.1 from install of
> php73-program-4:
Re: [packages/php] - drop if clause introduced in commit 20dcadbb (guard clause for rpm 4.16), we have fully transiti
On Sat, May 15, 2021 at 5:38 AM Adam Gołębiowski wrote: > > > W dniu 2021-05-13 o 21:32, Elan Ruusamäe pisze: > > > point of that guard was to wait for support to become available or > > someone implement a solution. > > (...) > > but as no such solution as provided, you need to update obsoletes to > > fill **all** package names that provide that file path. > > > > I refuse to do that myself as it's pretty stupid. > > ugly, for sure, but unless we come up with another solution (patching > rpm to support Obsoletes: /path), we will need to maintain 11 Obsoletes: > lines per package ... > What problem are you trying to solve here? I'm not sure I understand why you're doing this. -- 真実はいつも一つ！/ Always, there's only one truth! ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm.org/rpm5.org test
On Thu, Apr 1, 2021 at 8:51 AM Elan Ruusamäe wrote:
>
> ```
>
> rpm -E '%{?_rpmconfigdir:rpm.org}%{?_rpmhome:rpm5.org}'
>
> ```
>
> this is perhaps more reliable than comparing --version output.
>
Is there a reason to do such a test anymore? PLD Th is on rpm.org rpm
and there are no supported versions of PLD that use rpm5...
--
真実はいつも一つ！/ Always, there's only one truth!
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [projects/template-specs] use %cargo_* macros
On Wed, Mar 31, 2021 at 4:34 AM Elan Ruusamäe wrote: > > On 30.03.2021 21:57, Jakub Bogusz wrote: > > > On Tue, Mar 30, 2021 at 06:46:46PM +0300, Elan Ruusamäe wrote: > > [...] > > When it comes to crates, It'd better to find some generic solution for > > packaging creates system-wide instead of vendoring everything > > everywhere. I'm aware Fedora has some, but I didn't have enough time to > > do a research. > > their solution to create 120 packages for each of them. > > the same goes for npm and go packages. > As one of the developers of those macros, I can confidently say both ways (per component packaging and vendored packages) are supported. For Rust and Go, we're doing per-component packaging because having to patch and fix the same thing hundreds of times is terrible for security stuff. Fixing the code once and kicking off rebuilds of reverse dependency chains is way easier. For Nodejs, we do vendored by default now: https://fedoraproject.org/wiki/Changes/NodejsLibrariesBundleByDefault > besides, if you diverge from versions present in vendor lock, > > you are bringing package support on your own shoulders. we do not have > such resources! > While it's true you're diverging, this is no different than what you do with C, C++, Ruby, Perl, and Python. In practice, this is where distros sharing resources comes in handy because you can collaborate on it. -- 真実はいつも一つ！/ Always, there's only one truth! ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: package names in dependencies
On Tue, Mar 23, 2021 at 12:27 PM Jakub Bogusz wrote: > > On Tue, Mar 23, 2021 at 12:18:36PM -0400, Neal Gompa wrote: > > On Tue, Mar 23, 2021 at 11:39 AM Elan Ruusamäe wrote: > > > > > > > > > On 23.03.2021 12:59, Neal Gompa wrote: > > > > On Tue, Mar 23, 2021 at 5:04 AM Elan Ruusamäe > > > > wrote: > > > >> i found some odd inconsistency: > > > >> > > > >> > > > >> error: line 319: Illegal char ')' (0x29) in: Obsoletes: > > > >> virtual(init-daemon) > > > >> error: line 319: Only package names are allowed in Obsoletes: > > > >> Obsoletes:virtual(init-daemon) > > > >> > > > >> > > > >> So: "Obsoletes: virtual(init-daemon)" is not okay, but it's fine on > > > >> some > > > >> other tags; > > > >> > > > >> > > > >> Requires: webserver(indexfile) > > > >> Requires: webserver(php) >= 4.2.0 > > > >> Suggests: php(openssl) > > > >> Suggests: webserver(setenv) > > > >> Provides: group(eventum) > > > >> Provides: user(eventum) > > > >> > > > > Obsoletes has to be a real package name, but virtual names are allowed > > > > for other tags. > > > Why? > > > > This was always the case in RPM, but it started enforcing it in RPM > > > > 4.13. > > > > > > PLD has used virtual obsoletes for the time i've used it (since 2004). > > > > > > and we are using it when multiple packages provide something common, say: > > > > > > 'init-daemon" > > > > > > they are mutually exclusive, so installing one, must uninstall the other. > > > > > > and if adding new "virtual(init-daemon)" virtual, without need to update > > > other packages, they all can have O/P: virtual(init-daemon) > > > > > > > > > now rpm enforces that each of those packages must cross reference all > > > 'the other' virtuals... duh! > > > > > > > RPM since RPM 4.10 supports mutual exclusion by using Provides + Conflicts. > > > > For example, the following is enough to get the behavior you want: > > > > Provides: init-daemon > > Conflicts: init-daemon > > Uhm, AFAIR such combo was treated as self-conflict by some RPM-based package > management software, thus making package non-installable... > > Does it have well defined semantics now? > Hmm, actually I was wrong, it was done in RPM 4.9.0: https://rpm.org/wiki/Releases/4.9.0 As for "well-defined semantics", it's basically this mailing list post: http://lists.rpm.org/pipermail/rpm-maint/2010-April/002719.html It generally works for me, though admittedly, I've only tested YUM, DNF, and Zypper. -- 真実はいつも一つ！/ Always, there's only one truth! ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: package names in dependencies
On Tue, Mar 23, 2021 at 11:39 AM Elan Ruusamäe wrote: > > > On 23.03.2021 12:59, Neal Gompa wrote: > > On Tue, Mar 23, 2021 at 5:04 AM Elan Ruusamäe wrote: > >> i found some odd inconsistency: > >> > >> > >> error: line 319: Illegal char ')' (0x29) in: Obsoletes: > >> virtual(init-daemon) > >> error: line 319: Only package names are allowed in Obsoletes: > >> Obsoletes:virtual(init-daemon) > >> > >> > >> So: "Obsoletes: virtual(init-daemon)" is not okay, but it's fine on some > >> other tags; > >> > >> > >> Requires: webserver(indexfile) > >> Requires: webserver(php) >= 4.2.0 > >> Suggests: php(openssl) > >> Suggests: webserver(setenv) > >> Provides: group(eventum) > >> Provides: user(eventum) > >> > > Obsoletes has to be a real package name, but virtual names are allowed > > for other tags. > Why? > > This was always the case in RPM, but it started enforcing it in RPM 4.13. > > PLD has used virtual obsoletes for the time i've used it (since 2004). > > and we are using it when multiple packages provide something common, say: > > 'init-daemon" > > they are mutually exclusive, so installing one, must uninstall the other. > > and if adding new "virtual(init-daemon)" virtual, without need to update > other packages, they all can have O/P: virtual(init-daemon) > > > now rpm enforces that each of those packages must cross reference all > 'the other' virtuals... duh! > RPM since RPM 4.10 supports mutual exclusion by using Provides + Conflicts. For example, the following is enough to get the behavior you want: Provides: init-daemon Conflicts: init-daemon -- 真実はいつも一つ！/ Always, there's only one truth! ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: package names in dependencies
On Tue, Mar 23, 2021 at 5:04 AM Elan Ruusamäe wrote: > > i found some odd inconsistency: > > > error: line 319: Illegal char ')' (0x29) in: Obsoletes: virtual(init-daemon) > error: line 319: Only package names are allowed in Obsoletes: > Obsoletes:virtual(init-daemon) > > > So: "Obsoletes: virtual(init-daemon)" is not okay, but it's fine on some > other tags; > > > Requires: webserver(indexfile) > Requires: webserver(php) >= 4.2.0 > Suggests: php(openssl) > Suggests: webserver(setenv) > Provides: group(eventum) > Provides: user(eventum) > Obsoletes has to be a real package name, but virtual names are allowed for other tags. This was always the case in RPM, but it started enforcing it in RPM 4.13. -- 真実はいつも一つ！/ Always, there's only one truth! ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm 4.16 landed -> errors!
On Wed, Mar 17, 2021 at 5:44 PM Jan Rękorajski wrote: > > On Wed, 17 Mar 2021, Neal Gompa wrote: > > > On Wed, Mar 17, 2021 at 2:48 PM Jan Rękorajski > > wrote: > > > > > > Neal, > > > > > > Do you have any references to such issues? Like bug reports, or docs? > > > I'd like to link them to the rpm migration page on our wiki. > > > > > > > Not offhand, but I know that this change to RPM[1] (and a few other > > fun quirks of bdb) is what started causing things to trip up in > > containers with rpmdb rebuilds. It should basically go away once the > > conversion to sqlite rpmdb is done. There is information about how > > OverlayFS handles directory renames in the Linux kernel > > documentation[2]. This affected YUM too[3], though DNF has workarounds > > built into it now[4]. For this specific issue, you can avoid this by > > regenerating the container entirely from scratch instead of using an > > upgrade to fix it. > > > > More generally, I advise being careful with OverlayFS and being > > mindful of the pitfalls[2]. I personally use Btrfs instead, which > > neatly avoids this and is a lot more performant. > > Thanks. > > > (As an aside, can someone rebase the DNF package manager stack in PLD? > > It's pretty old and broken...) > > You mean this? I did an update of dnf packages recently. There are a few > things left to do but most should be up to date. > > poldek:/all-avail> ls dnf* > dnf-4.6.1-5.noarch > dnf-automatic-4.6.1-5.noarch > dnf-plugin-cow-0.0.2-1.noarch > dnf-plugin-diff-1.1-1.noarch > dnf-plugin-kickstart-4.0.13-2.noarch > dnf-plugin-leaves-4.0.19-1.noarch > dnf-plugin-local-4.0.19-1.noarch > dnf-plugin-migrate-4.0.19-1.noarch > dnf-plugin-ovl-0.0.3-1.noarch > dnf-plugin-post-transaction-actions-4.0.19-1.noarch > dnf-plugin-rpmconf-4.0.13-2.noarch > dnf-plugin-show-leaves-4.0.19-1.noarch > dnf-plugin-showvars-4.0.13-2.noarch > dnf-plugin-snapper-4.0.13-2.noarch > dnf-plugin-system-upgrade-4.0.13-2.noarch > dnf-plugin-torproxy-4.0.13-2.noarch > dnf-plugin-tracer-4.0.13-2.noarch > dnf-plugin-versionlock-4.0.19-1.noarch > dnf-plugins-core-4.0.19-1.noarch > dnf-plugins-extras-common-4.0.13-2.noarch > dnf-utils-4.0.19-1.noarch > dnfdaemon-0.3.20-2.noarch > Ah cool, I guess I just missed it. I checked last week. :P -- 真実はいつも一つ！/ Always, there's only one truth! ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm 4.16 landed -> errors!
On Wed, Mar 17, 2021 at 2:48 PM Jan Rękorajski wrote: > > On Tue, 16 Mar 2021, Neal Gompa wrote: > > > On Tue, Mar 16, 2021 at 1:39 PM Jan Rękorajski > > wrote: > > > > > > On Tue, 16 Mar 2021, Elan Ruusamäe wrote: > > > > > > > > > > > On 16.03.2021 16:45, Elan Ruusamäe wrote: > > > > > > > > > > the automatic upgrade is failing: > > > > > > > > > > - https://gitlab.com/pld-linux/pld/-/jobs/1094531330#L214 > > > > > > > > > oh, and user is left without rpmdb: > > > > > > > > > > > > [@46a17bd0ade9 /]# rpm -q rpm poldek > > > > warning: Found bdb Packages database while attempting sqlite backend: > > > > using bdb backend. > > > > warning: Generating 6 missing index(es), please wait... > > > > package rpm is not installed > > > > package poldek is not installed > > > > > > > > [@46a17bd0ade9 /]# rpm -q rpm poldek > > > > warning: Found bdb Packages database while attempting sqlite backend: > > > > using bdb backend. > > > > package rpm is not installed > > > > package poldek is not installed > > > > [@46a17bd0ade9 /]# > > > > > > First, regarding lost database. > > > You do have a backup of the database from before the update: > > > > > > Backup of the rpm database has been created in > > > /var/lib/rpm.rpmbackup-4.16.1.2-6 > > > > > > There is also the new database, that rpm was unable to move: > > > > > > error: replace files in /var/lib/rpm with files from > > > /var/lib/rpmrebuilddb.42 to recover > > > > > > Is /var/lib/rpm a mountpoint? That would be the explanation that comes > > > to mind. There must be something that prevented rpm from renaming > > > temporary > > > directory in /var/lib to rpm. > > > > > > I've been (live) testing upgrade path and I assumed it does work. > > > Never encountered problems after squashing rpm5 oddities. > > > > > > I've been also asking over and over for testing and no one came with any > > > issues like this. > > > > > > > This is probably an overlayfs specific issue, I've seen various > > problems with renames (which is what rpm does for rebuilding > > databases) in containers. > > Neal, > > Do you have any references to such issues? Like bug reports, or docs? > I'd like to link them to the rpm migration page on our wiki. > Not offhand, but I know that this change to RPM[1] (and a few other fun quirks of bdb) is what started causing things to trip up in containers with rpmdb rebuilds. It should basically go away once the conversion to sqlite rpmdb is done. There is information about how OverlayFS handles directory renames in the Linux kernel documentation[2]. This affected YUM too[3], though DNF has workarounds built into it now[4]. For this specific issue, you can avoid this by regenerating the container entirely from scratch instead of using an upgrade to fix it. More generally, I advise being careful with OverlayFS and being mindful of the pitfalls[2]. I personally use Btrfs instead, which neatly avoids this and is a lot more performant. (As an aside, can someone rebase the DNF package manager stack in PLD? It's pretty old and broken...) [1]: https://github.com/rpm-software-management/rpm/commit/fffd652c56eaef8fc41d23190e39513639f2092d [2]: https://www.kernel.org/doc/html/latest/filesystems/overlayfs.html#renaming-directories [3]: https://bugzilla.redhat.com/1213602 [4]: https://bugzilla.redhat.com/1658565 -- 真実はいつも一つ！/ Always, there's only one truth! ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm 4.16 landed -> errors!
On Tue, Mar 16, 2021 at 1:39 PM Jan Rękorajski wrote: > > On Tue, 16 Mar 2021, Elan Ruusamäe wrote: > > > > > On 16.03.2021 16:45, Elan Ruusamäe wrote: > > > > > > the automatic upgrade is failing: > > > > > > - https://gitlab.com/pld-linux/pld/-/jobs/1094531330#L214 > > > > > oh, and user is left without rpmdb: > > > > > > [@46a17bd0ade9 /]# rpm -q rpm poldek > > warning: Found bdb Packages database while attempting sqlite backend: > > using bdb backend. > > warning: Generating 6 missing index(es), please wait... > > package rpm is not installed > > package poldek is not installed > > > > [@46a17bd0ade9 /]# rpm -q rpm poldek > > warning: Found bdb Packages database while attempting sqlite backend: > > using bdb backend. > > package rpm is not installed > > package poldek is not installed > > [@46a17bd0ade9 /]# > > First, regarding lost database. > You do have a backup of the database from before the update: > > Backup of the rpm database has been created in > /var/lib/rpm.rpmbackup-4.16.1.2-6 > > There is also the new database, that rpm was unable to move: > > error: replace files in /var/lib/rpm with files from /var/lib/rpmrebuilddb.42 > to recover > > Is /var/lib/rpm a mountpoint? That would be the explanation that comes > to mind. There must be something that prevented rpm from renaming temporary > directory in /var/lib to rpm. > > I've been (live) testing upgrade path and I assumed it does work. > Never encountered problems after squashing rpm5 oddities. > > I've been also asking over and over for testing and no one came with any > issues like this. > This is probably an overlayfs specific issue, I've seen various problems with renames (which is what rpm does for rebuilding databases) in containers. -- 真実はいつも一つ！/ Always, there's only one truth! ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm 4.16.1.2 from rpm.org has landed in Th
On Mon, Feb 22, 2021 at 2:00 PM Jan Rękorajski wrote: > > rpm 4.16.1.2 and all dependant packages are now available in th-test. > > More details about the update can be found on > > https://www.pld-linux.org/packages/rpm > > Th builders has been upgraded and all builds will now use rpm.org rpm. > Congratulations on making that happen! I'm pleased to see that the transition has gone quite smoothly. :) -- 真実はいつも一つ！/ Always, there's only one truth! ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [PLDWWW] page changed: packages:rpm
On Sat, Feb 6, 2021 at 1:23 PM Elan Ruusamäe wrote: > > > On 06.02.2021 11:13, "Jan Rękorajski (baggins)" wrote: > > + * rpm.org rpm generates ''rpmlib(ShortCircuited)'' dependencies when > > package is build using ''--short-circuit'' option. To disable that add > > ''%disable_short_circuited_deps 0'' to ~/.rpmrc > > > what's the difference of ~/.rpmrc and ~/.rpmmacros? i thought ~/.rpmrc > was deprecated by jbj, but now it's back due rpm.org code? and .rpmrc > used different synta You put it in ~/.rpmmacros, not ~/.rpmrc. The latter is only for managing compiler flags and arch maps. -- 真実はいつも一つ！/ Always, there's only one truth! ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm.org 4.16.x is coming to Th
On Sun, Jan 31, 2021 at 4:16 AM Jan Rękorajski wrote:
>
> On Mon, 11 Jan 2021, Neal Gompa wrote:
>
> > On Mon, Jan 11, 2021 at 10:09 AM Elan Ruusamäe wrote:
> > >
> > >
> > > On 11.01.2021 10:38, Jan Rękorajski wrote:
> > > > If you think there is still something that is blocking the change please
> > > > speak*now*.
> > >
> > > are these pld introduced noauto* macros and files supported in 4.16 build?
> > >
> > >
> > > %define _noautoprovfiles%{_libdir}/%{name}
> >
> > No, you need to use the standard filtering mechanism:
> > https://docs.fedoraproject.org/en-US/packaging-guidelines/AutoProvidesAndRequiresFiltering/
>
> And, sadly, this mechanism is again a piece of crap, and another thing that
> was
> solved 20 years ago in PLD.
>
> rpm5 supports multiple lines with multiple regexps each. rpmfcExpandRegexps.
>
In the years I've been involved in rpm.org upstream, literally nobody
has ever asked for this to be made better, much less submitted
patches. Complaining about it being "crap" and "solved 20 years ago in
PLD" is unhelpful when as far as I know, nobody from PLD talked to
rpm.org rpm upstream in at least the past decade, even before PLD
switched to rpm5.org rpm back in 2012.
> rpm.org rpm can only do a single regexp in a single macro, so no things
> like we have:
>
> %__noautoreq%(sed -e s'/#.*//' /etc/rpm/noautoreq) \
> %{?_noautoreq: %{_noautoreq}} \
> %{?_noautoreq_java: %{__noauto_regexp_helper -p java
> %{_noautoreq_java}}} \
> %{?_noautoreq_mono: %{__noauto_regexp_helper -p mono
> %{_noautoreq_mono}}} \
> %{?_noautoreq_pear: %{__noauto_regexp_helper -p pear
> %{_noautoreq_pear}}} \
> %{?_noautoreq_perl: %{__noauto_regexp_helper -p perl
> %{_noautoreq_perl}}} \
> %{?_noautoreq_pyegg: %{__noauto_regexp_helper -p pythonegg
> %{_noautoreq_pyegg}}} \
> %{?_noautoreq_py3egg: %{__noauto_regexp_helper -p python3egg
> %{_noautoreq_py3egg}}} \
>
That's technically a single definition, isn't it?
> or, in a spec file
>
> %define _noautoreq libFoo.so.1 libBar.so.1
>
> I'll see if I can fix this...
>
You could make a macro wrapper that generates the RPM native one. Or
submit a patch to rpm.org rpm to support multiple regexps in the
current stuff.
--
真実はいつも一つ！/ Always, there's only one truth!
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: AutoProvidesAndRequiresFiltering (was Re: rpm.org 4.16.x is coming to Th)
On Mon, Jan 11, 2021 at 12:34 PM Elan Ruusamäe wrote:
>
>
> On 11.01.2021 17:10, Neal Gompa wrote:
> > On Mon, Jan 11, 2021 at 10:09 AM Elan Ruusamäe wrote:
> >>
> >> On 11.01.2021 10:38, Jan Rękorajski wrote:
> >>> If you think there is still something that is blocking the change please
> >>> speak*now*.
> >> are these pld introduced noauto* macros and files supported in 4.16 build?
> >>
> >>
> >> %define _noautoprovfiles%{_libdir}/%{name}
> > No, you need to use the standard filtering mechanism:
> > https://docs.fedoraproject.org/en-US/packaging-guidelines/AutoProvidesAndRequiresFiltering/
>
> I've always thought, why provide/require SONAME dependencies of files that
> are not in default dl.so search path?
>
> like, why this (or equivalent) can't be the default:
>
> %global __provides_exclude_from ^%{_libdir}/.+/.+\\.so$
> %global __requires_exclude_from ^%{_libdir}/.+/.+\\.so$
>
> to exclude everything not a direct file in %{_libdir}[*].
>
> [*] might also need to support lib32dir and libx32dir for multiarch.
>
The main reason is that it's difficult to *add* paths to dynamically
search sanely, but it's possible to do what you're saying by changing
the fileattr definitions for elf dependencies to include a file path
restriction.
--
真実はいつも一つ！/ Always, there's only one truth!
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm.org 4.16.x is coming to Th
On Mon, Jan 11, 2021 at 10:09 AM Elan Ruusamäe wrote:
>
>
> On 11.01.2021 10:38, Jan Rękorajski wrote:
> > If you think there is still something that is blocking the change please
> > speak*now*.
>
> are these pld introduced noauto* macros and files supported in 4.16 build?
>
>
> %define _noautoprovfiles%{_libdir}/%{name}
No, you need to use the standard filtering mechanism:
https://docs.fedoraproject.org/en-US/packaging-guidelines/AutoProvidesAndRequiresFiltering/
--
真実はいつも一つ！/ Always, there's only one truth!
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm4 on carme*
On Mon, Dec 14, 2020 at 10:21 AM Jan Palus wrote: > > If commit message includes '%' then rpmbuild spawned by builder script > fails. See ie test.spec which includes '%prep': > > error: line 40: second %prep > > builder creates spec copy with %changelog appended. Apparently rpm.org > evaluates macros in %changelog while rpm5 does not. Not sure whether > we're supposed to escape macros in changelog now or whether rpm.org > should read %changelog as is. Macros are supposed to be escaped. -- 真実はいつも一つ！/ Always, there's only one truth! ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm4 on carme*
On Sun, Nov 22, 2020 at 11:34 AM Arkadiusz Miśkiewicz via pld-devel-en wrote: > > W dniu 22.11.2020 o 17:00, Jan Palus pisze: > > * adding to the list of invalid chars in Obsoletes: '/' (msmtp: Obsoletes: > > /usr/lib/sendmail) > > > > * python-Cython built with rpm.org has weird unsatisfied R: > > python2.7dist(setuptools) / python3.8dist(setuptools) > > Could these be https://rpm.org/user_doc/boolean_dependencies.html that > are not handled by poldek ? > > And "/" could be forbidden due to that. I don't think Cython has a ranged dependency to trigger a boolean dependency expression. At least in Fedora, Cython generates a "python3.9dist(setuptools)" dependency. I would expect python3-setuptools to have a generated "Provides: python3.8dist(setuptools)" stanza from the pythondist generator. -- 真実はいつも一つ！/ Always, there's only one truth! ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm.org's rpm 4.16.0 ready for testing
On Sat, Oct 24, 2020 at 5:37 PM Jan Palus wrote:
>
> On 24.10.2020 17:15, Jan Rękorajski via pld-devel-en wrote:
> > I have prepared rpm 4.16, poldek and support packages, they are
> > available on http://ftp1.pld-linux.org/people/baggins/rpm.org/
> >
> > I would appreciate if you could test the uprade path, functionality
> > and tell me if anything is missing / broken.
>
> First of all great work, thanks!
>
> FWIW I did a build on aarch64 with few minor fixes and looks like it
> all works fine. Some funky things that I've noticed so far:
>
> * after build with -bb --short-circuit package has weird dependency:
>
> error: Failed dependencies:
> rpmlib(ShortCircuited) <= 4.9.0-1 is needed by
> poldek-libs-0.42.2-3.aarch64
> rpmlib(ShortCircuited) <= 4.9.0-1 is needed by
> poldek-0.42.2-3.aarch64
>
> if you're not doing %prep, %build or %install then you're... cheating
> and end up with this dep?
>
> build/build.c:
>
> int didBuild = (what & (RPMBUILD_PREP|RPMBUILD_BUILD|RPMBUILD_INSTALL));
> ...
> packageBinaries(spec, cookie, (didBuild == 0))
>
>
> build/pack.c:
>
> rpmRC packageBinaries(rpmSpec spec, const char *cookie, int cheating)
> ...
> if (cheating) {
> (void) rpmlibNeedsFeature(pkg, "ShortCircuited", "4.9.0-1");
> }
>
This is intentional. Short-circuit builds are not sane for production
builds, because it violates the integrity and consistency of the build
process.
> * libraries have build id symlinks, not sure what's that for:
>
> $ rpm -ql rpm-lib
> /lib64/librpm.so.9
> /lib64/librpm.so.9.1.0
> /lib64/librpmbuild.so.9
> /lib64/librpmbuild.so.9.1.0
> /lib64/librpmio.so.9
> /lib64/librpmio.so.9.1.0
> /lib64/librpmsign.so.9
> /lib64/librpmsign.so.9.1.0
> /usr/lib/.build-id
> /usr/lib/.build-id/2f
> /usr/lib/.build-id/2f/fc726b33e23f339fb4140cb2a858800f92f245
> /usr/lib/.build-id/72
> /usr/lib/.build-id/72/65fcdb96f521c1953560d780a5f82fa2017c2a
> /usr/lib/.build-id/73
> /usr/lib/.build-id/73/5b7b1130a7b6a74436438fb3fc02cad816224d
> /usr/lib/.build-id/e6
> /usr/lib/.build-id/e6/7a230d27a1b3fceb891aa2df1bfa5e1e980f50
> /usr/lib64/rpm-plugins
>
That's part of the improved debuginfo package handling[1][2].
[1]: https://fedoraproject.org/wiki/Changes/ParallelInstallableDebuginfo
[2]: https://fedoraproject.org/wiki/Changes/SubpackageAndSourceDebuginfo
> * are we sticking to new patch fuzz level (0) or go back to patch
> default (2)?
I hope you'd keep the fuzz at 0 by default.
--
真実はいつも一つ！/ Always, there's only one truth!
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm.org's rpm 4.16.0 ready for testing
On Sat, Oct 24, 2020 at 12:27 PM Jan Rękorajski via pld-devel-en wrote: > > On Sat, 24 Oct 2020, Neal Gompa wrote: > > > On Sat, Oct 24, 2020 at 11:16 AM Jan Rękorajski via pld-devel-en > > wrote: > > > > > > I have prepared rpm 4.16, poldek and support packages, they are > > > available on http://ftp1.pld-linux.org/people/baggins/rpm.org/ > > > > > > I would appreciate if you could test the uprade path, functionality > > > and tell me if anything is missing / broken. > > > > > > > Is there a set of git repos with the packaging and patches somewhere? > > Eveything is in PLD git repo, rpm and rpm-pld-macros on branch rpm.org > > http://git.pld-linux.org/gitweb.cgi/packages/rpm.git/ > http://git.pld-linux.org/gitweb.cgi/packages/rpm-pld-macros.git/ > > Everythong else on master (you need with rpm4 for poldek) > > http://git.pld-linux.org/gitweb.cgi/packages/poldek.git/ > > > Also, as an FYI: rpm-specdump can be retired for rpm's built-in rpmspec(8) > > tool. > > Thanks, but I'll stick with rpm-specdump and rpm-getdeps for now, switching to > rpmspec may require rewriting build tools. I don't want tp make too > many, possible breaking, changes at once. > That's fair, but I would suggest making a bug or something for everything using those to switch over. > There is also added bonus of forced PY2 -> PY3 transition for other > tools. rpm5 can't do PY3, rpm.org can't do PY2 :/ > What stuff still uses RPM Python bindings that are Python 2 only in PLD? Most of the RPM ecosystem tools I know of have Python 3 ports now... -- 真実はいつも一つ！/ Always, there's only one truth! ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm.org's rpm 4.16.0 ready for testing
On Sat, Oct 24, 2020 at 11:17 AM Neal Gompa wrote: > > On Sat, Oct 24, 2020 at 11:16 AM Jan Rękorajski via pld-devel-en > wrote: > > > > I have prepared rpm 4.16, poldek and support packages, they are > > available on http://ftp1.pld-linux.org/people/baggins/rpm.org/ > > > > I would appreciate if you could test the uprade path, functionality > > and tell me if anything is missing / broken. > > > > Is there a set of git repos with the packaging and patches somewhere? > > Also, as an FYI: rpm-specdump can be retired for rpm's built-in rpmspec(8) > tool. > And the same goes for rpm-getdeps, I think. -- 真実はいつも一つ！/ Always, there's only one truth! ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm.org's rpm 4.16.0 ready for testing
On Sat, Oct 24, 2020 at 11:16 AM Jan Rękorajski via pld-devel-en wrote: > > I have prepared rpm 4.16, poldek and support packages, they are > available on http://ftp1.pld-linux.org/people/baggins/rpm.org/ > > I would appreciate if you could test the uprade path, functionality > and tell me if anything is missing / broken. > Is there a set of git repos with the packaging and patches somewhere? Also, as an FYI: rpm-specdump can be retired for rpm's built-in rpmspec(8) tool. -- 真実はいつも一つ！/ Always, there's only one truth! ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm plan (Re: rpm-build pulls perl)
On Mon, Mar 30, 2020 at 2:14 AM Elan Ruusamäe wrote: > > On 3/29/20 11:52 AM, Jan Rękorajski wrote: > > >> i think the pear dependency generator should be disabled by default, > >> pear is considered dead in php world. > > ` > > Then disable it, or even better, delete the scripts and config. > what is the rpm4/rpm5 plan again? i'd rather do this only once, not both > branches. These php PEAR dependency generator scripts are gone in rpm.org codebase anyway... -- 真実はいつも一つ！/ Always, there's only one truth! ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: ninja macros
On Sun, Oct 7, 2018 at 2:43 PM Elan Ruusamäe wrote: > > why is invoking ninja hidden behind these macros? > > > %build > %meson build > %meson_build -C build > > %install > rm -rf $RPM_BUILD_ROOT > %meson_install -C build > > > i.e %meson_build and %meson_install expand to ninja, just have %ninja > macro out there? > > > or at least %ninja_build and %ninja_install > I'm fairly certain that the upstream meson macros wrap %ninja_build and %ninja_install because it's entirely possible for another backend to replace ninja in meson in the future. But the behavior you're describing doesn't look like the upstream macros... -- 真実はいつも一つ！/ Always, there's only one truth! ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: libexec and multi-arch
On Mon, Feb 5, 2018 at 3:20 PM, Jeff Johnson wrote: > > >> On Feb 5, 2018, at 10:13 AM, Tomasz Pala wrote: >> >>> On Mon, Feb 05, 2018 at 10:47:32 +0100, Jacek Konieczny wrote: >>> >>> Using lib/lib64/libx32 instead of libexec was much smarter in this case. >> >> No, it only hidden the problem behind getconf binary being handled >> _somehow_. I once even wondered how this is done, apparently rpm is >> trying to be way too smart. >> > > RPM implements arch specific content generally as: > Libraries on different paths. > Executables on same path. > This requires a resolution to a preferred arch (usually x86_64) when > installing executables onto identical paths. > > Whether RPM is too smart or the requested implementation is insufficiently > general is arguable. For example, one might desire the ability for > per-file-path configurable choice of architecture rather than per-system > confIguration. > I'd probably argue that libexec should have the same multi-arch handling that (s)bin does (primary arch "wins" and secondary arches are ignored), though last I checked this isn't specific to paths and should Just Work(TM). -- 真実はいつも一つ！/ Always, there's only one truth! ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/openssl] use the generic ca-bundle path instead of PLD-specific ca-certificates one
On Sun, Dec 3, 2017 at 9:34 AM, Elan Ruusamäe wrote: > On 03.12.2017 16:27, Arkadiusz Miśkiewicz wrote: >> >> On Sunday 03 of December 2017, gotar wrote: >>> >>> commit 618e7076669ee7a48416373d5da4369647c57246 >>> Author: Tomasz Pala >>> Date: Sun Dec 3 09:15:35 2017 +0100 >>> >>> use the generic ca-bundle path instead of PLD-specific >>> ca-certificates >>> one >> >> Why? > > why not? > > seems compatible change to me. >> >> >>> -# define X509_CERT_FILE OPENSSLDIR "/cert.pem" >>> -+# define X509_CERT_FILE "/etc/certs/ca-certificates.crt" >>> ++# define X509_CERT_FILE "/etc/pki/tls/certs/ca-bundle.crt" > > reason likely same as the commit for updated dep: > > https://github.com/pld-linux/ca-certificates/releases/tag/auto/th/ca-certificates-20141019-3 > We use /etc/pki/tls paths in Mageia, and I believe Fedora and openSUSE do too. -- 真実はいつも一つ！/ Always, there's only one truth! ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Re: [Nurmukhamed/centos-7-build-asterisk-rpms] License missing (#2)
On Fri, Aug 18, 2017 at 11:53 AM, Jacek Konieczny wrote: > Hi, > > I got such question from a GitGHub user: what is the license of our spec > files and patches – the asterisk package in particular. > > I am pretty sure it was GNU GPL, but I cannot find any confirmation. > > So, what is the license of our work? > > Jacek > > If it's derived from the Fedora package (I don't know if this is the case), then it would be MIT licensed, as that's the license of Fedora package specs unless otherwise noted. -- 真実はいつも一つ！/ Always, there's only one truth! ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
