Okay this PR served its purpose, lessons learned: not this way, and not just
now.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2886#issuecomment-1935490089
You are receiving this because you are subscribed to this thread.
Message
Merged #2893 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2893#event-11754933396
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
This started life as pkgdump.c written way back when I needed to analyze some
low-level issues with malformed packages and the like. Since then its
proven necessary every once in a blue moon, so might as well include it in the
rpm codebase where it may actually be kept up to date and even
> I think the database is abnormal because the verification fails when I run
> the rpm command,
You mean 'rpm --verify'? What errors?
> or the "rpm -qa" command cannot find the kernel package, but the "rpm -q"
> command can find the kernel package. According to the result, the problem is
>
Okay, managed to produce one by myself:
> [pmatilai︎localhost ~]$ clang -target bpf -c bpf.c -o bpf.o
> [pmatilai︎localhost ~]$ file bpf.o
> bpf.o: ELF 64-bit LSB relocatable, eBPF, version 1 (SYSV), not stripped
So it's an architecture by itself, speced to be always 64bit:
Other ponderings include the per-build directory macro name, should it be just
%builddir without the underscore (instead of %pkgbuilddir)
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2885#issuecomment-1931865327
You are receiving this
Merged this into a single commit at least for now as the changing paths clashed
in maddening ways in the test-suite on rebases, making simple changes too hard
to bother with.
Buildroot is just BUILDROOT now. I would've used name-version-release.arch for
the per-build directory, but this turns
@pmatilai commented on this pull request.
> @@ -303,6 +300,24 @@ static rpmRC doCheckBuildRequires(rpmts ts, rpmSpec
> spec, int test)
return rc;
}
+static rpmRC doBuildDir(rpmSpec spec, int test, StringBuf *sbp)
+{
+char *doDir = rstrscat(NULL,
+ "rm -rf
@pmatilai pushed 1 commit.
9d19699f6c8dc0c3eeaf8dcea820e76171aac84d Introduce an rpm-controlled per-build
directory
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2885/files/80a60aa2bddb78a897e6279891ec58d862d92d74..9d19699f6c8dc0c3eeaf8dcea820e76171aac84d
You are
The thing is (well, one of the things) is that, foo-1.0/foo-1.0 can mask a bug
or packaging error. The ugly -PKG suffix was absolutely necessary for seeing
which path a thing is actually trying to use when developing this PR, and will
be equally necessary for packagers trying to troubleshoot
Um, what exactly do you mean by "database being abnormal" then?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2828#issuecomment-1931688028
You are receiving this because you are subscribed to this thread.
Message ID:
AFAICS --target was always wrong from the autoconf cross-compilation
terminology point of view. For what it does in rpm, --host would be closer to
the mark. But outside a autoconf terminology explanation, would anybody ever
guess that --host somehow relates to output architecture and stuff?
> Not a fan of the `-PKG` and `-root` suffixes.
The -PKG is ugly for sure, but *some* differentation from the traditional
%setup created directory seems necessary to drive the point across, and make
logs easier to look at. If you just have 'foo-1.0/foo-1.0/' its easy to mix up
etc. NEVRA
@pmatilai commented on this pull request.
> @@ -303,6 +300,24 @@ static rpmRC doCheckBuildRequires(rpmts ts, rpmSpec
> spec, int test)
return rc;
}
+static rpmRC doBuildDir(rpmSpec spec, int test, StringBuf *sbp)
+{
+char *doDir = rstrscat(NULL,
+ "rm -rf
Nobody knows. See https://github.com/rpm-software-management/rpm/issues/1650
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2889#discussioncomment-8382986
You are receiving this because you are subscribed to this thread.
Message
Aside from those three-way indiretions making me cringe a bit (not that it
makes any difference here), looks pretty straight-forward to me.
This is one where feedback from active packagers would be useful.
--
Reply to this email directly or view it on GitHub:
Multiple buildroots could be useful for the the "variant builds" case, but the
arch-os naming doesn't help with *that* at all, the potential benefits I see
are more far fetched. But, it's useful to shake things a bit, it doesn't *have*
to be BUILDROOT just because we've had such a thing in the
I'll still want to see the "real-world" test cases added to this. The gotchas
and bugs are always in the part that you didn't think needs testing :laughing:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2405#issuecomment-1929442665
@pmatilai commented on this pull request.
> @@ -91,5 +91,16 @@ macros which is nicer in other situations, e.g.:
Always test for the `with`-condition, not the `without`-counterpart!
+## Overrinding Defaults
+
+For distributions it can be useful to overwrite the build conditionals on a
One more thing wrt the macro name: I wonder if this is a case where it should
*not* have those leading underscores. The generator itself is full of those,
but the newly added macro here is something directly intended for packager use.
--
Reply to this email directly or view it on GitHub:
@pmatilai commented on this pull request.
> @@ -995,6 +995,25 @@ runroot rpm -qp --requires
> /build/RPMS/noarch/shebang-0.1-1.noarch.rpm|grep -v ^
[])
RPMTEST_CLEANUP
+AT_SETUP([Local dependency generator])
+AT_KEYWORDS([build])
+RPMTEST_CHECK([
+RPMDB_INIT
+
+runroot rpmbuild -bb --quiet
@pmatilai commented on this pull request.
> - bn[strlen(bn)-strlen(".attr")] = '\0';
- fc->atypes[i] = rpmfcAttrNew(bn);
+ nfiles = argvCount(files);
+}
+char * local_attr_names = rpmExpand("%{?__local_file_attrs}", NULL);
+ARGV_t local_attrs =
@pmatilai commented on this pull request.
> - fc->atypes = xcalloc(nattrs + 1, sizeof(*fc->atypes));
- for (int i = 0; i < nattrs; i++) {
- char *bn = basename(files[i]);
- bn[strlen(bn)-strlen(".attr")] = '\0';
- fc->atypes[i] = rpmfcAttrNew(bn);
+
@pmatilai commented on this pull request.
> - bn[strlen(bn)-strlen(".attr")] = '\0';
- fc->atypes[i] = rpmfcAttrNew(bn);
+ nfiles = argvCount(files);
+}
+char * local_attr_names = rpmExpand("%{?__local_file_attrs}", NULL);
+ARGV_t local_attrs =
> > There are a few memleak fixes
>
> Oh, you mean (some commits from) #2879. Indeed, I somehow ignored this whole
> PR due to it starting with "Add support for ..." I'll look at those patches
> and see if cherry picking at least some of them would make sense, thanks.
Yup, those. OTOH you
@kloczek , this is not about SPECPARTS although if you *look* at the PR, that's
one of the issues that gets solved by this. See #2532 for the background.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2885#issuecomment-1929038038
You
I guess what you mean by "merging" is something entirely different than me &
ffesti think of.
Binary rpm's are immutable end products of a spec which directs rpmbuild to
produce said rpms. Somehow undoing a separation set by the packager is just not
a meaningful operation at all. The only
> I am not sure if tying this to the `%setup` is useful, unless there is also
> some alternative to setup this independently. Maybe if the `%{-s}` also
> accepted some alternative build name(s).
The way builds are tied to %setup, I think there needs to be a way to achieve
this via %setup. It
There are a few memleak fixes + maybe the unsigned buildtime thing that might
be worth considering too. Although, there's always the next release, so up to
you.
--
Reply to this email directly or view it on GitHub:
> Do I understand correctly that the `BUILDROOT` dir was replaced by
> `%{_builddir}/%{_target_cpu}-%{_target_os}-root`? The `%{_builddir}` is the
> right move IMHO, but what is the advantage of
> `%{_target_cpu}-%{_target_os}-root` over `BUILDROOT`, especially when e.g.
> `SPECPARTS` stays
Making remote execution (cross-compilation) easier added (inspired by
https://github.com/rpm-software-management/rpm/discussions/2884)
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2078#issuecomment-1928947972
You are receiving this
Oh. Reading more carefully now, I can see a lack of "the" and a relevant plural
in "running test suites" :sweat_smile: Adjusted the title to make it clear.
All the build scriptlets have (some) support for remote execution through this:
> %___build_cmd %{?_sudo:%{_sudo}
> Steps to reproduce:
>
>package gcc: version 1.1
>package hello: BuildDepends gcc; changelog epoch 1; but its build script
> includes SOURCE_DATE_EPOCH in the binary
>build package hello
>update package gcc to version 1.2
>[...]
I get that this is the real-world scenario,
@dmnks feel free to correct/extend, but the test-suite does run as a separate
step in the "native" mode using already built binaries. That's only supported
on Fedora at the moment but that's AIUI just a matter of somebody adding +
maintaining a native dockerfile for their target distro.
--
FWIW, the %{NAME}-%{VERSION}-PKG name is not really intended as final, I used
that just to have it stand out from the logs. Better ideas welcome.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2885#issuecomment-1926715511
You are
Besides PoC, this is of course rather simple-minded too. There may be some
interesting possibilities in supporting multiple build variants natively here.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2886#issuecomment-1926707782
You
@pmatilai pushed 1 commit.
80a60aa2bddb78a897e6279891ec58d862d92d74 fixup! Introduce an rpm-controlled
per-build directory
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2885/files/2e18582771df083726278bc64feee8b8b5268e74..80a60aa2bddb78a897e6279891ec58d862d92d74
This is on top of the per-build directory PR because it makes this much easier
to do, ie the actual feature here is just the last commit.
This is NOT meant for merging at this point, just that even a crude
implementation is easier to discuss than thin air. See also
Add a new %setup switch -s to indicate building in a directory outside the
source directory, known as vpath build in some circles. Add a new
%{sourcesubdir} macro which by default equals %{buildsubdir}, but when -s is
used, we create and switch to a separate directory after unpacking.
A one
@pmatilai pushed 2 commits.
beeb017d5f471aa5572f5c18365ece89cce8ebd0 Make buildroot fully rpm controlled,
always inside the per-build directory
2e18582771df083726278bc64feee8b8b5268e74 Move SPECPARTS to per-pkg builddir,
no longer needing name-version
--
View it on GitHub:
In our ancient wacko setup, %_builddir is shared by all your packages, under
which a package may create %buildsubdir - if it uses %setup that is. In other
words, theres no safe and sane place for rpm to place per-build material.
Introduce a new intermediate directory between the two, created in
Good point wrt multiple build directories :+1: While we have native support for
these kind of multiple variants builds via `RemovePathPostfixes` (which isn't
used by vim or python in fedora, curl does though), having separate build and
buildroot directories could make that easier to use.
--
Append/prepend is still operating on exactly one script of a type. Adding
support for multiple scripts for each step would be a huge amount of work for
very little benefit, I don't see that happening. With append/prepend, you can
place sub-package specific build scriptlet sections into their
Vpath builds added...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2078#issuecomment-1923786897
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint
Yeah I was aware Fedora is doing cmake builds in a vpath, but that's quite a
different thing from having rpm natively support it.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2882#discussioncomment-8346327
You are receiving
Oh, yup, this can be closed now. Thanks again!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2664#issuecomment-1923700556
You are receiving this because you are subscribed to this thread.
Message ID:
Closed #2664 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2664#event-11683454322
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
rpmbuild traditionally builds in the same directory where it unpacks the
sources. Probably at least in part because in the nineties anything else was
considered fancy pants that few projects supported. Apart from hand-rolled
makefiles, these days the situation is almost the opposite: any sane
I'd like to see tests with real-world bconds in packages. We already have tests
for bcond so this can build on top of those.
I'd like to see documentation and tests on how this is supposed to be used in
real life, answering some practical matters like
- Where would the overrides/defaults be
@pmatilai commented on this pull request.
> @@ -22,6 +26,8 @@ static struct poptOption optionsTable[] = {
N_("provide more detailed output"), NULL },
{ "dry-run", 'n', POPT_ARG_VAL, , 1,
N_("only print what would be done"), NULL },
+{ "path", 'C', POPT_ARG_STRING, , 0,
> This all makes `__local_file_attrs` look less horrible than I first thought
Indeed. It's sufficiently vague to cover both cases we care about, and totally
accurate in the sense that its local to the build.
> `__additional_file_attrs` is actually kinda close but not quite as it implies
>
Merged #2859 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2859#event-11682412695
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Oh well, rpmuncompress is an internal tool and we can still change the option
names before we release if need be, no point getting stuck over that here.
I initially misunderstood what happens when there are multiple top-entries, but
having cleared that up for myself, I think this is good to go.
@pmatilai commented on this pull request.
> @@ -22,6 +26,8 @@ static struct poptOption optionsTable[] = {
N_("provide more detailed output"), NULL },
{ "dry-run", 'n', POPT_ARG_VAL, , 1,
N_("only print what would be done"), NULL },
+{ "path", 'C', POPT_ARG_STRING, , 0,
@pmatilai commented on this pull request.
> @@ -22,6 +26,8 @@ static struct poptOption optionsTable[] = {
N_("provide more detailed output"), NULL },
{ "dry-run", 'n', POPT_ARG_VAL, , 1,
N_("only print what would be done"), NULL },
+{ "path", 'C', POPT_ARG_STRING, , 0,
Thanks for the test-cases! I see four tarballs added but only two used. Also,
it's better to add separate tests as separate RPMTESTS_CHECK() (under a shared
setup/cleanup block). Makes it easier to see what's going on and where.
--
Reply to this email directly or view it on GitHub:
The issues with this one start with the topic. Reproducible builds are
reproducible whether manually or automatically, we don't need this patch for
that. None of this makes any sense without reading up a whole lot of additional
context as to how some initially unmentioned buildsystem processes
That's a spec syntax issue, it doesn't matter for package format.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-8331847
You are receiving this because you are subscribed to this thread.
Message ID:
I recently fixed a couple of signed int time usages, the rest of the plan is
here:
https://github.com/rpm-software-management/rpm/issues/1229#issuecomment-1920724526
No point breaking compatibility to be 80+ years future compliant.
--
Reply to this email directly or view it on GitHub:
Closed #1084 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1084#event-11666047548
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
AFAICS we have precisely five relevant time-related APIs:
- rpmfiFMtime()
- rpmfilesFMtime()
- rpmtsTid()
- rpmtsSetTid()
- pgpDigParamsCreationTime()
Mtime and tid are stored in a uint32_t tag in the package as per RPM v3/v4
spec, former at build and latter at install-time. OpenPGP timestamps
Yes, I get that you have repetitive sections. Like I've been telling you:
script it (build scriptlets are shell scripts, you can have functions in there)
or macroize it, with parameters to allow for the variety. The package name in
macros would not be helpful here at all.
--
Reply to this
Oh yup, sorry for leaving you hanging in the air here. Technically this looks
pretty good (but yup, could use a test-case). What this needs now is us
thinking it all through, taking other plans into consideration and see how the
details fit in with those. Don't despair in the meanwhile
Merged #2881 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2881#event-11652657021
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
@pmatilai pushed 1 commit.
8b8f905d29b6bf92fd36f712ef55a59360353405 Fix an UB in expression code (when
built without -fno-strict-overflow)
--
View it on GitHub:
Similar to ASAN, now that we can this is a nice and cheap way to keep compiler
gremlins at bay.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2881
-- Commit Summary --
* Add a build option for enabling undefined behavior
Merged #2879 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2879#event-11652142792
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
> This seems to defeat the point. The point of this is to clamp the times to
> the date stamp in the changelog. If you're doing automatic rebuilds, you
> should not use that feature, full stop.
:+1:
It looks like an attempt to eat and keep the cake, and we all know how well
that works.
>
Details in commits, but in short
- fix a bunch of leaks + other issues found by ASAN
- add ENABLE_ASAN build-option to cmake, and enable it on CI going forward
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2879
-- Commit
There are some pretty nasty bugs in 4.19.1 still, I think we should put out an
expedited bugfix release to address at least these regressions:
- https://github.com/rpm-software-management/rpm/pull/2843
- https://github.com/rpm-software-management/rpm/pull/2818
Other, less nasty stuff:
-
Can you point me to such a specimen?
Rpm doesn't know anything about EBPF, the warning/error is based on detecting
ELF files which up to now have been pretty arch-specific.
--
Reply to this email directly or view it on GitHub:
Yep, both rpm-sequoia and popt are something we'd occasionally want to build
from sources instead of packaged versions. So this is actually fairly important
piece, even if we have managed without it so far.
--
Reply to this email directly or view it on GitHub:
One thing just for the record, up to now elfdeps has been path agnostic by
design to match the dynamic linker: it doesn't matter where those libraries
come from as long as they're in the runtime path. Of course it's not an "end
user tool" but having consistent output regardless of the file
Actually, we'll need to have this path-discovery wrapped in some libc specific
helper script in rpm because this eg musl has an entirely different library
search path mechnism. That's fine though, for glibc we could implement our own
ld.so.conf parser for the immediate use and then once the
Yeah elfdeps basically ignores all path-aspects, it only really handles
DT_NEEDED and DT_SONAME.
One thing here though: a manually added require/provide is not equal to one
discovered by rpm, the latter are tracked on file-level and rpm actually uses
this information. That's why I'm so
> If there was some macro with package name, I think I could simplify this:
>
> %{gem_extdir_mri}
> %dir %{gem_instdir}
> %{gem_libdir}
> %{gem_spec -d}
If you declared these macros in terms including some %{name} then ... you'd
have X number of such identical %files sections, now just even
Note that I'm specifically avoiding talking about filtering these dependencies
out because I think in many cases its more useful to turn them into something
else instead.
--
Reply to this email directly or view it on GitHub:
Yes, that possible ld.so.conf fragment in the buildroot needs to be covered.
But, I think the hosts ld.so.conf[.d] needs to be processed as well. The
currently building package could be installing to a subdirectory that some
other package (which would have to be a build-dependency) has declared
No no. What I'm telling you is to script the file section generation. Something
like
```
for n in psych mental; do
cat << EOF > ${n}.txt
%{ruby_libdir}/${n}
%{ruby_libdir}/${n}.rb
%{ruby_libarchdir}/${n}.so
#...
EOF
done
```
...and include from %files with -f. Or make that a spec local macro
If you have lots of those with nothing but the name changing, no macros will
help with that. Generate those files manifests programmatically from %install
and include with %files -f.
--
Reply to this email directly or view it on GitHub:
:monocle_face: seems most appropriate here...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2874#issuecomment-1910081323
You are receiving this because you are subscribed to this thread.
Message ID:
So this is actually another bug fixed by
a0553eb38a01772254cd48fef7ad116294cf801a
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2874#issuecomment-1910075031
You are receiving this because you are subscribed to this thread.
Message
Looking at `cpio -t` output is proving more helpful :smile:
This from the Ubuntu-created file:
> [pmatilai︎localhost tmp]$ cpio -tv < out |head -4
6 blocks
drwx-- 1 root root0 Jun 28 2011 ./a/dir
-r 1 root root 15 Jun 28 2011 ./a/file
drwx--
Okay, the headers are otherwise identical so it's the payload that has to
differ then, and that payloaddigest changing throws everything else off too.
And indeed, extracting the rpm2cpio output shows some differences (from `diff
-u -a` output), eg:
```
The above *almost* works. It's just that the ld.so.conf from Fedora causes an
"ldconfig: need absolute file name for configuration file when using -r" error
from ldconfig. Had me scratching hair for a bit because I thought it ws
complaining about the path I was passing in -f which *was*
4.18.2 would be missing at least this: 7ec148c1d61e0b526ae5c917f0ddc2b4a3222146
which could affect it.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2874#issuecomment-1909841982
You are receiving this because you are subscribed to
I remember a case or two where the checksums mismatch due to different libmagic
versions producing different strings. I also remember tweaking the test to
avoid relying on libmagic stuff there, but don't remember when exactly. But
yes, it's fragile. Very.
--
Reply to this email directly or
If guessing and trying fails, 'runroot rpm -qp --xml
/build/RPMS/noarch/attrtest-1.0-1.noarch.rpm' is your friend, one can then diff
the output of that between working and non-working files. We should probably
dump that output anyway to make it more debuggable.
--
Reply to this email directly
Yes, a clean way to discover the system library paths searched by the dynamic
loader would go a long way.
Hmm. I guess this is kinda doable by running `ldconfig -r ` followed
by `ldconfig -r -p` from which you can pull the directories (so
effectively the path) or the files themselves. Just do
FWIW, I think we should follow the [Python
lead](https://github.com/rpm-software-management/python-rpm-packaging) and call
it perl-rpm-packaging to allow for all sorts of helper material to live there
and not just macros/scripts and the like. A bit of consistency is a nice bonus.
--
Reply to
@pmatilai commented on this pull request.
> @@ -78,16 +84,81 @@ static char *doUncompress(const char *fn)
return cmd;
}
+/**
+ * Detect if an archive has a single top level entry, and it's a directory.
+ *
+ * @param path path of the archive
+ * @return 1 if archive as only a
Static checking in RHEL discovered exactly one place where we still had time_t
conversion to signed integers: getBuildTime(). Fixed that in
https://github.com/rpm-software-management/rpm/commit/97aa64d8281974fb369c66d5aef8650515b89c52,
I think we can consider this done now.
--
Reply to this
Closed #1228 as completed via 97aa64d8281974fb369c66d5aef8650515b89c52.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1228#event-11582158266
You are receiving this because you are subscribed to this thread.
Message ID:
This is one of those topics that gets raised semi-annually at least. To point
out a couple, https://bugzilla.redhat.com/show_bug.cgi?id=2259260 and
https://bugzilla.redhat.com/show_bug.cgi?id=1464368 and
https://github.com/rpm-software-management/rpm/issues/1227 but there are
certainly more
Thanks for the patch!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2856#issuecomment-1905777264
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint
Merged #2856 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2856#event-11568363991
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
I'm not actually finished with this, but I do have a local backup anyway,
closing is okay.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2835#issuecomment-1905561075
You are receiving this because you are subscribed to this thread.
@pmatilai commented on this pull request.
> @@ -532,7 +532,7 @@ static int filerequireTag(Header h, rpmtd td,
> headerGetFlags hgflags)
/* I18N look aside diversions */
-#if defined(ENABLE_NLS)
+#if defined(ENABLE_NLS) && (defined(__GLIBC__) || !defined(__linux__))
AFAICS this isn't
I'm glad this ended up on your plate, I never found the patience to sort this
out :smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2871#issuecomment-1905533378
You are receiving this because you are subscribed to this thread.
Merged #2871 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2871#event-11566516191
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
701 - 800 of 7772 matches
Mail list logo
