@Conan-Kudo pushed 1 commit.
fb305121ad7228b56f7b86ede47b021b99a573c9 elfdeps: Add full multiarch deps
support
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@Conan-Kudo pushed 1 commit.
46369dafd38c2c6240fb466bf8211333f3f66b4f platform: Ensure empty buildroot for
%install
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@ffesti, @pmatilai I'm deeply confused... I don't understand why the rpmbuild
runs in tests fail to be able to execute `/usr/bin/dirname`. Can you help?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
This change ensures that any existing buildroot contents are wiped
and a fresh empty one is created for usage in %install.
Variations of this exist in virtually every RPM-based Linux distribution
for more than a decade. At this point, it is expected behavior everywhere
and it is amazing that it
I've proposed this so that I can resolve
[RhBug:1523826](https://bugzilla.redhat.com/show_bug.cgi?id=1523826) in a
cross-distribution manner.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@ffesti Mainly because nothing else seemed to follow that convention? They all
seemed to use the GCC machine architecture name, and so we went with that.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@pmatilai I can fuse all three back into a single commit if you'd prefer
(that's how it was done in OMV). I broke them apart in case there was something
you'd want me to drop.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
@rwmjones In OpenMandriva, there was some interest in building the different
variants (including 32-bit stuff), so for a bit of future-proofing, we've gone
ahead and made the same architecture macro structure as ARM, MIPS, and POWER
have to simplify future work.
--
You are receiving this
@pmatilai The addition of this new architecture name is because we need a way
to declare incompatibility at the RPM level for CPUs that don't support it.
This is pretty much the only way we can do it. When this was first being worked
on, nobody seemed to think there was any better way to do
I've melded the 32-bit ARM macro updates into one commit, as requested.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@mlschroe This should be good to look at again. :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@Conan-Kudo pushed 1 commit.
f7ce837d5b6ed7663ce5774c6507fde6731436fe elfdeps: Add full multiarch deps
support
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@mlschroe I've added a default to enable biarch when neither option is set.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Conan-Kudo commented on this pull request.
> + break;
+case EM_MIPS:
+ elf_machine = "mips";
+ break;
+case EM_PPC:
+case EM_PPC64:
+ elf_machine = "ppc";
+ break;
+case EM_S390:
+ elf_machine = "s390";
+ break;
+case EM_ARM:
+
@Conan-Kudo pushed 1 commit.
7532c16153a793d516989f7b0cec622e85c10b33 elfdeps: Add full multiarch deps
support
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
Conan-Kudo commented on this pull request.
> + break;
+case EM_MIPS:
+ elf_machine = "mips";
+ break;
+case EM_PPC:
+case EM_PPC64:
+ elf_machine = "ppc";
+ break;
+case EM_S390:
+ elf_machine = "s390";
+ break;
+case EM_ARM:
+
@pmatilai @ffesti This doesn't seem to be working as intended. :(
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> since rpm >= 4.6, %{buildroot} is guaranteed to be defined to non-empty,
> non-"/" value so the tests are fairly redundant
The fact that SUSE continues to introduce those checks in _new_ stuff in
current versions of RPM makes me nervous about this property, so I kept the
safeguard in anyway.
Conan-Kudo commented on this pull request.
> + break;
+case EM_MIPS:
+ elf_machine = "mips";
+ break;
+case EM_PPC:
+case EM_PPC64:
+ elf_machine = "ppc";
+ break;
+case EM_S390:
+ elf_machine = "s390";
+ break;
+case EM_ARM:
+
@Conan-Kudo pushed 1 commit.
b79056006456be9a923b2dc17c789f35fce2b3a8 elfdeps: Add full multiarch deps
support
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@Conan-Kudo pushed 1 commit.
c730ef92f1fc746495663517e3ef6d92f348ea0f platform: Ensure empty buildroot for
%install
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@mikhailnov I'm not going to add architectures nobody has...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@mikhailnov what is e2k?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1038#issuecomment-581179157___
Rpm-maint mailing list
Conan-Kudo commented on this pull request.
> @@ -3107,7 +3107,7 @@ rpmRC processBinaryFiles(rpmSpec spec, rpmBuildPkgFlags
> pkgFlags,
int didInstall, int test)
{
Package pkg;
-rpmRC rc = RPMRC_OK;
+rpmRC res = RPMRC_OK;
I think it'd be better to restore
I dropped the checking because I don't understand `%{expr:}` well enough to use
it yet, and your points make a lot of sense for dropping the checking anyway.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Conan-Kudo commented on this pull request.
> @@ -67,6 +67,20 @@
#==
# Build policy macros.
#
+
+%__buildroot_clean %{__rm} -rf "%{buildroot}"} \
Oops.
--
You are receiving this because you are subscribed to
Conan-Kudo commented on this pull request.
> @@ -67,6 +67,20 @@
#==
# Build policy macros.
#
+
+%__buildroot_clean %{__rm} -rf "%{buildroot}"} \
+%{__mkdir_p} "%{dirname:%{buildroot}}"\
+%{__mkdir}
@Conan-Kudo pushed 1 commit.
147fbaf1fda2a9fd8c6dede8e8dc61406d7a20c9 platform: Ensure empty buildroot for
%install
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
Conan-Kudo approved this pull request.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1051#pullrequestreview-353748707___
Oh, I forgot about that... Lemme rework for that...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
It is not possible to evaluate scriptlets for dependencies and pushing that
back into rpm. Dependency generators work off of evaluating files to generate
dependencies leveraging specific content. Scriptlets generally lack this
information. Moreover, attempts to identify programs in shell
@pmatilai yay, I think I fixed it now. 浪
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1039#issuecomment-581882272___
@Conan-Kudo pushed 1 commit.
17a2747565834832809d2ae53b739c9d94b9bca2 elfdeps: Add full multiarch deps
support
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
Hmm, that's fair, and actually pretty much the reverse case of the problem I'm
going to have now with openSUSE environments built on Fedora.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Conan-Kudo commented on this pull request.
> @@ -3107,7 +3107,7 @@ rpmRC processBinaryFiles(rpmSpec spec, rpmBuildPkgFlags
> pkgFlags,
int didInstall, int test)
{
Package pkg;
-rpmRC rc = RPMRC_OK;
+rpmRC res = RPMRC_OK;
Maybe we should just filter out
@pmatilai My reading of this is that it only attempts a conversion if it can't
_write_ in the target database format. So it seems to be narrowly scoped enough
to not cause hell, while avoiding the nastiness of trying to do a database
conversion on the fly.
--
You are receiving this because
@pmatilai My thought there is that if scriptlets do progressive enhancement
(that is, they check for things and use if they're available), then this would
be useful functionality for that.
We used to have a number of those in Fedora, but these days I see them more
with third party packages
I definitely can see use-cases for this with some of the stuff I do for
`$DAYJOB`. For example, if an interpreter has multiple valid implementations,
being able to use `Suggests(*)` would allow the solver to be told which one to
prefer for that.
Generally speaking, if we allow strong
Conan-Kudo approved this pull request.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1027#pullrequestreview-350867595___
At least in this case, all Ryzen generation 1 and newer CPUs will match on
znver1, so I don't think that'd be a problem with this patch. But I take your
point about the general approach of adding more architectures.
I think it's probably something to explore on improving how we do this
At this point in time, `rpm-extras` is set up to be a dumping ground. It's
_not_ set up with any kind of quality things, any process of rationalization of
scripts and such. Without that, we're just going to commit stuff in there
that's not even going to work.
For example, the ALT Linux brp
> This is a dangerous argument, as by this logic we're required to accept
> anything at all that distros come up with.
I am very much aware of this. But considering this is how we were told to
implement this when we started this, I'm a little frustrated now that the
approach isn't good enough
> I'm just really, really weary and dubious about these architecture tweaks
> because they're so bleeping arbitrary.
I know, I don't particularly love it either, but RPM doesn't support defining
arbitrary architectures and architecture filter mechanisms. Each architecture
that people want to
Conan-Kudo requested changes on this pull request.
It's a good first start, just some initial nits...
> @@ -395,6 +395,7 @@ AC_SUBST(WITH_OPENSSL_LIB)
WITH_LIBGCRYPT_INCLUDE=
WITH_LIBGCRYPT_LIB=
if test "$with_crypto" = libgcrypt ; then
+ AC_DEFINE(WITH_LIBGCRYPT, 1, [Build with libgcrypt
Conan-Kudo requested changes on this pull request.
> +}
+#
+#
+usage() {
+echo >&2 "Usage: ${0##*/} -prov|-req [-f 'ocamlobjinfo cmd']"
+}
+#
+mode=
+ignore_implementation_a=()
+ignore_interface_a=()
+while test "$#" -gt 0
+do
+ : "${1}" "${2}"
+ case "${1}" in
+-prov) mode='prov' ;;
@mlschroe Are there patches SUSE has been backporting for SLE 15 that should be
included in here for 4.14.3?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@ffesti there have been a few cases where I'd like to directly generate runtime
dependencies from a specific file that doesn't necessarily get installed (like
`Gemfile` for Rails apps...).
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view
Conan-Kudo approved this pull request.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1070#pullrequestreview-359353949___
We used to have coverity scans running on rpm. We might want to see if we can
get that restored...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@ignatenkobrain No, there's no reason to move it there.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Conan-Kudo commented on this pull request.
> +}
+#
+#
+usage() {
+echo >&2 "Usage: ${0##*/} -prov|-req [-f 'ocamlobjinfo cmd']"
+}
+#
+mode=
+ignore_implementation_a=()
+ignore_interface_a=()
+while test "$#" -gt 0
+do
+ : "${1}" "${2}"
+ case "${1}" in
+-prov) mode='prov' ;;
+
@ignatenkobrain Three problems with it:
1. It would be regressive to current functionality for no good reason.
2. We don't have a way of distributing this in any kind of reasonable fashion
through rpm-extras.
3. IMO, That's not what rpm-extras is for. It's for staging things to
eventually
Conan-Kudo commented on this pull request.
> @@ -736,6 +736,16 @@ static rpmRC rpmPlatform(rpmrcCtx ctx, const char *
> platform)
}
+# if defined(__linux__) && defined(__x86_64__)
You're right, this was accidentally broken when I rebased it again...
--
You are receiving this
@ignatenkobrain This will be a crap situation to deal with in openSUSE, since
it's going to be a pain to make openSUSE keep this stuff in place correctly.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Conan-Kudo commented on this pull request.
> @@ -736,6 +736,16 @@ static rpmRC rpmPlatform(rpmrcCtx ctx, const char *
> platform)
}
+# if defined(__linux__) && defined(__x86_64__)
Wait nope, there's a `cpuid()` implementation for i386 right below...
--
You are receiving this
@fedya OpenMandriva 3.0 was rpm5, not rpm4. It isn't normally supported to sign
rpm5 packages with rpm4. If it was working with OpenMandriva 4.0 with rpm 4.14,
then that's a different story...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or
The RPM Python API may provide a way to build such a tool that could be
incorporated into [`rpmdevtools`](https://pagure.io/rpmdevtools), but there's
currently no such tool.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Conan-Kudo approved this pull request.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1006#pullrequestreview-341841785___
My current guess on how this slips through is that files that are marked as
excluded are still being passed to check-files, so it passes the check-files
check. But my attempts at trying to make it _not_ do that seem to be in vain...
:/
I at least have a test case to see if I fixed it, but so
How did you come up with the notation?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1014#issuecomment-576748339___
Rpm-maint
Also, we have a chunk of unused logic for Extras in here... Do we want to do
something with it?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@KOLANICH I'd rather you use the Debian bug reference than the patch URL. We
_have_ the patch, after all.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Conan-Kudo approved this pull request.
Code looks good and tests pass! :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Conan-Kudo approved this pull request.
Confirmed that it fixed the issue after backporting in OMV and ROSA.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@fedya Were you using rpm4 to sign six months ago? If so, what version and what
distribution?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Conan-Kudo approved this pull request.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/996#pullrequestreview-338018708___
> One possibility to handle the "conflict" might be making it an argument to
> --enable-bdb (eg --enable-bdb=readonly), which then skips the other variants.
> In that case it could technically be called "bdb" and avoid all the
> "configured to blabla, using blabla" warnings from backend
I just tried this on rpm 4.15.1 on Fedora 31, and it seems to still be broken
in this manner?
```
$ rpm --version
RPM version 4.15.1
$ rpm -qp --dump ./grep-3.3-3-rosa2019.0.i586.rpm
warning: ./grep-3.3-3-rosa2019.0.i586.rpm: Header V4 DSA/SHA1 Signature, key ID
c1c18146: NOKEY
/bin/egrep 28
@pmatilai
Original patch header information:
```
- vpkg-provides.sh, vpkg-provides2.sh: Use tempfile(1) for safe creation
of all temporary files. Many changes and untested. These scripts do not
work on linux anyway.
-- Joey Hess Thu, 19 Dec 2002 00:31:10 -0500
```
For what
> In other words, this is fewer lines than the BDB has source files.
This is a wonderful and equally terrifying statistic.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@KOLANICH That's really not the point. And webarchive systems do not
necessarily have this indexed.
The correct thing to do here would be to change the commit to have relevant
information:
```
$ git commit --amend --author="Michal Čihař " --date="Tue, 30
Dec 2014 11:55:15 +0100"
```
With the
@KOLANICH Here's a suggestion:
```
$ git commit --amend --author="Michal Čihař " --date="Sat, 11
Nov 2017 14:27:10 +0100"
```
With the following commit message:
```
tools/sepdebugcrcfix: Conditionally use MAP_POPULATE with mmap()
Not all architectures offer MAP_POPULATE. As MAP_POPULATE is
@pmatilai I'm pretty sure I'm going to want this for transitioning OpenMandriva
away from BDB. We're using db6 (even though I didn't want to...), and with the
latest versions of DNF okay with non-BDB, I can finally start considering it...
--
You are receiving this because you are subscribed to
@pmatilai The code works surprisingly well for me (which is terrifying and
awesome in itself), but I think I'd be more comfortable with this if it
conflicted with the regular bdb backend option.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly
Also... It appears `mktemp(1)` does not exist on AIX, which might be why this
script doesn't use it.
Cf.
https://stackoverflow.com/questions/10224921/how-to-create-a-temporary-file-with-portable-shell-in-a-secure-way
--
You are receiving this because you are subscribed to this thread.
Reply
@KOLANICH The patch was created by @joeyh in 2002, per `debian/changelog`.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Per the packaging description from Mageia:
> rpmconstant provides basic functions to map internal RPM constant values
> with their name. This is useful for perl/python or other language which has
> binding over rpmlib.
Based on that description and what the code _looks_ like it does, it allows a
(as for why I'm filing this now... well, I forgot about this in the shuffle two
years ago, and I was just reminded of this again today...)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
As part of some of the work I've done in OpenMandriva in transitioning the RPM
stack from rpm5.org to rpm.org RPM, I've discovered that there was an
_interesting_ behavioral difference with `%exclude`.
In rpm5.org RPM, `%exclude` does not give you a "get out of jail free" card to
bypass the
Perhaps @soig could explain rpmconstant use-cases? He's the maintainer of
rpmconstant and perl-RPM4...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@mlschroe This should probably conflict with the option to enable the normal
bdb backend. I see no reason for both to be enabled at the same time.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@KOLANICH I'd rather have the link to the Debian patch file removed from the
commit message. It's not particularly important...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Conan-Kudo approved this pull request.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/991#pullrequestreview-336458025___
@stefanbidi Can you try with the current git master? This should be fixed now.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Mageia (and Mandriva before it) has had a librpm extension library called
[rpmconstant](https://github.com/rpm-software-management/rpmconstant) for a
long time now.
I am not sure why this functionality does not exist in librpm itself, but it
probably should. While I am not proposing the
The problem with "randomly" defined tags is that the lack of consistency means
that RPMs can become incompatible with each other, simply by using the same
spots in the rpm header for different purposes. I suppose if the tag names were
discoverable from the header (e.g. with rpmconstant API),
This seems Debian specific? It also seems wholly unnecessary. This could
probably be dropped downstream too.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
This patch doesn't make sense to upstream. It also should just probably be
dropped downstream.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
This has been forwarded before. We did this in a different form upstream with
the "dummy" backend. Using that by default in Debian will "break" rpm as Debian
wishes.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Why is this safe? And is this a universally available property?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I feel like this patch is just asking for trouble. Given that it touches the
debuginfo generation code, I'm not terribly comfortable passing judgment here.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
It'd probably be better to use a POSIX sh-compatible way to use gettext instead
of straight up dropping internationalization capability.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@ignatenkobrain @pmatilai It seems like the tests are choking on `python`
binary missing?
```
+/opt/rpm/tests/rpmtests.dir/at-groups/398/test-source: line 70: python:
command not found
```
We probably need to request `/usr/bin/python` now...
--
You are receiving this because you are
Conan-Kudo approved this pull request.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/997#pullrequestreview-338989905___
@pmatilai Hey! I thought 74766d30b95f1575df8a42d185f2643caa235a8b might have
fixed it, since it sounded vaguely related!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Welp!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/997#issuecomment-571550507___
Rpm-maint mailing list
I guess this would mean that it would be a transaction task to identify changes
in alternatives and process them, similar to a transaction trigger?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> I guess the move isn't happening, and of course at this point it'd just break
> all the links to the current repo. I added a link to Rust RPM from
> http://rpm.org/software.html for added visibility.
> Thanks for your work on the bindings!
The bindings now live at
Conan-Kudo approved this pull request.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/999#pullrequestreview-339815518___
I think I did okay in this PR avoiding many freak cases, though I definitely
see your point about the broader architecture handling.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
601 - 700 of 1115 matches
Mail list logo
