Re: [Mageia-dev] unable to mount encrypted partitions created with drakdisk
On Wed, 28 Mar 2012 21:40:36 -0400, simple w8 wrote: You have chosen thekeysize 512 thats the one is not supported under the FreeOTFE project... Isnt possible to change the keysize to a value that can be supported under Windows? Yes. Test what works on your own system, then open a bug report asking for the change. Just don't use cbc, as it's too insecure. Regards, Dave Hodgins
Re: [Mageia-dev] Removal of sun java
Le 29/03/2012 23:06, Florian Hubold a écrit : Am 29.03.2012 22:23, schrieb Maarten Vanraes: Op donderdag 29 maart 2012 21:08:22 schreef David Walser: Guillaume Rousse writes: If I want to keep a proprietary JRE on my computers, because I trust it more to run crap proprietary applications (also called corporate-compliants), than marvelous free-licensed environment they have never been tested with, that is my choice, not yours. So you say that you really want to keep an outdated package with many security holes, which even the infamous Zeus bot is said to exploit? I think I'm best placed than anyone else to evaluate the exact risk I'm facing on the machines I'm running, because I know what they are used for, how they are managed, and how they are protected exactly from external threat such as Zeus. The decision of how to manage this problem exactly belongs to me. Sure, that's your choice and you're free to do this, but we can't keep our users susceptible to such problems. You're not a system administrator, whose duty is to take this kind of decision, you are a technical solution provider. You're clearly confusing the roles here. Removing the sun java package from the distribution is perfectly fine (and anyway, there is no real choice). Explaining it in release notes, with alternative solutions suggestions also. But automatically removing software for security concerns, without asking for user consent, would be a first step into transfering decision power from user to operating system vendor. Trusted computing approach, in other terms. -- BOFH excuse #301: appears to be a Slow/Narrow SCSI-0 Interface problem
Re: [Mageia-dev] Removal of sun java
On 29 March 2012 22:59, Pascal Terjan wrote: >> perhaps we can obsolete it with one of those nonfree getters? (if security >> bug) >> >> or, maybe a package that gives an README.urpmi ... >> >> IMHO: i think obsoleting it is fine, but with a README.urpmi that says >> notifies >> that it's been obsoleted. > > > Yes that seems the best solution to me We can do like RH & Ubuntu, provides an empty package that explain sun doesn't enable us anymore to distribute it and that they've to install (& update) it manually from sun.com
Re: [Mageia-dev] Removal of sun java
Le 30/03/2012 09:58, Thierry Vignaud a écrit : On 29 March 2012 22:59, Pascal Terjan wrote: perhaps we can obsolete it with one of those nonfree getters? (if security bug) or, maybe a package that gives an README.urpmi ... IMHO: i think obsoleting it is fine, but with a README.urpmi that says notifies that it's been obsoleted. Yes that seems the best solution to me We can do like RH& Ubuntu, provides an empty package that explain sun doesn't enable us anymore to distribute it and that they've to install (& update) it manually from sun.com Why should we manage this case differently from other similar situations ? That's not the first time we remove something from the distribution, because it is not supported anymore usually, and has known available vulnerabilities. -- Old and precious carpets weaken bowels and bladders. -- Jenning's Corollary Concerning Oriental Carpets and Pets
Re: [Mageia-dev] Removal of sun java
On 30 March 2012 10:06, Guillaume Rousse wrote: >> We can do like RH& Ubuntu, provides an empty package that explain sun >> doesn't enable us anymore to distribute it and that they've to install (& >> update) >> it manually from sun.com > > Why should we manage this case differently from other similar situations ? > That's not the first time we remove something from the distribution, because > it is not supported anymore usually, and has known available > vulnerabilities. Actually, _YOU_ want us to "manage this case differently from other similar situations". In case you didn't see, other packages are obsoleted by task-obsolete (if no better package) In this case, we even have strong decisions to do so: 1) users don't report bugs in our bugzilla 2) users get aware it's no longer supported by us 3) users get aware they won't get any security update anymore 4) users get aware they have to look at sun.com for updates 5) ... So please don't invent special exceptions to our policies for your own comfort.
Re: [Mageia-dev] dropping mysql-workbench
On Thu, 29 Mar 2012, Maarten Vanraes wrote: > > unfortunately, atm it doesn't work, so it needs to be rebuilt, but it doesn't > rebuild at all... and since we're in version freeze, you can't just update to > a new version. even more is that soon is release freeze... No, fixing a package that doesn't work can be a good reason for version freeze exception. So if a new version can help fix the problem, it should be considered.
Re: [Mageia-dev] Freeze push: pidgin-sipe
Le 29/03/2012 11:46, Damien Lallement a écrit : Le 28/03/2012 13:22, Damien Lallement a écrit : Hi, Can you please push pidgin-sipe. The new version (1.13.0) is a bug fix version: - add TLS-DSK authentification scheme (mandatory for Office365) - add non-public Lync support - fix build vith latest glib2 - refactored crypto code - remove kopete backend (telepathy now) http://sourceforge.net/projects/sipe/files/sipe/pidgin-sipe-1.13.0/ Thanks, ping ? ping ? -- Damien Lallement twitter: damsweb - IRC: damsweb/coincoin
Re: [Mageia-dev] Removal of sun java
On Fri, 30 Mar 2012, Thierry Vignaud wrote: > On 30 March 2012 10:06, Guillaume Rousse wrote: > >> We can do like RH& Ubuntu, provides an empty package that explain sun > >> doesn't enable us anymore to distribute it and that they've to install (& > >> update) > >> it manually from sun.com > > > > Why should we manage this case differently from other similar situations ? > > That's not the first time we remove something from the distribution, because > > it is not supported anymore usually, and has known available > > vulnerabilities. > > Actually, _YOU_ want us to "manage this case differently from other similar > situations". > In case you didn't see, other packages are obsoleted by task-obsolete (if > no better package) So I think we should obsolete sun-java in task-obsolete, and add it to release notes. Then people who want to remove unsupported packages can install task-obsolete.
Re: [Mageia-dev] Removal of sun java
2012/3/30 Thierry Vignaud : > On 29 March 2012 22:59, Pascal Terjan wrote: >>> perhaps we can obsolete it with one of those nonfree getters? (if security >>> bug) >>> >>> or, maybe a package that gives an README.urpmi ... >>> >>> IMHO: i think obsoleting it is fine, but with a README.urpmi that says >>> notifies >>> that it's been obsoleted. >> >> >> Yes that seems the best solution to me > > We can do like RH & Ubuntu, provides an empty package that explain sun doesn't > enable us anymore to distribute it and that they've to install (& update) it > manually from sun.com That's what others and I suggested in the bug report. We are not sysadmins of user's systems. But that's only the academical point of view. Reality is that the main target of Mageia is the average user who will likely not read technical papers or security alert and will probably not know about the security issue at all. Even if he reads something about it in a newspaper he will usually trust Mageia's repos, more so since we keep telling the users that we do QA for all software in the "official" repos. Telling that all over the place implies a responsibility which we can not simply put away with by telling that we are not sysadmins of the user's systems. Supplying a software in our repos does not allow us in cases like this one to simply point at the user and tell him that it is his own fault if he installs the software. We can do that if he installs software from a 3rd party source but not from our own repos. So, just removing the package and leaving the users who already installed it out in the rain is wrong and could even mean bad reputation. That's why I strongly suggest to think beyond the rim of a developer's bowl. -- wobo
Re: [Mageia-dev] Removal of sun java
2012/3/30 nicolas vigier : > On Fri, 30 Mar 2012, Thierry Vignaud wrote: > >> On 30 March 2012 10:06, Guillaume Rousse wrote: >> >> We can do like RH& Ubuntu, provides an empty package that explain sun >> >> doesn't enable us anymore to distribute it and that they've to install (& >> >> update) >> >> it manually from sun.com >> > >> > Why should we manage this case differently from other similar situations ? >> > That's not the first time we remove something from the distribution, >> > because >> > it is not supported anymore usually, and has known available >> > vulnerabilities. >> >> Actually, _YOU_ want us to "manage this case differently from other similar >> situations". >> In case you didn't see, other packages are obsoleted by task-obsolete (if >> no better package) > > So I think we should obsolete sun-java in task-obsolete, and add it to > release notes. Then people who want to remove unsupported packages can > install task-obsolete. Do all average users know about task-obsolete (I did not, never needed it) ? You can't use what you don't know about and what has not been documented in userland. Except you want to narrow down the target group for Mageia to people with technical knowledge and interest. -- wobo
Re: [Mageia-dev] php pear mga2 upgrade issues (file conflicts)
2012/3/16 Thierry Vignaud : > On 16 March 2012 03:36, Anssi Hannula wrote: >> I've seen some mga1->mga2 upgrade issues with php-pear packages: >> >> file /usr/share/pear/PHPUnit/Extensions/Database/Operation/Exception.php >> from install of php-pear-DbUnit-1.1.2-1.mga2.noarch conflicts with file >> from package php-pear-PHPUnit-3.3.17-3.mga1.noarch >> >> file /usr/share/pear/PHPUnit/Extensions/SeleniumTestCase/append.php from >> install of php-pear-PHPUnit_Selenium-1.2.3-1.mga2.noarch conflicts with >> file from package php-pear-PHPUnit-3.3.17-3.mga1.noarch >> >> >> It looks like php-pear-PHPUnit_Selenium and php-pear-DbUnit were >> probably splitted from php-pear-PHPUnit and so need >> "Conflicts: php-pear-PHPUnit < 3.5". >> >> Similar issues seem to exist (without closer look) in other pkgs like at >> least php-pear-File* and php-pear-PHPUnit_Story. >> >> Attached is the output of >> ./check-distro-files-conflicts /mirror/mageia/1/x86_64 \ >> /mirror/mageia/cauldron/x86_64 | grep php-pear | grep mga2 >> >> (check-distro-files-conflicts is the old Pixel's script at >> http://svn.mandriva.com/viewvc/soft/build_system/distrib/cleaning/check-distro-files-conflicts) > > You should open a BR instead of sending a mail... Just did it https://bugs.mageia.org/show_bug.cgi?id=5161 Please somebody have a look before RC -- Anne http://www.mageia.org
Re: [Mageia-dev] Removal of sun java
On 30 March 2012 10:40, Wolfgang Bornath wrote: >>> Actually, _YOU_ want us to "manage this case differently from other similar >>> situations". >>> In case you didn't see, other packages are obsoleted by task-obsolete (if >>> no better package) >> >> So I think we should obsolete sun-java in task-obsolete, and add it to >> release notes. Then people who want to remove unsupported packages can >> install task-obsolete. > > Do all average users know about task-obsolete (I did not, never needed > it) ? You can't use what you don't know about and what has not been > documented in userland. Except you want to narrow down the target > group for Mageia to people with technical knowledge and interest. Actually, if it's obsoleted by task-obsolete, task-obsolete will be automatically installed. Providing it's on the media (eg: in the DVD case)
Re: [Mageia-dev] Removal of sun java
On Fri, 30 Mar 2012, Wolfgang Bornath wrote: > 2012/3/30 nicolas vigier : > > On Fri, 30 Mar 2012, Thierry Vignaud wrote: > > > >> On 30 March 2012 10:06, Guillaume Rousse wrote: > >> >> We can do like RH& Ubuntu, provides an empty package that explain sun > >> >> doesn't enable us anymore to distribute it and that they've to install > >> >> (& update) > >> >> it manually from sun.com > >> > > >> > Why should we manage this case differently from other similar situations > >> > ? > >> > That's not the first time we remove something from the distribution, > >> > because > >> > it is not supported anymore usually, and has known available > >> > vulnerabilities. > >> > >> Actually, _YOU_ want us to "manage this case differently from other similar > >> situations". > >> In case you didn't see, other packages are obsoleted by task-obsolete (if > >> no better package) > > > > So I think we should obsolete sun-java in task-obsolete, and add it to > > release notes. Then people who want to remove unsupported packages can > > install task-obsolete. > > Do all average users know about task-obsolete (I did not, never needed > it) ? You can't use what you don't know about and what has not been > documented in userland. Except you want to narrow down the target > group for Mageia to people with technical knowledge and interest. It can be added to the release notes.
Re: [Mageia-dev] Removal of sun java
2012/3/30 Thierry Vignaud : > On 30 March 2012 10:40, Wolfgang Bornath wrote: Actually, _YOU_ want us to "manage this case differently from other similar situations". In case you didn't see, other packages are obsoleted by task-obsolete (if no better package) >>> >>> So I think we should obsolete sun-java in task-obsolete, and add it to >>> release notes. Then people who want to remove unsupported packages can >>> install task-obsolete. >> >> Do all average users know about task-obsolete (I did not, never needed >> it) ? You can't use what you don't know about and what has not been >> documented in userland. Except you want to narrow down the target >> group for Mageia to people with technical knowledge and interest. > > Actually, if it's obsoleted by task-obsolete, task-obsolete will be > automatically installed. > Providing it's on the media (eg: in the DVD case) It isn't at the moment. Where should we add it ? rpmsrate ? -- Anne http://www.mageia.org
Re: [Mageia-dev] Removal of sun java
On 30 March 2012 10:52, Anne nicolas wrote: > Actually, _YOU_ want us to "manage this case differently from other > similar > situations". > In case you didn't see, other packages are obsoleted by task-obsolete (if > no better package) So I think we should obsolete sun-java in task-obsolete, and add it to release notes. Then people who want to remove unsupported packages can install task-obsolete. >>> >>> Do all average users know about task-obsolete (I did not, never needed >>> it) ? You can't use what you don't know about and what has not been >>> documented in userland. Except you want to narrow down the target >>> group for Mageia to people with technical knowledge and interest. >> >> Actually, if it's obsoleted by task-obsolete, task-obsolete will be >> automatically installed. >> Providing it's on the media (eg: in the DVD case) > > It isn't at the moment. Where should we add it ? rpmsrate ? yes in the INSTALL section
Re: [Mageia-dev] Removal of sun java
2012/3/30 Thierry Vignaud : > On 30 March 2012 10:40, Wolfgang Bornath wrote: Actually, _YOU_ want us to "manage this case differently from other similar situations". In case you didn't see, other packages are obsoleted by task-obsolete (if no better package) >>> >>> So I think we should obsolete sun-java in task-obsolete, and add it to >>> release notes. Then people who want to remove unsupported packages can >>> install task-obsolete. >> >> Do all average users know about task-obsolete (I did not, never needed >> it) ? You can't use what you don't know about and what has not been >> documented in userland. Except you want to narrow down the target >> group for Mageia to people with technical knowledge and interest. > > Actually, if it's obsoleted by task-obsolete, task-obsolete will be > automatically installed. > Providing it's on the media (eg: in the DVD case) Ok, thx for the explanation. But thinking further task-obsolete will not be needed in this case: People who install a new system can not install it because it is removed anyway. People who update will get an update of java-sun-plugin telling them about the removal of the package and the reason Or do I misunderstand? -- wobo
Re: [Mageia-dev] Removal of sun java
Le 30/03/2012 10:10, Thierry Vignaud a écrit : On 30 March 2012 10:06, Guillaume Rousse wrote: We can do like RH&Ubuntu, provides an empty package that explain sun doesn't enable us anymore to distribute it and that they've to install (& update) it manually from sun.com Why should we manage this case differently from other similar situations ? That's not the first time we remove something from the distribution, because it is not supported anymore usually, and has known available vulnerabilities. Actually, _YOU_ want us to "manage this case differently from other similar situations". In case you didn't see, other packages are obsoleted by task-obsolete (if no better package) Using task-obsolete is fine: - its purpose is crystal-clear - if I don't want it, I don't install it Adding an obsolete tag in openjdk to remove sun jdk now, for security concernes, whereas we had suffered a useless mess of at least four available java environnement at once for years uselessly (excepted for blindly applying jpackage project practices), doesn't seems quite similar. In this case, we even have strong decisions to do so: 1) users don't report bugs in our bugzilla 2) users get aware it's no longer supported by us 3) users get aware they won't get any security update anymore 4) users get aware they have to look at sun.com for updates 5) ... 'user get aware' is a perfectly fine objective. 'users get managed automatically' is not. So please don't invent special exceptions to our policies for your own comfort. Get me a simple example of a similar situation, when a package A, after peacefully coexisting with package B for years, suddenly obsoleted it as B was removed from the distribution, for any kind of reason. And that's not really my own confort, as I don't have any java usage anymore. I really don't care about this specific package, I care about the limit between end user and packager for this kind of decision. If the global consensus here is toward enforcing operating system vendor choices, I'd rather not volonteer for for a role in the project... -- BOFH excuse #337: the butane lighter causes the pincushioning
Re: [Mageia-dev] [RFC] How to proceed with seamonkey/iceape for security updates and freeze push
Le mardi 27 mars 2012 21:10:04, Florian Hubold a écrit : > So if noone volunteers and ensures to keep it updated for stable distros, > i'm gonna drop it from cauldron next week, before it's too late. > What about adding it to task-obsolete and then if no maintainer is found for Mageia 3 drop it completely? Samuel
Re: [Mageia-dev] Removal of sun java
'Twas brillig, and Guillaume Rousse at 30/03/12 10:17 did gyre and gimble: > Using task-obsolete is fine: > - its purpose is crystal-clear > - if I don't want it, I don't install it > > Adding an obsolete tag in openjdk to remove sun jdk now, for security > concernes, whereas we had suffered a useless mess of at least four > available java environnement at once for years uselessly (excepted for > blindly applying jpackage project practices), doesn't seems quite similar. Well think of it this way (assuming I have the facts vaguely straight): Forget about Cauldron and mga2 We're providing a known insecure version to mga1 users. We need to find a way to update mga1 somehow right? Or do we want to just abandon them? Assuming we do not want to abandon them, what do we do? I'd suggest shipping a new empty package that replaces it with a README.urpmi telling them to go to Sun directly is the most responsible thing for us to do. If they do not have a JRE installed, and they have packages that require one, then they should be prompted to install e.g. openjdk to satisfy package deps. That should work OK right? Otherwise we're basically washing our hands of our users' security. This isn't hand holding or taking away choice. It's about informing them and being a socially responsible distributor. I don't why this is even a problem point for discussion. Whatever is decided, the position on mga1 then just then flows through into mga2. 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] No time for maintainership
'Twas brillig, and Remco Rijnders at 30/03/12 03:13 did gyre and gimble: > libcanberra eandry When it's released, I'll take this one (thought it was mine already TBH :D) > obexd eandry I'll take this one too. Maybe some others but these ones for sure. 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] Removal of sun java
On 12/03/30 08:29 +0200, D.Morgan wrote: > > Can't it be put into the tainted/PLF sort of repository? > tainted is not for nonfree packages and sun doesn't allow to > redistribute it anymore can a get-sunjdk package be created that actually downloads it, same as what is done for get-skype? jérôme
Re: [Mageia-dev] Removal of sun java
On Fri, Mar 30, 2012 at 12:29 PM, Jerome Quelin wrote: > On 12/03/30 08:29 +0200, D.Morgan wrote: >> > Can't it be put into the tainted/PLF sort of repository? >> tainted is not for nonfree packages and sun doesn't allow to >> redistribute it anymore > > can a get-sunjdk package be created that actually downloads it, same as > what is done for get-skype? > > jérôme is sun java of any use ? btw sun java is provided upstream as a rpm that need user "input" to validate the licence so i don't think we can do something.
Re: [Mageia-dev] Removal of sun java
Hi *, On Fri, Mar 30, 2012 at 9:52 AM, Guillaume Rousse wrote: > [...] > You're not a system administrator, whose duty is to take this kind of > decision, you are a technical solution provider. You're clearly confusing > the roles here. I don't get your problem really. Of course Mageia will only replace the mageia packaged version of Sun's java, not a version you obtained from Oracle. So while the user who has a security-flawed version of mageia's sun-java installed will have it scheduled for an update and replaced by OpenJDK, that user a) is not forced to do the update b) can just install a fixed version of Java from Oracle instead c) update and not care that much (>90% of the user base) > But automatically removing software > for security concerns, without asking for user consent, You are asked for confirmation when installing updates - you get notification that there are updates, and then have the choice to accept them or decline them. And there is a possiblilty to flag packages as "don't update those" via configuration files. > would be a first > step into transfering decision power from user to operating system vendor. > Trusted computing approach, in other terms. This is a weak argument really, as there were always security updates. Those as well were telling the user to update, and not wait until $system-admin decided it is time to check for vulnerabilities. There have been obsolete packages in the past as well, replacing unmaintained/outdated packages by better (for most) alternatives. This time it is just both at the same time. So if you want your outdated mageia-version of java, just tell urpmi to not touch it. But don't argue that the rest of the userbase should continue running a flawed version just because you have a special need. Users have a choice to unselect updates. If they don't read the update's description, it is their fault, not mageias. Users have the choice to specify packages that must never be removed in configuration files ciao Christian
Re: [Mageia-dev] Removal of sun java
On 12/03/30 13:19 +0200, D.Morgan wrote: > is sun java of any use ? in france, to declare our salaries before taxes are applied, the web app used to require a "trusted" version of java - that is, sun jdk. i don't know if openjdk works nowadays. > btw sun java is provided upstream as a rpm that need user "input" to > validate the licence so i don't think we can do something. the advantage of having it in the dist is that a maintainer is following the version and updates them. user doesn't have to check a website for new versions. jérôme
Re: [Mageia-dev] Freeze push: libmbfl
Thomas Spuhler wrote: >> >David, can you please look at this again, it will not upgrade the way it >> >is (downgrade) >> >> Thomas, it is my understanding that this is how it should work? That is, >> downgrades should not be handled automatically in Cauldron. In the stable >> release, you'd increase the epoch. In Cauldron, everyone affected has to >> handle this manually as there we don't want to increase the epoch (which >> would eventually trickle down into stable, and we want to avoid using an >> epoch unless absolutely necessary). >> >> Just one of the downsides of running the development version on your >> machine as I understand it. >> >> Remmy Yes, sorry if that wasn't clear. You need to install the libmbfl1-1.1.0-6.mga2 manually. > It fixed the libmbfl problem. > I still get this warning. Google only shows it for php-5.4 RC > > # pear list-upgrades > PHP Warning: can't find symbol in Unknown on line 0 Do we know where that is coming from? Also, Thomas, I just saw in the changelog of the php update Oden just made in Cooker a message about patching it to use system libzip (from fedora). Since libzip currently has a security vulnerability, can you add this patch if we don't already have it?
Re: [Mageia-dev] Removal of sun java
Στις 30/03/2012 13:34:23 Christian Lohmaier γράψατε: > But don't argue that the rest of the userbase should continue running > a flawed version just because you have a special need. Users have a > choice to unselect updates. If they don't read the update's > description, it is their fault, not mageias. I interpreted Guillaume's approach as about the impact that can have Mageia's decisions in a system and the respect of the user and his system as a priority, but it was finally interpreted as he wants something for his personal use or he does nt care about a security issue, for the same reason. At least, is what i got. -- Dimitrios Glentadakis
Re: [Mageia-dev] Removal of sun java
Hi Dimitrios, *, On Fri, Mar 30, 2012 at 2:52 PM, Dimitrios Glentadakis wrote: > [...] > I interpreted Guillaume's approach as about the impact that can have Mageia's > decisions in a > system and the respect of the user and his system as a priority, but it was > finally interpreted > as he wants something for his personal use or he does nt care about a > security issue, for the > same reason. At least, is what i got. Well - that is what he said: "Don't push security updates to users by replacing package A by package B." Or: "I don't care that other people will continue using software with security flaws, since I know what I am doing." And I strongly oppose to this attitude/point of view. Not limited to Java, but in general. When a package *cannot* be updated and thus there will never be a security fix (and not just a delay of a couple of days/weeks), then the only sane thing for a distro is to replace the package by something equivalent. In the case of Java it is just so much easier, as there already exists a package that virtually does the very same thing. He wants to keep java for a special need, so that "I don't want this package A to be removed" is his own personal use. I'm sure that >98% of the users will not be amused when you tell them after a year or two that they have been running a version of java that has a big security flaw for all that time, just because one didn't want to obsolete the package. Of course "obsoletes" shall not be taken lightly. But i the case for Java, the rationale that oracle gives for no longer having the distributor's license is that OpenJDK and Oracle's java are now very close, that they are no longer separate things, but that Oracle's Java just builds on top of OpenJDK. For people just in need for "java" there will hardly be any difference. People with a special need for specific versions of java can still download and install java from Oracle's site. It is not a case where installing OpenJDK would make using Oracle's java impossible/that you have to install OpenJDK in the first place. ciao Christian
Re: [Mageia-dev] Removal of sun java
Le 30/03/2012 15:04, Christian Lohmaier a écrit : Hi Dimitrios, *, On Fri, Mar 30, 2012 at 2:52 PM, Dimitrios Glentadakis wrote: [...] I interpreted Guillaume's approach as about the impact that can have Mageia's decisions in a system and the respect of the user and his system as a priority, but it was finally interpreted as he wants something for his personal use or he does nt care about a security issue, for the same reason. At least, is what i got. Well - that is what he said: "Don't push security updates to users by replacing package A by package B." Or: "I don't care that other people will continue using software with security flaws, since I know what I am doing." That is pure over-interpretation of my argumentation. I could be as well irrespective of your point of view by replying "you lie". -- BOFH excuse #49: Bogon emissions
Re: [Mageia-dev] Removal of sun java
Hi Guillaume, On Fri, Mar 30, 2012 at 3:11 PM, Guillaume Rousse wrote: > Le 30/03/2012 15:04, Christian Lohmaier a écrit : >> On Fri, Mar 30, 2012 at 2:52 PM, Dimitrios Glentadakis >> wrote: >> >> Well - that is what he said: >> "Don't push security updates to users by replacing package A by package >> B." >> Or: "I don't care that other people will continue using software with >> security flaws, since I know what I am doing." > > That is pure over-interpretation of my argumentation. I could be as well > irrespective of your point of view by replying "you lie". I think that paraphrasing matched what you were writing prettly closely. But let's use a few quotes then: "[...] don't treat uses as blatant idiots. If I want to keep a proprietary JRE [...] that is my choice, not yours." "I think I'm best placed than anyone else to evaluate the exact risk I'm facing on the machines I'm running [...]. The decision [...] belongs to me. You [Mageia] are not a system administrator [...], you are a technical solution provider. You're clearly confusing the roles here." If that is not reading: Don't push the security updates to the users, let the user take care of that manually, then what else? Sure, call me lying, but then I call you schizophrenic. ciao Christian
Re: [Mageia-dev] Freeze push: libmbfl
'Twas brillig, and Thomas Spuhler at 30/03/12 04:35 did gyre and gimble: > On Thursday, March 29, 2012 08:05:00 PM Remco Rijnders wrote: >> On Thu, Mar 29, 2012 at 07:50:10PM -0700, Thomas wrote in >> >> <201203291950.10882.tho...@btspuhler.com>: >>> On Wednesday, March 28, 2012 04:28:42 PM David Walser wrote: Colin Guthrie wrote: > We need to revert this ASAP or find a way to fix PHP to be compatible > and find out which other packages may be broken as a result. OK, I synced it with the version in Mageia 1 updates, so this is ready to go. I need a sysadmin to push it because of downgrading the version. Now it will be: libmbfl-1.1.0-6.mga2 >>> >>> David, can you please look at this again, it will not upgrade the way it >>> is (downgrade) >> >> Thomas, it is my understanding that this is how it should work? That is, >> downgrades should not be handled automatically in Cauldron. In the stable >> release, you'd increase the epoch. In Cauldron, everyone affected has to >> handle this manually as there we don't want to increase the epoch (which >> would eventually trickle down into stable, and we want to avoid using an >> epoch unless absolutely necessary). >> >> Just one of the downsides of running the development version on your >> machine as I understand it. >> >> Remmy > > It fixed the libmbfl problem. > I still get this warning. Google only shows it for php-5.4 RC > > # pear list-upgrades > PHP Warning: can't find symbol in Unknown on line 0 I can't reproduce here after installing the correct lib[64]mbfl and nuking the new one. 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] Removal of sun java
On Fri, 30 Mar 2012, Colin Guthrie wrote: > 'Twas brillig, and Guillaume Rousse at 30/03/12 10:17 did gyre and gimble: > > Using task-obsolete is fine: > > - its purpose is crystal-clear > > - if I don't want it, I don't install it > > > > Adding an obsolete tag in openjdk to remove sun jdk now, for security > > concernes, whereas we had suffered a useless mess of at least four > > available java environnement at once for years uselessly (excepted for > > blindly applying jpackage project practices), doesn't seems quite similar. > > Well think of it this way (assuming I have the facts vaguely straight): > > Forget about Cauldron and mga2 > > We're providing a known insecure version to mga1 users. > > We need to find a way to update mga1 somehow right? Or do we want to > just abandon them? > > Assuming we do not want to abandon them, what do we do? I'd suggest > shipping a new empty package that replaces it with a README.urpmi > telling them to go to Sun directly is the most responsible thing for us > to do. If they do not have a JRE installed, and they have packages that > require one, then they should be prompted to install e.g. openjdk to > satisfy package deps. That should work OK right? I think an empty package is not a good idea, it would be better to obsolete it in task-obsolete : - it's more clear that the package is obsoleted and is not a regular update. Users installing an empty package as update would only see that it is removed but not updated when it's already removed. - package is really removed and no longer listed as installed in rpm database - it's easy to add task-obsolete in urpmi skip.list for people who don't want unmaintained packages to be automatically removed
Re: [Mageia-dev] Removal of sun java
Le 30/03/2012 15:25, Christian Lohmaier a écrit : If that is not reading: Don't push the security updates to the users, let the user take care of that manually, then what else? That just means 'give the end user everything he needs to take a decision (advice, notification, packages, popup, whatever) but let him take this decision about this specific issue himself'. Let's try to move toward a consensus... Mixing removing of sun jdk with updating another jdk for security seems an unfair bundle, as you can't have one without another. Issuing a specific sun jdk security update package, containing only a README.urpmi file and a shell script inciting the user to read this file eventually, would be a fair compromise for me. And can be considered as a standard practice for semi-automatically removing very-dangerous-packages-we-cannot-afford-to-let-installed-anywhere-otherwise-the-apocalypse-will-happen. -- BOFH excuse #8: static buildup
Re: [Mageia-dev] Removal of sun java
On 30 March 2012 16:00, nicolas vigier wrote: >> Assuming we do not want to abandon them, what do we do? I'd suggest >> shipping a new empty package that replaces it with a README.urpmi >> telling them to go to Sun directly is the most responsible thing for us >> to do. If they do not have a JRE installed, and they have packages that >> require one, then they should be prompted to install e.g. openjdk to >> satisfy package deps. That should work OK right? > > I think an empty package is not a good idea, it would be better to > obsolete it in task-obsolete : > - it's more clear that the package is obsoleted and is not a regular > update. Users installing an empty package as update would only see that > it is removed but not updated when it's already removed. > - package is really removed and no longer listed as installed in rpm > database > - it's easy to add task-obsolete in urpmi skip.list for people who > don't want unmaintained packages to be automatically removed > In that case, I don't think so. We can thus popup a README.urpmi explaining what happened. Also user can find out this when running rpm -ql java-sun-foobar
Re: [Mageia-dev] Freeze push: libmbfl
On Friday, March 30, 2012 06:37:09 AM Colin Guthrie wrote: > 'Twas brillig, and Thomas Spuhler at 30/03/12 04:35 did gyre and gimble: > > On Thursday, March 29, 2012 08:05:00 PM Remco Rijnders wrote: > >> On Thu, Mar 29, 2012 at 07:50:10PM -0700, Thomas wrote in > >> > >> <201203291950.10882.tho...@btspuhler.com>: > >>> On Wednesday, March 28, 2012 04:28:42 PM David Walser wrote: > Colin Guthrie wrote: > > We need to revert this ASAP or find a way to fix PHP to be compatible > > and find out which other packages may be broken as a result. > > OK, I synced it with the version in Mageia 1 updates, so this is ready > to go. > > I need a sysadmin to push it because of downgrading the version. Now > it will be: libmbfl-1.1.0-6.mga2 > >>> > >>> David, can you please look at this again, it will not upgrade the way > >>> it is (downgrade) > >> > >> Thomas, it is my understanding that this is how it should work? That is, > >> downgrades should not be handled automatically in Cauldron. In the > >> stable release, you'd increase the epoch. In Cauldron, everyone > >> affected has to handle this manually as there we don't want to increase > >> the epoch (which would eventually trickle down into stable, and we want > >> to avoid using an epoch unless absolutely necessary). > >> > >> Just one of the downsides of running the development version on your > >> machine as I understand it. > >> > >> Remmy > > > > It fixed the libmbfl problem. > > I still get this warning. Google only shows it for php-5.4 RC > > > > # pear list-upgrades > > PHP Warning: can't find symbol in Unknown on line 0 > > I can't reproduce here after installing the correct lib[64]mbfl and > nuking the new one. > > Col Maybe there is some tray file around. can some else test it too? as root do pear list-upgrades -- Best regards Thomas Spuhler
[Mageia-dev] texlive need mf2pt1
I need to run, but want to get this up for discussion at one time mf2pt1 was removed from texlive, It was there somewhere in mga1 As a result, mscore does not build anymore adding the basic package texlive-mf2pts fixes it. I have it ready What I think would be preferable is to add it to texlive -- Best regards Thomas Spuhler
Re: [Mageia-dev] No time for maintainership
2012/3/30 Remco Rijnders : > python-yaml eandry I'll take this one
Re: [Mageia-dev] No time for maintainership
On Fri, 30 Mar 2012, Remco Rijnders wrote: > On Thu, Mar 29, 2012 at 09:52:04PM +0200, Emmanuel wrote in > <1333050724.11900.5.camel@manux-home>: >> Hi everyone, >> >> I hoped having time to work on my packages on mageia, but because of my >> spare time going shorter, I can't. >> >> Please feel free to maintain my packages. >> >> Thanks, and sorry for the delay of my feedback. > > Hi Emmanuel, > > Sorry to see you 'go', but thanks for letting us know and not disappearing > quietly and leaving us and your packages hanging in limbo. Hopefully your > lack of spare time is not caused by anything bad, and perhaps in the future > when this changes, you'll consider working on Mageia again. Thanks also for > the work you've done on these packages till now. obexd and libcanberra are now assigned to colin, python-yaml to philippem. And the following packages are assigned to nobody and can be taken : aubio autoscan brasero csound dconf eject empathy farsight2 fetchmail freerdp fuse ggz-gtk-client gnash gtk-engines2 irqbalance libagg libmtp libsvg libsvg-cairo lightspark modemmanager optipng orc physfs pngrewrite quesoglc remmina remmina-plugins stellarium udisks ultracopier usb_modeswitch usb_modeswitch-data
Re: [Mageia-dev] Freeze push: libmbfl
'Twas brillig, and Thomas Spuhler at 30/03/12 15:04 did gyre and gimble: > On Friday, March 30, 2012 06:37:09 AM Colin Guthrie wrote: >> 'Twas brillig, and Thomas Spuhler at 30/03/12 04:35 did gyre and gimble: >>> # pear list-upgrades >>> PHP Warning: can't find symbol in Unknown on line 0 >> >> I can't reproduce here after installing the correct lib[64]mbfl and >> nuking the new one. >> > Maybe there is some tray file around. can some else test it too? > as root do pear list-upgrades And if it fails for you, what is the output of: rpm -qa | grep mbfl If you see a 1.2 version of the lib there, you must downgrade manually - usual cauldron rules! 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] dropping mysql-workbench
Op vrijdag 30 maart 2012 10:11:34 schreef nicolas vigier: > On Thu, 29 Mar 2012, Maarten Vanraes wrote: > > unfortunately, atm it doesn't work, so it needs to be rebuilt, but it > > doesn't rebuild at all... and since we're in version freeze, you can't > > just update to a new version. even more is that soon is release > > freeze... > > No, fixing a package that doesn't work can be a good reason for version > freeze exception. So if a new version can help fix the problem, it > should be considered. ic, well in that case, i guess it can be done like this, but if there's no maintainer for it... personally, i have no problem with this being dropped. which is not to say i'm trying to hurt people who use it... but if we can't maintain a package, maybe it's better if the people who want to use it, can get it from upstream themselves. and since this is from oracle, i guess the maintainer should also doublecheck licensing to be on the safe side, since oracle has relicensed quite some code. who knows, maybe we can't even redistribute it anymore...
Re: [Mageia-dev] Removal of sun java
Op vrijdag 30 maart 2012 16:00:22 schreef nicolas vigier: [...] > I think an empty package is not a good idea, it would be better to > obsolete it in task-obsolete : > - it's more clear that the package is obsoleted and is not a regular >update. Users installing an empty package as update would only see that >it is removed but not updated when it's already removed. > - package is really removed and no longer listed as installed in rpm >database > - it's easy to add task-obsolete in urpmi skip.list for people who >don't want unmaintained packages to be automatically removed wrt to task-obsolete, do the users get notified? maybe a README.urpmi listing all the packages and reasons would be an option to get notified?
Re: [Mageia-dev] Removal of sun java
Op vrijdag 30 maart 2012 16:03:14 schreef Guillaume Rousse: [...] > Issuing a specific sun jdk security update package, containing only a > README.urpmi file and a shell script inciting the user to read this file > eventually, would be a fair compromise for me. And can be considered as > a standard practice for semi-automatically removing > very-dangerous-packages-we-cannot-afford-to-let-installed-anywhere-otherwis > e-the-apocalypse-will-happen. if at all possible, i'd like a similar solution, but with task-obsolete somehow, since it ties in nicely with all the related stuff (iiuc above) but i think it is nice to have such a notification with such kind of packages... ie: if we're proposing to delete something, i'd rather know why...
Re: [Mageia-dev] dropping mysql-workbench
On Fri, Mar 30, 2012 at 05:33:31PM +0200, Maarten wrote in <201203301733.31821.al...@rmail.be>: Op vrijdag 30 maart 2012 10:11:34 schreef nicolas vigier: On Thu, 29 Mar 2012, Maarten Vanraes wrote: > unfortunately, atm it doesn't work, so it needs to be rebuilt, but it > doesn't rebuild at all... and since we're in version freeze, you can't > just update to a new version. even more is that soon is release > freeze... No, fixing a package that doesn't work can be a good reason for version freeze exception. So if a new version can help fix the problem, it should be considered. ic, well in that case, i guess it can be done like this, but if there's no maintainer for it... personally, i have no problem with this being dropped. which is not to say i'm trying to hurt people who use it... but if we can't maintain a package, maybe it's better if the people who want to use it, can get it from upstream themselves. Not arguing about this... but I think the attached patch fixes at least (part) of the build problem (for the new maintainer to look into ;-) See also http://bugs.mysql.com/bug.php?id=63898 and since this is from oracle, i guess the maintainer should also doublecheck licensing to be on the safe side, since oracle has relicensed quite some code. who knows, maybe we can't even redistribute it anymore... I didn't check that... but I did notice that the tarball from upstream (now at 5.2.38) has "gpl" in its name, so assume that's still safe... --- wb.utils_Makefile.am2012-03-30 17:25:18.219213799 +0200 +++ modules/wb.utils/Makefile.am2012-03-30 17:27:00.259785100 +0200 @@ -1,6 +1,6 @@ pkglibdir=$(libdir)/@PACKAGE@/modules -pkglib_DATA=catalog_utils.grt.lua tools.grt.lua wb_utils_grt.py sqlide_grt.py text_grt.py sql_reformatter.py\ +pkgdata_DATA=catalog_utils.grt.lua tools.grt.lua wb_utils_grt.py sqlide_grt.py text_grt.py sql_reformatter.py\ wb_dev_utils_grt.py table_utils_grt.py code_utils_grt.py --- swig_Makefile.am2012-03-30 17:25:44.006350969 +0200 +++ library/forms/swig/Makefile.am 2012-03-30 17:27:00.260785106 +0200 @@ -2,7 +2,7 @@ pkglib_LTLIBRARIES=_mforms.la pkglibdir=$(libdir)/@PACKAGE@/modules -pkglib_DATA=mforms.py +pkgdata_DATA=mforms.py _mforms_la_SOURCES=\ mforms_wrap.cxx --- wb.doclib_Makefile.am 2012-03-30 17:26:19.209546254 +0200 +++ plugins/wb.doclib/Makefile.am 2012-03-30 17:27:00.260785106 +0200 @@ -1,7 +1,7 @@ pkglibdir=$(libdir)/@PACKAGE@/modules -pkglib_DATA=\ +pkgdata_DATA=\ mysqldoclib.py\ wb_doclib_grt.py --- frontend_Makefile.am2012-03-30 17:26:45.481698315 +0200 +++ plugins/wb.admin/frontend/Makefile.am 2012-03-30 17:27:00.260785106 +0200 @@ -1,7 +1,7 @@ pkglibdir=$(libdir)/@PACKAGE@/modules -pkglib_DATA=\ +pkgdata_DATA=\ wb_admin_grt.py\ wb_admin_monitor.py\ wb_admin_utils.py\ pgpvIc8KzjtMj.pgp Description: PGP signature
Re: [Mageia-dev] Removal of sun java
Am 30.03.2012 17:39, schrieb Maarten Vanraes: Op vrijdag 30 maart 2012 16:00:22 schreef nicolas vigier: [...] I think an empty package is not a good idea, it would be better to obsolete it in task-obsolete : - it's more clear that the package is obsoleted and is not a regular update. Users installing an empty package as update would only see that it is removed but not updated when it's already removed. - package is really removed and no longer listed as installed in rpm database - it's easy to add task-obsolete in urpmi skip.list for people who don't want unmaintained packages to be automatically removed wrt to task-obsolete, do the users get notified? maybe a README.urpmi listing all the packages and reasons would be an option to get notified? And how do you decide, when to put which warning in it? If you leave a warnign in it for too long, the user will get notified again and again and again on each update of task-obsolete. If you change the warnings every release of task-obsolte a user not updating frequently will miss some. But in this case, why not replacing the java sun packages by an empty package obsoleting the whole java sun stack <= our last package and showing the information via README.urpmi file and obsoleting that package in say two months so it will be completely gone? Oliver
Re: [Mageia-dev] Removal of sun java
30.03.2012 17:04, Thierry Vignaud kirjutas: On 30 March 2012 16:00, nicolas vigier wrote: Assuming we do not want to abandon them, what do we do? I'd suggest shipping a new empty package that replaces it with a README.urpmi telling them to go to Sun directly is the most responsible thing for us to do. If they do not have a JRE installed, and they have packages that require one, then they should be prompted to install e.g. openjdk to satisfy package deps. That should work OK right? I think an empty package is not a good idea, it would be better to obsolete it in task-obsolete : - it's more clear that the package is obsoleted and is not a regular update. Users installing an empty package as update would only see that it is removed but not updated when it's already removed. - package is really removed and no longer listed as installed in rpm database - it's easy to add task-obsolete in urpmi skip.list for people who don't want unmaintained packages to be automatically removed In that case, I don't think so. We can thus popup a README.urpmi explaining what happened. Also user can find out this when running rpm -ql java-sun-foobar We can obsolete it in mga2 and create an empty package for mga 1, explaining what's happening. So in mga2 we get rid of it and in mga1 people are warned that it's now removed because of its security issues. -- Sander
Re: [Mageia-dev] Freeze Push, liferea 1.8.4
Le Thu, 29 Mar 2012 20:31:12 +0200, Julien a écrit : > Le Wed, 28 Mar 2012 18:38:46 +0200, > Julien a écrit : > > > Hello, > > > > please push liferea 1.8.4 which fix a crash and some bugs related to > > performance and usability. > > > > thanks > > regards > > Julien > > ping ? ping ?
Re: [Mageia-dev] Removal of sun java
Em 30-03-2012 13:50, Jerome Quelin escreveu: On 12/03/30 13:19 +0200, D.Morgan wrote: is sun java of any use ? in france, to declare our salaries before taxes are applied, the web app used to require a "trusted" version of java - that is, sun jdk. i don't know if openjdk works nowadays. This is no more true for 3 years the overkill java applet to sign is gone.
Re: [Mageia-dev] [RFC] How to proceed with seamonkey/iceape for security updates and freeze push
On Thu, Mar 29, 2012 at 12:13:02PM +0200, nicolas vigier wrote: > It seems that if we don't have major changes, there should be no problem > to have permission. So I think someone should ask for permission for > firefox and thunderbird. Does anyone know where it should be asked ? The page at http://www.mozilla.org/foundation/trademarks/policy.html describes the policy. The policy covers the case of compiling from pristine sources: If you compile Mozilla unmodified source code (including code and config files in the installer) and do not charge for it, you do not need additional permission from Mozilla to use the relevant Mozilla Mark(s) for your compiled version. and the case of highly modified source: If you're...making significant functional changes, you may not redistribute the fruits of your labor under any Mozilla trademark, without Mozilla's prior written consent. and in a final section, also the case of making minor changes: Again, any modification to the Mozilla product...will require our permission if you want to use the Mozilla Marks. So, if we're applying any patches at all, we'll need to ask permission. >>> Dan
[Mageia-dev] Servers downtime
Hello, We have a temporary problem with the servers that are hosted in Marseille. The switch on which our servers are connected is having some problem, so the servers are unavailable. We will maybe need to replace the switch with a new one. Main afected services are : - build system - sympa mailing lists - bugzilla - forum - svn - identity - wiki - mirrors database
[Mageia-dev] Problems with flash 11.2
Hi... Is anybody else seeing strange things with flash 11.2 ? In my nvidia boxes it looks like I'm always seeing avatars in pandora... Looks like red and blue channels are switched. Try this: http://www.youtube.com/results?search_query=ntsc+color+bars look at the thumbnail, and then to the video (lookin close to the two rightmost bars...). It doesn't happen on intel graphics. My system is 64bit and nvidia. Still have to try on 32bit with older nvidia card (7600GT). Somebody else ? -- J.A. Magallon \ Winter is coming...
Re: [Mageia-dev] Problems with flash 11.2
On 03/31/2012 02:12 AM, JA Magallón wrote: Hi... Is anybody else seeing strange things with flash 11.2 ? In my nvidia boxes it looks like I'm always seeing avatars in pandora... Looks like red and blue channels are switched. Try this: http://www.youtube.com/results?search_query=ntsc+color+bars look at the thumbnail, and then to the video (lookin close to the two rightmost bars...). It doesn't happen on intel graphics. My system is 64bit and nvidia. Still have to try on 32bit with older nvidia card (7600GT). Somebody else ? Googling a bit more and with some experiments, I found the problem. Channels are swapped if you use accelerated video rendering but software decoding. If both are soft, or both accelerated there is no problem. And, btw, to get hw video decoding I had to write a file in /etc/adobe/mms.cfg with EnableLinuxHWVideoDecode=1 There are some more settings here http://wiki.debian.org/FlashPlayer and a fully commented file here http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/www-plugins/adobe-flash/files/mms.cfg I don't know how useful are the rest, but this one really enables HW in my nvidia card. Perhaps it should be a good idea to add it to the rpm, after downloading binaries. If it does not cause trouble in other chipsets. Will try on intel... -- J.A. Magallon \ Winter is coming...
Re: [Mageia-dev] Freeze push: libmbfl
On Friday, March 30, 2012 07:59:17 AM Colin Guthrie wrote: > 'Twas brillig, and Thomas Spuhler at 30/03/12 15:04 did gyre and gimble: > > On Friday, March 30, 2012 06:37:09 AM Colin Guthrie wrote: > >> 'Twas brillig, and Thomas Spuhler at 30/03/12 04:35 did gyre and gimble: > >>> # pear list-upgrades > >>> PHP Warning: can't find symbol in Unknown on line 0 > >> > >> I can't reproduce here after installing the correct lib[64]mbfl and > >> nuking the new one. > > > > Maybe there is some tray file around. can some else test it too? > > as root do pear list-upgrades > > And if it fails for you, what is the output of: > > rpm -qa | grep mbfl > > If you see a 1.2 version of the lib there, you must downgrade manually - > usual cauldron rules! > > Col rpm -qa | grep mbfl lib64mbfl-devel-1.1.0-6.mga2 lib64mbfl1-1.1.0-6.mga2 -- Best regards Thomas Spuhler
Re: [Mageia-dev] Problems with flash 11.2
Στις 31/03/2012 02:38:24 JA Magallón γράψατε: > And, btw, to get hw video decoding I had to write a file in /etc/adobe/mms.cfg > with > > EnableLinuxHWVideoDecode=1 Thanks, this solved the problem for me -- Dimitrios Glentadakis
Re: [Mageia-dev] Problems with flash 11.2
Στις 31/03/2012 08:38:19 γράψατε: > Στις 31/03/2012 02:38:24 JA Magallón γράψατε: > > And, btw, to get hw video decoding I had to write a file in > > /etc/adobe/mms.cfg > > with > > > > EnableLinuxHWVideoDecode=1 > > Thanks, this solved the problem for me > > > i had to reverse to disable hw acceleration because the embedded youtube videos in konqueror are invisible (in youtube it is ok) -- Dimitrios Glentadakis
