- Arch-dev-public - lists.archlinux.org

Re: [arch-dev-public] [arch-commits] CVS update of extra/devel/slang (PKGBUILD)
by Dan McGee 01 Oct '07

01 Oct '07

I think the options=(!makeflags) would work for this... -Dan On 10/1/07, andyrtr(a)archlinux.org <andyrtr(a)archlinux.org> wrote: > Date: Monday, October 1, 2007 @ 14:51:02 > Author: andyrtr > Path: /home/cvs-extra/extra/devel/slang > > Modified: PKGBUILD (1.15 -> 1.16) > > fixed smp build > > > ----------+ > PKGBUILD | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > > Index: extra/devel/slang/PKGBUILD > diff -u extra/devel/slang/PKGBUILD:1.15 extra/devel/slang/PKGBUILD:1.16 > --- extra/devel/slang/PKGBUILD:1.15 Sat Sep 29 04:26:02 2007 > +++ extra/devel/slang/PKGBUILD Mon Oct 1 14:51:02 2007 > @@ -1,4 +1,4 @@ > -# $Id: PKGBUILD,v 1.15 2007/09/29 08:26:02 juergen Exp $ > +# $Id: PKGBUILD,v 1.16 2007/10/01 18:51:02 andyrtr Exp $ > # Contributor: Tom Newsom <Jeepster(a)gmx.co.uk> > # Maintainer: Juergen Hoetzel <juergen(a)archlinux.org> > > @@ -17,5 +17,5 @@ > # patch -p1 -i $startdir/src/$pkgname-2.0.6-makefile.patch || return 1 > ./configure --prefix=/usr > make || return 1 > - make install DESTDIR=$startdir/pkg/ > + make -j1 install DESTDIR=$startdir/pkg/ > } > > _______________________________________________ > arch-commits mailing list > arch-commits(a)archlinux.org > http://archlinux.org/mailman/listinfo/arch-commits >

2 1

Re: [arch-dev-public] Arch mirrors
by eliott 01 Oct '07

01 Oct '07

There is a FS ticket for part of this thread: http://bugs.archlinux.org/task/7006 I support changing the link on the downloads page to reference the wiki. This would, however, allow end users to modify the mirror page thus changing the mirror list in a way that may be seen as more 'official'. We could perhaps lock the mirrors page, but that semi-defeats the purpose of the change control suggestion. Any thoughts or feedback of a high caliber?

5 10

[arch-dev-public] Fwd: Arch mirrors (discuss)
by Roman Kyrylych 01 Oct '07

01 Oct '07

