It seems like it's been almost a month since the last update on this subject. I've got a fanless 32-bit "network server" (VIA C7 processor) that I'd love to upgrade to CentOS 7.
So how can I help?
Thanks!
On 09/10/2014 05:37 PM, Ian Pilcher wrote:
It seems like it's been almost a month since the last update on this subject. I've got a fanless 32-bit "network server" (VIA C7 processor) that I'd love to upgrade to CentOS 7.
So how can I help?
All of the updates and rpms we are building for 7 are dual arch'd - and will have their 32bit components built as well, eg: http://buildlogs.centos.org/c7-updates/procmail/20140910115138/
so if you were to hit the repo's at buildlogs, you should be able to workout what is missing, once we have that list we can start doing some manual builds.
howse that for a place to start from ? Also, remember, we dont need -everything- we just need enough to build the installer, and do a minimal install. Thats the basic minimal we need to get in order to call the rest a distro.
regards
On 09/10/2014 05:51 PM, Karanbir Singh wrote:
All of the updates and rpms we are building for 7 are dual arch'd - and will have their 32bit components built as well, eg: http://buildlogs.centos.org/c7-updates/procmail/20140910115138/
so if you were to hit the repo's at buildlogs, you should be able to workout what is missing, once we have that list we can start doing some manual builds.
howse that for a place to start from ? Also, remember, we dont need -everything- we just need enough to build the installer, and do a minimal install. Thats the basic minimal we need to get in order to call the rest a distro.
Sounds good in theory. I see a bunch of directories with packages in them on that site. Is there any way to get a better idea of what's there? (Even a list of all the files would be helpful.)
Or should I just mirror the c7.00.04 and c7-updates directories?
Thanks!
On 09/11/2014 12:40 AM, Ian Pilcher wrote:
Sounds good in theory. I see a bunch of directories with packages in them on that site. Is there any way to get a better idea of what's there? (Even a list of all the files would be helpful.)
Or should I just mirror the c7.00.04 and c7-updates directories?
you will need .02 and .03 as well - but use something like reposync so you only end up with the latest builds for all the packages ( quite a few pkgs were built multiple times )
in terms of a 'what should we have list' - look at the x86_64 tree, eg: http://mirror.centos.org/centos/7/os/x86_64/Packages/
ofcourse the noarch ones we dont need to redo, we can just borrow over. And there might be some which are x86_64 only. Most of the rest should be on the 'desired' list. Of this desired list, the i686 ones that are already in the x86_64 tree can also be borrowed, giving you a delta on whats pending.
- KB
On 09/10/2014 05:51 PM, Karanbir Singh wrote:
so if you were to hit the repo's at buildlogs, you should be able to workout what is missing, once we have that list we can start doing some manual builds.
So I've decided to take the approach of getting a mock-based build environment set up, which led me to wanting to get yum installed inside the chroot, which led me to my first missing package -- python-pycurl.
I now have a shiny new python-pycurl-7.19.0-17.el7.i686.rpm, built in a 32-bit CentOS 7 chroot.
What should I do with it?
Thanks!
On 09/11/2014 11:26 PM, Ian Pilcher wrote:
On 09/10/2014 05:51 PM, Karanbir Singh wrote:
so if you were to hit the repo's at buildlogs, you should be able to workout what is missing, once we have that list we can start doing some manual builds.
So I've decided to take the approach of getting a mock-based build environment set up, which led me to wanting to get yum installed inside the chroot, which led me to my first missing package -- python-pycurl.
I now have a shiny new python-pycurl-7.19.0-17.el7.i686.rpm, built in a 32-bit CentOS 7 chroot.
What should I do with it?
Setup a local yum repo on your machine, and keep adding the ones you build there, and use the repos from buildlogs.centos.org/ as a back-stop for everything else. At some point you are going to need to attempt a kernel build as well....
Keep a track of what fails and what is missing, we can then workout a way for you to feed that back into the system and from there into buildlogs. Stuff is a bit hectic till the middle of next week, at which point we can have a go at making this happen. I suspect it might take you a few days to get to a stage of relative confidence!
On 09/11/2014 05:30 PM, Karanbir Singh wrote:
Keep a track of what fails and what is missing, we can then workout a way for you to feed that back into the system and from there into buildlogs. Stuff is a bit hectic till the middle of next week, at which point we can have a go at making this happen. I suspect it might take you a few days to get to a stage of relative confidence!
FYI, here's my initial take on what's missing ...
autofs blas64 blas64-devel blas64-static cmpi-bindings-pywbem esc fence-sanlock glusterfs glusterfs-api glusterfs-api-devel glusterfs-devel glusterfs-fuse glusterfs-libs glusterfs-rdma gnome-abrt gnome-boxes gnome-python2 gnome-python2-bonobo gnome-python2-canvas gnome-python2-devel gnome-python2-gconf gnome-python2-gnome gnome-python2-gnomevfs gnome-weather gnu-efi gnu-efi-devel gnu-efi-utils grub2-efi hyperv-daemons hypervkvpd hypervvssd ibus-chewing ibus-hangul ibus-libpinyin ibus-m17n ibus-rawcode ibus-sayura infinipath-psm infinipath-psm-devel inkscape inkscape-docs inkscape-view java-1.6.0-openjdk java-1.6.0-openjdk-demo java-1.6.0-openjdk-devel java-1.6.0-openjdk-javadoc java-1.6.0-openjdk-src kernel-debug kernel-debug-devel kernel-tools kernel-tools-libs kernel-tools-libs-devel lapack64 lapack64-devel lapack64-static libguestfs libguestfs-devel libguestfs-gobject libguestfs-gobject-devel libguestfs-java libguestfs-java-devel libguestfs-tools-c libipathverbs libipathverbs-static libtsan libtsan-static libvirt-daemon-driver-qemu libvirt-daemon-kvm libvirt-lock-sanlock lua-guestfs mokutil mpitests-mvapich2-psm mvapich2-psm mvapich2-psm-devel nautilus-sendto ocaml-libguestfs ocaml-libguestfs-devel ocaml-libvirt ocaml-libvirt-devel open-vm-tools open-vm-tools-desktop open-vm-tools-devel perl-Sys-Guestfs perl-XML-LibXML pesign python-libguestfs qemu-kvm qemu-kvm-common qemu-kvm-tools ras-utils ruby-libguestfs samba-vfs-glusterfs sanlock sanlock-devel sanlock-lib sanlock-python sblim-wbemcli seabios seabios-bin seavgabios-bin sgabios shim shim-unsigned spice-server spice-server-devel supermin supermin-helper syslinux syslinux-devel syslinux-extlinux syslinux-perl syslinux-tftpboot tboot transfig virt-top xorg-x11-server-Xspice
I'm ignoring package versions and releases for this comparison on the (possibly naïve) assumption that the key to getting the OS bootstrapped is getting *any* version from upstream built. (This, of course, means that the kernel isn't listed, because of kernel-3.10.0-121.el7.i686.rpm.)
Looking at a minimal 64-bit install, the only missing packages are kernel-tools and kernel-tools-libs.
On 09/11/2014 05:30 PM, Karanbir Singh wrote:
At some point you are going to need to attempt a kernel build as well....
FYI, I've successfully built kernel-3.10.0-123.6.3.el7.i686.rpm (and friends), using kernel-3.10.0-i686.config from 3.10.0-121.el7. I had to unset CONFIG_PARAVIRT to work around this error:
kernel/sched/cputime.c: In function 'steal_account_process_tick': kernel/sched/cputime.c:273:3: error: implicit declaration of function 'jiffies_to_nsecs' [-Werror=implicit-function-declaration] this_rq()->prev_steal_time += cputime_to_nsecs(steal_ct); ^
With a bit of SPEC file surgery, I got kernel-tools and kernel-tools-libs to build. IIRC, this means that every package in the minimal install has at least some sort of 32-bit package.
On 09/12/2014 12:00 AM, Ian Pilcher wrote:
FYI, I've successfully built kernel-3.10.0-123.6.3.el7.i686.rpm (and friends), using kernel-3.10.0-i686.config from 3.10.0-121.el7. I had to unset CONFIG_PARAVIRT to work around this error:
W00t!
https://twitter.com/ipilcher/status/510551441908301824/photo/1
On 09/12/2014 12:00 AM, Ian Pilcher wrote:
FYI, I've successfully built kernel-3.10.0-123.6.3.el7.i686.rpm (and friends), using kernel-3.10.0-i686.config from 3.10.0-121.el7. I had to unset CONFIG_PARAVIRT to work around this error:
kernel/sched/cputime.c: In function 'steal_account_process_tick': kernel/sched/cputime.c:273:3: error: implicit declaration of function 'jiffies_to_nsecs' [-Werror=implicit-function-declaration] this_rq()->prev_steal_time += cputime_to_nsecs(steal_ct); ^
I figured this error out.
http://bugs.centos.org/view.php?id=7592
On 13/09/14 08:35, Ian Pilcher wrote:
On 09/12/2014 12:00 AM, Ian Pilcher wrote:
FYI, I've successfully built kernel-3.10.0-123.6.3.el7.i686.rpm (and friends), using kernel-3.10.0-i686.config from 3.10.0-121.el7. I had to unset CONFIG_PARAVIRT to work around this error:
kernel/sched/cputime.c: In function 'steal_account_process_tick': kernel/sched/cputime.c:273:3: error: implicit declaration of function 'jiffies_to_nsecs' [-Werror=implicit-function-declaration] this_rq()->prev_steal_time += cputime_to_nsecs(steal_ct); ^
I figured this error out.
Cool, keep up the good work :-) Johnny was (busy) at Fossetcon but I'm sure he'll have a look at all that, and it would be good to integrate that into git.centos.org corresponding repositories.
Cheers,
On 09/13/2014 01:35 AM, Ian Pilcher wrote:
On 09/12/2014 12:00 AM, Ian Pilcher wrote:
FYI, I've successfully built kernel-3.10.0-123.6.3.el7.i686.rpm (and friends), using kernel-3.10.0-i686.config from 3.10.0-121.el7. I had to unset CONFIG_PARAVIRT to work around this error:
kernel/sched/cputime.c: In function 'steal_account_process_tick': kernel/sched/cputime.c:273:3: error: implicit declaration of function 'jiffies_to_nsecs' [-Werror=implicit-function-declaration] this_rq()->prev_steal_time += cputime_to_nsecs(steal_ct); ^
I figured this error out.
Ian,
Thanks very much for the hard work .. we are going to also need syslinux.
Since 5.11 just dropped, we need to concentrate on that for the next several days, but once that is done we can work more on c7 i686.
Great Job sor far.
Thanks, Johnny Hughes
On 09/18/2014 10:40 AM, Johnny Hughes wrote:
Thanks very much for the hard work .. we are going to also need syslinux.
Just built it in my 32-bit C7 VM. All I had to do was change the ExclusiveArch line in the SPEC file.
On Thu, 2014-09-11 at 17:26 -0500, Ian Pilcher wrote:
On 09/10/2014 05:51 PM, Karanbir Singh wrote:
so if you were to hit the repo's at buildlogs, you should be able to workout what is missing, once we have that list we can start doing some manual builds.
So I've decided to take the approach of getting a mock-based build environment set up, which led me to wanting to get yum installed inside the chroot, which led me to my first missing package -- python-pycurl.
I now have a shiny new python-pycurl-7.19.0-17.el7.i686.rpm, built in a 32-bit CentOS 7 chroot.
What should I do with it?
You could also look at smock that builds chains of packages and places them into a self hosted repo to be used as part of the build chain process. Or you could look at mockchain which does similar however I think it requires you to figure out the build dependencies yourself. I received some code from Seth way back that took a pile of RPMS and would break it out into ordering and grouping so you could build a whole bunch in parallel in groups if you had the infrastructure. I think it had the potential to have issues apparently something to do with the nature of build dependencies. However its always served me well. If you want a copy of it I can put it up someplace. I also have a modified version of smock that could build multiple packages in threads or in multiple sub processes if you want those versions instead of whatever you find online. I submitted a patch upstream but really have no idea if it was merged as I think smock is essentially dead when it comes to new devel but it works so I keep using it.
-
Fabian Arrotin -
Ian Pilcher -
Johnny Hughes -
Karanbir Singh -
Nathanael d. Noblet