July 2010 - Arch-general - lists.archlinux.org

[arch-general] [signoff] kernel26 2.6.34.1-1
by Tobias Powalowski 06 Jul '10

06 Jul '10

Latest kernel is in testing, please signoff for both arches. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

2 1

Re: [arch-general] [arch-dev-public] [signoff] autoconf-2.66-1
by Ng Oon-Ee 06 Jul '10

06 Jul '10

On Sat, 2010-07-03 at 20:11 +1000, Allan McRae wrote: > On 03/07/10 13:58, Allan McRae wrote: > > Upstream update. Mainly bug fixes for regressions introduced in the > > last couple of releases. > > > > Recalling the signoff thread... it appears this release has issues. > > Allan Just wanting to check, what's the 'correct' procedure in cases like this? Autoconf in [testing] is 2.66, 2.65 is the 'working' one (I've seen problems in using it in one package so far), do I add it to IgnorePkg? Is it supposed to be removed from [testing]? So far I'm manually downgrading after an -Syu which is almost certainly NOT the right procedure.... neither is reporting a bug since obviously Allan knows somethings up with this release.

2 1

[arch-general] [signoff] kernel26-lts 2.6.32.16-1
by Tobias Powalowski 05 Jul '10

05 Jul '10

Hi guys, bump to latest version. Please signoff both arches, greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

1 0

Re: [arch-general] [arch-dev-public] Python-3.x transition with python-2.7 update
by Damjan Georgievski 05 Jul '10

05 Jul '10

> Python-2.7 has been releases and will be the last 2.x official release of > python. So it is time to switch to python-3.x as our /usr/bin/python and > python-2.7 as our /usr/bin/python2. See > http://wiki.archlinux.org/index.php/DeveloperWiki:Python_Todo_List for all > the details about how to achieve this. What's the rationale for making Python 3.1 the "main" /usr/bin/python? A great deal of python modules still don't support 3.x, there's no WSGI standard for 3.x either so you can't make web apps (and hope to deploy them). Even less C modules are 3.x compatible, and then even less applications. And 2.7 is here to stay for a long time. I think it would be wiser to stay with 2.7 as the main python for now. And maybe switch after Python 3.3 comes out. By that time the 3.x series should have enough improvements to motivate people to port to 3.x -- damjan

3 2

[arch-general] [signoff] hdparm-9.29-1
by Tobias Powalowski 05 Jul '10

05 Jul '10

Hi guys, bump to latest version, added wiper.sh script. please signoff both arches greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

1 0

Re: [arch-general] [arch-dev-public] [PATCH 1/2] checkpkg: Use temporary working directory
by Evangelos Foutras 05 Jul '10

05 Jul '10

On 05/07/10 04:18, Eric Bélanger wrote: > Signed-off-by: Eric Bélanger<snowmaniscool(a)gmail.com> > --- > checkpkg | 8 ++++++++ > 1 files changed, 8 insertions(+), 0 deletions(-) > > diff --git a/checkpkg b/checkpkg > index 47fb672..7765d80 100755 > --- a/checkpkg > +++ b/checkpkg > @@ -27,6 +27,12 @@ if [ "$arch" == 'any' ]; then > CARCH='any' > fi > > +TEMPDIR=$(mktemp /tmp/checkpkg-script.XXXX) > +rm $TEMPDIR > +mkdir -p $TEMPDIR mktemp can be called with the -d switch and it will create a directory instead of a file. I believe that's the preferable way to go about it. > + > +cd $TEMPDIR > + > for _pkgname in ${pkgname[@]}; do > pkgfile=${_pkgname}-${pkgver}-${pkgrel}-${CARCH}${PKGEXT} > oldstylepkgfile=${_pkgname}-${pkgver}-${pkgrel}${PKGEXT} > @@ -90,3 +96,5 @@ for _pkgname in ${pkgname[@]}; do > echo "No filename differences for $_pkgname." > fi > done > + > +echo "Files saved to $TEMPDIR"

2 1

[arch-general] ftp.gigabit.nu / ftp.archlinux.se shutting down
by Rickard Eriksson 05 Jul '10

05 Jul '10

Cut from the forum where my co-admin first put this up, however it got closed with reason "trolling"... This mirror will shut down in the upcoming days. Few funny facts: * We never got contacted by anyone before we got added in the official mirror list. We just posted this thread and all of the sudden it appeared. No verification of whom we were and what our intension were. * ArchLinux is fundamentally unscalable in the package manager aspect. * ArchLinux puts the trust in the hands of every mirror owner and their security. ftp.archlinux.se is the prime example of a machine vulnerable to all sorts of things. This affect YOUR security. This is why it's being put down. If the ArchLinux authors would start signing packages this would not be a risk to you. * We posted a suggestion of this in 2006. http://bugs.archlinux.org/task/5331 -- This is 4 years of insecurity. * We recommend all of you to switch to a distribution caring about user security and atleast signs their packages. Most RPM and APT based distros does this (Ubuntu, Debian, RedHat, CentOS, SuSE, OpenSuSE, etc etc etc). Have fun. :-) Yours, Mikael & Rickard

