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

[arch-dev-public] fixing the dependency cycle in Core, part 1: coreutils
by Roman Kyrylych 26 Nov '07

26 Nov '07

Hi! I've attached a patch that removes unneeded dependency on coreutils from some packages. It also modifies install.proto to not endorse bad practice of /bin/true usage. Please review and signoff. -- Roman Kyrylych (Роман Кирилич)

5 7

[arch-dev-public] Use of force=y
by Jürgen Hötzel 26 Nov '07

26 Nov '07

Hi, openchrome released a stable version recently (0.2.9): http://www.openchrome.org/releases/ The current package in extra is based on a svn snapshot: openchrome 20070903-2 I need to use force=y for an update. How long do week keep force=y in packages: If pacman uses an outdated mirror, this will lead to downgrade. I'm also thinking about adding the radeonhd to extra but i prefer a naming scheme like radeonhd-git-2007xxxx until a official packages is released and then use "replaces". Any objections? Jürgen

4 5

[arch-dev-public] 2.6.23.8-2 with cfs scheduler backport from ingo molnar?
by Tobias Powalowski 26 Nov '07

26 Nov '07

Hi http://www.archlinux.org/~tpowa/2.6.23/ includes a new .8 kernel with ingo molnars backport of the cfs scheduler from .24 kernel and gregs rc1 stable patch for .9 kernel it adresses these bugs: http://bugs.archlinux.org/task/8721 http://bugs.archlinux.org/task/8745 this cfs patch is something quite big and i don't know if you all want to go this way to fix this issues. It could have the potential to break things, but also the speed improvements that will appear in .24 kernel and it seems to fix the wpa issues we have. Also for my system it runs stable. i would like to bring it to testing tomrrow to get finally the last issues fixed for a new installation ISO. any comments on it? thanks greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

2 2

[arch-dev-public] [signoff] less 416-1
by Andreas Radke 25 Nov '07

25 Nov '07

in testing for both architectures Andy

3 2

[arch-dev-public] Adding python-qscintilla to extra
by Eric Belanger 23 Nov '07

23 Nov '07

Hi, In the next few days, I'll add python-qscintilla to extra. It is currently in community as python-qscintilla2. It is a required dependency for the latest eric version (the qt4 one). Eric -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

2 1

[arch-dev-public] [Warning] Don't build openGL apps against fglrx-utils' libGL.so
by Thomas Bächler 22 Nov '07

22 Nov '07

tpowa and I found this when we were trying to fix a wine bug: When libgl or nvidia-utils are installed, applications are linked against "libGL.so.1": $ readelf -d /usr/lib/libGL.so|grep SONAME 0x000000000000000e (SONAME) Library soname: [libGL.so.1] However, if you try this command with fglrx-utils, it will return 'libGL.so.1.2' as SONAME. The binaries this produces are compatible with libgl and fglrx-utils, but not with nvidia-utils, as the file 'libGL.so.1.2' does not exist there (while libGL.so.1 does). Thus, to ensure compatibility with nvidia users, only build OpenGL applications in environments where libgl or nvidia-utils is installed.

4 7

[arch-dev-public] Status Report 2007-11-20
by Aaron Griffin 22 Nov '07

22 Nov '07

