I'm not surprised by yum segfaulting, separate python interpreters outside of
rpm running in the same address space isn't really a scenario taken into
consideration so far..
As only usage within macros has really been supported and seen real world usage
so far, getting scriptlet support in
As it's fairly common to generate changelog from version control system,
maintaining it entirel outside of spec file, it makes sense to support
loading the changelog entries from separate files generated rather than
requiring it to be merged with spec file.
You can view, comment on, or merge this
This last one I'm everything but proud of, it simply generates a temporary spec
file with %changelog from file appended to...
It should work satisfactory and all, but uhm... yeah..
---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
Hm, there's several asserts in place throughout source code that would be bad
to compile with -DNDEBUG as the desired and safe behaviour expected for assert
is to abort if expession evaluated is false...
Of course one could replace the assert(3) with:
if(--mt_options.threads == 0)
abort();
for the following example:
%changelog
%include changelog.txt
You would also have to add changelog.txt as a source file as well.
So that would require adding 'Source123: changelog.txt' as well to spec file.
I think having a default filename for external changelog and to include it in
src.rpm
I'm questioning the usefulness of using a different file name..
---
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/69#issuecomment-224793129___
sorry for slooow response, but rebased now :)
---
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/17#issuecomment-222306973___
Rpm-maint mailing list
2017-01-26 15:28 GMT+01:00 Florian Festi :
> While I have some sympathy for the idea as such I think just putting
> random stuff in a tags is a bad idea. We should at least force some
> key:value structure. This way someone parsing the tags has a fair chance of
>
Actually, we ended up solving this different in cooker, where in stead of
patching rpm for support, but rather by adding support for %{_specfile}, we
got the patch numbers differently:
%apply_patches %{lua:\
f = io.open(rpm.expand("%{_specfile}"))\
if f then\
for l in f:lines() do\
For the rpath & pkgconfig, they've been well tested and various breakages in
*cooker has all been fixed with all issues encountered having been properly
fixed without any issues being reported for some years now. :)
And considering that you suggest that they should rather be explicily enabled
proyvind commented on this pull request.
> @@ -0,0 +1,49 @@
+#!/bin/sh
+
+# This script makes sure to remove any standard library search paths from rpath
+# or runpath tags as they're not only redundant, but will break overriding
+# search paths. Search paths of the tag that's not stand
could you describe a scenario where any of these brp-scripts wouldn't be
desired to have enabled by default?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@proyvind pushed 6 commits.
5b75e58 unconditionally build embedded python interpreter with bindings
9abdb24 really drop conditionals in python extension
f2f6f7a ensure symbols aren't looked up in existing namespace if not found
cb2b380 do operations for rpmpython interpreter condtional
@proyvind pushed 1 commit.
85ecc46 Merge branch 'master' of github.com:rpm-software-management/rpm into
pythonembed2
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/96/files
ended up becoming quite a few commits and messing around after all, but I think
I'm about where I start feel satisfied with how implemented at least.
So if reviewed again now and found acceptable, I'll clean up the pull request.
:)
--
You are receiving this because you are subscribed to this
Done, this should hopefully suffice. :)
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/17#issuecomment-245781671___
Rpm-maint mailing list
@proyvind pushed 3 commits.
30fced1 move rpmpython.h to more appropriate location
c19a989 rpmpython: comment out code if not enabled
fb90536 fix conditionally disabling of rpmpython code in python bindings as
well
--
You are receiving this because you are subscribed to this thread.
View
@proyvind pushed 1 commit.
24b0963 rename 'rpmpython' variable back to 'librpmpython'
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/96/files/fb9053698425a8ff5c86e3f5d402d779fd590856
Maintenance of multiple meta tags for packages outside of packages, replacing
optional group tag isn't ideal wrt. package maintenance scaling..
In stead a MetaTags: tag has been added, accepting multiple tag words.
This seems like a far more ideal solution than what's currently implemented
@proyvind pushed 1 commit.
8d0a541 update tests with METATAGS added to queryformat test
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/107/files/7b838c4eb22c5df3b9a0c308cbe311d8764118c0
@proyvind pushed 1 commit.
cfe0869 MetaTags: should be translatable
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/107/files/8d0a541248e136b1ebcdec93ae4a2d5b9924882d
Closed #105.
--
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/105#event-884568493___
Rpm-maint mailing list
This bug made me really puzzled and I don't wanna dig further around to
try wrap my head around to confirm that this fix is actually the right
one, nor if I even understand the problem or not.
I encountered it repeatedly right away, when installing a mageia
installation from rpm5 based omv-cooker
printing an error message about this in stead of silently ignore and hope for
the best probably won't hurt.
It anyways reports about the issue, while gracefully handling it by skipping
file action decision for the files printed
--
You are receiving this because you are subscribed to this
backup files included in packages are nothing but a result of faulty packaging,
where disablingdefault non-intrusive functionality of use are clearly not the
right solution and really should be considered flawed packaging practices and
workarounds rather than correctly addressing and fixing the
Taking a closer look at the mageia bug, I notice that the backup files lacks
the '~' backup suffix, for which I'd consider this rather a mageia specific
shortcoming in their %apply_patches implementation, cooker's not affected by..
The only scare thing about mageia's past use of %apply_patches
Skimming through your link to suse's patterns, it's hard to easily grasp it's
purpose, while if serving the same purpose, the implementation of is not only
extremely confusing, hard to maintain and extremely non-standard fashion,
rather than implemented in rpm itself in a proper, intuitively
proyvind commented on this pull request.
> @@ -0,0 +1,14 @@
+#!/bin/sh
+
+# If using normal root, avoid changing anything.
+if [ -z "$RPM_BUILD_ROOT" -o "$RPM_BUILD_ROOT" = "/" ]; then
+ exit 0
+fi
+
+find "$RPM_BUILD_ROOT" \( -type f -o -type l
proyvind commented on this pull request.
> @@ -0,0 +1,14 @@
+#!/bin/sh
+
+# If using normal root, avoid changing anything.
+if [ -z "$RPM_BUILD_ROOT" -o "$RPM_BUILD_ROOT" = "/" ]; then
+ exit 0
+fi
+
+find "$RPM_BUILD_ROOT" \( -type f -o -type l
proyvind commented on this pull request.
> @@ -0,0 +1,49 @@
+#!/bin/sh
+
+# This script makes sure to remove any standard library search paths from rpath
+# or runpath tags as they're not only redundant, but will break overriding
+# search paths. Search paths of the tag that's not stand
As the multithreaded (de)compression support for pigz isn't implemented in the
binary, the benefits from aren't really there as it won't be possible to
implement multithreaded (de)compression for using in the rpmio library.
Same goes for pbzip2.
For xz, multithreaded compression support has
I've added most of the helper scripts, there's a few remaining and some I'll
have to consider whether to kill off in stead before done.
Anyways, I'm making a preliminary pull request as a request for comments.
Notice how all these scripts can either be disabled by setting an environment
proyvind commented on this pull request.
> @@ -0,0 +1,15 @@
+#!/bin/sh
+
+# If using normal root, avoid changing anything.
+if [ -z "$RPM_BUILD_ROOT" -o "$RPM_BUILD_ROOT" = "/" ]; then
+ exit 0
+fi
+
+INFODIR=`rpm --eval %{_infodir}/dir`
+
+dir="$RP
@proyvind pushed 1 commit.
a469648 add brp script for automatically creating library symlinks using
ldconfig
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/122/files
@proyvind pushed 1 commit.
0d496d8 add brp script to check elf files for unresolved symbols and unused
libs
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/122/files
@proyvind pushed 1 commit.
12e9521 add disabler for brp-compress
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/122/files/0d496d8a6469a13a96d8143c6096405b18d7a0fd
@proyvind pushed 1 commit.
fc8a8ad add run time package generator for use with embedded python
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/96/files/24b0963b66741dfda20adad27616920f865cdfc9
@soig you're making a good point, if one wanna look at truly stupid mechanisms,
one should look at how the internal dependency generator is doing the same work
over and over and over.. It's now become what takes up the most time of build
for certain packages..
In contrast, running 'find' over
This simply does the same thing as 'rpmspec -P' does.
parsedspec = rpm.spec("foo.spec).parsed
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/186
-- Commit Summary --
* add a spec.parsed setter for retrieving parsed spec
I dropped the redundant --target from rpmbuild as well, leaving for you to see
fit whether merge that one or not. ;)
RE: "add back", I seem to have made false assumptions related to global
--target having been in place @rpm5.org since forever, so I mistakenly figured
that it preceded the 4.4.2
@proyvind pushed 1 commit.
73a6443 drop redundant --target option for rpmbuild as well
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/142/files/5df4453619f70a620120a1e51e381e249a66ecd0
Trivial fixes to silence compile warnings..
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/191
-- Commit Summary --
* fix comparison between signed and unsigned integer expressions
* fix implicit declarations of lua
@proyvind pushed 1 commit.
2e190d5 move handle out out of rpminterp API
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/190/files/49f8f80ae6427bc648e040a41b73f0eabb3bb9e0
@proyvind pushed 1 commit.
fa515fc dlopen with RTLD_DEEPBIND
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/190/files/de807fa860a667ee1e09b1bcf97a2a555a76a1fd..fa515fcd83b2c8cbe1399b55b1b8fd00f060fa00
@proyvind pushed 1 commit.
de807fa drop md5 digest from download url
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/190/files/8215b221dd5508ef58c86b34966c4f5e1bb06203
@proyvind pushed 5 commits.
da5ac98 move 'extern "C"' to top of file
e1a6125 use flexible array member for rpminterp->name
b94a62c fix enum
0cad264 add api doc for rpminterpLoad()
8215b22 revert variable array member change as it breaks C++ compatibility
--
You are receiving
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/202
-- Commit Summary --
* set a %_specfile macro during build, holding full path to spec file
-- File Changes --
M build/parseSpec.c (1)
-- Patch Links --
@proyvind pushed 2 commits.
3750cb5 add md5 verification to pyspec()
dd27e48 really default to automatic archive selection for pyspec()
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/190/files
@proyvind pushed 1 commit.
49f8f80 work around python setuptools not supporting unlimited jobs in pyspec()
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/190/files
@proyvind pushed 1 commit.
03755b5 automatically pick latest version and preferred file format for
pyspec()
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/190/files
Here's #256 turned into a PR, it depends on #282
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/283
-- Commit Summary --
* add RPM_CHECK_LIB m4 macro
* add zstd compression support
-- File Changes --
M
Here's #257 made into a PR
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/282
-- Commit Summary --
* add RPM_CHECK_LIB m4 macro
-- File Changes --
A m4/acinclude.m4 (537)
A m4/rpm_check_lib.m4 (494)
-- Patch
GitHub feature request: Ignore PRs
...
--
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/122#issuecomment-318138422___
Rpm-maint
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/207
-- Commit Summary --
* dbus_connection_unref(bus) after dbus_connection_close(bus)
-- File Changes --
M plugins/systemd_inhibit.c (4)
-- Patch Links --
proyvind commented on this pull request.
That oughta suffice, no? :)
--
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/207#pullrequestreview
https://github.com/proyvind/rpm/blob/pyspec/python/rpm/generate.py
I'm using it in the python module spec generator (dependent on rpminterp PR,
pyspec branch depends on _specfile which is why a new branch were created),
where the python script reads the spec file to determine what sections etc
proyvind commented on this pull request.
> @@ -0,0 +1,17 @@
+#!/bin/sh
+# Fix .desktop files to be compliant with XDG specification
Why? .desktop files issuee corrected by this script is quite widespread and
goes often unnoticed.
Trivial to automatically fix with script, tedious to manua
No idea what you mean by prefering users explicitly doing the right thing..
Trying to interpret it, it seems to contradict the purpose of these scripts in
general, avoiding users having to explicitly take care of things that can be
safely automized and handled automatically outside of spec
brp-clean-files is convenient as it'll simply make sure that files which surely
has no place in builldroot are removed and accidental packaging of is prevented.
The script is extremely simple and the most trivial one in this PR, so I fail
to see your concern about it might break something.
--
why remove attribution from commit message?
--
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/234#issuecomment-318933780___
For the package exceptions requiring the libtool .la files, you have a disabler
macro.
That's the whole point of the disabler macros in general, while enabling the
scripts are desired in most cases, thus enabled by default, there always might
be exceptions where not desired and for those you
This PR is now four months old, where not a single comment on it has been made.
The implementation is completely unintrusive and at possibility to even create
regressions, yet not a single feedback..?
What gives?
In contrast to the preceeding rpmpython PR, this one has addresses all issues
proyvind commented on this pull request.
This should be sufficient for approval, no? :)
--
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/235#pullrequestreview
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/304
-- Commit Summary --
* add support for premacros.d, complimenting --predefine
-- File Changes --
M lib/rpmrc.c (17)
-- Patch Links --
@proyvind pushed 227 commits.
6b6b507 Drop dead-on-arrival untrustedkeys formatting from signature checking
886c417 Add a test for non-verbose signature check output
7de6172 Drop missing key formatting from non-verbose signature checking output
7488d88 Drop the ambiguous and bogus RSA/DSA
rebased..
--
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/190#issuecomment-323117737___
Rpm-maint mailing list
This makes no sense, /usr/bin/python is usually the linked to the binary of the
default python version in use on distros, so hardcoding the version makes no
sense.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I went with bash as interpreter;)
--
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/235#issuecomment-310149625___
Rpm-maint
then you don't seem to figure out what I'm trying to describe my needs for.
What I demonstated was how through the embedding of python interpreter through
the rpminterp PR, a complete and automatically self-maintained spec file for
python packages from a single line calling a python function
considering that the brp scripts is amongst the most important PR improving
packaging life in ages, it starts to reflect poorly of not just not giving it
priority, but actually just simply ignoring it for several months now.
last brp script with purpose not reflected by file name has been fixed
ntly in place, if you dispute this, you can't possibly
haved bothered trying to understand the matter, relationship with rpminterp
#190, pyspec (https://github.com/proyvind/rpm/tree/pyspec) and the huge
benefits to packagers.
rpminterp (which I still haven't received a comment on) & this PR op
proyvind commented on this pull request.
> @@ -237,6 +237,89 @@ const char * rpmlogLevelPrefix(rpmlogLvl pri)
return prefix;
}
+static const char * rpmlogLevelColor(rpmlogLvl pri)
+{
+return rpmlogMsgPrefixColor[pri&0x7];
+}
+
+static int rpmlogDefault(FILE *stdlog, rpmlog
ah, you were right about the missing brp-fix-pkgconfig script though, I'll
rather fix it in the original PR
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
disable_fix_foo are poor grammar, and not only 'disable' found to be consitent
with was %_disable_source_fetch..
why changing "wuzz out" to "quit" in comment? in order to not offend some
unlikely person, or just plain political correctness (not really mutually
exclusive)?
For pkgconfig, I
splitting the brp-check-elf-files script however, thx, I was planning on it ;)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I never really entirely understood what you meant by key:value, could you
provide an example? :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
which I discovered that was me who had done.. :p
my local branch on current workstation wasn't updated.. ;)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
proyvind commented on this pull request.
> @@ -237,6 +237,89 @@ const char * rpmlogLevelPrefix(rpmlogLvl pri)
return prefix;
}
+static const char * rpmlogLevelColor(rpmlogLvl pri)
+{
+return rpmlogMsgPrefixColor[pri&0x7];
+}
+
+static int rpmlogDefault(FILE *stdlog, rpmlog
I'd say "wuzz out" is clear enough, while also more suggestive ;)
for pkgconfig files, this isn't really just a pure upstream problem, the foo.pc
file is usually generated from ie. flags passed to configure..
And wrt. masking problems, a lot of the brp scripts simply fixes stuff easy to
detect
proyvind commented on this pull request.
> @@ -14,6 +14,8 @@
#include
#include
+#include/* NSPR thread pools */
openmp, unless for some reason would turn out to be unfeasiable, would be the
definitive candidate IMO given it's standardization and implementat
Here's a pull request of what posted by @n3npq Jeff in #198.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/225
-- Commit Summary --
* Colorized rpmlog() output (jbj, #198)
-- File Changes --
M rpmio/rpmlog.c (148)
Best way would be to simply create a pull request from a finalized branch of
yours (without unecessary amounts of WIP commits) pushed to a forked rpm repo
of yours.
Then it would make sense to rather continue discuss the subject and also the
implementation of.
Regardless of upstream
cool!
I'll try get around reviewing it myself at least when I find the time, then
provide feedback and/or my approval of (FWIW). :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@proyvind pushed 1 commit.
667aaf0 WIP: copyright notices in progress
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/122/files/82133413c0b2d416d3eb6b15518e964b659e2575
@proyvind pushed 1 commit.
41c7de8 finish WIP adding copyright notices to scripts
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/122/files/667aaf07d1cd3d0ab414fc05e742675a7f2df2b8
@proyvind pushed 1 commit.
cedff9a add parallel brp-* script support using GNU parallel
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/122/files/ed06b4f286c24f6c1fc36e9e282a46807e27927a
Shrinks body by removing all leading and trailing whitespaces and
reducing intermediate whitespaces to a single space character.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/234
-- Commit Summary --
* add support for
beecrypt are storing headers under /usr/include/beecrypt by default (which is
also where the configure.ac check looks for as well), but while passing
internal beecrypt build to default header search path, it fails to do so for
external beecrypt (ie. -I/usr/include/beecrypt).
You can view,
@proyvind pushed 2 commits.
9bdd811 add support for %{shrink:}, derived from rpm5.org
532a383 use %{shrink:} to slim down %__spec_install_post to work with
parallelize
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software
@proyvind pushed 1 commit.
7b278b4 change shebang to /bin/bash
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/235/files/e226a2841772fa2295f76f4cf508175fbb6dc073
@proyvind pushed 2 commits.
b59efa4 notify about missing chrpath
b22db1d fix proper stripping of .pc file name suffixes
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/122/files
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/235
-- Commit Summary --
* add support for passing multiple names to find-lang.sh to avoid having to
run find-lang.sh for each name and append the file lists produced later
@proyvind pushed 1 commit.
d3c3dc0 fix license versioning
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/122/files/532a383a4bc19daee7ac96ce44947bfa12b0ad7c..d3c3dc0f5151a5680be6d1e810afc621e44358a7
There's no %{trim:} nor %{strip:}.. ;)
But beyond just trimming/stripping, it shrinks it all the way down minimal size.
Where there's a common practice of ending macro defintions with '\n %{nil}',
the parsed output of will become completely unfeasiable for use with scripts
etc. that won't handle
First of all, while PEP 394 recommends this, it's not what's common practice
amongst distros, where Arch not even being a RPM based distro makes it less
relevant.
I know of no rpm based distros where /usr/bin/python isn't pointing to the
default python interpreter binary version. Also using
OpenMandriva uses python 3 as default, with /usr/bin/python pointing to python3.
AFAIK Mageia doesn't intentionally follow PEP 394 as much as it rather hasn't
switched to python3 as it's default yet, where ie. python packages prefixed
with python- are python 2, while python 3 packages are
the philosophical discussion regarding is anyways rather moot, but the patch
from my earlier comment should anyways be sufficient to address it properly. :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Nay on this one from me.
Given the generally and relatively small number of files found in buildroots
and thanks to fs caching, running 'find' in buildroot per script takes up an
irrelevant amount of time, where the KISS brp- scripts does a perfectly good
job (unless horribly implemented) of
About (optionally) separating %changelog from spec file, that makes perfect
sense, which several distributions does with as pointed out it rather generated
on the fly from vcs commit log and appended to spec file during build.
Adding changelog to spec files these days is comparable to
k, I can see that being corner case useful, at least for traditionally
installed distributions (ie. distro installation from packages).
But I guess live installers/image dumps are becoming more common these days (or
might just've become even what's considered common these days..? *dinosaur*) I
1 - 100 of 115 matches
Mail list logo