FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux User Repository

 
 
LinkBack Thread Tools
 
Old 05-19-2010, 04:59 AM
Allan McRae
 
Default community repo "cleanup"

Hi,

I was thinking that it has been almost a year since the [community] repo
switched to using the main db-scripts, but there are still a large
number of packages without the package architecture in their name (the
old scripts removed it). It is somewhere around 1/3 of the repo
(anything build before 2009-07-14). In fact, one package (datemath)
was built back in 2005!


Given these packages are obviously not updated much, it would be good to
give them a rebuild to get new packaging policies in place such as:

- get the package architecture in the file name
- build with new toolchain, CFLAGS, LDFLAGS etc
- compress with .xz format
- convert to arch=any as necessary
- $startdir usage
- package() functions
- ...

It would also be a good time to remove old packages that are really no
longer of interest from the repo.


What do people think? I can create an internal TODO list for these
packages that can be slowly worked through.


Allan
 
Old 05-19-2010, 08:51 AM
Stefan Husmann
 
Default community repo "cleanup"

Am 19.05.2010 06:59, schrieb Allan McRae:

Hi,

I was thinking that it has been almost a year since the [community] repo
switched to using the main db-scripts, but there are still a large
number of packages without the package architecture in their name (the
old scripts removed it). It is somewhere around 1/3 of the repo
(anything build before 2009-07-14). In fact, one package (datemath) was
built back in 2005!

Given these packages are obviously not updated much, it would be good to
give them a rebuild to get new packaging policies in place such as:
- get the package architecture in the file name
- build with new toolchain, CFLAGS, LDFLAGS etc
- compress with .xz format
- convert to arch=any as necessary
- $startdir usage
- package() functions
- ...

It would also be a good time to remove old packages that are really no
longer of interest from the repo.

What do people think? I can create an internal TODO list for these
packages that can be slowly worked through.

Allan



Good idea! Go ahaead!
 
Old 05-19-2010, 05:42 PM
Xyne
 
Default community repo "cleanup"

> Hi,
>
> I was thinking that it has been almost a year since the [community] repo
> switched to using the main db-scripts, but there are still a large
> number of packages without the package architecture in their name (the
> old scripts removed it). It is somewhere around 1/3 of the repo
> (anything build before 2009-07-14). In fact, one package (datemath)
> was built back in 2005!
>
> Given these packages are obviously not updated much, it would be good to
> give them a rebuild to get new packaging policies in place such as:
> - get the package architecture in the file name
> - build with new toolchain, CFLAGS, LDFLAGS etc
> - compress with .xz format
> - convert to arch=any as necessary
> - $startdir usage
> - package() functions
> - ...
>
> It would also be a good time to remove old packages that are really no
> longer of interest from the repo.
>
> What do people think? I can create an internal TODO list for these
> packages that can be slowly worked through.
>
> Allan

This sounds good to me.

I have a suggestion that might increase overall productivity by making
cooperation easier.

Create a dedicated directory for this on Sigurd, e.g. "rebuilds". We
can all mount this using sshfs which will ensure that each of us is
using the latest lists etc and thus avoid redundancy without having to
edit and refresh the bug tracker.

Create the following directories:

rebuilds/unsorted/
rebuilds/pending/
rebuilds/staging/
rebuilds/complete/

"unsorted" will contain the current PKGBUILDs and local source files,
e.g. "rebuilds/pending/foo/PKGBUILD".

"pending" will contain those that will be kept and that have been
inspected and possibly updated (e.g. $startdir usage). Considering that
most PKGBUILDs will only require minor tweaks, everything in "pending"
should be ready for makepkg.

The idea is that as packages end up in "pending", others can begin
building them without worrying about other architectures. Some will
require further tweaks which may even be architecture-specific. This
should not be an issue if "pending" is mounted via sshfs because each
person will always have the latest version of the PKGBUILD. Simultaneous
editing should not be an issue either because any good text editor will
detect the changes on the disk.

The easiest way to build each package would be to create a local
directory named $pkgname and then symlink the PKGBUILD and local source
files in it. Again, the symlink runs through SSH so you know you have
the latest version of each file. If the package builds successfully, it
can be uploaded to "staging".

