Building sources twice
by Toshio Kuratomi
We have a few packages that need to build themselves from their sources
twice. For instance, vim builds three times (a minimal version for /bin/vi,
and two versions with more dependencies for /usr/bin/vim and
/usr/bin/gvim). Working on the python3 Guidelines, it looks like we'll have
some more with packages that build both python2 and python3 modules from
source that undergoes an automated transformation as part of its build.
So there's approaches to doing this:
1) Copy the source tree and build in both places
2) Build once with the python2 interpreter, copy the results away, and then
build a second time with python3.
vim takes a C version of option #2 (build with one set of configure options,
copy the results; make clean; and build with another set of options) but I'm
not sure there's a reason for that. It uses less disk space as we don't
have to duplicate the source tree. However, in software that might pollute
its source tree when it builds (maybe substituting file paths directly into
a source file, for instance), this could break.
Are there other reasons than I see for doing #2?
-Toshio
14 years, 3 months
Globally-visible executables with parallel python 2 and python 3 stacks
by David Malcolm
python3 is in rawhide and I'm hoping to build out the Python 3 stack
(help would be most welcome!)
I've run into a snag with the plan of building out parallel python 2 and
python 3 stacks [1]: What do we do about executables that live
in /usr/bin ?
For example if we have a 'console_scripts' in a setup.py shared between
python 2 and python 3 builds: these will spit out files in /usr/bin/,
and these will collide.
The immediate example I'm thinking of is python-coverage. This
package's setup.py has:
entry_points = {
'console_scripts': [
'coverage = coverage:main',
]
},
which thus generates a /usr/bin/coverage executable (this is a python
script that runs another python script whilst generating code-coverage
information on the latter). Where does the python3 version of this
executable go?
Similarly for the 'scripts' clause; see e.g. python-pygments:
Pygments-1.1.1/setup.py has:
scripts = ['pygmentize'],
which thus leads to a /usr/bin/pygmentize executable (it's a utility to
do syntax-highlighting, so not a language-support feature as such;
still, having both py2 and py3 versions available seems worthwhile for
transition purposes).
One approach is to simply add a "3" or "-3" suffix to these paths. I've
already done this for python3-tools; "2to3" became "2to3-3"
In the above examples, this would lead to:
/usr/bin/coverage-3
/usr/bin/pymentize-3
Or we could use a "python3-" prefix, leading to:
/usr/bin/python3-coverage
/usr/bin/python3-pymentize
Or something involving directories and the PATH environment variable,
leading perhaps to:
/usr/libexec/python-3.1/coverage
/usr/libexec/python-3.1/pygmentize
Anyone got any better ideas? Thoughts about which of the above is
preferrable?
Potentially we could automate the solution in python3-setuptools, so
that you don't need to fixup the build by hand in each setup.py.
Thoughts?
Dave
[1] https://fedoraproject.org/wiki/Features/Python3F13
14 years, 3 months
rb_libtorrent has broken deps in Rawhide
by leigh scott
At the moment I am unable to build qbittorrent and torium (springlobby
as well) at Koji due to broken deps.
I have emailed Peter and requested commit rights for the devel branch
but received no response.
Would it be possible for a proven packager to rebuild rb_libtorrent
against the latest boost version ?
14 years, 3 months
Re: libcdio update
by Jay Greguske
----- "Adrian Reber" <adrian(a)lisas.de> wrote:
> On Tue, Jan 19, 2010 at 11:31:50AM +0100, Michael Schwendt wrote:
> > On Tue, 19 Jan 2010 09:43:49 +0100, Adrian wrote:
> >
> > > I would like to update libcdio to the latest version (0.82). This
> > > requires a rebuild of its dependencies:
> > >
> > > audacious-plugins
> > > gvfs
> > > kover
> > > libcddb
> > > oxine
> > > pycdio
> > > qmmp
> > > xfce4-cddrive-plugin
> > > xmms2
> > >
> > > If the maintainers of the above packages do not object I would do all
> > > the necessary rebuilds.
> >
> > Only in Rawhide I assume. No objections wrt audacious-plugins (with the
> > caveat that I don't know about the changes in libcdio 0.82 yet).
>
> Sure. Only rawhide. Forgot to mention that.
>
> > F-12 would be a different case.
>
> No intention at all.
>
> Adrian
> --
> devel mailing list
> devel(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>
I maintain pycdio; no objections here.
- Jay
14 years, 3 months
Fedora packages for upcoming wxWidgets 3.0 available
by Dan Horák
Hello,
wxWidgets developers are hard working on the upcoming major version 3.0.
To make life of Fedora users and maintainers easier I started building
recent snapshots and pre-releases as Fedora-compatible RPM packages. The
libraries are installable in parallel with the regular 2.8.x, devel
sub-package will replace the one from 2.8.x. Downloads for Fedora 12 and
Rawhide are available at http://fedora.danny.cz/danny-wx/
Dan
--
Fedora and Red Hat package maintainer
14 years, 3 months
question about state of F11 kernel
by Michał Piotrowski
Hi,
What is the state of F11 kernel? AFAIK 2.6.30 is not supported by
upstream for a month. Upgrade to 2.6.31 doesn't solve this problem,
because 2.6.31.12 is probably the latest from 31 series. I have seen
failed 2.6.32 build for F11 in koji
http://koji.fedoraproject.org/koji/buildinfo?buildID=150432 . I would
like to know if you want to maintain 2.6.30 for whole F11 lifetime or
switch to 2.6.32 soon.
If you plan to switch to 2.6.32 soon I would like to get some test
kernels. I understand that things like F11 kernel support doesn't have
top priority while F13 development, but it is important to some of us.
Regards,
Michal
14 years, 3 months
libdrm vs mesa updates - update group for bodhi?
by David Airlie
So I say libdrm was going to be karma'ed into updates, and
I thought I'd disabled that but it all got confused a few days ago.
So I thought well I better push all the packages that depends on it
into updates as well, and they'll all end up in one signing pass
and everyone will be happy.
Now somehow mesa is in updates without libdrm/xorg-x11-drv-ati/plymouth
updates that should have gone with it.
Do we have any way to do some sort of grouping in bodhi so as to
avoid this happening.
Dave.
14 years, 3 months
