Re: qt5-qtwebengine-freeworld
Hm and what about cross-compiling ? I work in the embedded software ( we build mips and arm targets ), and we never ever considered native build, linaro provides excellent cross toolchains for arm ( we cross compile on a forked gentoo) I don't know how works an rpm buildsys but i'm fairly sure cross compiling some packages is possible Le 03/01/2018 à 05:29, Kevin Kofler a écrit : Karel Volný wrote: wouldn't "more of them" work better than "faster"? - once upon a time, I had been using distcc successfully ... but I don't know how hard it would be to set it up ... just an idea It is surely not easy to set up something like distcc with Koji. Also, parallelization helps only so much. The linking also takes a couple hours, and that cannot be parallelized. More physical RAM (!) and a faster CPU are the ways to speed that up. (I have been told that the armv7hl builders have only 2 GiB RAM. If that is correct, then having 4 GiB would surely help. More is not all that useful on 32-bit though.) Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: qt5-qtwebengine-freeworld
Karel Volný wrote: > wouldn't "more of them" work better than "faster"? > > - once upon a time, I had been using distcc successfully ... > > but I don't know how hard it would be to set it up ... just an idea It is surely not easy to set up something like distcc with Koji. Also, parallelization helps only so much. The linking also takes a couple hours, and that cannot be parallelized. More physical RAM (!) and a faster CPU are the ways to speed that up. (I have been told that the armv7hl builders have only 2 GiB RAM. If that is correct, then having 4 GiB would surely help. More is not all that useful on 32-bit though.) Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: qt5-qtwebengine-freeworld
Hi, The only other solution would be for RPM Fusion to get faster 32-bit ARM builders, wouldn't "more of them" work better than "faster"? - once upon a time, I had been using distcc successfully ... but I don't know how hard it would be to set it up ... just an idea K. -- Karel Volný BaseOS QE - Daemons Red Hat Czech, Brno tel. +420 532294274 (RH: +420 532294111 ext. 8262074) :: "Never attribute to malice what can :: easily be explained by stupidity." ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: qt5-qtwebengine-freeworld
Nicolas Chauvet wrote: > What's annoying in this situation is more that the armv7hl build > failed than that it took time to build. Well, the long build times can also be an annoyance, particularly when I'm trying to get out security updates to all releases in a timely manner… > For this specific issue, I (one?) can probably find the option to > raise the koji task timeout. … but if you are fine with builds running more than 2 days and if you're willing to raise the timeout accordingly (I'd put it at 72 hours to be safe), I can work with that. At least, 5.10.0 is not a security update, the security fixes are also in 5.9.3 that is already out in all supported releases (and even in F25, I got it through just before the EOL). But 5.10.1 or 5.9.4 builds will surely be needed soon for security. Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: qt5-qtwebengine-freeworld
On Tue, 2 Jan 2018 14:24:31 +0100 Nicolas Chauvet wrote: > 2018-01-02 12:53 GMT+01:00 Kevin Kofler : > > Sérgio Basto wrote: > .. > > The only other solution would be for RPM Fusion to get faster > > 32-bit ARM builders, but it doesn't look like that is going to > > happen any time soon, unfortunately. > > Few things: > > What's annoying in this situation is more that the armv7hl build > failed than that it took time to build. > For this specific issue, I (one?) can probably find the option to > raise the koji task timeout. it should be rpmbuild_timeout in kojid.conf, which gets translated to a mock option Dan ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: qt5-qtwebengine-freeworld
2018-01-02 12:53 GMT+01:00 Kevin Kofler : > Sérgio Basto wrote: .. > The only other solution would be for RPM Fusion to get faster 32-bit ARM > builders, but it doesn't look like that is going to happen any time soon, > unfortunately. Few things: What's annoying in this situation is more that the armv7hl build failed than that it took time to build. For this specific issue, I (one?) can probably find the option to raise the koji task timeout. Getting faster armv7hl builders is possible, getting faster builders hosted 24/7 online is another topic... Right now I'm testing what can be expected on various local builders compared with our infra builders. Thx -- - Nicolas (kwizart) ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: qt5-qtwebengine-freeworld
Sérgio Basto wrote: > Build of qt5-qtwebengine-freeworld failed with EXCEPTION: > [commandTimeoutExpired()] [1], when it was almost build after 48 hours > ... > I notice that only in arm, the build took more than 24 hours in others > builders in less of 5 hours, package is done. May you sometimes not > build in arm builder ? (just one ideia) . I don't know how to handle this mess. If I can't get this thing building without hitting timeouts, I'll have to ExcludeArch it on armv7hl, unfortunately. I am already turning off ALL Chromium debuginfo (because the linker runs out of memory otherwise), I don't think there's much more I can do to speed up things. Compiling with -Os instead of -O2, maybe? (-O0 would be fastest to compile, but then I guess it will fail to link again because of the increased size.) Building only some builds for ARM is not a workable solution: I will still end up with those builds running into timeouts (builds are only getting longer with every release, surely not shorter: we went from 24 hours in 5.8 to 36 hours in 5.9 and now 48 hours in 5.10), and in addition, the qt5- qtwebengine-freeworld version must match the qt5-qtwebengine version (because otherwise, qt5-qtwebengine-freeworld would have to include its own copy of the huge data files). The only other solution would be for RPM Fusion to get faster 32-bit ARM builders, but it doesn't look like that is going to happen any time soon, unfortunately. Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
qt5-qtwebengine-freeworld
Hi , Build of qt5-qtwebengine-freeworld failed with EXCEPTION: [commandTimeoutExpired()] [1], when it was almost build after 48 hours ... I notice that only in arm, the build took more than 24 hours in others builders in less of 5 hours, package is done. May you sometimes not build in arm builder ? (just one ideia) . Best regards and happy new year. [1] http://koji.rpmfusion.org/koji/getfile?taskID=187284&volume=DEFAULT&nam e=build.log&offset=-4000 -- Sérgio M. B. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: [x264] Update x264 to 0.152 and switch asm compiler from yasm to nasm
On Mon, 2018-01-01 at 22:32 +0100, Dominik 'Rathann' Mierzejewski wrote: > Hi, Sérgio. > Happy New Year! > > On Sunday, 31 December 2017 at 21:27, Sérgio Basto wrote: > [...] > > The mass rebuild is finished , I had many unexpected problems ... > > Could you describe those problems? 1 - x265 failed to build, quick fix for arm builds [1] , I think I should report it upstream. 2 - gstreamer-plugins-ugly.git gtkdoc-mktmp removed from gtk-doc [2] and the fix [3] 3 - mythtv, also failed to build , the work (more than just a fix) [4] 4 - libquicktime, found out that we have lots of new commits since 2012 (date of latest release ) , I used "git cvsimport" to exemplify it better [5] [1] https://pkgs.rpmfusion.org/cgit/free/x265.git/commit/?id=fd9b4d23ced757 a2655f71c51d9e50f0dfbf648c [2] https://bodhi.fedoraproject.org/updates/gtk-doc-1.26-1.fc27 [3] https://pkgs.rpmfusion.org/cgit/free/gstreamer-plugins-ugly.git/commit/ ?id=867f9c9fd3c0aec021f22069102ac262b9afa05b [4] https://pkgs.rpmfusion.org/cgit/free/mythtv.git/commit/?id=cbe3ef59d962 59570cdcc0afd71872d260dcc302 [5] https://github.com/sergiomb2/libquicktime/compare/1.2.4...master > Regards, > Dominik -- Sérgio M. B. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
