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

[arch-dev-public] pending devtools issues
by Andreas Radke 04 Oct '07

04 Oct '07

Whenever I had tried out the devtools I had these issues: - I always set a certain pkgdest in makepkg.conf. So (old and) new packages are stored centralized. This breaks checkpkg and {foo-repo}pkg as they expect old and new pkg in the current directory. Correct me if I missed any option to solve that. - As I only have poor bandwidth and like to keep working while down-/uploading I want to have a bandwidth-limit option for filetransfer. At least for uploading. Afaik the scripts use scp. Man scp tells me there's -l limit - Limits the used bandwidth, specified in Kbit/s. Yes I like the idea to "force" all devs using devtools to reduce unneeded mistakes and issues. Forcing us with an integrated namcap run is something I would like to see. But we should still be able to do everything by hand. There always might appear some reason why the tools get broken and we need to fix something manually. Andy

7 31

[arch-dev-public] critical: fakeroot broken again, breaks makepkg
by Thomas Bächler 04 Oct '07

04 Oct '07

Oops, this should have gone to the public list directly, so I'll repost it here: I saw this problem a while ago already, but didn't really investigate it. When building a package, you would often end up with non-world-readable /usr/man/manX directories. This happens whenever this code in makepkg is executed: # move /usr/share/man files to /usr/man if [ -d $startdir/pkg/usr/share/man ]; then cd "$startdir" mkdir -p pkg/usr/man cp -a pkg/usr/share/man/* pkg/usr/man/ rm -rf pkg/usr/share/man fi This can be reproduced easily: [09:29:39][thomas@artin shm]$ fakeroot bash-3.2# mkdir -p foo/ab bar bash-3.2# ls -al foo/ bar/ bar/: total 0 drwxr-xr-x 2 root root 40 Jul 12 09:29 . drwxrwxrwt 4 root root 100 Jul 12 09:29 .. foo/: total 0 drwxr-xr-x 3 root root 60 Jul 12 09:29 . drwxrwxrwt 4 root root 100 Jul 12 09:29 .. drwxr-xr-x 2 root root 40 Jul 12 09:29 ab bash-3.2# cp -a foo/* bar/ bash-3.2# ls -al foo/ bar/ bar/: total 0 drwxr-xr-x 3 root root 60 Jul 12 09:29 . drwxrwxrwt 4 root root 100 Jul 12 09:29 .. drwx------ 2 root root 40 Jul 12 09:29 ab foo/: total 0 drwxr-xr-x 3 root root 60 Jul 12 09:29 . drwxrwxrwt 4 root root 100 Jul 12 09:29 .. drwxr-xr-x 2 root root 40 Jul 12 09:29 ab bash-3.2# I can't find out exactly what's causing this, so if anyone has an idea, feel free to share it. This should definitely be fixed quickly, as it prevents me from updating several packages.

4 6

[arch-dev-public] A big baad idea: ArchCon 2009
by Tom K 03 Oct '07

03 Oct '07

High concept: "What do you think would happen if as many Arch people as possible gathered in the same place at the same time?" Audience breakdown: All members of the dev team (well, duh) TU-selected members of the TU team Other Archers fanatical enough to attend People off the street Program: Hacking Talking Bonding (aww....) Drinking (woohoo!) etc TBC: Continent Country City Venue Menu Activities Restrooms Size of Mugs Imperial or Metric Yadda Yadda etc Teaser: one particular member of the dev team will volunteer to organise the whole shebang! I'm posting this here, because if the devs aren't interested, well... All the best Tom.

13 17

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] 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