Hi Jacco.
You can make a generic Makefile doing most of the steps. So "most" of your patches are at git.centos.org? but all patches are in SRPM's. I find working with SRPM annoying since I have to extract the SRPM to fetch/modify any patches. That is why I keep all my modifications in git. The labor is only intensive when a new release is out. Keeping updates build is not that high labor. BR, Bjarne Sendt fra Outlook<http://aka.ms/weboutlook> ________________________________ Fra: users <[email protected]> på vegne af Jacco Ligthart <[email protected]> Sendt: 27. september 2016 00:11 Til: [email protected] Emne: Re: [RedSleeve-Users] Redsleeve 7.2 release On 25-09-16 18:31, Bjarne Saltbæk wrote: Hi Jacco. On 25-09-2016 12:39, Jacco Ligthart wrote: Yayh, great work. Could you share all your work somewhere (is all work in the patches directory)?Have you stored it on Github or somewhere else? (feel free to use my git server at https://gitserver.dev.saltbaek.dk if you want). I think all is in the patches (or in own SRPMs). In the begin it took a lot of tinkering to get it all to compile. Especially all the missing dependencies. regarding git, I tried using git.centos.org but I find it a pain. Sometimes it does not create the SRPM and other times the SRPM it produces differs from the shipped version. I now use that git to create the patches, but the SRPM is created by applying the patch to a rpmbuild dir. hmm this sounds a bit vague ... it's something like this: - git clone https://git.centos.org/git/rpms/<rpm name>.git - git checkout c7 - git checkout -b redsleeve - apply previous patch - fix the errors (the patches never apply cleanly) - git commit - git format-patch c7 - rpm -i <rpm name>.src.rpm - apply patch - rpmbuild -bs <rpm name>.spec - mock <rpm name>-redsleeve.src.rpm Now that I write this, it sounds a little labor intensive. but there are not that many patched RPMs in RSEL7. If you have a better method, let me know. On 25-09-2016 12:39, Jacco Ligthart wrote: Hi All, Over the weekend I have been working on the 7.2 release. It was not that the underlying RPMs were not there, nor that they were not working, but it was just not logical to work with it. There are now 5 directories under 7.2: base, extra, patches, updates and upstream-extra: - base holds all the rebuild (and maybe changed) RPMs from the upstream vendor. (some packages are just a bit newer than upstream, I also included available updates at the time of release) - updates are the updates to that - extra is stuff that we add, think redsleeve-* packages, uboot, other arm specific things, build tools, etc. - upstream-extra is a partial rebuild from the extra stream of the upstream vendor. mostly the packages needed to build base are included - patches holds all patches to upstream RPMs I signed all packages with my redsleeve-testing key and made a new redsleeve-release package depending on that key. In short: if you already have Redsleeve7 working, please update the release rpm (http://ftp.redsleeve.org/pub/el7-devel/el7/7.2/extra/RPMS/redsleeve-release-7-2.1511.el7.2.armv5tel.rpm) and you should be good to go. (It still might take some time for all the mirrors to catch up) Next I went to make new images for the raspberrypi's (all models). I made new kernels based on Fabian's (of CentOS ARMv7 fame) SRPMs. These are actual builds (different from just packaging binary blobs, as I did previously). Fabian altered the .config file to allow for SELinux :) I also made a new raspberrypi-config package and new images (should be here later: http://www.mirrorservice.org/sites/ftp.redsleeve.org/pub/el7-devel/el7/rootfs/) Do you have the exact build process for those? I can supply boot-SD's for Odroid C1+, Banana PI M3 and the CuBox-i4x4 I would like to make the same updated boot-SD's for RSEL 6.8. Like I said previously, I use rbf (https://github.com/mndar/rbf/). I just downloaded that, created a raspberrypi redsleeve template (this is somewhere in an earlier mail) and the let it make the image by "./rbf.py build templates/<template name>.xml" just yesterday I tinkered a little with the script you can run after image creation. I added: echo "set autorelabel" touch $ROOTPATH/.autorelabel echo "remove rbf repos" rm $ROOTPATH/etc/yum.repos.d/*_rbf.repo echo "zero the disks freespace" dd if=/dev/zero of=$ROOTPATH/zero dd if=/dev/zero of=$ROOTPATH/boot/zero sync rm -f $ROOTPATH/zero $ROOTPATH/boot/zero These things are probably a good thing to store on git. We also have an empty org laying around in github: https://github.com/redsleeve-linux maybe that's a good location? I'm quite happy about the images, but there are a couple of open points in the whole setup, where I'd like some input: * I found out after the fact that the current kernel cannot uninstall itself. Of course I'll make an update soon. The question is, if this a reason to pull this RPM now? Nah, if just the updates fixes it. Over the weekend I have succeeded building a working kernel from the upstream ( http://vault.centos.org/6.8/os/Source/SPackages/kernel-2.6.32-642.el6.src.rpm ) so I assume that the upstream guys have done some proper post script ;) I was aware that the upstream kernel src.rpm now just builds on redsleeve. but it only produces kernel-headers. while nice, this hardly counts as a kernel. for what device is this kernel? Gordan always said that 2.6 could only support kirkwood, but none of the other arm devices. It is still a work-in-progress - still needs some tweaks here and there - you can follow the progress at - https://gitserver.dev.saltbaek.dk/summary/?r=rsel6/kernel-raspberrypi.git and https://gitserver.dev.saltbaek.dk/summary/?r=rsel6/kernel.git OK I read this, you put a new (4.4.22) source in the old redhat spec. Please have a look at what Fabian and I have been doing: http://armv7.dev.centos.org/repodir/arm-kernels/rpi2-4.4.14/ https://lists.centos.org/pipermail/arm-dev/2016-September/002283.html * Fabian made the kernel make an initramfs with dracut. This won't work well with previous images, due to /boot size. Does any of you know why you'd like a initramfs, if the machine boots perfectly fine without? (how to test if it is used at all?) I (and I guess Fabian) needs the initramfs temporary to create the U-Boot file uInitrd my SPEC code is: dracut --force --verbose %{buildroot}/boot/initramfs-%{version}-%{release}.img %{version}-%{release} mkimage -A arm -O linux -T ramdisk -C none -n %{version}-%{release} -d %{buildroot}/boot/initramfs-%{version}-%{release}.img %{buildroot}/boot/uInitrd-%{version}-%{release} After the uInitrd is created I do not need the initramfs anymore (just to lazy to delete it from the /boot partition =:-o ) point is that raspberry pi does not use u-boot. all the images I got from others don't have a (u)initrd and my machines boots perfectly without. Are there other reasons than must-do-for-booting ? * the new kernel allows for SELinux. if you update a machine to it, you could end with a SELinux enabled machine on a filesystem without labels. (It will disallow bash ...) any idea on how to prevent such a scenario? * I could not make a labeled filesystem with RBF. I added .autorelabel to the image. now the first boot takes a couple of minutes while the sytem relabels. Is this acceptable? * The image is made with RBF. RBF will create some files itself, notably /etc/fstab and /etc/sysconfig/network-scripts/ifcfg-eth0 These files were earlier part of raspberrypi-config. I removed them from that package. This works well for new images. But for updates these files could be lost on update. Anyone an idea on how not to delete files if the RPM gets updated? Release an intermediate "old" package with preservation code so rpm makes .rpmsave backups when upgraded. .rpmsave is no good. we *need* those files. with that name. hmm, looking at this: http://stackoverflow.com/questions/22456217/rpm-scriptlet-ordering-for-install-remove-upgrade-using-yum I could do something with %pre and %posttrans. copy a backup first and then as very last step move it back. that is maybe not that strange. * the image throws a small error on boot about missing the /var/lock/ppp directory. The dir should be part of the ppp package. ppp is needed because NetworkManager depends on it. I guess on install time there is something wrong with the /var/run symlink. /var/run is tmpfs at install time maybe? maybe, I think it might also link outside the install_root. I wondered if there are more exceptions, but I now don't think so. I'll try to add another mkdir to the post image creation script. "yum reinstall ppp" fixes the issue. I am not sure what the correct fix is here. Apparently ppp just does a "mkdir -p /var/lock/ppp" as post install script. I'll try to do something similar as part of RBF's finalize script. The plan for the coming time is: - update all odroid kernels, see if I can also build them (vs package binary blobs) see if they also can do SELinux - update the odroid-release package and sign all odroid packages - make images for the odroids - update epel-release and sign all packages -> which key to use? redsleeve-testing? or a new one specific for epel? well it is sort of a part of the distribution, right? So the redsleeve-testing. I think the signing should follow the build system AKA yours. If I get clearance to distribute redsleeve packages i will use my own key for my buildsystem. - build RSEL 7.3 if upstream finishes their beta testing. (anyone knows how to get SRPMs from the beta program? that would speedup the whole process) ftp://ftp.redhat.com/redhat/linux/enterprise/7Server/en/os/README Current sources for Red Hat Enterprise Linux 7 have been moved to the following location: https://git.centos.org/project/rpms yup, I use those, but beta is not there. Red Hat Enterprise Linux customers can obtain the RHEL 7 SRPMS in the Red Hat Customer Portal: https://access.redhat.com/site/downloads/. You can download them using a web browser or using yum-utils on a rhel7 system. I do have a company RHEL account, but I do not think I am allowed to distribute anything from inside the Customer Portal. Screenshots maybe ;) I guess I'm going to try to send them a polite request. - do the yearly epel refresh I do mine every day and they get build at http://koji.dev.saltbaek.dk at 04.00 UTC. Want the script? :D yes please. how do you make a repo of it after building? I notice epel repo's normally don't hold old versions of rpm's. how do you get them out? looking at your koji, I notice odroidc1plus-3.10.103-1.20160919gitc6c2cf7 which is a sort of a coincidence, as I was working yesterday on odroidxu3-kernel-3.10.103-2.20160926gitee5e188 maybe this is also a good candidate for a git. specially because the centos-arm people are probably also interested. Some of these items should, I guess, also make it to the wiki / bugzilla. I'm however a bit lost there. Me too Github tickets (or the ticket system in my Gitblit might be better). yup let's use the github thing. Jacco
_______________________________________________ users mailing list [email protected] https://lists.redsleeve.org/mailman/listinfo/users
