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
_______________________________________________ users mailing list [email protected] https://lists.redsleeve.org/mailman/listinfo/users
