Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
On Thu, 07 Jul 2011, Wolfgang Bornath wrote: I must admit I do not understand the cause of this discussion, maybe I am thinking in too simple ways. Free goes in core, non-free goes in non-free. If a non-free software has a restrictive license it goes in tainted. A free software can not have a restrictive license, if it has it is not free and goes in tainted. Tainted is not about restrictive license but patents. A free software can have a free license, but do something which is maybe patented.
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
2011/7/7 nicolas vigier bo...@mars-attacks.org: On Thu, 07 Jul 2011, Wolfgang Bornath wrote: I must admit I do not understand the cause of this discussion, maybe I am thinking in too simple ways. Free goes in core, non-free goes in non-free. If a non-free software has a restrictive license it goes in tainted. A free software can not have a restrictive license, if it has it is not free and goes in tainted. Tainted is not about restrictive license but patents. A free software can have a free license, but do something which is maybe patented. Yes, right. I made a mistake there - just replace restrictive license with patents in my sentence. -- wobo
Re: [Mageia-dev] Updates testing
On Wed, 06 Jul 2011, José Jorge wrote: Le mercredi 6 juillet 2011 18:12:44, nicolas vigier a écrit : Hello, A few package updates need testing on x86_64 (they have been tested on i586, thanks to Dave Hodgins) : https://bugs.mageia.org/show_bug.cgi?id=1944 https://bugs.mageia.org/show_bug.cgi?id=1485 https://bugs.mageia.org/show_bug.cgi?id=1892 https://bugs.mageia.org/show_bug.cgi?id=1939 All tested, but without a testcase, some are hard to test. Yes, testcase need to be done for each package. Maybe we could have a wiki page to save all test cases, and use them when the same package is updated again ?
Re: [Mageia-dev] Updates process is now available
On Tue, 21 Jun 2011, Damien Lallement wrote: Hello all, security, qa and sysadmin team worked on the qa/updates process to provide updates as soon as possible. All is now ready (boklm is finalizing a scrip to move updates from testing to updates). This script will be uses by security team members and a few QA people to push updates. You can now read: - http://www.mageia.org/wiki/doku.php?id=updates_policy - http://www.mageia.org/wiki/doku.php?id=qa_updates I have some questions about updates process : The page says to assign bug after validation : Assign the bug to secur...@groups.mageia.org if it's a security update (check that qa-b...@ml.mageia.org is in 'CC') Let it assigned to qa-b...@ml.mageia.org if it's a standard update Is it usefull to assign differently for security and non-security updates ? Could we add a keyword validated_update to bugs that are ready to be moved to updates, so they can be found easily ?
Re: [Mageia-dev] Updates testing
Le 07/07/2011 14:18, nicolas vigier a écrit : On Wed, 06 Jul 2011, José Jorge wrote: Le mercredi 6 juillet 2011 18:12:44, nicolas vigier a écrit : Hello, A few package updates need testing on x86_64 (they have been tested on i586, thanks to Dave Hodgins) : https://bugs.mageia.org/show_bug.cgi?id=1944 https://bugs.mageia.org/show_bug.cgi?id=1485 https://bugs.mageia.org/show_bug.cgi?id=1892 https://bugs.mageia.org/show_bug.cgi?id=1939 All tested, but without a testcase, some are hard to test. Yes, testcase need to be done for each package. Maybe we could have a wiki page to save all test cases, and use them when the same package is updated again ? No need to put this on the wiki as it will be useless for 90% of them as an update request must have a test case for the bug fixed, not for the whole package. So for me, it will be better if packagers follow the update policy and provide a testcase for each package. Dams -- Damien Lallement Treasurer of Mageia.Org twitter: damsweb - IRC: damsweb/coincoin
Re: [Mageia-dev] Updates testing
On Thu, 07 Jul 2011, Damien Lallement wrote: Le 07/07/2011 14:18, nicolas vigier a écrit : On Wed, 06 Jul 2011, José Jorge wrote: Le mercredi 6 juillet 2011 18:12:44, nicolas vigier a écrit : Hello, A few package updates need testing on x86_64 (they have been tested on i586, thanks to Dave Hodgins) : https://bugs.mageia.org/show_bug.cgi?id=1944 https://bugs.mageia.org/show_bug.cgi?id=1485 https://bugs.mageia.org/show_bug.cgi?id=1892 https://bugs.mageia.org/show_bug.cgi?id=1939 All tested, but without a testcase, some are hard to test. Yes, testcase need to be done for each package. Maybe we could have a wiki page to save all test cases, and use them when the same package is updated again ? No need to put this on the wiki as it will be useless for 90% of them as an update request must have a test case for the bug fixed, not for the whole package. Yes, for the test about the bug fixed. But isn't there tests to check for regressions ?
Re: [Mageia-dev] Updates process is now available
Le 07/07/2011 14:42, nicolas vigier a écrit : On Tue, 21 Jun 2011, Damien Lallement wrote: Hello all, security, qa and sysadmin team worked on the qa/updates process to provide updates as soon as possible. All is now ready (boklm is finalizing a scrip to move updates from testing to updates). This script will be uses by security team members and a few QA people to push updates. You can now read: - http://www.mageia.org/wiki/doku.php?id=updates_policy - http://www.mageia.org/wiki/doku.php?id=qa_updates I have some questions about updates process : The page says to assign bug after validation : Assign the bug to secur...@groups.mageia.org if it's a security update (check that qa-b...@ml.mageia.org is in 'CC') Let it assigned to qa-b...@ml.mageia.org if it's a standard update Is it usefull to assign differently for security and non-security updates ? Could we add a keyword validated_update to bugs that are ready to be moved to updates, so they can be found easily ? I just write this because that's what was discuss on the meeting at this time with misc, ennael, stew and I (you were here too IIRC). We can discuss this point again if needed. :-) The idea was just not to assign package to secteam if not a secteam update (not to distrub them for standard packages). -- Damien Lallement Treasurer of Mageia.Org twitter: damsweb - IRC: damsweb/coincoin
Re: [Mageia-dev] openldap-server needs rebuild agains new db51
On Thursday, 7 July 2011 06:38:44 Thomas Spuhler wrote: openldap-server needs rebuild against new db51 otherwise a lot of packages want to be uninstalled Please wait for 2.4.26 which is in progress (well, submitted to Mandriva cooker, building on my internal build system for RH-based systems, to be synced to Mageia as soon as I have time). Regards, Buchan
Re: [Mageia-dev] Updates process is now available
On Thu, 07 Jul 2011, Damien Lallement wrote: Le 07/07/2011 14:42, nicolas vigier a écrit : On Tue, 21 Jun 2011, Damien Lallement wrote: Hello all, security, qa and sysadmin team worked on the qa/updates process to provide updates as soon as possible. All is now ready (boklm is finalizing a scrip to move updates from testing to updates). This script will be uses by security team members and a few QA people to push updates. You can now read: - http://www.mageia.org/wiki/doku.php?id=updates_policy - http://www.mageia.org/wiki/doku.php?id=qa_updates I have some questions about updates process : The page says to assign bug after validation : Assign the bug to secur...@groups.mageia.org if it's a security update (check that qa-b...@ml.mageia.org is in 'CC') Let it assigned to qa-b...@ml.mageia.org if it's a standard update Is it usefull to assign differently for security and non-security updates ? Could we add a keyword validated_update to bugs that are ready to be moved to updates, so they can be found easily ? I just write this because that's what was discuss on the meeting at this time with misc, ennael, stew and I (you were here too IIRC). We can discuss this point again if needed. :-) The idea was just not to assign package to secteam if not a secteam update (not to distrub them for standard packages). Yes, but what is the difference between pushing standard update, and security update, after qa is done, and why should we disturb them for security updates, and not for standard updates ?
Re: [Mageia-dev] Arm, meeting, etc
Op woensdag 06 juli 2011 22:45:28 schreef Michael Scherer: Le lundi 04 juillet 2011 à 14:12 +0200, Michael Scherer a écrit : Hi, In order to discuss details in a more open fashion , a meeting have been planed for 6 juillet, in the afternoon around 13h UTC ( paris time, 15h ). We will use #mageia-meeting, and the goal is : 1) see who is interested by arm ( if you are but cannot be there, please say it on irc ) 2) see if the task decided for the previous IRL meeting have been caried So, no one came :( ( I blame the time we chose ). Anyway, discussing with rtp, he told me : - there is some issue with the pandaboard ( like oom killer without much reason ) - there is also some issue if we have external power and usb on the go So maybe we need to find another way to discuss this than irc ? oops, i am mildly interested in it. i still want a small cheap nas that doesn't use alot of power, so i'm thinking about arm stuff... and if i have it, i can test it with mageia (if it can run on it, of course)
[Mageia-dev] task-kde4*
I suggest to obsolete the 4.6.4 versions of task-kde4 task-kde4-minimal task-kde4-debug as to match the new package fragmentation of KDE 4.6.90. (Just removing them orphans packages, and unorphaning them is annoying.) I am already cursing the whole KDE f*ing team for the new fragmentation, because this affects *all* the packages that have BuildRequires: kdegraphics4-devel and I still don't know what the correct BuildRequires would be under 4.6.90. (I am impatiently waiting for Win8, maybe this would alleviate my pains with Linux.) R-C aka beranger
Re: [Mageia-dev] task-kde4*
On Thursday 07 July 2011 11:05:15 Radu-Cristian FOTESCU wrote:
I suggest to obsolete the 4.6.4 versions of
task-kde4
task-kde4-minimal
task-kde4-debug
as to match the new package fragmentation of KDE 4.6.90.
(Just removing them orphans packages, and unorphaning them is annoying.)
We'll keep thoses packages because they're still useful however we need to
work on them:
For example we need to define what's a minimal kde4 installation ,what's a «
full » kde installation, they also should match the task-{xfce|gnome|lxde}
package too
For example from my point of view task-kde-minimal should really install
*only* a minimum of kde app like the desktop (with few plasmoids) , a web
browser, an editor, a terminal...
When the task-kde could provides an irc client, more plasmoid, an agenda
(korganizer for example) etc etc.
I am already cursing the whole KDE f*ing team for the new fragmentation,
because this affects *all* the packages that have BuildRequires:
kdegraphics4-devel
I'm not sure we still have a lot of packages which requires kdegraphics4-devel
as buildrequires according to http://check.mageia.org/dependencies.html
calligra is the only one package mentionned on this url and i fixed it already
on svn (i did not push it because it's quite a big package)
Currently kdedindings4 is the missing part of KDE SC, i pushed smokekde
(without kdepimlibs support as suggested by fwang since smokegen seems to
crash with akonadi) and i guess fwang is going to finish others subpackage
soon.
Regarding digikam2 Ze is working on it i guess it's probably appears soon.
and I still don't know what the correct BuildRequires would be under 4.6.90.
For which package ?
(I am impatiently waiting for Win8, maybe this would alleviate my pains
with Linux.)
Well MacOS X Lion is probably the way to go :)
Regards,
--
Balcaen John
Jabber ID: mik...@jabber.littleboboy.net
Re: [Mageia-dev] task-kde4*
Well MacOS X Lion is probably the way to go :) mikala, I would rather support anal rape than to pay a single cent to Apple! R-C
Re: [Mageia-dev] Updates testing
2011/7/7 nicolas vigier bo...@mars-attacks.org: Yes, for the test about the bug fixed. But isn't there tests to check for regressions ? when you push a new minor version (only bugfix) for softwares like LibreOffice, Postgresql or Firebird for example, will the Mageia QA team run tests for regression and for all bug fixed ? wh !
[Mageia-dev] PPA-like repos
Hi folks, don't know if it was discussed previously, but I could not find it in the archives. Are there some plans for any kind of ppa-like repos in Mageia/BS? There are some cases where they could be useful. One special case which comes to mind is wayland packaging - I was discussing with Florian Hubold about it, and the trick about them is that: - they require latest xorg stuff from git - they require latest mesa from git - they require latest libxkbcommon from git - they require latest pixman from git and it is, well, madness to provide such versions in main repositories. However, it would be a nice case for providing them in some sort of private branch (like for example people.mageia.org/branch/ or something), using the same BS infrastructure (iurt/jurt) to compile them and generate hdlists automatically. I did some custom scripts to do this task, but before reinventing the wheel for either mandriva or mageia BS, perhaps there is something already planned in this sense... Cheers, -- Eugeni Dodonov http://eugeni.dodonov.net/
Re: [Mageia-dev] PPA-like repos
Le jeudi 07 juillet 2011 à 17:50 -0300, Eugeni Dodonov a écrit : Hi folks, don't know if it was discussed previously, but I could not find it in the archives. Are there some plans for any kind of ppa-like repos in Mageia/BS? There are some cases where they could be useful. One special case which comes to mind is wayland packaging - I was discussing with Florian Hubold about it, and the trick about them is that: - they require latest xorg stuff from git - they require latest mesa from git - they require latest libxkbcommon from git - they require latest pixman from git and it is, well, madness to provide such versions in main repositories. However, it would be a nice case for providing them in some sort of private branch (like for example people.mageia.org/branch/ or something), using the same BS infrastructure (iurt/jurt) to compile them and generate hdlists automatically. I did some custom scripts to do this task, but before reinventing the wheel for either mandriva or mageia BS, perhaps there is something already planned in this sense... There is nothing planned yet. ( we do not even have enough servers to have a shell for packagers or others :/ ) The problem I see with ppa is they lack basic quality control, they often interfere with upgrade and when they break, people blame the distribution. There is also non user friendly inter-ppa requires. So personally, I would rather try to ease the usage of iurt first ( wit documentation , etc ) and let people host everything them self. Having this on our servers would mean to most people we endorse the package, and I think we shouldn't unless we are sure of the quality ( which usually mean adding rules that people will complain about until they open 3rd party repository saying how much we are useless because we couldn't provide 'foo' rpm in a updated optimized version ). -- Michael Scherer
Re: [Mageia-dev] PPA-like repos
On Thu, Jul 7, 2011 at 18:29, Michael Scherer m...@zarb.org wrote:
The problem I see with ppa is they lack basic quality control, they
often interfere with upgrade and when they break, people blame the
distribution. There is also non user friendly inter-ppa requires.
So personally, I would rather try to ease the usage of iurt first ( wit
documentation , etc ) and let people host everything them self. Having
this on our servers would mean to most people we endorse the package,
and I think we shouldn't unless we are sure of the quality
( which usually mean adding rules that people will complain about until
they open 3rd party repository saying how much we are useless because we
couldn't provide 'foo' rpm in a updated optimized version ).
The only major problem with hosting iurt/jurt/whatever is that it requires
either full repositories locally or very good network connection for
everything, and - in both cases - tons of disk space..
But yes, I got your point, and I agree with it. Perhaps instead of full
'PPAs' it would be possible to have some sort of iurt-powered public
repositories. For example, http://people/~user dirs with 'upload'
directory there, where someone could put src.rpms and they would be
recompiled and stored in http://people.../~user/{i586,x86_64,arm} when done,
with full hdlists.
But as for QA, yes, this is true. Probably the best solution for it was
Meego's one, in the n800 era - when you install something from non-official
repo it shows a window saying 'You are installing something that could break
everything, so you are on your own, good luck'. For install/update, perhaps
it could be solved by adding some new installer/updater window which would
check of enabled urpmi medias, and if there are any non-official one, it
could show a warning or something like it as well.
--
Eugeni Dodonov
http://eugeni.dodonov.net/
Re: [Mageia-dev] PPA-like repos
Le 07/07/2011 23:38, Eugeni Dodonov a écrit :
But yes, I got your point, and I agree with it. Perhaps instead of full
'PPAs' it would be possible to have some sort of iurt-powered public
repositories. For example, http://people/~user dirs with 'upload'
directory there, where someone could put src.rpms and they would be
recompiled and stored in http://people.../~user/{i586,x86_64,arm} when done,
with full hdlists.
This solutions means more and more servers :/
--
Sandro Cazzaniga - https://lederniercoupdarchet.wordpress.com
IRC: Kharec (irc.freenode.net)
Software/Hardware geek
Conceptor
Magnum's Coordinator/editor (http://magnum.tuxfamily.org)
Mageia and Mandriva contributor
Re: [Mageia-dev] PPA-like repos
On Thu, Jul 7, 2011 at 18:40, Cazzaniga Sandro
cazzaniga.san...@gmail.comwrote:
Le 07/07/2011 23:38, Eugeni Dodonov a écrit :
But yes, I got your point, and I agree with it. Perhaps instead of full
'PPAs' it would be possible to have some sort of iurt-powered public
repositories. For example, http://people/~user dirs with 'upload'
directory there, where someone could put src.rpms and they would be
recompiled and stored in http://people.../~user/{i586,x86_64,arm} when
done,
with full hdlists.
This solutions means more and more servers :/
Or some smart scheduling, which would only recompile such packages when BS
load is below 1 for example.
--
Eugeni Dodonov
http://eugeni.dodonov.net/
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
Wolfgang Bornath a écrit : 2011/7/7 nicolas vigierbo...@mars-attacks.org: On Thu, 07 Jul 2011, Wolfgang Bornath wrote: I must admit I do not understand the cause of this discussion, maybe I am thinking in too simple ways. Free goes in core, non-free goes in non-free. If a non-free software has a restrictive license it goes in tainted. A free software can not have a restrictive license, if it has it is not free and goes in tainted. Tainted is not about restrictive license but patents. A free software can have a free license, but do something which is maybe patented. Yes, right. I made a mistake there - just replace restrictive license with patents in my sentence. free means that it can be redistributed with source code, with a free/open source license. non-free (in terms of the repos) means that it can be redistributed, but either not with source code, according to the license + or we simply don't have/can't get the source code. tainted was mostly for packages affected to some extent by tainted patents. Such packages could be free or non-free, that has nothing to do with being in tainted. Some discussions in the past considered that the likelihood of a patent impacting a particular software (in the few countries that do accept software packages to some extent, like the USA), should affect whether it goes into tainted or not. I don't know what consensus there was on this point, if any. There were some suggestions that non-free packages should go into non-free, even if considered subject to tainted patents. And some proposed excluding such packages. So the question is, should a non-free package potentially affected by patents go into non-free or tainted. Those more interested in using free as much as possible, might tend to say non-free, especially if they use tainted. So as to avoid using any non-free packages. Those who consider patents legitimate, among others, might tend to say tainted, especially if they use non-free. So as to avoid using any software which might be subject to patents. If they live in an area where software patents risk to be found legitimate, such as the USA. Of course, those who don't use non-free (except for software coming from it's manufacturer) or tainted, wouldn't be concerned by this question. -- André
Re: [Mageia-dev] Updates testing
On 07/07/2011 07:38 PM, andre999 wrote: All tested, but without a testcase, some are hard to test. Yes, testcase need to be done for each package. Maybe we could have a wiki page to save all test cases, and use them when the same package is updated again ? No need to put this on the wiki as it will be useless for 90% of them as an update request must have a test case for the bug fixed, not for the whole package. Yes, for the test about the bug fixed. But isn't there tests to check for regressions ? The general idea sounds good. But that would make a pretty big wiki page, if we especially if we include big apps like LibreOffice Postgresql. Maybe link each bigger app to a standing bugz report for that purpose ? It would be pretty hard to make even close to complete regression tests for bigger apps as well. (imagine 599 tests for LibreOffice ...) There once was a project at Mandriva where each packager was to supposed to come up with a basic functionality test for his/her package(s), although I don't think it got much traction aside from those of us who were getting paid to work on the distro and whose manager made the tests a deliverable. iirc there was even some automation framework so they they could be run by machine. -- Stew Benedict
Re: [Mageia-dev] Updates testing
On Thu, Jul 7, 2011 at 21:01, Stew Benedict stewbi...@gmail.com wrote: There once was a project at Mandriva where each packager was to supposed to come up with a basic functionality test for his/her package(s), although I don't think it got much traction aside from those of us who were getting paid to work on the distro and whose manager made the tests a deliverable. iirc there was even some automation framework so they they could be run by machine. Are you talking about testcould by a chance? -- Eugeni Dodonov http://eugeni.dodonov.net/
Re: [Mageia-dev] openldap-server needs rebuild agains new db51
On Thursday, July 07, 2011 08:06:41 am Buchan Milne wrote: On Thursday, 7 July 2011 06:38:44 Thomas Spuhler wrote: openldap-server needs rebuild against new db51 otherwise a lot of packages want to be uninstalled Please wait for 2.4.26 which is in progress (well, submitted to Mandriva cooker, building on my internal build system for RH-based systems, to be synced to Mageia as soon as I have time). Regards, Buchan This is why I didn't touch it, the maintainer knows best how to fix it. -- Thomas
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
2011/7/8 andre999 and...@laposte.net: Wolfgang Bornath a écrit : 2011/7/7 nicolas vigierbo...@mars-attacks.org: On Thu, 07 Jul 2011, Wolfgang Bornath wrote: I must admit I do not understand the cause of this discussion, maybe I am thinking in too simple ways. Free goes in core, non-free goes in non-free. If a non-free software has a restrictive license it goes in tainted. A free software can not have a restrictive license, if it has it is not free and goes in tainted. Tainted is not about restrictive license but patents. A free software can have a free license, but do something which is maybe patented. Yes, right. I made a mistake there - just replace restrictive license with patents in my sentence. free means that it can be redistributed with source code, with a free/open source license. non-free (in terms of the repos) means that it can be redistributed, but either not with source code, according to the license + or we simply don't have/can't get the source code. tainted was mostly for packages affected to some extent by tainted patents. Such packages could be free or non-free, that has nothing to do with being in tainted. Some discussions in the past considered that the likelihood of a patent impacting a particular software (in the few countries that do accept software packages to some extent, like the USA), should affect whether it goes into tainted or not. I don't know what consensus there was on this point, if any. That exactly was the reason why tainted was created. The gathering of such software in one repo to make it easy for users and mirror maintainers in those countries to avoid them if they chose (or are forced) to do so. -- wobo
Re: [Mageia-dev] Updates testing
Stew Benedict a écrit : On 07/07/2011 07:38 PM, andre999 wrote: All tested, but without a testcase, some are hard to test. Yes, testcase need to be done for each package. Maybe we could have a wiki page to save all test cases, and use them when the same package is updated again ? No need to put this on the wiki as it will be useless for 90% of them as an update request must have a test case for the bug fixed, not for the whole package. Yes, for the test about the bug fixed. But isn't there tests to check for regressions ? The general idea sounds good. But that would make a pretty big wiki page, if we especially if we include big apps like LibreOffice Postgresql. Maybe link each bigger app to a standing bugz report for that purpose ? It would be pretty hard to make even close to complete regression tests for bigger apps as well. (imagine 599 tests for LibreOffice ...) There once was a project at Mandriva where each packager was to supposed to come up with a basic functionality test for his/her package(s), although I don't think it got much traction aside from those of us who were getting paid to work on the distro and whose manager made the tests a deliverable. iirc there was even some automation framework so they they could be run by machine. That sounds like a good idea -- especially if we could implement it in a manner easy to do for packagers -- André
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
Wolfgang Bornath a écrit : 2011/7/8 andre999and...@laposte.net: Wolfgang Bornath a écrit : 2011/7/7 nicolas vigierbo...@mars-attacks.org: On Thu, 07 Jul 2011, Wolfgang Bornath wrote: I must admit I do not understand the cause of this discussion, maybe I am thinking in too simple ways. Free goes in core, non-free goes in non-free. If a non-free software has a restrictive license it goes in tainted. A free software can not have a restrictive license, if it has it is not free and goes in tainted. Tainted is not about restrictive license but patents. A free software can have a free license, but do something which is maybe patented. Yes, right. I made a mistake there - just replace restrictive license with patents in my sentence. free means that it can be redistributed with source code, with a free/open source license. non-free (in terms of the repos) means that it can be redistributed, but either not with source code, according to the license + or we simply don't have/can't get the source code. tainted was mostly for packages affected to some extent by tainted patents. Such packages could be free or non-free, that has nothing to do with being in tainted. Some discussions in the past considered that the likelihood of a patent impacting a particular software (in the few countries that do accept software packages to some extent, like the USA), should affect whether it goes into tainted or not. I don't know what consensus there was on this point, if any. That exactly was the reason why tainted was created. The gathering of such software in one repo to make it easy for users and mirror maintainers in those countries to avoid them if they chose (or are forced) to do so. Since as far as I know, nobody introduced any evidence during the debate of any mirror being pursued for carrying potentially patent-affected packages, despite the fact that many mirrors in the USA, for example, carry such packages, any problem for mirrors is a moot point. However users (or mirrors) that wish to respect patent claims would evidently appreciate avoiding the contents of a tainted repository. Remember that very few patent claims against software are ever validated by the courts. Most pursuits in the USA are against companies with very deep pockets, which are often settled out of court for convenience. Generally in these cases, the defending party is earning revenues from the subject of the patent claim. Which of course doesn't apply to software distributed for free by mirrors. (e.g., if I remember correctly, Novell paid license fees to Microsoft for patent claims, while other companies successfully contested the same claims in court.) -- André
Re: [Mageia-dev] Updates testing
On 7 July 2011 22:04, philippe makowski makowski.mag...@gmail.com wrote: 2011/7/7 nicolas vigier bo...@mars-attacks.org: Yes, for the test about the bug fixed. But isn't there tests to check for regressions ? when you push a new minor version (only bugfix) for softwares like LibreOffice, Postgresql or Firebird for example, will the Mageia QA team run tests for regression and for all bug fixed ? wh ! IMHO, for big packages like libreoffice, we'll have to rely on the free-cost-daily-usage QA, i.e. pushing it to Cauldron users for 1-2month, and waiting till the dust settles before pushing to older stable releases. The interesting part about packages like libreoffice, is they're multi-purpose, so there's no easy way to make sure every functionality works(tm), other than actually letting testes/cauldron-users use it. -- Ahmad Samir
[Mageia-dev] Standardising the virtual Provides in -devel packages
Hello.
I've had a rather vague idea about standardising the virtual provides
in the distro, there should be:
Provides: %{name}-devel
Provides: lib%{name}-devel
either both of them in _all_ packages, or one of them in _all_
packages, so that we don't have to check urpmq --provides all the
time. Personally, I am more inclined on having them both, so as not to
break already working specs.
For example:
$ urpmq --provides lib64gudev1.0-devel-166-5.mga1.x86_64
libgudev-devel[== 166-5.mga1]
pkgconfig(gudev-1.0)[== 166]
devel(libgudev-1.0(64bit))
lib64gudev1.0-devel[== 166-5.mga1]
lib64gudev1.0-devel(x86-64)[== 166-5.mga1]
only libgudev-devel, so if I put BR gudev-devel in a spec it won't
work, whereas I'd expect it to work since some other packages have
such similar provides:
$ urpmq --provides lib64dbus-1-devel
libdbus-1-devel[== 1.4.1-3.mga1]
libdbus-devel[== 1.4.1-3.mga1]
dbus-devel[== 1.4.1-3.mga1]
[...]
WDYT?
(If we agree to go one way or the other, will just fix them gradually
over time).
--
Ahmad Samir
