On 19-08-16 23:40, Bjarne Saltbæk wrote: > > Hi Gordan. > > > On 19-08-2016 10:49, Gordan Bobic wrote: >> On 2016-08-18 18:32, Bjarne Saltbæk wrote: >>> Hi Gordan and Jacco. >>> >>>> True, this is an issue, particularly with repository syncing. The >>>> discrepancy in part comes from the fact that building and signing >>>> are separate steps in the process >>> >>> Here is where Koji have its advantage. My koji installation signs the >>> package automatically in the end of the build process. >> >> Indeed, but my big ARM machine is internet facing, and I am not >> entirely comfortable keeping the signing keys on a machine that >> isn't air gapped. >> > > You can do the semi paranoid thing and put two netcards (or just two > VLAN's on the same netcard) in the Sigul Bridge. > Then connect one VLAN to the internet, one VLAN to a transport subnet > to your Sigul Server. > This is the intended way and this isolates the Sigul Server with the > pgp signing key from the network. > The completely paranoid is to shut down /remove the Sigul Server when > not in use (if you those so I think you should make some email > notification when there are packages waiting for signing). > > > >> I'm in the same boat, I haven't had a chance to touch anything >> RSEL related in weeks. :-( >> >> I think there is a lot of value in having an automated system >> churning out package updates as and when they appear upstream. >> Even if there are FTBFS packages, if we have a list of those >> somewhere visible, then whoever from the community needs them >> can step up and fix them. >> >> I've been thinking about this a lot and the more I think about >> it the more I am leaning toward putting everything on github. >> > My experience with Gitblit (which I like very much) is that storing > bigger files in git makes "git clone" break down (I think something > with HTTP Chunked not correct implemented in Gitblit). > Dunno if the same applies for Github. > I prefer to do the same as Fedoraproject - store .spec file and > patches in Git, store tarballs outside on a filestore. > >>> I have not spent time on EL7 but why not joining forces with the >>> CentOS7 arm team? Is there any problem with that? >> >> It is already happening to a large extent. They took a whole >> bunch of Jacco's patches to fix various EL7 FTBFS issue on ARM >> a while back, and since CentOS is effectively our upstream for >> EL7, we are benefiting from any fixes they apply. >> > > By the way. Isn't CentOS 7 ARM entirely focusing on 64-bit on ARMv8 ? > If so we could focus on 32-bit RSEL7 (CentOS 7 ARMv6,ARMv7l) ? > Isn't RSEL7 32-bit compiled? (it runs on ARMv6 and ARMv7l....)
I think there are two distinct CentOS ARM projects: * one is indeed for ARMv8 (aarch64). They want to standardize on one kernel (newer then std CentOS) and only support that kernel and UEFI. https://wiki.centos.org/SpecialInterestGroup/AltArch/AArch64 * one is for ARMv7 https://wiki.centos.org/SpecialInterestGroup/AltArch/Arm32 They are (like us) building on top of kernels supplied by the vendor of the specific board. RSEL7 is ARMv5 compiled and works also on 6 and 7. I guess it'll also work on 8, but that is yet untested. Jacco
_______________________________________________ users mailing list [email protected] https://lists.redsleeve.org/mailman/listinfo/users
