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

[arch-dev-public] Devices >2TB
by Paul Mattal 19 Jun '07

19 Jun '07

Anyone know if our standard kernels are capable of seeing/handling devices that are >2TB in size? I know you need 48-bit LBA to do this, but clearly 48-bit LBA is supported on the machines I'm using and in our kernel. The 2TB limit, as I understand it, comes from something *somewhere* being limited to a 32-bit address. Is it the kernel, or perhaps my SATA controller somehow? Or the sata_nv driver? The setup is that I'm hooking up a hardware-raid-enclosure external cabinet up via the ESATA port to the SATA controller built into the NVidia NForce 430 chipset on the motherboard. We can't see more than 2TB. Thanks for any helpful hints that people may know! - P

2 3

[arch-dev-public] DB rebuilds
by Dan McGee 19 Jun '07

19 Jun '07

I just threw up a pacman release (3.0.5) that fixes the following issue (http://bugs.archlinux.org/task/7338): conflicts lines from packages were not correctly added to a sync DB, causing issues when it comes to replacing stock packages with an -svn version, for example. Two things this likely affects: 1. If version 3.0.4 of pacman is installed on al.org, we should probably upgrade to 3.0.5 to get the fixed repo-add script (which is used by gensync, which may be used by our other scripts?) 2. The community DB should probably be rebuilt completely to ensure all the conflicts lines are now present, if this is a problem. Questions on this? Let me know if I wasn't clear about anything here. -Dan

2 2

[arch-dev-public] reverse staging idea
by Paul Mattal 18 Jun '07

18 Jun '07

Since I know there have been complaints about packages remaining in the ftp directories when new ones are uploaded, how about we modify the /arch/db-* update scripts run by the devs to move old versions of updated packages into ~/staging/<repo>/old? This makes the default behavior that they stick around but aren't cluttering the ftp directory. Just an idea I had that I didn't want us to lose. - P

6 9

[arch-dev-public] Away for a while, the hunt for funds
by Alexander Baldeck 18 Jun '07

18 Jun '07

Hey all, as you may have noticed I've stepped back from my enthusiasm a little on and after Linuxtag. This is primarily because I'm a little short on cash these days. Several things aren't going as well as I would like them to. Anyways, I'm on a job hunt atm which is probably taking most of my time during the next few days. On the other hand, if anyone has hints you're welcome to forward contacts. ;) I will work on the most cirtical packages as much as I can but if something takes to long, feel free to bump/fix/drop them. Cheers, Alex

4 3

[arch-dev-public] ABS cleanup
by Dan McGee 17 Jun '07

17 Jun '07

I used the following two home-grown scripts in the past few days to clean out ABS- it doesn't do it all, but it does get rid of directories without a PKGBUILD which was the original intent. It should help make an ABS checkout a bit faster as people aren't pulling needless files, although I'm sure there are still many checked in patches that are no longer needed. Arch 64 guys may want to give these a go after a few modifications and see what shows up. -Dan #!/bin/bash # # findstale - find directories in ABS tree without a PKGBUILD # cwd=$(pwd) for dir in $(find -type d); do if [[ "$dir" != *local* ]]; then cd "$cwd" if [ ! -f "$dir/PKGBUILD" ]; then nodir=1; cd "$dir" for node in $(ls); do [ -d "$node" ] && nodir=0 done if [ $nodir -eq 1 ]; then echo "$dir" #for file in $(ls); do # echo " $file" #done #echo fi fi fi done #!/bin/bash # # cleantags - clean up CVS tags in a given directory # cwd=$(pwd) for line in $(cat $1); do cd $cwd/$line ls /var/abs/extra/$line | xargs cvs tag -d CURRENT done

1 0

[arch-dev-public] community-64 broken
by Pierre Schmitz 16 Jun '07

16 Jun '07

Hi, the community.db.tar.gz file of community is still outdated resulting in a more or less broken repository. Packages are newer than the db entries. Is there anybody who can fix this? (or tell me how to do it?) Pierre

4 5

[arch-dev-public] java licensing issues
by Jan de Groot 15 Jun '07

15 Jun '07

Hi developers and users, As we all know, there's a distribution restriction on sun java. Today we asked at the Sun booth about possibilities for distributing java with our distribution. This solution would come down to entering a process which can take quite some months to get a final approvement. This means that until we would have such a solution, any Sun java we distribute is illegal. This would mean that jdk and jre can't have a place in our distribution at least for the upcoming few months if we choose to apply for a license. If we don't choose to apply for a license, it won't come back either. I would opt for not applying for a license, as it will license us to distribute it, but disallows all forks, livecds or even unofficial architectures of archlinux to do it. As we have GNU java right now supporting java 5.0, I would suggest approving GNU java as the prefered JDK and moving jdk/jre to unsupported. We are allowed to distribute build scripts, but users have to download the java binary themselves and build a package out of that. We leave it up to the user to have a non-free java, we won't force anything (java-environment and java-runtime will always stay runtime dependencies instead of depending on java-gcj-compat). At the final end of this mail I would like to have a word about the so called OpenJDK that was released as GPL: Though this Open JDK has been released as source, the sun provided binary JDK at this moment is anything but GPL. The problem with openjdk is that it needs jdk to get built (gcj is not enough). Also, the released sources are not complete because sun has licensing restrictions with 3rd parties themselves. This means we can't switch to Sun's free OpenJDK yet. At this moment Redhat has plans to stop further active development of gcj in their distribution and put their manpower in openjdk, to get it built with free tools and to extend the missing parts with pieces from other javas like GNU java. When this project is usable enough to replace java-gcj-compat as we have it now, it will enter the distribution and become the blessed Java SDK/runtime.

5 8

[arch-dev-public] away for a while
by Andreas Radke 12 Jun '07

12 Jun '07

do never inline skating without protectors - i broke my right hand yesterday. fuck :( i won't be able to do anything important for Arch for while :-/ Cya Andy

7 6

[arch-dev-public] ion3 in extra: licensing issues
by Jan de Groot 12 Jun '07

12 Jun '07

I see codemac upgraded ion3 in extra yesterday, which forces us to release any upgrade to the package to be available within 3 weeks after an official release. The is unacceptable, and looking at the discussion with the author of this piece of software on the tur-users list, we should remove it.

9 12

[arch-dev-public] Package Cleanup: Part II
by Aaron Griffin 11 Jun '07

11 Jun '07

http://wiki.archlinux.org/index.php/Package_Cleanup So the initial burst made a smallish dent, but there's still a lot more to do, which I'd like to get to this weekend. If anyone want to help out, that'd be great. In addition, please voice your opinions about a few things (I haven't heard a lot of developers talk about this, so I've left it alone: * Move desktop related stuff to extra? (possibly keep only xorg in current?) * Move wireless/network modules to current? (they're that important IMO) * Rename current to "core" ? * Anything else? Here's a handful of instructions for moving things, just to be complete. == Move to unsupported == cd repo/category/pkgname tar czf pkgname.tar.gz * /upload to the AUR/ cvs tag -d CURRENT cvs tag -d CURRENT-64 (possibly testing as well if it's there) cvs rm -f * cvs commit == Move from current to extra == cp -r current/category/pkgname extra/category/pkgname rm -rf extra/category/pkgname/CVS cd current/category/pkgname cvs tag -d CURRENT cvs tag -d CURRENT-64 (possibly testing as well if it's there) cvs rm -f * cvs commit cd extra/category/ cvs add pkgname cd pkgname (use extrapkg or any other means to get it in the repo) Thanks, Aaron

7 23