rpm2archive could use some love for sure, but I'd rather not teach it about
format internals, that's just the kind of thing I'd rather outsource to
somebody else - like libarchive. If it doesn't do what we want it to do, then
lets at least look at fixing it instead of doing it in rpm, it'd benef
Int vs enum type mismatches, initialization order consistency and other
"fascinating" trivia.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2977
-- Commit Summary --
* Fix some int/enum confusion in the build code
* Fix
Merged #2975 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2975#event-12147493990
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mail
Thanks for the patch!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2975#issuecomment-2003154611
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mai
Merged #2977 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2977#event-12147549787
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mail
This one is a particularly bad case of int/enum abuse. Not so suprisingly,
using separate variables for sqlite and rpm side returns makes the stuff much
saner. I can kinda remember this even: "Just make it work now, I'll
clean it all up later" and this is payback time.
You can view, comment on,
It just warns about the unknown attribute.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2972#issuecomment-2003338390
You are receiving this because you are subscribed to this thread.
Message ID: __
@pmatilai pushed 4 commits.
9bc302619451dac4745c5513f22686f32c4750de Fix int/enum type mess in
sqlite_pkgdbPut()
e5356bcad92b53b68330056b72c2710af0db804a Fix a few int/enum messes wrt
sqlite3_step() use
631692bd020456608834f7d003c1fcbcdd3a1269 Fix int/enum type mess in
sqlite_idxdbByKey()
61
And this is about file names, I think "upstream rpm" treats those pretty much
as binary as they are created by the build process and not part of the spec
file.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2972#issuecomment-200334575
I think pretty much everybody that uses rpmarchive just does it to pipe it into
tar/cpio to extract the content. How about adding an option so that it can
directly extract the content?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/29
Merged #2978 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2978#event-12149204018
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mail
Right. So the warning would only be seen by folks who run rpm2archive to
convert legacy rpms to tar - ie a rare corner case really. A harmless warning
from gnu tar in that case is quite acceptable to me at least.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-softw
Why "legacy"? Does the current code reject non-utf8 file names?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2972#issuecomment-2003513183
You are receiving this because you are subscribed to this thread.
Message ID: _
It does, by default. For many years now.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2972#issuecomment-2003543922
You are receiving this because you are subscribed to this thread.
Message ID:
That makes things a bit easier, so we just need to teach libarchive that it
should accept utf8. I'll adapt the title of this issue ;-)
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2972#issuecomment-2003579832
You are receiving this b
Closed #2880.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2880#event-12149995726
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
Rpm
The discussion has moved to
https://github.com/rpm-software-management/rpm/discussions/2934 and
https://github.com/rpm-software-management/rpm/pull/2944, seems to me we can
close this somewhat controversial draft.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-so
@Conan-Kudo commented on this pull request.
> @@ -245,6 +245,10 @@ Supplements: (%{name} = %{version}-%{release} and
> langpacks-%{1})\
# Is ignored when SOURCE_DATE_EPOCH is not set.
%clamp_mtime_to_source_date_epoch 0
+# If true, make sure that timestamps in built rpms
+#
rpmsign cannot know what the previous reservation (if any) was, so it *cannot
guarantee* going back to the former state on --delsign.
That said, there's something very wonky here, the reserved space doesn't appear
to get used at all on signing, although it does reclaim the space from the
--del
@pmatilai converted this issue into discussion #2980.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2963#event-12150300723
You are receiving this because you are subscribed to this thread.
Message ID:
Closed #2952 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2952#event-12150341988
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint m
You're instructing rpm to both exclude and include a file. It possibly do both,
so the only reasonable course of action can be erroring out.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2952#issuecomment-2003646399
You are receiving
> When I remove the unnecessary 'Requires:' of one package, I found that the
> residual package which is no more required can not br removed when upgrade. I
> tried 'Obsoletes', but I found that it affects other packages that requires
> it.
Impossible to give any detailed response because there
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2981
-- Commit Summary --
* Bunch of docs formatting cosmetics
-- File Changes --
M docs/manual/queryformat.md (34)
M docs/manual/spec.md (2)
-- Patch Links --
htt
Merged #2981 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2981#event-12150925799
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mail
> the only reasonable course of action is erroring out.
Shall I open separate ticket?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2952#issuecomment-2003741467
You are receiving this because you are subscribed to this thread.
Messag
Bernhard mentioned that the size of the rpm stays the same on --delsign, but
should shrink by 1104 bytes. I haven't calculated it myself but the direction
of that looks right and a quick read of the code looks like it should be doing
that (but I would need look much more careful to identify why
> So it looks to me like it is not reclaiming the space during --delsign. Where
> or why do we disagree?
>
> It looks to me like the reservation is hard coded. So as long as the rpm that
> was used to build and the one that was used to --delsign is the same it
> should be able to guarantee it,
Reopened #2952.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2952#event-12152413309
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
Hmm, it seems I misread the report because I thought that's what was happening,
I guess the strange ticket summary set the stage for strange ideas what will
follow.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2952#issuecomment-2003
I apologize if my previous description was not very precise. What I meant to
say was that if A originally depends on B, and we remove the "Requires B" from
the spec, the next time we upgrade A using "dnf upgrade" or "rpm -U", it will
not simultaneously remove B. This is different from the effect
I have not really wanted to suggest this should be prohibited / reported as an
error.
But since duplicates are already detected and reported, reporting this would be
in line with that and possibly prevented possible surprises, so that is
acceptable.
--
Reply to this email directly or view it
We've just published our roadmap for the next three years:
https://rpm.org/roadmap
Of course the big thing there is the looming RPM v6.0 on which we can now shed
a lot more light on, so copying it here:
RPM 6.0 release
* Introducing [RPM
v6](https://github.com/rpm-software-management/rpm/discu
Ever since the RPM upstream reboot in 2006, we've been striving to replace the
old-school, hand-written pointer gymnastics with general purpose APIs in the
codebase. We've come a long way, but all this time we've been dreaming about
richer data structures than C has to offer. Of course in C, you
After 2022-06-20 we changed to a new rsa4096 signkey for the project.
%__gpg_reserved_space seems to default to 4096 bytes so that should fit. And
indeed, rpm --delsign leaves the size as is.
With [this
dump-rpm-headers.py](https://gist.github.com/koseki/9737a4490128bcb8b426c22a0b7c3885)
I get
Just FWIW, there's now an in-tree tool for looking at low-level package
structure:
https://github.com/rpm-software-management/rpm/blob/master/tools/rpmdump.c
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2965#issuecomment-2005946927
36 matches
Mail list logo
