Re: [arch-general] kde4 Okular + Hp Laserjet PCL 4/5 driver - prints greyscale inversed
Hey Don't know whether this is kde4 or the print drivers, but saving a google maps map as pdf and then printing in Okular using a HP Laserjet 4 via the HP Laserjet PCL 4/5 driver prints the maps in inverse greyscale (i.e. the whole page is black with the roads shown in white). I've checked the driver settings and regardless of whether you specify greyscale or color, the inverse printing is the same. Prints fine from windows. Where to file the bug? Print drivers or kde? You should try printing with GIMP. I believe it'll be the same. Samsung ML-2010 here and I get the same behaviour. Might be due to some filtering chains. As text printing works and I do graphic printing once a year, I didn't bother. Regards
Re: [arch-general] kde4 Okular + Hp Laserjet PCL 4/5 driver - prints greyscale inversed
On Sat, Jan 15, 2011 at 8:27 AM, David C. Rankin drankina...@suddenlinkmail.com wrote: Guys, Don't know whether this is kde4 or the print drivers, but saving a google maps map as pdf and then printing in Okular using a HP Laserjet 4 via the HP Laserjet PCL 4/5 driver prints the maps in inverse greyscale (i.e. the whole page is black with the roads shown in white). I've checked the driver settings and regardless of whether you specify greyscale or color, the inverse printing is the same. Prints fine from windows. Where to file the bug? Print drivers or kde? I believe you're seeing https://bugs.archlinux.org/task/21388. It has been fixed upstream, but a new ghostscript release hasn't been made and the fixes haven't been applied to Arch's package yet.
[arch-general] Vuze doesn't work after update
HI, I just updated Vuze bittorrent client to its latest version and now it doesn't run. I am using 64 bit arch and openjdk6. The output when I run vuze on the terminal is: $ vuze Starting Azureus... Suitable java version found [java = 1.6.0_20] Configuring environment... Java exec found in PATH. Verifying... Browser check failed with: Cannot load 32-bit SWT libraries on 64-bit JVM Auto-scanning for GRE/XULRunner. You can skip this by appending the GRE path to LD_LIBRARY_PATH and setting MOZILLA_FIVE_HOME. checking /usr/lib/xulrunner-devel-1.9.2 for GRE Can not use GRE from /usr/lib/xulrunner-devel-1.9.2 because it's missing libxpcom.so. checking /usr/lib/xulrunner-1.9.2 for GRE GRE found at /usr/lib/xulrunner-1.9.2. Browser check failed with: Could not initialize class org.eclipse.swt.widgets.Display Can't create browser. Will try to set LD_LIBRARY_PATH and hope Vuze has better luck. setting LD_LIBRARY_PATH to: /usr/lib/xulrunner-1.9.2 setting MOZILLA_FIVE_HOME to: /usr/lib/xulrunner-1.9.2 Loading Azureus: java -Xmx128m -cp ./Azureus2.jar:./swt.jar -Djava.library.path=/usr/share/vuze -Dazureus.install.path=/usr/share/vuze -Dazureus.script=/usr/bin/vuze -Dazureus.script.version=2 org.gudy.azureus2.ui.swt.Main file:/usr/share/vuze/Azureus2.jar ; file:/usr/share/vuze/swt.jar ; file:/usr/share/vuze/ changeLocale: *Default Language* != English (United States). Searching without country.. changeLocale: Searching for language English in *any* country.. changeLocale: no message properties for Locale 'English (United States)' (en_US), using 'English (default)' java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:532) at org.gudy.azureus2.ui.swt.Main.init(Main.java:114) at org.gudy.azureus2.ui.swt.Main.main(Main.java:292) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at com.aelitis.azureus.launcher.MainExecutor$1.run(MainExecutor.java:37) at java.lang.Thread.run(Thread.java:636) Caused by: java.lang.UnsatisfiedLinkError: Cannot load 32-bit SWT libraries on 64-bit JVM at org.eclipse.swt.internal.Library.loadLibrary(Library.java:197) at org.eclipse.swt.internal.Library.loadLibrary(Library.java:174) at org.eclipse.swt.internal.C.clinit(C.java:21) at org.eclipse.swt.internal.Converter.wcsToMbcs(Converter.java:63) at org.eclipse.swt.internal.Converter.wcsToMbcs(Converter.java:54) at org.eclipse.swt.widgets.Display.clinit(Display.java:132) at org.gudy.azureus2.ui.swt.mainwindow.SWTThread.init(SWTThread.java:84) at org.gudy.azureus2.ui.swt.mainwindow.SWTThread.createInstance(SWTThread.java:63) at com.aelitis.azureus.ui.swt.Initializer.init(Initializer.java:163) ... 12 more Exit from Azureus complete No shutdown tasks to do Azureus TERMINATED.
Re: [arch-general] sage-mathematics 4.6.1 in [community-testing]
On Sat, Jan 15, 2011 at 2:45 AM, Brad Fanella bradfane...@archlinux.us wrote: Signoff both architectures :-D P.S. I apologize if this actually starts a new thread on the mailing list. I wasn't subscribed to arch-general when you sent this message. and it did :)
Re: [arch-general] Vuze doesn't work after update
On Sat, Jan 15, 2011 at 9:47 AM, Madhurya Kakati mkakati2...@gmail.com wrote: HI, I just updated Vuze bittorrent client to its latest version and now it doesn't run. I am using 64 bit arch and openjdk6. The output when I run vuze on the terminal is: $ vuze Starting Azureus... Suitable java version found [java = 1.6.0_20] Configuring environment... Java exec found in PATH. Verifying... Browser check failed with: Cannot load 32-bit SWT libraries on 64-bit JVM Auto-scanning for GRE/XULRunner. You can skip this by appending the GRE path to LD_LIBRARY_PATH and setting MOZILLA_FIVE_HOME. checking /usr/lib/xulrunner-devel-1.9.2 for GRE Can not use GRE from /usr/lib/xulrunner-devel-1.9.2 because it's missing libxpcom.so. checking /usr/lib/xulrunner-1.9.2 for GRE GRE found at /usr/lib/xulrunner-1.9.2. Browser check failed with: Could not initialize class org.eclipse.swt.widgets.Display Can't create browser. Will try to set LD_LIBRARY_PATH and hope Vuze has better luck. setting LD_LIBRARY_PATH to: /usr/lib/xulrunner-1.9.2 setting MOZILLA_FIVE_HOME to: /usr/lib/xulrunner-1.9.2 Loading Azureus: java -Xmx128m -cp ./Azureus2.jar:./swt.jar -Djava.library.path=/usr/share/vuze -Dazureus.install.path=/usr/share/vuze -Dazureus.script=/usr/bin/vuze -Dazureus.script.version=2 org.gudy.azureus2.ui.swt.Main file:/usr/share/vuze/Azureus2.jar ; file:/usr/share/vuze/swt.jar ; file:/usr/share/vuze/ changeLocale: *Default Language* != English (United States). Searching without country.. changeLocale: Searching for language English in *any* country.. changeLocale: no message properties for Locale 'English (United States)' (en_US), using 'English (default)' java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:532) at org.gudy.azureus2.ui.swt.Main.init(Main.java:114) at org.gudy.azureus2.ui.swt.Main.main(Main.java:292) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at com.aelitis.azureus.launcher.MainExecutor$1.run(MainExecutor.java:37) at java.lang.Thread.run(Thread.java:636) Caused by: java.lang.UnsatisfiedLinkError: Cannot load 32-bit SWT libraries on 64-bit JVM at org.eclipse.swt.internal.Library.loadLibrary(Library.java:197) at org.eclipse.swt.internal.Library.loadLibrary(Library.java:174) at org.eclipse.swt.internal.C.clinit(C.java:21) at org.eclipse.swt.internal.Converter.wcsToMbcs(Converter.java:63) at org.eclipse.swt.internal.Converter.wcsToMbcs(Converter.java:54) at org.eclipse.swt.widgets.Display.clinit(Display.java:132) at org.gudy.azureus2.ui.swt.mainwindow.SWTThread.init(SWTThread.java:84) at org.gudy.azureus2.ui.swt.mainwindow.SWTThread.createInstance(SWTThread.java:63) at com.aelitis.azureus.ui.swt.Initializer.init(Initializer.java:163) ... 12 more Exit from Azureus complete No shutdown tasks to do Azureus TERMINATED. This is a known issue: https://bugs.archlinux.org/task/22432 FS#22432 - [vuze] 4.6 fails to start on x86_64 What's interesting is that I can't find a 64bit version of vuze anymore like there was with the older version. and what's more interesting is that I downloaded the file on a 64bit computer and still got the 32bit version. Is this an upstream problem?
Re: [arch-general] Vuze doesn't work after update
On Sat, Jan 15, 2011 at 10:02 AM, Thomas Dziedzic gos...@gmail.com wrote: On Sat, Jan 15, 2011 at 9:47 AM, Madhurya Kakati mkakati2...@gmail.com wrote: HI, I just updated Vuze bittorrent client to its latest version and now it doesn't run. I am using 64 bit arch and openjdk6. The output when I run vuze on the terminal is: $ vuze Starting Azureus... Suitable java version found [java = 1.6.0_20] Configuring environment... Java exec found in PATH. Verifying... Browser check failed with: Cannot load 32-bit SWT libraries on 64-bit JVM Auto-scanning for GRE/XULRunner. You can skip this by appending the GRE path to LD_LIBRARY_PATH and setting MOZILLA_FIVE_HOME. checking /usr/lib/xulrunner-devel-1.9.2 for GRE Can not use GRE from /usr/lib/xulrunner-devel-1.9.2 because it's missing libxpcom.so. checking /usr/lib/xulrunner-1.9.2 for GRE GRE found at /usr/lib/xulrunner-1.9.2. Browser check failed with: Could not initialize class org.eclipse.swt.widgets.Display Can't create browser. Will try to set LD_LIBRARY_PATH and hope Vuze has better luck. setting LD_LIBRARY_PATH to: /usr/lib/xulrunner-1.9.2 setting MOZILLA_FIVE_HOME to: /usr/lib/xulrunner-1.9.2 Loading Azureus: java -Xmx128m -cp ./Azureus2.jar:./swt.jar -Djava.library.path=/usr/share/vuze -Dazureus.install.path=/usr/share/vuze -Dazureus.script=/usr/bin/vuze -Dazureus.script.version=2 org.gudy.azureus2.ui.swt.Main file:/usr/share/vuze/Azureus2.jar ; file:/usr/share/vuze/swt.jar ; file:/usr/share/vuze/ changeLocale: *Default Language* != English (United States). Searching without country.. changeLocale: Searching for language English in *any* country.. changeLocale: no message properties for Locale 'English (United States)' (en_US), using 'English (default)' java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:532) at org.gudy.azureus2.ui.swt.Main.init(Main.java:114) at org.gudy.azureus2.ui.swt.Main.main(Main.java:292) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at com.aelitis.azureus.launcher.MainExecutor$1.run(MainExecutor.java:37) at java.lang.Thread.run(Thread.java:636) Caused by: java.lang.UnsatisfiedLinkError: Cannot load 32-bit SWT libraries on 64-bit JVM at org.eclipse.swt.internal.Library.loadLibrary(Library.java:197) at org.eclipse.swt.internal.Library.loadLibrary(Library.java:174) at org.eclipse.swt.internal.C.clinit(C.java:21) at org.eclipse.swt.internal.Converter.wcsToMbcs(Converter.java:63) at org.eclipse.swt.internal.Converter.wcsToMbcs(Converter.java:54) at org.eclipse.swt.widgets.Display.clinit(Display.java:132) at org.gudy.azureus2.ui.swt.mainwindow.SWTThread.init(SWTThread.java:84) at org.gudy.azureus2.ui.swt.mainwindow.SWTThread.createInstance(SWTThread.java:63) at com.aelitis.azureus.ui.swt.Initializer.init(Initializer.java:163) ... 12 more Exit from Azureus complete No shutdown tasks to do Azureus TERMINATED. This is a known issue: https://bugs.archlinux.org/task/22432 FS#22432 - [vuze] 4.6 fails to start on x86_64 What's interesting is that I can't find a 64bit version of vuze anymore like there was with the older version. and what's more interesting is that I downloaded the file on a 64bit computer and still got the 32bit version. Is this an upstream problem? BTW, I would like to continue this discussion on the bug webpage, not on the ml please. thanks.
Re: [arch-general] Vuze doesn't work after update
So what will I do now? Any way I can downgrade? I have lots of torrents on Vuze. On 1/15/11, Thomas Dziedzic gos...@gmail.com wrote: On Sat, Jan 15, 2011 at 10:02 AM, Thomas Dziedzic gos...@gmail.com wrote: On Sat, Jan 15, 2011 at 9:47 AM, Madhurya Kakati mkakati2...@gmail.com wrote: HI, I just updated Vuze bittorrent client to its latest version and now it doesn't run. I am using 64 bit arch and openjdk6. The output when I run vuze on the terminal is: $ vuze Starting Azureus... Suitable java version found [java = 1.6.0_20] Configuring environment... Java exec found in PATH. Verifying... Browser check failed with: Cannot load 32-bit SWT libraries on 64-bit JVM Auto-scanning for GRE/XULRunner. You can skip this by appending the GRE path to LD_LIBRARY_PATH and setting MOZILLA_FIVE_HOME. checking /usr/lib/xulrunner-devel-1.9.2 for GRE Can not use GRE from /usr/lib/xulrunner-devel-1.9.2 because it's missing libxpcom.so. checking /usr/lib/xulrunner-1.9.2 for GRE GRE found at /usr/lib/xulrunner-1.9.2. Browser check failed with: Could not initialize class org.eclipse.swt.widgets.Display Can't create browser. Will try to set LD_LIBRARY_PATH and hope Vuze has better luck. setting LD_LIBRARY_PATH to: /usr/lib/xulrunner-1.9.2 setting MOZILLA_FIVE_HOME to: /usr/lib/xulrunner-1.9.2 Loading Azureus: java -Xmx128m -cp ./Azureus2.jar:./swt.jar -Djava.library.path=/usr/share/vuze -Dazureus.install.path=/usr/share/vuze -Dazureus.script=/usr/bin/vuze -Dazureus.script.version=2 org.gudy.azureus2.ui.swt.Main file:/usr/share/vuze/Azureus2.jar ; file:/usr/share/vuze/swt.jar ; file:/usr/share/vuze/ changeLocale: *Default Language* != English (United States). Searching without country.. changeLocale: Searching for language English in *any* country.. changeLocale: no message properties for Locale 'English (United States)' (en_US), using 'English (default)' java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:532) at org.gudy.azureus2.ui.swt.Main.init(Main.java:114) at org.gudy.azureus2.ui.swt.Main.main(Main.java:292) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at com.aelitis.azureus.launcher.MainExecutor$1.run(MainExecutor.java:37) at java.lang.Thread.run(Thread.java:636) Caused by: java.lang.UnsatisfiedLinkError: Cannot load 32-bit SWT libraries on 64-bit JVM at org.eclipse.swt.internal.Library.loadLibrary(Library.java:197) at org.eclipse.swt.internal.Library.loadLibrary(Library.java:174) at org.eclipse.swt.internal.C.clinit(C.java:21) at org.eclipse.swt.internal.Converter.wcsToMbcs(Converter.java:63) at org.eclipse.swt.internal.Converter.wcsToMbcs(Converter.java:54) at org.eclipse.swt.widgets.Display.clinit(Display.java:132) at org.gudy.azureus2.ui.swt.mainwindow.SWTThread.init(SWTThread.java:84) at org.gudy.azureus2.ui.swt.mainwindow.SWTThread.createInstance(SWTThread.java:63) at com.aelitis.azureus.ui.swt.Initializer.init(Initializer.java:163) ... 12 more Exit from Azureus complete No shutdown tasks to do Azureus TERMINATED. This is a known issue: https://bugs.archlinux.org/task/22432 FS#22432 - [vuze] 4.6 fails to start on x86_64 What's interesting is that I can't find a 64bit version of vuze anymore like there was with the older version. and what's more interesting is that I downloaded the file on a 64bit computer and still got the 32bit version. Is this an upstream problem? BTW, I would like to continue this discussion on the bug webpage, not on the ml please. thanks. -- Sent from my mobile device
Re: [arch-general] Vuze doesn't work after update
On Sat, 2011-01-15 at 22:28 +0530, Madhurya Kakati wrote: So what will I do now? Any way I can downgrade? I have lots of torrents on Vuze. On 1/15/11, Thomas Dziedzic gos...@gmail.com wrote: On Sat, Jan 15, 2011 at 10:02 AM, Thomas Dziedzic gos...@gmail.com wrote: On Sat, Jan 15, 2011 at 9:47 AM, Madhurya Kakati mkakati2...@gmail.com wrote: HI, I just updated Vuze bittorrent client to its latest version and now it doesn't run. I am using 64 bit arch and openjdk6. The output when I run vuze on the terminal is: $ vuze Starting Azureus... Suitable java version found [java = 1.6.0_20] Configuring environment... Java exec found in PATH. Verifying... Browser check failed with: Cannot load 32-bit SWT libraries on 64-bit JVM Auto-scanning for GRE/XULRunner. You can skip this by appending the GRE path to LD_LIBRARY_PATH and setting MOZILLA_FIVE_HOME. checking /usr/lib/xulrunner-devel-1.9.2 for GRE Can not use GRE from /usr/lib/xulrunner-devel-1.9.2 because it's missing libxpcom.so. checking /usr/lib/xulrunner-1.9.2 for GRE GRE found at /usr/lib/xulrunner-1.9.2. Browser check failed with: Could not initialize class org.eclipse.swt.widgets.Display Can't create browser. Will try to set LD_LIBRARY_PATH and hope Vuze has better luck. setting LD_LIBRARY_PATH to: /usr/lib/xulrunner-1.9.2 setting MOZILLA_FIVE_HOME to: /usr/lib/xulrunner-1.9.2 Loading Azureus: java -Xmx128m -cp ./Azureus2.jar:./swt.jar -Djava.library.path=/usr/share/vuze -Dazureus.install.path=/usr/share/vuze -Dazureus.script=/usr/bin/vuze -Dazureus.script.version=2 org.gudy.azureus2.ui.swt.Main file:/usr/share/vuze/Azureus2.jar ; file:/usr/share/vuze/swt.jar ; file:/usr/share/vuze/ changeLocale: *Default Language* != English (United States). Searching without country.. changeLocale: Searching for language English in *any* country.. changeLocale: no message properties for Locale 'English (United States)' (en_US), using 'English (default)' java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:532) at org.gudy.azureus2.ui.swt.Main.init(Main.java:114) at org.gudy.azureus2.ui.swt.Main.main(Main.java:292) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at com.aelitis.azureus.launcher.MainExecutor$1.run(MainExecutor.java:37) at java.lang.Thread.run(Thread.java:636) Caused by: java.lang.UnsatisfiedLinkError: Cannot load 32-bit SWT libraries on 64-bit JVM at org.eclipse.swt.internal.Library.loadLibrary(Library.java:197) at org.eclipse.swt.internal.Library.loadLibrary(Library.java:174) at org.eclipse.swt.internal.C.clinit(C.java:21) at org.eclipse.swt.internal.Converter.wcsToMbcs(Converter.java:63) at org.eclipse.swt.internal.Converter.wcsToMbcs(Converter.java:54) at org.eclipse.swt.widgets.Display.clinit(Display.java:132) at org.gudy.azureus2.ui.swt.mainwindow.SWTThread.init(SWTThread.java:84) at org.gudy.azureus2.ui.swt.mainwindow.SWTThread.createInstance(SWTThread.java:63) at com.aelitis.azureus.ui.swt.Initializer.init(Initializer.java:163) ... 12 more Exit from Azureus complete No shutdown tasks to do Azureus TERMINATED. This is a known issue: https://bugs.archlinux.org/task/22432 FS#22432 - [vuze] 4.6 fails to start on x86_64 What's interesting is that I can't find a 64bit version of vuze anymore like there was with the older version. and what's more interesting is that I downloaded the file on a 64bit computer and still got the 32bit version. Is this an upstream problem? BTW, I would like to continue this discussion on the bug webpage, not on the ml please. thanks. Well first don't panic, second go and do some research instead of being a help vampire. https://wiki.archlinux.org/index.php/Downgrade -- Jelle van der Waa
Re: [arch-general] [arch-dev-public] adding hunspell-xx packages
Added Hunspell and Thesaurus packages for Portuguese (European) to the AUR. http://aur.archlinux.org/packages.php?ID=45431 http://aur.archlinux.org/packages.php?ID=45430 http://aur.archlinux.org/packages.php?ID=45432 -- Mauro Santos
[arch-general] umask gnome
Dear Everyone, I would like to have a system-wide umask settings. If I create eg a directory with mkdir everything is fine, however if I create a directory using Nautilus or even Midnight Commander using Gnome Terminal the file permission settings are different from my .bashrc definition I put .bashrc and /etc/profiles the follwoing line: umask 077 I tried to put it to /etc/gdm/Xsession, I created .gnomerc but nothing. Is it even possible to set a system-wide umask settings?
[arch-general] root on NFS and archlinux init scripts
Hi all, one of my systems is booting over PXE and running diskless. The root-filesystem is mounted over NFS by the kernel (with the help of the net-hook in initcpio). On shutdown there is a message '/: device is busy'. I found out, that this is originated by the netfs-script in /etc/rc.d. It tries to umount everything on the network. By removing this hook the warning went away. I think this is not as meant. Its not a critical error, only a warning, because of that i would hear you opinion on that. Additionally i discoverd following piece of code in rc.shutdown: stat_busy Unmounting Filesystems /bin/umount -a -r -t noramfs,notmpfs,nosysfs,noproc,nodevtmpfs -O no_netdev stat_done Here, only non-network filesystems are unmounted, right? So, an NFS-root is not unmounted on shutdown. That is not good, i think it should be looked for a solution. What do you think? Would be nice to hear from you. Greetings Thomas Bahn Here are my settings related with nfs: kernel-parameter: rootfstype=nfs root=/dev/nfs nfsroot=192.168.1.2:/srv/nfs/erich,v3,rsize=16384,wsize=16384 ip=dhcp /etc/fstab entry for the root: none / none /etc/rc.conf: NETWORK_PERSIST = yes /etc/mkinitcpio.conf: MODULES=nfs HOOKS=base udev autodetect net filesystems
Re: [arch-general] root on NFS and archlinux init scripts
Am 15.01.2011 21:13, schrieb Thomas Bahn: On shutdown there is a message '/: device is busy'. I found out, that this is originated by the netfs-script in /etc/rc.d. It tries to umount everything on the network. By removing this hook the warning went away. I think this is not as meant. Its not a critical error, only a warning, because of that i would hear you opinion on that. This is known. If you have ideas, they are welcome. I only tested whether NFS root works in general, but I never figured out all the small problems. Additionally i discoverd following piece of code in rc.shutdown: stat_busy Unmounting Filesystems /bin/umount -a -r -t noramfs,notmpfs,nosysfs,noproc,nodevtmpfs -O no_netdev stat_done Here, only non-network filesystems are unmounted, right? So, an NFS-root is not unmounted on shutdown. That is not good, i think it should be looked for a solution. You cannot unmount the root file system. It should remount it read-only at a later stage though. I don't think umounting is NFS even necessary, is there a problem when you don't? What do you think? Would be nice to hear from you. I'll accept any improvements in that area, but I never used NFS root with Arch for more than basic testing. signature.asc Description: OpenPGP digital signature
Re: [arch-general] root on NFS and archlinux init scripts
On 15.01.2011 21:13, Thomas Bahn wrote:
/etc/rc.conf:
NETWORK_PERSIST = yes
With the spaces that should cause an error.
--
Florian Pritz -- {flo,bluewind}@server-speed.net
signature.asc
Description: OpenPGP digital signature
Re: [arch-general] root on NFS and archlinux init scripts
Am Samstag 15 Januar 2011, 21:32:23 schrieb Thomas Bächler: Am 15.01.2011 21:13, schrieb Thomas Bahn: On shutdown there is a message '/: device is busy'. I found out, that this is originated by the netfs-script in /etc/rc.d. It tries to umount everything on the network. By removing this hook the warning went away. I think this is not as meant. Its not a critical error, only a warning, because of that i would hear you opinion on that. This is known. If you have ideas, they are welcome. I will try to fix it properly. I only tested whether NFS root works in general, but I never figured out all the small problems. Additionally i discoverd following piece of code in rc.shutdown: stat_busy Unmounting Filesystems /bin/umount -a -r -t noramfs,notmpfs,nosysfs,noproc,nodevtmpfs -O no_netdev stat_done Here, only non-network filesystems are unmounted, right? So, an NFS-root is not unmounted on shutdown. That is not good, i think it should be looked for a solution. You cannot unmount the root file system. It should remount it read-only at a later stage though. Ok, i did not know this. I assumed it will be unmounted because otherwise there will be an filesystem check on next start. I don't think umounting is NFS even necessary, is there a problem when you don't? Mh, i do not know. I thought some caches are written out when unmounting. But i will google for it ;) What do you think? Would be nice to hear from you. I'll accept any improvements in that area, but I never used NFS root with Arch for more than basic testing. How i can contribute to the initscripts? Should i mail an patch to this list?
Re: [arch-general] root on NFS and archlinux init scripts
Am Samstag 15 Januar 2011, 21:42:24 schrieb Florian Pritz: On 15.01.2011 21:13, Thomas Bahn wrote: /etc/rc.conf: NETWORK_PERSIST = yes With the spaces that should cause an error. My fault ;) I did not do copy and paste. in the real rc.conf there are no spaces.
Re: [arch-general] Ye Olde Package Manager
On 01/13/2011 12:12 PM, C Anthony Risinger wrote: leverage a revisioning system for package files instead of tarballs, even if only locally. store metadata in a non-relational engine like couchdb (peer replicaition), or at least something like sqlite, for sane access. A relational engine is actually really helpful for packages. A while ago I tried writing a package manager like pacman but using sqlite, and it's MUCH faster and still easy to use. The huge pauses every time you need metadata are incredibly annoying, and they completely disappear when you store things in a real database. The problem is that it has to be used by the official package manager, because having package data stored in two formats causes issues (because any time you use pacman, the other database doesn't know what changed). Revisioning package files is also interesting; I don't see the point of doing it locally though. Once you have the package, installing it is fast. Checking if files are the same first seems like a waste of effort. There already is a mechanism for creating those .pacnew files (and I think auto-merging those into the existing file would mess with the knowing what your system is doing part of Arch). Using deltas for packages would be helpful though, especially in the case of huge packages with minor changes. The rest of your changes sound like things that would make packaging harder, and you should know that some (most?) of us like Arch's packages because they're easy to make. It make seem overly simple, but that's exactly what I want out of a package: Give a name, version number, source, and dependencies, then the commands I'd use to build it, and I'm done. If Arch every became like Debian with it's fancy, huge-time-sink packaging, I'd find a different distro.
Re: [arch-general] Ye Olde Package Manager
On 16/01/11 07:34, Brendan Long wrote: On 01/13/2011 12:12 PM, C Anthony Risinger wrote: leverage a revisioning system for package files instead of tarballs, even if only locally. store metadata in a non-relational engine like couchdb (peer replicaition), or at least something like sqlite, for sane access. A relational engine is actually really helpful for packages. A while ago I tried writing a package manager like pacman but using sqlite, and it's MUCH faster and still easy to use. The huge pauses every time you need metadata are incredibly annoying, and they completely disappear when you store things in a real database. The problem is that it has to be used by the official package manager, because having package data stored in two formats causes issues (because any time you use pacman, the other database doesn't know what changed). It is not so much having the data in a real database, but not having it spread over hundreds of small files. This has been largely fixed in the developmental branch of pacman, which is a lot faster. It could probably be improved further, but the complaints to patches ratio is really poor. Revisioning package files is also interesting; I don't see the point of doing it locally though. Once you have the package, installing it is fast. Checking if files are the same first seems like a waste of effort. There already is a mechanism for creating those .pacnew files (and I think auto-merging those into the existing file would mess with the knowing what your system is doing part of Arch). Using deltas for packages would be helpful though, especially in the case of huge packages with minor changes. Using binary deltas has been available in pacman for ages. Arch just does not use them... Allan
[arch-general] Syslinux Installer / Update Script - Testers Needed
Hello Community, Over the last few weeks I have been working on Syslinux support for the installer. With the help Thomas and Dieter I am nearing the completion of this project. As part of this project, I have written a script that will help install and update Syslinux (similar to that of grub-install). Some key features of the script: syslinux-install_update.sh * Install Syslinux to the FS + Partition Boot Loader (extlinux --install /boot/syslinux) * Install Syslinux MBR * Detect and optionally set the boot flag on the boot partition * Update Syslinux – copy files and execute (extilnux --update /boot/syslinux) * Support for GPT disks * Support for RAID configurations The goal is to include this script in the official Syslinux package. Therefore we need your help to test it. syslinux-install_update.sh -i -a -m . install Syslinux, set the boot flag (if needed), and install the MBR We need tests for the following setups: / + /boot on the *same* partition / + /boot on the *same* partition - RAID /boot + root on *separate* partition /boot + root on *separate* partition - RAID All of the above using but using the GPT partition layout NOTE: This is an alpha/beta stage script. The script modifies the first 440 bytes of the disk (using dd) and the partition table (using either sfdisk or sgdisk). Although the script should be safe to run, I am not responsible for any data loss that may occur. Let us know the following: * Did the script work for you? * What was your partition setup? (see above) * What version did you use? * If the script did not work, please provide as much information as possible Get the script here: https://gist.github.com/772138 Syslinux Sample Config File: http://projects.archlinux.org/svntogit/packages.git/plain/syslinux/trunk/syslinux.cfg The Syslinux package in testing includes the above configuration file. Cheers, pyther
Re: [arch-general] [arch-releng] Syslinux Installer / Update Script - Testers Needed
On 01/15/11 at 09:52pm, Matthew Gyurgyik wrote: Hello Community, Over the last few weeks I have been working on Syslinux support for the installer. With the help Thomas and Dieter I am nearing the completion of this project. As part of this project, I have written a script that will help install and update Syslinux (similar to that of grub-install). Some key features of the script: syslinux-install_update.sh * Install Syslinux to the FS + Partition Boot Loader (extlinux --install /boot/syslinux) * Install Syslinux MBR * Detect and optionally set the boot flag on the boot partition * Update Syslinux – copy files and execute (extilnux --update /boot/syslinux) * Support for GPT disks * Support for RAID configurations The goal is to include this script in the official Syslinux package. Therefore we need your help to test it. syslinux-install_update.sh -i -a -m . install Syslinux, set the boot flag (if needed), and install the MBR We need tests for the following setups: / + /boot on the *same* partition / + /boot on the *same* partition - RAID /boot + root on *separate* partition /boot + root on *separate* partition - RAID All of the above using but using the GPT partition layout NOTE: This is an alpha/beta stage script. The script modifies the first 440 bytes of the disk (using dd) and the partition table (using either sfdisk or sgdisk). Although the script should be safe to run, I am not responsible for any data loss that may occur. Let us know the following: * Did the script work for you? * What was your partition setup? (see above) * What version did you use? * If the script did not work, please provide as much information as possible Get the script here: https://gist.github.com/772138 Syslinux Sample Config File: http://projects.archlinux.org/svntogit/packages.git/plain/syslinux/trunk/syslinux.cfg The Syslinux package in testing includes the above configuration file. Cheers, pyther I've got an old box i use as a testing box.. I'll give it a shot tomorrow on it and in qemu pgpzWG95C1POf.pgp Description: PGP signature
[arch-general] makepkg --source makes empty folder src
Why makepkg --source makes empty folder src? Is it necessary?
Re: [arch-general] umask gnome
On Sat, Jan 15, 2011 at 10:11 PM, Béla Vizer bela.vi...@gmail.com wrote: I put .bashrc and /etc/profiles the follwoing line: umask 077 I tried to put it to /etc/gdm/Xsession, I created .gnomerc but nothing. Is it even possible to set a system-wide umask settings? Put it in ~/.bashrc, before the following line: [ -z $PS1 ] return
Re: [arch-general] makepkg --source makes empty folder src
On Sun, 2011-01-16 at 14:53 +1000, Joker-jar wrote: Why makepkg --source makes empty folder src? Is it necessary? man makepkg Search for the term '--source'
Re: [arch-general] makepkg --source makes empty folder src
On 16/01/11 14:53, Joker-jar wrote: Why makepkg --source makes empty folder src? Is it necessary? It is only empty if your PKGBUILD has no source files, which would make using makepkg --source a bit of a waste of time given it just tars up the PKGBUILD...
