Guillaume Rousse wrote: > Stefan van der Eijk wrote: > >>Guillaume Rousse wrote: >> >>>>Anssi Hannula wrote: >>>> >>>>>The only permanent & good solution to this problem is having some sort >>>>>of automated or semi-automated system to rebuild PLF packages for x86_64. >> >>>>Anyone wanting to integrate an already existing build bot (such as LBD, >>>>[il]urt, anything else) in our current procedures (not just saying: it >>>>is running on my own box, i'll take care of everything) is welcome to >>>>propose it. >> >>I'm willing to *try* to get lbd to work. the last time I tried there >>were some rpm challenges to deal with. I've lost interest in >>building older distro's due to compatability problems with the >>different rpmdb versions (native system vs lbd chroot). Perhaps one >>of the rpm hackers has a smart solution for it... >> >>At the moment I'm rebuilding cooker plf packages on my box at home: >> >>http://eijk.homelinux.org/build/i586/cooker_plf-free/ >>http://eijk.homelinux.org/build/i586/cooker_plf-non-free/ >> >>I have an upload process that can upload the resulting binary rpm's. >> >>I'm willing to share the config files I'm using, etc. > > That is exactly what I had in mind by "not just saying...". The point is > not to ask someone what he will do, but how this will impact other > people (both maintainers and admins) life... > > The main issue here is: do we want both automated and manual build for a > given distrib/arch target (as does currently mandriva) ?
> I personaly think that is a bad idea. We should try to have only one > primary manual target (cooker/i586), and rebuild automatically for a > maximum number of other targets, without manual upload allowed. +1 > The second issue is: once we know what we want, how do we enforce it > through our tools ? > > In a first time, I'd try to define a target list where monitored target > would appear, with the name of one only responsible, and define him as > the only one authorized uploader, no matter he's using a bot or not, by > convention first, enforcing through some kind of ACLs second. > In a second time, we could develop some kind of upload procedure more > adapted to an automated process rather than a program running from a > shell account. Sounds good to me. However, the current situation of some src.rpms being in Mandriva tree and on some of those only some resulting binary rpms are uploaded to plf (e.g. with vlc plf build many plugins are the same as in mdk build so they are not uploaded (however they *are* uploaded to 2006.0)) is quite complex for any bots to handle (afaics Stefan's bot misses those too). We need to either simplify things or come up with some way to tell the bots what binary rpms to upload and what not. Also, do we agree that *all* packages should be backported to latest stable (e.g. 2006.0)? As the chroots are now offline, many rpms do not get rebuilt for anything else than cooker-i586. I do have scripts that allow easy rebuilding of packages for other targets, but as I'm not able to thouroughly test every package, I'm hesitant to do uploads unless you confirm they should all be backported. If they do not, we also need a way to inform the bots on which targets the srpm should be build. I also made a (hacky, unfortunately) bot, which rebuilds plf packages for x86_64 distros in iurt-style chroot environment. It currently builds packages for target if the i586 equivalent is also present (e.g. if the rpm is present in 2006.0-i586, rebuild it also for 2006.0-x86_64, and if present in cooker-i586 => rebuild for cooker-x86_64), but as there now are many packages that should be backported on i586 but are not, this is not a good way to detect if the x86_64 backport is needed. -- Anssi Hannula _______________________________________________ PLF-discuss mailing list [email protected] https://www.zarb.org/mailman/listinfo/plf-discuss
