All
This may sound like a silly question but I will ask anyway: If I were to do re-spins of the FC5 ISOs would they need to be done on the particular arch (i.e. would x86_64 have to be re-spun on x86_64 hardware)?
Thanks in advance.
Scott Glaser
On Mon, 2006-05-01 at 07:28 -0400, Scott Glaser wrote:
This may sound like a silly question but I will ask anyway: If I were to do re-spins of the FC5 ISOs would they need to be done on the particular arch (i.e. would x86_64 have to be re-spun on x86_64 hardware)?
And PPC respun on PPC hardware. Yes, I think that's probably the case although I wouldn't swear to it.
I think you'll get away with doing i386 on x86_64 though.
On Mon, 2006-05-01 at 07:28 -0400, Scott Glaser wrote:
This may sound like a silly question but I will ask anyway: If I were to do re-spins of the FC5 ISOs would they need to be done on the particular arch (i.e. would x86_64 have to be re-spun on x86_64 hardware)?
I don't think this is the case.
On Mon, 1 May 2006, Jesse Keating wrote:
On Mon, 2006-05-01 at 07:28 -0400, Scott Glaser wrote:
This may sound like a silly question but I will ask anyway: If I were to do re-spins of the FC5 ISOs would they need to be done on the particular arch (i.e. would x86_64 have to be re-spun on x86_64 hardware)?
I don't think this is the case.
You should be able to do this with mock. Not certain if every package is buildable as a cross-compile though. Worth a test...
On Mon, 2006-05-01 at 07:28 -0400, Scott Glaser wrote:
All
This may sound like a silly question but I will ask anyway: If I were to do re-spins of the FC5 ISOs would they need to be done on the particular arch (i.e. would x86_64 have to be re-spun on x86_64 hardware)?
Thanks in advance.
Scott Glaser
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Lets see, Keating says no, Woodhouse says yes.
x86_64 spin on i386 failed...Could be user error or some other issue, I say we are batting .500.
On Mon, 2006-05-01 at 11:28 -0500, Robert 'Bob' Jensen wrote:
x86_64 spin on i386 failed...Could be user error or some other issue, I say we are batting .500.
Can you show me how it failed on i386? What were your steps, where did it go boom? Tracebacks or whatnot from the boom?
On Mon, 2006-05-01 at 13:03 -0400, Jesse Keating wrote:
Can you show me how it failed on i386? What were your steps, where did it go boom? Tracebacks or whatnot from the boom?
Jesse,
Thanks for the response, I will clean up my x86_64 tree here and give it a run.
It failed when running pkgorder, would get through the 5 kernels and fail...
Come to think of it, three of those kernels were on in x86_64 at release time, there were also some other "cluster bits" not in the original release. Let me check that out. I will post back, I bet all that needs to be added to the comps.xml.
-- Robert 'Bob' Jensen http://fedoraproject.org/wiki/BobJensen Fedora Documentation Projects Release Notes Editor-in-Chief
On Mon, 2006-05-01 at 13:03 -0400, Jesse Keating wrote:
Can you show me how it failed on i386? What were your steps, where did it go boom? Tracebacks or whatnot from the boom?
Here is the output at the point of failure
[bob-local@spinmaster x86_64]$ pwd /var/www/mirror/fedora/linux/5/x86_64 [bob-local@spinmaster x86_64]$ pkgorder /var/www/mirror/fedora/linux/5/x86_64/iso-build_bob-local x86_64 Fedora | tee /var/www/mirror/fedora/linux/5/x86_64/iso-build_pkgfile_bob-local kernel-2.6.16-1.2096_FC5.x86_64.rpm kernel-xen0-2.6.16-1.2096_FC5.x86_64.rpm kernel-xenU-devel-2.6.16-1.2096_FC5.x86_64.rpm kernel-xen0-devel-2.6.16-1.2096_FC5.x86_64.rpm kernel-xenU-2.6.16-1.2096_FC5.x86_64.rpm Traceback (most recent call last): File "/usr/lib/anaconda-runtime/pkgorder", line 159, in ? addGroups(ds, ["Core", "Base", "Text-based Internet"]) File "/usr/lib/anaconda-runtime/pkgorder", line 97, in addGroups ds.resolveDeps() File "/usr/lib/anaconda/yuminstall.py", line 303, in resolveDeps unresolved = self.tsCheck(unresolved) File "/usr/lib/anaconda/yuminstall.py", line 329, in tsCheck dep = self._provideToPkg(req) File "/usr/lib/anaconda/yuminstall.py", line 280, in _provideToPkg best = self.bestPackagesFromList(satisfiers)[0] IndexError: list index out of range
Again this is building x86_64 on i386, the instructions used worked for i386 on i386. Instructions are based on http://fedoranews.org/contributors/gene_czarcinski/update_distro/ modified and updated for FC5.
Should we be using Mock for this as alan pointed out above?
On Mon, 2006-05-01 at 14:38 -0500, Robert 'Bob' Jensen wrote:
On Mon, 2006-05-01 at 13:03 -0400, Jesse Keating wrote:
Can you show me how it failed on i386? What were your steps, where did it go boom? Tracebacks or whatnot from the boom?
Here is the output at the point of failure
[snip]
Again this is building x86_64 on i386, the instructions used worked for i386 on i386. Instructions are based on http://fedoranews.org/contributors/gene_czarcinski/update_distro/ modified and updated for FC5.
Should we be using Mock for this as alan pointed out above?
Using mock isn't the important part, but you'll need to make sure that things think that you're running on 32-bit as otherwise, arch scoring will want x86_64 pieces. You might be able to get away with just running the commands under setarch, but setarch + a chroot is safer[1]
Jeremy
[1] And also how we compose the actual trees
On Mon, 2006-05-01 at 15:49 -0400, Jeremy Katz wrote:
On Mon, 2006-05-01 at 14:38 -0500, Robert 'Bob' Jensen wrote:
On Mon, 2006-05-01 at 13:03 -0400, Jesse Keating wrote:
Can you show me how it failed on i386? What were your steps, where did it go boom? Tracebacks or whatnot from the boom?
Here is the output at the point of failure
[snip]
Again this is building x86_64 on i386, the instructions used worked for i386 on i386. Instructions are based on http://fedoranews.org/contributors/gene_czarcinski/update_distro/ modified and updated for FC5.
Should we be using Mock for this as alan pointed out above?
Using mock isn't the important part, but you'll need to make sure that things think that you're running on 32-bit as otherwise, arch scoring will want x86_64 pieces. You might be able to get away with just running the commands under setarch, but setarch + a chroot is safer[1]
...
and as Jesse points out, I read your message backwards.
There are ways to do i386 on x86_64, but x86_64 on i386 isn't going to work with the current set of tools
Jeremy
On Mon, 2006-05-01 at 15:55 -0400, Jeremy Katz wrote:
On Mon, 2006-05-01 at 15:49 -0400, Jeremy Katz wrote:
and as Jesse points out, I read your message backwards.
There are ways to do i386 on x86_64, but x86_64 on i386 isn't going to work with the current set of tools
Jeremy
I assume then the same is true for PPC.
Thank you all for your input.
-- Robert 'Bob' Jensen http://fedoraproject.org/wiki/BobJensen Fedora Documentation Projects Release Notes Editor-in-Chief
Keating 0 Woodhouse 1
On Mon, 2006-05-01 at 15:10 -0500, Robert 'Bob' Jensen wrote:
I assume then the same is true for PPC.
It's different for PPC.
The PPC32 architecture isn't as crap as i386 -- it actually has a sane number of registers. Therefore you don't really gain much by using 64-bit userspace on a PPC64 machine; on PPC64 we still use mostly PPC32 userspace.
So the PPC distro contains PPC64 as a secondary architecture in the same way that the x86_64 distro contains i386 packages. And you _can_ do the buildinstall of that (including ppc64 packages) on a ppc32 host.
There _is_ a 'pure ppc64' distro in rawhide, but we don't ship that -- just as we don't ship ia64, s390, etc.
On Mon, 2006-05-01 at 21:24 +0100, David Woodhouse wrote:
It's different for PPC.
The PPC32 architecture isn't as crap as i386 -- it actually has a sane number of registers. Therefore you don't really gain much by using 64-bit userspace on a PPC64 machine; on PPC64 we still use mostly PPC32 userspace.
So the PPC distro contains PPC64 as a secondary architecture in the same way that the x86_64 distro contains i386 packages. And you _can_ do the buildinstall of that (including ppc64 packages) on a ppc32 host.
There _is_ a 'pure ppc64' distro in rawhide, but we don't ship that -- just as we don't ship ia64, s390, etc.
-- dwmw2
I was asking about spinning the ISOs for PPC(32) on a PPC(32)
On Mon, 2006-05-01 at 21:24 +0100, David Woodhouse wrote:
So the PPC distro contains PPC64 as a secondary architecture in the same way that the x86_64 distro contains i386 packages. And you _can_ do the buildinstall of that (including ppc64 packages) on a ppc32 host.
I think it was more of 'I have to use ppc to compose ppc, I can't do it on i386' question (;
On Mon, May 01, 2006 at 03:55:32PM -0400, Jeremy Katz wrote:
There are ways to do i386 on x86_64, but x86_64 on i386 isn't going to work with the current set of tools
Is RHPL at fault here? I thought that was the case with FC4 and previous versions, but I seem to remember that things were supposed to change with FC5. Hold on, I thought you still couldn't do i386 on x86_64, either: is that new in FC5, then? Is this documented anywhere?
On Mon, 2006-05-01 at 15:55 -0400, Jeremy Katz wrote:
On Mon, 2006-05-01 at 15:49 -0400, Jeremy Katz wrote:
Using mock isn't the important part, but you'll need to make sure that things think that you're running on 32-bit as otherwise, arch scoring will want x86_64 pieces. You might be able to get away with just running the commands under setarch, but setarch + a chroot is safer[1]
...
and as Jesse points out, I read your message backwards.
There are ways to do i386 on x86_64, but x86_64 on i386 isn't going to work with the current set of tools
Jeremy
The results are in, my x86_64 updated ISO did build correctly on my x86_64 machine and installed correctly on two so far.
Thank you for your time everyone.
-- Robert 'Bob' Jensen http://fedoraproject.org/wiki/BobJensen Fedora Documentation Projects Release Notes Editor-in-Chief
On Mon, May 01, 2006 at 03:55:32PM -0400, Jeremy Katz wrote:
On Mon, 2006-05-01 at 15:49 -0400, Jeremy Katz wrote:
On Mon, 2006-05-01 at 14:38 -0500, Robert 'Bob' Jensen wrote:
On Mon, 2006-05-01 at 13:03 -0400, Jesse Keating wrote:
Can you show me how it failed on i386? What were your steps, where did it go boom? Tracebacks or whatnot from the boom?
Here is the output at the point of failure
[snip]
Again this is building x86_64 on i386, the instructions used worked for i386 on i386. Instructions are based on http://fedoranews.org/contributors/gene_czarcinski/update_distro/ modified and updated for FC5.
Should we be using Mock for this as alan pointed out above?
Using mock isn't the important part, but you'll need to make sure that things think that you're running on 32-bit as otherwise, arch scoring will want x86_64 pieces. You might be able to get away with just running the commands under setarch, but setarch + a chroot is safer[1]
...
and as Jesse points out, I read your message backwards.
There are ways to do i386 on x86_64, but x86_64 on i386 isn't going to work with the current set of tools
I think there may be some confusion in this thread. Some posters define "respin the isos" with "replace the packages with ones from updates and rerun anaconda bits on them", and others define it as "rebuild from src.rpms".
For the latter you need arch comaptibility, e.g. i386 can be built on x86_64 (provided you setup sane chroots, use setarch etc.).
But the former might not need any special arch considerations. E.g. createrepo, pkgroder and the like only look at rpm headers and hopefully shouldn't care about the actual contents and rpm colors. Is that true? E.g. can I build x86_64 and ppc isos on i386 (provided the packages are already available, e.g. no rebuilds).
On Mon, May 01, 2006 at 02:38:26PM -0500, Robert 'Bob' Jensen wrote:
On Mon, 2006-05-01 at 13:03 -0400, Jesse Keating wrote:
Can you show me how it failed on i386? What were your steps, where did it go boom? Tracebacks or whatnot from the boom?
Here is the output at the point of failure
[bob-local@spinmaster x86_64]$ pwd /var/www/mirror/fedora/linux/5/x86_64 [bob-local@spinmaster x86_64]$ pkgorder /var/www/mirror/fedora/linux/5/x86_64/iso-build_bob-local x86_64 Fedora | tee /var/www/mirror/fedora/linux/5/x86_64/iso-build_pkgfile_bob-local kernel-2.6.16-1.2096_FC5.x86_64.rpm kernel-xen0-2.6.16-1.2096_FC5.x86_64.rpm kernel-xenU-devel-2.6.16-1.2096_FC5.x86_64.rpm kernel-xen0-devel-2.6.16-1.2096_FC5.x86_64.rpm kernel-xenU-2.6.16-1.2096_FC5.x86_64.rpm Traceback (most recent call last): File "/usr/lib/anaconda-runtime/pkgorder", line 159, in ? addGroups(ds, ["Core", "Base", "Text-based Internet"]) File "/usr/lib/anaconda-runtime/pkgorder", line 97, in addGroups ds.resolveDeps() File "/usr/lib/anaconda/yuminstall.py", line 303, in resolveDeps unresolved = self.tsCheck(unresolved) File "/usr/lib/anaconda/yuminstall.py", line 329, in tsCheck dep = self._provideToPkg(req) File "/usr/lib/anaconda/yuminstall.py", line 280, in _provideToPkg best = self.bestPackagesFromList(satisfiers)[0] IndexError: list index out of range
I get similar results when trying to do the same for ppc on x86_64.
Is this considered a bug in pkgorder? createrepo works fine cross-arch (or at least seems to do so). Should I file a bug?
On Thu, 2006-05-11 at 00:01 +0200, Axel Thimm wrote: *snip*
I get similar results when trying to do the same for ppc on x86_64.
Is this considered a bug in pkgorder? createrepo works fine cross-arch (or at least seems to do so). Should I file a bug?
The utils have not been made with cross-arch building in mind and will not work by design. I hope it will be remade to work cross arch but from what I saw when investigating it it would not be an easy task.
What I consider a bug however is that it does not just check arch and tell you it won't work. Would be much cleaner imho.
-HK
On Thu, 2006-05-11 at 09:05 +0200, Hans Kristian Rosbach wrote:
On Thu, 2006-05-11 at 00:01 +0200, Axel Thimm wrote: *snip*
I get similar results when trying to do the same for ppc on x86_64.
Is this considered a bug in pkgorder? createrepo works fine cross-arch (or at least seems to do so). Should I file a bug?
The utils have not been made with cross-arch building in mind and will not work by design. I hope it will be remade to work cross arch but from what I saw when investigating it it would not be an easy task.
Correct. We'd like to get there, but there's some non-trivial work to be done.
What I consider a bug however is that it does not just check arch and tell you it won't work. Would be much cleaner imho.
If it's not in bugzilla... ;-)
Seriously, file a bug and we can easily make it error out if you're running on an incompatible arch. But I know that by the time I finish catching up with mail, I will have forgotten about this.
Jeremy
On Mon, 2006-05-15 at 11:16 -0400, Jeremy Katz wrote:
On Thu, 2006-05-11 at 09:05 +0200, Hans Kristian Rosbach wrote:
What I consider a bug however is that it does not just check arch and tell you it won't work. Would be much cleaner imho.
If it's not in bugzilla... ;-)
Seriously, file a bug and we can easily make it error out if you're running on an incompatible arch. But I know that by the time I finish catching up with mail, I will have forgotten about this.
But what would I target it against?
I'd like it (and other anaconda bugs) fixed in FC5 tree, but you'd probably only want to touch the rawhide tree..
-HK