2:56 a.m.
I had a bug filed that a Python package I'm maintaining cannot be
rebuilt using 'rpmbuild --rebuild'. The failure was that the *.pyc
and *.pyo files are missing.
After a lot of head-scratching and debugging it turns out that
brp-python-bytecompile was not running, and that happens because the
RPM macro %{__os_install_post} didn't contain a call to
brp-python-bytecompile. This macro exists in base RPM, but is
overridden/extended when redhat-rpm-config is installed.
Installing redhat-rpm-config fixes the problem for the bug reporter.
However this raises some questions:
- Should this package explicitly BR redhat-rpm-config?
- Should all Python packages explicitly BuildRequire redhat-rpm-config?
- Should this package not be packaging up the *.py[co] files?
- Is this a bug in redhat-rpm-config/Python/RPM/Fedora?
- Should I just ignore this because it builds fine in Koji?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
3:27 a.m.
On Thu, 14 Nov 2013 08:56:22 +0000
"Richard W.M. Jones" <rjones(a)redhat.com> wrote:
I had a bug filed that a Python package I'm maintaining cannot be
rebuilt using 'rpmbuild --rebuild'. The failure was that the *.pyc
and *.pyo files are missing.
After a lot of head-scratching and debugging it turns out that
brp-python-bytecompile was not running, and that happens because the
RPM macro %{__os_install_post} didn't contain a call to
brp-python-bytecompile. This macro exists in base RPM, but is
overridden/extended when redhat-rpm-config is installed.
Installing redhat-rpm-config fixes the problem for the bug reporter.
However this raises some questions:
- Should this package explicitly BR redhat-rpm-config?
- Should all Python packages explicitly BuildRequire
redhat-rpm-config?
- Should this package not be packaging up the *.py[co] files?
- Is this a bug in redhat-rpm-config/Python/RPM/Fedora?
- Should I just ignore this because it builds fine in Koji?
I think ignoring is fine, we should rather recommend to do "yum install
@buildsys-build" before starting to work on Fedora packages
Dan
3:36 a.m.
On Thu, 2013-11-14 at 10:27 +0100, Dan Horák wrote:
On Thu, 14 Nov 2013 08:56:22 +0000
"Richard W.M. Jones" <rjones(a)redhat.com> wrote:
> However this raises some questions:
>
> - Should this package explicitly BR redhat-rpm-config?
>
> - Should all Python packages explicitly BuildRequire
> redhat-rpm-config?
>
> - Should this package not be packaging up the *.py[co] files?
>
> - Is this a bug in redhat-rpm-config/Python/RPM/Fedora?
>
> - Should I just ignore this because it builds fine in Koji?
Or maybe the other way around, do you have to explictly list the .pyc
and .pyo files in the %files manifest?
Could a slightly larger glob work around the problem?
For example, if right now you have:
%dir %{python_sitelib}/mymodule
%{python_sitelib}/mymodule/*.py
%{python_sitelib}/mymodule/*.pyc
%{python_sitelib}/mymodule/*.pyo
You could replace that by:
%{python_sitelib}/mymodule
The above would include the folder, the .py files, and (if they have
been built) the .py[co] files as well.
Is something like this not possible in your case?
I think ignoring is fine, we should rather recommend to do "yum
install
@buildsys-build" before starting to work on Fedora packages
Or even fedora-packager, which has even more important stuff than
@buildsys-build.
--
Mathieu
8:18 a.m.
On Thu, Nov 14, 2013 at 05:36:34PM +0800, Mathieu Bridon wrote:
For example, if right now you have:
%dir %{python_sitelib}/mymodule
%{python_sitelib}/mymodule/*.py
%{python_sitelib}/mymodule/*.pyc
%{python_sitelib}/mymodule/*.pyo
You could replace that by:
%{python_sitelib}/mymodule
Unfortunately the Python files are placed directly in
%{python_sitelib} (not in a module subdirectory). ie: the spec file
has:
%files -n python-%{name}
%doc python/examples/*.py
%{python_sitearch}/*
%{python_sitelib}/*.py
%{python_sitelib}/*.pyc
%{python_sitelib}/*.pyo
I have no idea if this packaging is correct or not.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
10:12 a.m.
On Thu, Nov 14, 2013 at 02:18:05PM +0000, Richard W.M. Jones wrote:
On Thu, Nov 14, 2013 at 05:36:34PM +0800, Mathieu Bridon wrote:
> For example, if right now you have:
>
> %dir %{python_sitelib}/mymodule
> %{python_sitelib}/mymodule/*.py
> %{python_sitelib}/mymodule/*.pyc
> %{python_sitelib}/mymodule/*.pyo
>
> You could replace that by:
>
> %{python_sitelib}/mymodule
Unfortunately the Python files are placed directly in
%{python_sitelib} (not in a module subdirectory). ie: the spec file
has:
%files -n python-%{name}
%doc python/examples/*.py
%{python_sitearch}/*
%{python_sitelib}/*.py
%{python_sitelib}/*.pyc
%{python_sitelib}/*.pyo
I have no idea if this packaging is correct or not.
That is a somewhat odd split (somethings in sitearch and some things in
sitelib)....
If there's nothing else in python_sitelib besides this module, you can
change the glob there:
%{python_sitearch}/*
%{python_sitelib}/*
I'd have to look at the actual package to know whether that would cause
problems.
-Toshio
9:21 p.m.
On Thu, 2013-11-14 at 08:12 -0800, Toshio Kuratomi wrote:
If there's nothing else in python_sitelib besides this module,
you can
change the glob there:
%{python_sitearch}/*
%{python_sitelib}/*
Or:
%{python_sitearch}/*.py*
%{python_sitelib}/*.py*
Just to be sure not to include undesired stuff.
--
Mathieu
9:45 a.m.
On Thu, 2013-11-14 at 08:56 +0000, Richard W.M. Jones wrote:
I had a bug filed that a Python package I'm maintaining cannot
be
rebuilt using 'rpmbuild --rebuild'. The failure was that the *.pyc
and *.pyo files are missing.
After a lot of head-scratching and debugging it turns out that
brp-python-bytecompile was not running, and that happens because the
RPM macro %{__os_install_post} didn't contain a call to
brp-python-bytecompile. This macro exists in base RPM, but is
overridden/extended when redhat-rpm-config is installed.
Installing redhat-rpm-config fixes the problem for the bug reporter.
However this raises some questions:
- Should this package explicitly BR redhat-rpm-config?
No.
- Should all Python packages explicitly BuildRequire
redhat-rpm-config?
No.
- Should this package not be packaging up the *.py[co] files?
No.
- Is this a bug in redhat-rpm-config/Python/RPM/Fedora?
Yes. People hit this _constantly_ in a lot of ways. Like "why am I not
getting debuginfo packages". The theory is that you might want to build
with some other set of macros, which is why rpmbuild doesn't just
require r-r-c.
I think this is foolish, and that we should just fix rpmbuild: if you
wanted some other set of macros, start by rebuilding rpm to require
something other than r-r-c. The counter-argument is - and I find this
completely baffling - that it's easier to replace packages than rebuild
them, so that instead rpmbuild should Require: system-rpm-config and
then r-r-c happens to be what provides that by default. Which, sure,
that's also a thing we could do.
Either solution would be better than what we have.
- Should I just ignore this because it builds fine in Koji?
Yes.
- ajax
10:32 a.m.
On Thu, 14 Nov 2013, Adam Jackson wrote:
Yes. People hit this _constantly_ in a lot of ways. Like "why
am I not
getting debuginfo packages". The theory is that you might want to build
with some other set of macros, which is why rpmbuild doesn't just
require r-r-c.
I think this is foolish, and that we should just fix rpmbuild: if you
wanted some other set of macros, start by rebuilding rpm to require
something other than r-r-c. The counter-argument is - and I find this
completely baffling - that it's easier to replace packages than rebuild
them, so that instead rpmbuild should Require: system-rpm-config and
then r-r-c happens to be what provides that by default. Which, sure,
that's also a thing we could do.
Either solution would be better than what we have.
Agreed, and said so in the past. I had to add it as buildrequires: to
libreswan.
Paul
11:13 a.m.
On 11/14/2013 05:45 PM, Adam Jackson wrote:
On Thu, 2013-11-14 at 08:56 +0000, Richard W.M. Jones wrote:
> - Is this a bug in redhat-rpm-config/Python/RPM/Fedora?
Yes. People hit this _constantly_ in a lot of ways. Like "why am I not
getting debuginfo packages". The theory is that you might want to build
with some other set of macros, which is why rpmbuild doesn't just
require r-r-c.
I think this is foolish, and that we should just fix rpmbuild: if you
wanted some other set of macros, start by rebuilding rpm to require
something other than r-r-c. The counter-argument is - and I find this
completely baffling - that it's easier to replace packages than rebuild
them, so that instead rpmbuild should Require: system-rpm-config and
then r-r-c happens to be what provides that by default. Which, sure,
that's also a thing we could do.
Well, technically rpmbuild does NOT require redhat-rpm-config to
function, building "Fedora compliant" packages does. Anyway, I got tired
of this argument in March, so Fedora >= 20 has this:
http://pkgs.fedoraproject.org/cgit/rpm.git/commit/?id=6fb2566e2d6d8b2e29e...
- Panu -
11:59 a.m.
On Thu, 2013-11-14 at 19:13 +0200, Panu Matilainen wrote:
On 11/14/2013 05:45 PM, Adam Jackson wrote:
> On Thu, 2013-11-14 at 08:56 +0000, Richard W.M. Jones wrote:
>
>> - Is this a bug in redhat-rpm-config/Python/RPM/Fedora?
>
> Yes. People hit this _constantly_ in a lot of ways. Like "why am I not
> getting debuginfo packages". The theory is that you might want to build
> with some other set of macros, which is why rpmbuild doesn't just
> require r-r-c.
>
> I think this is foolish, and that we should just fix rpmbuild: if you
> wanted some other set of macros, start by rebuilding rpm to require
> something other than r-r-c. The counter-argument is - and I find this
> completely baffling - that it's easier to replace packages than rebuild
> them, so that instead rpmbuild should Require: system-rpm-config and
> then r-r-c happens to be what provides that by default. Which, sure,
> that's also a thing we could do.
Well, technically rpmbuild does NOT require redhat-rpm-config to
function, building "Fedora compliant" packages does. Anyway, I got tired
of this argument in March, so Fedora >= 20 has this:
http://pkgs.fedoraproject.org/cgit/rpm.git/commit/?id=6fb2566e2d6d8b2e29e...
Awesome, thanks!
- ajax
9:25 p.m.
On 11/14/2013 06:13 PM, Panu Matilainen wrote:
On 11/14/2013 05:45 PM, Adam Jackson wrote:
> On Thu, 2013-11-14 at 08:56 +0000, Richard W.M. Jones wrote:
>
>> - Is this a bug in redhat-rpm-config/Python/RPM/Fedora?
>
> Yes. People hit this _constantly_ in a lot of ways. Like "why am I not
> getting debuginfo packages". The theory is that you might want to build
> with some other set of macros, which is why rpmbuild doesn't just
> require r-r-c.
>
> I think this is foolish, and that we should just fix rpmbuild: if you
> wanted some other set of macros, start by rebuilding rpm to require
> something other than r-r-c. The counter-argument is - and I find this
> completely baffling - that it's easier to replace packages than rebuild
> them, so that instead rpmbuild should Require: system-rpm-config and
> then r-r-c happens to be what provides that by default. Which, sure,
> that's also a thing we could do.
Well, technically rpmbuild does NOT require redhat-rpm-config to
function, building "Fedora compliant" packages does. Anyway, I got tired
of this argument in March, so Fedora >= 20 has this:
http://pkgs.fedoraproject.org/cgit/rpm.git/commit/?id=6fb2566e2d6d8b2e29e...
I haven't tried, but in my understanding, this change renders it
impossible to use Fedora's rpm to build non-Fedora rpms
Ralf
1:01 a.m.
On 11/15/2013 05:25 AM, Ralf Corsepius wrote:
On 11/14/2013 06:13 PM, Panu Matilainen wrote:
> On 11/14/2013 05:45 PM, Adam Jackson wrote:
>> On Thu, 2013-11-14 at 08:56 +0000, Richard W.M. Jones wrote:
>>
>>> - Is this a bug in redhat-rpm-config/Python/RPM/Fedora?
>>
>> Yes. People hit this _constantly_ in a lot of ways. Like "why am I not
>> getting debuginfo packages". The theory is that you might want to build
>> with some other set of macros, which is why rpmbuild doesn't just
>> require r-r-c.
>>
>> I think this is foolish, and that we should just fix rpmbuild: if you
>> wanted some other set of macros, start by rebuilding rpm to require
>> something other than r-r-c. The counter-argument is - and I find this
>> completely baffling - that it's easier to replace packages than rebuild
>> them, so that instead rpmbuild should Require: system-rpm-config and
>> then r-r-c happens to be what provides that by default. Which, sure,
>> that's also a thing we could do.
>
> Well, technically rpmbuild does NOT require redhat-rpm-config to
> function, building "Fedora compliant" packages does. Anyway, I got tired
> of this argument in March, so Fedora >= 20 has this:
>
>
http://pkgs.fedoraproject.org/cgit/rpm.git/commit/?id=6fb2566e2d6d8b2e29e...
>
I haven't tried, but in my understanding, this change renders it
impossible to use Fedora's rpm to build non-Fedora rpms
Not impossible, just a bit harder. Which is the other reason I resisted
the change for quite some time. You now need to replace
redhat-rpm-config with some other package providing system-rpm-config to
get around this.
- Panu -
10:48 a.m.
New subject: Request Tracker v.4
I haven't seen anything related to Request Tracker v.4 on Fedora sites.
bestpractical.com claims it's a major update with lots of bug fixes and
improvements:
http://www.bestpractical.com/rt/whats-new/
What is the status---is anyone working on / planning to package v.4? I
suppose it won't be a simple package upgrade given that the current
package is called rt3 :)
11:18 a.m.
New subject: Request Tracker v.4
On mið 18.des 2013 16:48, Przemek Klosowski wrote:
I haven't seen anything related to Request Tracker v.4 on Fedora
sites. bestpractical.com claims it's a major update with lots of bug
fixes and improvements:
http://www.bestpractical.com/rt/whats-new/
What is the status---is anyone working on / planning to package v.4? I
suppose it won't be a simple package upgrade given that the current
package is called rt3 :)
Ralf can answer the current status but for a long time it was stuck in
review [¹] + and I guess he never said which Christmas in c14 ;)
JBG
1. https://bugzilla.redhat.com/show_bug.cgi?id=665096
12:15 p.m.
New subject: Request Tracker v.4
On 12/18/2013 06:18 PM, "Jóhann B. Guðmundsson" wrote:
On mið 18.des 2013 16:48, Przemek Klosowski wrote:
> I haven't seen anything related to Request Tracker v.4 on Fedora
> sites. bestpractical.com claims it's a major update with lots of bug
> fixes and improvements:
> http://www.bestpractical.com/rt/whats-new/
That's marketing. Experience
with rt tells BestPractical's marketing
needs to be read with caution.
> What is the status---is anyone working on / planning to package
v.4?
I am. Actually I have been continuously working on rt-4.0.x:
A pretty outdated version can be found in
http://corsepiu.fedorapeople.org/packages/
A more recent version package can be found on Packman:
ftp://packman.links2linux.de/pub/packman/fedora/20
ATM, I currently am locally testing a rt-4.0.18 rpm which I intend to
upload to fedorapeople.org + packman end of this week, ... if time permits.
I haven't looked into 4.2.x, yet, but I already know it once more will
require yet another lengthy series of perl-modules.
I
> suppose it won't be a simple package upgrade given that the current
> package is called rt3 :)
Correct. The initial idea was to make rt3 installable
in parallel to rt2
and rt4. It used to be possible with rt2, but unfortunately, this plan
has failed with rt-4.0.x
Ralf can answer the current status but for a long time it was stuck
in
review [¹]
rt4 was never submitted for review, because it's long dependency
requirement chains were stuck in Fedora review queues and absurdities.
In the end, I never managed to return to finish the plan to submit it.
+ and I guess he never said which Christmas in c14 ;)
Right ...
an it's basically the same situation this year:
End of years my personal situation tends to become hectic and time to
become very rare, with BestPractical's and Fedora's habits to release a
major update next to end of year not being helpful either ;)
Ralf
6:55 p.m.
New subject: Request Tracker v.4
I was packaging some Perl modules of rt4 a month ago.
If you want help, I can do it.
Thanks.
2:28 p.m.
On 11/14/2013 03:56 AM, Richard W.M. Jones wrote:
I had a bug filed that a Python package I'm maintaining cannot
be
rebuilt using 'rpmbuild --rebuild'. The failure was that the *.pyc
and *.pyo files are missing.
After a lot of head-scratching and debugging it turns out that
brp-python-bytecompile was not running, and that happens because the
RPM macro %{__os_install_post} didn't contain a call to
brp-python-bytecompile. This macro exists in base RPM, but is
overridden/extended when redhat-rpm-config is installed.
Installing redhat-rpm-config fixes the problem for the bug reporter
I noticed some
odd things about the whole brp-python* setup : for
instance, there are two very similar versions of brp-python-hardlink:
one from rpm-build-4.11.1-3.fc19.x86_64 and another from
redhat-rpm-config-9.1.0-46.1.fc19.noarch ; they seem to be doing the
same thing, the only difference is
< pyo="${pyc%c}o"
---
pyo="$(echo $pyc | sed -e 's/.pyc$/.pyo/')"
No big deal but it looks like someone who knows this area should review
and/or clean it up.
3779
days inactive
3814
days old
17 comments
12 participants
participants (12)
-
Adam Jackson -
Christopher Meng -
Dan Horák -
Jóhann B. Guðmundsson -
Kevin Kofler -
Mathieu Bridon -
Panu Matilainen -
Paul Wouters -
Przemek Klosowski -
Ralf Corsepius -
Richard W.M. Jones -
Toshio Kuratomi