Re: Resurrecting Fedora SPARC
by Peter Robinson
> Including the fedora release engineering list and Peter Robinson who is the
> lead for secondary arches.
>
> Thanks.
I suggest you subscribe to the rel-eng list so you post there too.
> Given how long it has been since there was a Fedora SPARC port I think the
> best bet at this point will be bootstrapping the arch. We have scripts
> available for doing so from the bringups of armv7hl, aarch64 and ppc64le. I
> would strongly suggest that 32 bit support is dropped on the floor and only
> sparc64 is done. we have removed 32 bit from s390, ppc and not done it for
> aarch64. I am looking at ways to remove it for x86 arches.
>
> What we did in LFS was to bootstrap in 64-bit only and then later we
> added multilib support in GCC and a glibc.sparcv9 so people could build
> and run 32-bit programs. We changed the .spec files and other scripts
> (including yum) so sparcv9 (the 32bit one) is a subarch of sparc64.
>
> In SPARC it is important to keep 32-bit capabilities, as a big amount of
> programs out there have not been ported to 64-bit.
By "big ammount of programs" I presume you mean proprietary as opposed
to open source programs that can generally just be recompiled with
minor changes (I've done a number of bootstraps), if it's the later I
suggest spending time fixing those. We're actively moving to deprecate
multilib from Fedora so that basically means that any new boot straps
should not be using it. Basically you're going to have to do a LOT of
convincing me that it's needed! I'm not convinced.
> Where can we find these bootstrap scripts?
I think there's another package in the wiki, I don't have time to dig
atm, this was the overview that was done for ARMv7 hfp.
https://fedoraproject.org/wiki/Architectures/ARM/Fedora15_HardFP_Bootstrap
> We do not have as much documentation as there could be in bringing things up.
> There will need to be a koji hub setup, along with builders. I think I have
> actually closed the sparc list, so it would need to be reopened if I
> did.
>
> Yes, the list is closed, I tried to subscribe but the mailman page is
> missing.
>
> You will need to get fas[1] accounts as well as bugzilla[2] all the fedora
> packaging guidelines[3] apply. any patches needed should go upstream. kernel
> wise we follow very closely upstream.
>
> I made a fas account already (jemarch) and I already had a bugzilla
> account at RH.
>
> I requested access to the fedora-sparc group, but seems like I need to
> be "sponsorized". That group is described as a cvs group, so I guess
> that group will give us access to some VCS holding the .spec and source
> tarballs?
Not exactly, that's a group for access to all packages for arch
maintainers, I'm not sure we're to that stage in the process as yet.
If it's packaging of sparc specific packages they should be handled as
part of the standard packaging process.
> Personally I no longer have any sparc hardware at all, and given my workload
> am unable to spend time on the port, however I am happy to provide guideance
> and direction. You can find our architecture support definition and
> architecture info from [4] it is an area that does need some love.
>
> Thank you! We will probably pester you with all kind of naive questions
There's also a "secondary arch" list that you might want to join.
https://lists.fedoraproject.org/admin/lists/secondary.lists.fedoraproject...
7 years, 11 months
Re: Resurrecting Fedora SPARC
by Dennis Gilmore
On Wednesday, May 18, 2016 7:11:50 PM CDT Jose E. Marchesi wrote:
> Hi Dennis, Tom, Mark.
>
> In short: Philip "Bryce" Copeland and myself want to resurrect the
> Fedora SPARC port and turn it into a multilib 64-bit sparc distro
> supporting the latest SPARC hardware.
>
> We will be using what we published in Oracle's Linux for SPARC [1] but
> we will be targetting the latest Fedora.
>
> How can we start?
>
> Should we reuse the existing sparc port, or create a new sparc64 port?
>
> I am not familiar at all with the Fedora project. Should we create
> accounts somewhere? I guess we should subscribe to
> sparc@lists.fedoraproject.org...
>
> Are there other lists/resources/guidelines/etc we should be aware of?
>
> Thanks!
>
> [1] https://oss.oracle.com/projects/linux-sparc/
Including the fedora release engineering list and Peter Robinson who is the
lead for secondary arches.
Given how long it has been since there was a Fedora SPARC port I think the
best bet at this point will be bootstrapping the arch. We have scripts
available for doing so from the bringups of armv7hl, aarch64 and ppc64le. I
would strongly suggest that 32 bit support is dropped on the floor and only
sparc64 is done. we have removed 32 bit from s390, ppc and not done it for
aarch64. I am looking at ways to remove it for x86 arches.
We do not have as much documentation as there could be in bringing things up.
There will need to be a koji hub setup, along with builders. I think I have
actually closed the sparc list, so it would need to be reopened if I did. You
will need to get fas[1] accounts as well as bugzilla[2] all the fedora
packaging guidelines[3] apply. any patches needed should go upstream. kernel
wise we follow very closely upstream.
Personally I no longer have any sparc hardware at all, and given my workload
am unable to spend time on the port, however I am happy to provide guideance
and direction. You can find our architecture support definition and
architecture info from [4] it is an area that does need some love.
Dennis
[1] https://admin.fedoraproject.org/accounts/
[2] https://bugzilla.redhat.com/
[3] https://fedoraproject.org/wiki/Packaging:Guidelines
[4] https://fedoraproject.org/wiki/Architectures
7 years, 11 months
#6418: [RFE] include version information in Atomic Host two week
release emails
by Fedora Release Engineering
#6418: [RFE] include version information in Atomic Host two week release emails
-----------------------------+------------------------
Reporter: miabbott | Owner: rel-eng@…
Type: enhancement | Status: new
Milestone: Fedora 24 Alpha | Component: koji
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
It can be difficult to determine which version of Atomic Host was released
as part of each two week release. Currently, the email announcing the two
week release just states that a release is available and points to where
it can be downloaded.
I think it would be useful to include the cloud image version (i.e.
20160420) and the version of the ostree compose (i.e. 23.106) in the email
announcing the two week release.
This would provide a record in the mailing list archive that could be
referenced when trying to determine if a problem was introduced in one
release vs. another.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6418>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
7 years, 11 months
#6369: Please create a f24-gnome side tag
by Fedora Release Engineering
#6369: Please create a f24-gnome side tag
-----------------------------+------------------------
Reporter: kalev | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 24 Alpha | Component: koji
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
Hi,
Please create a new f24-gnome side tag and build target. We'll use it for
building GNOME megaupdates before submitting them to Bodhi, to help ensure
they don't cause issues in F24 proper while we're preparing the updates.
Thanks,
Kalev
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6369>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
7 years, 11 months
#6415: remove el6-docs target/tags/etc
by Fedora Release Engineering
#6415: remove el6-docs target/tags/etc
-----------------------------+------------------------
Reporter: kevin | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 24 Final | Component: koji
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
Docs is not going to implement this setup, so they no longer need or want
the el6-docs target and tags. Remove them from koji.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6415>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
7 years, 11 months