On 24 August 2016 at 02:10, Jason L Tibbitts III wrote:
>> "PV" == Petr Viktorin writes:
>
> PV> - Make it standard practice in Fedora to use this data and treat the
> PV> spec file as an immutable generated artifact.
>
> If you're saying that any changes which are made to the spec file (say,
On Tue, Aug 23, 2016 at 12:48:40PM -0500, Jason L Tibbitts III wrote:
> > "ZJ" == Zbigniew Jędrzejewski-Szmek writes:
>
> ZJ> %changelog would have to be stored separately. This would apply even
> ZJ> for qthe case when no "external" changes were made — just normal updates
> ZJ> by the packag
> "ZJ" == Zbigniew Jędrzejewski-Szmek writes:
ZJ> %changelog would have to be stored separately. This would apply even
ZJ> for qthe case when no "external" changes were made — just normal updates
ZJ> by the package managers — since there's no way for pyp2rpm to know
ZJ> what happened in the p
On Tue, Aug 23, 2016 at 11:10:08AM -0500, Jason L Tibbitts III wrote:
> > "PV" == Petr Viktorin writes:
>
> PV> - Make it standard practice in Fedora to use this data and treat the
> PV> spec file as an immutable generated artifact.
>
> If you're saying that any changes which are made to the
> "PV" == Petr Viktorin writes:
PV> - Make it standard practice in Fedora to use this data and treat the
PV> spec file as an immutable generated artifact.
If you're saying that any changes which are made to the spec file (say,
by release engineering doing a rebuild or by someone tweaking the
On 08/17/2016 06:52 PM, Nick Coghlan wrote:
On 15 August 2016 at 19:42, Igor Gnatenko wrote:
It can't track/change BR/R's as RPM is Turing complete and impossible to parse.
Imagine, we have pythonXdist(foo) extracted from PyPI metadata, but in
Fedora we still need to add some more BR for that,
On 15 August 2016 at 19:42, Igor Gnatenko wrote:
> It can't track/change BR/R's as RPM is Turing complete and impossible to
> parse.
> Imagine, we have pythonXdist(foo) extracted from PyPI metadata, but in
> Fedora we still need to add some more BR for that, so we add it. When
> new release comes
It can't track/change BR/R's as RPM is Turing complete and impossible to parse.
Imagine, we have pythonXdist(foo) extracted from PyPI metadata, but in
Fedora we still need to add some more BR for that, so we add it. When
new release comes (still without added BR in upstream) rebase-helper
will not
On 08/12/2016 05:40 PM, Petr Viktorin wrote:
The idea with pyp2rpm is to work with the Python Packaging Authority
so that the upstream metadata *can* be converted automatically.
Ideally Fedora packagers would fix packaging problems upstream, rather
than maintaining spec files.
Ideas for a tool
On 08/12/2016 03:17 PM, Jason L Tibbitts III wrote:
"PV" == Petr Viktorin writes:
PV> The magic worries me. It seems like if these macros were finished,
PV> you'd be about the only person capable of maintaining them.
I don't think so. There are other committers, and the core of it didn't
eve
> "PV" == Petr Viktorin writes:
PV> The magic worries me. It seems like if these macros were finished,
PV> you'd be about the only person capable of maintaining them.
I don't think so. There are other committers, and the core of it didn't
even come from me so there's certainly at least two
On 08/11/2016 07:37 PM, Jason L Tibbitts III wrote:
"TO" == Tomas Orsava writes:
TO> That looks incredible! Why didn't it see the light of day? Time
TO> constraints or some technical issues?
Well, it sort of fell by the wayside as I got involved with other
things. I've learned a lot about RP
> "TO" == Tomas Orsava writes:
TO> That looks incredible! Why didn't it see the light of day? Time
TO> constraints or some technical issues?
Well, it sort of fell by the wayside as I got involved with other
things. I've learned a lot about RPM internals since then and I know I
really should
Hi!
No, this automatic Provides generator does not create "python(name)".
Only "pythonX.Ydist()" and "pythonXdist()".
On 08/10/2016 07:09 PM, Avram Lubkin wrote:
Is an unversioned python(name) also being created automagically? I
manually create these for the command line tools which support
Yeah, I really wish I had actually pushed through the macro work I had
done last year. You can see that at https://pagure.io/python-macros
A spec would look like this:
https://pagure.io/python-macros/blob/master/f/test1.spec
And most of that is actually implemented. Note the almost complete
On 10.8.2016 23:36, Jason L Tibbitts III wrote:
A spec would look like this:
https://pagure.io/python-macros/blob/master/f/test1.spec
And most of that is actually implemented. Note the almost complete
absence of version-specific bits. That package builds for an arbitrary
number of system pytho
> "PV" == Petr Viktorin writes:
PV> No, getting. Example expansion:
PV> %{python_dist_name ndg_HTTPSclient} => ndg-httpsclient
Ah, OK, that makes much more sense.
PV> Would "python3_requires" and "python3_buildrequires" be better?
I think so.
PV> Please do and share your thoughts, I trust
On 08/10/2016 06:49 PM, Jason L Tibbitts III wrote:
"PV" == Petr Viktorin writes:
PV> * One macro for getting the canonical (normalized) dist-name:
PV> %{python_dist_name NAME}
Do you mean "setting" here?
No, getting. Example expansion:
%{python_dist_name ndg_HTTPSclient} => ndg-httpscl
Is an unversioned python(name) also being created automagically? I manually
create these for the command line tools which support multiple Python
versions, where the python2-name and python3-name package both provide
python(name) and then the name package requires python(name) with a
recommends for
> "PV" == Petr Viktorin writes:
PV> * One macro for getting the canonical (normalized) dist-name:
PV> %{python_dist_name NAME}
Do you mean "setting" here?
PV> * Four macros for adding Requires and BuildRequires lines (which use
PV> the python_dist_name macro above):
PV> %{requires
To help automatic building RPMs from native Python packages, we need an
automatic way to record the software's upstream name (dist name, name
on PyPI) in Fedora packages.
For this, we are using RPM's automatic dependency generator written by
Per Øyvind Karlsen and Neal Gompa, which automatically
21 matches
Mail list logo