5 5

[arch-general] Bashification of initscripts for moderate speedup
by Victor Lowther 03 Jul '10

03 Jul '10

I have spent some time over the last month or so rewriting the Arch initscripts in idiomatic bash -- since they rely on bash-specific features, trying to keep them fairly POSIX is rather a waste of time and a net performance loss -- using bash-style conditionals is about 30% faster when nothing needs to be touched on the filesystem and about 200% easier to read, and you can use bash regexps in place of most trivial uses of sed, grep, and awk when mangling parameters or variables -- the fewer short-lived processes we fork the better. You can browse changes I have made in the git repo @ http://git.fnordovax.org/arch-initscripts/log/?h=bashification and you can checkout my changes to play around with from git://fnordovax.org/~victor/arch-initscripts There is a gigantic whitespace fixup patch at the end, all it does is fix all the whitespace errors I introduced while hacking and reformat everything to a consistent indentation style (emacs shell-script mode, if you are interested). I have tested these changes on a VM and on my local laptop. I inlcuded a PKGBUILD that will build an initscripts-git package, but be sure to backup and restore your rc.*local, inittab, and rc.conf files because they will get nuked the first time you install it. Questions, comments, flames, etc. welcome. I can also spam the list with patches if y'all really want. -- Victor Lowther LPIC2 UCP RHCE

12 31

[arch-general] Last Updates w/kernel 2.6.33.4-1 -> 2.6.34-2 broke radeon driver for RS690M cards
by David C. Rankin 03 Jul '10

03 Jul '10

Guys, Just updated my laptop's spare drive and something in the last set up updates, which included the kernel, really affected the radeon driver badly. It's almost like I am back running in framebuffer mode. I'm not quite sure where to start troubleshooting as I am not familiar at all with the changes kms introduced into the radeon driver soup, but I suspect that may be where the problem lies. I have no xorg.conf, so if there are config issues, it's with the default config. When I updated to the 2.6.33 kernel (2.6.33.4-1), I was ecstatic. The radeon driver was working the best I had ever seen it. Heat control was much better and frame rate had almost quadrupedaled and compiz worked great. IIRC, I even posted here giving kudos to the devs on how good it was working. With the update to 2.6.34-2, it is worse than ever before. Specifically, compiz will no longer run -- it just whitescreens. (usually a problem with the driver NOT being loaded). However, in this casee, all of the radeon modules are loaded: [01:10 alchemy:/home/david] # lsmod | grep rad radeon 790145 2 ttm 45713 1 radeon drm_kms_helper 23740 1 radeon drm 162265 4 radeon,ttm,drm_kms_helper i2c_algo_bit 5071 1 radeon i2c_core 18364 5 radeon,i2c_piix4,drm_kms_helper,drm,i2c_algo_bit The biggest problem with the new packages is HEAT. We are now back to the point where the heat generated by the gpu and driver makes it uncomfortable to rest your palms on the palm-rest to type. I don't know where to start looking. The Xorg.0.log isn't that remarkable at all. The only things that stand out are: [ 36.790] (II) UnloadModule: "fbdev" [ 36.790] (EE) Failed to load module "fbdev" (module does not exist, 0) ** from earlier discussions, this is no big deal IIRC [ 37.526] is imortant (WW) RADEON(0): Direct rendering disabled [ 37.526] (II) RADEON(0): Acceleration disabled ** this doesn't look good. I guess it means no DRI -- why is the question? I know DRI is important to compiz and I'm fairly sure dri was working with the last kernel/radeon driver combination. The difference between the setup with 2.6.33 and 2.6.34 is day and night. Also, the color in thunderbird has gone green -- literally. My normal dark gray message background is now green. I guess this is somehow related to the driver issue. The full Xorg.0.log and a screenshot of green tbird are here: http://www.3111skyline.com/dl/bugs/Archlinux/Xorg.0.log http://www.3111skyline.com/dl/bugs/Archlinux/green-tbird.jpg I'm not sure where to start with this problem, with the xf86-video-ati package or with the kernel? What say the gurus? -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com

5 7

[arch-general] Licensing of Arch Wiki content
by Ananda Samaddar 03 Jul '10

03 Jul '10

I notice it's all under GFDL 1.2. I'm wanting to use a Gentoo doc for the Arch Security stuff but it's under a CC-SA attribution license which is incompatible with GFDL. Would it be possible to allow Wiki content under a CC licenses? I can't see it being too controversial a choice, as in CC licenses are now widely accepted. Even the venerable RMS uses CC licenses for his personal stuff as does a lot of the FSF/GNU stuff. Ananda

8 12