3:26 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
No one currently is working on Fedora SPARC, and hasnt been for quite
some time. we would need to get gcc-4.7 bootstrapped as well as a few
other bits and pieces. its work that I just do not have the time to do,
I also do not have the interest that I used to have. I think its a bit
of a disservice to say that Fedora SPARC is a secondary arch at this
point. If people do not step up to get things fixed and working im
planning to take down the SPARC koji instance and remove sparc support
from fedora-packager.
Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iEYEARECAAYFAlBXh5IACgkQkSxm47BaWffZ7ACfUDMaCZd2RiHnf1twzowJveIN
aa8An2q4lujztP5y3udb9jPQ+8XXulhD
=vWHI
-----END PGP SIGNATURE-----
1:20 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 9/17/2012 10:26 PM, Dennis Gilmore wrote:
No one currently is working on Fedora SPARC, and hasnt been for
quite some time. we would need to get gcc-4.7 bootstrapped as well
as a few other bits and pieces. its work that I just do not have
the time to do, I also do not have the interest that I used to
have. I think its a bit of a disservice to say that Fedora SPARC is
a secondary arch at this point. If people do not step up to get
things fixed and working im planning to take down the SPARC koji
instance and remove sparc support from fedora-packager.
Sadly I have to say that it is probably the wisest path.
Fabio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQIcBAEBCAAGBQJQWBKZAAoJEFA6oBJjVJ+OfX0QAKusXyIu2l5jjPceD1qBAAdX
OP1FTJFUKst+eEys/ES6CvEuVe8JN9TBdfkMQp17KLDjaF7WyFb7cmDD3+kSRv41
PLiduFPmU4ebWAOB5zQDjryYZxr6xgOkbqQqBsHhrDAXnMJm11+S5DVAesWnQrBr
tm62X5HEbQ7R4fO57SKKA64S2yIvPTlm/NUozc6p3y9fI/4uQZoEECOpiahwLn0C
SeOsZt7mCMNCNF+y6tzOR2I5LQOceJFjIUa42kpVXfY9OImKsZoxFDhmDS6/BkIv
IWW9Cu0KNc5dw30uIQiXoI6fnnvkd6IIWK6jmZxxWsZLr+cFHpkzlRzfaGnhTBsH
knU+UdKqp3vMtKsvAEGDdvQKBbjXwxC2qPKJC9f4lEy3/gybeDKQXbQ4VC8/5Pw5
ALZ60SQmHoa1/CrDezkTXFkryjlpMlwM0qQNbCisBwA+8B+JhcF3H/uvP+hzcfev
7gPEu8tfPubQse6eRl6KM2jGxQs17y0TMMYsfI/TeB18bgeTimSNNCKDFLkpF5vb
VmRIqMc3DgsIu4tRhW4JdeYPqv5GspwgwjTipThDRkXxj95kt/QO8HVRnmELu7Lz
vSNHs9lGALNUp61uHvEG/5GuhFaNgAjIh4891/ZHHfqebN+3Zs2CwKYkWRgLWHJ9
7Wf/YBA3aSq+fNktGju0
=qzr7
-----END PGP SIGNATURE-----
2:16 a.m.
On Tue, Sep 18, 2012 at 8:20 AM, Fabio M. Di Nitto <fdinitto(a)redhat.com>wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 9/17/2012 10:26 PM, Dennis Gilmore wrote:
> No one currently is working on Fedora SPARC, and hasnt been for
> quite some time. we would need to get gcc-4.7 bootstrapped as well
> as a few other bits and pieces. its work that I just do not have
> the time to do, I also do not have the interest that I used to
> have. I think its a bit of a disservice to say that Fedora SPARC is
> a secondary arch at this point. If people do not step up to get
> things fixed and working im planning to take down the SPARC koji
> instance and remove sparc support from fedora-packager.
Sadly I have to say that it is probably the wisest path.
Fabio
Hi,
It's not that I am not interested. I just don't have the time and hardware.
- A Sun Blade 150 is pretty painful to compile stuff on.
- Using the T4s and T5240s at work is not an option unless I create a
logical domain aside the other ones, which doesn't work.
- Having a V240 at home is something any electricity company would support
but is too expensive for end-users.
So yes, the possibilities are sort of limited and then there is the doing
60+ hours of work in a week on top of that.
Ironic enough we actually DO use Linux for Sparc here at the company. It
was setup as there was no Intel hardware available and they needed Linux
installations fast...
Patrick
3:55 p.m.
On Tue, Sep 18, 2012 at 9:16 AM, Patrick Ale <patrick.ale(a)gmail.com> wrote:
It's not that I am not interested. I just don't have the time
and hardware.
Actually you don't need SPARC hardware to build sparc64 userland:
qemu-system-sparc64 boots Linux and may be fast enough for building stuff.
It is limited to one CPU, but I guess a fast PC running qemu is
consuming less electricity than an old sun4u machine.
--
Regards,
Artyom Tarasenko
solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu
5:06 p.m.
Actually you don't need SPARC hardware to build sparc64
userland:
qemu-system-sparc64 boots Linux and may be fast enough for building stuff.
It is limited to one CPU, but I guess a fast PC running qemu is
consuming less electricity than an old sun4u machine.
Hey wow, that's a great alternative for at home indeed, thanks for that.
I tried to install the 12 Beta on a T2000 today (which is not at home ;-)).
and it panics during the kernel boot.
But Solaris 11 panics too with messages like "Exception handler
interrupted, please file a bug", so I guess I first have to upgrade the
firmware on this thing. (Which wouldn't surprise me judging by what I get
to work with).
More will follow soon.
Patrick
8:03 a.m.
On Sep 19, 2012 12:06 AM, "Patrick Ale" <patrick.ale(a)gmail.com> wrote:
More will follow soon.
As expected: firmware from 2006. Its installing now.
Something I really miss during the installation is the option to manually
layout/review the file systems when installing via console in text mode. Or
I just overlook it?
I am using vnc now to work around it. :)
8:38 a.m.
On 20/09/12 14:03, Patrick Ale wrote:
On Sep 19, 2012 12:06 AM, "Patrick Ale" <patrick.ale(a)gmail.com
<mailto:patrick.ale@gmail.com>> wrote:
>
>
> More will follow soon.
>
As expected: firmware from 2006. Its installing now.
Something I really miss during the installation is the option to
manually layout/review the file systems when installing via console in
text mode. Or I just overlook it?
I am using vnc now to work around it. :)
_______________________________________________
sparc mailing list
sparc(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/sparc
Mmm been looking at that,.. though it got overshadowed by other issues,
then again the anaconda folk looks to be completely writing anaconda
(again) Fedora 18/19
I'd enough problems with getting the storage component stable again. 8/
Thn again, in large scale deployments you'd likely be installing using a
kickstart file so you'd not really be that worried about vnc/text modes.
Phil
=--=
8:46 a.m.
Thn again, in large scale deployments you'd likely be installing using a
kickstart file so you'd not really be that worried about vnc/text modes.
Phil
=--=
Hi, true fact about the kickstart usage. Which reminds me to test if the
installer borks out on filesystem creation with ks, never tried that to be
honest.
That's why I need the "manual partition" layout.
1) Create partitions in recue mode with parted.
2) Assign the mountpoints and fs types during installation.
Another item for my test bunny :)
Patrick
9 a.m.
On Thursday, September 20, 2012 09:03:14 AM Patrick Ale wrote:
On Sep 19, 2012 12:06 AM, "Patrick Ale"
<patrick.ale(a)gmail.com> wrote:
>
>
> More will follow soon.
>
As expected: firmware from 2006. Its installing now.
Something I really miss during the installation is the option to manually
layout/review the file systems when installing via console in text mode. Or
I just overlook it?
I am using vnc now to work around it. :)
Hmm, I seem to remember some issues around the partitioning under F12 on SPARC. It was
recommended, best I can recall, that you let the installer autopartition; anything else is
very unstable and will likely crash anaconda.
Once installed you can set up partitions, move LVM around (I did that with our E6500,
taking the defaults at first onto a single drive, and then moving the physical volume
(with the LVM tools) to a software RAID5. Worked fine.) set up RAID, or whatever else.
But it was important, IIRC, to take the defaults during installation. There is a set of
posts in the archives about the installer caveats, and I think it's on the F12Beta
page on Fedoraproject.org, or at least it used to be.
I have my own private archive of messages like that to this mailing list, and I can repost
if mecessary.
I'm currently running F12Beta updated (the update, incidentally, is less stable than
the original install was) on a Blade 1000 workstation with dual CPU's:
[root@sb1k-1 ~]# cat /proc/cpuinfo
cpu : TI UltraSparc III (Cheetah)
fpu : UltraSparc III integrated FPU
pmu : ultra3
prom : OBP 4.5.10 2002/02/11 10:38
type : sun4u
ncpus probed : 2
ncpus active : 2
D$ parity tl1 : 0
I$ parity tl1 : 0
Cpu0ClkTck : 000000002cb41780
Cpu1ClkTck : 000000002cb41780
MMU Type : Cheetah
State:
CPU0: online
CPU1: online
[root@sb1k-1 ~]#
Don't remember how to get CPU MHz from this, unfortunately. While I do have remote
serial console and could get it from OpenBoot, I'm enjoying:
[root@sb1k-1 ~]# uptime
09:57:46 up 706 days, 18:30, 1 user, load average: 0.00, 0.00, 0.00
[root@sb1k-1 ~]#
I don't have the E6500 up at the moment, but it was last booting F12Beta as well, on
(IIRC) 16 CPUs, each one 400MHz. I've documented the boot procedure for SBUS and F12
on this list before, including the kernel command line options required to get a
successful (manual) boot with dracut, up through RAID and LVM, given that F12's udev
on SBUS is borked.
9:40 a.m.
On 20/09/12 15:00, Lamar Owen wrote:
Hmm, I seem to remember some issues around the partitioning under F12 on SPARC. It was
recommended, best I can recall, that you let the installer autopartition; anything else is
very unstable and will likely crash anaconda.
Once installed you can set up partitions, move LVM around (I did that with our E6500,
taking the defaults at first onto a single drive, and then moving the physical volume
(with the LVM tools) to a software RAID5. Worked fine.) set up RAID, or whatever else.
But it was important, IIRC, to take the defaults during installation. There is a set of
posts in the archives about the installer caveats, and I think it's on the F12Beta
page on Fedoraproject.org, or at least it used to be.
I have my own private archive of messages like that to this mailing list, and I can
repost if mecessary.
Mmm auto partitioning works but replace doesn't because for whatever
reason it ignores anaconda/platform.py where _disklabel_types = ['sun']
is set for the sparc platform and decides the disk should be using a
msdos label instead, so the install goes along fine since linux is able
to handle both label types, at the end after you reboot, OBP looks for a
sun label disk and finds msdos garbage which it promptly chokes on.
I think the logic is buried in storage/device.py and
storage/partitioning.py.
Anaconda - a cruel and unusual punishment to make anyone do.
Phil
=--=
2:21 p.m.
On 21/09/12 15:40, Bryce wrote:
On 20/09/12 15:00, Lamar Owen wrote:
> Hmm, I seem to remember some issues around the partitioning under F12 on SPARC. It
was recommended, best I can recall, that you let the installer autopartition; anything
else is very unstable and will likely crash anaconda.
>
> Once installed you can set up partitions, move LVM around (I did that with our E6500,
taking the defaults at first onto a single drive, and then moving the physical volume
(with the LVM tools) to a software RAID5. Worked fine.) set up RAID, or whatever else.
But it was important, IIRC, to take the defaults during installation. There is a set of
posts in the archives about the installer caveats, and I think it's on the F12Beta
page on Fedoraproject.org, or at least it used to be.
>
> I have my own private archive of messages like that to this mailing list, and I can
repost if mecessary.
>
>
Mmm auto partitioning works but replace doesn't because for whatever
reason it ignores anaconda/platform.py where _disklabel_types = ['sun']
is set for the sparc platform and decides the disk should be using a
msdos label instead, so the install goes along fine since linux is able
to handle both label types, at the end after you reboot, OBP looks for a
sun label disk and finds msdos garbage which it promptly chokes on.
I think the logic is buried in storage/device.py and
storage/partitioning.py.
Anaconda - a cruel and unusual punishment to make anyone do.
Phil
=--=
_______________________________________________
sparc mailing list
sparc(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/sparc
Ah, I think I see it now.
storage/formats/disklabel.py
When you ask for a replacement of the existing linux system anaconda
does what I consider to be really bad practices.
It seems to believe that knowing where the partitions are is enough for
it to DELETE the 1st MB of the disk to destroy the partition table. It
then initializes the disklabel and then writes out the partitions in the
exact same place,...
WHY it thinks it's necessary to do all this russian roulette work rather
than just work with the existing table structure baffles me, however, I
didn't write it so I'm disavowing blame for once.
Anyway,. tracing shows
log.debug("resetting parted disks...")
for device in self.devices:
import pdb; pdb.set_trace()
if device.partitioned:
*device.format.resetPartedDisk()*
if device.originalFormat.type == "disklabel" and \
device.originalFormat != device.format:
device.originalFormat.resetPartedDisk()
which leads me into
storage/formats/disklabel.py
class DiskLabel(DeviceFormat):
...
def __init__(self, *args, **kwargs):
if not self.exists:
self._labelType = kwargs.get("labelType", "*msdos*")
else:
self._labelType = None
So when the disk is nuked, the label can't be found and it assumes msdos
rather than being sensible and looking up the platform data
This is part of why the "Replace linux system option" won't work for
sparc. There seems to be a gaping hole in anaconda where it just make no
effort to remember what the disk label format was. This seems to be true
of anaconda 18 as well, I didn't check whatever is in git, I kinda
expect this to be a problem for PPC folk as well.
changing
self._labelType = kwargs.get("labelType", "*msdos*")
to
self._labelType = *platform.getPlatform(None)._disklabel_types[0]*
alleviates the problem but is */not/* in any way a true fix but it will
suffice for 80-90% of cases... What should have happened is that the
original label type should have been noted and returned somehow.
(since at least one architecture has two types assigned, we'll
use index [0] as the default)
[root@emerald mnt]# *grep _disklabel_types platform.py*
_disklabel_types = ["msdos"]
return self._disklabel_types
_disklabel_types = ["gpt"]
_disklabel_types = ["bsd"]
_disklabel_types = ["mac"]
_disklabel_types = ["msdos"]
_disklabel_types = ["sun"]
self._disklabel_types = ["gpt"]
*self._disklabel_types = ["msdos", "gpt"]*
Phil
=--=
2:47 p.m.
On 21/09/12 15:40, Bryce wrote:
On 20/09/12 15:00, Lamar Owen wrote:
> Hmm, I seem to remember some issues around the partitioning under F12 on SPARC. It
was recommended, best I can recall, that you let the installer autopartition; anything
else is very unstable and will likely crash anaconda.
>
> Once installed you can set up partitions, move LVM around (I did that with our E6500,
taking the defaults at first onto a single drive, and then moving the physical volume
(with the LVM tools) to a software RAID5. Worked fine.) set up RAID, or whatever else.
But it was important, IIRC, to take the defaults during installation. There is a set of
posts in the archives about the installer caveats, and I think it's on the F12Beta
page on Fedoraproject.org, or at least it used to be.
>
> I have my own private archive of messages like that to this mailing list, and I can
repost if mecessary.
>
>
Mmm auto partitioning works but replace doesn't because for whatever
reason it ignores anaconda/platform.py where _disklabel_types = ['sun']
is set for the sparc platform and decides the disk should be using a
msdos label instead, so the install goes along fine since linux is able
to handle both label types, at the end after you reboot, OBP looks for a
sun label disk and finds msdos garbage which it promptly chokes on.
I think the logic is buried in storage/device.py and
storage/partitioning.py.
Anaconda - a cruel and unusual punishment to make anyone do.
Phil
=--=
_______________________________________________
sparc mailing list
sparc(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/sparc
Ah, I think I see it now.
storage/formats/disklabel.py
When you ask for a replacement of the existing linux system anaconda
does what I consider to be really bad practices.
It seems to believe that knowing where the partitions are is enough for
it to DELETE the 1st MB of the disk to destroy the partition table. It
then initializes the disklabel and then writes out the partitions in the
exact same place,...
WHY it thinks it's necessary to do all this russian roulette work rather
than just work with the existing table structure baffles me, however, I
didn't write it so I'm disavowing blame for once.
Anyway,. tracing shows
log.debug("resetting parted disks...")
for device in self.devices:
import pdb; pdb.set_trace()
if device.partitioned:
*device.format.resetPartedDisk()*
if device.originalFormat.type == "disklabel" and \
device.originalFormat != device.format:
device.originalFormat.resetPartedDisk()
which leads me into
storage/formats/disklabel.py
class DiskLabel(DeviceFormat):
...
def __init__(self, *args, **kwargs):
if not self.exists:
self._labelType = kwargs.get("labelType", "*msdos*")
else:
self._labelType = None
So when the disk is nuked, the label can't be found and it assumes msdos
rather than being sensible and looking up the platform data
This is part of why the "Replace linux system option" won't work for
sparc. There seems to be a gaping hole in anaconda where it just make no
effort to remember what the disk label format was. This seems to be true
of anaconda 18 as well, I didn't check whatever is in git, I kinda
expect this to be a problem for PPC folk as well.
changing
self._labelType = kwargs.get("labelType", "*msdos*")
to
self._labelType = *platform.getPlatform(None)._disklabel_types[0]*
alleviates the problem but is */not/* in any way a true fix but it will
suffice for 80-90% of cases... What should have happened is that the
original label type should have been noted and returned somehow.
(since at least one architecture has two types assigned, we'll
use index [0] as the default)
[root@emerald mnt]# *grep _disklabel_types platform.py*
_disklabel_types = ["msdos"]
return self._disklabel_types
_disklabel_types = ["gpt"]
_disklabel_types = ["bsd"]
_disklabel_types = ["mac"]
_disklabel_types = ["msdos"]
_disklabel_types = ["sun"]
self._disklabel_types = ["gpt"]
*self._disklabel_types = ["msdos", "gpt"]*
Phil
=--=
12:26 p.m.
On 09/17/2012 10:26 PM, Dennis Gilmore wrote:
No one currently is working on Fedora SPARC, and hasnt been for
quite
some time. we would need to get gcc-4.7 bootstrapped as well as a few
other bits and pieces. its work that I just do not have the time to do,
I also do not have the interest that I used to have. I think its a bit
of a disservice to say that Fedora SPARC is a secondary arch at this
point. If people do not step up to get things fixed and working im
planning to take down the SPARC koji instance and remove sparc support
from fedora-packager.
Actually... rethinking a bit about this, there might be a way to save
the port.
Something I started pondering a while ago, but never got close enough to
do it.
The main issues with our port (beside too few people working on it) are:
- sparc64 userland
virtually we are the only distro shipping and porting to sparc64 and the
only reason we do it, is to build the kernel. IMHO.. a tad overkilling.
sparc userland can build sparc64 kernels.
- the current "base" is just too old and too complex to rebuild clean.
as you mentioned in another email exchange, the arm port, that was
recently bootstrapped, used a tool to generate correct dependency build
order when starting from scratch.
my suggestion would be to simply kill all we have now, kill sparc64 and
start clean.
Debian and other distros are shipping the same code base as we do (given
or taken) and they can keep up no problem because they don't have to
deal with all the 64 bit userland failures and upstreams are more
willing to take patches.
The approach i am suggesting here for bootstrapping is "scorched earth".
Get current sources, build in correct sequence -> save binaries
somewhere non-public -> clean chroots -> install chroots from first run
binaries -> rebuild all again -> publish new binaries, kill/destroy old
ones.
The reason to not make old ones publics is to make sure there is no
version/binary collision, there is somewhat value in keeping them
secrets and avoid destroying user souls ;)
Most of this can probably be scripted. Major work left (beside fixing
build failures) would be to fix kernel package and port anaconda
(already more reasonable amount of work).
What do you think?
Fabio
3:12 p.m.
On 17/09/12 21:26, Dennis Gilmore wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
No one currently is working on Fedora SPARC, and hasnt been for quite
some time. we would need to get gcc-4.7 bootstrapped as well as a few
other bits and pieces. its work that I just do not have the time to do,
I also do not have the interest that I used to have. I think its a bit
of a disservice to say that Fedora SPARC is a secondary arch at this
point. If people do not step up to get things fixed and working im
planning to take down the SPARC koji instance and remove sparc support
from fedora-packager.
Dennis
I'd have replied sooner but I'd to go get a number of mandates and approvals.
Anyway that is all done. I and other folk at oracle can now formally assist.
Gcc bootstrapping and a fixed up toolchain? We can do for you 32/64bit,
kernel we have in house folk that can help with.
Cheers
Phil (infinitely abusable employee)
=--=
3:13 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, 18 Sep 2012 21:12:11 +0100
Bryce <bryce(a)zeniv.linux.org.uk> wrote:
On 17/09/12 21:26, Dennis Gilmore wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> No one currently is working on Fedora SPARC, and hasnt been for
> quite some time. we would need to get gcc-4.7 bootstrapped as well
> as a few other bits and pieces. its work that I just do not have
> the time to do, I also do not have the interest that I used to
> have. I think its a bit of a disservice to say that Fedora SPARC is
> a secondary arch at this point. If people do not step up to get
> things fixed and working im planning to take down the SPARC koji
> instance and remove sparc support from fedora-packager.
>
> Dennis
>
I'd have replied sooner but I'd to go get a number of mandates and
approvals.
Anyway that is all done. I and other folk at oracle can now formally
assist. Gcc bootstrapping and a fixed up toolchain? We can do for you
32/64bit, kernel we have in house folk that can help with.
What kind of resources are available? SPARC as a secondary arch needs
at least 1 probably more people to do pretty much full time work on it.
buildserver wise we only have a T2000 thats useable, the T1000 randomly
drops to OBP. maybe you can drop into #fedora-sparc on freenode and we
could discuss what is needed?
Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iEYEARECAAYFAlBbeNIACgkQkSxm47BaWfdy/gCeM5wF5WahDTFRgTsFHFMixmH+
a+kAn1u8GALTqOScJkwPomASyJ85Ir38
=csZN
-----END PGP SIGNATURE-----
3:24 p.m.
On 20/09/12 21:13, Dennis Gilmore wrote:
What kind of resources are available? SPARC as a secondary arch needs
at least 1 probably more people to do pretty much full time work on it.
buildserver wise we only have a T2000 thats useable, the T1000 randomly
drops to OBP. maybe you can drop into #fedora-sparc on freenode and we
could discuss what is needed?
Dennis
umm considerably more than that. (Thinking apps/kernel/gcc/toolchain/qa
folk here)
I'll have to yak at the boss to shift a few sparcs into the wild though,
obviously having them behind the company firewalls is no good unless
there's some kinda of black box proxying ability to koji in which case I
could throw a small lab at the build processing.
yeah,.. lemme sort out a few items here and I'll drop over in 40-50
minutes..-ish (timekeeping was never my strong suit)
Phil
=--=
3:36 p.m.
Bryce píše v Čt 20. 09. 2012 v 21:24 +0100:
On 20/09/12 21:13, Dennis Gilmore wrote:
>
> What kind of resources are available? SPARC as a secondary arch needs
> at least 1 probably more people to do pretty much full time work on it.
> buildserver wise we only have a T2000 thats useable, the T1000 randomly
> drops to OBP. maybe you can drop into #fedora-sparc on freenode and we
> could discuss what is needed?
>
> Dennis
>
umm considerably more than that. (Thinking apps/kernel/gcc/toolchain/qa
folk here)
I'll have to yak at the boss to shift a few sparcs into the wild though,
obviously having them behind the company firewalls is no good unless
there's some kinda of black box proxying ability to koji in which case I
could throw a small lab at the build processing.
yeah,.. lemme sort out a few items here and I'll drop over in 40-50
minutes..-ish (timekeeping was never my strong suit)
yeah, speaking with the Fedora/s390x experience having the 1 person
working (almost) full-time is the minimum for a successful secondary
arch and having experts in various areas ready to help is a big plus
Dan
8:42 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
El Thu, 20 Sep 2012 21:24:15 +0100
Bryce <bryce(a)zeniv.linux.org.uk> escribió:
On 20/09/12 21:13, Dennis Gilmore wrote:
>
> What kind of resources are available? SPARC as a secondary arch
> needs at least 1 probably more people to do pretty much full time
> work on it. buildserver wise we only have a T2000 thats useable,
> the T1000 randomly drops to OBP. maybe you can drop into
> #fedora-sparc on freenode and we could discuss what is needed?
>
> Dennis
>
umm considerably more than that. (Thinking
apps/kernel/gcc/toolchain/qa folk here)
I'll have to yak at the boss to shift a few sparcs into the wild
though, obviously having them behind the company firewalls is no good
unless there's some kinda of black box proxying ability to koji in
which case I could throw a small lab at the build processing.
yeah,.. lemme sort out a few items here and I'll drop over in 40-50
minutes..-ish (timekeeping was never my strong suit)
Sorry Just saw you had dropped in, you will need to ping me to get my
attention, i am in way to many rooms to keep track of them all. my irc
nick is dgilmore Lets try again :)
Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iEYEARECAAYFAlBdF4oACgkQkSxm47BaWfeScACgvUHHbioo7M6ubRVjAfkB46m/
UzIAnjXAJbY+Xgy1FPkfKro9E/BI9ll0
=A8yK
-----END PGP SIGNATURE-----
4227
days inactive
4232
days old
17 comments
7 participants
participants (7)
-
Artyom Tarasenko -
Bryce -
Dan Horák -
Dennis Gilmore -
Fabio M. Di Nitto -
Lamar Owen -
Patrick Ale