[aur-general] Community64 status again...

Allan McRae

26 Apr 2008 26 Apr '08

1:14 p.m.

Hi TUs, I know I keep on about this but I just had a look at the pkg_diff page [1] and I noticed there has been a big increase in the number of differences between the i686 and x86_64 community repos. To put some numbers to this, since the 17th there has been 11 packages added to i686 but not x86_64 and another 29 packages have been updated in i686 but not x86_64. We are now up to 190 differences between the architectures. Taking away the lib32 packages and the known build failures [2] leaves about 80 differences that can be fixed. That is about double the amount in the extra repo and it has more packages in total... How do we fix this? Here is what I propose: 1. If you add a new package to community and can only build for one repo then you must post a message to the list asking for someone to build it for the other. I.e. if you are bringing the package to community, then you are responsible for getting it in both arches. 2. Everyone who does not have access to a x86_64 machine, should get access to the build machine by contacting Aaron. 3. If it is inconvenient to build x86_64 packages on the build box (e.g. because of having to wait on deps to sync) then you should arrange with one of the x86_64 using TU's to do the building for you. What do TU's think about these ideas? I'd like to get some official guidelines out there so I can prod consistent offenders (you know who you are....)! Regards, Allan [1] http://dev.archlinux.org/~andyrtr/pkg_diff.html [2] http://wiki.archlinux.org/index.php/Community64_Status

Show replies by date

Allan McRae

29 Apr 29 Apr

5:40 a.m.

Allan McRae wrote:

...

Hi TUs,

I know I keep on about this but I just had a look at the pkg_diff page [1] and I noticed there has been a big increase in the number of differences between the i686 and x86_64 community repos. To put some numbers to this, since the 17th there has been 11 packages added to i686 but not x86_64 and another 29 packages have been updated in i686 but not x86_64. We are now up to 190 differences between the architectures. Taking away the lib32 packages and the known build failures [2] leaves about 80 differences that can be fixed. That is about double the amount in the extra repo and it has more packages in total...

How do we fix this? Here is what I propose:

1. If you add a new package to community and can only build for one repo then you must post a message to the list asking for someone to build it for the other. I.e. if you are bringing the package to community, then you are responsible for getting it in both arches.

2. Everyone who does not have access to a x86_64 machine, should get access to the build machine by contacting Aaron.

3. If it is inconvenient to build x86_64 packages on the build box (e.g. because of having to wait on deps to sync) then you should arrange with one of the x86_64 using TU's to do the building for you.

What do TU's think about these ideas? I'd like to get some official guidelines out there so I can prod consistent offenders (you know who you are....)!

Regards, Allan

[1] http://dev.archlinux.org/~andyrtr/pkg_diff.html [2] http://wiki.archlinux.org/index.php/Community64_Status

Bump.... So no TUs have any opinions on the above "guidelines"? The only response I saw to this thread was Partition building some of the missing x86_64 packages. Neverth has done some lately too. So a big cheer for those guys! (and of course any others I have missed) Allan

Ronald van Haren

7:14 a.m.

On Sat, Apr 26, 2008 at 3:14 PM, Allan McRae wrote:

...

Hi TUs,

I know I keep on about this but I just had a look at the pkg_diff page [1] and I noticed there has been a big increase in the number of differences between the i686 and x86_64 community repos. To put some numbers to this, since the 17th there has been 11 packages added to i686 but not x86_64 and another 29 packages have been updated in i686 but not x86_64. We are now up to 190 differences between the architectures. Taking away the lib32 packages and the known build failures [2] leaves about 80 differences that can be fixed. That is about double the amount in the extra repo and it has more packages in total...

How do we fix this? Here is what I propose:

1. If you add a new package to community and can only build for one repo then you must post a message to the list asking for someone to build it for the other. I.e. if you are bringing the package to community, then you are responsible for getting it in both arches.

