- Arch-general - lists.archlinux.org

[arch-general] RSS feed - missing feature|problem
by Netanel Shine 19 Jul '10

19 Jul '10

Hey all, My name is Netanel Shine, and a few days ago i began the process of building an israeli community of archlinux. I used a git clone to set up the main site. (like some other great projects file that archlinux git have to offer like the wiki and the forums) Everything went smoothly and just works great, except for one problem - the package rss feeds. The site address is: http://archlinux.org.il - under heavy development. The problem: As you all can see, the left rss box with the latest updates dont work and the list is empty. - because the system comes with an integrated "packages" part (you can see it here: http://archlinux.org.il/packages - not gonna use it), so the rss list updates from here (i guess) After discussions with some great people (in the irc) we concluded that the rss box pull`s the data from the 'models.Package' object - that connected to archlinux mainsite DB (Package.objects=PackageManager()), so if i dont have any access for the database - thats not gonna work. All sorts of ideas were came up like bulding a script that will do the job or, a an iframe that will copy the box from the mainsite (but the problem it will not be in hebrew) and an idea to replace the table that has for update in pkg_updates. (with logic that pulls from the feed) - but thats not easy because the logic is a wrapped up in django MVC. So dear friends, i turn to you for help - and I`m sure I would find it. -- Netanel Shine Blog - http://netshine.wordpress.com

2 1

[arch-general] Bad News .35rc kernel boots to KMS switch then hardlocks box
by David C. Rankin 18 Jul '10

18 Jul '10

