[arch-dev-public] Automated rebuild for ncurses 6.0 in progress
You can follow the progress at: https://rebuilds.foutrelis.com/ If anyone wants to tackle a build failure, you can commit the fix in /trunk (without bumping pkgrel) and then click on the failing package and select "Retry build task". Note: This rebuild is not listed on https://www.archlinux.org/todo/ in order to avoid any confusion.
On 06.09.2015 19:02, Evangelos Foutras wrote:
You can follow the progress at: https://rebuilds.foutrelis.com/
If anyone wants to tackle a build failure, you can commit the fix in /trunk (without bumping pkgrel) and then click on the failing package and select "Retry build task".
Note: This rebuild is not listed on https://www.archlinux.org/todo/ in order to avoid any confusion.
Looks awesome. How exactly is this down? Did you setup jenkins etc.? Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com
On 06/09/15 21:18, Pierre Schmitz wrote:
On 06.09.2015 19:02, Evangelos Foutras wrote:
You can follow the progress at: https://rebuilds.foutrelis.com/
If anyone wants to tackle a build failure, you can commit the fix in /trunk (without bumping pkgrel) and then click on the failing package and select "Retry build task".
Note: This rebuild is not listed on https://www.archlinux.org/todo/ in order to avoid any confusion.
Looks awesome. How exactly is this down? Did you setup jenkins etc.?
Greetings,
Pierre
The source is hosted at https://github.com/foutrelis/arch-rebuilds It currently requires some manual setup at the start of a rebuild; steps are roughly: 1) Create a new arch_rebuilds database and copy a few tables from the live archweb database. 2) Import the list of packages to be rebuilt using mkrebuild.pl; at this point you also specify which packages are going to be built manually before the rebuild starts (in this case: ncurses, lib32-ncurses, readline and bash; the latter two due to bootstrapping issues). 3) After the above is done, multiple packagers can start rebuilding stuff by running builder/build.sh. The build.sh script queries the web service for a package to build, it bumps its pkgrel, builds and releases the package into the respective staging repo. (Builders are authenticated using a database-stored token and also need to use the private mirror on nymeria to receive updates immediately.)
Evangelos Foutras <evangelos@foutrelis.com> on Sun, 2015/09/06 20:02:
You can follow the progress at: https://rebuilds.foutrelis.com/
If anyone wants to tackle a build failure, you can commit the fix in /trunk (without bumping pkgrel) and then click on the failing package and select "Retry build task".
Note: This rebuild is not listed on https://www.archlinux.org/todo/ in order to avoid any confusion.
Looks like this is stuck at the moment. An kind of dependency loop between python and gdb? -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Chris get my mail address: */=0;b=c[a++];) putchar(b-1/(/* gcc -o sig sig.c && ./sig */b/42*2-3)*42);}
On 07/09/15 16:30, Christian Hesse wrote:
Evangelos Foutras <evangelos@foutrelis.com> on Sun, 2015/09/06 20:02:
You can follow the progress at: https://rebuilds.foutrelis.com/
If anyone wants to tackle a build failure, you can commit the fix in /trunk (without bumping pkgrel) and then click on the failing package and select "Retry build task".
Note: This rebuild is not listed on https://www.archlinux.org/todo/ in order to avoid any confusion.
Looks like this is stuck at the moment. An kind of dependency loop between python and gdb?
Python needed two patches to build but it's done now. There is indeed a dependency cycle between python and gdb; it's not an issue but gdb will be rebuilt once more in the following (now, current) batch.
On 06/09/15 20:02, Evangelos Foutras wrote:
You can follow the progress at: https://rebuilds.foutrelis.com/
If anyone wants to tackle a build failure, you can commit the fix in /trunk (without bumping pkgrel) and then click on the failing package and select "Retry build task".
Note: This rebuild is not listed on https://www.archlinux.org/todo/ in order to avoid any confusion.
Just a heads up that the rebuilds should be done very soon. Before moving everything to the testing repos, we need to be mindful of the following: 1) TeXLive 2015 is currently in [testing] but only texlive-bin is part of the rebuilds. Therefore, we must wait until TeXLive 2015 leaves [testing] before moving the ncurses stuff out of the staging repos. 2) vagrant repackages upstream binaries and contains two files that link to libncursesw.so.5: opt/vagrant/embedded/lib/ruby/2.0.0/x86_64-linux/readline.so opt/vagrant/embedded/lib/ruby/2.0.0/x86_64-linux/curses.so 3) cuda repackages upstream binaries and contains one file linking to libncurses.so.5: opt/cuda/bin/cuda-gdb The above packages may or may not work properly after the move; depends on whether the binaries/libraries linking to old ncurses are important to their function. Personally, I feel that cuda can be left as is. Vagrant on the other hand, being open source, can most likely be changed to build from source instead of repackaging upstream binaries. I'll poke both packages' maintainers on IRC to see what we can do.
On Fri, Sep 11, 2015 at 12:14 AM, Evangelos Foutras <evangelos@foutrelis.com> wrote:
1) TeXLive 2015 is currently in [testing] but only texlive-bin is part of the rebuilds. Therefore, we must wait until TeXLive 2015 leaves [testing] before moving the ncurses stuff out of the staging repos.
Done.
2) vagrant repackages upstream binaries and contains two files that link to libncursesw.so.5:
opt/vagrant/embedded/lib/ruby/2.0.0/x86_64-linux/readline.so opt/vagrant/embedded/lib/ruby/2.0.0/x86_64-linux/curses.so
Fixed.
3) cuda repackages upstream binaries and contains one file linking to libncurses.so.5:
opt/cuda/bin/cuda-gdb
Won't fix.
The above packages may or may not work properly after the move; depends on whether the binaries/libraries linking to old ncurses are important to their function.
Personally, I feel that cuda can be left as is. Vagrant on the other hand, being open source, can most likely be changed to build from source instead of repackaging upstream binaries. I'll poke both packages' maintainers on IRC to see what we can do.
Rebuilds are now in testing!
Hi Evangelos On Mon, Sep 7, 2015 at 1:02 AM, Evangelos Foutras <evangelos@foutrelis.com> wrote:
You can follow the progress at: https://rebuilds.foutrelis.com/
If anyone wants to tackle a build failure, you can commit the fix in /trunk (without bumping pkgrel) and then click on the failing package and select "Retry build task".
Note: This rebuild is not listed on https://www.archlinux.org/todo/ in order to avoid any confusion.
Thanks for this fast automatic rebuild. Majority rebuilds can be done this way, I would love to see this tool used more often. Currently we have python35 rebuild with 500+ packages. To finish this rebuild requires a lot of time from developers. I wonder if your magic tool can be utilized again.
On Sat, Sep 19, 2015 at 1:45 PM, Anatol Pomozov <anatol.pomozov@gmail.com> wrote:
python35 rebuild with 500+ packages. To finish this rebuild requires a lot of time from developers. I wonder if your magic tool can be utilized again.
We went with a todo list for this rebuild because some PKGBUILDs hardcoded the 3.4 Python version and others discarded failures during check(). (Felix pointed out that new test failures might be missed because of this if rebuilds were to be done automatically.) That said, I'm currently doing some automated Python 3.5 rebuilds after having special-cased the above scenarios in the builder script. [1] It seems to be going ok although there are several failures which need to be looked into. [1] https://github.com/foutrelis/arch-rebuilds/commit/6137d2269669
participants (4)
-
Anatol Pomozov
-
Christian Hesse
-
Evangelos Foutras
-
Pierre Schmitz