---------- Forwarded message ---------- From: Vinay Shastry <vinayshastry(a)gmail.com> Date: 1 Жов 2007 09:03 Subject: Fwd: [arch-dev-public] Arch mirrors (discuss) To: roman.kyrylych(a)gmail.com ehm... i forgot that the ml is not open for the general public to jump in :P ---------- Forwarded message ---------- From: Vinay Shastry <vinayshastry(a)gmail.com> Date: Oct 1, 2007 11:29 AM Subject: Re: [arch-dev-public] Arch mirrors (discuss) To: Public mailing list for ArchLinux development <arch-dev-public(a)archlinux.org> > Well, I think official mirror list can be kept on our download page > (almost all official mirrors have iso dirs anyway, those who don't - > deserve removal :-P). > It can be a table with the following row format: > > mirror | FTP | HTTP | rsync | country > ------------------------------------------------ > mirror.domain.org | + | + | + | Country1 > mir1.domain2.com | + | - | - | Country2 > > where mirror name should be a URL to the FTP (or HTTP if FTP does not exist) > and those "+" (or some nice checkmark images) should be URLs of > respective protocol. > > And put a link to 'Unofficial mirrors' section on wiki page. > > This way official mirrorlist will be clean and could be changed only by devs. Won't it be nice if the mirror list is organised according to Continent/Country.. perhaps something like http://en.opensuse.org/Mirrors_Released_Version ? -- Vinay S Shastry http://vinayshastry.blogspot.com/ -- Roman Kyrylych (Роман Кирилич)

1 0

[arch-dev-public] Arch mirrors (discuss)
by eliott 29 Sep '07

29 Sep '07

Ok. Starting a new thread for some discussion. Roman did great work generating an up to date mirror list. I changed the "get arch" page to a layout more conducive to "new users". In doing so, I realized that the focus of that page is for downloading ISOs (eg. Getting arch). I think I am going to change the layout a bit, and link directly to the /iso/ folder on the mirrors listed. I am going to incorporate the changes roman made, regarding mirrors, and only include those that offer isos *in that page*. This leads me to an interesting suggestion. Should be create a page with an more official list of mirrors, and list only teir1 mirrrors (those that we allow rysnc from on gerolde)? We can list the top level http, ftp, and rsync locations for those servers (if they have them). We can then link to the Wiki for "teir2" mirrors. Those that we do not allow direct sync from gerolde, but are viable alternatives nonetheless. Maybe those servers sync from one of the teir1 servers. This should allow us to keep a handle on the teir1 servers, and whom we allow to sync against gerolde, as well as provide a mechanism for the community to manage the list of teir{n} servers more effectively. Not sure how the tie-in to pacman's mirror list is going to handle this, insofar as teir1..n mirrors. Thoughts?

3 5

[arch-dev-public] Additional Package ISOs
by Aaron Griffin 29 Sep '07

29 Sep '07

Continuing a discussion from earlier, on into a fresh thread. We need a plan for the additional ISOs. To reiterate what's going on here: There are a handful of users who would like to have a giant iso of packages to aid in installing on boxes with slower networks (for instance, they could download and burn the ISOs from school). So, I've seen a few ideas, and Thomas seems to have the best grasp on what is slated. Here's what I'd like to see: * A small script which constructs a repo from a list of packages, then runs mkisofs on it. This would allow users to very easily create a CD or DVD full of packages THEY want. * One or two officially built ISOs (CD? DVD?) using the above tool, with some nice utilities and tools, etc. * Perhaps a combination of the two, and a bootable "OMGHUGE" DVD. Opinions, what do you guys think? I haven't really heard much comment on this topic so far. Thanks in advance, Aaron

6 23

[arch-dev-public] Architecture Independent Packages
by Aaron Griffin 28 Sep '07

28 Sep '07

This was brought up in a previous thread started by Damir, regarding committing a package to more than one repo at a time. I think it'd be more beneficial for us to split of architecture independent packages, just to eliminate redundancy. Python modules, scripts, etc they'd all fit here. Does anyone have an opinion on the matter? I think adding a arch=(none) or arch=(all) setup would be a good idea, BUT there might be a lot of other things that need to be changed. For instance, pacman doesn't handle this case right now, we'd need code in there, etc Please discuss, I haven't put much thought into it. Thanks, Aaron

9 19

[arch-dev-public] Upcoming Rebuilds
by Andreas Radke 28 Sep '07

28 Sep '07

pending updates that force us to another major rebuild session due to a so bump are: heimdal - 15-20 (no old todo list so far) db - 30-40 rebuilds (old todo list is broken after repo shuffle in django) i have a major cups and ghostscript update pending. new cups depends on heimdal. other updates that _might_ have so bumps or forces us to rebuilds: - icu (means OOo) - libgphoto2 - flac a few other important updates are also pending: hplip, eclipse and some more. afaik Xorg and Gnome in testing shouldn't be a big problem. they shouldn't hold us back to start the db/heimdal bumps. we should just decide on which architecture we will go in front with the bumps. i vote for x86_64. 64bit devs can also do some i686 rebuilds if needed. if we find useless packages while rebuilding we should do a minor pkg cleanup. anything that holds us back? Andy

4 5

[arch-dev-public] fglrx-utils preferred over libgl-dri
by Alexander Baldeck 27 Sep '07

27 Sep '07

Hey all, I was just about to upgrade oxine and it used to only depend on xine-lib. xine-lib pulls a great deal of xorg stuff but then one strange thing happened. pacman felt like fglrx-utils would be the right package to pull to fulfill the requirement of 'libgl' on the system. Now I would like to not have that, what would happen if I were to go and change pkgname of libgl-dri to just libgl since Jan dropped libgl-mesa long ago? Pacman should prefer the real pkgname over provides, right? Cheers, -J

2 1

[arch-dev-public] Test Isos 2007.09-0.2 with core repository and 64MB RAM image
by Tobias Powalowski 27 Sep '07

27 Sep '07

Hi here the changelog: i changed everything to fit to new core repository, 2 isos left ftp iso and core iso, the rest was setup/archboot changes to achieve this. - I cleaned up our documentation, to fit to those stuff please read it and tell me what is missing or wrong. GENERAL: - disabled arch_addons hook by default, it is triggered by arch-addons boot parameter - Ram usage increased to 160MB (FTP-ISO,CORE-ISO arch boot image) - Ram usage 64 MB (CORE-ISO lowmem boot image) FIXES: - fixed the nasty /dev mount bug - fixed the /dev/ttyS0 errors if no serial port is installed in the system - fixed repositories in install environment to fit to both architectures - fixed km to not show broken chars after exit NEW STUFF: - added pptpclient to install environment - added sdparm to install environment - added all free wireless drivers to install environment - added intel wireless drivers to install environment which will be activated by intel-wireless boot parameter - added hosts.deny and hosts.allow to config dialog - added licenses to install environment - added new lowmem boot image to core iso stripped everything out that is not necessary for installation TODO: - update archboot on cvs - update documentation for lowmem image you can download i686 Isos here: http://www.archlinux.org/~tpowa/rc-iso/686 you can download x86_64 Isos here: http://www.archlinux.org/~tpowa/rc-iso/x86_64 have fun in testing and report issues immediatly, thanks greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

1 0

[arch-dev-public] testing status announcements table
by Damir Perisa 25 Sep '07

25 Sep '07

hi devs, i just feel like bringing up an old idea about testing... we announce the happenings, which happen in testing in the news, in the mailinglists and maybe elsewhere (forums?). however, sometimes we do not know how long things need to reside there... and the overview is even sometimes for a dev lost, what is happening in testing. what i suggest is to maintain a small table... like the todo-table, but that is public. it should have the following contents: * name of task / name of single pkg * brief description about task / brief description on reason why pkg is in testing * possible effects * link to task in bugs.archlinux.org * date of entry in testing * condition of finishing testing (moving thigs out of testing) ** eventually deadline of testing / date for finishing the testing (if no reports come in) * responsible dev this would look like the following at the moment: * X.org 1.4.0 release * major upstream change in packages * impact on various xorg pkgs, breaking of drivers (wacom, ...), incompatibilities, instabilities (nvidia, ati), new drivers (video-intel) * 1234 (i do not remember the number, but there is one; i remember asking for one and that one was made *smile*) * 2007-08-xx * reported issues solved * Andreas * R 2.5.1-2 paths cleanup * path cleanup in the extra/science/r pkgs * possible impact on self-made CRAN pkgs * no bug associated (yet) * 2007-09-24 * 2007-10-07 - no issues * Damir ... this would help keeping an overview about the status of things in testing... we can even announce in advance a planned testing event. thoughts? - D -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><

2 3