ArchLinux Status Report, 2007-11-20 =================================== Aaron Griffin (Reviewed by Eliott) Another couple of weeks, another status report. Things have been calm around here, oddly enough. A lot of us are getting ready for the holidays, or exams, or both. Me? I'm just really busy with work these days. I want to let everyone know that you are always welcome to contact me over jabber or email for any questions or concerns. I seem to be getting a few emails recently with lines such as "sorry for emailing you" - I like email. Emails are fun. So don't be afraid ;) == Newsworthy Items == * New Logo Competition Voting All the submissions for the Logo Competition are in, and the developers are currently voting. Hold on to your seats, the final verdict will be incoming soon. http://bbs.archlinux.org/viewtopic.php?pid=298688 * Simo takes over AUR development Paul has taken a step back from being the lead on the AUR project, and Simo is taking his place. In Paul's own words: Thanks to all of you for making the AUR come alive over the last few years! It's been exciting to watch our creation really brought to life by this vibrant community. I'm excited about beginning a new chapter with Simo at the helm! * Bug Tracker open for [community] packages In the past, we've not allowed bug tracker items for community packages because it was difficult to manage the bugs. Now, we've created a section in our bug tracker for community package issues. http://archlinux.org/news/364/ == Completed Tasks == * Xorg 7.3 Brouhaha This update seems to have caused quite a ruckus among the users. For some people it worked fine, but others ended up with broken systems. Sadly, this is somewhat expected on large upgrades like this. I remember a day when we had breakages like this all the time. Arch has been running so smoothly recently that most people forget that software actually does break. http://archlinux.org/news/363/ * Package Cleanup An extraordinary amount of thanks goes to Eric here. This is a thankless job, but he has done the legwork and cleaned up a large amount of packages from extra. This makes everyone's job easier, and our repos cleaner. There's still more to come, so stay tuned: http://archlinux.org/pipermail/arch-dev-public/2007-November/003154.html * [core] repo rebuild Daniel did a huge amount of work here, rebuilding all of our core packages for the new gcc/glibc toolchain. This is a common rebuild that a lot of distros do, yet we typically do not do it that often. So hats-off to Daniel for doing the rebuild and package move, and special thanks to Tobias (tpowa), Andreas, Roman, and anyone else I missed for doing the cleanup work that enabled Daniel to do this. * New netcfg scripts in [testing] James has spent some time revamping our network profile support, and generally cleaning up our network scripts. His changes have been moved to testing now. Please try them out if you get a chance. http://archlinux.org/news/362/ * QT4 Move to [testing] Pierre and others have begun the move to Qt 4 based packages. This includes backwards compatible support for Qt 3 (in the form of a package named qt3). These packages should all be moved to testing now. Please try them out and report any problems you come across. http://archlinux.org/pipermail/arch-dev-public/2007-November/003242.html. * GPL License naming Just so we don't bollocks this up, the following naming scheme will be using for GPL licenses in PKGBUILDs: GPL means GPL2 or later GPL2 means GPL2 GPL3 means GPL3 or later Note: We have no GPL1 packages, and I doubt anyone could actually find one. == Pending Tasks, Short Term == * Getting rid of /opt Revisiting this from last time. It looks like we have a lot of packages which can move out of /opt when we have the time. The first step is to create a todolist in the dashboard for all packages which currently install to /opt. Would anyone be willing to create this list? * License Updates We still have a large TODO list sitting here, of packages that have broken licenses. Please take a look at these while packaging, to ensure we have licenses setup properly. http://archlinux.org/todo/43/ * ABS Redux This is actually a multi-part task here. The first part, involves replacing the cvs dependence in ABS with rsync. http://archlinux.org/pipermail/arch-dev-public/2007-November/003224.html This change will allow abs to be independent of the SCM backend we use, and perhaps more efficient in the long run. I think Dan and Eliott have done some work here in this regard. Step 2 is actually breaking abs out from the pacman package, as it's very ArchLinux specific, and pacman/makepkg are not. This can, and should, most likely be done around the same time as the pacman 3.1 release (see below). * The dividing line: extra and community Ah, waning discussion is always fun. I've tried to revitalize this a few times, but it seems discussion feel short. So here's a fun little ultimatum for ya: Since no one seems to care about this topic anymore, if we don't get a vote, or at least continued discussion here, I'm going to have to make an "executive decision". That decision will be as follows: * Packages in [extra] define us as a distro and should not include packages for personal use. If something is personal and/or only used by small amounts of people, it should go to community. Not only does this help us with our vision, it also helps out our mirrors (not all mirrors mirror the community repo). * People should inform everyone if they're putting a new package into extra, just in case someone has an issue with it, to prevent silly bloat from too many personal packages. If someone has a problem with a package going into extra, a simple vote should suffice (no need to discuss it to death) The other reigning idea seems to be Damir's idea of the mantle/crust repos. That is, the same idea as above, except there is another repo in between extra and community that serves as the developers' dumping grounds for these packages. So, take a look at your options, and decide what feels best to you - I'd like to close this task out soon, as there's no real work here - only process. * Unified chroot build tools The chroot tools I've put in devtools have gotten little response. Jason has made some changes, and Roman has provided some patches, if I remember correctly. I'd like to get more input here, suggestions of things like using linux32 and dchroot are great (both suggested by Thomas). So feel free to bring it up. * Getting rid of CVS Yep, this is moving up the chain from long-term to short-term. Before the next status report (2 weeks from now) I want to at least begin this task. In order to do this, we need to first make a decision on where we want to go. The root of the decision here is how we represent a given package being in multiple repos at one time. * Jason has provided us with an svn solution, where sub-directories control the location of the package (i.e. package-name/repos/extra/PKGBUILD will place the package into extra) * Dan has provided us with a git solution that uses named branches to control the location (i.e. a branch named "testing" has changes to PKGBUILDs present only in the testing repo) Both of the solutions above solve the issue. The real question is - what tool do YOU want to use? == Pending Tasks, Long Term == * Perl policy implementation Looks like some perl progress has been made. As said last time, there's not a HUGE amount of perl hubbub on Arch, so this isn't critical. It's important, sure, so lets keep this one in mind. http://bugs.archlinux.org/task/8374 * Pacman 3.1 Release Dan has been doing some amazing work closing out a lot of bugs for this release. In addition, he has a public repository which contains recent builds of pacman from git, that should help in testing in debugging. If you feel like helping out with testing, please use Dan's repo to install 'pacman-git'. More info here: http://archlinux.org/pipermail/pacman-dev/2007-November/009825.html Pending bugs for the release are listed here: http://bugs.archlinux.org/task/8109 * Official pacbuild usage Another pipe-dreamy project. I'm not even sure of the state here anymore - Simo, Jason, any news? * Modernize our Dashboard Eliott has been pushing out some very nice changes to our web interface, so thanks goes out to him. For some of this stuff. I'd, of course, love to see more web-dev type people working on this. Take a look at our gitweb: http://projects.archlinux.org/git/?p=archweb.git;a=summary At some point, I want to add README text with information on how to run a local instance. * Architecture Independent Repos As stated last time, Roman sent us a patch for pacman 3.1 to incorporate the no-arch packages. This means that when the 3.1 release comes out, we should be ready to go here. So here's your deadline: let's try and get support into our DB scripts before the pacman 3.1 release. Who's interested? http://bugs.archlinux.org/task/8555 This one is a rather small change, is anyone interested in doing this? Thomas? * ArchCon 2009: Big Baaad Idea /me winks http://archlinux.org/pipermail/arch-dev-public/2007-September/001614.html

