Rpm scriptlets should have no business dealing with this level of detail in
process control, rpm.execut() is much saner and safer for scriptlet needs. We
cant just remove because this is a public API with known users (eg glibc
in Fedora), but we can at least document these as deprecated.
@pmatilai commented on this pull request.
> + return p->token;
+ }
+}
+return NULL;
+}
+
+static const int partBeforeBuildOnly(int part)
+{
+const struct PartRec *p;
+
+for (p = partList; p->token != NULL; p++) {
+ if (p->part == part) {
+ return
@ffesti commented on this pull request.
> + return p->token;
+ }
+}
+return NULL;
+}
+
+static const int partBeforeBuildOnly(int part)
+{
+const struct PartRec *p;
+
+for (p = partList; p->token != NULL; p++) {
+ if (p->part == part) {
+ return
Closed #2470 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2470#event-12028572241
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Closing in favor of #2949, seems fairly obvious this is the same issue.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2470#issuecomment-1980968956
You are receiving this because you are subscribed to this thread.
Message ID:
(updated the commit message to reflect error -> warning change)
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2940#issuecomment-1980694996
You are receiving this because you are subscribed to this thread.
Message ID:
@ffesti pushed 1 commit.
137a4353cf32f7a4d10d05d216dbd9392f84acc4 Don't allow build directives in
generated specs
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2917/files/8dcf8824b2e7c00097e28e7ac1d4e939e431a0ab..137a4353cf32f7a4d10d05d216dbd9392f84acc4
You are
@pmatilai approved this pull request.
I actually meant you could just as well inline the whole lookup in what you're
calling checkPart() since there are no other users for this in sight, but works
for me.
--
Reply to this email directly or view it on GitHub:
Oh, that sounds a whole lot like
https://github.com/rpm-software-management/rpm/issues/2470
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2949#issuecomment-1980957355
You are receiving this because you are subscribed to this thread.
And here goes: https://github.com/rpm-software-management/perl-rpm-packaging
The rest is up to the Perl community. If/when you need help with permission
matters, please file tickets in
https://github.com/rpm-software-management/org-admin .
--
Reply to this email directly or view it on
@ffesti commented on this pull request.
> @@ -1060,71 +1069,72 @@ typedef const struct PreambleRec_s {
int type;
int deprecated;
int ismacro;
+int beforebuildonly;
`prebuildonly` it is. Not that I am looking for any hills...
--
Reply to this email directly or view it on
@ffesti commented on this pull request.
> {0, 0, 0, 0}
};
/**
*/
static int findPreambleTag(rpmSpec spec,rpmTagVal * tag,
- const char ** macro, char * lang)
+ const char ** macro, char * lang, int * beforebuildonly)
Done. I looked at the same issue
We probably should also issue warnings on execution...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2948#issuecomment-1980752228
You are receiving this because you are subscribed to this thread.
Message ID:
These are far better maintained by the Perl community, in a repository of their
own:
https://github.com/rpm-software-management/perl-rpm-packaging
Fixes: #2873
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2947
--
For reference: https://bugzilla.suse.com/show_bug.cgi?id=1220213
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2949#issuecomment-1980932247
You are receiving this because you are subscribed to this thread.
Message ID:
How do you know if the package was built with an older rpm vs. the new rpm? If
you can ascertain that, then you can surely have the latest rpm complain/warn
if it finds an rpm built with the latest rpm that doesn't have the tags, while
older rpm would be blissfully unaware, happy, and able to
You probably already know this, but rpmbuild is killed by the write() system
that writes the filelist to the generator being done after the child has exited.
I think the only way to prevent this is to ignore SIGPIPE before calling
write(). Everything else like the select() thing we currently do
@pmatilai commented on this pull request.
> + return p->token;
+ }
+}
+return NULL;
+}
+
+static const int partBeforeBuildOnly(int part)
+{
+const struct PartRec *p;
+
+for (p = partList; p->token != NULL; p++) {
+ if (p->part == part) {
+ return
Oh and for whatever reason, there's some po/ submodule update in here:
> diff --git a/po b/po
index d5cc5d368e..eee506492f 16
--- a/po
+++ b/po
@@ -1 +1 @@
-Subproject commit d5cc5d368e2cbb639156b3f6ceb824a8815fdeba
+Subproject commit eee506492f5fe2f4fe8940c5e5b088b42167b790
(also visible in
@praiskup It is exactly the same problem. We will continue to have these issues
at the distribution level until we change the way we model how a package
exports an interface e.g. list of shared objects. There is perhaps a broader
question that this mistake would *not* have been caught without
@ffesti commented on this pull request.
> + return p->token;
+ }
+}
+return NULL;
+}
+
+static const int partBeforeBuildOnly(int part)
+{
+const struct PartRec *p;
+
+for (p = partList; p->token != NULL; p++) {
+ if (p->part == part) {
+ return
This is a bit of a corner case, but I just received a bug report that builds
sometimes terminate for a specific package. It turned out the package contained
this little gem:
```
%define __perllib_provides /bin/true
```
Anyway, I don't think rpm should be killed by this. Once upon a time
The flaky test-case is:
```cat << EOF > "${RPMTEST}"/tmp/bad.req
#!/bin/sh
echo 'bad = *'
EOF
chmod a+x "${RPMTEST}"/tmp/bad.req
runroot rpmbuild -bb --quiet \
--define "__script_requires /tmp/bad.req" \
/data/SPECS/shebang.spec
```
The common theme being a tiny
Agreed, especially with the [CI gating
part](https://matrix.to/#/!IHsypFkurbRbXzkjTO:matrix.org/$Jo1uzuG9SVrm__zmNvoYXXI2EarBYgIt-WdTu8TPBVg?via=fedora.im=matrix.org=fedoraproject.org).
--
Reply to this email directly or view it on GitHub:
Okay, this is not going to make it to 4.20. But, we need to start looking into
this soon - shortly after 4.20 is branched to not be in this same situation one
year from now.
--
Reply to this email directly or view it on GitHub:
Thinking some more on this, I believe the right thing here is treating regular
(as in not having (post/pre) type qualifiers) weak dependencies as implicit
"meta" dependencies, which is exactly how they are *normally* used (eg that
fwupd case).
For the rare case where packagers do want them to
We agree that at some point, it is good idea to forcefully remove some package
from a system. We know how to remove the package from the system, when it is
removed from repository using e.g.
[fedora-obsolete-packages](https://src.fedoraproject.org/rpms/fedora-obsolete-packages).
The method
> I don't think bumping the changelog for rebuilds is actually important, but I
> do think that this is still the wrong way to solve it, because we're
> presuming that _a rebuild is important_. When rebuilds happen every day for
> whatever reason due to dependency churn, they are no longer
Closed #2404 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2404#event-12024317033
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Resolved with #2921
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2404#issuecomment-1980336343
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint
Closed #2855 as completed via #2914.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2855#event-12025012740
You are receiving this because you are subscribed to this thread.
Message ID:
___
Merged #2914 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2914#event-12025012441
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
32 matches
Mail list logo
