[Mageia-dev] Fwd: [Mageia-discuss] Fwd: [FOSDEM] Call for stands, devroom talks and lightning talks
FYI: Originele bericht Onderwerp: [Mageia-discuss] Fwd: [FOSDEM] Call for stands, devroom talks and lightning talks Datum: Tue, 22 Nov 2011 09:52:57 +0100 Van:Romain d'Alverny r...@mageia.org Antwoord-naar: Mageia general discussions mageia-disc...@mageia.org Aan:Mageia general discussions mageia-disc...@mageia.org Hi guys, FOSDEM is calling! (4-5 February, in Brussels, Belgium) And this will be the time: - we meet Europe-wide (and more); - we can handle a booth to demonstrate Mageia; - lots of cool people and cool talks happen to happen; - we hold our annual general assembly (with a moral and financial report); - 1/3rd of the board is renewed - there are 6 board members, so that makes for 2 people to be elected among current Council members; see https://wiki.mageia.org/en/Org#Mageia_Board - council should be re-elected (that is, team leaders re-elected). So. - who will be there? (I will) - who would like to act there as a Mageia member? (booth, conference) - what do we need? Romain -- Message transféré -- De : Mattiasapos;Tiasapos; Gunsmg...@fosdem.org Date : 16 nov. 2011 10:53 Objet : [FOSDEM] Call for stands, devroom talks and lightning talks À : Fosdem Announcefos...@lists.fosdem.org Dear Hackers, We hereby invite any and all open source projects to participate in FOSDEM 2012 by manning a stand for the weekend, by giving a talk in a devroom or by giving a 15 minute talk in our lightning talk room. See http://fosdem.org/2012/call-for-participation on how to submit proposals. * Manning a stand We offer open source projects a place for a stand in the hallways. Stands can be used to share information, demo software, sell merchandising, give away goodies and so forth. Stands allow projects to present themselves to the visitors in a more personal fashion. See http://fosdem.org/2012/call-for-stands for more details * Talking in a devroom We will be hosting 25 (!) different devrooms, covering a broader spectrum of the open source landscape than any year before. The accepted devrooms are: Ada -- BSD licensed operating systems -- Configuration and Systems Management -- Cross Desktop -- Distribution Miniconf -- Embedded -- Free Java -- Graph Processing -- Hardware Security and Cryptography -- JBoss.org -- Legal Issues -- LibreOffice -- Mono -- Mozilla -- Multiserver -- microkernel-based operating systems -- MySQL and Friends -- Open Mobile Linux -- Open Source Game Development -- Open Source Telephony -- Open Source Virtualization and Cloud -- Perl -- PostgreSQL -- Smalltalk -- World of GNUstep -- X.org and OpenICC See http://fosdem.org/2012/call-for-participation for the list of announcements or contact devro...@fosdem.org for a contact address. * Lightning talks We have a special lightning talk room for all remaining open source projects that do not fit in any of the devrooms. Lightning talks are short 15 minute focussed talks in which one person gets to present the project or an aspect of it. See http://fosdem.org/2012/call-for-lightningtalks for more details. FOSDEM is organized by and for the community, non-commercial and highly developer-oriented. Its goal is to provide Free and Open Source developers a place to meet. Now is the time to become part of it. The FOSDEM organizers. ___ FOSDEM mailing list fos...@lists.fosdem.org https://lists.fosdem.org/listinfo/fosdem -- Romain d'Alverny http://mageia.org/ board council member
Re: [Mageia-dev] Proposition to drop the package pastebin from Mageia
On 24.11.2011 00:36, andre999 wrote: Kamil Rytarowski a écrit : Hello! As a maintainer of pastebin ( http://raphael.slinckx.net/files/ )my proposition is to drop it, because: - it's redundand for betternewermore featured wgetpaste - it doesn't seem to be updated upstream for years I can maintain it, but I would like to know that someone it really needs. I don't see any rational reason to ship it - wgetpaste fully supercedes it. In its place (or next to it) I've imported susepaste. It's well supported upstream and also supports screenshot (of a single window or full-screen) paste feature. In general that sounds good. Being only a user of pastebins, I have some concerns about flexibility of the width. Normally when using a pastebin, one wants to make reference to another window. Having a pastebin with flexible width is a big plus. (Like the old wiki.) The reference you give redirects to dpaste.com, which wastes width on the large left margin, as well as the fixed width of the body. (dpaste.com is better than pastebin.com, which has a much larger fixed width.) A much better pastebin is Lodgit (paste.pocoo.org), which has small left/right margins, and fully flexible width. Another plus is a large number of file types. (Conveniently ranged in alphabetical order.) They list the software used for their site at http://paste.pocoo.org/about/ (near the bottom of the page). Thank you for your feedback! wgetpaste supports multiple pastebins, the result of the -S command is: $ wgetpaste -S Services supported: (case sensitive): Name:| Url: =|= ca | http://pastebin.ca/ codepad | http://codepad.org/ dpaste | http://dpaste.com/ osl | http://pastebin.osuosl.org/ *pocoo | http://paste.pocoo.org/ And pastebin supports http://en.pastebin.ca/ I don't know how that compares to wgetpaste or susepaste, but thought you might like to consider it. I'm not sure Fedora Paste or openSUSE Paste are better than the previous ones, but I would ship them (and I will maintain them), because of the constant support from the upstream. + the handy screenshot feature from openSUSE! Regards :)
Re: [Mageia-dev] Proposition to drop the package pastebin from Mageia
2011/11/24 Kamil Rytarowski n...@gmx.com On 24.11.2011 00:36, andre999 wrote: Kamil Rytarowski a écrit : Hello! As a maintainer of pastebin ( http://raphael.slinckx.net/**files/http://raphael.slinckx.net/files/)my proposition is to drop it, because: - it's redundand for betternewermore featured wgetpaste - it doesn't seem to be updated upstream for years I can maintain it, but I would like to know that someone it really needs. I don't see any rational reason to ship it - wgetpaste fully supercedes it. In its place (or next to it) I've imported susepaste. It's well supported upstream and also supports screenshot (of a single window or full-screen) paste feature. In general that sounds good. Being only a user of pastebins, I have some concerns about flexibility of the width. Normally when using a pastebin, one wants to make reference to another window. Having a pastebin with flexible width is a big plus. (Like the old wiki.) The reference you give redirects to dpaste.com, which wastes width on the large left margin, as well as the fixed width of the body. (dpaste.com is better than pastebin.com, which has a much larger fixed width.) A much better pastebin is Lodgit (paste.pocoo.org), which has small left/right margins, and fully flexible width. Another plus is a large number of file types. (Conveniently ranged in alphabetical order.) They list the software used for their site at http://paste.pocoo.org/about/ (near the bottom of the page). Thank you for your feedback! wgetpaste supports multiple pastebins, the result of the -S command is: $ wgetpaste -S Services supported: (case sensitive): Name:| Url: =|= ca | http://pastebin.ca/ codepad | http://codepad.org/ dpaste | http://dpaste.com/ osl | http://pastebin.osuosl.org/ *pocoo | http://paste.pocoo.org/ And pastebin supports http://en.pastebin.ca/ I don't know how that compares to wgetpaste or susepaste, but thought you might like to consider it. I'm not sure Fedora Paste or openSUSE Paste are better than the previous ones, but I would ship them (and I will maintain them), because of the constant support from the upstream. + the handy screenshot feature from openSUSE! Regards :) Now we need pastebin.mageia.org :)
[Mageia-dev] ffmpeg in mageia1 updates testing (revision 171164)
To Funda : you modified the spec file of ffmpeg : disable x264 support as x264 is too old in mageia 1 This may induce a regression (a missing feature) Why not to update libx264 before updating ffmpeg, and by this way allow to keep x264 support enabled ? Is there a problem for other programs depending on libx264 if you update it ? (need to rebuild them ?) Regards Philippe
Re: [Mageia-dev] ffmpeg in mageia1 updates testing (revision 171164)
Yes, new x264 introduces new libmajor, which requires a mass rebuilding of other packages. 2011/11/24 Philippe DIDIER philippedid...@laposte.net: To Funda : you modified the spec file of ffmpeg : disable x264 support as x264 is too old in mageia 1 This may induce a regression (a missing feature) Why not to update libx264 before updating ffmpeg, and by this way allow to keep x264 support enabled ? Is there a problem for other programs depending on libx264 if you update it ? (need to rebuild them ?) Regards Philippe
Re: [Mageia-dev] ffmpeg in mageia1 updates testing (revision 171164)
Funda Wang skrev 24.11.2011 14:26: Yes, new x264 introduces new libmajor, which requires a mass rebuilding of other packages. Then the ffmpeg update must be fixed. Either only backport the needed fixes, or fix the build with current x264. It's not allowed to push updates that breaks/disables current features. This is _exactly_ why we have the policy to backport fixes and not blindly update to newer versions. -- Thomas 2011/11/24 Philippe DIDIERphilippedid...@laposte.net: To Funda : you modified the spec file of ffmpeg : disable x264 support as x264 is too old in mageia 1 This may induce a regression (a missing feature) Why not to update libx264 before updating ffmpeg, and by this way allow to keep x264 support enabled ? Is there a problem for other programs depending on libx264 if you update it ? (need to rebuild them ?) Regards Philippe
Re: [Mageia-dev] ffmpeg in mageia1 updates testing (revision 171164)
Funda Wang a écrit : Yes, new x264 introduces new libmajor, which requires a mass rebuilding of other packages. 2011/11/24 Philippe DIDIER philippedid...@laposte.net: To Funda : you modified the spec file of ffmpeg : disable x264 support as x264 is too old in mageia 1 This may induce a regression (a missing feature) Why not to update libx264 before updating ffmpeg, and by this way allow to keep x264 support enabled ? Is there a problem for other programs depending on libx264 if you update it ? (need to rebuild them ?) Regards Philippe heavy dilemma ! heavy choice ! - let ffmpeg not updated (with x264 support but with security problem) - update ffmpeg disabling x264 support - update ffmpeg keeping x264 support but need to rebuild mass of packages (not alone ) and provide lots of updated rpms to QA !
Re: [Mageia-dev] ffmpeg in mageia1 updates testing (revision 171164)
Philippe DIDIER skrev 24.11.2011 14:52: heavy dilemma ! heavy choice ! - let ffmpeg not updated (with x264 support but with security problem) The proper thing is to identify the needed fixes and backport them. - update ffmpeg disabling x264 support not an option - update ffmpeg keeping x264 support but need to rebuild mass of packages (not alone ) and provide lots of updated rpms to QA ! Absolutely not an option -- Thomas
Re: [Mageia-dev] [Bug 3431] ffmpeg security update to version 0.7.8
Funda Wang a écrit : And, we will rely on current maintainer nobody to take care of this bug. Don't be angry ... please !!! I know how much work you do for nobody's packages. I just pointed a little problem about the dilemma to which you found an answer that may be discussed and that may push someone to help you for the job (I am not skilled enough to help : can only tilt... sometimes wrongly !)
[Mageia-dev] Down to one missing libclutter for update
The following package has to be removed for others to be upgraded: lib64cheese-gtk20-3.3.1-1.mga2.x86_64 (due to missing libclutter-glx-1.0.so.0()(64bit)) There appears to be only one files missing in action (MIA) - libclutter-glx Is this intended or should I wait a bit more?? Cheers, R.Fox
Re: [Mageia-dev] Down to one missing libclutter for update
2011/11/24 Robert Fox l...@foxconsult.net: The following package has to be removed for others to be upgraded: lib64cheese-gtk20-3.3.1-1.mga2.x86_64 (due to missing libclutter-glx-1.0.so.0()(64bit)) There appears to be only one files missing in action (MIA) - libclutter-glx Is this intended or should I wait a bit more?? It's safe to remove it as there's new cheese libs available with higher major. Latest cheese version is 3.3.2, with gtk major 21..
Re: [Mageia-dev] ffmpeg in mageia1 updates testing (revision 171164)
On Thu, Nov 24, 2011 at 1:58 PM, Thomas Backlund t...@mageia.org wrote: Philippe DIDIER skrev 24.11.2011 14:52: heavy dilemma ! heavy choice ! - let ffmpeg not updated (with x264 support but with security problem) The proper thing is to identify the needed fixes and backport them. - update ffmpeg disabling x264 support not an option - update ffmpeg keeping x264 support but need to rebuild mass of packages (not alone ) and provide lots of updated rpms to QA ! Absolutely not an option But how many packages are affected ?
Re: [Mageia-dev] perl-ExtUtils-XSpp-0.160.200-2.mga2
On 11/11/21 16:22 +0100, Jerome Quelin wrote: note that i don't understand why some scripts get installed with /usr/bin/perl5.14.x shebang, while some other are installed with /usr/bin/perl... maybe if we force -Dinstallusrbinperl in perl spec file? i need to try that... and it doesn't seem to fix the problem. i therefore don't know why some scripts get installed with full version interpreter, while others aren't... jérôme
Re: [Mageia-dev] [Bug 3431] ffmpeg security update to version 0.7.8
Philippe DIDIER a écrit : Funda Wang a écrit : And, we will rely on current maintainer nobody to take care of this bug. Don't be angry ... please !!! I know how much work you do for nobody's packages. I just pointed a little problem about the dilemma to which you found an answer that may be discussed and that may push someone to help you for the job (I am not skilled enough to help : can only tilt... sometimes wrongly !) sorry for the mistake : this answer was sent on devel mail list where the discussion on ffmpeg began just before it goes ahead on bugs mailing list...
[Mageia-dev] eclipse installation under cauldron
Hi, Now a day, when someone wants to install eclipse he has to answer to less than 17 package selection ! I can anderstand the 2 first (which jvm and javamail vs. classpathx-mail) but the next 15 are ant-* vs. ant17-* choices. I was wondering: Is it temporary ? if not: do we expect that any user that want to use eclipse can understand those questions ? (personnaly, I was not installing eclipse for java use and I don't know the meaning of all those packages) Claire
Re: [Mageia-dev] eclipse installation under cauldron
Le 24/11/2011 21:43, Claire Revillet a écrit : Hi, Now a day, when someone wants to install eclipse he has to answer to less than 17 package selection ! s/to less/not less/ I can anderstand the 2 first (which jvm and javamail vs. classpathx-mail) but the next 15 are ant-* vs. ant17-* choices. I was wondering: Is it temporary ? if not: do we expect that any user that want to use eclipse can understand those questions ? (personnaly, I was not installing eclipse for java use and I don't know the meaning of all those packages) Claire And it seems there is some lines to suppress in different specfiles :) sorry for the french error messages (impossible de créer le répertoire == cannot create folder) : 62/64: eclipse-platform ## cp: impossible de créer le fichier standard « /home/iurt/rpm/tmp//artifacts.xml »: Aucun fichier ou dossier de ce type cp: impossible de créer le lien symbolique « /home/iurt/rpm/tmp//eclipse.ini »: Aucun fichier ou dossier de ce type cp: impossible de créer le répertoire « /home/iurt/rpm/tmp//p2 »: Aucun fichier ou dossier de ce type cp: impossible de créer le répertoire « /home/iurt/rpm/tmp//configuration »: Aucun fichier ou dossier de ce type Eclipse: An error has occurred. See the log file /usr/lib64/eclipse/configuration/1322167734873.log. cp: impossible d'évaluer « /home/iurt/rpm/tmp//artifacts.xml »: Aucun fichier ou dossier de ce type cp: impossible d'évaluer « /home/iurt/rpm/tmp//eclipse.ini »: Aucun fichier ou dossier de ce type cp: impossible d'évaluer « /home/iurt/rpm/tmp//p2 »: Aucun fichier ou dossier de ce type cp: impossible d'évaluer « /home/iurt/rpm/tmp//configuration »: Aucun fichier ou dossier de ce type 63/64: eclipse-jdt ## cp: impossible de créer le fichier standard « /home/iurt/rpm/tmp//artifacts.xml »: Aucun fichier ou dossier de ce type cp: impossible de créer le lien symbolique « /home/iurt/rpm/tmp//eclipse.ini »: Aucun fichier ou dossier de ce type cp: impossible de créer le répertoire « /home/iurt/rpm/tmp//p2 »: Aucun fichier ou dossier de ce type cp: impossible de créer le répertoire « /home/iurt/rpm/tmp//configuration »: Aucun fichier ou dossier de ce type 64/64: eclipse-pde ## cp: impossible de créer le fichier standard « /home/iurt/rpm/tmp//artifacts.xml »: Aucun fichier ou dossier de ce type cp: impossible de créer le lien symbolique « /home/iurt/rpm/tmp//eclipse.ini »: Aucun fichier ou dossier de ce type cp: impossible de créer le répertoire « /home/iurt/rpm/tmp//p2 »: Aucun fichier ou dossier de ce type cp: impossible de créer le répertoire « /home/iurt/rpm/tmp//configuration »: Aucun fichier ou dossier de ce type
Re: [Mageia-dev] alpha 1 release info preparation
On Tue, Nov 22, 2011 at 20:58, Dick Gevers dvgev...@xs4all.nl wrote: On Tue, 22 Nov 2011 20:04:56 +0100, Romain d'Alverny wrote about Re: So please see https://wiki.mageia.org/en/Mageia_2_alpha1 as the canvas and update as you see fit. Ping? Alpha 1 release is in 3 days, and it cannot go outside without this info available. And you guys know what to say there. Till now qa recorded all in http://piratepad.net/owkBzzoJId Thanks. Well, this is cool for QA, but difficult to summarize as such for release notes by an outsider. Release notes are in this shape at this time: https://wiki.mageia.org/en/Mageia_2_alpha1#Major_new_features - and this directly shapes the release announcement (to be managed by Patricia). At this time, that means we have near to nothing to say... although there are quite some changes. Are we to push the ISOs online tomorrow, without a status of what's new (packaging team?) and without a public plan for tests technical review (QA team?) and without a drafted roadmap for the big items to work on for the next alpha? (and without an announcement) Anne and me will manage the download links, for all the rest, insiders summarized input is more than welcome for their own part. Ahoy! Romain
Re: [Mageia-dev] Proposition to drop the package pastebin from Mageia
Le jeudi 24 novembre 2011 à 10:49 +0100, Sandro CAZZANIGA a écrit : Now we need pastebin.mageia.org :) Well, if you are ready to maintain it, just submit a patch to the puppet configuration. -- Michael Scherer
Re: [Mageia-dev] ffmpeg in mageia1 updates testing (revision 171164)
On Thu, 24 Nov 2011 10:53:07 -0500, D.Morgan dmorga...@gmail.com wrote: On Thu, Nov 24, 2011 at 1:58 PM, Thomas Backlund t...@mageia.org wrote: Philippe DIDIER skrev 24.11.2011 14:52: - update ffmpeg keeping x264 support but need to rebuild mass of packages (not alone ) and provide lots of updated rpms to QA ! Absolutely not an option But how many packages are affected ? urpmq --whatrequires-recursive ffmpeg|sort -u 2mandvd clipgrab ffmpeg ffmpegthumbs kdenlive kino kino-devel kmediafactory konvertible luciole mythtv-plugin-archive Might be worth considering, depending on how difficult it is to port the security patch back to the current version. Regards, Dave Hodgins
Re: [Mageia-dev] ffmpeg in mageia1 updates testing (revision 171164)
On 24.11.2011 17:53, D.Morgan wrote: On Thu, Nov 24, 2011 at 1:58 PM, Thomas Backlund t...@mageia.org wrote: Philippe DIDIER skrev 24.11.2011 14:52: heavy dilemma ! heavy choice ! - let ffmpeg not updated (with x264 support but with security problem) The proper thing is to identify the needed fixes and backport them. - update ffmpeg disabling x264 support not an option - update ffmpeg keeping x264 support but need to rebuild mass of packages (not alone ) and provide lots of updated rpms to QA ! Absolutely not an option But how many packages are affected ? BTW, if you look at http://git.videolan.org/?p=ffmpeg.git;a=shortlog;h=refs/heads/release/0.7 you'll notice the the security issues mentioned here are just a tip of the iceberg, since there are hundreds of commits fixing buffer overflows and other similar issues in various codecs in the 0.7 stable branch alone. -- Anssi Hannula
[Mageia-dev] Weirdness with GnomeShell theme
Hi all... I have just noticed that GnomeShell is doing strange things wrt windows decorations. I've had always used the default Adwaita theme, I just like it. Only changed font sizes. Chasing another bug (a strange character trailing Mozilla Firefox window title...) I tried to change window title font, and GS ignored me. I could not change even the size. Other changes in gnome-tweak-tool are accepted immediately. Well, lets try my children's/wife's accounts. That was worse, they don't even have the default Adwaita theme (even if GTT says it is the one used). It looks like something is forcing the settings for window decorations in GnomeShell. Any idea ? Where are these settings stored ? Can I just delete them from a terminal ? (something in .gconf or the like). TIA
Re: [Mageia-dev] eclipse installation under cauldron
2011/11/24 Claire Revillet gren...@zarb.org: Le 24/11/2011 21:43, Claire Revillet a écrit : Hi, Now a day, when someone wants to install eclipse he has to answer to less than 17 package selection ! s/to less/not less/ I can anderstand the 2 first (which jvm and javamail vs. classpathx-mail) but the next 15 are ant-* vs. ant17-* choices. I was wondering: Is it temporary ? if not: do we expect that any user that want to use eclipse can understand those questions ? (personnaly, I was not installing eclipse for java use and I don't know the meaning of all those packages) Claire And it seems there is some lines to suppress in different specfiles :) sorry for the french error messages (impossible de créer le répertoire == cannot create folder) : 62/64: eclipse-platform ## cp: impossible de créer le fichier standard « /home/iurt/rpm/tmp//artifacts.xml »: Aucun fichier ou dossier de ce type cp: impossible de créer le lien symbolique « /home/iurt/rpm/tmp//eclipse.ini »: Aucun fichier ou dossier de ce type cp: impossible de créer le répertoire « /home/iurt/rpm/tmp//p2 »: Aucun fichier ou dossier de ce type cp: impossible de créer le répertoire « /home/iurt/rpm/tmp//configuration »: Aucun fichier ou dossier de ce type Eclipse: An error has occurred. See the log file /usr/lib64/eclipse/configuration/1322167734873.log. cp: impossible d'évaluer « /home/iurt/rpm/tmp//artifacts.xml »: Aucun fichier ou dossier de ce type cp: impossible d'évaluer « /home/iurt/rpm/tmp//eclipse.ini »: Aucun fichier ou dossier de ce type cp: impossible d'évaluer « /home/iurt/rpm/tmp//p2 »: Aucun fichier ou dossier de ce type cp: impossible d'évaluer « /home/iurt/rpm/tmp//configuration »: Aucun fichier ou dossier de ce type 63/64: eclipse-jdt ## cp: impossible de créer le fichier standard « /home/iurt/rpm/tmp//artifacts.xml »: Aucun fichier ou dossier de ce type cp: impossible de créer le lien symbolique « /home/iurt/rpm/tmp//eclipse.ini »: Aucun fichier ou dossier de ce type cp: impossible de créer le répertoire « /home/iurt/rpm/tmp//p2 »: Aucun fichier ou dossier de ce type cp: impossible de créer le répertoire « /home/iurt/rpm/tmp//configuration »: Aucun fichier ou dossier de ce type 64/64: eclipse-pde ## cp: impossible de créer le fichier standard « /home/iurt/rpm/tmp//artifacts.xml »: Aucun fichier ou dossier de ce type cp: impossible de créer le lien symbolique « /home/iurt/rpm/tmp//eclipse.ini »: Aucun fichier ou dossier de ce type cp: impossible de créer le répertoire « /home/iurt/rpm/tmp//p2 »: Aucun fichier ou dossier de ce type cp: impossible de créer le répertoire « /home/iurt/rpm/tmp//configuration »: Aucun fichier ou dossier de ce type Please test next eclipse rpm.
Re: [Mageia-dev] eclipse installation under cauldron
On Thu, Nov 24, 2011 at 9:43 PM, Claire Revillet gren...@zarb.org wrote: Hi, Now a day, when someone wants to install eclipse he has to answer to less than 17 package selection ! I can anderstand the 2 first (which jvm and javamail vs. classpathx-mail) but the next 15 are ant-* vs. ant17-* choices. I was wondering: Is it temporary ? if not: do we expect that any user that want to use eclipse can understand those questions ? (personnaly, I was not installing eclipse for java use and I don't know the meaning of all those packages) Claire Gil can you look to fix this issue ? this is a really important pb.
[Mageia-dev] Proposal to change default gtk3 theme back to upstream choice
Hello, Currently, we are selecting oxygen as default theme for whole distro, but oxygen-gtk3 is too unstable, nor seems to be actively maintained. Maybe we should change default theme for gtk3 applications, the same as upstream? Especially considering we will providing gtk3 as one major choice of applications in mageia 2? Regards.
[Mageia-dev] Eclipse MarketPlace plugin
I didn't find a marketplace plugin for Mageia, is there one and is it that I just didn't find it? if no is there one in the works? Fedora has had one for quite a while. Michel Catudal -- For OS/2 and Linux Software visit http://home.comcast.net/~mcatudal
Re: [Mageia-dev] eclipse installation under cauldron
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/24/2011 08:30 PM, D.Morgan wrote: On Thu, Nov 24, 2011 at 9:43 PM, Claire Revillet gren...@zarb.org wrote: Hi, Now a day, when someone wants to install eclipse he has to answer to less than 17 package selection ! I can anderstand the 2 first (which jvm and javamail vs. classpathx-mail) but the next 15 are ant-* vs. ant17-* choices. I was wondering: Is it temporary ? if not: do we expect that any user that want to use eclipse can understand those questions ? (personnaly, I was not installing eclipse for java use and I don't know the meaning of all those packages) Claire Gil can you look to fix this issue ? this is a really important pb. This is what I do: Go to Eclipse.org and download the version of your choice to your home directory. They are all stand alone programs and work fine. I have 4 different versions installed. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mageia - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOzwWLAAoJECPQsolLqbfHlIMH/3HDd1CTeHLTgUcjaGnwksNX WYrt//9yBfILvh+/owzGg2sgdaG9+tTHXCHG5mMBXJbOShX12cc0+daU2yxfOsN5 tU1mYXEABx41BXOgABmUSYAI2i1/SGbR1/S2mj9VQMBPLbygacf+p5hK3d8K3Mld 34SSckpOqWEua4ODcegVIQmpXC3gKLo6qWUQf9rpo4mQFPiOGn0+//vLf3C9HySP 5NEm5Q07LRQDpWiiSsKwE4ccfI0BCwd4VfCquSbT1xU98neI9jxWJQGEkVH3iR4z XPi6cZZdXcm3RTVGtwoplrzt+nJ2fsC1kkGznXPMpWtopFiP/hCNuBlPXldkpZI= =wZ1W -END PGP SIGNATURE-
[Mageia-dev] [Off topic: GPG-signature]
Hi Duane, I tried to send this via email to you directly, but your overly tight spamfilter blocked my message and jumping through the hoops it presented to me didn't work. It's nice that you sign your posts, but I can't find your public key online anywhere to check it. Perhaps you can point me to it or upload it to a keyserver? Without it there is little point in signing messages to public lists I guess. Thanks, Remco signature.asc Description: Digital signature
Re: [Mageia-dev] [Off topic: GPG-signature]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/24/2011 09:42 PM, Remco Rijnders wrote: Hi Duane, I tried to send this via email to you directly, but your overly tight spamfilter blocked my message and jumping through the hoops it presented to me didn't work. It's nice that you sign your posts, but I can't find your public key online anywhere to check it. Perhaps you can point me to it or upload it to a keyserver? Without it there is little point in signing messages to public lists I guess. Thanks, Remco There is a point: If an email appears on the list from me which has not been signed its not from me which has happened in the past. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mageia - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOzxedAAoJECPQsolLqbfHkH8H/ig99/otCKiyCLFWpPLWC47/ G/tos3Vq6mZYZWGHLUgNqz0IWQX2VroJnj65ykEnNrCXo8u/uhpfMrHNdU1kygbt RhOooijN66X8QoAJ/FYWsN+heCqBkF4JfnH6xlGo96Duq8MQmms7rYgZ3ioR3wip /odK6QJjQZF/1gdsMiapRyggadwl6urJXlkF5MI24TckWRILCwxac3y0wdVqdC9O ycT/bPNftCmPWerFdVZbdh+0Ao6mxp99fJ1izjtuYgGgpkPQZ1coZEkJtCz9ZHIe 2N7kCrAWrP+KRO8ndyCVa2YOYaehI9sMkf9xyogY6EPZ/oeVdAh1PbYLAZL905E= =75mW -END PGP SIGNATURE-
Re: [Mageia-dev] [Off topic: GPG-signature]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 24 Nov 2011 23:20:46 -0500, Duane Phinney genom...@earthlink.net wrote: There is a point: If an email appears on the list from me which has not been signed its not from me which has happened in the past. If the public key is not made available, no one can tell if you signed the message, or if someone copied the pgp sig from some other message, from you. Regards, Dave Hodgins -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk7PHTcACgkQObhOpZiwE+AKlwCgsTjOGOgoFBAumwl+6S6sssTX ee4AoI6LMmSxKSu5TBX6/xAcVI2B106P =+cbm -END PGP SIGNATURE-
Re: [Mageia-dev] [Off topic: GPG-signature]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/24/2011 10:46 PM, David W. Hodgins wrote: On Thu, 24 Nov 2011 23:20:46 -0500, Duane Phinney genom...@earthlink.net wrote: There is a point: If an email appears on the list from me which has not been signed its not from me which has happened in the past. If the public key is not made available, no one can tell if you signed the message, or if someone copied the pgp sig from some other message, from you. Regards, Dave Hodgins If you are looking for a fight look elseware. Over and out. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mageia - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOzyHOAAoJECPQsolLqbfHf54H/jf58ag7/IFoR6ZLo5Z0r98a 2JOWhNqBcP1xxv1qmuBzJNHoQdWbsX++oq3Dr3Zeuc3+0N+J4CsN5kMtJxuyOkfi OKsA1sqeKg6ILxNKQ5Qs+Q/+ti5T8QZQ/ei/66qUQrEQNwnLdVmNmiOGkZw1q9cK kt/o+uTcO9zFgfP9m8eFLrADNaTRqpwpcV31LczTlpMX+NCpue8bxMyLFvHgq0uw hyFFay77q8ZUIgIzDOt/ns5P+CiAJopbypW8FXVPglQfut/XPp4qofk8paDio/kD vgJH2em/JIANK3fGVjgmkrWrNgEd0Dpi7BlpUOwd8jxojrD8wpc78d9pTAB7Nbg= =siBv -END PGP SIGNATURE-
[Mageia-dev] update problems, KDE...
hi, it seems that we have a little problem with the last updates of KDE components... # urpmi --auto-up http://twiska.zarb.org/mageia/distrib/cauldron/i586/media/core/release/media_info/2025-062623-synthesis.hdlist.cz média « Core Release » mis à jour le média « Core Updates » est à jour le média « Nonfree Release » est à jour le média « Nonfree Updates » est à jour le média « Tainted Release » est à jour le média « Tainted Updates » est à jour Pour satisfaire les dépendances, les paquetages suivants vont être installés : Paquetage Version Révision Arch (média « Core Release ») curl 7.23.1 2.mga2i586 kactivitymanagerd 6.1 0.mga2i586 kdebase4-runtime 4.7.32.mga2i586 libaudit-devel 2.1.31.mga2i586 libaudit1 2.1.31.mga2i586 libauparse02.1.31.mga2i586 libcurl-devel 7.23.1 2.mga2i586 libcurl4 7.23.1 2.mga2i586 libkdefakes5 4.7.33.mga2i586 libkprintutils44.7.33.mga2i586 libkpty4 4.7.33.mga2i586 libkunittest4 4.7.33.mga2i586 libnepomuksync44.7.32.mga2i586 un espace de 365Ko sera libéré. 6.8Mo de paquets seront récupérés. Procéder à l'installation des 13 paquetages ? (O/n) installation de libaudit-devel-2.1.3-1.mga2.i586.rpm kactivitymanagerd-6.1-0.mga2.i586.rpm libauparse0-2.1.3-1.mga2.i586.rpm libaudit1-2.1.3-1.mga2.i586.rpm libkpty4-4.7.3-3.mga2.i586.rpm libkprintutils4-4.7.3-3.mga2.i586.rpm libkunittest4-4.7.3-3.mga2.i586.rpm libkdefakes5-4.7.3-3.mga2.i586.rpm depuis /var/cache/urpmi/rpms Préparation ... # installation de libnepomuksync4-4.7.3-2.mga2.i586.rpm kdebase4-runtime-4.7.3-2.mga2.i586.rpm libcurl4-7.23.1-2.mga2.i586.rpm curl-7.23.1-2.mga2.i586.rpm libcurl-devel-7.23.1-2.mga2.i586.rpm depuis /var/cache/urpmi/rpms L'installation a échoué :le fichier /usr/bin/kactivitymanagerd de l'installation de kactivitymanagerd-6.1-0.mga2.i586 entre en conflit avec le fichier du paquetage kdebase4-runtime-1:4.7.3-1.mga2.i586 le fichier /usr/share/kde4/services/kactivitymanagerd.desktop de l'installation de kactivitymanagerd-6.1-0.mga2.i586 entre en conflit avec le fichier du paquetage kdebase4-runtime-1:4.7.3-1.mga2.i586 kactivitymanagerd est nécessaire pour kdebase4-runtime-1:4.7.3-2.mga2.i586 # urpmi kactivitymanagerd Marque kactivitymanagerd comme étant manuellement installé, il ne sera pas considéré comme un paquet orphelin writing /var/lib/rpm/installed-through-deps.list installation de kactivitymanagerd-6.1-0.mga2.i586.rpm depuis /var/cache/urpmi/rpms Préparation ... # L'installation a échoué :le fichier /usr/bin/kactivitymanagerd de l'installation de kactivitymanagerd-6.1-0.mga2.i586 entre en conflit avec le fichier du paquetage kdebase4-runtime-1:4.7.3-1.mga2.i586 le fichier /usr/share/kde4/services/kactivitymanagerd.desktop de l'installation de kactivitymanagerd-6.1-0.mga2.i586 entre en conflit avec le fichier du paquetage kdebase4-runtime-1:4.7.3-1.mga2.i586