By now everyone should be able to use Aaron's build machine. Only for large package groups it does not work out, and a separate builder must be found. Not building packages for both architectures is just plain lazy (at least for new packages). For packages already in community I can understand I can understand people have some time constraints. Maybe for them it is better to drop some packages to unsupported or give the maintainership over to another TU. That said, I think sometimes you guys build the x86_64 package too fast (well in a way it does increase your workload where it is not needed). For example, last 1.5 day I was not able to connect to the build box, but now I can again I see the package has already been build. Well, most likely these things don't happen very often so it should not be that big of a deal.

...

2. Everyone who does not have access to a x86_64 machine, should get access to the build machine by contacting Aaron.

Yes they should. I'm thinking about filing a feature request for the build box. AFAIK it is not possible to upload packages directly into community from within the build box, having to move the package back to my own box and upload it from there. Is that true or am I missing something obvious?

...

3. If it is inconvenient to build x86_64 packages on the build box (e.g. because of having to wait on deps to sync) then you should arrange with one of the x86_64 using TU's to do the building for you.

see my point at 1

...

What do TU's think about these ideas? I'd like to get some official guidelines out there so I can prod consistent offenders (you know who you are....)!

I think I most likely will support your guidelines. I would say create a new (separate) version of the guidelines (http://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines), adjust it as you think it should be and organize a vote (really I'm not all that for voting but that is the only way the new guidelines must be followed). Ronald ps. When counting the diffs I hope you don't count the e17 packages (because those are cvs versions and will most likely never be build on the same day as they are not build by the same person). Flock also has no sources released after the 1.1.1 release, whereas binaries are released up until 1.1.3. pss. A couple of days ago I did build pcmanx-gtk2 for Shinlun on i686, but I failed on the build machine. Asked two times if a x86_64 TU could take a look at it but I've never seen any response, nor is the package updated.

Allan McRae

7:28 a.m.

Ronald van Haren wrote:

...

pss. A couple of days ago I did build pcmanx-gtk2 for Shinlun on i686, but I failed on the build machine. Asked two times if a x86_64 TU could take a look at it but I've never seen any response, nor is the package updated.

I had to really search to find that... hidden away in the Shinlun thread as it was. Admittedly, I really skimmed through those emails when I got back. I will have a look at that package tonight. Allan

Allan McRae

10:47 a.m.

New subject: [aur-general] pcmanx-gtk2 [was Community64 status again...]

Allan McRae wrote:

...

Ronald van Haren wrote:

...
pss. A couple of days ago I did build pcmanx-gtk2 for Shinlun on i686, but I failed on the build machine. Asked two times if a x86_64 TU could take a look at it but I've never seen any response, nor is the package updated.

I had to really search to find that... hidden away in the Shinlun thread as it was. Admittedly, I really skimmed through those emails when I got back. I will have a look at that package tonight.

I have got it building. Two problems in the CFLAGS. It should be "-O2" not "-02". Also gcc-3.4 didn't know about x86_64 so that is a no go for -march/-mtune. Adjusting the PKGBUILD and uploading now... Allan

Ronald van Haren

11:14 a.m.

New subject: [aur-general] pcmanx-gtk2 [was Community64 status again...]

On Tue, Apr 29, 2008 at 12:47 PM, Allan McRae wrote:

...

Allan McRae wrote:

...
Ronald van Haren wrote:

...
pss. A couple of days ago I did build pcmanx-gtk2 for Shinlun on i686, but I failed on the build machine. Asked two times if a x86_64 TU could take a look at it but I've never seen any response, nor is the package updated.

I had to really search to find that... hidden away in the Shinlun thread as it was. Admittedly, I really skimmed through those emails when I got back. I will have a look at that package tonight.

I have got it building. Two problems in the CFLAGS. It should be "-O2" not "-02". I can't believe that I typed that :p .... /me hides

...

Also gcc-3.4 didn't know about x86_64 so that is a no go for -march/-mtune. I didn't know that. I thought it had something to do with the build machine. Thanks for clarifying that.

...

Adjusting the PKGBUILD and uploading now...

Allan

Thanks again :) Ronald

Allan McRae

11:11 a.m.

New subject: [aur-general] pcmanx-gtk2 [was Community64 status again...]

Ronald van Haren wrote:

...

