[arch-dev-public] rebuilding the whole core repo
A new glibc 2.7 is out and it's time to build a new toolchain. After each major glibc and gcc update it's recommended to rebuild every pkg. Only that way you can make sure to get latest (speed) improvements and fixes. This is no problem for all non-rolling release distros. So far we haven't done this before. But now we should try. ArchLinux community strongly depends on good internet connections. So for most parts of the users this will be no problem. My suggestion: 1) We rebuild the core repo. It's small enough to start there. We run a script increasing the pkgrel, run makeworld and upload everything to testing. I'm not sure if makeworld {core,lib,devel,support} will run through. We should test it. We could still hack a simple script doing the makepkg calls one by one in the order we like. After some testing this whole bunch of packages would move to core. Both needs to be done for i686 and x86_64. 2) The extra cleanup should be done meanwhile. 3) Rebuild extra repo and fix or kick broken packages. I could offer some systems to do the rebuilds. I only have slow upload bandwidth. Thoughts? How could help out? -Andy
On Sat, 20 Oct 2007 13:36:41 +0200 Andreas Radke <a.radke@arcor.de> wrote:
A new glibc 2.7 is out and it's time to build a new toolchain. After each major glibc and gcc update it's recommended to rebuild every pkg. Only that way you can make sure to get latest (speed) improvements and fixes. This is no problem for all non-rolling release distros. So far we haven't done this before. But now we should try.
ArchLinux community strongly depends on good internet connections. So for most parts of the users this will be no problem.
My suggestion:
1) We rebuild the core repo. It's small enough to start there.
We run a script increasing the pkgrel, run makeworld and upload everything to testing. I'm not sure if makeworld {core,lib,devel,support} will run through. We should test it. We could still hack a simple script doing the makepkg calls one by one in the order we like. After some testing this whole bunch of packages would move to core. Both needs to be done for i686 and x86_64.
2) The extra cleanup should be done meanwhile.
3) Rebuild extra repo and fix or kick broken packages.
I could offer some systems to do the rebuilds. I only have slow upload bandwidth.
Thoughts? How could help out?
-Andy
I can help out. I have a good upload connection and I can offer some free time in the evenings. The script for automatically increasing the pkgrel have you get already from me. For need of other scripts, just let me know. I can hack something together. I think the process you described for rebuilding the whole core repo first is ok. I think, we should try it. Daniel
Daniel Isenmann wrote:
On Sat, 20 Oct 2007 13:36:41 +0200 Andreas Radke <a.radke@arcor.de> wrote:
A new glibc 2.7 is out and it's time to build a new toolchain. After each major glibc and gcc update it's recommended to rebuild every pkg. Only that way you can make sure to get latest (speed) improvements and fixes. This is no problem for all non-rolling release distros. So far we haven't done this before. But now we should try.
ArchLinux community strongly depends on good internet connections. So for most parts of the users this will be no problem.
My suggestion:
1) We rebuild the core repo. It's small enough to start there.
We run a script increasing the pkgrel, run makeworld and upload everything to testing. I'm not sure if makeworld {core,lib,devel,support} will run through. We should test it. We could still hack a simple script doing the makepkg calls one by one in the order we like. After some testing this whole bunch of packages would move to core. Both needs to be done for i686 and x86_64.
2) The extra cleanup should be done meanwhile.
3) Rebuild extra repo and fix or kick broken packages.
I could offer some systems to do the rebuilds. I only have slow upload bandwidth.
Thoughts? How could help out?
-Andy
I can help out. I have a good upload connection and I can offer some free time in the evenings. The script for automatically increasing the pkgrel have you get already from me.
Same here, got some time and machines to use for that. Just sent me a list of packages once we have a way to organize the action. Cheers, -A
On Sat, 20 Oct 2007 22:17:32 +0200 Daniel Isenmann <daniel.isenmann@gmx.de> wrote:
On Sat, 20 Oct 2007 13:36:41 +0200 Andreas Radke <a.radke@arcor.de> wrote:
A new glibc 2.7 is out and it's time to build a new toolchain. After each major glibc and gcc update it's recommended to rebuild every pkg. Only that way you can make sure to get latest (speed) improvements and fixes. This is no problem for all non-rolling release distros. So far we haven't done this before. But now we should try.
ArchLinux community strongly depends on good internet connections. So for most parts of the users this will be no problem.
My suggestion:
1) We rebuild the core repo. It's small enough to start there.
We run a script increasing the pkgrel, run makeworld and upload everything to testing. I'm not sure if makeworld {core,lib,devel,support} will run through. We should test it. We could still hack a simple script doing the makepkg calls one by one in the order we like. After some testing this whole bunch of packages would move to core. Both needs to be done for i686 and x86_64.
2) The extra cleanup should be done meanwhile.
3) Rebuild extra repo and fix or kick broken packages.
I could offer some systems to do the rebuilds. I only have slow upload bandwidth.
Thoughts? How could help out?
-Andy
I can help out. I have a good upload connection and I can offer some free time in the evenings. The script for automatically increasing the pkgrel have you get already from me.
For need of other scripts, just let me know. I can hack something together.
I think the process you described for rebuilding the whole core repo first is ok. I think, we should try it.
I think, as well, for this we need to make sure that NOTHING is in testing before we begin - ie. everything has been pushed back to core or extra. That will ensure that the PKGBUILDs in CVS are all in a consistent state. I could probably contribute some CPU power to this effort. If we're feeling REALLY ambitious, this would be a great time to fix all the licenses in our packages - we still have over 1000 bad licenses in extra - attached file shows packages that need work. -- Travis
Sunday 21 October 2007, Travis Willard wrote: | On Sat, 20 Oct 2007 22:17:32 +0200 | | Daniel Isenmann <daniel.isenmann@gmx.de> wrote: | > On Sat, 20 Oct 2007 13:36:41 +0200 | > | > Andreas Radke <a.radke@arcor.de> wrote: | > > A new glibc 2.7 is out and it's time to build a new toolchain. | > > After each major glibc and gcc update it's recommended to | > > rebuild every pkg. Only that way you can make sure to get | > > latest (speed) improvements and fixes. This is no problem for | > > all non-rolling release distros. So far we haven't done this | > > before. But now we should try. | > > | > > ArchLinux community strongly depends on good internet | > > connections. So for most parts of the users this will be no | > > problem. | > > | > > My suggestion: | > > | > > 1) We rebuild the core repo. It's small enough to start there. | > > | > > We run a script increasing the pkgrel, run makeworld and | > > upload everything to testing. | > > I'm not sure if makeworld {core,lib,devel,support} will run | > > through. We should test it. We could still hack a simple | > > script doing the makepkg calls one by one in the order we | > > like. After some testing this whole bunch of packages would | > > move to core. Both needs to be done for i686 and x86_64. | > > | > > 2) The extra cleanup should be done meanwhile. | > > | > > 3) Rebuild extra repo and fix or kick broken packages. | > > | > > I could offer some systems to do the rebuilds. I only have | > > slow upload bandwidth. | > > | > > Thoughts? How could help out? | > > | > > -Andy | > | > I can help out. I have a good upload connection and I can offer | > some free time in the evenings. The script for automatically | > increasing the pkgrel have you get already from me. | > | > For need of other scripts, just let me know. I can hack | > something together. | > | > I think the process you described for rebuilding the whole core | > repo first is ok. I think, we should try it. | | I think, as well, for this we need to make sure that NOTHING is in | testing before we begin - ie. everything has been pushed back to | core or extra. That will ensure that the PKGBUILDs in CVS are all | in a consistent state. i agree. we should wait for testing to empty and then freeze the updating while rebuilding everything. one option would be to split it in stages... and spread them over e.g. 2 months, so that users do not have to download once a huge load of pkgs. (some providers limit ammount of free traffick) | If we're feeling REALLY ambitious, this would be a great time to | fix all the licenses in our packages - we still have over 1000 bad | licenses in extra - attached file shows packages that need work. good idea... regarding your list i have some items: * we should have the MIT licence in our common licences folder * we should add all possible CC licences in our common licences folder ... maybe informing creative commons that we support their full scheme of licencing in our licence handling (public relations, networking *g*) * LGPL2 = LGPL2.1 ? and if some pkg uses 2.0? our LGPL2 is indeed the 2.1 version * some pkgs have licence-formatting issues (Apache instead of APACHE or gpl instead of GPL ... we change the formating? licences are all-caps always?) - D -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><
On Mon, 22 Oct 2007 15:00:59 +0200, Damir Perisa wrote
Sunday 21 October 2007, Travis Willard wrote: | On Sat, 20 Oct 2007 22:17:32 +0200 | | Daniel Isenmann <daniel.isenmann@gmx.de> wrote: | > On Sat, 20 Oct 2007 13:36:41 +0200 | > | > Andreas Radke <a.radke@arcor.de> wrote: | > > A new glibc 2.7 is out and it's time to build a new toolchain. | > > After each major glibc and gcc update it's recommended to | > > rebuild every pkg. Only that way you can make sure to get | > > latest (speed) improvements and fixes. This is no problem for | > > all non-rolling release distros. So far we haven't done this | > > before. But now we should try. | > > | > > ArchLinux community strongly depends on good internet | > > connections. So for most parts of the users this will be no | > > problem. | > > | > > My suggestion: | > > | > > 1) We rebuild the core repo. It's small enough to start there. | > > | > > We run a script increasing the pkgrel, run makeworld and | > > upload everything to testing. | > > I'm not sure if makeworld {core,lib,devel,support} will run | > > through. We should test it. We could still hack a simple | > > script doing the makepkg calls one by one in the order we | > > like. After some testing this whole bunch of packages would | > > move to core. Both needs to be done for i686 and x86_64. | > > | > > 2) The extra cleanup should be done meanwhile. | > > | > > 3) Rebuild extra repo and fix or kick broken packages. | > > | > > I could offer some systems to do the rebuilds. I only have | > > slow upload bandwidth. | > > | > > Thoughts? How could help out? | > > | > > -Andy | > | > I can help out. I have a good upload connection and I can offer | > some free time in the evenings. The script for automatically | > increasing the pkgrel have you get already from me. | > | > For need of other scripts, just let me know. I can hack | > something together. | > | > I think the process you described for rebuilding the whole core | > repo first is ok. I think, we should try it. | | I think, as well, for this we need to make sure that NOTHING is in | testing before we begin - ie. everything has been pushed back to | core or extra. That will ensure that the PKGBUILDs in CVS are all | in a consistent state.
i agree. we should wait for testing to empty and then freeze the updating while rebuilding everything. one option would be to split it in stages... and spread them over e.g. 2 months, so that users do not have to download once a huge load of pkgs. (some providers limit ammount of free traffick)
Good plan - people probably wouldn't appreciate downloading their entire system again in a single -Syu... but then there'll still be some people who wait 2 or 3 months to upgrade, so we can't accomodate everyone, unfortunately.
| If we're feeling REALLY ambitious, this would be a great time to | fix all the licenses in our packages - we still have over 1000 bad | licenses in extra - attached file shows packages that need work.
good idea... regarding your list i have some items:
* we should have the MIT licence in our common licences folder
* we should add all possible CC licences in our common licences folder ... maybe informing creative commons that we support their full scheme of licencing in our licence handling (public relations, networking *g*)
Regarding the above two, I'm all for adding common licenses (MIT, CC) to the licenses package, provided we can - I remember some licenses that are pretty common actually differ in their text from package to package (ie. the devs of the software need to add their own info for copyrights or something) - we can't really provide a common license for those.
* LGPL2 = LGPL2.1 ? and if some pkg uses 2.0? our LGPL2 is indeed the 2.1 version
How significant are the differences between 2.0 and 2.1? Isn't our GPL2 license 2.1 as well?
* some pkgs have licence-formatting issues (Apache instead of APACHE or gpl instead of GPL ... we change the formating? licences are all-caps always?)
The script I used to generate that list checked, for each license in licenses, is it "custom"? If not, then does a folder structure exist at /usr/share/licenses/common/${license}? If no, then it's invalid. Since the folders in /usr/share/licenses/common are capitalized, I think the entries in the license array should be as well. -- Travis
2007/10/22, Travis Willard <travisw@wmpub.ca>:
On Mon, 22 Oct 2007 15:00:59 +0200, Damir Perisa wrote
Sunday 21 October 2007, Travis Willard wrote: | If we're feeling REALLY ambitious, this would be a great time to | fix all the licenses in our packages - we still have over 1000 bad | licenses in extra - attached file shows packages that need work.
good idea... regarding your list i have some items:
* we should have the MIT licence in our common licences folder
* we should add all possible CC licences in our common licences folder ... maybe informing creative commons that we support their full scheme of licencing in our licence handling (public relations, networking *g*)
Regarding the above two, I'm all for adding common licenses (MIT, CC) to the licenses package, provided we can - I remember some licenses that are pretty common actually differ in their text from package to package (ie. the devs of the software need to add their own info for copyrights or something) - we can't really provide a common license for those.
From Arch Packaging Standards: The MIT, BSD, zlib/libpng and Python licenses are special cases and cannot be included in the 'common' licenses pkg. For the sake of the license variable, it's treated like a common license (license=('BSD'), license=('MIT'), license=('ZLIB') or license=('Python')) but for the sake of the filesystem, it's a custom license, because each one has its own copyright line. Each MIT, BSD, zlib/libpng or Python licensed package should have its unique license stored in /usr/share/licenses/$pkgname/.
* LGPL2 = LGPL2.1 ? and if some pkg uses 2.0? our LGPL2 is indeed the 2.1 version
How significant are the differences between 2.0 and 2.1? Isn't our GPL2 license 2.1 as well?
There is GPL 2.0 but no 2.1. There is LGPL 2.1 and no 2.0. Check FSF site. ;) We should add [L]GPL 3 licenses, AFAIR there are already packages with these licenses. -- Roman Kyrylych (Роман Кирилич)
* we should have the MIT licence in our common licences folder
The MIT license is like the BSD license in that it's customized per package.
* we should add all possible CC licences in our common licences folder ... maybe informing creative commons that we support their full scheme of licencing in our licence handling (public relations, networking *g*)
Our original policy was to only distribute a common license in our license package if it was used by two or more packages. Do any of our packages have CC licenses?
* LGPL2 = LGPL2.1 ? and if some pkg uses 2.0? our LGPL2 is indeed the 2.1 version
I didn't know there was a difference between LGPL2 and LGPL2.1. Do more than two packages use the LGPL2.0?
* some pkgs have licence-formatting issues (Apache instead of APACHE or gpl instead of GPL ... we change the formating? licences are all-caps always?)
That's how I wrote the namcap rule. License data should have the same case as the common license directory. Jason
On Sat, 20 Oct 2007 22:17:32 +0200 Daniel Isenmann <daniel.isenmann@gmx.de> wrote:
On Sat, 20 Oct 2007 13:36:41 +0200 Andreas Radke <a.radke@arcor.de> wrote:
A new glibc 2.7 is out and it's time to build a new toolchain. After each major glibc and gcc update it's recommended to rebuild every pkg. Only that way you can make sure to get latest (speed) improvements and fixes. This is no problem for all non-rolling release distros. So far we haven't done this before. But now we should try.
ArchLinux community strongly depends on good internet connections. So for most parts of the users this will be no problem.
My suggestion:
1) We rebuild the core repo. It's small enough to start there.
We run a script increasing the pkgrel, run makeworld and upload everything to testing. I'm not sure if makeworld {core,lib,devel,support} will run through. We should test it. We could still hack a simple script doing the makepkg calls one by one in the order we like. After some testing this whole bunch of packages would move to core. Both needs to be done for i686 and x86_64.
2) The extra cleanup should be done meanwhile.
3) Rebuild extra repo and fix or kick broken packages.
I could offer some systems to do the rebuilds. I only have slow upload bandwidth.
Thoughts? How could help out?
-Andy
I can help out. I have a good upload connection and I can offer some free time in the evenings. The script for automatically increasing the pkgrel have you get already from me.
For need of other scripts, just let me know. I can hack something together.
I think the process you described for rebuilding the whole core repo first is ok. I think, we should try it.
Daniel
I have made a little script, which increase pkgrel and rebuild the whole core repo after increasing. At the moment I'm testing the script, it need some more improvements and error handling. It is realized with makeworld, which work great for this task. Let me do some more work on it. After the first run, I will post here some showstoppers for automatic rebuilds (e.g. source not found or wrong md5sums and such things for fixing it in the PKGBUILD). Daniel
2007/11/6, Daniel Isenmann <daniel.isenmann@gmx.de>:
I have made a little script, which increase pkgrel and rebuild the whole core repo after increasing. At the moment I'm testing the script, it need some more improvements and error handling. It is realized with makeworld, which work great for this task.
Let me do some more work on it. After the first run, I will post here some showstoppers for automatic rebuilds (e.g. source not found or wrong md5sums and such things for fixing it in the PKGBUILD).
Does it increment pkgrel=1.1 correcty too? -- Roman Kyrylych (Роман Кирилич)
On Tue, 6 Nov 2007 18:20:59 +0200 "Roman Kyrylych" <roman.kyrylych@gmail.com> wrote:
2007/11/6, Daniel Isenmann <daniel.isenmann@gmx.de>:
I have made a little script, which increase pkgrel and rebuild the whole core repo after increasing. At the moment I'm testing the script, it need some more improvements and error handling. It is realized with makeworld, which work great for this task.
Let me do some more work on it. After the first run, I will post here some showstoppers for automatic rebuilds (e.g. source not found or wrong md5sums and such things for fixing it in the PKGBUILD).
Does it increment pkgrel=1.1 correcty too?
Yes, it increment it to pkgrel=2 in your example.
On Nov 6, 2007 10:32 AM, Daniel Isenmann <daniel.isenmann@gmx.de> wrote:
On Tue, 6 Nov 2007 18:20:59 +0200 "Roman Kyrylych" <roman.kyrylych@gmail.com> wrote:
2007/11/6, Daniel Isenmann <daniel.isenmann@gmx.de>:
I have made a little script, which increase pkgrel and rebuild the whole core repo after increasing. At the moment I'm testing the script, it need some more improvements and error handling. It is realized with makeworld, which work great for this task.
Let me do some more work on it. After the first run, I will post here some showstoppers for automatic rebuilds (e.g. source not found or wrong md5sums and such things for fixing it in the PKGBUILD).
Does it increment pkgrel=1.1 correcty too?
Yes, it increment it to pkgrel=2 in your example.
Even if it isn't fully complete, feel free to post it here for people to look it over and offer suggestions and maybe help. Of course, we don't want another bikeshed here, but a second (and third and...) set of eyes always helps. makeworld itself may outdated as well- it is packaged with pacman, but we haven't touched it since June. <http://code.toofishes.net/gitweb.cgi?p=pacman.git;a=history;f=scripts/makeworld.in;h=23976b5e4635b951ff5c20e3225165b49fad7bdd;> -Dan
On Tue, 6 Nov 2007 17:32:48 +0100 Daniel Isenmann <daniel.isenmann@gmx.de> wrote:
Let me do some more work on it. After the first run, I will post here some showstoppers for automatic rebuilds (e.g. source not found or wrong md5sums and such things for fixing it in the PKGBUILD).
Ok, here is a first list of packages which have wrong sources, md5sums or dependencies. Only for category "core/base", rest is following (maybe tonight or tomorrow): e2fsprogs: makedepends on 'bc', which is in extra file: failure on getting source, server doesn't exist anymore gcc-libs: ==> Starting build()... You need the de_DE locale to build gcc. ==> ERROR: Build Failed. Aborting... very strange!!!! glibc: failure on getting source, wrong: ftp://ftp.archlinux.org/other/glibc-patches-2.7-3.tar.bz2 right: ftp://ftp.archlinux.org/other/glibc/glibc-patches-2.7-3.tar.bz2 iputils: makedepends on 'jade', which is in extra kernel26: wrong md5sum for file config klibc-extras: failure on getting source, wrong: http://ftp.archlinux.org/other/klibc-extras/klibc-extras-2.3.tar.bz2 right: ftp://ftp.archlinux.org/other/klibc-extras/klibc-extras-2.3.tar.bz2 pacman: makedepend on 'doxygen', which is in extra reiserfsprogs: failure on getting source, connection timed out on server syslog-ng: makedepend on 'glib2', which is in extra vi: ----snip--- having patch file:7.1.147 having patch file:7.1.148 Number of patches does not match the patchlevel! Edit the PKGBUILD accordingly! ==> ERROR: Build Failed. Aborting... That's all from core/base. I'm not saying, that I'm totally right on that, but that are the errors which makepkg/makeworld reported.
Even if it isn't fully complete, feel free to post it here for people to look it over and offer suggestions and maybe help. Of course, we don't want another bikeshed here, but a second (and third and...) set of eyes always helps.
Sure I can, but it is only very small. What I have said, need some improvements. It was just a proof of concepts, if an automated rebuild of a repo is scriptable. I know, that makeworld is a little bit outdated, but it works very well for this. Here it comes: ---------------begin---------------- #!/bin/bash #increment all pkgrel for i in `find -name PKGBUILD`;do #getting pkgrel number after = package_pkgrel=`cat $i | grep pkgrel= | cut -d'=' -f 2` #extract number before dot in pkgrel beforedot=`echo $package_pkgrel | cut -n -d'.' -f 1` #add 1 to pkgrel new_pkgrel=$[$beforedot+1] #write it back to PKGBUILD sed -i "s:pkgrel=${package_pkgrel}:pkgrel=${new_pkgrel}:g" $i done build base makeworld -S -r -i --noconfirm -c -f ~/packages_rebuild base -------------end-------------------- Daniel
On Tue, 2007-11-06 at 18:41 +0100, Daniel Isenmann wrote:
On Tue, 6 Nov 2007 17:32:48 +0100 Daniel Isenmann <daniel.isenmann@gmx.de> wrote:
Let me do some more work on it. After the first run, I will post here some showstoppers for automatic rebuilds (e.g. source not found or wrong md5sums and such things for fixing it in the PKGBUILD).
Ok, here is a first list of packages which have wrong sources, md5sums or dependencies. Only for category "core/base", rest is following (maybe tonight or tomorrow):
e2fsprogs: makedepends on 'bc', which is in extra file: failure on getting source, server doesn't exist anymore gcc-libs: ==> Starting build()... You need the de_DE locale to build gcc. ==> ERROR: Build Failed. Aborting... very strange!!!!
gcc/gcc-libs will build a compiler and library with incorrect locale methods if de_DE is not present on the system. This is because of some test in configure that checks for the locale.
glibc: failure on getting source, wrong: ftp://ftp.archlinux.org/other/glibc-patches-2.7-3.tar.bz2 right: ftp://ftp.archlinux.org/other/glibc/glibc-patches-2.7-3.tar.bz2 iputils: makedepends on 'jade', which is in extra kernel26: wrong md5sum for file config klibc-extras: failure on getting source, wrong: http://ftp.archlinux.org/other/klibc-extras/klibc-extras-2.3.tar.bz2 right: ftp://ftp.archlinux.org/other/klibc-extras/klibc-extras-2.3.tar.bz2 pacman: makedepend on 'doxygen', which is in extra reiserfsprogs: failure on getting source, connection timed out on server syslog-ng: makedepend on 'glib2', which is in extra vi: ----snip--- having patch file:7.1.147 having patch file:7.1.148 Number of patches does not match the patchlevel! Edit the PKGBUILD accordingly! ==> ERROR: Build Failed. Aborting...
We should have some way to force the patchlevel. If we want 7.1.147, we get 7.1.147 and not 7.1.148 with a forced updated pkgrel. What if we want to force-downgrade to a specific revision because a later patch is buggy? We can't.
On Tue, 6 Nov 2007, Daniel Isenmann wrote:
On Tue, 6 Nov 2007 17:32:48 +0100 Daniel Isenmann <daniel.isenmann@gmx.de> wrote:
Let me do some more work on it. After the first run, I will post here some showstoppers for automatic rebuilds (e.g. source not found or wrong md5sums and such things for fixing it in the PKGBUILD).
Ok, here is a first list of packages which have wrong sources, md5sums or dependencies. Only for category "core/base", rest is following (maybe tonight or tomorrow):
e2fsprogs: makedepends on 'bc', which is in extra file: failure on getting source, server doesn't exist anymore gcc-libs: ==> Starting build()... You need the de_DE locale to build gcc. ==> ERROR: Build Failed. Aborting... very strange!!!! glibc: failure on getting source, wrong: ftp://ftp.archlinux.org/other/glibc-patches-2.7-3.tar.bz2 right: ftp://ftp.archlinux.org/other/glibc/glibc-patches-2.7-3.tar.bz2 iputils: makedepends on 'jade', which is in extra kernel26: wrong md5sum for file config klibc-extras: failure on getting source, wrong: http://ftp.archlinux.org/other/klibc-extras/klibc-extras-2.3.tar.bz2 right: ftp://ftp.archlinux.org/other/klibc-extras/klibc-extras-2.3.tar.bz2 pacman: makedepend on 'doxygen', which is in extra reiserfsprogs: failure on getting source, connection timed out on server syslog-ng: makedepend on 'glib2', which is in extra vi: ----snip--- having patch file:7.1.147 having patch file:7.1.148 Number of patches does not match the patchlevel! Edit the PKGBUILD accordingly! ==> ERROR: Build Failed. Aborting...
That's all from core/base. I'm not saying, that I'm totally right on that, but that are the errors which makepkg/makeworld reported.
Even if it isn't fully complete, feel free to post it here for people to look it over and offer suggestions and maybe help. Of course, we don't want another bikeshed here, but a second (and third and...) set of eyes always helps.
Sure I can, but it is only very small. What I have said, need some improvements. It was just a proof of concepts, if an automated rebuild of a repo is scriptable. I know, that makeworld is a little bit outdated, but it works very well for this. Here it comes:
---------------begin---------------- #!/bin/bash
#increment all pkgrel for i in `find -name PKGBUILD`;do
#getting pkgrel number after = package_pkgrel=`cat $i | grep pkgrel= | cut -d'=' -f 2`
#extract number before dot in pkgrel beforedot=`echo $package_pkgrel | cut -n -d'.' -f 1`
#add 1 to pkgrel new_pkgrel=$[$beforedot+1]
#write it back to PKGBUILD sed -i "s:pkgrel=${package_pkgrel}:pkgrel=${new_pkgrel}:g" $i done
build base makeworld -S -r -i --noconfirm -c -f ~/packages_rebuild base -------------end--------------------
Daniel
Before rebuilding the repo, we should make sure that all PKGBUILD have a license. That way, all the new package will have a correct license. Does the core packages all have a license field? Eric -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
On Nov 6, 2007 11:41 AM, Daniel Isenmann <daniel.isenmann@gmx.de> wrote:
Ok, here is a first list of packages which have wrong sources, md5sums or dependencies. Only for category "core/base", rest is following (maybe tonight or tomorrow):
file: failure on getting source, server doesn't exist anymore
<http://archlinux.org/pipermail/arch-commits/2007-November/005416.html> I updated the download location to one that works, but I didn't move tags or anything. Since the build didn't change I guess it would be OK to do so. -Dan
On Tue, 6 Nov 2007 18:41:45 +0100 Daniel Isenmann <daniel.isenmann@gmx.de> wrote:
On Tue, 6 Nov 2007 17:32:48 +0100 Daniel Isenmann <daniel.isenmann@gmx.de> wrote:
Let me do some more work on it. After the first run, I will post here some showstoppers for automatic rebuilds (e.g. source not found or wrong md5sums and such things for fixing it in the PKGBUILD).
Ok, here is the second list with core/lib, core/devel and core/support: core/lib: everything build fine core/devel: fakeroot: source doesn't exists anymore on server gcc: libstdc++-4.2.0.tar.bz2 doesn't exists anymore on server core/support: bcm43xx-fwcutter: missing arch-tag in PKGBUILD capi4k-utils: compiling fails with errors gpm: compiling fails with errors madwifi-utils: depends on 'sharutils', which is in [extra] rt2x00-cvs: depends on command 'cvs', which is in [extra] wlan-ng26-utils: compiling fails with errors wlan-ng26: fails, because of missing -util package, see error above That's all of [core] repo. I think, those things should be fixed first and maybe the missing/wrong license tag, too. I hope, that every maintainer of his package can fix those things. They are all nearly small things to change in the PKGBUILD. After fixing those things, we can think about rebuilding the whole core repo completly and put it to [testing] first. Daniel
On Wed, 7 Nov 2007, Daniel Isenmann wrote:
On Tue, 6 Nov 2007 18:41:45 +0100 Daniel Isenmann <daniel.isenmann@gmx.de> wrote:
On Tue, 6 Nov 2007 17:32:48 +0100 Daniel Isenmann <daniel.isenmann@gmx.de> wrote:
Let me do some more work on it. After the first run, I will post here some showstoppers for automatic rebuilds (e.g. source not found or wrong md5sums and such things for fixing it in the PKGBUILD).
Ok, here is the second list with core/lib, core/devel and core/support:
core/lib: everything build fine
core/devel: fakeroot: source doesn't exists anymore on server gcc: libstdc++-4.2.0.tar.bz2 doesn't exists anymore on server
core/support: bcm43xx-fwcutter: missing arch-tag in PKGBUILD capi4k-utils: compiling fails with errors gpm: compiling fails with errors madwifi-utils: depends on 'sharutils', which is in [extra] rt2x00-cvs: depends on command 'cvs', which is in [extra] wlan-ng26-utils: compiling fails with errors wlan-ng26: fails, because of missing -util package, see error above
That's all of [core] repo. I think, those things should be fixed first and maybe the missing/wrong license tag, too. I hope, that every maintainer of his package can fix those things. They are all nearly small things to change in the PKGBUILD.
After fixing those things, we can think about rebuilding the whole core repo completly and put it to [testing] first.
Daniel
There is also eventlog which is missing from the repo. Is everybody OK with having it readded in the core repo instead of extra? Eric -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
2007/11/7, Eric Belanger <belanger@astro.umontreal.ca>:
There is also eventlog which is missing from the repo. Is everybody OK with having it readded in the core repo instead of extra?
http://archlinux.org/pipermail/arch-dev-public/2007-November/002921.html Most commented there are OK to core. -- Roman Kyrylych (Роман Кирилич)
participants (11)
-
Alexander Baldeck
-
Andreas Radke
-
Damir Perisa
-
Dan McGee
-
Daniel Isenmann
-
Eric Belanger
-
Jan de Groot
-
Jason Chu
-
Roman Kyrylych
-
Travis Willard
-
Travis Willard