9:40 a.m.
I'd like to talk about the ground rules that Fedora/RISC-V should obey
for making '%ifarch riscv64'-specific changes to spec files in dist-git.
I'm aware that no one wants invasive changes to be made (least of all
me) for the sake of an architecture that isn't generally available and
isn't even a secondary arch.
Also, we are working on persuading the RISC-V community that they
really must be more proactive in upstreaming their changes, something
they have not been good about so far. For this reason, Fedora/RISC-V
will try to get changes to the following packages upstream and won't
even consider making changes in Fedora (IOW we'll be shipping forks of
these packages for a while):
- kernel
- glibc
- binutils
- gcc
So far I have only pushed a single change to Fedora dist-git which was
related to RISC-V:
http://pkgs.fedoraproject.org/cgit/rpms/lua.git/commit/
My aim, once we have a pure RPM-built "stage4", is to start auto-
building all @Core packages as they are built in Koji (either using
koji-shadow, or similar). Many packages will just work. For others
it'll be a matter of fixing something and sending it upstream. It's
the ones where we have to make changes to the spec file to get them to
build which concern me. Ideally, if the changes are non-invasive, we
could add them to Fedora which would reduce the differences between
Fedora/RISC-V and Fedora.
The question is what things should we be doing or should we not be
doing, especially w.r.t Fedora spec files in dist-git?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
11:41 a.m.
On 09/11/2016 04:40 PM, Richard W.M. Jones wrote:
Also, we are working on persuading the RISC-V community that they
really must be more proactive in upstreaming their changes, something
they have not been good about so far. For this reason, Fedora/RISC-V
will try to get changes to the following packages upstream and won't
even consider making changes in Fedora (IOW we'll be shipping forks of
these packages for a while):
The “IOW“ part does not really make sense to me.
Do you plan to have a special branch in dist-git of these packages?
Florian
12:31 p.m.
On Sun, Sep 11, 2016 at 06:41:27PM +0200, Florian Weimer wrote:
On 09/11/2016 04:40 PM, Richard W.M. Jones wrote:
>Also, we are working on persuading the RISC-V community that they
>really must be more proactive in upstreaming their changes, something
>they have not been good about so far. For this reason, Fedora/RISC-V
>will try to get changes to the following packages upstream and won't
>even consider making changes in Fedora (IOW we'll be shipping forks of
>these packages for a while):
[For glibc, binutils, gcc, kernel only]
The “IOW“ part does not really make sense to me.
I mean that currently the changes to those packages are very invasive
and also involve substantial non-upstream patchsets.
I want those patchsets to go upstream first, and for the other
differences in the spec file to be substantially reduced or eliminated.
Do you plan to have a special branch in dist-git of these packages?
The details aren't worked out, but I imagine completely separate spec
files + patches for those packages, stored outside Fedora, and
infrequently rebased against Rawhide. A private-* branch in Fedora
dist-git would also work, but I understand that Fedora doesn't want to
give any "resources" to this architecture at the moment.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
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
2:06 a.m.
On 09/11/2016 07:31 PM, Richard W.M. Jones wrote:
On Sun, Sep 11, 2016 at 06:41:27PM +0200, Florian Weimer wrote:
> On 09/11/2016 04:40 PM, Richard W.M. Jones wrote:
>> Also, we are working on persuading the RISC-V community that they
>> really must be more proactive in upstreaming their changes, something
>> they have not been good about so far. For this reason, Fedora/RISC-V
>> will try to get changes to the following packages upstream and won't
>> even consider making changes in Fedora (IOW we'll be shipping forks of
>> these packages for a while):
[For glibc, binutils, gcc, kernel only]
> The “IOW“ part does not really make sense to me.
I mean that currently the changes to those packages are very invasive
and also involve substantial non-upstream patchsets.
I want those patchsets to go upstream first, and for the other
differences in the spec file to be substantially reduced or eliminated.
I had a brief look at the glibc patches. Apparently, off_t and time_t
are 32-bit. For a new architecture, that's quite strange. How fixed is
the ABI?
Florian
1:48 p.m.
On Mon, Sep 12, 2016 at 09:06:59AM +0200, Florian Weimer wrote:
On 09/11/2016 07:31 PM, Richard W.M. Jones wrote:
>On Sun, Sep 11, 2016 at 06:41:27PM +0200, Florian Weimer wrote:
>>On 09/11/2016 04:40 PM, Richard W.M. Jones wrote:
>>>Also, we are working on persuading the RISC-V community that they
>>>really must be more proactive in upstreaming their changes, something
>>>they have not been good about so far. For this reason, Fedora/RISC-V
>>>will try to get changes to the following packages upstream and won't
>>>even consider making changes in Fedora (IOW we'll be shipping forks of
>>>these packages for a while):
>
>[For glibc, binutils, gcc, kernel only]
>
>>The “IOW“ part does not really make sense to me.
>
>I mean that currently the changes to those packages are very invasive
>and also involve substantial non-upstream patchsets.
>
>I want those patchsets to go upstream first, and for the other
>differences in the spec file to be substantially reduced or eliminated.
I had a brief look at the glibc patches. Apparently, off_t and
time_t are 32-bit. For a new architecture, that's quite strange.
I'll just note that the new architecture includes 32, 64 and 128-bit
variants. We are only targetting the 64 bit variant. Whether that
means it's correct to have off_t and time_t be 32 bit, I don't know.
How fixed is the ABI?
I'm hoping quite fixed because I don't want to re-bootstrap
everything, but OTOH nothing is upstream.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
1:55 p.m.
On Mon, Sep 12, 2016 at 07:48:31PM +0100, Richard W.M. Jones wrote:
On Mon, Sep 12, 2016 at 09:06:59AM +0200, Florian Weimer wrote:
> I had a brief look at the glibc patches. Apparently, off_t and
> time_t are 32-bit. For a new architecture, that's quite strange.
How do you determine this?
I wrote a simple program which prints sizeof (off_t) and sizeof (time_t)
inside the RISC-V environment. I *didn't* define
`-D_FILE_OFFSET_BITS=64' when compiling the program. Both values are
printed as 8 (bytes). So it seems we're OK?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
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
4:32 a.m.
On 09/12/2016 08:55 PM, Richard W.M. Jones wrote:
On Mon, Sep 12, 2016 at 07:48:31PM +0100, Richard W.M. Jones wrote:
> On Mon, Sep 12, 2016 at 09:06:59AM +0200, Florian Weimer wrote:
>> I had a brief look at the glibc patches. Apparently, off_t and
>> time_t are 32-bit. For a new architecture, that's quite strange.
How do you determine this?
I looked at the patch.
I wrote a simple program which prints sizeof (off_t) and sizeof
(time_t)
inside the RISC-V environment. I *didn't* define
`-D_FILE_OFFSET_BITS=64' when compiling the program. Both values are
printed as 8 (bytes). So it seems we're OK?
Yes, for 64-bit. But the 32-bit parts do not look acceptable as-is.
If you only want the 64-bit architecture, then getting the author to
submit only the 64-bit parts first to glibc upstream would be the
prudent thing to do. (This has to come from the patch author, and the
author has to assign copyright to the FSF.)
Florian
6:52 a.m.
On Tue, Sep 13, 2016 at 11:32:26AM +0200, Florian Weimer wrote:
On 09/12/2016 08:55 PM, Richard W.M. Jones wrote:
>On Mon, Sep 12, 2016 at 07:48:31PM +0100, Richard W.M. Jones wrote:
>>On Mon, Sep 12, 2016 at 09:06:59AM +0200, Florian Weimer wrote:
>>>I had a brief look at the glibc patches. Apparently, off_t and
>>>time_t are 32-bit. For a new architecture, that's quite strange.
>
>How do you determine this?
I looked at the patch.
>I wrote a simple program which prints sizeof (off_t) and sizeof (time_t)
>inside the RISC-V environment. I *didn't* define
>`-D_FILE_OFFSET_BITS=64' when compiling the program. Both values are
>printed as 8 (bytes). So it seems we're OK?
Yes, for 64-bit. But the 32-bit parts do not look acceptable as-is.
Fair enough. For Fedora we are only building for 64 bit[1]. There
aren't even multilib 32 bit libs. (I'm not saying someone couldn't
come along and add that later, but initially we're not considering it)
The reasons for this are:
- There is no legacy of 32 bit code to support.
- By the time this is available, people will care even less about 32 bit.
- I've even talked to embedded manufacturers who intend to jump
straight to RV64 (which surprised me because RV32 is designed for
embedded uses).
If you only want the 64-bit architecture, then getting the author to
submit only the 64-bit parts first to glibc upstream would be the
prudent thing to do. (This has to come from the patch author, and
the author has to assign copyright to the FSF.)
I've been telling everyone who will listen that they should get their
changes upstream.
Rich.
[1] Specifically for "RV64G" = "RV64IMAFD" = RISC-V, 64 bit with
Integer, Multiplication/division, Atomics, single Floats, and Double
floats. For more info, see section 10.4 in this document:
https://people.eecs.berkeley.edu/~krste/papers/riscv-spec-2.0.pdf
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
2:52 p.m.
On Tue, 2016-09-13 at 12:52 +0100, Richard W.M. Jones wrote:
On Tue, Sep 13, 2016 at 11:32:26AM +0200, Florian Weimer wrote:
>
> On 09/12/2016 08:55 PM, Richard W.M. Jones wrote:
> >
> > On Mon, Sep 12, 2016 at 07:48:31PM +0100, Richard W.M. Jones
> > wrote:
> > >
> > > On Mon, Sep 12, 2016 at 09:06:59AM +0200, Florian Weimer wrote:
> > > >
> > > > I had a brief look at the glibc patches. Apparently, off_t
> > > > and
> > > > time_t are 32-bit. For a new architecture, that's quite
> > > > strange.
> >
> > How do you determine this?
>
> I looked at the patch.
>
> >
> > I wrote a simple program which prints sizeof (off_t) and sizeof
> > (time_t)
> > inside the RISC-V environment. I *didn't* define
> > `-D_FILE_OFFSET_BITS=64' when compiling the program. Both values
> > are
> > printed as 8 (bytes). So it seems we're OK?
>
> Yes, for 64-bit. But the 32-bit parts do not look acceptable as-
> is.
Fair enough. For Fedora we are only building for 64 bit[1]. There
aren't even multilib 32 bit libs. (I'm not saying someone couldn't
come along and add that later, but initially we're not considering
it)
The reasons for this are:
- There is no legacy of 32 bit code to support.
- By the time this is available, people will care even less about 32
bit.
- I've even talked to embedded manufacturers who intend to jump
straight to RV64 (which surprised me because RV32 is designed for
embedded uses).
Interesting! I'd like some more details on this; embedded
systems range
from low end (16 bit or 32 bit cpu, 10's of KB of memory, hundreds of
KB of storage) to fairly serious systems.
>
> >
> > If you only want the 64-bit architecture, then getting the author
> > to
> > submit only the 64-bit parts first to glibc upstream would be the
> > prudent thing to do. (This has to come from the patch author, and
> > the author has to assign copyright to the FSF.)
>
> I've been telling everyone who will listen that they should get their
> changes upstream.
>
> Rich.
>
> [1] Specifically for "RV64G" = "RV64IMAFD" = RISC-V, 64 bit with
> Integer, Multiplication/division, Atomics, single Floats, and Double
> floats. For more info, see section 10.4 in this document:
> https://people.eecs.berkeley.edu/~krste/papers/riscv-spec-2.0.pdf
>
11:52 a.m.
On Sun, 11 Sep 2016 15:40:39 +0100
"Richard W.M. Jones" <rjones(a)redhat.com> wrote:
I'd like to talk about the ground rules that Fedora/RISC-V should
obey
for making '%ifarch riscv64'-specific changes to spec files in
dist-git.
I'm aware that no one wants invasive changes to be made (least of all
me) for the sake of an architecture that isn't generally available and
isn't even a secondary arch.
Also, we are working on persuading the RISC-V community that they
really must be more proactive in upstreaming their changes, something
they have not been good about so far. For this reason, Fedora/RISC-V
will try to get changes to the following packages upstream and won't
even consider making changes in Fedora (IOW we'll be shipping forks of
these packages for a while):
- kernel
- glibc
- binutils
- gcc
So far I have only pushed a single change to Fedora dist-git which was
related to RISC-V:
http://pkgs.fedoraproject.org/cgit/rpms/lua.git/commit/
My aim, once we have a pure RPM-built "stage4", is to start auto-
building all @Core packages as they are built in Koji (either using
koji-shadow, or similar). Many packages will just work. For others
With koji-shadow you would need ~3k packages (of all kinds) to fulfil
the complete minimal buildroots. But maybe a simple script that listens
on Fedora message bus and starts a new riscv build when a rawhide build
for a whitelisted package appears could do the job.
it'll be a matter of fixing something and sending it upstream.
It's
the ones where we have to make changes to the spec file to get them to
build which concern me. Ideally, if the changes are non-invasive, we
could add them to Fedora which would reduce the differences between
Fedora/RISC-V and Fedora.
The question is what things should we be doing or should we not be
doing, especially w.r.t Fedora spec files in dist-git?
It reminds me we are still waiting for pull-requests support in
dist-git to allow easier contributions.
Dan
9:10 a.m.
On Sun, 11 Sep 2016 18:52:10 +0200
Dan Horák <dan(a)danny.cz> wrote:
...snip...
It reminds me we are still waiting for pull-requests support in
dist-git to allow easier contributions.
FYI, we have a test setup in staging:
http://pkgs.stg.fedoraproject.org/pagure/
But there's some outstanding issues we need to figure out/address
before it can go live anywhere. Further details in #fedora-apps or
fedora-infrastructure list.
( see this thread:
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedora...
)
kevin
12:15 p.m.
On Sunday, 11 September 2016 at 16:40, Richard W.M. Jones wrote:
I'd like to talk about the ground rules that Fedora/RISC-V should
obey
for making '%ifarch riscv64'-specific changes to spec files in dist-git.
I'm aware that no one wants invasive changes to be made (least of all
me) for the sake of an architecture that isn't generally available and
isn't even a secondary arch.
[...]
My aim, once we have a pure RPM-built "stage4", is to start
auto-
building all @Core packages as they are built in Koji (either using
koji-shadow, or similar). Many packages will just work. For others
it'll be a matter of fixing something and sending it upstream. It's
the ones where we have to make changes to the spec file to get them to
build which concern me. Ideally, if the changes are non-invasive, we
could add them to Fedora which would reduce the differences between
Fedora/RISC-V and Fedora.
The question is what things should we be doing or should we not be
doing, especially w.r.t Fedora spec files in dist-git?
IMHO, if the change is self-contained, follows the conventions
of neighbouring code and doesn't break anything else then just
notify the maintainer, give them a day or two to respond (especially
if it's the weekend) and just go ahead and commit. At least, that's
what you can do with the packages where I'm the POC.
If patching of the upstream code is required, then please add a
reference to a ticket filed with upstream, per our Packaging Guidelines.
Regards,
Dominik
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
12:26 a.m.
Hi,
On 11-09-16 19:15, Dominik 'Rathann' Mierzejewski wrote:
On Sunday, 11 September 2016 at 16:40, Richard W.M. Jones wrote:
> I'd like to talk about the ground rules that Fedora/RISC-V should obey
> for making '%ifarch riscv64'-specific changes to spec files in dist-git.
>
> I'm aware that no one wants invasive changes to be made (least of all
> me) for the sake of an architecture that isn't generally available and
> isn't even a secondary arch.
[...]
> My aim, once we have a pure RPM-built "stage4", is to start auto-
> building all @Core packages as they are built in Koji (either using
> koji-shadow, or similar). Many packages will just work. For others
> it'll be a matter of fixing something and sending it upstream. It's
> the ones where we have to make changes to the spec file to get them to
> build which concern me. Ideally, if the changes are non-invasive, we
> could add them to Fedora which would reduce the differences between
> Fedora/RISC-V and Fedora.
>
> The question is what things should we be doing or should we not be
> doing, especially w.r.t Fedora spec files in dist-git?
IMHO, if the change is self-contained, follows the conventions
of neighbouring code and doesn't break anything else then just
notify the maintainer, give them a day or two to respond (especially
if it's the weekend) and just go ahead and commit. At least, that's
what you can do with the packages where I'm the POC.
If patching of the upstream code is required, then please add a
reference to a ticket filed with upstream, per our Packaging Guidelines.
Yes that sounds just about right :) +1
Regards,
Hans
8:19 a.m.
On Sunday, September 11, 2016 7:15:45 PM CDT Dominik 'Rathann' Mierzejewski
wrote:
On Sunday, 11 September 2016 at 16:40, Richard W.M. Jones wrote:
> I'd like to talk about the ground rules that Fedora/RISC-V should obey
> for making '%ifarch riscv64'-specific changes to spec files in dist-git.
>
> I'm aware that no one wants invasive changes to be made (least of all
> me) for the sake of an architecture that isn't generally available and
> isn't even a secondary arch.
[...]
> My aim, once we have a pure RPM-built "stage4", is to start auto-
> building all @Core packages as they are built in Koji (either using
> koji-shadow, or similar). Many packages will just work. For others
> it'll be a matter of fixing something and sending it upstream. It's
> the ones where we have to make changes to the spec file to get them to
> build which concern me. Ideally, if the changes are non-invasive, we
> could add them to Fedora which would reduce the differences between
> Fedora/RISC-V and Fedora.
>
> The question is what things should we be doing or should we not be
> doing, especially w.r.t Fedora spec files in dist-git?
IMHO, if the change is self-contained, follows the conventions
of neighbouring code and doesn't break anything else then just
notify the maintainer, give them a day or two to respond (especially
if it's the weekend) and just go ahead and commit. At least, that's
what you can do with the packages where I'm the POC.
If patching of the upstream code is required, then please add a
reference to a ticket filed with upstream, per our Packaging Guidelines.
Regards,
Dominik
The one thing I would add is do not use %ifarch to selectively apply
patches.
The existing guildelines should be followed. You really need to get patches
upstream and spec changes in, carrying forks of packages is frought with pain
and errors. it was done for some time on arm initially and it took a long time
to fix things and get it right.
Dennis
1:49 p.m.
On Mon, Sep 12, 2016 at 08:19:19AM -0500, Dennis Gilmore wrote:
On Sunday, September 11, 2016 7:15:45 PM CDT Dominik
'Rathann' Mierzejewski
wrote:
> On Sunday, 11 September 2016 at 16:40, Richard W.M. Jones wrote:
> > I'd like to talk about the ground rules that Fedora/RISC-V should obey
> > for making '%ifarch riscv64'-specific changes to spec files in
dist-git.
> >
> > I'm aware that no one wants invasive changes to be made (least of all
> > me) for the sake of an architecture that isn't generally available and
> > isn't even a secondary arch.
>
> [...]
>
> > My aim, once we have a pure RPM-built "stage4", is to start auto-
> > building all @Core packages as they are built in Koji (either using
> > koji-shadow, or similar). Many packages will just work. For others
> > it'll be a matter of fixing something and sending it upstream. It's
> > the ones where we have to make changes to the spec file to get them to
> > build which concern me. Ideally, if the changes are non-invasive, we
> > could add them to Fedora which would reduce the differences between
> > Fedora/RISC-V and Fedora.
> >
> > The question is what things should we be doing or should we not be
> > doing, especially w.r.t Fedora spec files in dist-git?
>
> IMHO, if the change is self-contained, follows the conventions
> of neighbouring code and doesn't break anything else then just
> notify the maintainer, give them a day or two to respond (especially
> if it's the weekend) and just go ahead and commit. At least, that's
> what you can do with the packages where I'm the POC.
>
> If patching of the upstream code is required, then please add a
> reference to a ticket filed with upstream, per our Packaging Guidelines.
>
> Regards,
> Dominik
The one thing I would add is do not use %ifarch to selectively apply
patches. The existing guildelines should be followed. You really
need to get patches upstream and spec changes in, carrying forks of
packages is frought with pain and errors. it was done for some time
on arm initially and it took a long time to fix things and get it
right.
No argument with that.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
2776
days inactive
2778
days old
14 comments
8 participants
participants (8)
-
Dan Horák -
Dennis Gilmore -
Dominik 'Rathann' Mierzejewski -
Florian Weimer -
Hans de Goede -
Kevin Fenzi -
Richard W.M. Jones -
Russell Doty