From aba at disipos.de Wed Aug 3 11:39:31 2005 From: aba at disipos.de (Alexander Baldeck) Date: Wed, 03 Aug 2005 17:39:31 +0200 Subject: [arch-ports] hey list! Message-ID: <42F0E533.7010804@disipos.de> hey list, only wanted to try if the ports list actually works. :) regards, kth5 From jason at archlinux.org Wed Aug 3 21:33:33 2005 From: jason at archlinux.org (Jason Chu) Date: Wed, 3 Aug 2005 21:33:33 -0400 Subject: [arch-ports] Welcome to the arch-ports list Message-ID: <20050804013333.GA8426@mercury.xentac.net> I'm pretty sure there are only 3 of us here (maybe Judd too...), but I figured I'd just set the tone. This list is where all "official" port-related discussion will happen. It's not a secret list, anyone will be able to join and offer help/listen/ideas. I'll always be here as a conduit to the developers, to offer guidance, and to get that damned pacbuild done (actually, things are progressing well... just slowly). I wouldn't mind getting port status from you guys. Currently I know that Alex is managing the ppc port and symajala is managing the amd64 and i586 ports. Where are you guys at, what are your methods, what would you like to improve, how do you feel about your progress? In an email following shortly, I'll tell you my ideas for multiple arch support in pacman and our official package management process. Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From aba at disipos.de Thu Aug 4 05:58:55 2005 From: aba at disipos.de (Alexander Baldeck) Date: Thu, 04 Aug 2005 11:58:55 +0200 Subject: [arch-ports] PPC port status Message-ID: <42F1E6DF.9030701@disipos.de> hey ports ml, regarding jason's request for us to present status of the port we work on i'd like to present a summary of what my initial goal was and while i was working on to achieve it has been going on: back in late summer 2004 i got a few old Power Macintosh machines for free. right from the start i wanted to run linux on them. me being an archer thought about porting it. first thing to do was to install another distro first, in my case it was debian as it is working pretty well on all platforms it supports. first thing to do is - in my opinion - getting current/base to work as a standalone system. for that one needs to start with the following packages in order: binutils gcc glibc zlib libtar ncurses readline bash pacman when i had these installed to a chroot, i started from scratch - to get rid of references to debian - from within the chroot using makepkg. if all goes well you now have clean packages to start buildin the rest of current, this can be a pretty timeconsuming and stressing process. fortunately i didn't have to modify that many PKGBUILDs. :) one advice: if you compile pacman first and use makepkg from the start, it may happen that the md5 check is not working properly. at least that was how it was on ppc32. no idea about others. Archlinux/PPC Status: ============== it's been almost a year now - i am after all a one man army - and i have a complete current and a rather small part of extra built and working fine. current (100%) extra (30%) the installer is still not working well mainly due to the lack of time. right now i am in the process of migrating current to GCC 4.0.1. for that i stopped to work on extra for i cannot manage it on my own anyway. testing now has about 50% of current including X, a few window managers and other stuff to drive a desktop system. best regards, alex / kth5 From syamajala at gamebox.net Thu Aug 4 21:39:52 2005 From: syamajala at gamebox.net (syamajala at gamebox.net) Date: Thu, 4 Aug 2005 21:39:52 -0400 Subject: [arch-ports] x86_64 port Message-ID: Well, its been more than 6 months since the port was started. I think a lot of good progress has been made. There are well over 650 packages. I'm not really as organized as I could be, packages that I use have are top priority for me. So there is a mix of extra packages and current packages. Then I just do random packages. I would also like to migrate to gcc 4 and add 32bit support, or make it optional. It probably should not be optional because there are things like grub that need to be 32bit. Right now the grub package has been compiled on a 32bit system but it has been statically linked. There are also things like flash and opera. Cvsup needs to be fixed. The pacman issue that kth5 talked about needs to be fixed. Dorphell suggested that it might be a problem with the kernel. Also, one major request has been to support the intel 64bit chip. So when things are migrated to gcc 4 i would like to change the flags to support both cpu (intel 64bit chip whatever it may be called and the amd64). All in all I think the future is bright for arch and its various ports! - Seshu (syamajala) From syamajala at gamebox.net Thu Aug 4 21:46:32 2005 From: syamajala at gamebox.net (Seshu Yamajala) Date: Thu, 4 Aug 2005 21:46:32 -0400 Subject: [arch-ports] i586 port Message-ID: <053D9EA1-43A8-4AF3-AE51-1892C2C0C484@gamebox.net> Ok, I personally have not used the i586 packages. I am just hosting them for maci and disc-devil. I haven't heard anything from either of them in a while. So maybe the best thing to do is just merge their changes with what is on the main servers? I don't know, just an idea. Also, this is my first time using a mailing list so bare with me. Finally, i will be on "vacation" for 3 weeks (i think?) in India. - Seshu From aba at disipos.de Fri Aug 5 05:51:50 2005 From: aba at disipos.de (Alexander Baldeck) Date: Fri, 05 Aug 2005 11:51:50 +0200 Subject: [arch-ports] i586 port In-Reply-To: <053D9EA1-43A8-4AF3-AE51-1892C2C0C484@gamebox.net> References: <053D9EA1-43A8-4AF3-AE51-1892C2C0C484@gamebox.net> Message-ID: <42F336B6.4050401@disipos.de> Seshu Yamajala wrote: > Ok, I personally have not used the i586 packages. I am just hosting > them for maci and disc-devil. I haven't heard anything from either of > them in a while. So maybe the best thing to do is just merge their > changes with what is on the main servers? I don't know, just an idea. > Also, this is my first time using a mailing list so bare with me. > Finally, i will be on "vacation" for 3 weeks (i think?) in India. > > - Seshu > Wish I could come along... no, instead I have to go to Austria->Hungary->Slovakia->Chechz->Germany next month. Just kidding, but it's true. ;-) Have a nice time! From aba at disipos.de Mon Aug 8 11:40:26 2005 From: aba at disipos.de (Alexander Baldeck) Date: Mon, 08 Aug 2005 17:40:26 +0200 Subject: [arch-ports] integration of ports into original archlinux Message-ID: <42F77CEA.8000807@disipos.de> hey list, i am wondering about this quite some time now: how will ports be handled by the main archlinux project for i686? as it seems there hasn't been much talk about this lately but a while ago Judd moved the repos to a new structure (os/i686) which seems to be a first step. since then i haven't heard much. now then, i simply want to start another discussion. maybe to find a few things a port has to implement before it may be officially mentioned or even why they should not be considered as a part of the official archlinux. regards, alex From jason at archlinux.org Mon Aug 8 15:49:18 2005 From: jason at archlinux.org (Jason Chu) Date: Mon, 8 Aug 2005 15:49:18 -0400 Subject: [arch-ports] integration of ports into original archlinux In-Reply-To: <42F77CEA.8000807@disipos.de> References: <42F77CEA.8000807@disipos.de> Message-ID: <20050808194918.GH9350@mercury.xentac.net> On Mon, Aug 08, 2005 at 05:40:26PM +0200, Alexander Baldeck wrote: > hey list, > > i am wondering about this quite some time now: > > how will ports be handled by the main archlinux project for i686? as it seems there hasn't been much talk > about > this lately but a while ago Judd moved the repos to a new structure (os/i686) which seems to be a first > step. since > then i haven't heard much. > > now then, i simply want to start another discussion. maybe to find a few things a port has to implement > before it > may be officially mentioned or even why they should not be considered as a part of the official > archlinux. > > > regards, > > alex I planned on talking about this when I got the inclination. I expect I'll be able to "force" myself to do it tonight, after I finish the conference for the day. Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jason at archlinux.org Tue Aug 9 00:24:08 2005 From: jason at archlinux.org (Jason Chu) Date: Tue, 9 Aug 2005 00:24:08 -0400 Subject: [arch-ports] integration of ports into original archlinux In-Reply-To: <42F77CEA.8000807@disipos.de> References: <42F77CEA.8000807@disipos.de> Message-ID: <20050809042408.GA14950@mercury.xentac.net> On Mon, Aug 08, 2005 at 05:40:26PM +0200, Alexander Baldeck wrote: > hey list, > > i am wondering about this quite some time now: > > how will ports be handled by the main archlinux project for i686? as it seems there hasn't been much talk > about > this lately but a while ago Judd moved the repos to a new structure (os/i686) which seems to be a first > step. since > then i haven't heard much. > > now then, i simply want to start another discussion. maybe to find a few things a port has to implement > before it > may be officially mentioned or even why they should not be considered as a part of the official > archlinux. I've also been wondering this. I've tried to find good solutions to the problems that I saw, but I never really asked you guys what your methods are ;o) So, that's what I'll start with. Assume that we always want to have an ABS (basically cvsup) that reflects the current repo's packages. How do you do your package updating/building and repo updating? My thinking was something like this: try to keep all the work in a single CVS tree, tagging things as CURRENT (as we do for i686), CURRENT-PPC, CURRENT-amd64, etc, using CARCH to make platform specific changes. This way the ports are essentially just modifying the global i686 packages. Obviously there are some architecture specific changes, but the direction of the packages is kept consistent over all the ports. I even wrote a patch for gensync to build repos out of package files only. This does entail untaring each package to get the meta data though. But you don't need matching PKGBUILDs. One of the reasons to do this was to add a -$CARCH part to package files (---$CARCH.pkg.tar.gz); if gensync reads package information from the package itself, the package can be named anything you want. The other option is to have totally seperate trees and let each port manage their own packages however they please. Personally, I don't like this way. There's a lot more duplicated work (because problems have to be fixed multiple times). You're essentially implementing your own distro that's sharing the arch name. This means that everything can stay the same, but managing the CVS tree (assuming it's still shared) becomes a real nasty task (make change for one arch, commit, tag, undo changes for that arch, make changes for different arch, commit, tag). It's a very inefficient use of CVS and sure to lead to lots of mistakes in the long run. Anyway, I'm curious to hear your input on how you do stuff and which changes you'd prefer. The discussion has happened between the developers, but now it's out on the arch-ports list. About port acceptance, I have no idea. I was thinking we'd wait till the other ports were managed by pacbuild, but things are moving forward slowly (though they actually are moving forward!). Suggestions there too? Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From aba at disipos.de Tue Aug 9 05:23:25 2005 From: aba at disipos.de (Alexander Baldeck) Date: Tue, 09 Aug 2005 11:23:25 +0200 Subject: [arch-ports] integration of ports into original archlinux In-Reply-To: <20050809042408.GA14950@mercury.xentac.net> References: <42F77CEA.8000807@disipos.de> <20050809042408.GA14950@mercury.xentac.net> Message-ID: <42F8760D.2000900@disipos.de> Jason Chu wrote: >On Mon, Aug 08, 2005 at 05:40:26PM +0200, Alexander Baldeck wrote: > > >>hey list, >> >>i am wondering about this quite some time now: >> >>how will ports be handled by the main archlinux project for i686? as it seems there hasn't been much talk >>about >>this lately but a while ago Judd moved the repos to a new structure (os/i686) which seems to be a first >>step. since >>then i haven't heard much. >> >>now then, i simply want to start another discussion. maybe to find a few things a port has to implement >>before it >>may be officially mentioned or even why they should not be considered as a part of the official >>archlinux. >> >> > >I've also been wondering this. I've tried to find good solutions to the >problems that I saw, but I never really asked you guys what your methods >are ;o) > >So, that's what I'll start with. Assume that we always want to have an ABS >(basically cvsup) that reflects the current repo's packages. How do you do >your package updating/building and repo updating? > > In my case - the PPC port - the ABS script would still need to be modified since I still haven't sucessfully compiled cvsup itself. Also I got offered a Subversion repository on archlinuxfr.org and am happily using it. From my experience there are lots of feature I definetely wouldn't want to miss out on. Since ABS only wraps around a few CVS pulls in the i686 branch I could say that i have soemthing like ABS as well. Package updating normally is done by first modifying the PKGBUILD, building the package, test the package, then upload the binary and finally commit to SVN after generating a new db.tar.gz. >My thinking was something like this: try to keep all the work in a single >CVS tree, tagging things as CURRENT (as we do for i686), CURRENT-PPC, >CURRENT-amd64, etc, using CARCH to make platform specific changes. This >way the ports are essentially just modifying the global i686 packages. >Obviously there are some architecture specific changes, but the direction >of the packages is kept consistent over all the ports. > > How would you do that? Here is how I think it could be done (this reflects the testing/xorg package for ppc), sorry for the long interruption of the textflow. ;) [snippet] # Maintainer: Alexander Baldeck pkgname=xorg pkgver=11R6.8.2 pkgrel=3 pkgdesc="A fork of the XFree86 Project with a GPL-compatible license" url="http://www.x.org" depends=('glibc' 'freetype1' 'fontconfig' 'gcc' 'libpng') makedepends=('perl') conflicts=('ttf-bitstream-vera' 'xfree86') provides=('x-server' 'xfree86') replaces=('x') install=x.install source=(http://ftp.skynet.be/pub/ftp.x.org/pub/X${pkgver}/src-single/X${pkgver}-src.tar.bz2 \ http://www.joerg-pommnitz.de/TrueType/ttmkfdir.tar.gz xdm.pam \ xterm256.patch libGL.la xorg.sh no-fc-cache-run.patch \ macintosh-xkb-us-de-ibook.patch imakemdep_ppc.patch) build() { # -fno-strict-aliasing seems to fix a problem with mkfontscale caused by # gcc or freetype. mor information can be found here: # http://lists.gnu.org/archive/html/freetype-devel/2005-04/msg00033.html export CFLAGS=$"$CFLAGS -fno-strict-aliasing" export CXXFLAGS=$"$CXXFLAGS -fno-strict-aliasing" cd $startdir/src make FREETYPE_INCL=/usr/include/freetype || return 1 install -D ttmkfdir $startdir/pkg/usr/X11R6/bin/ttmkfdir # fc-cache may segfault on misc. occasions patch -p0 < no-fc-cache-run.patch if [ "$CARCH" = "ppc" ]; then # some keyboard issues on ibooks patch -p0 < macintosh-xkb-us-de-ibook.patch fi cd $startdir/src/xc if [ "$CARCH" = "ppc" ]; then patch -p0 < ../imakemdep_ppc.patch fi # build fixes sed -i 's|$(HARDCOPYDIR)||g' doc/Imakefile || return 1 if [ "$CARCH" = "ppc" ]; then echo '#define LinuxDistName ArchLinux-ppc' >config/cf/host.def fi if [ "$CARCH" = "i686" ]; then echo '#define LinuxDistName ArchLinux-i686' >config/cf/host.def fi echo $"#define DefaultGcc2PpcOpt $CFLAGS -fno-strict-aliasing" >>config/cf/host.def echo $'#define HasZlib YES' >> config/cf/host.def echo $'#define HasNCurses YES' >> config/cf/host.def echo $'#define HasFreetype2 YES' >> config/cf/host.def echo $'#define HasLibpng YES' >> config/cf/host.def echo $'#define UseExpat YES' >> config/cf/host.def echo $'#define HasExpat YES' >> config/cf/host.def #echo $'#define UseFontconfig YES' >> config/cf/host.def echo $'#define HasFontconfig YES' >> config/cf/host.def #echo '#define HasPam NO' >> config/cf/host.def echo '#define BuildLinuxDocPS NO' >> config/cf/host.def echo '#define BuildLinuxDocText NO' >> config/cf/host.def echo '#define BuildLinuxDocHtml NO' >> config/cf/host.def echo '#define BuildHtmlManPages NO' >> config/cf/host.def echo '#define BuildSpecsDocs NO' >> config/cf/host.def echo '#define BuildAllSpecsDocs NO' >> config/cf/host.def echo '#define BuildXF86DRI YES' >> config/cf/host.def echo '#define BuildXDriInfo YES' >> config/cf/host.def echo '#define BuildGLXLibrary YES' >> config/cf/host.def echo '#define BuildXdmcpLib YES' >> config/cf/host.def echo '#define BuildXInputLib YES' >> config/cf/host.def echo '#define BuildXvLibrary YES' >> config/cf/host.def echo '#define SharedLibFont NO' >> config/cf/host.def #echo $'#define CcCmd $CC' >> config/cf/host.def echo $"#define OptimizedCDebugFlags $CFLAGS" >> config/cf/host.def echo $"#define OptimizedCplusplusDebugFlags $CXXFLAGS" >> config/cf/host.def # this should enable any available driver with dri where possible echo "#define XF86CardDrivers mga glint s3virge sis savage trident chips tdfx fbdev ati DevelDrivers vga nv imstt \ XF86OSCardDrivers XF86ExtraCardDrivers" >> config/cf/host.def echo '#define DevelDRIDrivers YES' >> config/cf/host.def # use this for relinking a compiled xorg source tree, # it'll save lot's of time depending on how fast your system is # ATTENTION: do not use when compiling from scratch as it will not # generate deps # make Everything || return 1 make World || return 1 make DESTDIR=$startdir/pkg install rm -f programs/xkbcomp/rules/xfree86* make DESTDIR=$startdir/pkg install.man (cd $startdir/pkg/usr/include && ln -sf ../X11R6/include/X11 X11) (cd $startdir/pkg/usr/include && ln -sf ../X11R6/include/GL GL) # exorcise the SysV demons and set up environment stuff rm -rf $startdir/pkg/etc/rc.d/rc?.d rm -f $startdir/pkg/etc/profile.d/xprint.csh mv $startdir/pkg/etc/init.d/xprint $startdir/pkg/etc/rc.d/xprint sed -i 's|init.d|rc.d|g' $startdir/pkg/etc/profile.d/xprint.sh rmdir $startdir/pkg/etc/init.d # get the pkgconfig .pc files in the right place mkdir -p $startdir/pkg/usr/lib/pkgconfig mv $startdir/pkg/usr/X11R6/lib/pkgconfig/* $startdir/pkg/usr/lib/pkgconfig # XDG stuff install -d -m755 $startdir/pkg/etc/xdg install -D -m644 $startdir/src/xdm.pam $startdir/pkg/etc/pam.d/xdm install -D -m755 $startdir/src/xorg.sh $startdir/pkg/etc/profile.d/xorg.sh install -D -m644 $startdir/src/libGL.la $startdir/pkg/usr/lib/libGL.la } md5sums=('8131cd7ea1e4566e6e05c438a93fcfe1' 'dcf6aa4d28f5c52acf2bb57f49f53089'\ '419d6289ba6f851135f5c70c0e3cbec4' '9d04512b66834aefecf32b15555c2f97'\ '6b4052cf6d50cbd2854ebd3409f02695' 'f782bb79086e6e25c9e1182017f02a16'\ 'f4b82c3357912726a5781df127f4e28b' '5e5220f4d55a9925b9b59576ed9b8a39'\ '25b3637412556320593768db6bbb4a34') [/snippet] That is one possibility but as you can see it might get very messy if other CARCHes come in as well. Which makes me thing this is far from perfect. >I even wrote a patch for gensync to build repos out of package files only. >This does entail untaring each package to get the meta data though. But >you don't need matching PKGBUILDs. One of the reasons to do this was to >add a -$CARCH part to package files >(---$CARCH.pkg.tar.gz); if gensync reads package >information from the package itself, the package can be named anything you >want. > > What about current/os/$CARCH ? This structure has been there for ages now in the binary repos. >The other option is to have totally seperate trees and let each port manage >their own packages however they please. Personally, I don't like this way. >There's a lot more duplicated work (because problems have to be fixed >multiple times). You're essentially implementing your own distro that's >sharing the arch name. This means that everything can stay the same, but >managing the CVS tree (assuming it's still shared) becomes a real nasty >task (make change for one arch, commit, tag, undo changes for that arch, >make changes for different arch, commit, tag). It's a very inefficient use >of CVS and sure to lead to lots of mistakes in the long run. > > Agreed, I'm all for merging the PKGBUILDs as far as possible. Though someone still needs to come up with an idea for architecture specific packages like bootloaders (yaboot, quik, grub, lilo, pbbuttons etc.) >Anyway, I'm curious to hear your input on how you do stuff and which >changes you'd prefer. The discussion has happened between the developers, >but now it's out on the arch-ports list. > >About port acceptance, I have no idea. I was thinking we'd wait till the >other ports were managed by pacbuild, but things are moving forward slowly >(though they actually are moving forward!). Suggestions there too? > >Jason > > > >------------------------------------------------------------------------ > >_______________________________________________ >arch-ports mailing list >arch-ports at archlinux.org >http://www.archlinux.org/mailman/listinfo/arch-ports > > From jason at archlinux.org Wed Aug 10 10:58:34 2005 From: jason at archlinux.org (Jason Chu) Date: Wed, 10 Aug 2005 10:58:34 -0400 Subject: [arch-ports] integration of ports into original archlinux In-Reply-To: <42F8760D.2000900@disipos.de> References: <42F77CEA.8000807@disipos.de> <20050809042408.GA14950@mercury.xentac.net> <42F8760D.2000900@disipos.de> Message-ID: <20050810145834.GI14950@mercury.xentac.net> On Tue, Aug 09, 2005 at 11:23:25AM +0200, Alexander Baldeck wrote: > Jason Chu wrote: > > >On Mon, Aug 08, 2005 at 05:40:26PM +0200, Alexander Baldeck wrote: > > > >>hey list, > >>i am wondering about this quite some time now: > >>how will ports be handled by the main archlinux project for i686? as it seems there hasn't been much > >>talk about > >>this lately but a while ago Judd moved the repos to a new structure (os/i686) which seems to be a first > >>step. since > >>then i haven't heard much. > >>now then, i simply want to start another discussion. maybe to find a few things a port has to implement > >>before it > >>may be officially mentioned or even why they should not be considered as a part of the official > >>archlinux. > >> > >I've also been wondering this. I've tried to find good solutions to the > >problems that I saw, but I never really asked you guys what your methods > >are ;o) > >So, that's what I'll start with. Assume that we always want to have an ABS > >(basically cvsup) that reflects the current repo's packages. How do you do > >your package updating/building and repo updating? > > > In my case - the PPC port - the ABS script would still need to be modified since I still haven't > sucessfully > compiled cvsup itself. Also I got offered a Subversion repository on archlinuxfr.org and am happily using > it. > From my experience there are lots of feature I definetely wouldn't want to miss out on. Like what? The more features I have, the better argument I can make to move to it ;o) > Since ABS only wraps around a few CVS pulls in the i686 branch I could say that i have soemthing like ABS > as > well. I wrote something like that for the TUR way back, but it was shouted down by a different dev. The reason? We shouldn't have to have a different tool (or modify the existing tool) to access the TU repos. > Package updating normally is done by first modifying the PKGBUILD, building the package, test the > package, then > upload the binary and finally commit to SVN after generating a new db.tar.gz. There's a slight problem with this when working on it with more than one person (or multiple changes in one tree). If you make development changes to two seperate packages, but only want to sync one into the tree, how do you rollback (and not forget) your changes? In the multiple person situation, how do you (or they) see your updates when syncing? For the developers, our actual update script does a cvs co of a tagged version of cvs. Then we know we have the correct (not development) versions of everything (basically the packages that should be in the repo). > >My thinking was something like this: try to keep all the work in a single > >CVS tree, tagging things as CURRENT (as we do for i686), CURRENT-PPC, > >CURRENT-amd64, etc, using CARCH to make platform specific changes. This > >way the ports are essentially just modifying the global i686 packages. > >Obviously there are some architecture specific changes, but the direction > >of the packages is kept consistent over all the ports. > > > How would you do that? Here is how I think it could be done (this reflects the testing/xorg package for > ppc), > sorry for the long interruption of the textflow. ;) > > [snippet] > > # Maintainer: Alexander Baldeck > pkgname=xorg > pkgver=11R6.8.2 > pkgrel=3 > pkgdesc="A fork of the XFree86 Project with a GPL-compatible license" > url="http://www.x.org" > depends=('glibc' 'freetype1' 'fontconfig' 'gcc' 'libpng') > makedepends=('perl') > conflicts=('ttf-bitstream-vera' 'xfree86') > provides=('x-server' 'xfree86') > replaces=('x') > install=x.install > source=(http://ftp.skynet.be/pub/ftp.x.org/pub/X${pkgver}/src-single/X${pkgver}-src.tar.bz2 \ > http://www.joerg-pommnitz.de/TrueType/ttmkfdir.tar.gz xdm.pam \ > xterm256.patch libGL.la xorg.sh no-fc-cache-run.patch \ > macintosh-xkb-us-de-ibook.patch imakemdep_ppc.patch) > > build() { > # -fno-strict-aliasing seems to fix a problem with mkfontscale caused by > # gcc or freetype. mor information can be found here: > # http://lists.gnu.org/archive/html/freetype-devel/2005-04/msg00033.html > export CFLAGS=$"$CFLAGS -fno-strict-aliasing" > export CXXFLAGS=$"$CXXFLAGS -fno-strict-aliasing" > > cd $startdir/src > make FREETYPE_INCL=/usr/include/freetype || return 1 > install -D ttmkfdir $startdir/pkg/usr/X11R6/bin/ttmkfdir > > # fc-cache may segfault on misc. occasions > patch -p0 < no-fc-cache-run.patch > > if [ "$CARCH" = "ppc" ]; then > # some keyboard issues on ibooks > patch -p0 < macintosh-xkb-us-de-ibook.patch > fi > > > cd $startdir/src/xc > if [ "$CARCH" = "ppc" ]; then > patch -p0 < ../imakemdep_ppc.patch > fi > > # build fixes > sed -i 's|$(HARDCOPYDIR)||g' doc/Imakefile || return 1 > > if [ "$CARCH" = "ppc" ]; then > echo '#define LinuxDistName ArchLinux-ppc' >config/cf/host.def > fi > > if [ "$CARCH" = "i686" ]; then > echo '#define LinuxDistName ArchLinux-i686' >config/cf/host.def > fi > echo $"#define DefaultGcc2PpcOpt $CFLAGS -fno-strict-aliasing" >>config/cf/host.def > echo $'#define HasZlib YES' >> config/cf/host.def > echo $'#define HasNCurses YES' >> config/cf/host.def > echo $'#define HasFreetype2 YES' >> config/cf/host.def > echo $'#define HasLibpng YES' >> config/cf/host.def > echo $'#define UseExpat YES' >> config/cf/host.def > echo $'#define HasExpat YES' >> config/cf/host.def > #echo $'#define UseFontconfig YES' >> config/cf/host.def > echo $'#define HasFontconfig YES' >> config/cf/host.def > #echo '#define HasPam NO' >> config/cf/host.def > echo '#define BuildLinuxDocPS NO' >> config/cf/host.def > echo '#define BuildLinuxDocText NO' >> config/cf/host.def > echo '#define BuildLinuxDocHtml NO' >> config/cf/host.def > echo '#define BuildHtmlManPages NO' >> config/cf/host.def > echo '#define BuildSpecsDocs NO' >> config/cf/host.def > echo '#define BuildAllSpecsDocs NO' >> config/cf/host.def > echo '#define BuildXF86DRI YES' >> config/cf/host.def > echo '#define BuildXDriInfo YES' >> config/cf/host.def > echo '#define BuildGLXLibrary YES' >> config/cf/host.def > echo '#define BuildXdmcpLib YES' >> config/cf/host.def > echo '#define BuildXInputLib YES' >> config/cf/host.def > echo '#define BuildXvLibrary YES' >> config/cf/host.def > echo '#define SharedLibFont NO' >> config/cf/host.def > > #echo $'#define CcCmd $CC' >> config/cf/host.def > echo $"#define OptimizedCDebugFlags $CFLAGS" >> config/cf/host.def > echo $"#define OptimizedCplusplusDebugFlags $CXXFLAGS" >> config/cf/host.def > > # this should enable any available driver with dri where possible > echo "#define XF86CardDrivers mga glint s3virge sis savage trident chips tdfx fbdev ati DevelDrivers > vga nv imstt \ > XF86OSCardDrivers XF86ExtraCardDrivers" >> config/cf/host.def > echo '#define DevelDRIDrivers YES' >> config/cf/host.def > > # use this for relinking a compiled xorg source tree, > # it'll save lot's of time depending on how fast your system is > # ATTENTION: do not use when compiling from scratch as it will not > # generate deps > # make Everything || return 1 > make World || return 1 > make DESTDIR=$startdir/pkg install > rm -f programs/xkbcomp/rules/xfree86* > make DESTDIR=$startdir/pkg install.man > (cd $startdir/pkg/usr/include && ln -sf ../X11R6/include/X11 X11) > (cd $startdir/pkg/usr/include && ln -sf ../X11R6/include/GL GL) > > # exorcise the SysV demons and set up environment stuff > rm -rf $startdir/pkg/etc/rc.d/rc?.d > rm -f $startdir/pkg/etc/profile.d/xprint.csh > mv $startdir/pkg/etc/init.d/xprint $startdir/pkg/etc/rc.d/xprint > sed -i 's|init.d|rc.d|g' $startdir/pkg/etc/profile.d/xprint.sh > rmdir $startdir/pkg/etc/init.d > > # get the pkgconfig .pc files in the right place > mkdir -p $startdir/pkg/usr/lib/pkgconfig > mv $startdir/pkg/usr/X11R6/lib/pkgconfig/* $startdir/pkg/usr/lib/pkgconfig > > # XDG stuff > install -d -m755 $startdir/pkg/etc/xdg > install -D -m644 $startdir/src/xdm.pam $startdir/pkg/etc/pam.d/xdm > install -D -m755 $startdir/src/xorg.sh $startdir/pkg/etc/profile.d/xorg.sh > install -D -m644 $startdir/src/libGL.la $startdir/pkg/usr/lib/libGL.la > } > md5sums=('8131cd7ea1e4566e6e05c438a93fcfe1' 'dcf6aa4d28f5c52acf2bb57f49f53089'\ > '419d6289ba6f851135f5c70c0e3cbec4' '9d04512b66834aefecf32b15555c2f97'\ > '6b4052cf6d50cbd2854ebd3409f02695' 'f782bb79086e6e25c9e1182017f02a16'\ > 'f4b82c3357912726a5781df127f4e28b' '5e5220f4d55a9925b9b59576ed9b8a39'\ > '25b3637412556320593768db6bbb4a34') > > [/snippet] > > That is one possibility but as you can see it might get very messy if other CARCHes come in as well. > Which makes me thing this is far from perfect. I think the xorg example is a bad one. It's messy without multiple CARCH support. But even still, I think having a bunch of CARCH if's in there is much cleaner than having multiple copies of the PKGBUILDs. > >I even wrote a patch for gensync to build repos out of package files only. > >This does entail untaring each package to get the meta data though. But > >you don't need matching PKGBUILDs. One of the reasons to do this was to > >add a -$CARCH part to package files > >(---$CARCH.pkg.tar.gz); if gensync reads package > >information from the package itself, the package can be named anything you > >want. > > > What about current/os/$CARCH ? This structure has been there for ages now in the binary repos. That's what they say. You would still have current/os/$CARCH, but the idea is that you'd also be able to see the arch a specific package was built against even if it wasn't stored in a current/os/$CARCH path. > >The other option is to have totally seperate trees and let each port manage > >their own packages however they please. Personally, I don't like this way. > >There's a lot more duplicated work (because problems have to be fixed > >multiple times). You're essentially implementing your own distro that's > >sharing the arch name. This means that everything can stay the same, but > >managing the CVS tree (assuming it's still shared) becomes a real nasty > >task (make change for one arch, commit, tag, undo changes for that arch, > >make changes for different arch, commit, tag). It's a very inefficient use > >of CVS and sure to lead to lots of mistakes in the long run. > > > Agreed, I'm all for merging the PKGBUILDs as far as possible. Though someone still needs to come up > with an idea for architecture specific packages like bootloaders (yaboot, quik, grub, lilo, pbbuttons > etc.) One option (staying with the tagging method) is to just not tag it for that architecture. Then lilo would never be in the ppc repo, because it wasn't tagged CURRENT-PPC. Another way would be to patch makepkg to support an arch=() variable, so that gensync would just skip over the PKGBUILDs not supported by that arch. We're still not getting very far. How about I start with a bunch of questions to try and direct things. Would you want to stick with svn or move over (backwards) to cvs? If you wanted to go to cvs, we could share the same cvs tree, so that changes across the arches are more easily visible to you (and thus more easily merged). Unless you can find a very compelling argument, I'm sticking with the if $CARCH option because I like it. ;) Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From aba at disipos.de Wed Aug 10 11:35:26 2005 From: aba at disipos.de (Alexander Baldeck) Date: Wed, 10 Aug 2005 17:35:26 +0200 Subject: [arch-ports] integration of ports into original archlinux In-Reply-To: <20050810145834.GI14950@mercury.xentac.net> References: <42F77CEA.8000807@disipos.de> <20050809042408.GA14950@mercury.xentac.net> <42F8760D.2000900@disipos.de> <20050810145834.GI14950@mercury.xentac.net> Message-ID: <42FA1EBE.7010109@disipos.de> Jason Chu wrote: >On Tue, Aug 09, 2005 at 11:23:25AM +0200, Alexander Baldeck wrote: > > >>Jason Chu wrote: >> >> >> >>>On Mon, Aug 08, 2005 at 05:40:26PM +0200, Alexander Baldeck wrote: >>> >>> >>> >>>>hey list, >>>>i am wondering about this quite some time now: >>>>how will ports be handled by the main archlinux project for i686? as it seems there hasn't been much >>>>talk about >>>>this lately but a while ago Judd moved the repos to a new structure (os/i686) which seems to be a first >>>>step. since >>>>then i haven't heard much. >>>>now then, i simply want to start another discussion. maybe to find a few things a port has to implement >>>>before it >>>>may be officially mentioned or even why they should not be considered as a part of the official >>>>archlinux. >>>> >>>> >>>> >>>I've also been wondering this. I've tried to find good solutions to the >>>problems that I saw, but I never really asked you guys what your methods >>>are ;o) >>>So, that's what I'll start with. Assume that we always want to have an ABS >>>(basically cvsup) that reflects the current repo's packages. How do you do >>>your package updating/building and repo updating? >>> >>> >>> >>In my case - the PPC port - the ABS script would still need to be modified since I still haven't >>sucessfully >>compiled cvsup itself. Also I got offered a Subversion repository on archlinuxfr.org and am happily using >>it. >> From my experience there are lots of feature I definetely wouldn't want to miss out on. >> >> > >Like what? The more features I have, the better argument I can make to >move to it ;o) > > Well, can you easily move a directory somewhere else within the same repository without losing all archived versions? I've seen quite a couple of packages crossing the border between current and extra lately. ;-) $ svn move source/ destination/ $ cvs ?? On top of that it shouldn't be too time consuming to convert a CVS repo to SVN. You can even use SVN just like CVS, so you see that right now there's no reason for me to fall back to CVS. >>Package updating normally is done by first modifying the PKGBUILD, building the package, test the >>package, then >>upload the binary and finally commit to SVN after generating a new db.tar.gz. >> >> > >There's a slight problem with this when working on it with more than one >person (or multiple changes in one tree). If you make development changes >to two seperate packages, but only want to sync one into the tree, how do >you rollback (and not forget) your changes? In the multiple person >situation, how do you (or they) see your updates when syncing? > >For the developers, our actual update script does a cvs co of a tagged >version of cvs. Then we know we have the correct (not development) >versions of everything (basically the packages that should be in the repo). > > In detail I do it similar. Me uploading the package does not mean that I delete the old one imediately. Like you said, I generate the DB using a fresh ABS tree from SVN right after I commited my changes first. Still, you are right that I don't have a plan to have several devs working on the port yet, simply because there hasn't been one other really contributing regularly in the past 1.2 years. That's also why I didn't tag a release yet. I can't say for sure that everything works stable enough to tag it CURRENT or whatever yet because I only use what I need. >>>My thinking was something like this: try to keep all the work in a single >>>CVS tree, tagging things as CURRENT (as we do for i686), CURRENT-PPC, >>>CURRENT-amd64, etc, using CARCH to make platform specific changes. This >>>way the ports are essentially just modifying the global i686 packages. >>>Obviously there are some architecture specific changes, but the direction >>>of the packages is kept consistent over all the ports. >>> >>> >>> >>That is one possibility but as you can see it might get very messy if other CARCHes come in as well. >>Which makes me thing this is far from perfect. >> >> > >I think the xorg example is a bad one. It's messy without multiple CARCH >support. But even still, I think having a bunch of CARCH if's in there is >much cleaner than having multiple copies of the PKGBUILDs. > > > Yeah, that's a critical package here though since I've messed with it for weeks a while back until I finally got it fully working. The kernel package would have been even worse. ;-) >>>I even wrote a patch for gensync to build repos out of package files only. >>>This does entail untaring each package to get the meta data though. But >>>you don't need matching PKGBUILDs. One of the reasons to do this was to >>>add a -$CARCH part to package files >>>(---$CARCH.pkg.tar.gz); if gensync reads package >>>information from the package itself, the package can be named anything you >>>want. >>> >>> >>> >>What about current/os/$CARCH ? This structure has been there for ages now in the binary repos. >> >> > >That's what they say. You would still have current/os/$CARCH, but the idea >is that you'd also be able to see the arch a specific package was built >against even if it wasn't stored in a current/os/$CARCH path. > > You can already! At least since makepkg 2.9.2 - so far back I've checked - the .PKGINFO in a compiled packages comes with an architecture tag. The current libtool package for example carries one that looks like this: [snippet] builddate = Thu May 19 15:55:25 2005 packager = Arch Linux (http://www.archlinux.org) size = 2313395 arch = i686 depend = bash [/snippet] The problem here is that pacman (2.9.6) does not seem to care about what's in there regarding arch yet, meaning I can still install a ppc package "without any problem".... *cough* >>>The other option is to have totally seperate trees and let each port manage >>>their own packages however they please. Personally, I don't like this way. >>>There's a lot more duplicated work (because problems have to be fixed >>>multiple times). You're essentially implementing your own distro that's >>>sharing the arch name. This means that everything can stay the same, but >>>managing the CVS tree (assuming it's still shared) becomes a real nasty >>>task (make change for one arch, commit, tag, undo changes for that arch, >>>make changes for different arch, commit, tag). It's a very inefficient use >>>of CVS and sure to lead to lots of mistakes in the long run. >>> >>> >>> >>Agreed, I'm all for merging the PKGBUILDs as far as possible. Though someone still needs to come up >>with an idea for architecture specific packages like bootloaders (yaboot, quik, grub, lilo, pbbuttons >>etc.) >> >> > >One option (staying with the tagging method) is to just not tag it for that >architecture. Then lilo would never be in the ppc repo, because it wasn't >tagged CURRENT-PPC. > >Another way would be to patch makepkg to support an arch=() variable, so >that gensync would just skip over the PKGBUILDs not supported by that arch. > > Very true, the tagging method sounds reasonable. I would like to keep makepkg as it is though. >We're still not getting very far. How about I start with a bunch of >questions to try and direct things. > >Would you want to stick with svn or move over (backwards) to cvs? If you >wanted to go to cvs, we could share the same cvs tree, so that changes >across the arches are more easily visible to you (and thus more easily >merged). > > I wouldn't mind to continue using SVN but this should sure not result in multiple development trees so I'd rather move to CVS than to have to create a totally seperated archderivate for another platform. >Unless you can find a very compelling argument, I'm sticking with the if >$CARCH option because I like it. ;) > > It's ok to use $CARCH sections in a packagebuild but it would be nice to have makepkg being able to handle different "sourcesets". Example: kernel26 needs a few patches which are mostly platform independent - yes - but the config is distinct for every platform. So I would be nice to have a way to tag CURRENT only let's say config.ppc but not config.i686 since it's really not needed for ppc but then still have a working package build. Only a cosmetic problem though. Alex From i.galic at gmail.com Wed Aug 10 15:42:17 2005 From: i.galic at gmail.com (Igor Galic) Date: Wed, 10 Aug 2005 21:42:17 +0200 Subject: [arch-ports] integration of ports into original archlinux In-Reply-To: <42F8760D.2000900@disipos.de> References: <42F77CEA.8000807@disipos.de> <20050809042408.GA14950@mercury.xentac.net> <42F8760D.2000900@disipos.de> Message-ID: <42FA5899.3000504@gmail.com> Alexander Baldeck wrote: > Jason Chu wrote: > >> On Mon, Aug 08, 2005 at 05:40:26PM +0200, Alexander Baldeck wrote: >> >> >>> hey list, >>> >>> i am wondering about this quite some time now: >>> >>> how will ports be handled by the main archlinux project for i686? as >>> it seems there hasn't been much talk about >>> this lately but a while ago Judd moved the repos to a new structure >>> (os/i686) which seems to be a first step. since >>> then i haven't heard much. >>> >>> now then, i simply want to start another discussion. maybe to find a >>> few things a port has to implement before it >>> may be officially mentioned or even why they should not be considered >>> as a part of the official archlinux. >>> >> >> >> I've also been wondering this. I've tried to find good solutions to the >> problems that I saw, but I never really asked you guys what your methods >> are ;o) >> >> So, that's what I'll start with. Assume that we always want to have >> an ABS >> (basically cvsup) that reflects the current repo's packages. How do >> you do >> your package updating/building and repo updating? >> >> > In my case - the PPC port - the ABS script would still need to be > modified since I still haven't sucessfully > compiled cvsup itself. Also I got offered a Subversion repository on > archlinuxfr.org and am happily using it. > From my experience there are lots of feature I definetely wouldn't want > to miss out on. > Since ABS only wraps around a few CVS pulls in the i686 branch I could > say that i have soemthing like ABS as > well. > > Package updating normally is done by first modifying the PKGBUILD, > building the package, test the package, then > upload the binary and finally commit to SVN after generating a new > db.tar.gz. > >> My thinking was something like this: try to keep all the work in a single >> CVS tree, tagging things as CURRENT (as we do for i686), CURRENT-PPC, >> CURRENT-amd64, etc, using CARCH to make platform specific changes. This >> way the ports are essentially just modifying the global i686 packages. >> Obviously there are some architecture specific changes, but the direction >> of the packages is kept consistent over all the ports. >> >> > How would you do that? Here is how I think it could be done (this > reflects the testing/xorg package for ppc), > sorry for the long interruption of the textflow. ;) > > [snippet] > > # Maintainer: Alexander Baldeck > pkgname=xorg > pkgver=11R6.8.2 > pkgrel=3 > pkgdesc="A fork of the XFree86 Project with a GPL-compatible license" > url="http://www.x.org" > depends=('glibc' 'freetype1' 'fontconfig' 'gcc' 'libpng') > makedepends=('perl') > conflicts=('ttf-bitstream-vera' 'xfree86') > provides=('x-server' 'xfree86') > replaces=('x') > install=x.install > source=(http://ftp.skynet.be/pub/ftp.x.org/pub/X${pkgver}/src-single/X${pkgver}-src.tar.bz2 > \ > http://www.joerg-pommnitz.de/TrueType/ttmkfdir.tar.gz xdm.pam \ > xterm256.patch libGL.la xorg.sh no-fc-cache-run.patch \ > macintosh-xkb-us-de-ibook.patch imakemdep_ppc.patch) > > build() { > # -fno-strict-aliasing seems to fix a problem with mkfontscale caused by > # gcc or freetype. mor information can be found here: > # http://lists.gnu.org/archive/html/freetype-devel/2005-04/msg00033.html > export CFLAGS=$"$CFLAGS -fno-strict-aliasing" > export CXXFLAGS=$"$CXXFLAGS -fno-strict-aliasing" > > cd $startdir/src > make FREETYPE_INCL=/usr/include/freetype || return 1 > install -D ttmkfdir $startdir/pkg/usr/X11R6/bin/ttmkfdir > > # fc-cache may segfault on misc. occasions > patch -p0 < no-fc-cache-run.patch > > if [ "$CARCH" = "ppc" ]; then > # some keyboard issues on ibooks > patch -p0 < macintosh-xkb-us-de-ibook.patch > fi > > > cd $startdir/src/xc > > if [ "$CARCH" = "ppc" ]; then > patch -p0 < ../imakemdep_ppc.patch > fi > > # build fixes > sed -i 's|$(HARDCOPYDIR)||g' doc/Imakefile || return 1 > > if [ "$CARCH" = "ppc" ]; then > echo '#define LinuxDistName ArchLinux-ppc' >config/cf/host.def > fi > > if [ "$CARCH" = "i686" ]; then > echo '#define LinuxDistName ArchLinux-i686' >config/cf/host.def > fi > > echo $"#define DefaultGcc2PpcOpt $CFLAGS -fno-strict-aliasing" > >>config/cf/host.def > echo $'#define HasZlib YES' >> config/cf/host.def > echo $'#define HasNCurses YES' >> config/cf/host.def > echo $'#define HasFreetype2 YES' >> config/cf/host.def > echo $'#define HasLibpng YES' >> config/cf/host.def > echo $'#define UseExpat YES' >> config/cf/host.def > echo $'#define HasExpat YES' >> config/cf/host.def > #echo $'#define UseFontconfig YES' >> config/cf/host.def > echo $'#define HasFontconfig YES' >> config/cf/host.def > #echo '#define HasPam NO' >> config/cf/host.def > echo '#define BuildLinuxDocPS NO' >> config/cf/host.def > echo '#define BuildLinuxDocText NO' >> config/cf/host.def > echo '#define BuildLinuxDocHtml NO' >> config/cf/host.def > echo '#define BuildHtmlManPages NO' >> config/cf/host.def > echo '#define BuildSpecsDocs NO' >> config/cf/host.def > echo '#define BuildAllSpecsDocs NO' >> config/cf/host.def > echo '#define BuildXF86DRI YES' >> config/cf/host.def > echo '#define BuildXDriInfo YES' >> config/cf/host.def > echo '#define BuildGLXLibrary YES' >> config/cf/host.def > echo '#define BuildXdmcpLib YES' >> config/cf/host.def > echo '#define BuildXInputLib YES' >> config/cf/host.def > echo '#define BuildXvLibrary YES' >> config/cf/host.def > echo '#define SharedLibFont NO' >> config/cf/host.def > > #echo $'#define CcCmd $CC' >> config/cf/host.def > echo $"#define OptimizedCDebugFlags $CFLAGS" >> config/cf/host.def > echo $"#define OptimizedCplusplusDebugFlags $CXXFLAGS" >> > config/cf/host.def > > # this should enable any available driver with dri where possible > echo "#define XF86CardDrivers mga glint s3virge sis savage trident > chips tdfx fbdev ati DevelDrivers vga nv imstt \ > XF86OSCardDrivers XF86ExtraCardDrivers" >> config/cf/host.def > echo '#define DevelDRIDrivers YES' >> config/cf/host.def > > # use this for relinking a compiled xorg source tree, > # it'll save lot's of time depending on how fast your system is > # ATTENTION: do not use when compiling from scratch as it will not > # generate deps > # make Everything || return 1 > make World || return 1 > make DESTDIR=$startdir/pkg install > rm -f programs/xkbcomp/rules/xfree86* > make DESTDIR=$startdir/pkg install.man > (cd $startdir/pkg/usr/include && ln -sf ../X11R6/include/X11 X11) > (cd $startdir/pkg/usr/include && ln -sf ../X11R6/include/GL GL) > > # exorcise the SysV demons and set up environment stuff > rm -rf $startdir/pkg/etc/rc.d/rc?.d > rm -f $startdir/pkg/etc/profile.d/xprint.csh > mv $startdir/pkg/etc/init.d/xprint $startdir/pkg/etc/rc.d/xprint > sed -i 's|init.d|rc.d|g' $startdir/pkg/etc/profile.d/xprint.sh > rmdir $startdir/pkg/etc/init.d > > # get the pkgconfig .pc files in the right place > mkdir -p $startdir/pkg/usr/lib/pkgconfig > mv $startdir/pkg/usr/X11R6/lib/pkgconfig/* $startdir/pkg/usr/lib/pkgconfig > > # XDG stuff > install -d -m755 $startdir/pkg/etc/xdg > install -D -m644 $startdir/src/xdm.pam $startdir/pkg/etc/pam.d/xdm > install -D -m755 $startdir/src/xorg.sh $startdir/pkg/etc/profile.d/xorg.sh > install -D -m644 $startdir/src/libGL.la $startdir/pkg/usr/lib/libGL.la > } > md5sums=('8131cd7ea1e4566e6e05c438a93fcfe1' > 'dcf6aa4d28f5c52acf2bb57f49f53089'\ > '419d6289ba6f851135f5c70c0e3cbec4' > '9d04512b66834aefecf32b15555c2f97'\ > '6b4052cf6d50cbd2854ebd3409f02695' > 'f782bb79086e6e25c9e1182017f02a16'\ > 'f4b82c3357912726a5781df127f4e28b' > '5e5220f4d55a9925b9b59576ed9b8a39'\ > '25b3637412556320593768db6bbb4a34') > > [/snippet] > > That is one possibility but as you can see it might get very messy if > other CARCHes come in as well. > Which makes me thing this is far from perfect. > > >> I even wrote a patch for gensync to build repos out of package files >> only. >> This does entail untaring each package to get the meta data though. But >> you don't need matching PKGBUILDs. One of the reasons to do this was to >> add a -$CARCH part to package files >> (---$CARCH.pkg.tar.gz); if gensync reads package >> information from the package itself, the package can be named anything >> you >> want. >> >> > What about current/os/$CARCH ? This structure has been there for ages > now in the binary repos. > >> The other option is to have totally seperate trees and let each port >> manage >> their own packages however they please. Personally, I don't like this >> way. >> There's a lot more duplicated work (because problems have to be fixed >> multiple times). You're essentially implementing your own distro that's >> sharing the arch name. This means that everything can stay the same, but >> managing the CVS tree (assuming it's still shared) becomes a real nasty >> task (make change for one arch, commit, tag, undo changes for that arch, >> make changes for different arch, commit, tag). It's a very >> inefficient use >> of CVS and sure to lead to lots of mistakes in the long run. >> >> > Agreed, I'm all for merging the PKGBUILDs as far as possible. Though > someone still needs to come up > with an idea for architecture specific packages like bootloaders > (yaboot, quik, grub, lilo, pbbuttons etc.) > >> Anyway, I'm curious to hear your input on how you do stuff and which >> changes you'd prefer. The discussion has happened between the >> developers, >> but now it's out on the arch-ports list. >> >> About port acceptance, I have no idea. I was thinking we'd wait till the >> other ports were managed by pacbuild, but things are moving forward >> slowly >> (though they actually are moving forward!). Suggestions there too? >> >> Jason >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> arch-ports mailing list >> arch-ports at archlinux.org >> http://www.archlinux.org/mailman/listinfo/arch-ports >> >> > > > _______________________________________________ > arch-ports mailing list > arch-ports at archlinux.org > http://www.archlinux.org/mailman/listinfo/arch-ports > IF i look at this PKGBUILD I don't feel like this is the way things should go.. or at least I don't thing this is the way things are done in Arch. The more simpler solution would be to simply seperate the PKGBUILDS/pkgs like Judd already started. I can imagine one thing: [snip] # Architecture : PPC # $Id: PKGBUILD,v 1.52 2005/07/13 20:09:02 joe Exp $ # Maintainer: joe [/snip] So long, Igor From jason at archlinux.org Wed Aug 10 21:17:04 2005 From: jason at archlinux.org (Jason Chu) Date: Wed, 10 Aug 2005 21:17:04 -0400 Subject: [arch-ports] integration of ports into original archlinux In-Reply-To: <42FA1EBE.7010109@disipos.de> References: <42F77CEA.8000807@disipos.de> <20050809042408.GA14950@mercury.xentac.net> <42F8760D.2000900@disipos.de> <20050810145834.GI14950@mercury.xentac.net> <42FA1EBE.7010109@disipos.de> Message-ID: <20050811011704.GL14950@mercury.xentac.net> On Wed, Aug 10, 2005 at 05:35:26PM +0200, Alexander Baldeck wrote: > Jason Chu wrote: > > >On Tue, Aug 09, 2005 at 11:23:25AM +0200, Alexander Baldeck wrote: > > > >>Jason Chu wrote: > >> > >>>On Mon, Aug 08, 2005 at 05:40:26PM +0200, Alexander Baldeck wrote: > >>> > >>>>hey list, > >>>>i am wondering about this quite some time now: > >>>>how will ports be handled by the main archlinux project for i686? as it seems there hasn't been much > >>>>talk about > >>>>this lately but a while ago Judd moved the repos to a new structure (os/i686) which seems to be a > >>>>first step. since > >>>>then i haven't heard much. > >>>>now then, i simply want to start another discussion. maybe to find a few things a port has to > >>>>implement before it > >>>>may be officially mentioned or even why they should not be considered as a part of the official > >>>>archlinux. > >>>> > >>>I've also been wondering this. I've tried to find good solutions to the > >>>problems that I saw, but I never really asked you guys what your methods > >>>are ;o) > >>>So, that's what I'll start with. Assume that we always want to have an ABS > >>>(basically cvsup) that reflects the current repo's packages. How do you do > >>>your package updating/building and repo updating? > >>> > >>In my case - the PPC port - the ABS script would still need to be modified since I still haven't > >>sucessfully > >>compiled cvsup itself. Also I got offered a Subversion repository on archlinuxfr.org and am happily > >>using it. > >>From my experience there are lots of feature I definetely wouldn't want to miss out on. > >> > >Like what? The more features I have, the better argument I can make to > >move to it ;o) > > > Well, can you easily move a directory somewhere else within the same repository without losing all > archived versions? I've seen quite a couple of packages crossing the border between current and extra > lately. ;-) > > $ svn move source/ destination/ > > $ cvs ?? > > On top of that it shouldn't be too time consuming to convert a CVS repo to SVN. You can even use SVN > just like CVS, so you see that right now there's no reason for me to fall back to CVS. Ok, just remember, you're not trying to convince me. I'd like to move to svn across the board (it's better than cvs, but darcs would be kinda cool ;o) ), but I know all the arguments against. Here we go: - Packages rarely move between extra and current, so we don't really need that functionality and when we do, it's no big deal to just delete one and add the other. - Extra and current are two different repositories so that wouldn't work anyway. - The way we use tags (not exactly the best way) doesn't easily map over to svn's tag usage (ok, that was mostly my own, but it was an amalgamation of some other ideas as well). > >>Package updating normally is done by first modifying the PKGBUILD, building the package, test the > >>package, then > >>upload the binary and finally commit to SVN after generating a new db.tar.gz. > >> > >There's a slight problem with this when working on it with more than one > >person (or multiple changes in one tree). If you make development changes > >to two seperate packages, but only want to sync one into the tree, how do > >you rollback (and not forget) your changes? In the multiple person > >situation, how do you (or they) see your updates when syncing? > >For the developers, our actual update script does a cvs co of a tagged > >version of cvs. Then we know we have the correct (not development) > >versions of everything (basically the packages that should be in the repo). > > > In detail I do it similar. Me uploading the package does not mean that I delete the old one imediately. > Like you said, I generate the DB using a fresh ABS tree from SVN right after I commited my changes first. > > Still, you are right that I don't have a plan to have several devs working on the port yet, simply > because > there hasn't been one other really contributing regularly in the past 1.2 years. That's also why I didn't > tag > a release yet. I can't say for sure that everything works stable enough to tag it CURRENT or whatever yet > because I only use what I need. Well, in our case, we don't tag things as CURRENT when they're stable, we tag them as CURRENT when they go into the repo. There's a subtle difference there ;o) > >>>My thinking was something like this: try to keep all the work in a single > >>>CVS tree, tagging things as CURRENT (as we do for i686), CURRENT-PPC, > >>>CURRENT-amd64, etc, using CARCH to make platform specific changes. This > >>>way the ports are essentially just modifying the global i686 packages. > >>>Obviously there are some architecture specific changes, but the direction > >>>of the packages is kept consistent over all the ports. > >>> > >>That is one possibility but as you can see it might get very messy if other CARCHes come in as well. > >>Which makes me thing this is far from perfect. > >> > >I think the xorg example is a bad one. It's messy without multiple CARCH > >support. But even still, I think having a bunch of CARCH if's in there is > >much cleaner than having multiple copies of the PKGBUILDs. > > > Yeah, that's a critical package here though since I've messed with it for weeks a while back until I > finally > got it fully working. The kernel package would have been even worse. ;-) Sure, but the majority of packages won't be that bad. I suspect the majority of packages just work. Not saying the ones that are bad aren't difficult, but the sheer number of the ones that don't need to be modified is probably pretty high. > >>>I even wrote a patch for gensync to build repos out of package files only. > >>>This does entail untaring each package to get the meta data though. But > >>>you don't need matching PKGBUILDs. One of the reasons to do this was to > >>>add a -$CARCH part to package files > >>>(---$CARCH.pkg.tar.gz); if gensync reads package > >>>information from the package itself, the package can be named anything you > >>>want. > >>> > >>What about current/os/$CARCH ? This structure has been there for ages now in the binary repos. > >> > >That's what they say. You would still have current/os/$CARCH, but the idea > >is that you'd also be able to see the arch a specific package was built > >against even if it wasn't stored in a current/os/$CARCH path. > > > You can already! At least since makepkg 2.9.2 - so far back I've checked - the .PKGINFO Not by looking at the filename... before you download it... > in a compiled packages comes with an architecture tag. The current libtool package for > example carries one that looks like this: > > [snippet] > > builddate = Thu May 19 15:55:25 2005 > packager = Arch Linux (http://www.archlinux.org) > size = 2313395 > arch = i686 > depend = bash > > [/snippet] > > > The problem here is that pacman (2.9.6) does not seem to care about what's in there regarding > arch yet, meaning I can still install a ppc package "without any problem".... *cough* Pacman has no notion of arch, except as a string of information. This should probably be fixed someday ;) > >>>The other option is to have totally seperate trees and let each port manage > >>>their own packages however they please. Personally, I don't like this way. > >>>There's a lot more duplicated work (because problems have to be fixed > >>>multiple times). You're essentially implementing your own distro that's > >>>sharing the arch name. This means that everything can stay the same, but > >>>managing the CVS tree (assuming it's still shared) becomes a real nasty > >>>task (make change for one arch, commit, tag, undo changes for that arch, > >>>make changes for different arch, commit, tag). It's a very inefficient use > >>>of CVS and sure to lead to lots of mistakes in the long run. > >>> > >>Agreed, I'm all for merging the PKGBUILDs as far as possible. Though someone still needs to come up > >>with an idea for architecture specific packages like bootloaders (yaboot, quik, grub, lilo, pbbuttons > >>etc.) > >> > >One option (staying with the tagging method) is to just not tag it for that > >architecture. Then lilo would never be in the ppc repo, because it wasn't > >tagged CURRENT-PPC. > >Another way would be to patch makepkg to support an arch=() variable, so > >that gensync would just skip over the PKGBUILDs not supported by that arch. > > > Very true, the tagging method sounds reasonable. I would like to keep makepkg as it is though. So would I. I forgot to mention that Judd rejected a patch that did just that. It was one of VMiklos'. > >We're still not getting very far. How about I start with a bunch of > >questions to try and direct things. > >Would you want to stick with svn or move over (backwards) to cvs? If you > >wanted to go to cvs, we could share the same cvs tree, so that changes > >across the arches are more easily visible to you (and thus more easily > >merged). > > > I wouldn't mind to continue using SVN but this should sure not result in multiple development trees > so I'd rather move to CVS than to have to create a totally seperated archderivate for another platform. That's my thinking. That's why I want to keep the ports from splitting off as much as possible. And that's why I want to keep a single PKGBUILD with arch specific modifications. > >Unless you can find a very compelling argument, I'm sticking with the if > >$CARCH option because I like it. ;) > > > It's ok to use $CARCH sections in a packagebuild but it would be nice to have makepkg being able > to handle different "sourcesets". > > Example: > > kernel26 needs a few patches which are mostly platform independent - yes - but the config is distinct > for every platform. > > So I would be nice to have a way to tag CURRENT only let's say config.ppc but not > config.i686 since it's really not needed for ppc but then still have a working package build. > Only a cosmetic problem though. Hmm, interesting point. That still means you have to merge changes in the config.i686 file into config.ppc file IF they don't directly affect i686 machines (like enabling more netfilter modules, for example). Couldn't you just modify the PKGBUILD to make some arch specific customizations (like split out only the options directly related to that arch and then cat config config.ppc > config)? I'm trying to minimize the number of manual merges... Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jason at archlinux.org Wed Aug 10 21:23:27 2005 From: jason at archlinux.org (Jason Chu) Date: Wed, 10 Aug 2005 21:23:27 -0400 Subject: [arch-ports] integration of ports into original archlinux In-Reply-To: <42FA5899.3000504@gmail.com> References: <42F77CEA.8000807@disipos.de> <20050809042408.GA14950@mercury.xentac.net> <42F8760D.2000900@disipos.de> <42FA5899.3000504@gmail.com> Message-ID: <20050811012327.GM14950@mercury.xentac.net> > IF i look at this PKGBUILD I don't feel like this is the way things should go.. or at least I don't thing > this is the way things are done in Arch. > > The more simpler solution would be to simply seperate the PKGBUILDS/pkgs like Judd already started. My problem with seperating PKGBUILDs is, if we actually want to keep the ppc version of arch with the same options as the i686 version, there will be a lot of manual merging. Nothing in our process would help to keep them together. We'd essentially be using arch i686 as a base and creating a new distro that may or may not be anything like the arch i686 now. Which also seems to (on the surface) mean we need just as many developers for each port. > I can imagine one thing: > [snip] > # Architecture : PPC > # $Id: PKGBUILD,v 1.52 2005/07/13 20:09:02 joe Exp $ > # Maintainer: joe > [/snip] That means we have many PKGBUILDs that are exactly the same across ports, but it's difficult to know which are which. There's lots of duplicated data. Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From aba at disipos.de Tue Aug 23 11:10:09 2005 From: aba at disipos.de (Alexander Baldeck) Date: Tue, 23 Aug 2005 17:10:09 +0200 Subject: [arch-ports] PPC Port Developer List Reset Message-ID: <430B3C51.7060508@disipos.de> Hey List, I am going to wipe all currently registered SVN accounts from the PPC repo in the next few days, as most people haven't done a thing yet or at least didn't seem to. However, I'm open for new devs so feel free to contact me. Also I need to have at least one other dev who will be able to manage the whole thing while I am unavailable. This actually happens quite often, since I travel a lot and might not get the chance to hook up with the internet. regards, -kth5 From jason at archlinux.org Wed Aug 24 16:45:36 2005 From: jason at archlinux.org (Jason Chu) Date: Wed, 24 Aug 2005 16:45:36 -0400 Subject: [arch-ports] pacbuild status and design Message-ID: <20050824204536.GA17642@mercury.xentac.net> First I'll go over the basic design of pacbuild, then I'll highlight how far I am, and then I'll explain the the problems I see so far. My original goal with pacbuild was to write a program that would scan abs for package discrepencies between different architecture's repos (well, between i686 and everything else), build the new package for that architecture, and stick it in the appropriate repo. I broke the design into four pieces: peach, cherry, strawberry, and waka. Peach is the web interface for package validation. Cherry is the main build manager, it scans the abs repo, queues packages, sends them to remote strawberry instances, sets them to be validated, and adds them to the repo after validation. Strawberry runs on each remote build machine. It gets builds from cherry and sends them to waka to be built. Waka takes a source package (I can explain this later if needed), builds it in a clean chroot, and spits out a binary package. Currently cherry does everything up to the validation part and strawberry and waka are complete. Peach is still but a twinkle in my eye. Now the fun part: problems. I started pacbuild for i586. It worked really well, because packages are very rarely modified from i686 to i586. There was no real need for a cvsup tree and whatnot. I also designed cherry to do too much. I should probably make another one or two daemons in there. One, at least, to scan the repos and queue packages. That way cherry can just worry about managing all the remote builds. The other daemon would be for putting the packages back into the repos. The only reason I would develop this seperately is then we could use it for i686 as well. The way pacbuild was designed originally, it needed the single-PKGBUILD-for-all-architectures method. It depended on all PKGBUILDs working for all architectures and tried to build them for all architectures without those architecture developers even having looked at an update. This way architecture developers become more of a manager than an active maintainer. The problem here is that each architecture's version of a package (if the newer version isn't in the ppc repo, for example) isn't accessible in abs. To do the abs thing for each individual architecture, we need to tag them at the very least (have seperate repos at the most). Tagging them pretty much means they'd need someone looking at them. It's possible that the build script could tag all the ones that were verified, but developers would still need to fix problems that showed up and tag those. As far as I know, Debian does it with one source package for many architectures. They also have different source sharing methods (I don't know exactly how they work). Frugalware does it with multiple repos, I believe. Gentoo has people sign off on each package on each architecture, but they sort of have to in gentoo... Comments? Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From syamajala at gamebox.net Tue Aug 30 17:37:22 2005 From: syamajala at gamebox.net (Seshu Yamajala) Date: Tue, 30 Aug 2005 17:37:22 -0400 Subject: [arch-ports] x86_64 update Message-ID: <20050830173722.036eb851.syamajala@gamebox.net> ok, its been a while since i have actually done some work on the port. Today I grabbed the latest pkgbuilds from testing, current, extra, and started working on gcc 4. The packages will now support the emt64 and amd64 chips. I have also decided that 32bit support will be included in the base install. This make life much easier for me and anyone else who decides to help out. Many things like the ati drivers, grub, opera, and openoffice 1 will only work with 32bit "stuff" installed. Also i am gonna start a subversion repo soon and put pkgbuilds up. Xentac knows how i was doing things before. I had managed 2 dirs. one where development occured (packages were built there, pkgbuilds were edited...) and one where the final pkgbuild for the package was kept. It worked fine for me, but people weren't able to see the pkgbuilds or get them from me unless i put them on my web server. Since cvsup is still messed up on x86_64 i'm gonna go with subversion. I have no experience in these thi ngs (subversion, cvs, ...), so if i shouldn't use subversion or something please tell me. - Seshu Yamajala (syamajala) From aba at disipos.de Wed Aug 31 06:24:51 2005 From: aba at disipos.de (Alexander Baldeck) Date: Wed, 31 Aug 2005 12:24:51 +0200 Subject: [arch-ports] New PPC Mirror Message-ID: <43158573.90206@disipos.de> Hey List, just underwent the hassle to finally set up my very own server for to mirror the ppc packages. Feel free to give it a shot: [current] Server = http://kleiner-weise.de/~kth5/archlinux/current/os/ppc [testing] Server = http://kleiner-weise.de/~kth5/archlinux/testing/os/ppc Additionally everyone who rsyncs the packages should start to use this machine instead as well: rsync kleiner-weise.de::archppc-current/ rsync kleiner-weise.de::archppc-testing/ Extra will not be mirrored since it is *NOT* maintained at the moment! regards, -kth5 From syamajala at gamebox.net Wed Aug 31 09:16:04 2005 From: syamajala at gamebox.net (seshu yamajala) Date: Wed, 31 Aug 2005 09:16:04 -0400 Subject: [arch-ports] New PPC Mirror In-Reply-To: <43158573.90206@disipos.de> References: <43158573.90206@disipos.de> Message-ID: On Aug 31, 2005, at 6:24 AM, Alexander Baldeck wrote: > > Additionally everyone who rsyncs the packages should start to use > this machine instead > as well: > > rsync kleiner-weise.de::archppc-current/ > rsync kleiner-weise.de::archppc-testing/ > > > Extra will not be mirrored since it is *NOT* maintained at the moment! > _______________________________________________ I can mirror the ppc packages too. First, I just wanna fix the issues I'm having with my server. The video card is messed up and for some reason the time is always off by like a day. - Seshu Yamajala From aba at disipos.de Wed Aug 31 17:58:24 2005 From: aba at disipos.de (Alexander Baldeck) Date: Wed, 31 Aug 2005 23:58:24 +0200 Subject: [arch-ports] pacbuild status and design In-Reply-To: <20050824204536.GA17642@mercury.xentac.net> References: <20050824204536.GA17642@mercury.xentac.net> Message-ID: <43162800.1090100@disipos.de> Jason Chu wrote: >Now the fun part: problems. I started pacbuild for i586. It worked really >well, because packages are very rarely modified from i686 to i586. There >was no real need for a cvsup tree and whatnot. > > I hear you! Cvsup it a overhead only, if you x86 guys had'nt set a password for eradonly anonymous not even bypassing a password prompt would have been necessary. ;-) Not to speak of the fact that Emz3 only runs on a platform where there is already a bootstrapped Emz3 compiler, which I haven't found for PPC yet. If it were possible I'd like to see everyone move away from it and use plain CVS or Subversion at best. >I also designed cherry to do too much. I should probably make another one >or two daemons in there. One, at least, to scan the repos and queue >packages. That way cherry can just worry about managing all the remote >builds. The other daemon would be for putting the packages back into the >repos. The only reason I would develop this seperately is then we could >use it for i686 as well. > >The way pacbuild was designed originally, it needed the >single-PKGBUILD-for-all-architectures method. It depended on all PKGBUILDs >working for all architectures and tried to build them for all architectures >without those architecture developers even having looked at an update. >This way architecture developers become more of a manager than an active >maintainer. > > I cannot agree more, all of the maintainers should always try to keep the PKGBUILDs exactly the same wherevere possible. Debian does it by the lowest deminor I think, stripping features off the configure until it works everywhere. Archlinux users might not agree with that, so do I. So smaller if[ $CARCH ] sections are totally ok. Unless some really obscure platforms such as ARM32, m68K or even SH-* are planned we won't have a problem. And even then, we could still have like a Archembedded or whatever. >The problem here is that each architecture's version of a package (if the >newer version isn't in the ppc repo, for example) isn't accessible in abs. >To do the abs thing for each individual architecture, we need to tag them >at the very least (have seperate repos at the most). Tagging them pretty >much means they'd need someone looking at them. It's possible that the >build script could tag all the ones that were verified, but developers >would still need to fix problems that showed up and tag those. > > Do you mean for instance something like this? 2 kinds of tags in CVS for the latest stable: CURRENT-I686 CURRENT-PPC Then I do not see a problem with the fact that a new PKGBUILD might not yet be available for all platforms as soon as one platform's maintainer updated it. I think reviewing and kind of signing the package for other architectures is a must, not a problem in itself. If a user want's stuff that has not necessarily been tested or even been uploaded to be tested, he checks out the HEAD or whatever which always works for getting *all* the latest PKGBULDs, unlike TESTING-I686 on ppc f.e. - kth5 From jason at archlinux.org Wed Aug 31 18:17:50 2005 From: jason at archlinux.org (Jason Chu) Date: Wed, 31 Aug 2005 18:17:50 -0400 Subject: [arch-ports] pacbuild status and design In-Reply-To: <43162800.1090100@disipos.de> References: <20050824204536.GA17642@mercury.xentac.net> <43162800.1090100@disipos.de> Message-ID: <20050831221750.GA19577@mercury.xentac.net> On Wed, Aug 31, 2005 at 11:58:24PM +0200, Alexander Baldeck wrote: > Jason Chu wrote: > > >Now the fun part: problems. I started pacbuild for i586. It worked really > >well, because packages are very rarely modified from i686 to i586. There > >was no real need for a cvsup tree and whatnot. > > > I hear you! Cvsup it a overhead only, if you x86 guys had'nt set a password for eradonly anonymous > not even bypassing a password prompt would have been necessary. ;-) > Not to speak of the fact that Emz3 only runs on a platform where there is already a bootstrapped > Emz3 compiler, which I haven't found for PPC yet. > > If it were possible I'd like to see everyone move away from it and use plain CVS or Subversion at best. Well, cvsup is just sort of a seperate daemon for sharing cvs trees. I understand that cactus (I believe that's who it was) wrote some patches for abs to work with subversion. I wrote something similar for the old TUR... it's not hard technically, it's finding acceptance that's so difficult. > >I also designed cherry to do too much. I should probably make another one > >or two daemons in there. One, at least, to scan the repos and queue > >packages. That way cherry can just worry about managing all the remote > >builds. The other daemon would be for putting the packages back into the > >repos. The only reason I would develop this seperately is then we could > >use it for i686 as well. > >The way pacbuild was designed originally, it needed the > >single-PKGBUILD-for-all-architectures method. It depended on all PKGBUILDs > >working for all architectures and tried to build them for all architectures > >without those architecture developers even having looked at an update. > >This way architecture developers become more of a manager than an active > >maintainer. > > > I cannot agree more, all of the maintainers should always try to keep the PKGBUILDs exactly the same > wherevere possible. Debian does it by the lowest deminor I think, stripping features off the configure > until > it works everywhere. Archlinux users might not agree with that, so do I. So smaller if[ $CARCH ] > sections > are totally ok. > Unless some really obscure platforms such as ARM32, m68K or even SH-* are planned we won't have a > problem. And even then, we could still have like a Archembedded or whatever. Hehehe, Archembedded. > >The problem here is that each architecture's version of a package (if the > >newer version isn't in the ppc repo, for example) isn't accessible in abs. > >To do the abs thing for each individual architecture, we need to tag them > >at the very least (have seperate repos at the most). Tagging them pretty > >much means they'd need someone looking at them. It's possible that the > >build script could tag all the ones that were verified, but developers > >would still need to fix problems that showed up and tag those. > > > Do you mean for instance something like this? > > 2 kinds of tags in CVS for the latest stable: > CURRENT-I686 > CURRENT-PPC Yeah, basically. > Then I do not see a problem with the fact that a new PKGBUILD might not yet be available for all > platforms > as soon as one platform's maintainer updated it. I think reviewing and kind of signing the package for > other > architectures is a must, not a problem in itself. > > If a user want's stuff that has not necessarily been tested or even been uploaded to be tested, he > checks out the > HEAD or whatever which always works for getting *all* the latest PKGBULDs, unlike TESTING-I686 on ppc > f.e. By doing this though, we lose one of the major benefits of having an autobuilder (Debian's autobuilder works like this): package releases for multiple architectures. When a Debian maintainer releases a new i686 package, their buildd detects that it's not available for the other architectures and queues it up to be built. The benefit is that building for the other architectures happens all the time, so there's less catchup that needs doing. If builds have to be verified first, they're already being built on the developer's boxes for that architecture. Ignoring the benefits of a clean build system (even though they are nice benefits...), why not use the developer's package instead of the autobuilt one? Thing about getting the HEAD specifically, you're never sure if it's for current or for testing. At least the way we're using it. Ok, what about this... there are a lot of technologies we'd benefit from using (something other than cvsup, different PKGBUILD tree layout, etc). What if we modelled something off the current arch practices, but substituted our own technologies? Say we wanted to use svn and lay the repo out differently, we distribute a patched abs that can handle the newer layout and different technology. As long as someone keeps the i686 PKGBUILDs in sync with the ones in the official cvs tree on a regular basis (should be scriptable), we'd get all the benefits of the new technology and we might even be able to convince the other developers to move over. Doing something like this would be more work on the outset, but would probably be very helpful in the long run (especially if the newer system was adopted ;) ). Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From eliott at cactuswax.net Wed Aug 31 18:26:56 2005 From: eliott at cactuswax.net (eliott) Date: Wed, 31 Aug 2005 15:26:56 -0700 (PDT) Subject: [arch-ports] pacbuild status and design In-Reply-To: <20050831221750.GA19577@mercury.xentac.net> References: <20050824204536.GA17642@mercury.xentac.net> <43162800.1090100@disipos.de> <20050831221750.GA19577@mercury.xentac.net> Message-ID: <36253.69.88.121.42.1125527216.squirrel@hosting2.planetargon.com> Jason Chu said: > Well, cvsup is just sort of a seperate daemon for sharing cvs trees. I > understand that cactus (I believe that's who it was) wrote some patches... Aye. it was me. I used svn update, while you were using wget. Your solution was probably more scalable, quicker, and less dependent upon subversion being on the client. Mine had the benefit of being damn simple. ;) > it's not hard technically, it's finding acceptance that's so difficult. yeah.. /me nods head "bobble head" style