Unlike #2390, this doesnt change the bit-level value so its backwards
compatible, this is just for eliminating compiler level ambiguity.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2391
-- Commit Summary --
* Move
Closed #2390.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2390#event-8486970992
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
Having slept over it, no. At least not just now.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2390#issuecomment-1425334499
You are receiving this because you are subscribed to this thread.
Message ID:
I hope I get this right, because I'm no expert for that topic either.
SBOM is "Software bill of materials". Basically it is a document that describes
what exactly is on a product/appliance/container/... There are two standard
formats, SPDX and CycloneDX, coming from different directions.
SPDX
Deep in the Finnish countryside? :sweat_smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2389#issuecomment-1424229682
You are receiving this because you are subscribed to this thread.
Message ID:
But but but... where have you been? Software supply chain security is the thing
nowadays ;-)
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2389#issuecomment-1424220433
You are receiving this because you are subscribed to this thread.
@pmatilai pushed 5 commits.
b95f5ece77f1a737c0f93e5d8d81c615a9fe0735 Use proper type for
copyTagsFromMainDebug
ff25dc68a0e25caee247d92a6cd9def857a7ffdb Move RPMTAG_NOT_FOUND out of the
rpmTag enum into a macro
03f55eb3035e18358dfc34f5276b5be67b687ba8 Bump RPMDBI_PACKAGES enum from 0 to 1
Yes, this is a documentation issue.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2064#issuecomment-1424217697
You are receiving this because you are subscribed to this thread.
Message ID:
RPMTAG_NOT_FOUND being -1 while all the valid data is unsigned causes all
manner of headaches throughout the code in the form of type mismatches and
potential associated bugs. Zero makes for a much nicer not-found value, shuffle
things around a little to make this possible.
The caveat of
Hard for me to comment when I don't know a single term/name mentioned here,
starting with SBOM which I looked up from wikipedia :laughing:
A smallish practical example of what that data may look like would help.
--
Reply to this email directly or view it on GitHub:
Well, nothing looks or tries to enforce any particular format for this tag, so
in reality it's just "whatever is people come up with".
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2064#issuecomment-1424141303
You are receiving this
(See the SPDX documentation for something similar)
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2064#issuecomment-1424092752
You are receiving this because you are subscribed to this thread.
Message ID:
Sorry for chiming in so late, but is this really `:`? e.g.
`git:git://foo.com/...`? Many other formats use `git+https://github.com` or
similar.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2064#issuecomment-1424089548
You are
@pmatilai pushed 4 commits.
0a05239923e031bc282962df1a94ca55d59489e2 Refactor dataLength() to return the
length through a pointer
65120b3d4621b655d6b0a7c90a08fe11413d10a8 Switch regionSwab() length return
type to unsigned, update callers
db590b36fbb652a591f26c55d2da2533b0d6d03b Refactor
> Static variables are best avoided, for one they wont work correctly for the
> case where you query/build multiple specs on a single run.
Argh... The multi-spec case somehow didn't occur to me... yet it's pretty
obvious :sweat_smile:
> A simple alternative would be adding a special purpose
Static variables are best avoided, for one they wont work correctly for the
case where you query/build multiple specs on a single run.
A simple alternative would be adding a special purpose counter to the spec
struct, and log a message based on that towards the end of parsePrep() where
you can
GH ticket, PR and discussions activity are gated to rpm-maint (eg start of this
thread is
[here](https://lists.rpm.org/pipermail/rpm-maint/2023-January/022891.html), and
AFAIK replying via email does work. We've no intention to have a separate
discussion on any mailing list, but those not
17 matches
Mail list logo
