[Pkg-e-devel] some items to discuss

[Lut!n]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Daniele Favara a écrit :
> On Thu, Nov 09, 2006 at 10:34:20PM +0100, Lut!n wrote:
>> Hay there
>> here's a list of items I think we should discuss about in a meeting
>>
>>  * Team structure / organisation
>> 	how do we organise ourselves to work ? Maintain as a team is good, but
>> I think ppl could have some 'prefered' pkges though.
>> 	maybe building the deb pkge won't be the only thing to do, so how would
>> we split the tasks between us / defining what we have to an write a
>> clear TODO
> 
>     + 1.
> 
>   i think we should use bzr to store debian trees and their branches, in
> that way we can all work on the same packages. For ex i added all the
> "watch" file, but i can't commit it, as i know Lutin did some work from
> the last time i checked his debia source pkges.
> 
> So the item i'd propose here is the bzr repo tree, i'll write down a
> wiki page and link it here.
> 
>>  * Builds
>> 	What system do we choose for the builds ? I'm using pbuilder, nomed
>> told me about lp autobuilder network. pro / cons ?
>> 	How do we build.Thiss will be scripted, but how. 
> 
>  the way debian and ubuntu do this is more or less the following:
> 
>  - Maintainer: # dput $host pkge_xyz_arch.(source_)changes
>  - if 'source_changes':
>    --> buildd incoming
>      --> buildd asks wanna-build what pkgs need to be build
>      --> buildd run sbuild
>      --> if succesfull:
>        --> upload/
>    --> dput $dak_host pkge_xyz_arch.chages
>      --> queue/unchacked
>      --> if already not in the archive and changes file signed by a known
> maintainer:
>        --> queue/new
>      --> queue/accepted
>    --> ARCHIVE
> 
> Pro is that we're using the offcial debian way, and you can use pbuilder
> locally anyway. It seems there is an ubuntu dedicated server ... so it's
> possible to set up an Autobuilder Network
> 
>> I have a bash script,
>> quite hackish, but I saw nomed is a python lover & pretty good in it, so
>> maybe he has already something ready :)
> 
> Using that way any Maintainer can use his own scripts set, but i'm more
> for using standard way.
> 
>  - generate a package
>  - test a build locally
>  - send it to the autobuilder network
> 
> Refs:
> 
> 1] http://www.us.debian.org/doc/developers-reference/ch-resources#s-incoming-system
> 2] http://ftp-master.debian.org/
> 3] http://buildd.debian.org/
> 4] http://ftp-master.debian.org/new.html
> 
> Important!!: http://www.us.debian.org/devel/buildd/
> 
>> 	when do we build. We should define an update rhythm. 
> 
> i think we should have a dedicated meeting for this :) . So i just
> deffere this. As it depends on what we decide for other topics
> 
>> My current policy
>> is 
>> 1. Not more than a once-a-week update. this is mostly for end-users,
>> not qualified geeks. 
> 
> this is more or less the general idea
> 
> http://www.us.debian.org/devel/testing 
> 
> we should have branches. Let's go with some example.
> 
> We start packaging for *debian unstable*, everything cames from there
> as:
> 
> - (ubuntu , debian testing)
> 
> all the pacakges build fine they are all debian policy compliant.
> 
> Then we start building for *ubuntu development branch* (aka feisty), we
> shouldn't have problems as it derives directly from unstable.
> 
> We update packages in fesity and unstable when:
> 
>  - dependencies packages have been updated
>  - bugs need to be solved
> 
> Here we can superseed the package version or just use patches, for
> ubuntu this is valid untill *ubuntu development branch* is froozen, then
> we should just use patches and we shouldn't superseed versions, when
> this happen it's considered a "backport", we should avoid this.
> 
> (We coninue updating unstable obvioulsy so we're ready even for next
> ubuntu releases)
> 
> 
>> 2. Try the pkges before uploading, that should
>> be replaced by a debian-style way to integrate the pkges as nomed said.
>> Btw I don't think stabilizing by patches and such is a good idea, given
>> tha amount of patches commited each day.
>>
> 
> an important point for me is to have the watch file within the debian
> tree. If we're not using an official released tarball but it has been
> generated from CVS we should write down a script and put it in the
> debian dir (we can do that, the pkge is still debian policy compliant).
> 
> The script in this case should checkout the package from cvs (the revno
> used for the commited debian dir), check Build-Deps and run make
> checkinstall (this probably in a tmp dir) and generate the tarball to be
> used for the package.
> 
> I can write it down.
> 
Actually the process also needs to patch the configure file because of
its crappy references to debian/changelog.in
Here's the piece of bash code I'm using to make distcheck the things :
(simplified version)

apt-get update
apt-get install -y --force-yes automake1.9 cvs libtool (non-builddeps
requied things)
"bash $PREFIX/pbuilder-satisfydepends --control .........
./autogen.sh
make dist (if we know make distcheck is ok, it's pointless to run it as
it's muuuuuch longer)


then the part that deals with the configure and the produced tarball
source :
rm -Rf $debName-$smallVersion/debian (from the src tar)
cp $debName-$smallVersion/configure $debName-$smallVersion.patch/configure
perl -p -i -e 's/.*debian\/changelog.*;;//g;' $debName-perl -p -i -e
's/debian\/changelog//g;' $debName-$smallVersion.patch/configure
$smallVersion.patch/configure
diff -Nru $debName-$smallVersion/configure
$debName-$smallVersion.patch/configure > 00_configure.patch
/*put the configure in the right place*/
tar cvfz $debName-$newDebVersion.tar.gz $debName-$smallVersion
tar cvfz $debName"_"$newDebVersion.orig.tar.gz
$debName-$newDebVersion.tar.gz
move the tar to the right places
let's go

(note : smallversion is the soft version, eg 0.16.999.036. the
newDebVersion is 0.16.999.036+cvs20061110 for ex.)
(note2: yeah, I'm using tarball.mk. that's a major point to discuss as well)
>>  * Other
>> 	What will become the edevelop repo ? I don't want it to die. According
>> to shadoi's stats we're pretty well know there and I don't think it'd be
>> a good idea to move the primary mirror out of there. That needs to be
>> discussed
> 
> I don't see any reason for that , we can have 10000000 archives and all
> synced from the main one.
> 
> I have a shell at edevelop and you too, a cron job using rsync can do
> it.
> 
>> 	TODO : we need to have a packaging policy for an easier scriptability,
>> we should define it for the new pacakges to add.
> 
> see above (watch and script files)
> 
>> 		adding new pkges (mainly efl-based apps)
>> 		downgrade epochs on enlightenment and emodules (will be done within a
>> week)
>>
>> Maybe we could define a meeting date depending on your availability
> 
> Sure!
>  
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Pkg-e-devel mailing list
> Pkg-e-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/pkg-e-devel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFFVGwBIjAgwqfG8N8RAq5KAJwMNPr94Xv3j3sQQGV+Xs+g5V3NwgCcChFc
OW/AcKn+SCgPIbwO2gopvqs=
=m8sV
-----END PGP SIGNATURE-----