For the record, I tried it on several different pis, 3, and some 2s, even underclocked a 2 a little bit (to 800mhz from 900mhz) to see if maybe it was just unstable, or if the heat might've been getting to it. Got it to go through 1 package before locking up that way. Jacco, you built on a pi, could you perhaps give me some info on how you had yours set up, packages, etc.?
On Wed, Apr 20, 2016 at 7:03 PM, Mark Campbell < [email protected]> wrote: > So I've been busy, but I finally got a little time to try out mock. Do > you guys have problems with mock locking up on you? Invariably within the > first couple of packages, I get complete lockup, no response from numlock, > nothing. have to power off the pi3 for 10 seconds before I can get it to > come back up. I've left this pi doing stuff for days otherwise, with no > lockups, so I figure it's gotta be something to do with mock. Suggestions? > > On Sat, Apr 9, 2016 at 10:23 AM, Mark Campbell < > [email protected]> wrote: > >> Wow, quite a few responses. I'll try to sum up my response. >> >> Regarding arm64, I was not aware that CentOS/RHEL had arm64. In that >> case, I may try them out for my 64 bit Pi sometime. >> >> Regarding mock, I did not realize that about rpms getting different >> results based on extra packages. My attempts at building the whole repo >> were merely an exercise designed at getting the missing packages, so that >> if I were to build updates to existing packages, I'd already have the deps >> installed. But at your advice, I will scrap what I have, and try >> mock/koji. With mock/koji, do I still need to install packages like I did, >> or does it require a different method to get those packages? >> >> Also, given that I've got some similar concerns about SD wear, I was >> considering mounting a share from my main server to do the actual builds >> in. Would that be workable in a chroot env that is getting destroyed and >> rebuilt all the time? >> On Apr 9, 2016 07:45, "Gordan Bobic" <[email protected]> wrote: >> >> On 09/04/16 12:07, Bjarne Saltbæk wrote: >> >>> >>> >>> > > Does mock / Koji use rpmbuild as its base? >>> > >>> > Koju uses mock to create a minimal dependency chroot. Inside that >>> > minimal dependency chroot, it uses rpmbuild to rebuild the src.rpm. >>> or from at Makefile in a SCM (git, svn or git) just to clarify :) :) >>> > However, if you are asking if koji is more clever about the build >>> order >>> > in the sense that it will figure out the dependency tree and build the >>> > dependees before dependers, no, it won't. >>> Yea and no. No In that sense that it will just build a package as >>> mock/rpmbuild. >>> Yes in that sense that it has a feature - "chainbuild". I have not tried >>> it yet. but as I read it, you can define a build task as a chain of >>> builds. In this way you can build dependencies for a package before you >>> (in the end of the chain) build the package. Very neat for build >>> bootstrapping an OS. >>> >> >> I don't think it works out the dependency chains itself, though. >> >> >> > 1) I don't think there is any benefit in duplicating their work now >>> that >>> > they have finally caught up with us after 5 years. That just seems >>> like >>> > a huge waste of time where it isn't necessary, and they are at least >>> > better funded (IIRC some of their maintainers are on the PNAELV >>> payroll, >>> > and get paid for it, rather than doing it only in their spare time >>> like >>> > we do here). >>> Agreed. Let the CentOS guys maintain the 64-bit arm RHEL-based OS and >>> RSEL focus on 32-bit arm OS. I assume there will still be a need for 32 >>> bit arm support for a long time. >>> >> >> Yes and no. There is an armv7hl build of CentOS 7. It is running my plex >> server in a docker container on an CentOS 7 aarch64, so I know it works OK >> for server tasks at least. >> >> The main use cases for RSEL are: >> >> 1) If you want to use EL6 on ARM, we are the only option (for all those >> who detest systemd enough to not upgrade for as long as possible). >> >> 2) If you are on pre-ARMv7 hardware, we are the only option for EL6 or >> EL7. That means all the *Plug hardware (ARMv5), R-Pi 1 (ARMv6), and various >> NAS-es, e.g. QNAP TS-421 which was until recently my main internet facing >> server. >> >> 3) If you don't feel armv7hl build of CentOS 7 is quite there yet (there >> are packages missing, and thanks to Jacco we have the only working EL 7.2 >> where gnome isn't broken. Having said that, I expect the CentOS guys to >> absorb those changes soon. >> >> My main annoyance about soft-float ARM at the moment is closed source >> video drivers. For example, ARM only provide hard-float Linux Mali drivers >> (but they provide soft-float Android drivers). And in that boat, Nvidia >> only provide 32-bit hard-float drivers (but not 32-bit soft-float nor >> 64-bit ones, and my thread on the Nvidia developer forum requesting 64-bit >> drviers got deleted). >> >> But that's a whole different thread. >> >> >> Gordan >> _______________________________________________ >> users mailing list >> [email protected] >> https://lists.redsleeve.org/mailman/listinfo/users >> >> > > > -- > --Mark > -- --Mark
_______________________________________________ users mailing list [email protected] https://lists.redsleeve.org/mailman/listinfo/users