Once a package has been built for each architecture with the same
PKGBUILD, it can be moved to "complete". Everything in "complete" can
be committed to SVN later.

The idea is to avoid dealing with SVN checkouts and commits
unnecessarily and to make it possible to build for a given architecture
without having to worry about others. This will make it possible for
i686-only packagers to work on multi-architecture packages and it will
let x86_64 packagers avoid dealing with chroots and virtual machines.

I could write scripts to make all of this easier (creating the dir with
symlinks, building and moving to staging, checking for "complete"
packages, removing old packages after a version bump, etc).

I'm just floating the idea though.


Xyne
 
Old 05-19-2010, 06:07 PM
Evangelos Foutras
 
Default community repo "cleanup"

On 19/05/10 20:42, Xyne wrote:

The idea is to avoid dealing with SVN checkouts and commits
unnecessarily and to make it possible to build for a given architecture
without having to worry about others. This will make it possible for
i686-only packagers to work on multi-architecture packages and it will
let x86_64 packagers avoid dealing with chroots and virtual machines.


I didn't read the whole proposal as I found it a bit hard to follow
(it's kinda late; 9pm :P) and just skimmed through. However, let me note
that the above suggestion is bad practice. All packages should ideally
be built inside a clean chroot to prevent linking against other
libraries that are installed on the system but not explicitly wanted in
the package, and to a lesser extent to avoid having missing dependencies
(might not apply to rebuilds) or custom {C,LD}FLAGS.
 
Old 05-19-2010, 06:36 PM
Caleb Cushing
 
Default community repo "cleanup"

On Wed, May 19, 2010 at 12:59 AM, Allan McRae <allan@archlinux.org> wrote:
> It would also be a good time to remove old packages that are really no
> longer of interest from the repo.
>

if any are perl-* let me know and I'll pick them up on AUR

--
Caleb Cushing

http://xenoterracide.blogspot.com
 
Old 05-19-2010, 10:47 PM
Allan McRae
 
Default community repo "cleanup"

On 20/05/10 03:42, Xyne wrote:

Hi,

I was thinking that it has been almost a year since the [community] repo
switched to using the main db-scripts, but there are still a large
number of packages without the package architecture in their name (the
old scripts removed it). It is somewhere around 1/3 of the repo
(anything build before 2009-07-14). In fact, one package (datemath)
was built back in 2005!

Given these packages are obviously not updated much, it would be good to
give them a rebuild to get new packaging policies in place such as:
- get the package architecture in the file name
- build with new toolchain, CFLAGS, LDFLAGS etc
- compress with .xz format
- convert to arch=any as necessary
- $startdir usage
- package() functions
- ...

It would also be a good time to remove old packages that are really no
longer of interest from the repo.

What do people think? I can create an internal TODO list for these
packages that can be slowly worked through.

Allan


This sounds good to me.

I have a suggestion that might increase overall productivity by making
cooperation easier.

Create a dedicated directory for this on Sigurd, e.g. "rebuilds". We
can all mount this using sshfs which will ensure that each of us is
using the latest lists etc and thus avoid redundancy without having to
edit and refresh the bug tracker.

Create the following directories:

rebuilds/unsorted/
rebuilds/pending/
rebuilds/staging/
rebuilds/complete/

"unsorted" will contain the current PKGBUILDs and local source files,
e.g. "rebuilds/pending/foo/PKGBUILD".

"pending" will contain those that will be kept and that have been
inspected and possibly updated (e.g. $startdir usage). Considering that
most PKGBUILDs will only require minor tweaks, everything in "pending"
should be ready for makepkg.

The idea is that as packages end up in "pending", others can begin
building them without worrying about other architectures. Some will
require further tweaks which may even be architecture-specific. This
should not be an issue if "pending" is mounted via sshfs because each
person will always have the latest version of the PKGBUILD. Simultaneous
editing should not be an issue either because any good text editor will
detect the changes on the disk.

The easiest way to build each package would be to create a local
directory named $pkgname and then symlink the PKGBUILD and local source
files in it. Again, the symlink runs through SSH so you know you have
the latest version of each file. If the package builds successfully, it
can be uploaded to "staging".

Once a package has been built for each architecture with the same
PKGBUILD, it can be moved to "complete". Everything in "complete" can
be committed to SVN later.

The idea is to avoid dealing with SVN checkouts and commits
unnecessarily and to make it possible to build for a given architecture
without having to worry about others. This will make it possible for
i686-only packagers to work on multi-architecture packages and it will
let x86_64 packagers avoid dealing with chroots and virtual machines.

I could write scripts to make all of this easier (creating the dir with
symlinks, building and moving to staging, checking for "complete"
packages, removing old packages after a version bump, etc).

I'm just floating the idea though.



This seems way too complicated... and I am not sure of the advantages
over the current TODO list system.


The TODO list which shows when packages are built for only one
architecture. So if someone can only build for one Arch, another person
already can see the other needing done and do the build. And that
should be a non-issue given access to PKGBUILD.com anyway.


Also, x86_64 packagers should not need to anything complicated to deal
with chroots or VMs to build i686 packages. My only change to build for
i686 from x86_64 is to add linux32 in front of the makechrootpkg command.


Allan
 
Old 05-19-2010, 11:08 PM
Isaac Dupree
 
Default community repo "cleanup"

On 05/19/10 00:59, Allan McRae wrote:

Given these packages are obviously not updated much, it would be good to
give them a rebuild to get new packaging policies in place[...]


I wonder if we should be concerned about the current toolchain? For
example GCC 4.5.0 was mis-compiling some things when optimizations were
on, if I recall correctly -- an effect that might be magnified by
recompiling a lot of rarely-used/tested packages with it. (For example,
I suppose we could wait until GCC 4.5.1 before doing a rebuild.)


-Isaac
 
Old 05-19-2010, 11:18 PM
Allan McRae
 
Default community repo "cleanup"

On 20/05/10 09:08, Isaac Dupree wrote:

On 05/19/10 00:59, Allan McRae wrote:

Given these packages are obviously not updated much, it would be good to
give them a rebuild to get new packaging policies in place[...]


I wonder if we should be concerned about the current toolchain? For
example GCC 4.5.0 was mis-compiling some things when optimizations were
on, if I recall correctly -- an effect that might be magnified by
recompiling a lot of rarely-used/tested packages with it. (For example,
I suppose we could wait until GCC 4.5.1 before doing a rebuild.)



I'm not sure we should be too worried. Already over 1/3 of the repo is
built with it and only 1 package has been reported broken (and one other
not in the repo).


Anyway, I will be doing a new gcc rebuild when the next 4.5 snapshot
gets released (~24 hours away). That has a fix for at least one of the
issues we have encountered.


Allan
 
Old 05-20-2010, 08:46 AM
Ray Rashif
 
Default community repo "cleanup"

On 20/05/2010, Allan McRae <allan@archlinux.org> wrote:
> This seems way too complicated... and I am not sure of the advantages
> over the current TODO list system.
>
> The TODO list which shows when packages are built for only one
> architecture. So if someone can only build for one Arch, another person
> already can see the other needing done and do the build. And that
> should be a non-issue given access to PKGBUILD.com anyway.
>
> Also, x86_64 packagers should not need to anything complicated to deal
> with chroots or VMs to build i686 packages. My only change to build for
> i686 from x86_64 is to add linux32 in front of the makechrootpkg command.

I think Xyne was concerned about packagers sharing the (architecture)
load and conflicting updates, but I believe that is very unlikely to
happen. Even when it does, you can just revert your changes and let
the previous committer go on to complete the update for both
architectures. He can request another packager to build for an arch
that he cannot.

It will just be like previous major rebuilds, only this time they go
to community-testing. And there are 2 slots per arch on PKGBUILD.com
with a nice queueing system


--
GPG/PGP ID: B42DDCAD
 
Old 05-22-2010, 01:58 PM
Allan McRae
 
Default community repo "cleanup"

Hi,

The TODO list has been created for this "rebuild". Obviously no rush on
this one given it is not a real rebuild. And remember to consider
whether the package really needs to stay in [community] given many have
not been updated in ages.


Cheers,
Allan
 

Thread Tools




All times are GMT. The time now is 01:21 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org