Merged #3074 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3074#event-12712137504
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
While these were necessary to get things going, they are only counterproductive
now: we want to be able to freely use C++ features inside rpm.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/3074
-- Commit Summary --
*
Closed #3049 as completed via #3071.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3049#event-12711076211
You are receiving this because you are subscribed to this thread.
Message ID:
___
Merged #3071 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3071#event-12711076023
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Closed #3072.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3072#event-12710658133
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
Sorry but I agree with @nwalfield , this is just strange churn for churn's
sake. Like advertising use of goto but then still using return for the cases
that *could* use a central clean-up point. Even the changes that I could use
because I suggested them are mixed with unrelated other changes,
v6 will have signed payload size information :
https://github.com/rpm-software-management/rpm/pull/3017/commits/784bb9076d614da33d29123f5ef6236a57d38463
--
Reply to this email directly or view it on GitHub:
> So is there a way to detect the SRPM build?
Whether an SRPM gets generated by a build is not something the spec should be
aware of. It's not a separate thing - it may take place as an isolated step or
as a part of a binary build. A plain SRPM build does not invoke the dynamic
spec generation
Sub-package noarch's a special case hack that doesn't cause spec parse
recursion. So the answer is: nothing.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3071#issuecomment-2095257485
You are receiving this because you are subscribed
@pmatilai pushed 1 commit.
a5ea8c6db14455399d5447601ab0b5ebe7896878 Automatically reload rpm
configuration on mismatching BuildArch
--
View it on GitHub:
Eh, including the test-spec in the commit improves the chances of success...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3071#issuecomment-2084986916
You are receiving this because you are subscribed to this thread.
Message ID:
@pmatilai pushed 1 commit.
d09c5e9543dedac603f95e7a3252b10fecea5d85 Automatically reload rpm
configuration on mismatching BuildArch
--
View it on GitHub:
The way buildForTarget() now serves two quite different purposes is a bit ugly
of course but keeps the patch small. I'd rather live with this for now and
address the whole thing at a more fundamental level later on.
--
Reply to this email directly or view it on GitHub:
When BuildArch is encountered during spec parse, rpm recurses the parse, but
this doesnt reset/reload the global configuration and macros to match. So
eg a BuildArch: noarch package gets built with a dramatically
different macros depending on whether --target noarch was used or
not, whereas
--target causes the entire rpm configuration to be reloaded from scratch, and
since --undefine operates on the init macro context at program startup, the
rpmPopMacro()'s it does get lost in the reload. Filing this as "documentation"
for the issue: if nothing else, it's inconsistent behavior.
Thing is, since the payload is typically compressed, offsets are useless
because they'd just point to somewhere in the middle of a compression stream.
If the files in the payload were individually compressed, it'd seem quite
reasonable to have offsets stored. Of course that would likely loose
There are no offsets stored, so I don't think there is.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2057#discussioncomment-9271000
You are receiving this because you are subscribed to this thread.
Message ID:
Merged #3069 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3069#event-12652696073
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Merged #3067 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3067#event-12652692342
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Merged #3066 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3066#event-12652691270
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Merged #3062 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3062#event-12652690152
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
> The rpm payload format isn't modified, although there's a slight "bending" of
> the cpio/newc spec to use the filename field for padding. zstandard frames
> making up the compressed rpm payload explicitly carry both compressed and
> uncompressed lengths, to allow detection of
@pmatilai pushed 1 commit.
658bc4f097fd0dd050e10b3ee31a31d25fa35be1 Drop architecture from %builddir path
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3069/files/60ca0113b7a935f3e670e390b4720def7fbadd62..658bc4f097fd0dd050e10b3ee31a31d25fa35be1
You are receiving
The compressed and uncompressed digests are *alternatives*, both cannot be
valid at the same time. Rpm calculates both but uses the one that matches (if
any). This is to allow freely changing between uncompressed and compressed
format of the same content, which "obviously" must be a legit case.
This causes more issues than it solves, at least presently. For one, when
BuildArch is used it typically causes the path to disagree with the actual arch
(eg on noarch packages). Which looks weird and causes yet other issues in turn.
The other issue, raised by Neal Gompa, is that it can cause
> I took the liberty to make this whole source look better.
Better is subjective. The indentation was mostly following rpm coding style,
now it's not. See Coding style / Indentation in CONTRIBUTING.md. Never, ever
make formatting changes at the same time as other changes, and in particular,
Hmm, and of course we have entirely different way of reporting the error on
install, eg:
> [root@localhost _build]# ./tools/rpm --define "_urlhelper /bad" -U --nodeps
> --root /srv/test
>
If sources or patches in the spec are defined via a macro that does not yet
exist, itll still work for building if the macro has been defined by that
time as theres another round of expansion there. But this can leave the
source/patch names inserted to the header disagreeing with what actually
You can't.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/3065#discussioncomment-9261221
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
The final commit turns the macro entry stack into an STL container too, making
the macro entries themselves freestanding and since all this is now standard
library stuff we don't need to manually clean up and deallocate etc.
--
Reply to this email directly or view it on GitHub:
Nothing hugely interesting in here, see commit
0d1071b99ada2df920ba657d9e015e0c2259d4b6 for rationale.
There are bits and pieces to finish in librpmio side still but moving on to
librpm as some of this stuff is linked, eg string pool cannot use C++
containers before rpmds is updated to clean
@pmatilai pushed 3 commits.
9c28251cdb3664839a5a03b6f6b15f096653483b Add copy control and in particular,
destructor to the macro context
3ff1f78c49d63d75b30cc46607edfb148cb5e948 Convert macro table to STL containers
+ native strings
a06877ec1ed1fd5ac8cbaae8100288a2b220fd5c Untangle the
No, we'll cherry-pick obvious fixes when doing the next release.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3056#issuecomment-2078687995
You are receiving this because you are subscribed to this thread.
Message ID:
Have local recipes from building from those upstream sources, install in
suitable prefix with LD_LIBRARY_PATH. In a word, painfully? :smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2877#issuecomment-2077175576
You are
Use an STL map for the macro entry table, this matches exactly the behavior we
manually did with the C array.
The variable length array at end of macro entry structs is not really C++, use
native strings for the storage. Its slower, but not tragically so. For
now, keep name, opts and body as
Merged #3060 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3060#event-12605908368
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
@pmatilai pushed 2 commits.
666caf176f6845cca30ab8c697cea48d05ca38db Replace a couple of local IO buffers
with a vector
aae0ee12c4f6b9aac19be04654d83ed7500901a2 Replace temporary argv array in Lua
posix.exec() with a vector
--
View it on GitHub:
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/3060
-- Commit Summary --
* Take advantage of rvasprintf() in rpmlog()
* Use strings as keyid and STL map for keyring storage
* Replace homegrown mallocing getcwd() with
Oh and thanks for reporting! Like the testcase shows, we *kinda* knew about
this all along but had forgotten, and who knows how long more this might've
lurked along :smile:
--
Reply to this email directly or view it on GitHub:
I totally get the testing use-case, we have -bb --short-circuit for similar
reasons. Only with --short-circuit we "poison" the produced packages to prevent
people from distributing them (accidentally or otherwise).
Anyway, I agree there seems to be a bug - or more likely a few - in there.
We discussed this at some length, and actually the current behavior seems
correct.
Nosource items are not managed by rpm in any way: they don't get pulled into
src.rpm's, and if you want to rebuild an src.rpm utilizing nosources, you need
to manually copy any nosource items in place. It's then
@pmatilai pushed 1 commit.
6e816f3f05c0c3f7f123e2bb0e7d8c11d7acd506 Fix multiply defined local macros
escaping scope
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3059/files/e2cba360ec40d34538de99ebf4c007821b847866..6e816f3f05c0c3f7f123e2bb0e7d8c11d7acd506
You are
freeArgs() only popped any local macros once, so if a local macro was pushed
multiple times, whether through %define or multiple identical options getting
passed, we leaked any remaining macros to the outside scope.
Simply pop the local macros in a loop to fix. Have the internal popMacro()
This gets kinda philosophical: --rmsource removes sources, but is a "nosource"
a source? The name seems to indicate it's not.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3037#issuecomment-2074167627
You are receiving this because
This should fail instead of quietly falling back to fdio.
$ python -c "import rpm; print(rpm.fd('/dev/null', 'w', 'aaaiiiooo'))"
Besides being ugly buggy, it kinda prevents us from testing optional io types
as well.
--
Reply to this email directly or view it on GitHub:
It's a bug alright. I actually just stumbled on that code a couple of days ago
thinking this doesn't look right. It isn't.
It's not just multiple identical options, it's any local macro multiply
defined, issue being that freeArgs() only ever pops once. Easily reproduced
with eg
> rpm --define
@pmatilai commented on this pull request.
> @@ -248,4 +248,29 @@ char *argvJoin(ARGV_const_t argv, const char *sep)
return dest;
}
-
+
+ARGV_t argvFromVaList(const char *fmt, va_list ap)
+{
+ARGV_t argv = argvNew();
No need for argvNew(), argvAdd*() handles that as needed.
@pmatilai commented on this pull request.
> @@ -145,6 +145,9 @@
#%__systemd_sysusers @__SYSTEMD_SYSUSERS@
%__systemd_sysusers%{_rpmconfigdir}/sysusers.sh
+# enable debug package generation
+%_enable_debug_packages 1
I realized this doesn't belong to the main macros.in, really - it
@pmatilai commented on this pull request.
> %global __debug_package 1\
+%(cat > "%{specpartsdir}/rpm-debuginfo.specpart" << EOL\
I'd like it a whole lot more if the `cat` was in the template part. This is an
ugly side-effect for a macro to have, eg somebody doing `rpm --eval
Nice, thanks!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3055#issuecomment-2071520497
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing
Merged #3055 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3055#event-12570092472
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Closed #3024 as completed via #3047.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3024#event-12570032397
You are receiving this because you are subscribed to this thread.
Message ID:
___
Merged #3047 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3047#event-12570032216
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Merged #3054 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3054#event-12570029080
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Added a bunch of rationale/background to the first commit message, no code
changes.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3054#issuecomment-2071512091
You are receiving this because you are subscribed to this thread.
Message
Would really be nice to get rid of this stuff in rpm...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3051#issuecomment-2069259429
You are receiving this because you are subscribed to this thread.
Message ID:
Merged #3051 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3051#event-12558970441
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Convert a bunch of dynamic allocations in librpmio to native C++ new/delete to
enable use of native structures in those structs and then take advantage of it.
Misc other string/vector conversions too.
This is a pretty random stuff, the primary points being to bring the number of
raw C
Yup. Note "ideally" in there - this is stuff to explore with, and indeed for
packaging hygiene reasons rather than any "security" thing.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3050#issuecomment-2065908096
You are receiving
Closing in favor of a more generic #3050
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3010#issuecomment-2065857806
You are receiving this because you are subscribed to this thread.
Message ID:
Closed #3010 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3010#event-12533384975
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Ideally, the build scriptlets would be isolated from each other:
- %prep unpacks the source, and %build takes place in a separate directory
against a read-only source. Obviously not all software can be built outside the
source tree, but this would be a nice addon to vpath builds (#2985)
-
Rpm already hashes any packaged content cryptographically (SHA256 by default),
any such mechanism should utilize that to minimize the extra cost.
But this seems like a big extra cost with limited benefit, we're more
interested in *preventing* writes across the different stages.
--
Reply to
Seems I've managed to throroughly confuse myself with the recent split :joy:
So yup, we still need to support the internal parser in 4.19.x but *this*
change is not there, and while we still have openssl-related code in >= 4.20,
DSA is not part of it.
--
Reply to this email directly or view
This is not about "preventing XZ", it's just somewhat inspired by it.
I really don't know why multiple people are arguing against rpm looking to do
some extra packaging hygiene enforcement here. In a similar vein, rpm would
prefer an unwritable build directory during %install.
Hashing the
One report of the issue is here:
https://bugzilla.redhat.com/show_bug.cgi?id=2069163 but also ran into this in
various other circumstances, eg #2319 and %ifarch not working in dynamic spec
parts.
The spec parsing recurses through build architectures, pushing and popping
%_target_cpu as it
Merged #3045 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3045#event-12520804092
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Oh, of course. I'm already forgetting I just split a good chunk of that code
out :laughing:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3045#issuecomment-2063473913
You are receiving this because you are subscribed to this thread.
There may not be DSA keys in active use but they do exist in old distros and
packages people may want to install for whatever reason. If we broke it we
should fix it.
--
Reply to this email directly or view it on GitHub:
There should be a test for the case where the urlhelper is missing - it's what
we can easily test, and also happens to be the case we're also most interested
in for the bug.
> $ ./tools/rpm --define "_urlhelper /not/there" -qp
>
So the API we updated to just now was there all this time? Oh well...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3045#issuecomment-2063422093
You are receiving this because you are subscribed to this thread.
Message ID:
...aaand then in the exact reverse order to make up a nice refactoring series.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3047#issuecomment-2063363180
You are receiving this because you are subscribed to this thread.
Message ID:
@pmatilai pushed 3 commits.
9e9a3fa747a285876726c33ca8d4df15a6f6759b Refactor getSection() to more
generally useful
106c81b7050c255e4281eb3f4717c601e40fb7e9 Refactor build script parse calls to
a helper
39ff076a33d645ec4e40b0ca07c7ecad74df0912 Fix build scriptlet append/prepend
interaction
@pmatilai pushed 1 commit.
b50ac2d506491e3651797b4a4e2f133731c2ddb0 Refactor getSection() to more
generally useful
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3047/files/3bf011d4aa230f120f07d205d5e9bff710b5e8c6..b50ac2d506491e3651797b4a4e2f133731c2ddb0
You are
@pmatilai pushed 1 commit.
3bf011d4aa230f120f07d205d5e9bff710b5e8c6 Refactor parseBuildScript() to take
spec PART_* numbers instead of names
--
View it on GitHub:
@pmatilai commented on this pull request.
> @@ -461,6 +461,13 @@ when name is omitted, the description refers to the main
> package.
Package build is divided into multiple separate steps, each executed
in a separate shell.
+Only one of each section can be present in a spec, but all build
The append and prepend modes got added before the declarative Buildsystem, and
did not get thoroughly tested with it. The existing %build -a test didnt
actually work but automake handling the build in %install masked the issue
embarrasingly. As the Buildsystem is parsed after everything else,
The current behavior is a mistake really, and one that we'll be reverting in
6.0: https://github.com/rpm-software-management/rpm/issues/2581
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/3044#discussioncomment-9140144
You are
I guess you'd need a lawyer to answer this one, but the autogenerated
debugsource can only contain stuff that was built.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/3035#discussioncomment-9139731
You are receiving this because
That %install definition is a bug in its own right: #2204 - yes, this is an
upstream issue.
As for build-in-place alternatives, not really, the very concept of building
from whatever happens to be around is alien to rpm's design of pristine
sources.
--
Reply to this email directly or view
With this, #3036 now passes with debuginfo enabled by default.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3043#issuecomment-2058941726
You are receiving this because you are subscribed to this thread.
Message ID:
Now with debug packages enabled by default.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3036#issuecomment-2058940742
You are receiving this because you are subscribed to this thread.
Message ID:
@pmatilai pushed 2 commits.
63cdb8add41c1708f23e681239f628ba7fd00e3d Add proper program logic for
debuginfo enablement
33068282eef319bfe7687d177718962dd904c32f Enable debuginfo package generation
by default now that we can
--
View it on GitHub:
Merged #3043 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3043#event-12488348307
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
--build-in-place is a hack that doesn't fit well into rpm's view of the world,
I doubt debuginfo is the only thing that doesn't work with that. Thanks for the
report though.
--
Reply to this email directly or view it on GitHub:
Like #3040, this would need to pass with `%_enable_debug_packages 1` in the
main macros file (currently it fails a bunch).
It's an interesting solution, but I don't see making it any less magic, perhaps
to the contrary.
--
Reply to this email directly or view it on GitHub:
This really needs to be done with `%_enable_debug_packages 1` as default in
macros.in.
With that, this fails on 332 and 409, so there's at least that much more work
to do.
--
Reply to this email directly or view it on GitHub:
Merged #3034 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3034#event-12482993321
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Excellent, thanks!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3034#issuecomment-2058321276
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint
Oh it's certainly not the best way imaginable, it'd be nice to move this all to
a script or something, but ... its complicated. The decision to create
debuginfo packages must happen before %install in the spec is parsed, because
*extracting* debuginfo is hooked into %__spec_install_post based
On a related note, we should really differentiate between loops which we *can*
resolve, and those that we can't. Eg a loop which resolves reliably by eg
pre/post qualifier, there's no reason to complain about, probably not even
--deploops output. The ones we can't resolve, we should make far
Clearly it's Monday - took me a few moments to see the difference to
https://github.com/rpm-software-management/rpm/commit/23770e1a4f28c56a31fe600cae332c77333b60b6
:sweat_smile:
I'd be wary of adding any default rule there but clearly ECDSA belongs to DSA
as much as EDDSA does, no objection
FWIW I think there's plenty of cleanup possibilities in this area, but for now
I just want something to ship in 4.20.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3036#issuecomment-2056391869
You are receiving this because you are
All these years, enabling debuginfo has required distros to hijack the spec
%install section with a macro like this:
%install %{?_enable_debug_packages:%{?buildsubdir:%{debug_package}}}\
%%install\
%{nil}
This for a widely used, longtime upstream supported feature is just gross, and
Merged #3031 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3031#event-12436417461
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
This leak has been there ever since rpm 4.7.0, so pretty close to 15 years.
ASAN wouldve caught it, if it had it been tested. Oops. Of course, in the
fakechroot era we couldnt have tested installation but we couldve at
least tested the parsing side.
Add tests for parsing, query and install
Basically the returned value throws off our expectations wrt the Lua stack.
I need to sharper head than today to figure what exactly to do with it, we
probably should allow returning an exit code for success/failure in this way.
And in any case we shouldn't crash.
--
Reply to this email
Oh and, thanks for the report and reproducer!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3029#issuecomment-2047189180
You are receiving this because you are subscribed to this thread.
Message ID:
Easily reproduced. There issue is related to `return 0`, something doesn't like
data being returned from there.
It's a bug we need to fix, but in the meanwhile, just drop the `0` from the
return and it should work.
--
Reply to this email directly or view it on GitHub:
FWIW, turns out this stuff is pretty crippled in the alpha release due to these
two issues:
https://github.com/rpm-software-management/rpm/issues/3024
https://github.com/rpm-software-management/rpm/issues/2204
They don't prevent one from developing buildsystems but pretty much prevent
using
101 - 200 of 7772 matches
Mail list logo
