Thanks for the fix!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2308#issuecomment-1331809694
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint
Merged #2308 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2308#event-7919726606
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
The first version of the `find-lang.sh` PR is now online: #2300
Feedback welcome!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2032#discussioncomment-4263807
You are receiving this because you are subscribed to this thread.
to match the new reality of cmake
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2303
-- Commit Summary --
* Remove build artifacts from .gitignore
* Add _build/ to .gitignore
-- File Changes --
M .gitignore (65)
Use the new dynamic spec feature to create language sub packages.
The is more of a RFC as there are a few things that need more polishing. The
code for getting the language description is a bit ad-hoc and may need to
switch to another entry in `locale` data. Suggestions welcome.
The package
Could not quite bring myself to just say no.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2249#issuecomment-1327216695
You are receiving this because you are subscribed to this thread.
Message ID:
Merged #2249 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2249#event-7891355010
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Merged #2292 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2292#event-7891320781
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Closed #2288 as completed via #2292.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2288#event-7891320894
You are receiving this because you are subscribed to this thread.
Message ID:
___
Closed #2286 as completed via #2287.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2286#event-7890654619
You are receiving this because you are subscribed to this thread.
Message ID:
___
Merged #2287 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2287#event-7890654539
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
You can't reference some local files in the commit message ([fix file leak when
install src rpm which is
URL](https://github.com/rpm-software-management/rpm/pull/2289/commits/3938cefacedbfd1ae40ff356c9d8d43e173da902)).
You need to include the content if it is appropriate. Or describe the issue.
Closed #1532.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1532#event-7866567762
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
This doesn't seem to go anywhere. So I am closing this PR here. Feel free to
re-open or may be open a new one. The discussion is becoming a bit unwieldy.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1532#issuecomment-1323478239
You
Merged #2279 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2279#event-7842521899
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
It's not a great example. But all we have for now.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2280#issuecomment-1319817181
You are receiving this because you are subscribed to this thread.
Message ID:
Merged #2280 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2280#event-7842406498
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Commit message should probably give a bit more background. It should mention
the ticket it fixes but not rely on the information in the ticket still being
available.
--
Reply to this email directly or view it on GitHub:
Added test case and mered the first two patches.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2271#issuecomment-1317320343
You are receiving this because you are subscribed to this thread.
Message ID:
@ffesti pushed 1 commit.
95b14d38a131a42ef637f387b9d2fc0cf5ffe674 Fix previous patch
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2271/files/837f8cc116043a4386cd17ad4faa207272d7296a..95b14d38a131a42ef637f387b9d2fc0cf5ffe674
You are receiving this because you are
OK; after looking at the failing test case it's a bit more obvious that we need
to treat the dependency check and the %generatebuilddependency script
differently. While the forme needs to move to the case 'p'(rep) block the later
needs to stay where it is at it is not needed for %prep at all.
There are two different things to consider: When are BuildRequires checks done
during the build process and whether to do it depending on what
stage/subcommand are executed. Looking at
https://github.com/rpm-software-management/rpm/blob/master/build/build.c#L379
and
I will update the top post as a design document and add your answers and
suggestions so they don't get lost in the discussion below. So the first
questions to every one is:
How does your distribution handle user and group creation? What features would
you hope for and what issues solved? I am
Currently the creation of users and groups are left to the packagers and is
though done differently between different distribution and as %pre scriptlets.
This has several drawbacks:
* It is not known which packages create which users
* Packages may ship files with users/groups that don't exist
Merged #2218 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2218#event-7803500644
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
OK, #1485 is finally merged. This is the minimally useful step. I'll resubmit
the patch to `find-lang.sh` that uses this to create language sub-packages as a
use/show case.
Still the current state is limited to complete sub packages and can't really
interact with the content of the spec file.
Rebased on top of #2270 and squashed latest fixes.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1485#issuecomment-1308683146
You are receiving this because you are subscribed to this thread.
Message ID:
@ffesti pushed 3 commits.
a1056d0b1487ee921db9de8d53bf693976e1f0b5 Split actual parsing of spec into its
own function
a2592627c300ddbe9af1632d0681391567213791 Allow starting new spec parts with
PART_EMPTY
26de93c844ee13d456542e867cf35a60e574c90b Add Dynamic Spec generation
--
View it on
Merged #2270 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2270#event-7772829149
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
@ffesti pushed 1 commit.
5b4d7065b2f720dd098db92234f496ae59a03882 Dynamic Specs: Add order of specparts
reading
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1485/files/a2ec843b8dbc11ece43f057092b0f768931c933c..5b4d7065b2f720dd098db92234f496ae59a03882
You are
Added alternative error handling. Turns out to be less of a change than I
expected. So it's probably just the way to go.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1485#issuecomment-1307049064
You are receiving this because you are
@ffesti pushed 1 commit.
a2ec843b8dbc11ece43f057092b0f768931c933c Move rpmSpecFree out of
parseSpecSection
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1485/files/a07501c24c391ed091f72c2933f259bb617c6185..a2ec843b8dbc11ece43f057092b0f768931c933c
You are receiving
@ffesti commented on this pull request.
> + if (checkForEncoding(pkg->header, 0) != RPMRC_OK) {
+ badenc = 1;
+ }
+ }
+ if (badenc)
+ goto errxit;
+}
+
+closeSpec(spec);
+
+exit:
+return spec;
+
+errxit:
+if (!secondary)
+
@ffesti commented on this pull request.
> + if (checkForEncoding(pkg->header, 0) != RPMRC_OK) {
+ badenc = 1;
+ }
+ }
+ if (badenc)
+ goto errxit;
+}
+
+closeSpec(spec);
+
+exit:
+return spec;
+
+errxit:
+if (!secondary)
+
- Removed u2p macro
- Added _prefix to test case
- Removed unnneccessary rpmSpecFree call
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1485#issuecomment-1306984561
You are receiving this because you are subscribed to this thread.
@ffesti commented on this pull request.
> +
+runroot rpmbuild -ba /data/SPECS/dynamic.spec
+],
+[0],
+[ignore],
+[ignore])
+
+AT_CHECK([
+
+runroot rpm -qp --qf "%{Summary}\n"
/build/RPMS/noarch/dynamic-docs-1.0-1.noarch.rpm
+runroot rpm -ql /build/RPMS/noarch/dynamic-docs-1.0-1.noarch.rpm
+],
@ffesti commented on this pull request.
> @@ -715,7 +715,8 @@ package or when debugging this package.\
RPM_ARCH=\"%{_arch}\"\
RPM_OS=\"%{_os}\"\
RPM_BUILD_NCPUS=\"%{_smp_build_ncpus}\"\
- export RPM_SOURCE_DIR RPM_BUILD_DIR RPM_OPT_FLAGS RPM_ARCH RPM_OS
RPM_BUILD_NCPUS\
+
@ffesti pushed 3 commits.
825d644e5654c1898849c54eb2b7327a9044f7da Split actual parsing of spec into its
own function
a3f967656ccdec466653a12301c7449f9f746975 Allow starting new spec parts with
PART_EMPTY
a07501c24c391ed091f72c2933f259bb617c6185 Add Dynamic Spec generation
--
View it on
OK, addressed all the comments above except the issue with the signature of
`parseSpecSection()` where I not quite see what a better solution would be.
Fixed for now:
- Reworded documentation
- Merged spec files for test cases
- Failing test case checks rpmbuild output
- removed spurious u2p
@ffesti commented on this pull request.
> + if (checkForEncoding(pkg->header, 0) != RPMRC_OK) {
+ badenc = 1;
+ }
+ }
+ if (badenc)
+ goto errxit;
+}
+
+closeSpec(spec);
+
+exit:
+return spec;
+
+errxit:
+if (!secondary)
+
@ffesti commented on this pull request.
> @@ -273,6 +273,15 @@ static int doSetupMacro(rpmSpec spec, const char *line)
free(buf);
}
+/* mkdir for dynamic specparts */
+buf = rpmExpand("%{__mkdir} SPECPARTS", NULL);
+appendBuf(spec, buf, 1);
+free(buf);
+
+buf
@ffesti commented on this pull request.
> +layout: default
+title: rpm.org - Package Build Process
+---
+# Dynamic Spec Generation
+
+Since rpm 4.19 RPM supports parsing dynamically generated specs. This
+allows the build scripts (**%build** or **%install**) to create parts
+of the spec file.
@ffesti commented on this pull request.
> +%description
+Simple rpm demonstration.
+
+%prep
+%setup -q -T -c
+
+%build
+echo "Q: Why?\nA: Because we can!" > FAQ
+
+%install
+mkdir -p $RPM_BUILD_ROOT/usr/local/bin
+echo " " > $RPM_BUILD_ROOT/usr/local/bin/hello
+
+
+echo "%package docs" >>
@ffesti commented on this pull request.
> @@ -273,6 +273,15 @@ static int doSetupMacro(rpmSpec spec, const char *line)
free(buf);
}
+/* mkdir for dynamic specparts */
+buf = rpmExpand("%{__mkdir} SPECPARTS", NULL);
+appendBuf(spec, buf, 1);
+free(buf);
+
+buf
@ffesti commented on this pull request.
> +
+%prep
+%setup -q -T -c
+
+%build
+echo "Q: Why?\nA: Because we can!" > FAQ
+
+%install
+mkdir -p $RPM_BUILD_ROOT/usr/local/bin
+echo " " > $RPM_BUILD_ROOT/usr/local/bin/hello
+
+
+echo "%package docs" >> %{specpartsdir}/docs.specpart
+echo "Summary:
@ffesti commented on this pull request.
> @@ -2272,3 +2272,44 @@ runroot rpmbuild \
],
[ignore])
AT_CLEANUP
+
+# --
+# Check if dynamic spec generation works
+AT_SETUP([rpmbuild with dynamic spec generation])
+AT_KEYWORDS([build])
+RPMDB_INIT
+AT_CHECK([
+
@ffesti pushed 1 commit.
387da564de03e2c12200d09abf746690b103af86 Add Dynamic Spec generation
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1485/files/ab78270fca71149a42fdead2b8dd14a0f2d0898c..387da564de03e2c12200d09abf746690b103af86
You are receiving this because
@ffesti commented on this pull request.
> @@ -1129,3 +1157,26 @@ rpmSpec rpmSpecParse(const char *specFile,
> rpmSpecFlags flags,
{
return parseSpec(specFile, flags, buildRoot, 0);
}
+
+rpmRC parseGeneratedSpecs(rpmSpec spec)
+{
+ARGV_t argv = NULL;
+int argc = 0;
+int i;
+
OK, fixed the error handling and added a failing test case.
Added $RPM_SPECPARTS_DIR to the build scripts and removed the true directory
name from the docs.
Turns out there is a reason that `parseSpecSection()` returns a `Spec` object:
The BUILDARCHITECTURES magic may return a different Spec
@ffesti pushed 3 commits.
a63662e1558a086a850a2da382bd7c5759a1d7ca Split actual parsing of spec into its
own function
05e784b9b576aefd88522c88ab06133048c7904d Allow starting new spec parts with
PART_EMPTY
ab78270fca71149a42fdead2b8dd14a0f2d0898c Add Dynamic Spec generation
--
View it on
There are a few reasons why this is not wired into `%include`. The first being
that `%include` includes a file in place and then continues to read, expand and
parse the rest of the file. This is something that just cannot be done
afterwards. All kind of things could change by re-parsing the
- Rebased
- Added `specpartsdir` macro
- Changed name of dir to `SPECPARTS`
- Fixed white space issues
- Use noarch package in test case
- Merged patches
Final patch might still deserve a bit longer commit message. Otoh there is docs
on this and there is no need to duplicated that in the patch.
@ffesti pushed 1 commit.
06c764a2625fe2daea62598075bac2d10fc42317 Read in spec pieces generated during
builds
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1485/files/7e43a675d518fbe41fab8c456cb73d26a95c8af3..06c764a2625fe2daea62598075bac2d10fc42317
You are
@ffesti pushed 3 commits.
ae3a952f96aa84c7eed1cd10ee86d56017a8968b Split actual parsing of spec into its
own function
28834422d628f5ad7381d18bdbb13e91dc3fc223 Allow starting new spec parts with
PART_EMPTY
7e43a675d518fbe41fab8c456cb73d26a95c8af3 Read in spec pieces generated during
builds
> > The patch now uses a SPECS sub dir in the buildsubdir
>
> Names are hard, but this directory is nothing at all like SPECS in
> %{_topdir}, I don't think it should share that name. SPEC, maybe. Except, I
> think we may want to use such a directory for other purposes too, which is
> why the
@ffesti commented on this pull request.
> @@ -138,8 +138,14 @@ in the RPM sources.
## Payload
-The Payload is currently a gzipped cpio archive. The cpio
-archive type used is SVR4 with a CRC checksum.
+The Payload is currently a cpio archive, gzipped by default. The cpio archive
+type
OK, added test case and some docs.
In addition I stripped the find-lang patch as this needs to g into it's own PR
and was only there as a demonstration piece.
The patch now uses a `SPECS` sub dir in the `buildsubdir` to allow detecting
whether the feature is supported.
I also removed the code to
@ffesti pushed 5 commits.
4320abf21b4d228b446fb679f0fa2e9f992e5985 Split actual parsing of the spec into
its own function
d8f830518e70e1bae31fab10c75720185446c5ba Allow starting new spec parts with
PART_EMPTY
29708e32c8e2fb9f2b758d97fda24f23e1506ca6 Read in spec pieces generated during
These look like they were different blocks needed at different places at some
point. But I fail to see why this split is still necessary.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2243
-- Commit Summary --
* Remove
While the payload is compressed the header is not. This is wasting time and IO
whenever a header is loaded - be it form a package or the RPM BD.
For the v6 format we need to examine if compressing the headers yields enough
benefits to justify this change.
--
Reply to this email directly or
Yes, but creating them from C seems like a step in the wrong direction
especially when hard coding the details like Summary and Description.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2204#issuecomment-1262397566
You are receiving
Well, guess the easiest way to do this is to get #1485 merged and use that. All
it takes it looking at the results of the `find_debuginfo` run and write
`%{_debuginfo_template}` and `%{_debugsource_template}` into a file. That's
kinda what it was designed for...
--
Reply to this email
For now build root policy scripts are just shipped in the
[scripts/](https://github.com/rpm-software-management/rpm/tree/master/scripts)
and it is left to the distributions to run them in ` %__os_install_post`
([Fedora as an
Yeah, but that is the hard part - especially if we want to keep the debuginfo
packages as a macro template. Ofc we could just create those packages in C. But
parsing the template macros after build would be closer to the current
implementation. With the current parser this is a hard ting to do.
OK, I guess I start with writing down how debuginfo works right now:
There are quite a few macros that
[control](https://github.com/rpm-software-management/rpm/blob/master/macros.in#L452)
and
[implement](https://github.com/rpm-software-management/rpm/blob/master/macros.in#L135)
the debuginfo
The issue here is that we actually want some macros in the SPEC file. I wonder
if we could just add `%__spec_pre` and `%__spec_post` macros that are expanded
at the beginning and the end of the spec file. We have something similar for
the build scripts already. This would give rpm itself but
Well, `%install` following the preamble is technically a different issue.
`%prep` is setting `%buildsubdir` via `%setup` and everything that makes use of
that needs to be after `%prep`. This is not limited to the debuginfo magic -
although it is especially non-obvious there.
--
Reply to this
It closes a section. So it would end the `%prep` section. Idea is that the
debuginfo magic wold then be evaluated after the `prep` section. Basically the
same as if there was another section inbetween.
--
Reply to this email directly or view it on GitHub:
I wonder if adding `%end` to the `%install` macro fixes the issue. The `%end`
would be useful for once...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1870#issuecomment-1258384207
You are receiving this because you are subscribed to
%prep is very special. It is first parsed completely and only then are `%setup`
and `%patch` replaced. While these two need to do special things they should
still be internal macros that are processed right when they are encountered.
One side effect of this is #1870
--
Reply to this email
OK, I think I have an idea what's wrong here:
If `%install` is encountered after/as part of `%prep` debuginfo does not work.
The reason is that `%prep` is first parsed and `%setup` - which is setting
`%buildsubdir` - is only executed after the whole `%prep` section is processed
and all macros
Merged #2177 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2177#event-7457689352
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Closed #2119 as completed via #2177.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2119#event-7457689454
You are receiving this because you are subscribed to this thread.
Message ID:
___
Well, those switches are basically for disabling a single, problematic
scriptlet. Yes, it is not likely that you want to disable preuntrans and not a
postuntrans - simply because they will still be very rare. But the semantics
here is that you can at least target a specific type and mixing
But it looks so nice and sane...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2201#issuecomment-1254855652
You are receiving this because you are subscribed to this thread.
Message ID: ___
OK, finally looking at the proper diff between my and your version:
`pkgGoalString` is missing entries for `PKG_PREUNTRANS` and `PKG_POSTUNTRANS`
The other differences are due to different naming, you not adding `RPMSENSE_`
flags and my patch being incomplete.
Missing `RPMSENSE_` flags means
The discussion here is beside the point of the PR. This is in large parts my
fault as the original patch also was beside the point. As it turns out this is
unrelated to v4 OpenPGP signatures and their use of SHA-1.
The current patch only returns the error of not supported older SHA-1 based
Yeah, that was something I was not really happy with. Saving those precious
bits is surly the better way to do it. It also reduces the places that need
touching.
--
Reply to this email directly or view it on GitHub:
Comparing this to
https://github.com/ffesti/rpm/commit/4930200d5de32a7c7f68be2f6c09e3451c80bf95#diff-0abd926819b4533c0286c8e9c82a3f8e4893bb9b8f81024e921d1b0309a909c2
I wonder why you don't need the changes to `processScriptFiles` in
It's quite possible that this is a bug. Can you still please verify that these
files are not owned by another package by running `rpm -qf /usr/bin/strip`?
Thanks!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@ffesti commented on this pull request.
> @@ -19,6 +19,7 @@
#undef HTDATATYPE
#define ALLOWED_CHARS_NAME ".-_+%{}"
+#define ALLOWED_FIRSTCHARS_NAME "_%{}"
OK, so this is not by accident but to not blow up for unexpanded macros that
may just not be available at that point in time.
--
@ffesti pushed 1 commit.
a5e67695d970c964089470001f7fad1d99354fac Require package names to be valid
provides
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@ffesti pushed 1 commit.
2019abae2439c5d3d4e250098b093e648a1f72d7 Require package names to be valid
provides
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@ffesti commented on this pull request.
> @@ -19,6 +19,7 @@
#undef HTDATATYPE
#define ALLOWED_CHARS_NAME ".-_+%{}"
+#define ALLOWED_FIRSTCHARS_NAME "_%{}"
Ok, after reading `rpmCharCheck()` 3 more times: Looks like `%{}`are actually
legal in dependency names and only create a warning. So
@ffesti pushed 1 commit.
c1d631c94bf078936fcfe07b136344f924a112cd Require package names to be valid
provides
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
Merged #1793 into master.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1793#event-5434455706___
Rpm-maint mailing list
It won't solve the issue though, as the group still doesn't exist when the
files are created. Guess something like `echo "shadow:x:404:" >> /etc/group` in
%pre might do the trick.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
Oh, right. The patch does only move the `rpmugInit` call to later. I first
thought it now does that whenever entering the chroot and was wondering why the
commit message is more vocal about that.
I still have this vivid memory of rpm no longer using the the files from
outside the chroot. But I
This is caused by RPM no longer using the user and group information from out
side of the change root. Earlier versions were not properly using the inside
files in all cases.
The uid and gid of these files are set before they are moved in place. So the
shadow group does not exist yet. While
Skipping over `"\ "` and `"\^t"` in `splitQuoted()` makes `%autosetup -n auto\
foo` work. Still need to figure out what this all breaks. It is also not
compatible with `shescape` which uses single quotes.
--
You are receiving this because you are subscribed to this thread.
Reply to this email
OK, to be more clear with this: We currently don't have any (working) means to
have spaces in macro parameters (with the exception of built-in macros which
are different in all kind of wonderful ways).
I wonder if we actually need two ways for doing that. One that is stripped
during parsing
Ok, more thorough investigation turns up a few more problems than expected:
- Macro parameters are split by ` splitQuoted()`
https://github.com/rpm-software-management/rpm/blob/master/rpmio/macro.c#L930
- It uses Unit Separator (ASCII 0x1f) as separator and ignores quotes
- Non UTF-8 characters
Closed #1782 via #1784.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1782#event-5372460130___
Rpm-maint mailing list
Merged #1784 into master.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1784#event-5372460114___
Rpm-maint mailing list
Yeah, not beautiful but just good enough for now.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1784#issuecomment-929018182___
Closed #1765 via ee5d150aea19ebd10569cd805917acc583719e49.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Merged #1780 into master.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1780#event-5372346573___
Rpm-maint mailing list
I talked to mjw about this. eu-strip would probably be able to strip even these
Guile files. I don't really know whether they should be stripped or not,
though. Excluding the Golang (source) files should really not matter but this
is to be on the save side.
And yes this whole brp business
Merged #1783 into master.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1783#event-5355924327___
Rpm-maint mailing list
I'll adjust this to use the new macro as soon as it is upstream.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
401 - 500 of 1513 matches
Mail list logo