...
Also gcc-3.4 didn't know about x86_64 so that is a no go for -march/-mtune.

I didn't know that. I thought it had something to do with the build machine. Thanks for clarifying that.

To correct myself... gcc-3.4 knows x86-64 not x86_64 so you can't just use $CARCH. Allan

Geoffroy Carrier

11:56 a.m.

New subject: [aur-general] pcmanx-gtk2 [was Community64 status again...]

On Tue, Apr 29, 2008 at 1:11 PM, Allan McRae wrote:

...

To correct myself... gcc-3.4 knows x86-64 not x86_64 so you can't just use $CARCH. Do we have some list of packages requiring gcc34 to compile? I'd like to work on patching them.

-- Geoffroy Carrier

Sergej Pupykin

12:14 p.m.

New subject: [aur-general] pcmanx-gtk2 [was Community64 status again...]

Hi, $ cd /var/abs && grep -R makedepend PKGBUILD . | grep gcc34 ./extra/qemu/PKGBUILD:makedepends=('gcc34') ./community/system/xen/PKGBUILD:makedepends=('gcc34') ./community/network/flock/PKGBUILD:makedepends=('gcc34') 2008/4/29 Geoffroy Carrier :

...

On Tue, Apr 29, 2008 at 1:11 PM, Allan McRae wrote:

...
To correct myself... gcc-3.4 knows x86-64 not x86_64 so you can't just use $CARCH. Do we have some list of packages requiring gcc34 to compile? I'd like to work on patching them.

-- Geoffroy Carrier

Eric Belanger

1 May 1 May

4:18 p.m.

On Tue, 29 Apr 2008, Ronald van Haren wrote:

...

On Sat, Apr 26, 2008 at 3:14 PM, Allan McRae wrote:

...
Hi TUs,

I know I keep on about this but I just had a look at the pkg_diff page [1] and I noticed there has been a big increase in the number of differences between the i686 and x86_64 community repos. To put some numbers to this, since the 17th there has been 11 packages added to i686 but not x86_64 and another 29 packages have been updated in i686 but not x86_64. We are now up to 190 differences between the architectures. Taking away the lib32 packages and the known build failures [2] leaves about 80 differences that can be fixed. That is about double the amount in the extra repo and it has more packages in total...

How do we fix this? Here is what I propose:

1. If you add a new package to community and can only build for one repo then you must post a message to the list asking for someone to build it for the other. I.e. if you are bringing the package to community, then you are responsible for getting it in both arches.

By now everyone should be able to use Aaron's build machine. Only for large package groups it does not work out, and a separate builder must be found. Not building packages for both architectures is just plain lazy (at least for new packages). For packages already in community I can understand I can understand people have some time constraints. Maybe for them it is better to drop some packages to unsupported or give the maintainership over to another TU. That said, I think sometimes you guys build the x86_64 package too fast (well in a way it does increase your workload where it is not needed). For example, last 1.5 day I was not able to connect to the build box, but now I can again I see the package has already been build. Well, most likely these things don't happen very often so it should not be that big of a deal.

If the x86_64 build machine is not available, you might want to notify the othe TU via the TU IRC channel or this ML (if these problems happens rarely). The TU with x86_64 system don't use the build machine so they don't know its status. Another thing to do would be to have a liste of TU who needs to have their packages built for x86_64 and only build these TU's packages.

...

ps. When counting the diffs I hope you don't count the e17 packages (because those are cvs versions and will most likely never be build on the same day as they are not build by the same person). Flock also has no sources released after the 1.1.1 release, whereas binaries are released up until 1.1.3.

You can build cvs package with the same version. Just use: makepkg --holdver BTW, is there anyone interested in building the x86_64 packages for e17? I am supposed to be doing it but it's time consuming and inconvenient for me to build and test. I will likely skip some updates in the future wich I already did. I could update it this time. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

5853

Age (days ago)

5858

Last active (days ago)

List overview

Download

9 comments

5 participants

participants (5)

Allan McRae
Eric Belanger
Geoffroy Carrier
Ronald van Haren
Sergej Pupykin