Re: [arch-dev-public] 8 CPUs instead of 4? (was: kernel26 2.6.25-1 enters [testing])
> I've got some machines at work that have 4 dual core CPU's (cpuinfo > shows 8 cpu's) running 32 bit Linux so it's not that wierd. We have quite a few dual quad-core cpu boxes at work too.
Re: [arch-dev-public] Database breakage - again!
On Sun, 20 Apr 2008, Thomas Bächler wrote: Thomas Bächler schrieb: Okay, I am pissed right now. bzip2 (x86_64) had version 1.0.5-1 in the database, while the version in the package and the filename are 1.0.5-2. I tried to fix it, and found out what happened in the first place: [x86_64][17:21:[EMAIL PROTECTED] trunk]$ archrelease testing-x86_64 svnmerge: no integration info available ~/arch/repos/svn-packages/bzip2 ~/arch/repos/svn-packages/bzip2/trunk Nothing to commit ~/arch/repos/svn-packages/bzip2/trunk However, the PKGBUILD in testing-x86_64 was the old one. This is clearly a problem in the archrelease script. AND in our db scripts. I fixed it this time, however, people should actually look at the output of the scripts. It's not like we're monkeys. Here are all others: Inconsistency: firefox3 3.0b4-1 vs. firefox3-3.0b5-1-x86_64.pkg.tar.gz Inconsistency: bmpx 0.40.13-1 vs. bmpx-0.40.13-2-i686.pkg.tar.gz Inconsistency: bzr 1.3-1.1 vs. bzr-1.3-1-x86_64.pkg.tar.gz Inconsistency: darcs 1.0.9-1 vs. darcs-2.0.0-1-x86_64.pkg.tar.gz Inconsistency: pidgin 2.4.0-1 vs. pidgin-2.4.1-1-x86_64.pkg.tar.gz I tried again to fix bmpx but it idn't work: http://archlinux.org/pipermail/arch-dev-public/2008-April/005883.html The others are packages that I built for x86_64. For reasons I don't know, something went wrong. I asked for help on this ML: http://archlinux.org/pipermail/arch-dev-public/2008-April/005798.html http://archlinux.org/pipermail/arch-dev-public/2008-April/005726.html So far no response. Can anyone explicitly explain how to fix these things? I don't know snv and don't want to break the repos further. I wonder if the problem isn't that the other dev modified the files in repos/extra/i686 instead of trunk... Thanks Eric -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: [arch-dev-public] 8 CPUs instead of 4? (was: kernel26 2.6.25-1 enters [testing])
On Sun, 2008-04-20 at 12:31 -0500, Dan McGee wrote: > On Sun, Apr 20, 2008 at 12:21 PM, Thomas Bächler <[EMAIL PROTECTED]> wrote: > > Have a look at: > > http://bbs.archlinux.org/viewtopic.php?id=47390 > > > > According to the kernel configuration help, increasing the maximum number > > of CPUs from 4 to 8 will make the kernel 32KB bigger with no performance > > decrease. > > > > Opinions? > > I'd always rather these things go through the ML or a feature request, > rather than a forum post. That way someone can actually trace the > process. > > Sounds fine to me, although I don't think there is any point on i686 > (who would run >4 cores there?). x86_64 makes sense though. I've got some machines at work that have 4 dual core CPU's (cpuinfo shows 8 cpu's) running 32 bit Linux so it's not that wierd. > -Dan -- K. Piche <[EMAIL PROTECTED]>
Re: [arch-dev-public] testing ->core/extra movement instructions?
On Tue, 15 Apr 2008, Aaron Griffin wrote: On Tue, Apr 15, 2008 at 12:10 PM, Jan de Groot <[EMAIL PROTECTED]> wrote: Can someone give clear instructions on how to move things from testing to core and/or extra? I've done some packages a while ago, which were graphviz and glib2. Looking again, I see glib2 isn't moved at all and graphviz has been fixed up by some other dev last week. What's going on here? It should be exactly the same as it always ways, except instead of CVS tags, we're using "archrelease" and "svn rm" (or archrm, which does very little) In essence: cd graphviz/trunk archrelease extra-i686 (or run extrapkg to do this and the scp upload) cd ../repos/ svn rm testing-i686 Then you need to do the db-script side exactly as we always have done it: both db-testing and db-extra need to be run, with a package in $STAGING/add and one in $STAGING/del Pierre's testing2extra script should do all this - but I have not used it myself. Jan, did you attempt to do it manually, or use the script? It doesn't seem to work: PWD: ~/svnroot/bmpx/trunk 48 [EMAIL PROTECTED] $ archrelease extra-i686 UG ../repos/extra-i686/PKGBUILD property 'svnmerge-integrated' set on '../repos/extra-i686' ~/svnroot/bmpx ~/svnroot/bmpx/trunk Sendingrepos/extra-i686 Committed revision 547. ~/svnroot/bmpx/trunk -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
[arch-dev-public] Issue on kernel 2.6.25 upgrade
I've pasted the full output below, but what I wanted to point out is the "missing ide-cd module" part. Some of us unfortunately still have to use IDE. In addition, the kernel26.preset.pacnew file was installed with 600 permissions...any reason why it is so restrictive? -Dan (18/27) upgrading kernel26 [-] 100% warning: /etc/mkinitcpio.d/kernel26.preset installed as /etc/mkinitcpio.d/kernel26.preset.pacnew >>> Updating module dependencies. Please wait ... >>> MKINITCPIO SETUP >>> >>> If you use LVM2, Encrypted root or software RAID, >>> Ensure you enable support in /etc/mkinitcpio.conf . >>> More information about mkinitcpio setup can be found here: >>> http://wiki.archlinux.org/index.php/Mkinitcpio >>> Generating initial ramdisk, using mkinitcpio. Please wait... ==> Building image "default" ==> Running command: /sbin/mkinitcpio -k 2.6.25-ARCH -c /etc/mkinitcpio.conf -g /boot/kernel26.img :: Begin build :: Parsing hook [base] :: Parsing hook [udev] :: Parsing hook [autodetect] :: Parsing hook [ide] ERROR: module 'ide[-_]cd' not found :: Parsing hook [filesystems] :: Generating module dependencies :: Generating image '/boot/kernel26.img'...SUCCESS ==> SUCCESS ==> Building image "fallback" ==> Running command: /sbin/mkinitcpio -k 2.6.25-ARCH -c /etc/mkinitcpio.d/kernel26-fallback.conf -g /boot/kernel26-fallback.img config file '/etc/mkinitcpio.d/kernel26-fallback.conf' cannot be found, aborting... ==> FAIL ==> Building image "pata" ==> Running command: /sbin/mkinitcpio -k 2.6.25-ARCH -c /etc/mkinitcpio.d/kernel26-pata.conf -g /boot/kernel26-pata.img :: Begin build :: Parsing hook [base] :: Parsing hook [udev] :: Parsing hook [autodetect] :: Parsing hook [pata] :: Parsing hook [filesystems] :: Generating module dependencies :: Generating image '/boot/kernel26-pata.img'...SUCCESS ==> SUCCESS
Re: [arch-dev-public] Drop the unstable repository
On Sun, 20 Apr 2008, Tobias Kieslich wrote: Hi, two remarks: - gimp-devel: 2.5.x gains speed these days but I think it is better done in AUR gimp(-devel) takes time to compile even on my fast machine. For that reason, it should remain in a repo. I'm willing to continue maintain it (unless someone else is more interested). The devel 2.5 branch was released a few days ago so the gimp-devel package will switch to that instead of following the stable branch like it did since 2.4 is out.. - fvwm-devel: the actually popular 2.5.x series of fvwm is what people are using. fvwm 2.4 is more of a legacy and I think we should maintain 2.5.x in the official repos. I have the suspicion that actually 2.5.x is the only one that is maintained upstream. Oh and 2.5 is "unstable" since I started using Arch; roughly 5 years I'd say. fvwm 2.4 is still active. Latest release was last December. Developement is slow on both branches. I've been using fvwm-devel for years and it's rock stable. I believe most fvwm users use the devel version. Possibly we could update the fvwm package to the 2.5 branch. A similar thing was done for fluxbox a couple of years ago. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: [arch-dev-public] Drop the unstable repository
On Sun, 20 Apr 2008, Thomas Bächler wrote: I had this thought during the above discussion about compat-wireless: Do we really need unstable? Almost nobody uses it and let's see which packages are in there: opera-devel firefox3 kernel26mm fvwm-devel gimp-devel reiser4progs + dependencies. openoffice-devel mplayer-svn Most of the rest is so out of date and old that it should be dropped anyway (including the external modules for kernel26mm). The packages that are actually being maintained can IMO be moved to extra. Everybody who installs a -svn or -devel package probably knows it is unstable (firefox3 should be renamed to firefox-devel then). So I'm asking you: What is the point of having a repository with <30 packages, half of which are neither used nor maintained? Except maybe confusion among users (wait? enable unstable? isn't that dangerous?). You forgot gqview-devel in your list. The package is up-to-date and it works fine. I've been using it for years as my main image viewer without any problems. I don't see why we wouldn't keep it. I agree about removing the out-of-date and old packages unless a dev wants to actively maintain them. I don't mind wether we keep the rest in the unstable repo or move them in extra. If we move them in extra, we could add "Developement version" at the end of the package description to inform the user. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: [arch-dev-public] Drop the unstable repository
Am Sun, 20 Apr 2008 14:14:23 +0200 schrieb Thomas Bächler <[EMAIL PROTECTED]>: > I had this thought during the above discussion about compat-wireless: > Do we really need unstable? Almost nobody uses it and let's see which > packages are in there: > > opera-devel > firefox3 > kernel26mm > fvwm-devel > gimp-devel > reiser4progs + dependencies. > openoffice-devel > mplayer-svn > > Most of the rest is so out of date and old that it should be dropped > anyway (including the external modules for kernel26mm). The packages > that are actually being maintained can IMO be moved to extra. > Everybody who installs a -svn or -devel package probably knows it is > unstable (firefox3 should be renamed to firefox-devel then). > > So I'm asking you: What is the point of having a repository with <30 > packages, half of which are neither used nor maintained? Except maybe > confusion among users (wait? enable unstable? isn't that dangerous?). > opera-devel - this is an exception only until there will be the first 64bit release. later devel releases could be maintained in AUR openoffice-base-devel - i really doubt it would be a good idea to maintain it in AUR - compile time matters here - it should stay somewhere binary (maybe even in extra or permanently in testing) ! -Andy
Re: [arch-dev-public] kernel26 2.6.25-1 enters [testing]
Am Sun, 20 Apr 2008 10:27:02 +0200 schrieb Pierre Schmitz <[EMAIL PROTECTED]>: > Am Samstag, 19. April 2008 18:09:08 schrieb Thomas Bächler: > > If there are any problems due to the configuration changes or new > > kernel bugs, please let me know. > > I got the following error when using the nvidia driver: > > > NVRM: bad caching on address 0x81007c91a000: actual 0x173 != > expected 0x17b > NVRM: please see the README section on Cache Aliasing for more > information NVRM: bad caching on address 0x81007c91b000: actual > 0x173 != expected 0x17b > NVRM: bad caching on address 0x81007cbad000: actual 0x173 != > expected 0x17b > NVRM: bad caching on address 0x81007cbb4000: actual 0x173 != > expected 0x17b > NVRM: bad caching on address 0x81007cbb5000: actual 0x173 != > expected 0x17b > NVRM: bad caching on address 0x81007cbb6000: actual 0x173 != > expected 0x17b > NVRM: bad caching on address 0x81007cbb7000: actual 0x173 != > expected 0x17b > NVRM: bad caching on address 0x81007cbb8000: actual 0x173 != > expected 0x17b > NVRM: bad caching on address 0x81007cbb9000: actual 0x173 != > expected 0x17b > NVRM: bad caching on address 0x81007cbba000: actual 0x173 != > expected 0x17b > > Even when using the 173.08 beta driver which is meant for kernel > 2.6.25 I got the same errors. Any ideas? Same here: NVRM: bad caching on address 0x81022ce78000: actual 0x173 != expected 0x17b NVRM: please see the README section on Cache Aliasing for more information NVRM: bad caching on address 0x81022ce79000: actual 0x173 != expected 0x17b NVRM: bad caching on address 0x81022ce7a000: actual 0x173 != expected 0x17b NVRM: bad caching on address 0x81022ce7b000: actual 0x173 != expected 0x17b NVRM: bad caching on address 0x81022ce7c000: actual 0x173 != expected 0x17b NVRM: bad caching on address 0x81022ce7d000: actual 0x173 != expected 0x17b NVRM: bad caching on address 0x81022ce7e000: actual 0x173 != expected 0x17b NVRM: bad caching on address 0x81022ce7f000: actual 0x173 != expected 0x17b NVRM: bad caching on address 0x81022c47a000: actual 0x173 != expected 0x17b NVRM: bad caching on address 0x81022cac1000: actual 0x173 != expected 0x17b but seems to work fine so far. -Andy
Re: [arch-dev-public] 8 CPUs instead of 4?
eliott schrieb: Well.. if it isn't harmful in any way, and if we would do it on x86_64, then we should also do it on i686. Having as consistent a baseline as possible is good. Agreed. As to actually doing it, are there any ramifications due to the potential for tracking additional cpus (timeslice allocation algorithmic changes?) that would be a noticeable performance inpact for people running 2 or 4 cpus? "This allows you to specify the maximum number of CPUs which this kernel will support. The maximum supported value is 255 and the minimum value which makes sense is 2. This is purely to save memory - each supported CPU adds approximately eight kilobytes to the kernel image." That's all they say about it. signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Drop the unstable repository
Hi, two remarks: - gimp-devel: 2.5.x gains speed these days but I think it is better done in AUR - fvwm-devel: the actually popular 2.5.x series of fvwm is what people are using. fvwm 2.4 is more of a legacy and I think we should maintain 2.5.x in the official repos. I have the suspicion that actually 2.5.x is the only one that is maintained upstream. Oh and 2.5 is "unstable" since I started using Arch; roughly 5 years I'd say. for the other packages, toss them. -T
Re: [arch-dev-public] 8 CPUs instead of 4? (was: kernel26 2.6.25-1 enters [testing])
On 4/20/08, Dan McGee <[EMAIL PROTECTED]> wrote: > On Sun, Apr 20, 2008 at 12:21 PM, Thomas Bächler <[EMAIL PROTECTED]> wrote: > > Have a look at: > > http://bbs.archlinux.org/viewtopic.php?id=47390 > > > > According to the kernel configuration help, increasing the maximum number > > of CPUs from 4 to 8 will make the kernel 32KB bigger with no performance > > decrease. > > > > Opinions? > > > I'd always rather these things go through the ML or a feature request, > rather than a forum post. That way someone can actually trace the > process. > > Sounds fine to me, although I don't think there is any point on i686 > (who would run >4 cores there?). x86_64 makes sense though. Well.. if it isn't harmful in any way, and if we would do it on x86_64, then we should also do it on i686. Having as consistent a baseline as possible is good. As to actually doing it, are there any ramifications due to the potential for tracking additional cpus (timeslice allocation algorithmic changes?) that would be a noticeable performance inpact for people running 2 or 4 cpus?
Re: [arch-dev-public] Drop the unstable repository
Am Sonntag, 20. April 2008 14:14:23 schrieb Thomas Bächler: > Do > we really need unstable? I have never used it. -- archlinux.de
Re: [arch-dev-public] 8 CPUs instead of 4? (was: kernel26 2.6.25-1 enters [testing])
On Sun, Apr 20, 2008 at 12:21 PM, Thomas Bächler <[EMAIL PROTECTED]> wrote: > Have a look at: > http://bbs.archlinux.org/viewtopic.php?id=47390 > > According to the kernel configuration help, increasing the maximum number > of CPUs from 4 to 8 will make the kernel 32KB bigger with no performance > decrease. > > Opinions? I'd always rather these things go through the ML or a feature request, rather than a forum post. That way someone can actually trace the process. Sounds fine to me, although I don't think there is any point on i686 (who would run >4 cores there?). x86_64 makes sense though. -Dan
[arch-dev-public] 8 CPUs instead of 4? (was: kernel26 2.6.25-1 enters [testing])
Have a look at: http://bbs.archlinux.org/viewtopic.php?id=47390 According to the kernel configuration help, increasing the maximum number of CPUs from 4 to 8 will make the kernel 32KB bigger with no performance decrease. Opinions? signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] kernel26 2.6.25-1 enters [testing]
Travis Willard schrieb: On Sat, Apr 19, 2008 at 7:40 PM, Simo Leone <[EMAIL PROTECTED]> wrote: On Sat, Apr 19, 2008 at 06:09:08PM +0200, =?ISO-8859-1?Q?Thomas_B=E4chler_ wrote: > - aufs (Simo, could you have a look, you must probably update it) I'll fix this very soon. It just needs a hug. I'm going to update this to a later snapshot (aufs doesn't really do releases). That alright? > - catalyst Got this one, had to patch 2 or 3 lines due to some api changes in 2.6.25, no big deal (tm). Also updated it to 8.4 while I was at it. Holy crap you rule Simo. I have guests over this weekend and haven't really been able to look at it yet. Apparently, our fix does not work on x86_64, see the thread in the Desktop section of our forum. signature.asc Description: OpenPGP digital signature
[arch-dev-public] Drop the unstable repository
I had this thought during the above discussion about compat-wireless: Do we really need unstable? Almost nobody uses it and let's see which packages are in there: opera-devel firefox3 kernel26mm fvwm-devel gimp-devel reiser4progs + dependencies. openoffice-devel mplayer-svn Most of the rest is so out of date and old that it should be dropped anyway (including the external modules for kernel26mm). The packages that are actually being maintained can IMO be moved to extra. Everybody who installs a -svn or -devel package probably knows it is unstable (firefox3 should be renamed to firefox-devel then). So I'm asking you: What is the point of having a repository with <30 packages, half of which are neither used nor maintained? Except maybe confusion among users (wait? enable unstable? isn't that dangerous?). signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Database breakage - again!
Thomas Bächler schrieb: Okay, I am pissed right now. bzip2 (x86_64) had version 1.0.5-1 in the database, while the version in the package and the filename are 1.0.5-2. I tried to fix it, and found out what happened in the first place: [x86_64][17:21:[EMAIL PROTECTED] trunk]$ archrelease testing-x86_64 svnmerge: no integration info available ~/arch/repos/svn-packages/bzip2 ~/arch/repos/svn-packages/bzip2/trunk Nothing to commit ~/arch/repos/svn-packages/bzip2/trunk However, the PKGBUILD in testing-x86_64 was the old one. This is clearly a problem in the archrelease script. AND in our db scripts. I fixed it this time, however, people should actually look at the output of the scripts. It's not like we're monkeys. Here are all others: Inconsistency: firefox3 3.0b4-1 vs. firefox3-3.0b5-1-x86_64.pkg.tar.gz Inconsistency: bmpx 0.40.13-1 vs. bmpx-0.40.13-2-i686.pkg.tar.gz Inconsistency: bzr 1.3-1.1 vs. bzr-1.3-1-x86_64.pkg.tar.gz Inconsistency: darcs 1.0.9-1 vs. darcs-2.0.0-1-x86_64.pkg.tar.gz Inconsistency: pidgin 2.4.0-1 vs. pidgin-2.4.1-1-x86_64.pkg.tar.gz signature.asc Description: OpenPGP digital signature
[arch-dev-public] please help rebuilding (gnome) for i686
please someone with some time left rebuild packages for i686. difflist is getting a bit too long these days: http://dev.archlinux.org/~andyrtr/pkg_diff.html some of my packages depend on new gnome stuff. the build order should be in our public wiki and Jan also uses version related dependencies. so it shouldn't be that hard. thanks Andy
[arch-dev-public] Added b43-fwcutter to core
The bcm43xx driver is being replaced with b43 and b43legacy. bcm43xx will be removed in 2.6.26. Thus, I added b43-fwcutter to core. This replaces bcm43xx-fwcutter, which should be deleted when 2.6.26 is out. signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] kernel26 2.6.25-1 enters [testing]
Am Samstag, 19. April 2008 18:09:08 schrieb Thomas Bächler: > If there are any problems due to the configuration changes or new kernel > bugs, please let me know. I got the following error when using the nvidia driver: NVRM: bad caching on address 0x81007c91a000: actual 0x173 != expected 0x17b NVRM: please see the README section on Cache Aliasing for more information NVRM: bad caching on address 0x81007c91b000: actual 0x173 != expected 0x17b NVRM: bad caching on address 0x81007cbad000: actual 0x173 != expected 0x17b NVRM: bad caching on address 0x81007cbb4000: actual 0x173 != expected 0x17b NVRM: bad caching on address 0x81007cbb5000: actual 0x173 != expected 0x17b NVRM: bad caching on address 0x81007cbb6000: actual 0x173 != expected 0x17b NVRM: bad caching on address 0x81007cbb7000: actual 0x173 != expected 0x17b NVRM: bad caching on address 0x81007cbb8000: actual 0x173 != expected 0x17b NVRM: bad caching on address 0x81007cbb9000: actual 0x173 != expected 0x17b NVRM: bad caching on address 0x81007cbba000: actual 0x173 != expected 0x17b Even when using the 173.08 beta driver which is meant for kernel 2.6.25 I got the same errors. Any ideas? And here is the mentioned part of the README: Cache Aliasing Cache aliasing occurs when multiple mappings to a physical page of memory have conflicting caching states, such as cached and uncached. Due to these conflicting states, data in that physical page may become corrupted when the processor's cache is flushed. If that page is being used for DMA by a driver such as NVIDIA's graphics driver, this can lead to hardware stability problems and system lockups. NVIDIA has encountered bugs with some Linux kernel versions that lead to cache aliasing. Although some systems will run perfectly fine when cache aliasing occurs, other systems will experience severe stability problems, including random lockups. Users experiencing stability problems due to cache aliasing will benefit from updating to a kernel that does not cause cache aliasing to occur. NVIDIA has added driver logic to detect cache aliasing and to print a warning with a message similar to the following: NVRM: bad caching on address 0x1cdf000: actual 0x46 != expected 0x73 If you see this message in your log files and are experiencing stability problems, you should update your kernel to the latest version. If the message persists after updating your kernel, send a bug report to NVIDIA. -- archlinux.de
