Re: rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)
On 2013-06-20 14:19, Jonathan Masters wrote:
Indeed. This was a concern I raised when we first began the bootstrap. Blindly
rerunning autoreconf in every case is a really bad idea. But doing it in a
discretionary way, allowing the package maintainer to influence what happens
(they in theory know whether this will work for their package and their
upstream) is good.
Sent from my Android phone using TouchDown (www.nitrodesk.com)
-Original Message-
From: Ben Boeckel [maths...@gmail.com]
Received: Thursday, 20 Jun 2013, 7:53
To: devel@lists.fedoraproject.org
Subject: Re: rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not
support aarch64 in f19 and rawhide bug #925276)
On Mon, 17 Jun, 2013 at 15:29:39 GMT, Michael Schwendt wrote:
One problem with that is, one cannot "blindly" run autoreconf -fi and
expect it to be 100% compatible with the multitude of Autotools' based
projects. Typically one will need to update the configure script, m4
macros as well as Makefile.{am,in} templates. And if one doesn't verify
the build framework, one can miss files where regenerating them drops
stuff (as one example, config.h.in files where someone has inserted
stuff the wrong way).
There are also those rare upstreams which run autoreconf once, commit
the generated files, then make "minor" changes to configure and friends
directly. Running autoreconf on these projects is bound to fail and
upstream might be unhappy moving "back" to editing the .in and .ac files
directly.
--Ben
Hm... it actually seems that there is a lot of common ground here, and
quite different from what a newbie will find if googling [1]. Yes, it's
an old draft, but in a sense it't the most official document found, I guess.
We have at least three cases?
- Ben's case: projects running auto(re)conf once, then committing and
maintaining the generated files (and some years later, in desperation,
goes for cmake...)
- Projects which intitially had a working autotools setup which have
become more or less unusable in a modern environment.
- Projects which have a well maintained, working autotools setup - here
it's natural to run autoreconf as part of the build.
Seems that we all agree that the last situation is the preferred one. In
the other scenarios, it might make make sense to try to help upstream to
update the obsolete configure.in/ac and Makefile.am. Or it just might
not, and it's better to use the generated fiels.
This should really be a fpc ticket before we lose everything. However,
my fpc quota has expired... ;)
--alec
[1] https://fedoraproject.org/wiki/PackagingDrafts/AutoConf
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
RE: rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)
Indeed. This was a concern I raised when we first began the bootstrap. Blindly
rerunning autoreconf in every case is a really bad idea. But doing it in a
discretionary way, allowing the package maintainer to influence what happens
(they in theory know whether this will work for their package and their
upstream) is good.
Sent from my Android phone using TouchDown (www.nitrodesk.com)
-Original Message-
From: Ben Boeckel [maths...@gmail.com]
Received: Thursday, 20 Jun 2013, 7:53
To: devel@lists.fedoraproject.org
Subject: Re: rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not
support aarch64 in f19 and rawhide bug #925276)
On Mon, 17 Jun, 2013 at 15:29:39 GMT, Michael Schwendt wrote:
> One problem with that is, one cannot "blindly" run autoreconf -fi and
> expect it to be 100% compatible with the multitude of Autotools' based
> projects. Typically one will need to update the configure script, m4
> macros as well as Makefile.{am,in} templates. And if one doesn't verify
> the build framework, one can miss files where regenerating them drops
> stuff (as one example, config.h.in files where someone has inserted
> stuff the wrong way).
There are also those rare upstreams which run autoreconf once, commit
the generated files, then make "minor" changes to configure and friends
directly. Running autoreconf on these projects is bound to fail and
upstream might be unhappy moving "back" to editing the .in and .ac files
directly.
--Ben
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)
On Mon, 17 Jun, 2013 at 15:29:39 GMT, Michael Schwendt wrote:
> One problem with that is, one cannot "blindly" run autoreconf -fi and
> expect it to be 100% compatible with the multitude of Autotools' based
> projects. Typically one will need to update the configure script, m4
> macros as well as Makefile.{am,in} templates. And if one doesn't verify
> the build framework, one can miss files where regenerating them drops
> stuff (as one example, config.h.in files where someone has inserted
> stuff the wrong way).
There are also those rare upstreams which run autoreconf once, commit
the generated files, then make "minor" changes to configure and friends
directly. Running autoreconf on these projects is bound to fail and
upstream might be unhappy moving "back" to editing the .in and .ac files
directly.
--Ben
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)
On Tue, 18 Jun 2013 01:37:19 +0300, Oron Peled wrote: > Let me be more specific: > * If upstream uses a modern autotools, than "autoreconf" should be preferred > (IMO). > * If not, we should advise them to modernize (and if we can, try to help > them). > IIRC, that has been suggested in the many aarch64 bz tickets recently as one of several options to fix the issue. However, to repeat, often one only "touches" the Autotools files when one really needs to do that. One doesn't regularly examine them for whether they contain hacks or other problems that only turn up when regenerating the files in an env that differs from upstream's. Some contain surprises, such as but not limited to losing preprocessor definitions or using conflicting variable names. -- Fedora release 19 (Schrödinger’s Cat) - Linux 3.9.5-301.fc19.x86_64 loadavg: 0.62 0.23 0.19 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)
On Mon, 2013-06-17 at 16:57 +0200, Alec Leamas wrote:
> On 2013-06-17 16:43, Jerry James wrote:
> > On Mon, Jun 17, 2013 at 2:59 AM, Björn Esser wrote:
> >> I completely agree to this. Using `autoreconf -fi` in %build or %prep
> >> should be mandatory in packages using autotools. This will surely avoid
> >> lots of possible problems caused by just injecting config.{guess,sub} by
> >> %configure.
>>
> > That would only work if the autotools had perfect backwards
> > compatibility. They don't. I maintain multiple packages where
> > "autoreconf -fi" with modern autotools fails due to use of obsolete
> > macros.
>
> Isn't the proper solution then to patch the config files to get rid of
> the obsolete macros? Such patches should certainly be acceptable upstream.
Not necessarily, or at least not reasonably quickly.
Upstream might be running an older version of the Autotools on their
development machine, and not be interested in upgrading it (e.g they run
Debian Stable or RHEL).
So you'd still have to carry that patch downstream until they finally
upgrade and accept your patch, which can take years.
--
Mathieu
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)
On Monday 17 June 2013 22:58:53 Alec Leamas wrote: > On 2013-06-17 21:17, Jerry James wrote: > > ... I'd rather not spend the small amount of time I can devote to > > open source software work messing with a configure script just because > > somebody thinks they should be able to run autoreconf with a newer > > version of the autotools and get away with it. > > Fair enough. Hope you did not recognize me as one of those who "just > thinks they should be able to run autoreconf with a newer version of the > autotools and get away with it" - that was not my idea. Actually, that was me who *hoped* we could get away with this ;-) > ... If we ever will be able to write GL about it, we should keep both > doors open. Perhaps with a recommendation about one of > them being preferred, but nothing more drastic. Agreed. Let me be more specific: * If upstream uses a modern autotools, than "autoreconf" should be preferred (IMO). * If not, we should advise them to modernize (and if we can, try to help them). Because using very old autotools version isn't so different than using other very old development tools (think about compilers, support libraries, etc.). It is "OK", but not the most advisable practice. Helping upstream to modernize is helping our ecosystem and helping Fedora being "First". Again, all of this should be *recommendation*. Like Jerry James mentioned, it should be weighted by the package maintainer against other tasks which may be more urgent/important. -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron "Without the wind, the grass does not move. Without software, hardware is useless." -- Tao of Programming -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)
On Seg, 2013-06-17 at 16:57 +0200, Alec Leamas wrote:
> On 2013-06-17 16:43, Jerry James wrote:
> > On Mon, Jun 17, 2013 at 2:59 AM, Björn Esser wrote:
> >> I completely agree to this. Using `autoreconf -fi` in %build or %prep
> >> should be mandatory in packages using autotools. This will surely avoid
> >> lots of possible problems caused by just injecting config.{guess,sub} by
> >> %configure.
> > That would only work if the autotools had perfect backwards
> > compatibility. They don't. I maintain multiple packages where
> > "autoreconf -fi" with modern autotools fails due to use of obsolete
> > macros.
> > --
> > Jerry James
> > http://www.jamezone.org/
> Isn't the proper solution then to patch the config files to get rid of
> the obsolete macros? Such patches should certainly be acceptable upstream.
>
> That said, this and related questions have been discussed in several
> threads over the years. The sad fact is that it hasn't been possible to
> find an agreement how to cope with autotools and that we thus havn't
> much about them in the guidelines.
>
> What are the chances finding common ground now?
I hope so , some guidelines about this would be nice.
Thanks,
--
Sérgio M. B.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)
On Seg, 2013-06-17 at 08:43 -0600, Jerry James wrote:
> On Mon, Jun 17, 2013 at 2:59 AM, Björn Esser wrote:
> > I completely agree to this. Using `autoreconf -fi` in %build or %prep
> > should be mandatory in packages using autotools. This will surely avoid
> > lots of possible problems caused by just injecting config.{guess,sub} by
> > %configure.
>
> That would only work if the autotools had perfect backwards
> compatibility. They don't. I maintain multiple packages where
> "autoreconf -fi" with modern autotools fails due to use of obsolete
> macros.
What you are writing is not much common. In fact some times I had to do
the opposite, which is : run autoreconf because we have errors with
configure .
--
Sérgio M. B.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)
On 2013-06-17 21:17, Jerry James wrote: On Mon, Jun 17, 2013 at 8:57 AM, Alec Leamas wrote: Isn't the proper solution then to patch the config files to get rid of the obsolete macros? Such patches should certainly be acceptable upstream. If I have some other reason for needing to touch the configure script, then sure. (In fact, I have done just that with several projects. See what I've had to do to the gcl configure script, for example.) If not, I'd rather not spend the small amount of time I can devote to open source software work messing with a configure script just because somebody thinks they should be able to run autoreconf with a newer version of the autotools and get away with it. -- Jerry James http://www.jamezone.org/ Fair enough. Hope you did not recognize me as one of those who "just thinks they should be able to run autoreconf with a newer version of the autotools and get away with it" - that was not my idea. My question mark was for real. My personal feeling is that the old discussion about keeping these files and not running autoreconf vs running autoreconf doesn't have a "one size fits all" answer. If we ever will be able to write GL about it, we should keep both doors open. Perhaps with a recommendation about one of them being preferred, but nothing more drastic. Not perfect, simple and clean. But that's what the world is like from time to time. --alec -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpm and config.{guess,sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)
On Seg, 2013-06-17 at 11:39 +0300, Oron Peled wrote: > In the Fedora spirit of "everything buildable from clean sources", I > think > the "autoreconf" solution should be globally adopted (regardless of > aarch64): > * It doesn't use generated files as input to the build process. > * It delegates the actual management to where it belongs. Agreed , I will do that on dpkg Thanks, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)
On Mon, Jun 17, 2013 at 8:57 AM, Alec Leamas wrote: > Isn't the proper solution then to patch the config files to get rid of the > obsolete macros? Such patches should certainly be acceptable upstream. If I have some other reason for needing to touch the configure script, then sure. (In fact, I have done just that with several projects. See what I've had to do to the gcl configure script, for example.) If not, I'd rather not spend the small amount of time I can devote to open source software work messing with a configure script just because somebody thinks they should be able to run autoreconf with a newer version of the autotools and get away with it. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)
On Mon, 17 Jun 2013 10:59:06 +0200, Björn Esser wrote:
> I completely agree to this. Using `autoreconf -fi` in %build or %prep
> should be mandatory in packages using autotools.
One problem with that is, one cannot "blindly" run autoreconf -fi and
expect it to be 100% compatible with the multitude of Autotools' based
projects. Typically one will need to update the configure script, m4
macros as well as Makefile.{am,in} templates. And if one doesn't verify
the build framework, one can miss files where regenerating them drops
stuff (as one example, config.h.in files where someone has inserted
stuff the wrong way).
--
Fedora release 19 (Schrödinger’s Cat) - Linux 3.9.5-301.fc19.x86_64
loadavg: 0.13 0.12 0.08
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)
On 2013-06-17 16:43, Jerry James wrote:
On Mon, Jun 17, 2013 at 2:59 AM, Björn Esser wrote:
I completely agree to this. Using `autoreconf -fi` in %build or %prep
should be mandatory in packages using autotools. This will surely avoid
lots of possible problems caused by just injecting config.{guess,sub} by
%configure.
That would only work if the autotools had perfect backwards
compatibility. They don't. I maintain multiple packages where
"autoreconf -fi" with modern autotools fails due to use of obsolete
macros.
--
Jerry James
http://www.jamezone.org/
Isn't the proper solution then to patch the config files to get rid of
the obsolete macros? Such patches should certainly be acceptable upstream.
That said, this and related questions have been discussed in several
threads over the years. The sad fact is that it hasn't been possible to
find an agreement how to cope with autotools and that we thus havn't
much about them in the guidelines.
What are the chances finding common ground now?
--alec
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)
On Mon, Jun 17, 2013 at 2:59 AM, Björn Esser wrote:
> I completely agree to this. Using `autoreconf -fi` in %build or %prep
> should be mandatory in packages using autotools. This will surely avoid
> lots of possible problems caused by just injecting config.{guess,sub} by
> %configure.
That would only work if the autotools had perfect backwards
compatibility. They don't. I maintain multiple packages where
"autoreconf -fi" with modern autotools fails due to use of obsolete
macros.
--
Jerry James
http://www.jamezone.org/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 17 Jun 2013 09:04:02 +0200
Dan Horák wrote:
> On Mon, 17 Jun 2013 08:44:52 +0200
> Simone Caronni wrote:
>
> > On 17 June 2013 03:13, Sérgio Basto wrote:
> >
> > > we had updated dpkg some major versions sine bug opened, how I
> > > know if dpkg is now ready for aarch64 ?
> > >
> >
> > I've discovered you can trigger builds for the ARM Koji instance
> > with your account:
> >
> > koji --server=http://arm.koji.fedoraproject.org/kojihub build
> > --scratch f19 dpkg.src.rpm
>
> the fedora-packager package provides wrappers for the koji command for
> all secondary architectures in Fedora in the form ${arch}-koji, where
> arch can be arm, ppc and s390, so you can use
>
> arm-koji build --scratch f19 your.src.rpm
but you can not yet build aarch64 in koji
Dennis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iEYEARECAAYFAlG+9SAACgkQkSxm47BaWff1RwCfV7Y8ehblXK/PvqdXWnXi8IfW
IfYAoK9++/dGMjVCZbzPdMrxHxMyMQax
=PNg5
-END PGP SIGNATURE-
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)
Am Montag, den 17.06.2013, 11:39 +0300 schrieb Oron Peled:
> On Monday 17 June 2013 02:13:06 Sérgio Basto wrote:
> > Hi,
> > I'm trying follow this (aarch64 support) but
> > https://bugzilla.redhat.com/show_bug.cgi?id=922257#c1
> >
> > "could/should be closed now, as this is done automatically from %
> > configure", so no need update it anymore ?
> >
> > we had updated dpkg some major versions sine bug opened, how I know if
> > dpkg is now ready for aarch64 ?
>
> When I fixed one of my packages (libhocr), I chose a different fix:
> * Added: BuildRequires: autoconf, automake, libtool, pkgconfig
> * In "%prep" added: autoreconf --install --force
>
> IMO this is better then the new rpm kludge:
> * In autotools based projects, the tarball contain *many* generated files.
> (e.g: configure, config.h.in, config.{guess,sub}, INSTALL, etc.}
>
> * The only reason they are in the tarball is to enable build without
> the autotools suite (e.g: on other platforms)
>
> * As such, these files are not [and should not be] committed to version
> control systems.
>
> * So although they are packages in the source tarball, they are no
> part of the package real "source" -- they just happen to
> come from the platform of the one who maintain the source tarball.
> (via "make dist")
>
> * The "autoreconf" solution let autotools handle this complete problem
> without trying to mess in its internals (rpm replacing only some files).
>
> * As an example how wrong it is for rpm macros to interfere with the
> internal logic of autotools, you could have a look in %GNUconfigure
> macro in /usr/lib/rpm/macros. This one, tries to second guess
> autoconf behavior, but it still search for "configure.in" files.
> (For those who don't know -- while these files are still supported,
> most modern packages correctly renamed them to "configure.ac").
>
> In the Fedora spirit of "everything buildable from clean sources", I think
> the "autoreconf" solution should be globally adopted (regardless of aarch64):
> * It doesn't use generated files as input to the build process.
> * It delegates the actual management to where it belongs.
>
> Bye,
>
> --
> Oron Peled Voice: +972-4-8228492
> o...@actcom.co.il http://users.actcom.co.il/~oron
> "In theory, there is no difference between theory and practice. In practice,
> there is."
> -- Yogi Berra
>
Hi Oron!
I completely agree to this. Using `autoreconf -fi` in %build or %prep
should be mandatory in packages using autotools. This will surely avoid
lots of possible problems caused by just injecting config.{guess,sub} by
%configure.
Cheers,
Björn
signature.asc
Description: This is a digitally signed message part
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)
On Monday 17 June 2013 02:13:06 Sérgio Basto wrote:
> Hi,
> I'm trying follow this (aarch64 support) but
> https://bugzilla.redhat.com/show_bug.cgi?id=922257#c1
>
> "could/should be closed now, as this is done automatically from %
> configure", so no need update it anymore ?
>
> we had updated dpkg some major versions sine bug opened, how I know if
> dpkg is now ready for aarch64 ?
When I fixed one of my packages (libhocr), I chose a different fix:
* Added: BuildRequires: autoconf, automake, libtool, pkgconfig
* In "%prep" added: autoreconf --install --force
IMO this is better then the new rpm kludge:
* In autotools based projects, the tarball contain *many* generated files.
(e.g: configure, config.h.in, config.{guess,sub}, INSTALL, etc.}
* The only reason they are in the tarball is to enable build without
the autotools suite (e.g: on other platforms)
* As such, these files are not [and should not be] committed to version
control systems.
* So although they are packages in the source tarball, they are no
part of the package real "source" -- they just happen to
come from the platform of the one who maintain the source tarball.
(via "make dist")
* The "autoreconf" solution let autotools handle this complete problem
without trying to mess in its internals (rpm replacing only some files).
* As an example how wrong it is for rpm macros to interfere with the
internal logic of autotools, you could have a look in %GNUconfigure
macro in /usr/lib/rpm/macros. This one, tries to second guess
autoconf behavior, but it still search for "configure.in" files.
(For those who don't know -- while these files are still supported,
most modern packages correctly renamed them to "configure.ac").
In the Fedora spirit of "everything buildable from clean sources", I think
the "autoreconf" solution should be globally adopted (regardless of aarch64):
* It doesn't use generated files as input to the build process.
* It delegates the actual management to where it belongs.
Bye,
--
Oron Peled Voice: +972-4-8228492
o...@actcom.co.il http://users.actcom.co.il/~oron
"In theory, there is no difference between theory and practice. In practice,
there is."
-- Yogi Berra
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276
On 17 June 2013 09:04, Dan Horák wrote:
> the fedora-packager package provides wrappers for the koji command for
> all secondary architectures in Fedora in the form ${arch}-koji, where
> arch can be arm, ppc and s390, so you can use
>
> arm-koji build --scratch f19 your.src.rpm
>
Oh, thanks, I did not know.
--Simone
--
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).
http://xkcd.com/229/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276
On Mon, 17 Jun 2013 08:44:52 +0200
Simone Caronni wrote:
> On 17 June 2013 03:13, Sérgio Basto wrote:
>
> > we had updated dpkg some major versions sine bug opened, how I know
> > if dpkg is now ready for aarch64 ?
> >
>
> I've discovered you can trigger builds for the ARM Koji instance with
> your account:
>
> koji --server=http://arm.koji.fedoraproject.org/kojihub build
> --scratch f19 dpkg.src.rpm
the fedora-packager package provides wrappers for the koji command for
all secondary architectures in Fedora in the form ${arch}-koji, where
arch can be arm, ppc and s390, so you can use
arm-koji build --scratch f19 your.src.rpm
Dan
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276
On 17 June 2013 03:13, Sérgio Basto wrote: > we had updated dpkg some major versions sine bug opened, how I know if > dpkg is now ready for aarch64 ? > I've discovered you can trigger builds for the ARM Koji instance with your account: koji --server=http://arm.koji.fedoraproject.org/kojihub build --scratch f19 dpkg.src.rpm Regards, --Simone -- You cannot discover new oceans unless you have the courage to lose sight of the shore (R. W. Emerson). http://xkcd.com/229/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276
Hi, I'm trying follow this (aarch64 support) but https://bugzilla.redhat.com/show_bug.cgi?id=922257#c1 "could/should be closed now, as this is done automatically from % configure", so no need update it anymore ? we had updated dpkg some major versions sine bug opened, how I know if dpkg is now ready for aarch64 ? Thanks, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: aarch64 bugs
On Sun, Mar 24, 2013 at 8:46 AM, Roberto Ragusa wrote: > On 03/23/2013 04:12 PM, Peter Robinson wrote: >> On Sat, Mar 23, 2013 at 2:53 PM, Bruno Wolff III wrote: > >> Eventually there will be hardware available but I'm not sure when >> that will be as there's not been anything publicly announced. >> Ultimately we're very much in the prep stages for a mass rebuild of >> Fedora for aarch64 when we eventually get actual HW, at the moment a >> build of something like gcc takes days. > > Days to build gcc? Wow. The current emulated HW runs at around 200mhz or something horribly slow. > OpenSUSE managed to build the entire distribution without any hardware. > Definitely not a trivial task. > > http://lists.linaro.org/pipermail/cross-distro/2013-March/000425.html OpenSUSE don't do native compiles with OBS. They use distcc or something like that to cross compile some of their architectures. It was developed as part of the Intel/Nokia MeeGo use of OBS. Fedora has a requirement of native builds. Stage1/2 of a Fedora platform bring up can be cross compiled but we're now into stage 3 which is native builds. Fedora also has over double the amount of source packages to OpenSUSE and we're working with upstream to get fixes upstream (both Fedora mainline upstream and projects upstream) as we go rather than forking and fixing later all of which ends up being more time consuming in the short term but less overall. Peter [1] http://fedoraproject.org/wiki/Architectures/ARM/AArch64 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: aarch64 bugs
On 03/23/2013 04:12 PM, Peter Robinson wrote: > On Sat, Mar 23, 2013 at 2:53 PM, Bruno Wolff III wrote: > Eventually there will be hardware available but I'm not sure when > that will be as there's not been anything publicly announced. > Ultimately we're very much in the prep stages for a mass rebuild of > Fedora for aarch64 when we eventually get actual HW, at the moment a > build of something like gcc takes days. Days to build gcc? Wow. OpenSUSE managed to build the entire distribution without any hardware. Definitely not a trivial task. http://lists.linaro.org/pipermail/cross-distro/2013-March/000425.html -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: aarch64 bugs
On 03/23/2013 06:12 PM, Jonathan Masters wrote: > ARM deprecate endian switching in ARMv7+ application (server) profiles. It is > possible to do big endian but with external hardware assistance. We will be > an LP64 little endian architecture with a relaxed memory model. Ping me with > questions. I will run a tutorial session and pull in the developing subject experts on AArch64 to assist in a few weeks, once we have the updated filesystem available and perhaps some additional information to share (certain timing-related aspects of hardware availability and so on are non-public and that is not a decision that we have direct control over). Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: aarch64 bugs
On 03/23/2013 10:14 AM, Jeffrey Ollie wrote: > Yesterday a bunch of bugs were opened up regarding aarch64 support in > some packages. I'd like to do my part in fixing these, but is there a > way to actually run test builds? As Peter says, there will be an updated F19-ish filesystem image soon. The current (now deprecated as of the end of the week) filesystem is available as a git repository: https://fedoraproject.org/wiki/Architectures/ARM/AArch64#Git_Based_Rootfs_Workflow (in particular, you can use the NFS option to boot with busybox, or you can make your own disk image - increase the 10GB size though to 12GB+) Mark Salter just got systemd finally booting at the end of the week, and the docs are about to be updated as we move into the next stage of the bootstrap (and are about to be able to conduct distributed builds). Further information will be sent out, but in the coming days. > I know that there's ARM support in > the works, but I haven't really kept up with the details. Please feel free to ping me with architecture specific questions. Meanwhile, bear with us, as we have updated stuff landing soon. Further, on the subject of hardware what I'll say is "watch this space". You won't be waiting all that long now. Fedora has been well taken care of in the planning to get AArch64 support completed. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: aarch64 bugs
We are doing some enablement work with Linaro (Linaro Enterprise Group) that
includes both KVM and Xen, and libvirt. Let's sync up next week Rich.
Sent from my Android phone using TouchDown (www.nitrodesk.com)
-Original Message-
From: Richard W.M. Jones [rjo...@redhat.com]
Received: Saturday, 23 Mar 2013, 17:37
To: Development discussions related to Fedora [devel@lists.fedoraproject.org]
Subject: Re: aarch64 bugs
On Sat, Mar 23, 2013 at 07:35:08PM +, Peter Robinson wrote:
> On Sat, Mar 23, 2013 at 7:32 PM, Richard W.M. Jones wrote:
> > Do you know what processor features ('flags') will be available in the
> > first shipping hardware?
>
> Nope, although I will find out, what particular bits do you need to
> know, or just all of them?
>From the point of view of porting Fedora software (eg. OCaml):
anything that could affect code generation: vector instructions,
concurrency primitives, and that sort of thing.
With my virtualization hat on: hardware virt capabilities.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: aarch64 bugs
ARM deprecate endian switching in ARMv7+ application (server) profiles. It is
possible to do big endian but with external hardware assistance. We will be an
LP64 little endian architecture with a relaxed memory model. Ping me with
questions.
Sent from my Android phone using TouchDown (www.nitrodesk.com)
-Original Message-
From: Peter Robinson [pbrobin...@gmail.com]
Received: Saturday, 23 Mar 2013, 15:35
To: Development discussions related to Fedora [devel@lists.fedoraproject.org]
Subject: Re: aarch64 bugs
On Sat, Mar 23, 2013 at 7:32 PM, Richard W.M. Jones wrote:
> On Sat, Mar 23, 2013 at 03:12:13PM +, Peter Robinson wrote:
>> On Sat, Mar 23, 2013 at 2:53 PM, Bruno Wolff III wrote:
>> > On Sat, Mar 23, 2013 at 09:14:52 -0500,
>> > Jeffrey Ollie wrote:
>> >>
>> >> Yesterday a bunch of bugs were opened up regarding aarch64 support in
>> >> some packages. I'd like to do my part in fixing these, but is there a
>> >> way to actually run test builds? I know that there's ARM support in
>> >> the works, but I haven't really kept up with the details.
>> >
>> >
>> > I was going to ask the same question.
>>
>> At the moment there is not. We're working on the platform bring up and
>> in the coming weeks there will an initial Fedora 19 based image
>> released that will be able to run on the free ARM Foundation model
>> [1]. Eventually there will be hardware available but I'm not sure when
>> that will be as there's not been anything publicly announced.
>> Ultimately we're very much in the prep stages for a mass rebuild of
>> Fedora for aarch64 when we eventually get actual HW, at the moment a
>> build of something like gcc takes days.
>>
>> Peter
>>
>> [1] https://fedoraproject.org/wiki/Architectures/ARM/AArch64/FoundationModel
>
> Peter,
>
> I spent a few minutes searching for details of AArch64, such as its
> endianness and what processor features (ie. 'flags' in /proc/cpuinfo)
> it has.
>
> It seems the endianness is switchable like MIPS, which I guess is a
> good thing. What endianness will Fedora use? What about other Linux
> distros?
We will be using little endian. All ARM processors have the ability to
switch endianness.
> Do you know what processor features ('flags') will be available in the
> first shipping hardware?
Nope, although I will find out, what particular bits do you need to
know, or just all of them?
Peter
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: aarch64 bugs
On Sat, Mar 23, 2013 at 07:35:08PM +, Peter Robinson wrote:
> On Sat, Mar 23, 2013 at 7:32 PM, Richard W.M. Jones wrote:
> > Do you know what processor features ('flags') will be available in the
> > first shipping hardware?
>
> Nope, although I will find out, what particular bits do you need to
> know, or just all of them?
From the point of view of porting Fedora software (eg. OCaml):
anything that could affect code generation: vector instructions,
concurrency primitives, and that sort of thing.
With my virtualization hat on: hardware virt capabilities.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: aarch64 bugs
On Sat, Mar 23, 2013 at 7:32 PM, Richard W.M. Jones wrote:
> On Sat, Mar 23, 2013 at 03:12:13PM +, Peter Robinson wrote:
>> On Sat, Mar 23, 2013 at 2:53 PM, Bruno Wolff III wrote:
>> > On Sat, Mar 23, 2013 at 09:14:52 -0500,
>> > Jeffrey Ollie wrote:
>> >>
>> >> Yesterday a bunch of bugs were opened up regarding aarch64 support in
>> >> some packages. I'd like to do my part in fixing these, but is there a
>> >> way to actually run test builds? I know that there's ARM support in
>> >> the works, but I haven't really kept up with the details.
>> >
>> >
>> > I was going to ask the same question.
>>
>> At the moment there is not. We're working on the platform bring up and
>> in the coming weeks there will an initial Fedora 19 based image
>> released that will be able to run on the free ARM Foundation model
>> [1]. Eventually there will be hardware available but I'm not sure when
>> that will be as there's not been anything publicly announced.
>> Ultimately we're very much in the prep stages for a mass rebuild of
>> Fedora for aarch64 when we eventually get actual HW, at the moment a
>> build of something like gcc takes days.
>>
>> Peter
>>
>> [1] https://fedoraproject.org/wiki/Architectures/ARM/AArch64/FoundationModel
>
> Peter,
>
> I spent a few minutes searching for details of AArch64, such as its
> endianness and what processor features (ie. 'flags' in /proc/cpuinfo)
> it has.
>
> It seems the endianness is switchable like MIPS, which I guess is a
> good thing. What endianness will Fedora use? What about other Linux
> distros?
We will be using little endian. All ARM processors have the ability to
switch endianness.
> Do you know what processor features ('flags') will be available in the
> first shipping hardware?
Nope, although I will find out, what particular bits do you need to
know, or just all of them?
Peter
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: aarch64 bugs
On Sat, Mar 23, 2013 at 03:12:13PM +, Peter Robinson wrote:
> On Sat, Mar 23, 2013 at 2:53 PM, Bruno Wolff III wrote:
> > On Sat, Mar 23, 2013 at 09:14:52 -0500,
> > Jeffrey Ollie wrote:
> >>
> >> Yesterday a bunch of bugs were opened up regarding aarch64 support in
> >> some packages. I'd like to do my part in fixing these, but is there a
> >> way to actually run test builds? I know that there's ARM support in
> >> the works, but I haven't really kept up with the details.
> >
> >
> > I was going to ask the same question.
>
> At the moment there is not. We're working on the platform bring up and
> in the coming weeks there will an initial Fedora 19 based image
> released that will be able to run on the free ARM Foundation model
> [1]. Eventually there will be hardware available but I'm not sure when
> that will be as there's not been anything publicly announced.
> Ultimately we're very much in the prep stages for a mass rebuild of
> Fedora for aarch64 when we eventually get actual HW, at the moment a
> build of something like gcc takes days.
>
> Peter
>
> [1] https://fedoraproject.org/wiki/Architectures/ARM/AArch64/FoundationModel
Peter,
I spent a few minutes searching for details of AArch64, such as its
endianness and what processor features (ie. 'flags' in /proc/cpuinfo)
it has.
It seems the endianness is switchable like MIPS, which I guess is a
good thing. What endianness will Fedora use? What about other Linux
distros?
Do you know what processor features ('flags') will be available in the
first shipping hardware?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: aarch64 bugs
On Sat, Mar 23, 2013 at 2:53 PM, Bruno Wolff III wrote: > On Sat, Mar 23, 2013 at 09:14:52 -0500, > Jeffrey Ollie wrote: >> >> Yesterday a bunch of bugs were opened up regarding aarch64 support in >> some packages. I'd like to do my part in fixing these, but is there a >> way to actually run test builds? I know that there's ARM support in >> the works, but I haven't really kept up with the details. > > > I was going to ask the same question. At the moment there is not. We're working on the platform bring up and in the coming weeks there will an initial Fedora 19 based image released that will be able to run on the free ARM Foundation model [1]. Eventually there will be hardware available but I'm not sure when that will be as there's not been anything publicly announced. Ultimately we're very much in the prep stages for a mass rebuild of Fedora for aarch64 when we eventually get actual HW, at the moment a build of something like gcc takes days. Peter [1] https://fedoraproject.org/wiki/Architectures/ARM/AArch64/FoundationModel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: aarch64 bugs
On Sat, Mar 23, 2013 at 09:14:52 -0500, Jeffrey Ollie wrote: Yesterday a bunch of bugs were opened up regarding aarch64 support in some packages. I'd like to do my part in fixing these, but is there a way to actually run test builds? I know that there's ARM support in the works, but I haven't really kept up with the details. I was going to ask the same question. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
aarch64 bugs
Yesterday a bunch of bugs were opened up regarding aarch64 support in some packages. I'd like to do my part in fixing these, but is there a way to actually run test builds? I know that there's ARM support in the works, but I haven't really kept up with the details. -- Jeff Ollie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
