On Sun, Nov 22, 2015 at 1:00 AM, Thierry Vignaud
wrote:
>
> On 21 November 2015 at 17:50, Neal Gompa (ニール・ゴンパ) <
> notificati...@github.com> wrote:
>
>> Per the recommendation of Nick Coghlan and Toshio Kuratomi, pythonXegg(M)
>> is being renamed to pythonX.Ydis
On Sun, Nov 22, 2015 at 1:00 AM, Thierry Vignaud
wrote:
>
> On 21 November 2015 at 17:50, Neal Gompa (ニール・ゴンパ) <
> notificati...@github.com> wrote:
>
>> Per the recommendation of Nick Coghlan and Toshio Kuratomi, pythonXegg(M)
>> is being renamed to pythonX.Ydis
On Thu, Nov 26, 2015 at 5:20 AM, Florian Festi wrote:
> On 11/19/2015 04:09 PM, Vít Ondruch wrote:
> > What is the usecase for this? Isn't this just feature bloat?
>
> I kinda agree that this looks like feature bloat. This patch set needs a
> very good justification to go in upstream. The overall
On Mon, Nov 30, 2015 at 4:22 AM, Vít Ondruch wrote:
> Dne 28.11.2015 v 14:37 Neal Gompa napsal(a):
>
> On Thu, Nov 26, 2015 at 5:20 AM, Florian Festi wrote:
>>
>> On 11/19/2015 04:09 PM, Vít Ondruch wrote:
>> > What is the usecase for this? Isn't this just feat
Florian,
It should be all nice and fixed up in the GitHub PR. I added an extra
patch on top to resolve getopt related issues, so everything should be
peachy. :)
Thanks for the patch. :)
On Thu, Feb 11, 2016 at 11:34 AM, Florian Festi wrote:
> I think the different cli flags are not orthogonal e
On Fri, Feb 12, 2016 at 6:42 PM, Kamil Rytarowski wrote:
>
> Thanks!
>
> I somehow lost interest since --chroot cannot be implemented with
> rpm(1) on NetBSD with chroot(2). There is not known a breakage from
> NetBSD chroot.
Kamil,
Two things:
* Doesn't --root already use chroot(2)? Also, as fa
On Fri, Mar 18, 2016 at 11:10 AM, Lubos Kardos wrote:
> Hi,
>
> I went through the bug #564613 [1] and now I am considering add section end
> markers to rpm spec syntax. I would add only optional end markers to preserve
> backward compatibility i. e. if the end marker is not used then the end of
>
On Wed, Aug 10, 2016 at 10:09 AM, Richard W.M. Jones wrote:
> Returning the value into a char is a mistake on all platforms, but is
> particularly bad on RISC-V. On that platform (like ARM) char is
> unsigned. Therefore EOF (-1) is returned as 255, and the subsequent
> test 'c == EOF' ('255 == -
On Wed, Aug 10, 2016 at 1:52 PM, Richard W.M. Jones wrote:
> On Wed, Aug 10, 2016 at 06:51:43PM +0100, Richard W.M. Jones wrote:
>> So this sort of works.
>>
>> However %{_arch} is not defined, for reasons I don't understand.
>>
>> # uname -a
>> Linux stage3 4.1.26-01508-g592a151 #1 Sat Aug 6
On Thu, Sep 15, 2016 at 8:53 AM, Mark Wielaard wrote:
> GCC6 will warn about:
>
> lib/rpmplugins.c: In function ‘rpmpluginsCallInit’:
> lib/rpmplugins.c:217:5: warning: this ‘if’ clause does not guard...
> if (hookFunc)
> ^~
> lib/rpmplugins.c:219:9: note: ...this statement, but the latt
On Fri, Oct 14, 2016 at 9:33 AM, Panu Matilainen
wrote:
>
> Hey folks,
>
> Time to get rpm 4.13.0 out of the door. But in order to do that, we'll need
> to cut -rc2 first, there's just too much change to jump right into final.
>
> The idea is to get -rc2 out next week (ie by Oct 21st at latest). I
On Sun, Jan 15, 2017 at 11:43 AM, Ralf Corsepius wrote:
> On 01/15/2017 04:03 PM, Neal Gompa (ニール・ゴンパ) wrote:
>
>> I'm not sure how true it is, but it seems to bear out with the number of
>> previously BDB users now being LMDB users.
>
>
> Unless a different DB of
It comes up with increasing regularity that we don't have a way to
represent ranges of versions for a single dependency (c.f. RHBZ[1] and
RPM GitHub[2]). Most language-specific dependency managers (e.g. pip
for Python, gem for Ruby, composer for PHP, cargo for Rust, npm for
Nodejs, whatever Golang
On Thu, Oct 29, 2020 at 12:15 AM L A Walsh wrote:
>
> I was out of touch from my normal internet connectivity for a few
> months and when I got back and d/l'd rpms and tried to use them
> I got an error:
>
> Failed dependencies: rpmlib(PayloadIsZstd)
>
> I tried building rpm from source, but it h
On Thu, Oct 21, 2021 at 11:19 AM Justus Winter wrote:
>
> Hello,
>
> I'd like to propose to replace RPM's built-in PGP support with Sequoia.
> Sequoia is an OpenPGP implementation written in Rust. We have released
> Sequoia 1.5 earlier this week, which is the first version released under
> the LG
On Thu, Oct 28, 2021 at 11:17 AM Justus Winter wrote:
>
> Panu Matilainen writes:
>
> >> https://tests.sequoia-pgp.org/rpmsop.html#Detached_Sign-Verify_roundtrip_with_key__Bob___MD5
> >>
> >> - accepts MD5 signatures !!!
> >>
> >> https://tests.sequoia-pgp.org/rpmsop.html#Signature_over_the_shatt
On Mon, Oct 25, 2021 at 10:42 AM Justus Winter wrote:
>
> Neal Gompa writes:
>
> > What about DNF? The DNF package manager also uses gpgme right now, and
> > one of the larger problems we have right now is that we have no
> > unified keyring between DNF and RPM, beca
On Tue, Dec 7, 2021 at 9:05 AM Panu Matilainen wrote:
>
> On 12/7/21 06:00, Chris Murphy wrote:
> > Hi RPM and DNF folks,
> >
> > I have a draft change proposal for review and comment, i.e. it's not yet
> > set to be published to Fedora devel@. It's a bit thin, but I expect to
> > fill in more det
(Adding the correct Daniel Mach email address, he moved from Red Hat
to SUSE last month...)
On Thu, Dec 9, 2021 at 10:11 AM Chris Murphy wrote:
>
> On Thu, Dec 9, 2021 at 5:01 AM Jaroslav Mracek wrote:
> >
> > Hello Chris,
> >
> > On Tue, Dec 7, 2021 at 5:01 AM Chris Murphy wrote:
> >>
> >> Hi
It should be compatible with that too, since it's effectively `Tag(qualifier)`
format.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/463#issuecomment-1474183736
You are receiving this because you are subscribed to this thread.
Messag
I think so, yes.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/463#issuecomment-1474507843
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing
@Conan-Kudo approved this pull request.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2430#pullrequestreview-1349357701
You are receiving this because you are subscribed to this thread.
Message ID: __
@Conan-Kudo approved this pull request.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2441#pullrequestreview-1349359077
You are receiving this because you are subscribed to this thread.
Message ID: __
`%getmem` could be useful for making `%limit_build` work better in Fedora, so I
think it'd be worth having.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2418#issuecomment-1476902969
You are receiving this because you are subscribed to
That's even better. 👍🏾
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2418#issuecomment-1477683506
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint m
Thank you so much for finally doing this! 🥳
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2451#issuecomment-1494685753
You are receiving this because you are subscribed to this thread.
Message ID: __
If we're doing our own FindLua module, can we still leverage pkgconfig if it's
available?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2469#issuecomment-1498748502
You are receiving this because you are subscribed to this thread.
Mess
In general, I'm wary about this whole approach because it reduces/eliminates
the fungibility of compatible library implementations.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2372#issuecomment-1499585799
You are receiving this becaus
Have we tried advocating to Lua upstream to include a pkgconfig file recently?
If not, maybe that's worth doing, and then we can keep relying on pkgconfig.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2469#issuecomment-1501028061
You a
I don't think it's unreasonable for those flags to be exposed out of the gate.
It would certainly be nice if there was an extensible way to add more of them,
but this patch, as it is, is simple and reasonable to mainline.
--
Reply to this email directly or view it on GitHub:
https://github.com/
@Conan-Kudo requested changes on this pull request.
> @@ -750,11 +750,12 @@ Supplements: (%{name} = %{version}-%{release} and
> langpacks-%{1})\
RPM_SOURCE_DIR=\"%{_sourcedir}\"\
RPM_BUILD_DIR=\"%{_builddir}\"\
RPM_OPT_FLAGS=\"%{optflags}\"\
+ RPM_LD_FLAGS=\"%{?build_ldflags}\"\
I
Well, RPM has the "fat" arch for multi-arch RPMs already...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-5613991
You are receiving this because you are subscribed to this thread.
Message ID:
_
Actually, it should be `/usr/share/dbus-1/system.d/`
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2474#issuecomment-1511399657
You are receiving this because you are subscribed to this thread.
Message ID:
@Conan-Kudo approved this pull request.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2530#pullrequestreview-1461356520
You are receiving this because you are subscribed to this thread.
Message ID: __
Wait what? That's what what I said.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-6084512
You are receiving this because you are subscribed to this thread.
Message ID:
_
I said that mtimes for files in the payload are the only thing that actually
matters for clamping to SOURCE_DATE_EPOCH. We absolutely don't want
SOURCE_DATE_EPOCH by default affecting package buildtimes.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-manag
For RPM packaging purposes, the `librpm` subpackage would be
`LGPL-2.1-or-later`. Fedora's `rpm-libs` package would be `LGPL-2.1-or-later
and GPL-2.0-or-later` while the rest of the binary packages would be
`GPL-2.0-or-later`.
--
Reply to this email directly or view it on GitHub:
https://githu
Actually, maybe we should rename `fat` to `multi` instead and use that to
inform RPM that it needs to process per-file architecture information.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-6087757
You are
The Python generator has always supported multifile, since it was originally
written for that case way back when. This will be a sweet speed-up!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2537#issuecomment-1582302318
You are receivin
@Conan-Kudo approved this pull request.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2571#pullrequestreview-1526020644
You are receiving this because you are subscribed to this thread.
Message ID: __
@Conan-Kudo requested changes on this pull request.
Looks like this isn't working exactly:
>From CI:
```
[ 73%] Building C object CMakeFiles/rpmuncompress.dir/tools/rpmuncompress.c.o
/srv/rpm/tools/rpmuncompress.c: In function 'doUntar':
/srv/rpm/tools/rpmuncompress.c:101:39: error: passing ar
What do we do if we want to run the test suite on non-Linux? Like macOS?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2559#issuecomment-1632247013
You are receiving this because you are subscribed to this thread.
Message ID: __
Yocto will probably wind up using this too, since they support the RPM stack
with architectures like this.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2540#issuecomment-1632250845
You are receiving this because you are subscribed to t
Darwin has `chroot()` like all POSIX systems. I'm not sure if `fakechroot`
works on Darwin, but [`fakeroot`](https://salsa.debian.org/clint/fakeroot) is
supposed to work on macOS and is [available via
homebrew](https://formulae.brew.sh/formula/fakeroot).
Darwin also has the sandbox API (which A
I have a virtual machine with macOS that I do destructive things in.
Occasionally that includes running the test suite, but even just making a build
environment for RPM in macOS manually (and avoiding homebrew) is pretty messy,
so I do all that work in a dedicated virtual machine.
--
Reply to
@Conan-Kudo approved this pull request.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2571#pullrequestreview-1526434141
You are receiving this because you are subscribed to this thread.
Message ID: __
> Unfortunately the suggested format of `Source(sha256): format` is not
> backward compatible with older rpm releases, and having the checksum as an
> extra tag (with autonumbering) and if conditions could be error prone and
> tricky.
Is backward compatibility really an issue if we're talking a
@Conan-Kudo approved this pull request.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2571#pullrequestreview-1547721323
You are receiving this because you are subscribed to this thread.
Message ID: __
@Conan-Kudo requested changes on this pull request.
> +This is enough for regular Linux distributions, except Yocto. Yocto has
+so called Board Support Packages (BSPs) that cover more than the CPU
+architectures. These BSPs cover specific single board computer systems.
+Examples of such BSP name
@Conan-Kudo commented on this pull request.
> +
+hasgroup() {
+ grep "^${1}:" "$ROOT"/etc/group >/dev/null
+}
+
+user() {
+ local user="$1"
+ local uid="$2"
+ local desc="$3"
+ local group="$4"
+ local home="$5"
+ local shell="$6"
+
+ [ "$desc" = '
There's also the missing case for the `root` user, as the default shell for UID
0 is defined to be `/bin/sh`.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2573#issuecomment-1651811249
You are receiving this because you are subscribed t
@Conan-Kudo approved this pull request.
This is weird, but I can't find anything overwhelmingly wrong with it
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2585#pullrequestreview-1548364281
You are receiving this because you are subsc
For what it's worth, I think we should _at least_ consider making a build flag
to switch RPM to use `C.UTF-8` instead of `C`, and make our CMake default to it
for Linux.
>From my research, it seems that Darwin/macOS does the "interesting" thing of
>overlaying UTF-8 support to the C locale by do
We shouldn't make the problem worse, and there are plenty of people using RPM
on macOS for various reasons. We will have support for it one way or another.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2587#issuecomment-1654994764
You
Fixes #2569
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2588
-- Commit Summary --
* CI: Add initial GitHub Actions configuration
-- File Changes --
A .github/workflows/linux.yml (16)
-- Patch Links --
https://gi
@Conan-Kudo pushed 1 commit.
e1249d42d350b473f53d3eda25761a034251bae2 CI: Add initial GitHub Actions
configuration
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2588/files/2f792c1b7aae0bb9e0f32b1743555663acdf8180..e1249d42d350b473f53d3eda25761a034251bae2
You are rec
@Conan-Kudo pushed 2 commits.
2074852a883335613cd6285f188d73b557c72e78 tests: Do not use interactive mode
for mktree.podman "make check"
5467e43fc7a5c0c3f4592cba83328aefb1fedc09 CI: Add initial GitHub Actions
configuration
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/
This will also lay the groundwork for us to add macOS CI to RPM, as GitHub
Actions offers Mac runners we can use.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2588#issuecomment-1655040608
You are receiving this because you are subscrib
@mlschroe A lot of the stuff around bundled dependencies are often expressed as
`bundled()` Provides either manually or via dependency generators in Fedora.
I'm not sure we want to do something different when that works fairly well...
--
Reply to this email directly or view it on GitHub:
https:
As part of the production of SRPMs, RPM injects the C/C++ compiler flags into
the `Optflags` tag and a processed spec file into the `Spec` tag.
As we can't reasonably use the `Optflags` and `Spec` tags effectively for
builds and it creates issues when `noarch` packages are built on different hos
@Conan-Kudo approved this pull request.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2600#pullrequestreview-1565047659
You are receiving this because you are subscribed to this thread.
Message ID: __
On Thu, Mar 23, 2017 at 2:22 PM, Gleb Fotengauer-Malinovskiy
wrote:
> It can be dropped because this code was never actually enabled.
> Actually, this implementation *surely* never ever compiled.
>
Are you sure of this? Because this is supposed to be wired up so RPM
builds and runs correctly on B
On Thu, Jun 22, 2017 at 10:20 PM, Darren Hart (VMware)
wrote:
> Introduce a --disable-bdb configuration option which disables the use of
> Berkeley DB entirely. Update the various autotools to ensure that at
> least one of BDB or NDB is enabled. Existing configuration options
> continue as before.
On Fri, Jun 30, 2017 at 12:38 AM, Darren Hart wrote:
> On Thu, Jun 29, 2017 at 08:33:46AM +0100, Neal Gompa wrote:
>> On Thu, Jun 22, 2017 at 10:20 PM, Darren Hart (VMware)
>> wrote:
>> > Introduce a --disable-bdb configuration option which disables the use of
>>
On Mon, Oct 9, 2017 at 11:25 AM, Richard Brown wrote:
>
> What do you all think? And if a change like this is on the cards as an rpm
> default, where would the likely
> location be?
>
So, I think we should probably expose this as an configure switch, and
default to /var/lib/rpm. Most people have
On Fri, Oct 13, 2017 at 2:44 AM, Panu Matilainen wrote:
> On 10/12/2017 11:16 PM, Thierry Vignaud wrote:
>>
>> On 12 October 2017 at 11:22, Panu Matilainen wrote:
>>>
>>>
>>> In short, RPM 4.14.0 is out now. It's not quite what we originally had in
>>> mind - some things we planned for didn't mak
On Mon, Oct 16, 2017 at 11:22 AM, Richard Brown wrote:
> On Fri, 2017-10-13 at 11:31 +0300, Panu Matilainen wrote:
>
>> The database path has always been trivially configurable with a macro
>> without having to patch rpm, nobody is taking that away. And because
>> it's so trivial to change it real
On Wed, Oct 25, 2017 at 7:30 AM, Panu Matilainen wrote:
> On 10/25/2017 02:06 PM, Mark Wielaard wrote:
>>
>> On Wed, 2017-10-25 at 12:49 +0200, Igor Gnatenko wrote:
>>>
>>> On Wed, 2017-10-25 at 13:46 +0300, Panu Matilainen wrote:
>>> So I'm wondering how to make this less ugly.
The
On Thu, Oct 26, 2017 at 5:59 AM, Richard Brown wrote:
> On Wed, 2017-10-18 at 08:51 -0400, Colin Walters wrote:
>>
>> On Wed, Oct 18, 2017, at 06:56 AM, Panu Matilainen wrote:
>>
>> > I don't see /usr/lib as a *good* place for this, but if a new top level
>> > directory in /usr seems too much then
On Wed, Nov 29, 2017 at 9:20 AM, Colin Walters wrote:
> [/me moves to center of thread, pulls out defibrillation machine, *zzzt*
> *zzzt*]
>
> On Thu, Oct 26, 2017, at 04:59 AM, Richard Brown wrote:
>>
>> As we're pressed on time, openSUSE will be going right ahead and moving it's
>> rpmdb to /u
On Mon, Dec 11, 2017 at 12:19 PM, Baho Utot wrote:
> In rpm version 4.11.2 I define some macros in /etc/rpm/macros.
> After compiling and installing version 4.14.0 I have a few questions.
>
> Is this still the place to define system wide macros?
>
> If not how does one go about doing that?
>
On Tue, Feb 27, 2018 at 5:03 PM, Vladimir D. Seleznev
wrote:
> Hello, rpm-maint@!
>
> We in ALT Linux Team implemented some new RPM tags for our RPM package
> header and RPM database. Since RPM tags are numerical identifiers and we
> want to keep compatibility with mainstream RPM tools and package
On Thu, Mar 29, 2018 at 11:00 AM, Michael Schroeder wrote:
> On Wed, Mar 28, 2018 at 04:02:16PM +0300, Panu Matilainen wrote:
>> The reason for the "unexpected" rich dependency backport is that we failed
>> to add a new rpmlib() dependency tracker when adding these new dependencies,
>> and thus rp
On Wed, Sep 12, 2018 at 9:41 AM Thierry Vignaud
wrote:
>
> Le mer. 12 sept. 2018 à 14:30, Igor Gnatenko
> a écrit :
> >> In Mageia, we eg had:
> >> 1) manual "requires(post)" or "requires(posttrans): info-install"
> >> (info-install being the package containing /sbin/ /sbin/install-info
> >>
Hey all,
As I had alluded to in the pull request adding the SQLite rpmdb
backend[1], I have been doing some work every once in a while for the
past few years on rpm for macOS.
A point of frustration has been having a working bdb package, and
maintaining bdb is functionally impossible for me, as I
75 matches
Mail list logo
