Re: [Slackbuilds-users] Help offer
On 11/06/2016 12:47 PM, David Spencer wrote: > So the outline idea would be > - a submission arrives Will we be able to download submissions from the pending queue? That's a question to SlackBuilds.org maintainers :-) https://slackbuilds.org/pending/ > - our bot checks if it's a simple update, and how many packages > depend on it -- including optional deps ;) slpkg can do this (based on REQUIRES). Short example with virt-manager: # slpkg -t sbo virt-manager --check-deps Resolving dependencies... Done + | Package virt-manager dependencies : + \ +---[ Tree of dependencies ] | +--1: vala is dependency --> gtk-vnc, libosinfo, libvirt-glib, spice-gtk, virt-manager, virt-viewer, vte3 | +--2: celt051 is dependency --> spice, spice-gtk, virt-manager | +--3: pyparsing is dependency --> spice, spice-gtk, virt-manager | +--4: six is dependency --> spice, spice-gtk, virt-manager | +--5: spice-protocol is dependency --> spice, spice-gtk, virt-manager | +--6: spice is dependency --> spice-gtk, virt-manager | +--7: yajl is dependency --> libvirt, libvirt-glib, libvirt-python, virt-manager | +--8: urlgrabber is dependency --> libvirt, libvirt-glib, libvirt-python, virt-manager | +--9: libvirt is dependency --> libvirt-glib, libvirt-python, virt-manager | +--10: libosinfo is dependency --> virt-manager | +--11: libvirt-glib is dependency --> virt-manager | +--12: libvirt-python is dependency --> virt-manager | +--13: gnome-python2-gconf is dependency --> virt-manager | +--14: tunctl is dependency --> virt-manager | +--15: ipaddr-py is dependency --> virt-manager | +--16: python-urllib3 is dependency --> virt-manager | +--17: python-requests is dependency --> virt-manager | +--18: gtk-vnc is dependency --> virt-manager, virt-viewer | +--19: spice-gtk is dependency --> virt-manager | +--20: vte3 is dependency --> virt-manager > - if it's a simple update, and the total expected build time > (including depending packages) is less than a threshold, throw all > those builds and rebuilds at the automatic build queue (I already have > a database of build times) > - if possible, do builds with multiple build tools (sbopkg sbotools > slackrepo) because diverse tests catch more problems And don't forget about slpkg: https://github.com/dslackw/slpkg > - do some automated tests on the final package (e.g. Heinz's lintpkg) https://github.com/pprkut/lintpkg -- Thomas Szteliga smime.p7s Description: S/MIME Cryptographic Signature ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/
Re: [Slackbuilds-users] Help offer
On 06/11/16 12:47, David Spencer wrote: I have some ideas for automated builds of pending submissions, but that is > for separate discussion (and I don't know how you admins are handling it > now). Awesome! I'm sending this to the list because it needs to be sanity checked by everybody else :) As far as I know several people have been thinking independently about automated testing, continuous integration, etc I haven't discussed this with anybody until now, but maybe buildbot could be useful to us. Unless I've made a mistake reading the buildbot docs, it would allow people to volunteer their own systems as build hosts. There are a couple of things we would need to worry about - clean build environment, authentication - but the idea would seem to fit a project like SlackBuilds.org that tries to exist with minimum infrastructure of our own. So the outline idea would be - a submission arrives - our bot checks if it's a simple update, and how many packages depend on it -- including optional deps ;) - if it's a simple update, and the total expected build time (including depending packages) is less than a threshold, throw all those builds and rebuilds at the automatic build queue (I already have a database of build times) - if possible, do builds with multiple build tools (sbopkg sbotools slackrepo) because diverse tests catch more problems - do some automated tests on the final package (e.g. Heinz's lintpkg) - if the automatic builds fail, the submitter (maintainer) can see what happened and resubmit - otherwise flag it for manual testing - final approval always a human decision I've got a draft SlackBuild for buildbot-0.9.1, but since 0.9 it's one of those packages that need to download huge quantities of npm stuff at build time :( Anyway I'd love to make some progress on this today, but I have a wedding to go to -- not mine :) Thanks! -D. You have outlined more than less what I've been thinking of ;-) But I wonder if there could be a case where the update is not checked by human at all. Assume it's a version bump. Then you only make sure that the only part changed in the download link is version string. The check for version can be very strict, e.g. it has to change from 0.1 to 0.2 so it won't change from 0.1 to 0.$(screw up the system). When it comes to automated build systems, there is also https://jenkins.io/ But I've been thinking about rolling our own too. -- Best regards, Andrzej Telszewski ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/
Re: [Slackbuilds-users] Help offer
> I can offer some man power. > Please contact me by e-mail. > [...] > > I have some ideas for automated builds of pending submissions, but that is > for separate discussion (and I don't know how you admins are handling it > now). Awesome! I'm sending this to the list because it needs to be sanity checked by everybody else :) As far as I know several people have been thinking independently about automated testing, continuous integration, etc I haven't discussed this with anybody until now, but maybe buildbot could be useful to us. Unless I've made a mistake reading the buildbot docs, it would allow people to volunteer their own systems as build hosts. There are a couple of things we would need to worry about - clean build environment, authentication - but the idea would seem to fit a project like SlackBuilds.org that tries to exist with minimum infrastructure of our own. So the outline idea would be - a submission arrives - our bot checks if it's a simple update, and how many packages depend on it -- including optional deps ;) - if it's a simple update, and the total expected build time (including depending packages) is less than a threshold, throw all those builds and rebuilds at the automatic build queue (I already have a database of build times) - if possible, do builds with multiple build tools (sbopkg sbotools slackrepo) because diverse tests catch more problems - do some automated tests on the final package (e.g. Heinz's lintpkg) - if the automatic builds fail, the submitter (maintainer) can see what happened and resubmit - otherwise flag it for manual testing - final approval always a human decision I've got a draft SlackBuild for buildbot-0.9.1, but since 0.9 it's one of those packages that need to download huge quantities of npm stuff at build time :( Anyway I'd love to make some progress on this today, but I have a wedding to go to -- not mine :) Thanks! -D. ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/
[Slackbuilds-users] Help offer
Hi, I can offer some man power. Please contact me by e-mail. I feel most comfortably with C/C++ packages. I can build test in QEMU/slackrepo clean environment. I can go about i486 -> i586 migration and test build, but I'm not limited to it. We can settle something over e-mail. I'm C/C++ programmer too, if that was of help. As I mentioned before, I did a bit of PHP extension writing. I'm also somehow familiar with libarchive, that could be handy to process and/or inspect the submission archive at the time of landing in pending queue. I have some ideas for automated builds of pending submissions, but that is for separate discussion (and I don't know how you admins are handling it now). We all don't have time, so I'm not gonna tell how little of it I have :-^ P.S. Don't feel offended but proposals to change something. Nobody is rude here and most importantly nobody can push you to implement the change. Proposals are what they are, proposals. We all have different needs and wishes, and proposals are about fulfilling those wishes. It probably does not happen here that somebody comes with completely stupid idea/request. I am aware of the fact that if I propose something, it is very likely that I will have to spent my personal time on it. And I am prepared for that. And again, it does not have to all happen at once. Cheers :-) -- Best regards, Andrzej Telszewski ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/