2 1

[arch-dev-public] [signoff] man-pages 2.68-1
by Andreas Radke 22 Nov '07

22 Nov '07

in testing for both architectures Andy

3 2

[arch-dev-public] [signoff] moving wicd to extra
by Varun Acharya 21 Nov '07

21 Nov '07

Hi guys, I'd like to move wicd to extra now. After I fixed some errors in the PKGBUILD, I haven't received any more complaints, and I've successfully moved it to /usr from the default /opt. I asked for a signoff on this a while ago, but no one responded, and I assume its cause I forgot to add the "[signoff]" to the subject line. Specifically, I'd like to know how it fares with encrypted wireless networks. From what I've seen, this program seems to be one of the easiest ways to get onto wireless networks. Available for both architectures in testing. signoff please. Varun

4 8

[arch-dev-public] (Still) cannot connect to archlinux.org
by Thomas Bächler 21 Nov '07

21 Nov '07

As of yesterday, I (among others) am unable to connect to archlinux.org. A trace tells me that the problem is somewhere at cogent. This means I cannot do anything right now: [x86_64][09:18:30][root@artin ~]# tcptraceroute archlinux.org Selected device rwth, address 137.226.101.95, port 58868 for outgoing packets Tracing the path to archlinux.org (66.211.213.17) on TCP port 80 (http), 30 hops max 1 c3750-ww10-2.noc.RWTH-Aachen.DE (134.130.5.254) 41.334 ms 40.643 ms 41.082 ms 2 c6k-ww10.noc.RWTH-Aachen.DE (137.226.138.1) 41.656 ms 41.680 ms 42.513 ms 3 c6k-rwth.noc.RWTH-Aachen.DE (137.226.139.49) 41.965 ms 43.641 ms 51.844 ms 4 pfi-stone-1.noc.RWTH-Aachen.DE (134.130.9.243) 41.342 ms 42.467 ms 41.068 ms 5 n6k-xwin.noc.RWTH-Aachen.DE (134.130.9.225) 41.551 ms 46.496 ms 50.785 ms 6 xr-aac1-te1-3.x-win.dfn.de (188.1.43.109) 41.491 ms 48.075 ms 46.804 ms 7 zr-fra1-te0-0-0-3.x-win.dfn.de (80.81.192.222) 59.875 ms 45.793 ms 45.654 ms 8 decix.mpd01.fra03.atlas.cogentco.com (80.81.192.63) 108.447 ms 199.492 ms 222.729 ms 9 t7-2.mpd01.par02.atlas.cogentco.com (130.117.0.102) 128.717 ms 198.280 ms 215.676 ms 10 t7-1.mpd02.par01.atlas.cogentco.com (130.117.1.234) 58.085 ms 58.368 ms 60.158 ms 11 g0-0-0.core01.par01.atlas.cogentco.com (130.117.2.49) 69.687 ms 69.867 ms 69.860 ms 12 p14-0.core02.dca01.atlas.cogentco.com (66.28.4.206) 152.241 ms 159.736 ms 149.169 ms 13 t3-1.mpd01.dca01.atlas.cogentco.com (154.54.5.50) 150.661 ms 181.276 ms 157.748 ms 14 t8-3.mpd01.dca02.atlas.cogentco.com (154.54.6.198) 152.689 ms 159.701 ms 152.143 ms 15 t1-4.mpd01.iad01.atlas.cogentco.com (154.54.7.162) 156.777 ms 156.578 ms 161.400 ms 16 g2-0-0-3491.core01.iad01.atlas.cogentco.com (154.54.5.33) 137.817 ms 152.898 ms 150.242 ms 17 * * *

4 5