- Arch-general - lists.archlinux.org

[arch-general] plans for Xorg/Mesa - closed drivers may break for some time in testing
by Andreas Radke 17 Dec '10

17 Dec '10

A new libdrm has been released. This is required to build new ddx drivers for nouveau and the latest intel rc driver for sandy bridge gfx. The current Mesa 7.9 branch won't build anymore the nouveau-dri stuff with the updated libdrm and it's quiet a buggy upstream release. Mesa 7.10 branch is short before the release and has tons of fixes and completes some missing features. We also have a minor Xorg-server 1.9.3 update pending that I will do in extra. Then there's already Xorg-server 1.10 rc1 out for some time we need to test. My plan is to start bringing new libdrm/mesa7.10/Xorg1.10 in the next days to testing. This will improve (me prays) the situation for open source drivers but will probably break the proprietary drivers for some time. I don't follow the closed stuff. Maybe you know something about the state of catalyst and nvidia with new Xorg 1.10. -Andy

2 1

[arch-general] howto tease and install of kdemod3 from the old packages?
by David C. Rankin 17 Dec '10

17 Dec '10

Guys, I know kdemod3 is considered dead, but I would like to install it on the new box I am setting up tonight. I have the full chakra repo of files and I thought it would be as simple as just creating an entry in pacman.conf to point to my server and the install would proceed. But I ran into an issue with [00:19 phoenix:~] # pacman -Sy kdemod3-complete :: Synchronizing package databases... core is up to date extra is up to date community is up to date archlinuxfr is up to date kdemod-legacy is up to date xyne-any is up to date resolving dependencies... warning: cannot resolve "libxxf86misc", a dependency of "kdemod3-kdebase" <snip 50 of the same> :: the following package(s) cannot be upgraded due to unresolvable dependencies: kdemod3-applets kdemod3-baghira-sidebar kdemod3-kdeaddons-base <snip the rest of the kdemod3 packages> Do you want to skip the above package(s) for this upgrade? [y/N] Yes, I know kdemod3 is broken by the cups strlcpy problem, but I use many of the kde3 apps in whatever desktop I use. For this new box it will most likely be just fluxbox, but I need kwrite, kate, konqueror, kcolorchooser, ksnapshot, quanta+, etc.... I hate the sloppy kde4 versions or it would load those. Before the kdemod-legacy repo was pulled, install was simple, so I wonder if it is possible to trick the installer into resolving "libxxf86misc" somehow so that the install can proceed. Anybody have any thoughts on how this can be done? Worst case, I guess I could cannibalize a kdemod3 install from one of my other boxes, but I would like to find a way to do a proper install since I have 3 more boxes to install. So, what says the brain trust? Possible? Not Possible? -- 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 2

[arch-general] dmraid install failure (new thread)
by David C. Rankin 16 Dec '10

16 Dec '10