Guys, Still plugging away at why the 2.6.34 kernels either lock on boot or if boot is successful, the graphics system whitescreens when compiz is started. To investigate (http://bugs.archlinux.org/task/20200) Andreas suggested I try the .35rc kernel. So once Thomas pointed me in the right direction to get the kernel from AUR, I built it (it built fine, all default values were used except the Ath9k modules were activated (I have an Atheros wireless card). Bad news, the kernel boots to what I guess is the KMS switch (that part where your screen flips from normal text mode to the higher resolution graphics mode) and then: (1) a 3-4 pixel horizontal white line flashes across the 'center' of the screen for approximately 1-2 seconds and; then (2) the screen goes completely black (dead unpowered black) and the box hardlocks. So the 2.6.35rc test was a bust. Do you think there is any use in recompiling and not enabling the Ath9k module will make any difference. Let me know. I guess the next step is to get with the radeon upstream folks and get them involved because the kernel/atiRS690M problem has gone from: good (2.6.32 kernel); to bad (2.6.33 kernel - compiz works but slow); to worse (2.6.34 only boots less than 20% of the time and compiz whitescreens every time); to completely unsuable (2.6.35rc kernel - won't boot at all) Let me know if you think recompiling w/o ath9k will make any difference and if any of you have contacts on the radeon upstream list, pass them along so I at least have an idea of who has any Arch knowledge on that list. Any other thoughts let me know, because it is apparent something has to be fixed before 2.6.35 moves forward. -- 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

1 0

[arch-general] Keep older kernel intact while upgrading to new kernel
by Madhurya Kakati 17 Jul '10

17 Jul '10

Hi, While updating to a new kernel pacman replaces the older kernel with the new one. Is there someway to keep the older kernel in /boot and have new entries for new kernel in menu.lst while keeping old entries intact?

11 22

[arch-general] [PATCH] gdisk patches
by Mark Pustjens 17 Jul '10

17 Jul '10

Hi List, Below a patch wich fixes two bugs in the gdisk package. They have been submitted uptream but not yet been accepted. The first bug fixed is that partition attributes are read/stored backwards. The second bug fixed is that when changing an undefined attribute no longer junk is displayed. I'm not sure if this is the right place, but i sent to this list mainly because there is no official gpt fdisk list afai could find. Now this patch has a place on the net. Cheers! Greetings/Groetjes Mark Pustjens -- diff --git a/extra/gdisk/PKGBUILD b/extra/gdisk/PKGBUILD index 0664a57..af9b44e 100644 --- a/extra/gdisk/PKGBUILD +++ b/extra/gdisk/PKGBUILD @@ -9,10 +9,12 @@ arch=('i686' 'x86_64') url="http://www.rodsbooks.com/gdisk" depends=('gcc-libs' 'util-linux-ng' 'popt') license=('GPL2') -source=(http://www.rodsbooks.com/gdisk/gdisk-$pkgver.tgz) +source=(http://www.rodsbooks.com/gdisk/gdisk-$pkgver.tgz + gdisk_attributes.patch) build() { cd $srcdir/$pkgname-$pkgver + patch -p1 -i "$srcdir/gdisk_attributes.patch" make install -D -m755 gdisk $pkgdir/sbin/gdisk install -D -m755 sgdisk $pkgdir/sbin/sgdisk @@ -23,4 +25,6 @@ build() { install -D -m644 README $pkgdir/usr/share/gdisk/README install -D -m644 NEWS pkgdir/usr/share/gdisk/NEWS } -md5sums=('48740d8de518f79ae9dae7ec58068d05') + +md5sums=('48740d8de518f79ae9dae7ec58068d05' + '106a4186587ab572f6397ba1702e8d47') diff --git a/extra/gdisk/gdisk_attributes.patch b/extra/gdisk/gdisk_attributes.patch new file mode 100644 index 0000000..e03c957 --- /dev/null +++ b/extra/gdisk/gdisk_attributes.patch @@ -0,0 +1,29 @@ +diff --git a/attributes.cc b/attributes.cc +index 527dc87..a7b2afd 100644 +--- a/attributes.cc ++++ b/attributes.cc +@@ -26,6 +26,7 @@ Attributes::Attributes(void) { + // Most bits are undefined, so start by giving them an + // appropriate name + for (i = 1; i < NUM_ATR; i++) { ++ temp.str(""); // empty stream + temp << "Undefined bit #" << i; + atNames[i] = temp.str(); + } // for +@@ -75,12 +76,12 @@ void Attributes::ChangeAttributes(void) { + do { + response = GetNumber(0, 64, -1, (string) "Toggle which attribute field (0-63, 64 to exit): "); + if (response != 64) { +- bitValue = PowerOf2(uint32_t (NUM_ATR - response - 1)); // Find the integer value of the bit +- if ((bitValue & attributes) == bitValue) { // bit is set +- attributes -= bitValue; // so unset it ++ bitValue = 1 << response; ++ if (bitValue & attributes) { // bit is set ++ attributes &= ~bitValue; // so unset it + cout << "Have disabled the '" << atNames[response] << "' attribute.\n"; + } else { // bit is not set +- attributes += bitValue; // so set it ++ attributes |= bitValue; // so set it + cout << "Have enabled the '" << atNames[response] << "' attribute.\n"; + } // if/else + } // if

4 5

[arch-general] Manager Duplicates in /var/cache/pacman/pkg
by David C. Rankin 17 Jul '10

17 Jul '10

Guys, I've updated my find duplicates script to work with the .xz packages. There are actually 2 scripts involved: 'fduparch.sh' is the wrapper script that just sets the directories and options for the actual duplicate finding script 'fduppkg'. In its current configuration fduparch.sh actually calls fduppkg twice. PASS 1: it calls fduppkg to scan /var/cache/pacman/pkg and move any duplicates found to '/home/backup/pkg-old'. Packages with the same name are then checked by DATE and any older packages are moved /home/backup/pkg-old. This leaves only the current packages in /var/cache/pacman/pkg making it much easing to move your install from machine-to-machine without copying unneeded duplicates. Second, it frees up space on / by moving duplicates to the /home partition. PASS 2: it calls fduppkg a second time to scan '/home/backup/pkg-old' and move any duplicates found to '/home/backup/pkg-older'. That way you have the latest packages in the normal '/var/cache/pacman/pkg' and you have a duplicate-free set of the last packages before update in '/home/backup/pkg-old'. All older versions are kept in '/home/backup/pkg-older' The way I use the scripts is to create softlinks to the scripts in /usr/local/bin (making sure /usr/local/bin is in your PATH) as follows: ln -s /wherever/you/put/fduparch.sh /usr/local/bin/fduparch ln -s /wherever/you/put/fduppkg /usr/local/bin/fduppkg then I simply call fduparch after each update to clean the duplicates out of /var/cache/pacman/pkg. running fduppkg without arguments gives the general usage: 01:16 nirvana:/srv/http/dl/Archlinux/scripts> sh fduppkg Usage: fduppkg <search dir> [ -d dup_dir -l logfile -s -v ] Searches <search dir> for duplicate pkgs and moves duplicate files to [dup_dir] or <search dir>/duplicates by default. -d | --dupdir Used to specify directory to hold duplicate rpms -l | --logfile Specify the log file name (default ./duplicates.log) -s | --silent Don't output anything to stdout, just log results -v | --verbose Output information showing which files are kept and not moved However, to change the default duplicate directories, just edit the wrapper script 'fduparch' and set the directories you want there. I have used a wrapper script to keep fduppkg as flexible as possible so I can simply run it on any package directory to find and move duplicates. (the split setup was originally developed to handle suse's archane cache directory structure, but it handles Arch's simple setup as well) Grab the duplicate scripts at: http://www.3111skyline.com/dl/Archlinux/scripts/fduparch.sh http://www.3111skyline.com/dl/Archlinux/scripts/fduppkg Finally, I have developed a script for determining which packages in /var/cache/pacman/pkg are 'Installed' or not. The script is 'chkinstpkgs.sh' and is available here: http://www.3111skyline.com/dl/Archlinux/scripts/chkinstpkgs.sh Running the script without argument will check the status of all packages in /var/cache/pacman/pkg and provide you with a concise list of installed/uninstalled packages in the following format: 01:24 alchemy:~/scr/arch> sh chkinstpkgs.sh Determining installed/orphaned packages in /var/cache/pacman/pkg... Initializing the package-information arrays Checking installed packages Total Number of Packages : 2713 Total Number Installed : 2225 Total Number Orphaned : 488 Updating the installed package array with installed/orphaned info ( be patient, time required is: [~30 sec/1000 pkgs] ) ORPHANS (pkg in /var/cache/pacman/pkg but not installed): Total packages orphaned: 488 Package Arch Installed ---------------------------------------------------------------------------- a2ps-4.14-1 x86_64 no acct-6.5.1-1 x86_64 no acpi-1.4-2 x86_64 no <snip> INSTALLED PACKAGES: Total packages installed: 2225 Package Arch Installed ---------------------------------------------------------------------------- a52dec-0.7.4-4 x86_64 yes aalib-1.4rc5-6 x86_64 yes <snip> I find all 3 scripts useful in managing my Arch boxes and for moving installs to new arch boxes. The chkinstpkgs.sh script is great for checking what I have forgotten to install on a new box. Enjoy! -- 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

1 0

Re: [arch-general] Keep older kernel intact while upgrading to new kernel
by Legioner 17 Jul '10

17 Jul '10

http://wiki.archlinux.org/index.php/Pacman In pacman.conf: IgnorePkg=name IgnoreGroup=name ________________ Reply Header ________________ Subject: [arch-general] Keep older kernel intact while upgrading to new kernel Author: Madhurya Kakati <mkakati2805(a)gmail.com> Date: 17th July 2010 06:27 Hi, While updating to a new kernel pacman replaces the older kernel with the new one. Is there someway to keep the older kernel in /boot and have new entries for new kernel in menu.lst while keeping old entries intact?

2 1

[arch-general] Tracking down ATI/Compiz Bug in 2.6.34 kernels (looks like gpu init in 2.6.34)
by David C. Rankin 17 Jul '10

17 Jul '10

Guys, Still trying to get compiz to quit white-screening when running the 2.6.34 kernels. (I booted OK this time, still down want to see if it will boot again yet while I'm working this compiz issue). For those not following the earlier threads, compiz and the entire graphics system on my laptop works perfectly with the LTS kernel, but when I upgraded to the 2.6.34 kernels, compiz white-screens due to a bug somewhere in the kernel/KMS/xf86-video-ati interplay. As mentioned earlier, starting with the 2.6.32 kernels, everything was GREAT with this laptop and the graphic response had never been so good on the 'radeon' driver -- it was kicking ass! But with the 2.6.34 kernel, something is badly broken. Now 'compositing' works fine on the box. I can toggle compositing on/off in Gnome and it is fine (still disappointed that it re-sizes the gnome-terminal, etc.. back to it's original geometry on switching compositing on/off, but that is small potatoes compared to this compiz mess). There is nothing compiz specific in Xorg.0.log that is helpful (but see below for the massive differences between 2.6.34 and LTS Xorg.0.log files). .xsession-error catches a couple of errors when compiz tries to start: Window manager warning: Invalid WM_TRANSIENT_FOR window 0x111 specified for 0x5e0017b (Configure ). Window manager warning: Invalid WM_TRANSIENT_FOR window 0x111 specified for 0x5e004cd (Configure ). Window manager warning: Invalid WM_TRANSIENT_FOR window 0x111 specified for 0x5e0099b (Configure ). * Detected Session: gnome * Searching for installed applications... ** Message: pygobject_register_sinkfunc is deprecated (GtkWindow) ** Message: pygobject_register_sinkfunc is deprecated (GtkInvisible) ** Message: pygobject_register_sinkfunc is deprecated (GtkObject) compiz (core) - Error: Plugin 'text' not loaded. compiz (shift) - Warn: No compatible text plugin loaded. Window manager warning: Received a _NET_WM_MOVERESIZE message for 0x4800021 (CompositeT); these messages lack timestamps and therefore suck. Window manager warning: Received a _NET_WM_MOVERESIZE message for 0x4800021 (CompositeT); these messages lack timestamps and therefore suck. Window manager warning: Received a _NET_WM_MOVERESIZE message for 0x4800021 (CompositeT); these messages lack timestamps and therefore suck. Window manager warning: Received a _NET_WM_MOVERESIZE message for 0x4800021 (CompositeT); these messages lack timestamps and therefore suck. Window manager warning: Invalid WM_TRANSIENT_FOR window 0x111 specified for 0x5800006 (Session Ch). but I can't really decipher them. The compiz (core) and compiz (shift) lines are normal, I get them when starting compiz under LTS also and compiz starts fine. Where there are MASSIVE differences is in the initialization of my video card in the Xorg.0.log files. The LTS Xorg.0.log is twice a large as the Xorg.0.log file from the 2.6.34 kernel startup. Much of it is just gibberish to me, but I'm sure the bug lies in the way the 2.6.34 kernel is trying to initialize my gpu. I have saved copies of each file for review: 2.6.34.1 kernel (35k): http://www.3111skyline.com/dl/Archlinux/bugs/compiz/34.1/gnome/Xorg.0.log LTS-kernel (62k) http://www.3111skyline.com/dl/Archlinux/bugs/compiz/lts/gnome/Xorg.0.log I don't know if you want me to open a bug here or if Allan, Tobias or some of the other devs would like to try to narrow this down 'on-list' first so a more meaningful bug report can be filed, if needed. Let me know what you guys think. I hate to admit it, but I'm somewhat of a compiz junkie. There is nothing like managing multiple desktops than the simple elegance of compiz and a few smart key/mouse bindings. I've got to get this bug fixed :p -- 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

2 3

Re: [arch-general] [arch-dev-public] Anyone using lilo?
by Eric Bélanger 17 Jul '10

17 Jul '10

On Thu, Jul 15, 2010 at 7:46 PM, Dale Blount <dale(a)archlinux.org> wrote: > On Thu, 2010-07-15 at 15:29 -0400, Eric Bélanger wrote: >> Hi, >> >> Roman has flagged my lilo packages. Lilo developpement is now active >> and lilo 23.0 was released. Unfortunately, my only system using lilo >> is no longer working. Is there anyone else using lilo? Ideally, it >> would be a dev who would take over the package or, at least, a user >> willing to work with me in testing the new packgae before it hits the >> testing repo. > > I'm forced to use it on a single HP server where grub just flat out > refuses to work. I could be convinced to help with testing (as long as > it's just verifying that it's working and not several reboots). > > Dale > > If I understodd correctly, you can only reboot that server once. Is that correct? I'll wait to see if I can't get more testers. I'll forward this thread on arch-general ML.

1 0

[arch-general] Tasks for newbie at online bug squashing (during Archcon)?
by Mathias Huber 16 Jul '10

16 Jul '10

Dear Archers, I've seen there will be an online bug squashing with Archers worldwide during Archcon on July 22 and 23 <http://bbs.archlinux.org/viewtopic.php?id=83844>. I've set some time apart to join the fun. However, I am an Arch newbie, though long standing Linux user. What will there be for me to do? Can you find me some trivial tasks? Most bugs I find in flyspray are beyond my capabilities -- X.org flaws or missing hardware support. I think I could update simple package builds, or correct a wrong path here and there. Apart from that, I am quite good at writing documentation. Should I comb the Arch wiki? Do I need to have a spare Arch system at hand to test things? Maybe someone could take this newbie by the hand? Cheers, Mathias

2 3

[arch-general] bbs.archlinux.org is now switched to https only!
by Thomas Bächler 16 Jul '10

16 Jul '10

I just performed the switch to https only on bbs! I also adjusted some internal URLs, so all files will be properly fetched via https directly. http is redirected automatically. Note that the navbar links on Archweb and all other sites still point to http, but that is redirected automatically. There is a catch: 1) Apache configures SSL per-vhost. That means that even though we have a wildcard certificate, the browser must support SNI for name-based vhosts to work. All clients that are not SNI-capable will be redirected to www instead. 2) wget doesn't like wildcard certificates. That means you need to use --no-check-certificate with wget. 3) Our certificate is from CACert. AFAIK, this is not included in many browsers by default. If you use Arch Linux, at least everything that uses the OpenSSL certificate store and all Mozilla browsers are CACert-enabled - on other operating systems, our certificate might show up as untrusted. Let me know if any of the above (especially 1) cause any problems.

1 0