Should be done as a part of #567.
--
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/1090#issuecomment-606054657___
Rpm-maint
Ok, still easily reproducable by commenting out this:
https://src.fedoraproject.org/rpms/timeshift/blob/master/f/timeshift.spec#_71
Whether there's anything rpm can actually do about this I dunno.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly
Looks good
--
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/1146#issuecomment-605953855___
Rpm-maint mailing list
This is a valid use case. But I dislike the idea of adding a new tag for this.
I'd rather like to see something that is closer to the hack without its
drawbacks
`Source1: https://foo.bar/baz -> ba-1.2.tgz` or
`Source1: https://foo.bar/baz : ba-1.2.tgz`
--
You are receiving this because you
Right, that's a fair point.
Ultimately there should indeed be just one way to build the bindings,
maintaining multiple ways was never a good idea anyway. OTOH calling setup.py
from inside automake sounds like a nightmare too.
--
You are receiving this because you are subscribed to this
Without the setup.py, we don't have the egg-info data which other projects use
to depend on the Python bindings. The Autofoo should probably just be reworked
to call setup.py instead.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it
Needs to be looked at when re-doing the architecture handling.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
The issue here is pretty convoluted: the setup.py method of building was
originally added primarily to support shipping python-bindings as a separate
tarball, to support building multiple versions of the bindings. The former
never happened, and to support Py 2 vs 3 people have been building the
This needs to be reviewed in the context of the architecture redesign whenever
that happens.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Unfortunately, the minimalistic solution is used for something else already:
URL fragments are used to have a different file name from what a download from
the URL would normally yield, e.g. if an on-the-fly generated upstream archive
doesn't contain the package name.
--
You are receiving
Added similar cleanup for fcntl.h, and rebased to fix conflict from the
vfs-cleanup.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@pmatilai pushed 1 commit.
6ac1880a100c8ab4cf532f5959bf84fe2af9dfdb Flush 1998 vintage
fcntl-compatibility mess from system.h
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
Added a missed dirent.h in fts.c (now there's another pile of ... to clean up)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
dirent.h and struct dirent are actually standard on this millenium, the
only thing that isnt is d_type member for which we have and retain
a specific test in configure.ac. Include dirent.h where needed,
relatively few places do which makes it even a bigger insult to have
this included from
Merged #1143 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/1143#event-3177469691___
Rpm-maint mailing list
Thanks for the patches and having a close look at the alpha!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Merged #1145 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/1145#event-3177397915___
Rpm-maint mailing list
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1145
-- Commit Summary --
* fix phrasing
* also package rpm-plugins.8
-- File Changes --
M doc/Makefile.am (1)
M doc/rpm-plugin-prioreset.8 (2)
-- Patch Links --
@pmatilai approved this pull request.
Doh! Thanks :slightly_smiling_face:
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Merged #1144 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/1144#event-3177329018___
Rpm-maint mailing list
https://rpm.org/wiki/Releases/4.16.0 says Add man pages for all plugins
and rpm2archive (#1016)
However RPM 4.16.0 alpha doesnt actually include them…
Ahem
This pull request actually includes the new man pages the tarball and thus the
vendor rpms… :-)
Thanks
You can view, comment on, or merge
21 matches
Mail list logo
