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

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

[arch-dev-public] Status Report 24-09-2007
by Aaron Griffin 25 Sep '07

25 Sep '07

Hey all, One of the things I plan on doing, for myself and for all of us, is sending out a little "what's going on in devland" status report ever Monday. So here's the very first one! Please, if you can, split off any discussion to other threads, and only use this one for missed milestones that I may have forgotten. So without further ado: ----------------- ArchLinux Status Report, 24-09-2007 == Completed Tasks == * PHP Modularization Pierre completed a rehash of our php package, making it smaller, more agile, and modular. The full details can be found in another thread on the private list. Pierre, would you mind pushing the details somewhere so the public can see? * Move to [core] Repo I want to send a special "Thanks" out to everyone who participated in this. It was a long time coming, and it definitely gives us more of an idea of what's going on overall. So thanks guys, you all deserve it! * ISO Naming Scheme decision We will be using YYYY.MM-REL for ISO versioning, where REL is the release number of this ISO. For internal and testing ISOs, we will use the point release scheme popularized by the x86_64 architecture. For instance, 2007.12-1.5 is the 5th internal/testing release. To prevent complication, we will start with release 0 for these testing releases, so 0.1 should be the first internal release * GNOME 2.20 in [testing] If you are a GNOME user please take the time to test this, and let Jan know if there are any issues - please put them in the bug tracker. * X.org 7.3 in [testing] This release will probably need a lot of testing, especially with nvidia and fglrx drivers. Please test if you can. == Pending Tasks, Short Term == * New Round of Package Cleanup Eric will be leading the charge here. This will mostly be internal to the developers as we will get rid of packages that are not compatible between architectures and packages which no longer build or are just broken. * DVD and Additional Package ISOs We need to decide on what exactly we're shipping on these "extra" iso images. Thomas seems to have the idea mostly in hand, so I'd like him to lead the discussion here (if that's ok with you) * Unified chroot build tools I am in the process of creating a script to aid us all in building packages in a clean chroot. We should all be doing this whenever possible. I told you all I'd get this out by this weekend, but I failed. Sorry. I will spend tonight getting this prepped. Again, I apologize. * Use vendor_perl for pacman perl packages This is an easy bug to fix, it's just tedious. http://bugs.archlinux.org/task/8082 If someone has the time, I'd like to see this accomplished sometime this week. Any volunteers? * Move all Arch related projects to gerolde This is just a reminder - mainly to myself and Jason, and maybe Paul. We'd like to get all Arch oriented projects in a common location so we can all work on them and users can peek at things to see if they could contribute at all. http://bugs.archlinux.org/task/7789 * Next ISO Release Date I'd like to remain in the loop here. Could anyone project the next kernel release date and how long the ISO will take from the time of release? I'd like to start with (see above) a -0.1 release for internal and testing stuff, and give that a few days, then release a -1 version. * Upcoming Rebuilds Andy mentioned some incoming rebuilds for some libs and things like db. Is there any word on the schedule for these releases? Andy, could you fill us in? * DB Script Rewrite Our DB scripts are kinda messy and are in a serious need of a rewrite. Thomas and I have planned to sit down and fix these things, but if anyone else is interested, I'd like to start planning a "sprint", if you will, shortly. * Orphan Packages This is another one Andy brought up. We have A LOT of orphan packages. We need someone to evaluate all of these orphans, to see if we should 1) still support them or move them "down" to community/unsupported 2) get someone to maintain them. Seeing as Andy is concerned with this, could you take the reins here? Collaborating with Eric on the package cleanup is probably a good thing too. == Pending Tasks, Long Term == * Pacman 3.1 Release Dan and I are going to be working towards a 3.1 pacman release. Please attach bugs you feel are critical to this here: http://bugs.archlinux.org/task/8109 Dan and I will sort it out. * Official pacbuild usage This is Jason's boat. I'd like to get him some help here. The more hands we can get in pacbuild, the faster we can start using it. * 'Continuous Integration' setup / machine This is a pipedream of mine. I'd like to setup a CI server somewhere. For those unfamiliar with the term, what this means is that the server will, periodically, check out our PKGBUILDs and try to build ever single package. Clean chroots don't matter, what we're checking is whether it will build as the instructions say. I guess a pacbuild instance COULD be used here, but this should be a simple bash script. If anyone wants to do something fun, feel free to jump on this one, but otherwise it's not important. * Multiple Maintainers on the Dashboard Yeah yeah this has been around for a while. We need to hack at our django code, so we can have multiple maintainers per package. Right now Eliott and Simo are the only ones with their hands in this code. If anyone else has the desire to jump into this code, please help out with this. It's something we are in dire need of. * Multiple Architectures on the Dashboard This is the same as above, BUT we need support for packages in all architectures, AND the ability to assign different maintainers to each architecture (not all of us can build for more than one arch). * ArchCon 2009: Big Baaad Idea So Tom K started this one, and, well, let's just throw it out there. http://archlinux.org/pipermail/arch-dev-public/2007-September/001614.html The tentative idea, which might be just a pipedream, is to get all the devs and users, or as many as possible, together for a big-ol' meet up. Let's see how this pans out. ----------- Well, there it goes. Monday status report for Arch devland. I threw a few questions in there, feel free to use this thread for that, but lets not pollute things with long-winded discussion - break those off and help make our mail clients happy. Thanks for all your hard work guys, Aaron

4 12