Re: [Mageia-dev] About panotools patent problem (and other problematic rpms)
On 26.02.2011 07:35, andre999 wrote: Maarten Vanraes a écrit : Op donderdag 24 februari 2011 16:08:51 schreef Anne nicolas: 2011/2/24 Thierry Vignaudthierry.vign...@gmail.com: On 24 February 2011 07:13, andre999and...@laposte.net wrote: And if you discussed the issue and your POV wasn't adapted, what's the point re-emerging it now given that changing the new isn't easy now that the infra- is already in place. In 4+ months, a lot will be changed/corrected. In my mind, this inappropriate name will tarnish Mageia. We can surely find a much more appropriate name. Since the repositories in question are empty, and will never be very big, the cost of changing is minimal. Then what do you suggest? (Remember we already have that discussion) half free :-) maybe free free maybe patent-free in your country/release not sure (special idiocraty for blinopterjan) (me slapping enael for having let those guys view that film) As a side note, let me protest against this. I was a victim and had to watch it 3 or 4 times i'm really curious about the movie now... me too :) actually, any of those suggestions would be an improvement ;) I did suggest contrained. Ubuntu uses restricted and/or multiverse (which include mostly non-free packages), and there were a lot of other suggestions. There was only ONE that seemed inappropriate. Ubuntu's multiverse and restricted contain non-free packages only. Packages in tainted are all free packages. -- Anssi Hannula
Re: [Mageia-dev] About panotools patent problem (and other problematic rpms)
Anssi Hannula a écrit : On 26.02.2011 07:35, andre999 wrote: ... actually, any of those suggestions would be an improvement ;) I did suggest contrained. Ubuntu uses restricted and/or multiverse (which include mostly non-free packages), and there were a lot of other suggestions. There was only ONE that seemed inappropriate. Ubuntu's multiverse and restricted contain non-free packages only. Packages in tainted are all free packages. ok just the Ubuntu web site repository descriptions indicate that patent-threatened or legally restricted packages would go into these repositories, along with the usual non-free. I have no idea what they do in practice. do you mean that you consider that non-free packages should go into non-free, even if threatened by legal or patent constraints ? -- André
Re: [Mageia-dev] About panotools patent problem (and other problematic rpms)
On 26.02.2011 22:20, andre999 wrote: Anssi Hannula a écrit : On 26.02.2011 07:35, andre999 wrote: ... actually, any of those suggestions would be an improvement ;) I did suggest contrained. Ubuntu uses restricted and/or multiverse (which include mostly non-free packages), and there were a lot of other suggestions. There was only ONE that seemed inappropriate. Ubuntu's multiverse and restricted contain non-free packages only. Packages in tainted are all free packages. ok just the Ubuntu web site repository descriptions indicate that patent-threatened or legally restricted packages would go into these repositories, along with the usual non-free. I have no idea what they do in practice. They have fully enabled ffmpeg in main, and mplayer,x264,lame in universe. So patent-constrained pkgs do not appear to be put in multiverse. do you mean that you consider that non-free packages should go into non-free, even if threatened by legal or patent constraints ? Well, those don't really belong to either, so I'm unsure what would be done with those. However, I'm not aware of any such packages so it is a moot point :) -- Anssi Hannula
Re: [Mageia-dev] About panotools patent problem (and other problematic rpms)
Op donderdag 24 februari 2011 16:08:51 schreef Anne nicolas: 2011/2/24 Thierry Vignaud thierry.vign...@gmail.com: On 24 February 2011 07:13, andre999 and...@laposte.net wrote: And if you discussed the issue and your POV wasn't adapted, what's the point re-emerging it now given that changing the new isn't easy now that the infra- is already in place. In 4+ months, a lot will be changed/corrected. In my mind, this inappropriate name will tarnish Mageia. We can surely find a much more appropriate name. Since the repositories in question are empty, and will never be very big, the cost of changing is minimal. Then what do you suggest? (Remember we already have that discussion) half free :-) maybe free free maybe patent-free in your country/release not sure (special idiocraty for blinopterjan) (me slapping enael for having let those guys view that film) As a side note, let me protest against this. I was a victim and had to watch it 3 or 4 times i'm really curious about the movie now...
Re: [Mageia-dev] About panotools patent problem (and other problematic rpms)
Maarten Vanraes a écrit : Op donderdag 24 februari 2011 16:08:51 schreef Anne nicolas: 2011/2/24 Thierry Vignaudthierry.vign...@gmail.com: On 24 February 2011 07:13, andre999and...@laposte.net wrote: And if you discussed the issue and your POV wasn't adapted, what's the point re-emerging it now given that changing the new isn't easy now that the infra- is already in place. In 4+ months, a lot will be changed/corrected. In my mind, this inappropriate name will tarnish Mageia. We can surely find a much more appropriate name. Since the repositories in question are empty, and will never be very big, the cost of changing is minimal. Then what do you suggest? (Remember we already have that discussion) half free :-) maybe free free maybe patent-free in your country/release not sure (special idiocraty for blinopterjan) (me slapping enael for having let those guys view that film) As a side note, let me protest against this. I was a victim and had to watch it 3 or 4 times i'm really curious about the movie now... me too :) actually, any of those suggestions would be an improvement ;) I did suggest contrained. Ubuntu uses restricted and/or multiverse (which include mostly non-free packages), and there were a lot of other suggestions. There was only ONE that seemed inappropriate. -- André
Re: [Mageia-dev] About panotools patent problem (and other problematic rpms)
On 24 February 2011 07:13, andre999 and...@laposte.net wrote: And if you discussed the issue and your POV wasn't adapted, what's the point re-emerging it now given that changing the new isn't easy now that the infra- is already in place. In 4+ months, a lot will be changed/corrected. In my mind, this inappropriate name will tarnish Mageia. We can surely find a much more appropriate name. Since the repositories in question are empty, and will never be very big, the cost of changing is minimal. Then what do you suggest? (Remember we already have that discussion) half free :-) maybe free free maybe patent-free in your country/release not sure (special idiocraty for blinopterjan) (me slapping enael for having let those guys view that film)
Re: [Mageia-dev] About panotools patent problem (and other problematic rpms)
2011/2/24 Thierry Vignaud thierry.vign...@gmail.com: On 24 February 2011 07:13, andre999 and...@laposte.net wrote: And if you discussed the issue and your POV wasn't adapted, what's the point re-emerging it now given that changing the new isn't easy now that the infra- is already in place. In 4+ months, a lot will be changed/corrected. In my mind, this inappropriate name will tarnish Mageia. We can surely find a much more appropriate name. Since the repositories in question are empty, and will never be very big, the cost of changing is minimal. Then what do you suggest? (Remember we already have that discussion) half free :-) maybe free free maybe patent-free in your country/release not sure (special idiocraty for blinopterjan) (me slapping enael for having let those guys view that film) As a side note, let me protest against this. I was a victim and had to watch it 3 or 4 times -- Anne http://www.mageia.org
Re: [Mageia-dev] About panotools patent problem (and other problematic rpms)
Quote: Thomas Backlund wrote on Sun, 20 February 2011 19:48 It is an abuse yes, but the great thing about it is we _know_ it works... so no surprises... (if it aint broken...) Agreed, the automatic preference of urpmi for plf when plf is enabled is something I have always appreciated on Mandriva, so I would prefer if we keep it similar in Mageia. The only plf package (and I make heavy use of plf packages) I ever had to put in skip.list was libfreetype since the mdv one rendered fonts better on my hardware. Well, the old simple logic works... lets say we abuse the release tag, for example changing mga to mgt then if the user enables tainted (meaning he/she wants the rpms) urpmi will automatically get the mgt ones, no questions asked... simple, and effective. mga / mgt seems the best solution to me, just like Thomas says: simple and effective! -- Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/
Re: [Mageia-dev] About panotools patent problem (and other problematic rpms)
On Fri, Feb 18, 2011 at 10:57, Michael Scherer m...@zarb.org wrote: Le vendredi 18 février 2011 à 10:13 +0100, Philippe DIDIER a écrit : Just seen that mikala added panotools in the repository . (some algorythms library to build panoramic photographs) Very happy with this ! (thanks a lot...) That's one of the first patent problems we may encounter : Yes, that's a good sample to use to improve our policy draft. Long time ago, How long is a long time ago? because every patent has a term and here it may have expired. iPIX, a company from USA muliplied patent lawsuit against these free algorythms inventor and photographers using them (this company is now dead because of bankruptcy but the patent problem is still live... ) Well, who own the patents now ? From http://wiki.panotools.org/Ipix it looks a former competitor got a hold on all assets from iPix. On the decision/sorting out side, for this and for any other patent issue, do we document already (in source code or a separate file) the reasons to activate or not pieces of a software (or to exclude them from packages), because of some patents? List of questions to check would be at least: - what is exactly covered by what patent (reference, registration, territory/ies for which it has been registered)? - where is it implemented exactly in the source code? ( - who owns this patent? - did the patent holder announce his clear intention upon it? (that is, is he using it to control/restrain use or not? *) - are there obvious prior art that could make this patent obviously invalid? - what is decided and when (and what may change the decision, later)? - what would be alternative ways to implement the function (if the patent does not just cover the function, but a specific implementation of it)? * one does not necessarily register a patent to be offensive with it; here, we knew about iPix, what about the new holder? Btw, a draft policy for patents management was discussed among founders and other people (lawyers) months ago and a tentative summary written by me here: http://mageia.org/wiki/doku.php?id=software_patents_policy . Cheers, Romain
Re: [Mageia-dev] About panotools patent problem (and other problematic rpms)
Quote: rdalverny wrote on Tue, 22 February 2011 11:04 Long time ago, How long is a long time ago? because every patent has a term and here it may have expired. Long time ago means 1999.. Actually the problem has not expired : Bruno Postle the main dev of hugin and panotools projects uses fedora and builds the rpm for Fedora (and proposes on his own repo rpms of the betas and release candidates ... ) He is certainly the guy that must be aware of the patent problems : he still proposes a limited version of panotools on official Fedora's repositories !!! The source are written to be built with or without fov limitation depending of the possible patent infringement (no limit in Europe...) List of questions to check would be at least: - what is exactly covered by what patent (reference, registration, territory/ies for which it has been registered)? - where is it implemented exactly in the source code? ( - who owns this patent? - did the patent holder announce his clear intention upon it? (that is, is he using it to control/restrain use or not? *) - are there obvious prior art that could make this patent obviously invalid? - what is decided and when (and what may change the decision, later)? - what would be alternative ways to implement the function (if the patent does not just cover the function, but a specific implementation of it)? * one does not necessarily register a patent to be offensive with it; here, we knew about iPix, what about the new holder? Btw, a draft policy for patents management was discussed among founders and other people (lawyers) months ago and a tentative summary written by me here: http://mageia.org/wiki/doku.php?id=software_patents_policy . Cheers, Romain Best regards Philippe
Re: [Mageia-dev] About panotools patent problem (and other problematic rpms)
Maarten Vanraes a écrit : Op vrijdag 18 februari 2011 14:42:02 schreef Michael Scherer: Le vendredi 18 février 2011 à 12:47 +, James Kerr a écrit : If there are two packages, one in core and another in tainted, then doesn't urpmi need a way to recognise that the tainted package is newer than (an update to) the corresponding core package? I believe that this is achieved in Mandriva, because plf is greater than mdv. That's abusing release tag and it work by pure chance ( ie, had the plf decided to be called the guillomovitch liberation front, it would not have worked ). And this is quite inflexible, since people will always have plf packages, leading to users adding some rpm in skip.list with a regexp. This doesn't make much sense to treat tainted rpm as update to core, this is not the same notion. But we cannot express this in urpmi for the moment, as this would requires some way to say if you need to install something, prefer this source rather than this one. We can imagine a priority system, or we can simply say that if there is the same rpm on 2 media, we ask to the user ( except this would requires IMHO a better system than the current path based one to see what is in a rpm, but that's a rather long proposal to make ). But you are right this another set of issues to solve for dual life packages. after sleeping on this, i've had this idea: why don't we rename packages in tainted? keeping them in the same name, perhaps has issues with search engines, (ie: which version do you get?) i proposed renaming packages in tainted,(but not the release tag). would it be a good compromise if we named packages: orig_packagename-tainted-version-release ? the benefit of this could be adding an Obsoletes and Provides on the original package with the identical version. for building, i may have this solution: %tainted(%_optional_feature1 %optional_feature2 %optional_feature3) this would allow the buildbot to look for %tainted and if it does, it could rebuild it for tainted and add the particulars itself. this would simplify the whole plf/tainted thing easily. and since all 4 rpms are being built at the same time, you have no srpm problem either. WDYT? aside First of all, tainted in English implies that the software doesn't work. (Unless it refers to food, in which case it means poisonous.) So we should choose a more appropriate name, such as constrained, or use the Ubuntu approach and use a name which doesn't literally describe the contents. (Multiverse, in their case.) Anything but something that implies that there is something inherently wrong with the package in question. That was one advantage of plf, but of course that is already taken. And it is certainly advantageous to include such packages directly on Mageia mirrors. /aside A Cleaner approach -- albeit more work -- would be for the constrained package to be an external module which adds the missing functionality. For less modular packages, this would be replacing (only) the files which provide the questioned functionality. For a typical a music player-type application, this would be only a be a few relatively small files. So a user that wants to add the contrained functionality would simply add an extra package, which obviously would have a different name based on the main package. (It would be useful to suggest adding such packages during installation, if the contrained repositories are selected.) (That is, if such a related package is available in selected repos.) Think of the gstreamer packages -- the ugly perhaps corresponding to the constrained packages being considered. my 2 cents :) -- André
Re: [Mageia-dev] About panotools patent problem (and other problematic rpms)
On Tuesday, 22 February 2011 20:09:17 andre999 wrote: Maarten Vanraes a écrit : Op vrijdag 18 februari 2011 14:42:02 schreef Michael Scherer: Le vendredi 18 février 2011 à 12:47 +, James Kerr a écrit : If there are two packages, one in core and another in tainted, then doesn't urpmi need a way to recognise that the tainted package is newer than (an update to) the corresponding core package? I believe that this is achieved in Mandriva, because plf is greater than mdv. That's abusing release tag and it work by pure chance ( ie, had the plf decided to be called the guillomovitch liberation front, it would not have worked ). And this is quite inflexible, since people will always have plf packages, leading to users adding some rpm in skip.list with a regexp. This doesn't make much sense to treat tainted rpm as update to core, this is not the same notion. But we cannot express this in urpmi for the moment, as this would requires some way to say if you need to install something, prefer this source rather than this one. We can imagine a priority system, or we can simply say that if there is the same rpm on 2 media, we ask to the user ( except this would requires IMHO a better system than the current path based one to see what is in a rpm, but that's a rather long proposal to make ). But you are right this another set of issues to solve for dual life packages. after sleeping on this, i've had this idea: why don't we rename packages in tainted? keeping them in the same name, perhaps has issues with search engines, (ie: which version do you get?) i proposed renaming packages in tainted,(but not the release tag). would it be a good compromise if we named packages: orig_packagename-tainted-version-release ? the benefit of this could be adding an Obsoletes and Provides on the original package with the identical version. for building, i may have this solution: %tainted(%_optional_feature1 %optional_feature2 %optional_feature3) this would allow the buildbot to look for %tainted and if it does, it could rebuild it for tainted and add the particulars itself. this would simplify the whole plf/tainted thing easily. and since all 4 rpms are being built at the same time, you have no srpm problem either. WDYT? aside First of all, tainted in English implies that the software doesn't work. I have never seen that interpretation. Tainted is a synonym for contaminated. Contaminated doesn't mean that it doesn't work, it means that you should exercise caution in using it (e.g. you may not want to drink it, but you can use it to wash your car). http://www.encyclopedia.com/doc/1O999-taint.html (Unless it refers to food, in which case it means poisonous.) So we should choose a more appropriate name, such as constrained, or use the Ubuntu approach and use a name which doesn't literally describe the contents. (Multiverse, in their case.) Anything but something that implies that there is something inherently wrong with the package in question. There is something wrong with the package, it is contaminated by software patents. Regards, Buchan
Re: [Mageia-dev] About panotools patent problem (and other problematic rpms)
On 22 February 2011 20:09, andre999 and...@laposte.net wrote: aside First of all, tainted in English implies that the software doesn't work. (Unless it refers to food, in which case it means poisonous.) So we should choose a more appropriate name, such as constrained, or use the Ubuntu approach and use a name which doesn't literally describe the contents. (Multiverse, in their case.) Anything but something that implies that there is something inherently wrong with the package in question. That was one advantage of plf, but of course that is already taken. And it is certainly advantageous to include such packages directly on Mageia mirrors. /aside A Cleaner approach -- albeit more work -- would be for the constrained package to be an external module which adds the missing functionality. For less modular packages, this would be replacing (only) the files which provide the questioned functionality. For a typical a music player-type application, this would be only a be a few relatively small files. So a user that wants to add the contrained functionality would simply add an extra package, which obviously would have a different name based on the main package. (It would be useful to suggest adding such packages during installation, if the contrained repositories are selected.) (That is, if such a related package is available in selected repos.) Think of the gstreamer packages -- the ugly perhaps corresponding to the constrained packages being considered. my 2 cents :) -- André Just a small note, if you didn't like the colour of the bike shed you should have discussed the point before it was built, painted, the paint has dried and is about to have new residents. And if you discussed the issue and your POV wasn't adapted, what's the point re-emerging it now given that changing the new isn't easy now that the infra- is already in place. I like the name tainted, (note that the kernel does use the word tainted to indicate there's a non-open source binary blob/driver e.g. with the nvidia proprietary driver, so this usage is not unheard of). :) -- Ahmad Samir
Re: [Mageia-dev] About panotools patent problem (and other problematic rpms)
Op dinsdag 22 februari 2011 19:09:17 schreef andre999: [...] aside First of all, tainted in English implies that the software doesn't work. (Unless it refers to food, in which case it means poisonous.) So we should choose a more appropriate name, such as constrained, or use the Ubuntu approach and use a name which doesn't literally describe the contents. (Multiverse, in their case.) Anything but something that implies that there is something inherently wrong with the package in question. That was one advantage of plf, but of course that is already taken. And it is certainly advantageous to include such packages directly on Mageia mirrors. /aside [...] This reply is not meant for andre, but for people responding to his email: I clearly didn't respond to this, because this is aside, and in general the preference of one user, we already had a big discussion about this, so please let's not restart this one. and besides the aside, naming is unimportant in my view.
Re: [Mageia-dev] About panotools patent problem (and other problematic rpms)
Michael Scherer skrev 18.2.2011 15:42: Le vendredi 18 février 2011 à 12:47 +, James Kerr a écrit : If there are two packages, one in core and another in tainted, then doesn't urpmi need a way to recognise that the tainted package is newer than (an update to) the corresponding core package? I believe that this is achieved in Mandriva, because plf is greater than mdv. That's abusing release tag and it work by pure chance ( ie, had the plf decided to be called the guillomovitch liberation front, it would not have worked ). And this is quite inflexible, since people will always have plf packages, leading to users adding some rpm in skip.list with a regexp. It is an abuse yes, but the great thing about it is we _know_ it works... so no surprises... (if it aint broken...) This doesn't make much sense to treat tainted rpm as update to core, this is not the same notion. But we cannot express this in urpmi for the moment, as this would requires some way to say if you need to install something, prefer this source rather than this one. We can imagine a priority system, or we can simply say that if there is the same rpm on 2 media, we ask to the user ( except this would requires IMHO a better system than the current path based one to see what is in a rpm, but that's a rather long proposal to make ). Well, the old simple logic works... lets say we abuse the release tag, for example changing mga to mgt then if the user enables tainted (meaning he/she wants the rpms) urpmi will automatically get the mgt ones, no questions asked... simple, and effective. and since the rebuild should be automatically on our bs, the versions will stay in sync. But you are right this another set of issues to solve for dual life packages. I'd say go for the setup that we know works for Mageia 1, and re-evalute the issue after... -- Thomas
Re: [Mageia-dev] About panotools patent problem (and other problematic rpms)
Well, the old simple logic works... lets say we abuse the release tag, for example changing mga to mgt then if the user enables tainted (meaning he/she wants the rpms) urpmi will automatically get the mgt ones, no questions asked... simple, and effective. and since the rebuild should be automatically on our bs, the versions will stay in sync. That seems to be the easyest compromise. Allowing to use the existing spec files from mdv and plf with the least modifications. 2 problems indeed : for sysadmin point of view : Is the BS able to build and dispatch two different versions of the same rpm (core and tainted) ? for the user Is the package manager able to substitue simply a tainted rpm to a core rpm if the tainted repos are selected ?
Re: [Mageia-dev] About panotools patent problem (and other problematic rpms)
On Sat, 19 Feb 2011 09:20:50 +0100, Maarten Vanraes wrote: Op vrijdag 18 februari 2011 14:42:02 schreef Michael Scherer: Le vendredi 18 février 2011 à 12:47 +, James Kerr a écrit : If there are two packages, one in core and another in tainted, then doesn't urpmi need a way to recognise that the tainted package is newer than (an update to) the corresponding core package? I believe that this is achieved in Mandriva, because plf is greater than mdv. That's abusing release tag and it work by pure chance ( ie, had the plf decided to be called the guillomovitch liberation front, it would not have worked ). And this is quite inflexible, since people will always have plf packages, leading to users adding some rpm in skip.list with a regexp. This doesn't make much sense to treat tainted rpm as update to core, this is not the same notion. But we cannot express this in urpmi for the moment, as this would requires some way to say if you need to install something, prefer this source rather than this one. We can imagine a priority system, or we can simply say that if there is the same rpm on 2 media, we ask to the user ( except this would requires IMHO a better system than the current path based one to see what is in a rpm, but that's a rather long proposal to make ). But you are right this another set of issues to solve for dual life packages. after sleeping on this, i've had this idea: why don't we rename packages in tainted? keeping them in the same name, perhaps has issues with search engines, (ie: which version do you get?) with search engine ? I can see the issue for support, yes, but search engine, no i proposed renaming packages in tainted,(but not the release tag). would it be a good compromise if we named packages: orig_packagename-tainted-version-release ? the benefit of this could be adding an Obsoletes and Provides on the original package with the identical version. This could work, but I am not sure that a Obsoletes is required. One problem with this idea is that it will ask to user lots of questions, and that's something we should rather try to avoid ( any people who installed some java rpm will understand the issue ). But it has the advantage of not requiring anything special on BS while providing the choice. for building, i may have this solution: %tainted(%_optional_feature1 %optional_feature2 %optional_feature3) this would allow the buildbot to look for %tainted and if it does, it could rebuild it for tainted and add the particulars itself. this would simplify the whole plf/tainted thing easily. and since all 4 rpms are being built at the same time, you have no srpm problem either. A simple %define would do the trick, so that doesn't bring much. And we can keep a list of package that should be compiled twice, that's not the biggest problem to solve. -- Michael Scherer
Re: [Mageia-dev] About panotools patent problem (and other problematic rpms)
Op zaterdag 19 februari 2011 14:59:46 schreef Michael Scherer: On Sat, 19 Feb 2011 09:20:50 +0100, Maarten Vanraes wrote: Op vrijdag 18 februari 2011 14:42:02 schreef Michael Scherer: Le vendredi 18 février 2011 à 12:47 +, James Kerr a écrit : If there are two packages, one in core and another in tainted, then doesn't urpmi need a way to recognise that the tainted package is newer than (an update to) the corresponding core package? I believe that this is achieved in Mandriva, because plf is greater than mdv. That's abusing release tag and it work by pure chance ( ie, had the plf decided to be called the guillomovitch liberation front, it would not have worked ). And this is quite inflexible, since people will always have plf packages, leading to users adding some rpm in skip.list with a regexp. This doesn't make much sense to treat tainted rpm as update to core, this is not the same notion. But we cannot express this in urpmi for the moment, as this would requires some way to say if you need to install something, prefer this source rather than this one. We can imagine a priority system, or we can simply say that if there is the same rpm on 2 media, we ask to the user ( except this would requires IMHO a better system than the current path based one to see what is in a rpm, but that's a rather long proposal to make ). But you are right this another set of issues to solve for dual life packages. after sleeping on this, i've had this idea: why don't we rename packages in tainted? keeping them in the same name, perhaps has issues with search engines, (ie: which version do you get?) with search engine ? I can see the issue for support, yes, but search engine, no i proposed renaming packages in tainted,(but not the release tag). would it be a good compromise if we named packages: orig_packagename-tainted-version-release ? the benefit of this could be adding an Obsoletes and Provides on the original package with the identical version. This could work, but I am not sure that a Obsoletes is required. One problem with this idea is that it will ask to user lots of questions, and that's something we should rather try to avoid ( any people who installed some java rpm will understand the issue ). But it has the advantage of not requiring anything special on BS while providing the choice. if there is obsoletes, i don't think a question will be asked... for building, i may have this solution: %tainted(%_optional_feature1 %optional_feature2 %optional_feature3) this would allow the buildbot to look for %tainted and if it does, it could rebuild it for tainted and add the particulars itself. this would simplify the whole plf/tainted thing easily. and since all 4 rpms are being built at the same time, you have no srpm problem either. A simple %define would do the trick, so that doesn't bring much. And we can keep a list of package that should be compiled twice, that's not the biggest problem to solve. well, it's an idea, that allows us to have all the functionality we want, and no manual intervention needed anymore.
Re: [Mageia-dev] About panotools patent problem (and other problematic rpms)
This sound like w32codecs issues. I suggest create a nonfree repository or don't install it if user choose a non-European country during install.
Re: [Mageia-dev] About panotools patent problem (and other problematic rpms)
2011/2/18 Michael Scherer m...@zarb.org: Le vendredi 18 février 2011 à 12:47 +, James Kerr a écrit : If there are two packages, one in core and another in tainted, then doesn't urpmi need a way to recognise that the tainted package is newer than (an update to) the corresponding core package? I believe that this is achieved in Mandriva, because plf is greater than mdv. That's abusing release tag and it work by pure chance ( ie, had the plf decided to be called the guillomovitch liberation front, it would not have worked ). And this is quite inflexible, since people will always have plf packages, leading to users adding some rpm in skip.list with a regexp. Exactly! :) I've just started to look into implementing support for favoring packages based on %disttag, I'm thinking about implementing it in a way similar to this: Say we have global variables such as these in urpmi.cfg: disttag-priority: plf,mdv,mga disttag-pin: 1 disttag-pin-force: 0 in urpmi: * if disttag-priority is defined, it will compared the disttag of all packages that has the same or newer version, and favor the one of those with the disttag that's highest on the disttag-priority list. * if disttag-pin is set, it will refuse to upgrade to a newer version of a package that has a different disttag than the one installed. * if disttag-pin-force is set, it will *always* upgrade/downgrade to the newest version of a package which has the highest priority match, ie. if foo-2-1mdv is installed, and the newest version with 'mga' disttag available in repos is foo-1-1mga, then it will downgrade to it. Notice that %disttag is a tag that's been implemented in rpm since long time ago, but was never really adopted for anything, so in rpm5 it was dusted off and was adjusted a tiny bit for it to be made possible to be defined globally through macro files read, similar to ie. %vendor etc. I've already in the past patched rpm 4.6 in cooker with support for at least recognizing %distepoch (but not for using it in version comparision, doing it should be fairly trivial though), I might've already made the change mentioned for %disttag as well in the same patch, I don't really remember, should anyhow be very trivial to do.. So if you'd like to eliminate 'mga' from release and version comparision, you can already do so by making the minor change for %disttag, then make adjustments accordingly to %_build_name_fmt and %mkrel. Adopting distepoch as well will require slightly more, but won't really been hard (the hard part has already been tendered well after slamming cooker a bit more than expected..;) and would be a sane thing to adopt anyways.. FWIW in .spec files, the preferred conditional would be: %if %disttag == mga blabla %else if %disttag == plf hubbabubba %else if %disttag == mdv boink! %endif WDYT? -- Regards, Per Øyvind
Re: [Mageia-dev] About panotools patent problem (and other problematic rpms)
Le vendredi 18 février 2011 à 10:13 +0100, Philippe DIDIER a écrit : Hi everybody ! Just seen that mikala added panotools in the repository . (some algorythms library to build panoramic photographs) Very happy with this ! (thanks a lot...) That's one of the first patent problems we may encounter : Long time ago, iPIX, a company from USA muliplied patent lawsuit against these free algorythms inventor and photographers using them (this company is now dead because of bankruptcy but the patent problem is still live... ) Well, who own the patents now ? -- Michael Scherer
Re: [Mageia-dev] About panotools patent problem (and other problematic rpms)
Philippe DIDIER philippedid...@laposte.net schrieb am 2011-02-18 But this doesn't solve the more global problem of rpms with patent problems (how to have them clearly built and identified : need different suffixes ?) Wasn't this the reason for creating the tainted repository? Since we don't have any software patents in Europe, we Europeans can safely ignore them and for those regions, where they do have sw patents, we wanted to let the people decide wether they use tainted packages on their own risk or not? At least that is how I understood the lengthy discussion we had at that time... Oliver
Re: [Mageia-dev] About panotools patent problem (and other problematic rpms)
Philippe DIDIER philippedid...@laposte.net schrieb am 2011-02-18 And what I talked about (in the other thread with the same name) was about the easiness to build and use different rpms with the same spec having mdv versus plf suffixes... And about it seems that we need to have different naming for Mageia (whether it's a normal or tainted rpm) I still don't see a reason for this. We devide those packages by the repo they get in, why do another thing? Oliver
Re: [Mageia-dev] About panotools patent problem (and other problematic rpms)
Le vendredi 18 février 2011 à 12:43 +0100, Oliver Burger a écrit : Philippe DIDIER philippedid...@laposte.net schrieb am 2011-02-18 And what I talked about (in the other thread with the same name) was about the easiness to build and use different rpms with the same spec having mdv versus plf suffixes... And about it seems that we need to have different naming for Mageia (whether it's a normal or tainted rpm) I still don't see a reason for this. We devide those packages by the repo they get in, why do another thing? From a build system point f view, this is easier to indeed treat that like non-free, because there is no modification to do. A better solution would indeed be to allow to have a tainted rpm in code and tained, the core version being cleaned from litigious parts. let's take a exemple, let's imagine someone has a patent on a fictional video codec let's call it MCVC ( MegaCompressionVideoCodec ), and a army of cloned lawyers from Hell that enforce the patent in USA. Let's assume that Mplayer, as it support almost everything, support MCVC in the current version. First solution : we move mplayer rpm to tainted, with support for MCVC. Second solution : we compile mplayer in core without support for MCVC Third solution : we compile mplayer 2 times, once in tainted with MCVC, another one to core without. The first solution force us to place everything that requires mplayer to tainted, as core must be self contained. So that mean various frontends, firefox plugin, etc. This could be problematic if we place some libraries in tainted. ( like freetype ). The second solution may slightly annoy people with lots of holidays movies encoded in MCVC. And would render tainted basically useless. The third solution is the one we use for PLF, but suffer from a few technical issues : - I am not sure the current system support it. In mdv, the 2 uploads system are fully separated. Not here. - We need to make sure that the binaries and source rpms are kept in sync. If I upload a new version of mplayer, it will erase the source rpm and use the new one. So if I built the tainted one, the srpm that was used for the core rpm is no longer here. - we need to make sure that the binaries rpms are in sync. If we upload the core one, it would be nice to wait for the tainted one to be uploaded too. Ie keep them in sync like we keep x86_64/i586 in sync. But, only if the package is dual lived ( ie, there is rpms that will be distributed only in tainted ). That's a rather non trivial problem to solve. And hopefully, we only have core and tainted ( ie, while non-free could be added to the mix, there is no dual life issue with it ). -- Michael Scherer
Re: [Mageia-dev] About panotools patent problem (and other problematic rpms)
Le vendredi 18 février 2011 06:13:07, Philippe DIDIER a écrit : Hi everybody ! Just seen that mikala added panotools in the repository . (some algorythms library to build panoramic photographs) Very happy with this ! (thanks a lot...) That's one of the first patent problems we may encounter : Long time ago, iPIX, a company from USA muliplied patent lawsuit against these free algorythms inventor and photographers using them (this company is now dead because of bankruptcy but the patent problem is still live... ) This patent problem was revoked in Europe by the European Patent Office but is still valid in USA and perhaps other countries (Japan...) There's a limitation to its use if you are in a country where the patent problem exists ! For this reason : Mandriva proposed a rpm limited to a 160° fov (field of view) support but we could find in PLF a rpm without limitation (up to 360°...). The spec was written to build differently for mandriva repo and plf repo... and this is the one imported... but it allows to build only a limited rpm (as it is not used with plf buildsystem)... I imported like this explicity due to that in fact so we can take a decision to know if we should get it up to 360°. If i read correctly fedora still ship it without 360° support ( http://pkgs.fedoraproject.org/gitweb/?p=libpano13.git;a=commit;h=8d37dc9492f4ec51bbe1f88e7db850cf5db8fc7e ) -- Balcaen John
Re: [Mageia-dev] About panotools patent problem (and other problematic rpms)
On 18/02/11 12:07, Michael Scherer wrote: Le vendredi 18 février 2011 à 12:43 +0100, Oliver Burger a écrit : Philippe DIDIERphilippedid...@laposte.net schrieb am 2011-02-18 And what I talked about (in the other thread with the same name) was about the easiness to build and use different rpms with the same spec having mdv versus plf suffixes... And about it seems that we need to have different naming for Mageia (whether it's a normal or tainted rpm) I still don't see a reason for this. We devide those packages by the repo they get in, why do another thing? From a build system point f view, this is easier to indeed treat that like non-free, because there is no modification to do. A better solution would indeed be to allow to have a tainted rpm in code and tained, the core version being cleaned from litigious parts. let's take a exemple, let's imagine someone has a patent on a fictional video codec let's call it MCVC ( MegaCompressionVideoCodec ), and a army of cloned lawyers from Hell that enforce the patent in USA. Let's assume that Mplayer, as it support almost everything, support MCVC in the current version. First solution : we move mplayer rpm to tainted, with support for MCVC. Second solution : we compile mplayer in core without support for MCVC Third solution : we compile mplayer 2 times, once in tainted with MCVC, another one to core without. The first solution force us to place everything that requires mplayer to tainted, as core must be self contained. So that mean various frontends, firefox plugin, etc. This could be problematic if we place some libraries in tainted. ( like freetype ). The second solution may slightly annoy people with lots of holidays movies encoded in MCVC. And would render tainted basically useless. The third solution is the one we use for PLF, but suffer from a few technical issues : - I am not sure the current system support it. In mdv, the 2 uploads system are fully separated. Not here. - We need to make sure that the binaries and source rpms are kept in sync. If I upload a new version of mplayer, it will erase the source rpm and use the new one. So if I built the tainted one, the srpm that was used for the core rpm is no longer here. - we need to make sure that the binaries rpms are in sync. If we upload the core one, it would be nice to wait for the tainted one to be uploaded too. Ie keep them in sync like we keep x86_64/i586 in sync. But, only if the package is dual lived ( ie, there is rpms that will be distributed only in tainted ). That's a rather non trivial problem to solve. And hopefully, we only have core and tainted ( ie, while non-free could be added to the mix, there is no dual life issue with it ). If there are two packages, one in core and another in tainted, then doesn't urpmi need a way to recognise that the tainted package is newer than (an update to) the corresponding core package? I believe that this is achieved in Mandriva, because plf is greater than mdv. Jim