Sorry for the new thread, but I'm at the office and the 'leave message of server' in Tbird didn't work :( Sir Thomas wrote: >Am 16.12.2010 03:30, schrieb David C. Rankin: >> > Waiting 10 seconds for device /dev/mapper/nvidia_haheegdbp6 ... >> > >> > Root device '/dev/mapper/nvidia_haheegdbp6' doesn't exist. Attempting to >create it. >> > >> > ERROR: Unable to determine major/minor number of root device >> > '/dev/mapper/nvidia_haheegdbp6' >> > >> > You are being dropped to a recovery shell >> > >> > Type 'exit' to try and continue booting >> > >> > /bin/sh: can't access tty; job control turned off >> > >> > [ ramfs \ ]# >You have an almost fully functional system in that ramfs environment. >Look at the output of 'ls -l /dev/mapper' to see if the devices are >indeed missing. > Yep, but the issue is I haven't the foggies about what I can and can't do with the ramfs prompt. However, I think I have some additional information that will help. >Look at 'ls -l /dev/sd*' to see if your hard drives even show up. If >they do, try to issue 'dmraid -ay' again and see if the /dev/mapper >devices show up now. > All of the drives are there and you can see them with cat /proc/partitions. I tried recreating the arrays with 'dmraid -ay' but 'dmraid' isn't found. So it looks like it either wasn't installed (hard to believe because I install just about everything exept firmware stuff in the initial package selectioni), or for some reason the initramfs was made to include them. My guess is that it wasn't installed to begin with because dmraid should be there if it was. I'll go back and chroot the environment and see what happened to dmraid and report back. I'll bet that fixes it. Then the question becomes "Why wasn't dmraid installed to begin with?" Only 2 possible answers: (1) stupidity (never ruled out); or (2) a bug. I'll let you know. Thanks for your help. >This might just be a timing problem: dmraid -ay might be called before >/dev/sd* is fully set up and detected - we had these problems in the >past already. The 'sleep' hook put after the udev hook can work around that. > I>f it isn't a timing problem, then your hard drives are probably not d>etected. The reasons for this can be manifold, but it never hurts to >try if the fallback image shows the same behaviour. -- 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 1

[arch-general] [PATCH]: suggestion for new udev.install
by Tom Gundersen 16 Dec '10

16 Dec '10

Hi UDev maintainers, Attached is a suggestion for a new udev.install file. Two changes: Removed the output regarding upgrading from udev =< 100. This is more than four years old, and was referring to a non-existent readme file. Added a conditional database conversion, as this is recommended when upgrading from udev <=164 to 165 (which was recently released). Cheers, Tom

2 2

[arch-general] new dmraid install - grub installed fine - boot fails to find root filesystem - dropped to [ramfs /]# ?
by David C. Rankin 16 Dec '10

16 Dec '10

Guys, There is either a new bug in the dmraid install routine or I've screwed something up. However, after not having problems with the prior 3 dmraid installs I've done, I'm not sure it's me. I made a new Arch install on a box that had an existing dmraid setup running suse 10.3. I installed per the "Installing with Fake Raid" wiki. For this setup, it was a complete fresh install, I completely repartitioned the array for this install not preserving /home or anything else. The logical partitions are: /dev/mapper/nvidia_haheegdb /dev/mapper/nvidia_haheegdbp5 /boot /dev/mapper/nvidia_haheegdbp6 / /dev/mapper/nvidia_haheegdbp7 swap /dev/mapper/nvidia_haheegdbp8 /home All of the data partitions are ext3. (swap is of course swap) As per the wiki, during the grub install, I got an Error 22, so I went back in created sym links between nvidia_haheegdbp5 -> nvidia_haheegdb5, to get around the 'p' problem with grub not finding the partitions. I set the geometry with CHS information from cfdisk and confirmed that grub was happy with a 'find /grub/stage1' before setting the root (hd0,4) and performing the setup on (hd0). Grub setup completes without any errors and reports success. dm_mod and dm_mirror are included in /etc/mkinitcpio.conf and /etc/rc.conf. However on boot, the boot fails when it can't find /dev/mapper/nvidia_haheegdbp6. The actual error is: -------------------- Waiting 10 seconds for device /dev/mapper/nvidia_haheegdbp6 ... Root device '/dev/mapper/nvidia_haheegdbp6' doesn't exist. Attempting to create it. ERROR: Unable to determine major/minor number of root device '/dev/mapper/nvidia_haheegdbp6' You are being dropped to a recovery shell Type 'exit' to try and continue booting /bin/sh: can't access tty; job control turned off [ ramfs \ ]# -------------------- Now I'm stuck here. I have gone back chrooted the install and reinstalled grub twice just to make sure. No change. It boots to the grub menu and then boots fine until it gets to where it reads the root line from menu.lst and then dies. One thing I found strange, the second time I was setting up the chroot and had made a /mnt/arch to base the chroot in, when I when to mount the root partition with: mount /dev/mapper/nvidia_haheegdbp6 /mnt/arch mount gave the error "You must specify a type..." which I thought was strange because then I turned around and did: mount /dev/dm-2 /mnt/arch and it worked just fine. Since /dev/mapper/nvidia_haheegdbp6 is just a link to ../dm-2 I found that strange. So I need ideas of what to try to get this box working. I can't figure out what went wrong. dm_mod and dm_mirror are loaded and working fine when chrooted. With this as the 4th dmraid install I've done with Arch, I figured it would be simple, but I think this is the first install I've done since dmraid added the 'p' designation. Other than needing to add the links from 'p' to 'no p' everything seemed the same, so I'm not sure where things are mucked up. Let me know if I can provide anything else to help. I'm sort of dead in the water until I get this sorted. -- 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 5

Re: [arch-general] We want to help
by Tomás Acauan Schertel 16 Dec '10

16 Dec '10

On Thu, Dec 16, 2010 at 05:57, Andrea Scarpino <andrea(a)archlinux.org> wrote: > On Wednesday 15 December 2010 22:45:21 Loui Chang wrote: >> Finally, I'd like to honestly say I don't see AUR2 as really being a >> worthwhile investment for the next generation of the AUR. It's just >> another web app like the current AUR, it might have a couple extra >> frills, but I don't think it makes sense to rewrite the whole thing just >> for that sake. They can probably added easily enough to the current >> code. > I agree. > Instead of write code for AUR2, you guys should help fixing current AUR bugs or > implement new AUR features. Just my two cents. Guys, we're here to help where project needs. If you say the best effort is expand the current AUR, we gonna help on this. If you say that we need to close bug reports in flyspray, we gonna help on this. I agree that rewrite AUR just to have it running on Django but with no new BIG features is like working in vain. I'll start looking for PHP developers (to implement features on current AUR) and looking people to help on closing bur reports on flyspray. It that OK for you guys? > > Cheers > > -- > Andrea Scarpino > Arch Linux Developer > -- Tomás A. Schertel ---------------------------------------------- Linux Registered User #304838 Arch Linux User http://www.archlinux-br.org/ ----------------------------------------------

1 0

[arch-general] dropping go-openoffice/icu-4.6 rebuilds
by Andreas Radke 15 Dec '10

15 Dec '10

The former ooo-build project "go-openoffice" is deprecated by upstream developers in favor of the upcoming LibreOffice (LibO). It's time to drop it from our repos while we are rebuilding all OpenOffice branches for the icu-4.6 .so-bump. Please use the vanilla Oracle openoffice-base packages or try out the new and already very stable libreoffice packages. The Oracle office beta and devel packages will get rebuilt when new upstream releases will happen. Don't expect them to work when we move icu-4.6. They are of low interest. -Andy

4 7

[arch-general] why I'd rather use Python over Javascript for web development
by C Anthony Risinger 14 Dec '10

14 Dec '10

On Tue, Dec 14, 2010 at 1:23 PM, Kaiting Chen <kaitocracy(a)gmail.com> wrote: > On Tue, Dec 14, 2010 at 2:14 PM, C Anthony Risinger <anthony(a)extof.me>wrote: > >> the benefit to the pyjs approach is 100% client side operation, so it >> can run without online access. additionally, the python-DOM version >> (or the pyjs version if proxying thru a local daemon) could >> potentially direct install from the website, leading to "install now" >> functionality. lastly, python means you could use the same lang to >> write the front end and the backend, and communicate using JSON >> messages. >> >> as a professional web applications developer by day, i can vouch that >> writing webapps requires knowledge of about 4 different haphazardly >> implemented "standards", requiring far to much painfully acquired >> knowledge. by using a library like pyjamas, you allow anyone with >> python experience to write incredibly functional plugins/modules, and >> share maintenance load. django is a great platform, but after i >> discovered pyjamas about 1yr ago, i haven't looked back, and am >> convinced that compiler technology is the only sane way to develop >> complex and maintainable web-based applications. > > Out of curiosity why is everyone so again just writing Javascript? Everyone > seems to want to write in some other language and then compile to Javascript > these days. --Kaiting. well for me at least, it not 100% related to javascript itself; JS is an incredibly powerful language that will let you hang yourself again and again :-) primarily, it's: ) JS is completely unstructured. powerful, but causes developers to implement many things that would be a part of the core syntax in other langs ) the ^^^^ causes many different impls of the same, and new devs to misuse the really great things about JS, like first-class closures. leads to absolutely obtuse and horrendous looking libraries, with weird semantics for its usage, like passing objects to emulate named arguments, and a hundred other more prudent examples. ) umpteen number of naunces between browsers, browser versions, and half-eaten standards. maddening. combined with [some] similar problems with both HTML and CSS, and it's enough to drive one ape-sh*t. soooo.... i use a python abstraction to give me my favorite language and all it's goodies while also shielding me from platform variation, along with widget libraries to support the build-once-deploy-everywhere thinking. yes, JS has some decent libraries, and widget sets (don't say extjs). but pyjamas can be ran as a 100% python desktop app too. so ultimately, compiler tech gives me a 100% cross-desktop cross-platform cross-browser cross-version solution... try it out, it's like finding a nude beach after walking 100km thru a blizzard :-) C Anthony

