Re: [RFC] A change to the way packages are built
David Lang - 10:41 5.05.16 wrote: > On Thu, 5 May 2016, Michal Hrusecky wrote: > > > David Lang - 18:20 4.05.16 wrote: > > > Debian has ... > > > > Just for the sake of discussion and inspiration, how openSUSE does it's > > rolling > > release. We have OBS, which is server software, connected to multiple > > builders. > > It has projects and in those projects packages. Packages can have sources > > somewhere in the git and git hook can trigger rebuild. Builds are done in > > new > > cleanly installed environment (there is option to have some precached) > > which is > > afterward thrown away. When package is built, all packages in the project > > that > > depends on it are rebuild, unless there is no change to the package - it is > > binary same as the last one (somebody fixed coding style?). > > > > When package is send to Tumbleweed (rolling distro) it has to first build in > > the project it is submitted from, then it is put into staging project where > > it > > is built against clean Tumbleweed and packages depending on it from > > Tumbleweed > > are rebuild. Once done, staging project is run through automatic test and > > if > > it passes, it is merged. > > > > One more side note, OBS is opensource, it can build packages for multiple > > architectures and distributions (openSUSE, SUSE, RHEL, Debian, ...) and they > > accept patches to support more distributions :-) > > can it do cross-compiles? Should be able to, we used to use it at some point, but don't know any details. In openSUSE we first switched to qemu-user builds (to avoid all the troubles with cross-compilation) and later on to native workers (to speed up things). But OpenWRT/LEDE can do it on it's own and I wouldn't suggest throwing out current build system. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [RFC] A change to the way packages are built
David Lang - 18:20 4.05.16 wrote: > Debian has ... Just for the sake of discussion and inspiration, how openSUSE does it's rolling release. We have OBS, which is server software, connected to multiple builders. It has projects and in those projects packages. Packages can have sources somewhere in the git and git hook can trigger rebuild. Builds are done in new cleanly installed environment (there is option to have some precached) which is afterward thrown away. When package is built, all packages in the project that depends on it are rebuild, unless there is no change to the package - it is binary same as the last one (somebody fixed coding style?). When package is send to Tumbleweed (rolling distro) it has to first build in the project it is submitted from, then it is put into staging project where it is built against clean Tumbleweed and packages depending on it from Tumbleweed are rebuild. Once done, staging project is run through automatic test and if it passes, it is merged. One more side note, OBS is opensource, it can build packages for multiple architectures and distributions (openSUSE, SUSE, RHEL, Debian, ...) and they accept patches to support more distributions :-) ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: getting users involved in on-device testing
John Crispin - 9:39 5.05.16 wrote: > > > On 05/05/2016 09:10, Michal Hrusecky wrote: > > John Crispin - 8:56 5.05.16 wrote: > >> Hi, > >> > >> It would be nice if there was a process in place that would allow > >> community members to easily be able to test images on devices and report > >> the results some place. after some time thinking of different ways to do > >> this I came up with one possible solution and wanted to know what others > >> think about this. > >> > >> we setup a file similar to how the MAINTAINERS file in the kernel. > >> anyone can add his name/email and boards he would like to be a tester > >> of. every time an image is built for said board, an email is generated > >> and sent out to the according persons. this email would contains an otp. > >> with this credential you could then log into some web frontend and get a > >> simple mask along the lines of > >> > >> * wifi worked > >> * ethernet worked > >> * leds worked > >> * buttons worked > >> * iperf > >> * ssl benchmark > >> ... > >> > >> this could all be done in a rather trivial manner and i dont think the > >> work behind such a setup is really that huge. using otps would for > >> example eliminate the need for user credential management. results could > >> simply be stored in files on the backend and then harvested later by a > >> secondary script etc etc... > >> > >> next it would be possible to generate static content based on aggregated > >> data that will show a traffic light style support status for various > >> boards, listing when it was last tested, with what revision and what the > >> test results were. > >> > >> would something like this make sense ? > > > > It kinda makes sense, although it would be even nicer if the tests were > > automated as well. That is something that Purple is working on. There is a > > BoardFarm[1] test framework that is designed to test routers and there > > could be > > created test suites that reflects some of the criteria you described and in > > the > > best case, whenever image is produced, automatic test could be triggered and > > results uploaded. It outputs junit and there is plenty of parsers of junit > > - we > > have it nicely integrated in Jenkins. > > > > [1] https://github.com/qca/boardfarm > > i doubt they will test the 900+ boards. i would expect them to test > their own boards. Yes, they probably wouldn't but as the software is opensource anybody can deploy it and test his router. And they might end up have at some point test results for tenths of routers. The project is just starting. > additionally the proposal does not tell you how to test. it describes a > way to notify when testing is required and where the images are located. > i think you misread/understood the purpose of what i proposed or i > worded it badly. Yep I understand, I think that it is good idea. My mail was just to bring awareness that there is something that can be used quite nicely on the receiving end of those notifications to automate/speed up the testing and make it easier. So making it easy to reply automatically would be nice ;-) And also that it might be worth talking to and joining efforts with Prpl or Eric. Just to note that there is somebody trying to achieve pretty much similar results - having an idea how well OpenWRT/LEDE works on various routers ;-) ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: getting users involved in on-device testing
John Crispin - 8:56 5.05.16 wrote: > Hi, > > It would be nice if there was a process in place that would allow > community members to easily be able to test images on devices and report > the results some place. after some time thinking of different ways to do > this I came up with one possible solution and wanted to know what others > think about this. > > we setup a file similar to how the MAINTAINERS file in the kernel. > anyone can add his name/email and boards he would like to be a tester > of. every time an image is built for said board, an email is generated > and sent out to the according persons. this email would contains an otp. > with this credential you could then log into some web frontend and get a > simple mask along the lines of > > * wifi worked > * ethernet worked > * leds worked > * buttons worked > * iperf > * ssl benchmark > ... > > this could all be done in a rather trivial manner and i dont think the > work behind such a setup is really that huge. using otps would for > example eliminate the need for user credential management. results could > simply be stored in files on the backend and then harvested later by a > secondary script etc etc... > > next it would be possible to generate static content based on aggregated > data that will show a traffic light style support status for various > boards, listing when it was last tested, with what revision and what the > test results were. > > would something like this make sense ? It kinda makes sense, although it would be even nicer if the tests were automated as well. That is something that Purple is working on. There is a BoardFarm[1] test framework that is designed to test routers and there could be created test suites that reflects some of the criteria you described and in the best case, whenever image is produced, automatic test could be triggered and results uploaded. It outputs junit and there is plenty of parsers of junit - we have it nicely integrated in Jenkins. [1] https://github.com/qca/boardfarm ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
