[Mageia-dev] Fwd: Distress signal for resolving issue with Drakxnet tools
forwarded from mageia-discuss It would be great if someone mastering wireless network issues could at least have a look to the bug report. ---BeginMessage--- Hello, I send an ultimate distress signal about this : https://bugs.mageia.org/show_bug.cgi?id=2712 Once again I am having this bug that can occur on any WPA hotspot my laptops can connect to. But now, I cannot work in my development environment for more than one day because he refuses connect me to the hotspot I need to connect to. Since I got no answer since I opened the bug, as asked previously in this ML, I now cry for help about this. This seriously affects the work I have to complete everyday (I know I have the printer thing as well to answer and solve) and I just cannot do anything about this except really endangering my laptop currently, in the absence of progress concerning this extremely annoying bug. Tell me what I should do, I shall answer you very quickly and give the answers I am able to fetch if you tell me what is precisely needed. Thank you very much by advance. Thomas aka Skiper. ---End Message---
Re: [Mageia-dev] Fwd: Distress signal for resolving issue with Drakxnet tools
Le mercredi 12 octobre 2011 10:39:13, Samuel Verschelde a écrit : forwarded from mageia-discuss It would be great if someone mastering wireless network issues could at least have a look to the bug report. (sorry for the HTML formatting, kmail did it automatically because the forwarded message was in HTML too, and I didn't notice it before sending)
[Mageia-dev] [RFC] Change default scanning application for hplip
Hey there, i'd like to start a poll or request for comments to change the default scanning application for hplip. Currently for hplip the default would be xsane, and it also searches for kooka (which is deprecated and was replaced by skanlite IIRC) and for xscanimage, in that order. As in my opinion xsane is quite complicated and not user-friendly for scanning, i want to change the default to simple-scan, to improve the user experience. All the others are kept, maybe replacing kooka by skanlite, only simple-scan would then be first in search order. This should be done first for cauldron. Debian/*buntu has already changed their defaults (seems logical as simple-scan was developed by an Ubuntu developer). For more information on simple-scan, you might have a look at https://launchpad.net/simple-scan or http://en.wikipedia.org/wiki/Scanner_Access_Now_Easy#Simple_Scan Please give your opinions.
Re: [Mageia-dev] [RFC] Change default scanning application for hplip
On Wednesday 12 October 2011 11:59, Florian Hubold wrote: As in my opinion xsane is quite complicated and not user-friendly for scanning, i want to change the default to simple-scan, to improve the user experience. All the others are kept, maybe replacing kooka by skanlite, only simple-scan would then be first in search order. Sounds like a good idea. -- Johnny A. Solbu PGP key ID: 0xFA687324 signature.asc Description: This is a digitally signed message part.
[Mageia-dev] [RFC] nspluginwrapper should exclude native x86_64 plugins from wrapping
Hey there, currently nspluginwrapper tries to wrap x86_64 plugins (like native x86_64 flash player plugin), but there is only i386 npviewer which is needed to run the plugins. You can see the problem from the following output, which are a more verbose form of the scripts run through nspluginwrapper filetrigger: $ nspluginwrapper -v -i /usr/lib64/mozilla/plugins/libflashplayer.so *** NSPlugin Viewer *** ERROR: /usr/lib64/mozilla/plugins/libflashplayer.so: wrong ELF class: ELFCLASS64 nspluginwrapper: no appropriate viewer found for /usr/lib64/mozilla/plugins/libflashplayer.so In my and Anssi's opinion, nspluginwrapper.script (from nspluginwrapper filetrigger, http://svnweb.mageia.org/packages/cauldron/nspluginwrapper/current/SOURCES/nspluginwrapper.script?view=markup ) should be modified by excluding /usr/lib64. BTW the scripts run during nspluginwrapper installation/removal get it right by only using /usr/lib: http://svnweb.mageia.org/packages/cauldron/nspluginwrapper/current/SPECS/nspluginwrapper.spec?view=markup Anybody more knowledgeable on nspluginwrapper care to share his opinion, or are there other reasons for objections? Also are there good reasons to still use nspluginwraper for flash player at all, as all current browser support out-of-thread execution of plugins and flash-player-plugin is available as native i586 and x86_64 plugins?
Re: [Mageia-dev] [RFC] nspluginwrapper should exclude native x86_64 plugins from wrapping
On Wed, Oct 12, 2011 at 11:24, Florian Hubold doktor5...@arcor.de wrote: Hey there, currently nspluginwrapper tries to wrap x86_64 plugins (like native x86_64 flash player plugin), but there is only i386 npviewer which is needed to run the plugins. I'm quite sure we used to have the x86-64 version too You can see the problem from the following output, which are a more verbose form of the scripts run through nspluginwrapper filetrigger: $ nspluginwrapper -v -i /usr/lib64/mozilla/plugins/libflashplayer.so *** NSPlugin Viewer *** ERROR: /usr/lib64/mozilla/plugins/libflashplayer.so: wrong ELF class: ELFCLASS64 nspluginwrapper: no appropriate viewer found for /usr/lib64/mozilla/plugins/libflashplayer.so In my and Anssi's opinion, nspluginwrapper.script (from nspluginwrapper filetrigger, http://svnweb.mageia.org/packages/cauldron/nspluginwrapper/current/SOURCES/nspluginwrapper.script?view=markup ) should be modified by excluding /usr/lib64. BTW the scripts run during is nspluginwrapper installation/removal get it right by only using /usr/lib: http://svnweb.mageia.org/packages/cauldron/nspluginwrapper/current/SPECS/nspluginwrapper.spec?view=markup Anybody more knowledgeable on nspluginwrapper care to share his opinion, or are there other reasons for objections? It used to be a good way to separate plugin execution into another process which is good for security/stability but browsers include that feature now Also are there good reasons to still use nspluginwraper for flash player at all, as all current browser support out-of-thread execution of plugins and flash-player-plugin is available as native i586 and x86_64 plugins? Indeed it is now less useful
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release drupal-7.8-1.mga2
Le 12/10/2011 11:52, Mageia Team a écrit : - added patches for .htaccess and shebang removal patching is not the easiest way to do remove .htaccess files, and doesn't offer any garanty all relevant files are removed, especially as the software evolves. You'd better do it from the spec file directly: find . -name .htaccess | xargs rm -f -- BOFH excuse #116: the real ttys became pseudo ttys and vice-versa.
[Mageia-dev] Lazarus for qt
Hello! The package Lazarus in Cauldron only works on gtk2. For working with qt is neccesary to change the line of the file spec 'export LCL_PLATFORM=gtk2' to 'export LCL_PLATFORM=qt'. Find an example of file spec here: https://build.opensuse.org/package/view_file?file=lazarus-qt.specpackage=lazarus-qtproject=home%3Aenzokielsrcmd5=b56e9b13184ee7e052da6b0a562a0947 Afterwards, do what it is shown on the section Quick start guide for Linux of the website: http://wiki.lazarus.freepascal.org/Qt_Interface Which says: - To visit: http://users.telenet.be/Jan.Van.hijfte/qtforfpc/fpcqt4.html - To download: http://users.telenet.be/Jan.Van.hijfte/qtforfpc/V2.4/bin-qt4pas-V2.4_Qt4.5.3.tar.gz - To unpack: bin-qt4pas-V2.4_Qt4.5.3.tar.gz - To copy files to /usr/lib Lazarus QT is neccessary to pack Double Commander 0.5.1. Regards, Joaquin.
Re: [Mageia-dev] Lazarus for qt
Joaquin Mandriva a écrit : Hello! The package Lazarus in Cauldron only works on gtk2. For working with qt is neccesary to change the line of the file spec 'export LCL_PLATFORM=gtk2' to 'export LCL_PLATFORM=qt'. Find an example of file spec here: https://build.opensuse.org/package/view_file?file=lazarus-qt.specpackage=lazarus-qtproject=home%3Aenzokielsrcmd5=b56e9b13184ee7e052da6b0a562a0947 https://build.opensuse.org/package/view_file?file=lazarus-qt.specpackage=lazarus-qtproject=home%3Aenzokielsrcmd5=b56e9b13184ee7e052da6b0a562a0947 Afterwards, do what it is shown on the section Quick start guide for Linux of the website: http://wiki.lazarus.freepascal.org/Qt_Interface Which says: - To visit: http://users.telenet.be/Jan.Van.hijfte/qtforfpc/fpcqt4.html - To download: http://users.telenet.be/Jan.Van.hijfte/qtforfpc/V2.4/bin-qt4pas-V2.4_Qt4.5.3.tar.gz - To unpack: bin-qt4pas-V2.4_Qt4.5.3.tar.gz - To copy files to /usr/lib Lazarus QT is neccessary to pack Double Commander 0.5.1. Regards, Joaquin. You're suggesting to make a companion package that works with QT ? Or removing the gtk2 version ? -- André
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release drupal-7.8-1.mga2
Am Mittwoch, 12. Oktober 2011, 12:31:31 schrieb Guillaume Rousse: Le 12/10/2011 11:52, Mageia Team a écrit : - added patches for .htaccess and shebang removal patching is not the easiest way to do remove .htaccess files, and doesn't offer any garanty all relevant files are removed, especially as the software evolves. You'd better do it from the spec file directly: find . -name .htaccess | xargs rm -f I see now, my commit message wasn't quite clear... I didn't remove the .htacces by this patch. I patched some things inside the .htaccess and I added a patch to remove the shebang out of some scripts as it's done by Fedora. I will work on my commit messages in the future :/ Oliver
Re: [Mageia-dev] [RFC] nspluginwrapper should exclude native x86_64 plugins from wrapping
Can i take that as +1 to exclude flash-player-plugin from wrapping? I don't know the technical ins and outs but when 64 bit flash-player-plugin was updated to the native 64 bit flash it was necessary to first uninstall the 32 bit plugin. As we currently have no obvious way to let people know to do things like that, it could have caused problems for people. That obviously doesn't do anything to improve the Mageia experience, so a non technical +1 from me if that counts.
Re: [Mageia-dev] Fwd: Distress signal for resolving issue with Drakxnet tools
Le 12/10/2011 10:39, Samuel Verschelde a écrit : forwarded from mageia-discuss It would be great if someone mastering wireless network issues could at least have a look to the bug report. As for every other problem involving drakxtools (or any other configuration tool), it would help to test either manual wireless access, either with another configuration tool (network-manager comes to my mind) to distinguish between problems in configuration code and problems in actual connectivity tools. -- BOFH excuse #280: Traceroute says that there is a routing problem in the backbone. It's not our problem.
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release drupal-7.8-1.mga2
Le 12/10/2011 13:02, Oliver Burger a écrit : Am Mittwoch, 12. Oktober 2011, 12:31:31 schrieb Guillaume Rousse: Le 12/10/2011 11:52, Mageia Team a écrit : - added patches for .htaccess and shebang removal patching is not the easiest way to do remove .htaccess files, and doesn't offer any garanty all relevant files are removed, especially as the software evolves. You'd better do it from the spec file directly: find . -name .htaccess | xargs rm -f I see now, my commit message wasn't quite clear... I didn't remove the .htacces by this patch. I patched some things inside the .htaccess and I added a patch to remove the shebang out of some scripts as it's done by Fedora. That's not a proper practice to rely on multiple .htaccess files scattered among individual directories to configure an application when you have total control on apache configuration, you're supposed to use a unique apache configuration file: http://wiki.mandriva.com/en/Policies/Web_Applications#Configuration -- BOFH excuse #304: routing problems on the neural net
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release drupal-7.8-1.mga2
Am Mittwoch, 12. Oktober 2011, 13:30:21 schrieb Guillaume Rousse: That's not a proper practice to rely on multiple .htaccess files scattered among individual directories to configure an application when you have total control on apache configuration, you're supposed to use a unique apache configuration file: http://wiki.mandriva.com/en/Policies/Web_Applications#Configuration Guilty as charged. I did overread that part of the policy. Will fix it. Oliver
Re: [Mageia-dev] x11-server 1.11.0
'Twas brillig, and Thierry Vignaud at 11/10/11 19:45 did gyre and gimble: On 11 October 2011 09:59, Thierry Vignaud thierry.vign...@gmail.com wrote: Updated status: Updated status: = Tested (OK): Major video drivers : ati, intel Major input drivers: evdev, synaptics, wacom Untested: Major video drivers : fb[1], vesa[1], fglrx, nouveau, nvidia Somewhat less important drivers: virtualbox, vmware, qxl Minor video drivers: sis [1] used by the installer, tried in that order FWIW, I think there are still several packages not in testing... certainly my normal update process recommends several as potentially being available from release, but none from testing... Are more still needed to be bumped and pushed there? Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] TeamViewer under Cauldron x86_64
'Twas brillig, and Robert Fox at 11/10/11 08:51 did gyre and gimble: I can't seem to get TeamViewer to install: [oot@ThinkFox Downloads]# urpmi teamviewer_linux.rpm A requested package cannot be installed: teamviewer6-6.0.9258-1.i386 (due to unsatisfied libXdamage(x86-32)) Continue installation anyway? (Y/n) y [root@ThinkFox Downloads]# rpm -qa | grep libXdamage [root@ThinkFox Downloads]# urpmi libXdamage No package named libXdamage The following packages contain libXdamage: libxdamage-devel, libxdamage-static-devel, libxdamage1 You should use -a to use all of them [root@ThinkFox Downloads]# urpmi libXdamage1 Package libxdamage1-1.1.3-1.mga1.i586 is already installed [root@ThinkFox Downloads]# rpm -qa | grep libXdamage [root@ThinkFox Downloads]# updatedb [root@ThinkFox Downloads]# locate libXdamage /usr/lib/libXdamage.so.1 /usr/lib/libXdamage.so.1.1.0 /usr/lib64/libXdamage.la /usr/lib64/libXdamage.so /usr/lib64/libXdamage.so.1 /usr/lib64/libXdamage.so.1.1.0 [root@ThinkFox Downloads]# rpm -q --provides -f /usr/lib/libXdamage.so.1 But as others have said, the package being installed is simply not built with our deps in mind, so either create a dummy bridging package that requires our libxdamage1(x86-32) and provides libXdamange(x86-32) or just force the install. Col Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] Strange warnings during urpmi --auto-update -v
'Twas brillig, and Robert Fox at 10/10/11 14:14 did gyre and gimble: Note sure why I am getting this long list of errors during an update: perl: include /lib/module-init-tools/modprobe.compat is deprecated, please use /etc/modprobe.d : No such file or directory perl: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/. : Not a directory perl: include /lib/module-init-tools/modprobe.compat is deprecated, please use /etc/modprobe.d : No such file or directory perl: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/. : Not a directory perl: include /lib/module-init-tools/modprobe.compat is deprecated, please use /etc/modprobe.d : No such file or directory perl: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/. : Not a directory perl: include /lib/module-init-tools/modprobe.compat is deprecated, please use /etc/modprobe.d : No such file or directory perl: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/. : Not a directory perl: include /lib/module-init-tools/modprobe.compat is deprecated, please use /etc/modprobe.d : No such file or directory perl: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/. : Not a directory perl: include /lib/module-init-tools/modprobe.compat is deprecated, please use /etc/modprobe.d : No such file or directory perl: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/. : Not a directory perl: include /lib/module-init-tools/modprobe.compat is deprecated, please use /etc/modprobe.d : No such file or directory perl: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/. : Not a directory perl: include /lib/module-init-tools/modprobe.compat is deprecated, please use /etc/modprobe.d : No such file or directory perl: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/. : Not a directory perl: include /lib/module-init-tools/modprobe.compat is deprecated, please use /etc/modprobe.d : No such file or directory perl: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/. : Not a directory perl: include /lib/module-init-tools/modprobe.compat is deprecated, please use /etc/modprobe.d : No such file or directory perl: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/. : Not a directory perl: include /lib/module-init-tools/modprobe.compat is deprecated, please use /etc/modprobe.d : No such file or directory perl: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/. : Not a directory perl: include /lib/module-init-tools/modprobe.compat is deprecated, please use /etc/modprobe.d : No such file or directory perl: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/. : Not a directory perl: include /lib/module-init-tools/modprobe.compat is deprecated, please use /etc/modprobe.d : No such file or directory perl: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/. : Not a directory perl: include /lib/module-init-tools/modprobe.compat is deprecated, please use /etc/modprobe.d : No such file or directory perl: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/. : Not a directory perl: include /lib/module-init-tools/modprobe.compat is deprecated, please use /etc/modprobe.d : No such file or directory perl: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/. : Not a directory perl: include /lib/module-init-tools/modprobe.compat is deprecated, please use /etc/modprobe.d : No such file or directory perl: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/. : Not a directory perl: include /lib/module-init-tools/modprobe.compat is deprecated, please use /etc/modprobe.d : No such file or directory perl: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/. : Not a directory perl: include /lib/module-init-tools/modprobe.compat is deprecated, please use /etc/modprobe.d : No such file or directory perl: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/. : Not a directory defaulting background resolution to 1024x768 perl: include /lib/module-init-tools/modprobe.compat is deprecated, please use /etc/modprobe.d : No such file or directory perl: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/. : Not a directory perl: include /lib/module-init-tools/modprobe.compat is deprecated, please use /etc/modprobe.d : No such file or directory perl: Deprecated config file /etc/modprobe.conf, all config
Re: [Mageia-dev] x11-server 1.11.0
Colin Guthrie skrev 12.10.2011 15:37: 'Twas brillig, and Thierry Vignaud at 11/10/11 19:45 did gyre and gimble: On 11 October 2011 09:59, Thierry Vignaudthierry.vign...@gmail.com wrote: Updated status: Updated status: = Tested (OK): Major video drivers : ati, intel Major input drivers: evdev, synaptics, wacom Untested: Major video drivers : fb[1], vesa[1], fglrx, nouveau, nvidia Somewhat less important drivers: virtualbox, vmware, qxl Minor video drivers: sis [1] used by the installer, tried in that order FWIW, I think there are still several packages not in testing... certainly my normal update process recommends several as potentially being available from release, but none from testing... Are more still needed to be bumped and pushed there? Yeah. Thierry forgot to bump release before re-pushing to testing, so the same release is in both /release and /updates_testing for several rpms... I did a: urpmi --auto-update --media Core Updates Testing to work around it here. -- Thomas
Re: [Mageia-dev] x11-server 1.11.0
'Twas brillig, and Thomas Backlund at 12/10/11 13:49 did gyre and gimble: FWIW, I think there are still several packages not in testing... certainly my normal update process recommends several as potentially being available from release, but none from testing... Are more still needed to be bumped and pushed there? Yeah. Thierry forgot to bump release before re-pushing to testing, so the same release is in both /release and /updates_testing for several rpms... I did a: urpmi --auto-update --media Core Updates Testing to work around it here. Ahh right. I only did --searchmedia, not --media. Hey ho! Cheers Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] Lazarus for qt
Joaquin Mandriva a écrit : 2011/10/12 andre999 andre999...@laposte.net mailto:andre999...@laposte.net Joaquin Mandriva a écrit : Hello! The package Lazarus in Cauldron only works on gtk2. For working with qt is neccesary to change the line of the file spec 'export LCL_PLATFORM=gtk2' to 'export LCL_PLATFORM=qt'. Find an example of file spec here: https://build.opensuse.org/package/view_file?file=lazarus-qt.specpackage=lazarus-qtproject=home%3Aenzokielsrcmd5=b56e9b13184ee7e052da6b0a562a0947 https://build.opensuse.org/package/view_file?file=lazarus-qt.specpackage=lazarus-qtproject=home%3Aenzokielsrcmd5=b56e9b13184ee7e052da6b0a562a0947 https://build.opensuse.org/package/view_file?file=lazarus-qt.specpackage=lazarus-qtproject=home%3Aenzokielsrcmd5=b56e9b13184ee7e052da6b0a562a0947 https://build.opensuse.org/package/view_file?file=lazarus-qt.specpackage=lazarus-qtproject=home%3Aenzokielsrcmd5=b56e9b13184ee7e052da6b0a562a0947 Afterwards, do what it is shown on the section Quick start guide for Linux of the website: http://wiki.lazarus.freepascal.org/Qt_Interface Which says: - To visit: http://users.telenet.be/Jan.Van.hijfte/qtforfpc/fpcqt4.html - To download: http://users.telenet.be/Jan.Van.hijfte/qtforfpc/V2.4/bin-qt4pas-V2.4_Qt4.5.3.tar.gz - To unpack: bin-qt4pas-V2.4_Qt4.5.3.tar.gz - To copy files to /usr/lib Lazarus QT is neccessary to pack Double Commander 0.5.1. Regards, Joaquin. You're suggesting to make a companion package that works with QT ? Yes, it's necessary (for example) to pack Double Commander 0.5.1. http://doublecmd.sourceforge.net/ Following the various links from there, there is a gtk2 version of Double Commander 0.5.1 for Mandriva 2010.1 (called doublecmd-gtk) http://software.opensuse.org/download.html?project=home:Alexx2000package=doublecmd-gtk (Click the Mandriva icon.) It is in the official Mandriva repos. (i586, x86_64, and src.rpm packages) So it could be imported as an update. Unless of course you want to avoid gtk2. Since we are only talking about buildrequires between the Lazarus and Lazarus-qt, the difference is essentially requiring QT vs. resquiring gtk2. Regards, -- André
Re: [Mageia-dev] TeamViewer under Cauldron x86_64
Am 12.10.2011 14:41, schrieb Colin Guthrie: 'Twas brillig, and Robert Fox at 11/10/11 08:51 did gyre and gimble: I can't seem to get TeamViewer to install: [oot@ThinkFox Downloads]# urpmi teamviewer_linux.rpm A requested package cannot be installed: teamviewer6-6.0.9258-1.i386 (due to unsatisfied libXdamage(x86-32)) Continue installation anyway? (Y/n) y [root@ThinkFox Downloads]# rpm -qa | grep libXdamage [root@ThinkFox Downloads]# urpmi libXdamage No package named libXdamage The following packages contain libXdamage: libxdamage-devel, libxdamage-static-devel, libxdamage1 You should use -a to use all of them [root@ThinkFox Downloads]# urpmi libXdamage1 Package libxdamage1-1.1.3-1.mga1.i586 is already installed [root@ThinkFox Downloads]# rpm -qa | grep libXdamage [root@ThinkFox Downloads]# updatedb [root@ThinkFox Downloads]# locate libXdamage /usr/lib/libXdamage.so.1 /usr/lib/libXdamage.so.1.1.0 /usr/lib64/libXdamage.la /usr/lib64/libXdamage.so /usr/lib64/libXdamage.so.1 /usr/lib64/libXdamage.so.1.1.0 [root@ThinkFox Downloads]# rpm -q --provides -f /usr/lib/libXdamage.so.1 But as others have said, the package being installed is simply not built with our deps in mind, so either create a dummy bridging package that requires our libxdamage1(x86-32) and provides libXdamange(x86-32) or just force the install. Col Col Or maybe do like with skype and whip up a get-teamviewer package ...
[Mageia-dev] Tonight's meeting
Hi there Unless there are some topics to be discussed on IRC, there is no specific one for now that could not be managed by mail. So speak now or we cancel meeting for tonight :) Cheers -- Anne http://www.mageia.org
Re: [Mageia-dev] [RFC] Change default scanning application for hplip
On 12 October 2011 12:09, Johnny A. Solbu coo...@solbu.net wrote: As in my opinion xsane is quite complicated and not user-friendly for scanning, i want to change the default to simple-scan, to improve the user experience. All the others are kept, maybe replacing kooka by skanlite, only simple-scan would then be first in search order. Sounds like a good idea. It doesn't integrate within gimp
Re: [Mageia-dev] MANDATORY READ : 7 days before misc unleashes CERBERUS !
Le mercredi 12 octobre 2011 20:40:51, philippe makowski a écrit : 2011/9/14 Samuel Verschelde sto...@laposte.net: You may know it or not, many packages have no maintainer. If I do a mgarepo maintdb get | grep python- | grep nobody | wc -l I get 148 if nobody stand, may be I can take them but with the idea that if someone else than me touch these packages to maintain them, I will be pleased ;) or can we set up teams ? (answering on the mageia-dev list) Teams would not be a bad thing, I think we may have to set up them if we want some of the remaining unmaintained packages find maintainers. Until then (I don't know when we will have them), if you think you can maintain python packages, I sure won't cry if 148 packages find a maintainer :) Are there other packagers who would be interested in maintaining python packages within a group ? Samuel
[Mageia-dev] mageia 2 and systemd
Hi, how and when will we make the move ? should we need to provide native systemd service files for Mageia 2 ? some doc from Fedora for packaging : http://fedoraproject.org/wiki/Packaging:Guidelines:Systemd http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd
Re: [Mageia-dev] mageia 2 and systemd
On 12 October 2011 21:00, philippe makowski makowski.mag...@gmail.com wrote: how and when will we make the move ? should we need to provide native systemd service files for Mageia 2 ? Would you have tried to install Cauldron, you would know it's enabled by default.
Re: [Mageia-dev] mageia 2 and systemd
在 Thu, 13 Oct 2011 04:08:48 +0800, Thierry Vignaud thierry.vign...@gmail.com寫道: On 12 October 2011 21:00, philippe makowski makowski.mag...@gmail.com wrote: how and when will we make the move ? should we need to provide native systemd service files for Mageia 2 ? Would you have tried to install Cauldron, you would know it's enabled by default. I know colin had explained before, but my cauldron still lost sound in the last update and I got no idea how to get it back. Any idea, guys? I looked into /etc/pam.d and renamed system-auth.rpmnew to system-auth, but after doing so I still got no sound.