3 3

Re: [arch-general] [arch-dev-public] [signoff] filesystem 2010.12-1
by Jesse Young 14 Dec '10

14 Dec '10

On Tue, Dec 14, 2010 at 08:21:41 +0100, Pierre Schmitz wrote: > Morning, > > this is a minor update to the filesystem package and I hope we can > finally move it to core. Only change is: > > * don't check if profiles are executable; FS#22036 > > Please sign off, Hopefully I'm not too late. But I think you should know that filesystem depends on iana-etc, which is not in the base group, nor is it on the core install CD. What I would do is to add iana-etc to base/core ISO, which should not hold up this signoff, but if another course of action is taken, it might block this filesystem release from moving to core. I've opened https://bugs.archlinux.org/task/22101 to track this task. conditional-user-unsignoff x86_64. Regards, Jesse

3 4

[arch-general] Howto Preserve Current Kernel through Update?
by David C. Rankin 14 Dec '10

14 Dec '10

Guys, I want to keep the current kernel while I upgrade to 2.6.36-2 and where I confused is how to use mkinitcpio to do this. What I think I can do to preserve the current kernel as 2.6.36-dcr is: (1) cp -a /lib/modules/2.6.36-ARCH /lib/modules/2.6.36-dcr (2) mkinitcpio -k 2.6.35-dcr \ -c /etc/mkinitcpio.conf \ -g /boot/kernel26-dcr.img mkinitcpio -k 2.6.35-dcr \ -c /etc/mkinitcpio.conf \ -g /boot/kernel26-dcr-fallback.img \ -S autodetect (3) update grub menu.lst and create entries for the dcr kernel Before I wasted too much time chasing my tail, I thought would put this out to the list and see if (or what) I'm missing. -- 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 4