From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/20101015/001209.html | 190 ++++++++++++++++++++++++++ zarb-ml/mageia-dev/20101015/001210.html | 83 +++++++++++ zarb-ml/mageia-dev/20101015/001211.html | 89 ++++++++++++ zarb-ml/mageia-dev/20101015/001212.html | 165 ++++++++++++++++++++++ zarb-ml/mageia-dev/20101015/001213.html | 173 +++++++++++++++++++++++ zarb-ml/mageia-dev/20101015/001214.html | 222 ++++++++++++++++++++++++++++++ zarb-ml/mageia-dev/20101015/001215.html | 112 +++++++++++++++ zarb-ml/mageia-dev/20101015/001216.html | 143 +++++++++++++++++++ zarb-ml/mageia-dev/20101015/001217.html | 82 +++++++++++ zarb-ml/mageia-dev/20101015/001218.html | 89 ++++++++++++ zarb-ml/mageia-dev/20101015/001219.html | 76 +++++++++++ zarb-ml/mageia-dev/20101015/001220.html | 105 ++++++++++++++ zarb-ml/mageia-dev/20101015/001221.html | 76 +++++++++++ zarb-ml/mageia-dev/20101015/001222.html | 68 +++++++++ zarb-ml/mageia-dev/20101015/001223.html | 143 +++++++++++++++++++ zarb-ml/mageia-dev/20101015/001224.html | 228 +++++++++++++++++++++++++++++++ zarb-ml/mageia-dev/20101015/001225.html | 82 +++++++++++ zarb-ml/mageia-dev/20101015/001226.html | 88 ++++++++++++ zarb-ml/mageia-dev/20101015/001227.html | 92 +++++++++++++ zarb-ml/mageia-dev/20101015/001228.html | 92 +++++++++++++ zarb-ml/mageia-dev/20101015/author.html | 147 ++++++++++++++++++++ zarb-ml/mageia-dev/20101015/date.html | 147 ++++++++++++++++++++ zarb-ml/mageia-dev/20101015/index.html | 1 + zarb-ml/mageia-dev/20101015/subject.html | 147 ++++++++++++++++++++ zarb-ml/mageia-dev/20101015/thread.html | 183 +++++++++++++++++++++++++ 25 files changed, 3023 insertions(+) create mode 100644 zarb-ml/mageia-dev/20101015/001209.html create mode 100644 zarb-ml/mageia-dev/20101015/001210.html create mode 100644 zarb-ml/mageia-dev/20101015/001211.html create mode 100644 zarb-ml/mageia-dev/20101015/001212.html create mode 100644 zarb-ml/mageia-dev/20101015/001213.html create mode 100644 zarb-ml/mageia-dev/20101015/001214.html create mode 100644 zarb-ml/mageia-dev/20101015/001215.html create mode 100644 zarb-ml/mageia-dev/20101015/001216.html create mode 100644 zarb-ml/mageia-dev/20101015/001217.html create mode 100644 zarb-ml/mageia-dev/20101015/001218.html create mode 100644 zarb-ml/mageia-dev/20101015/001219.html create mode 100644 zarb-ml/mageia-dev/20101015/001220.html create mode 100644 zarb-ml/mageia-dev/20101015/001221.html create mode 100644 zarb-ml/mageia-dev/20101015/001222.html create mode 100644 zarb-ml/mageia-dev/20101015/001223.html create mode 100644 zarb-ml/mageia-dev/20101015/001224.html create mode 100644 zarb-ml/mageia-dev/20101015/001225.html create mode 100644 zarb-ml/mageia-dev/20101015/001226.html create mode 100644 zarb-ml/mageia-dev/20101015/001227.html create mode 100644 zarb-ml/mageia-dev/20101015/001228.html create mode 100644 zarb-ml/mageia-dev/20101015/author.html create mode 100644 zarb-ml/mageia-dev/20101015/date.html create mode 120000 zarb-ml/mageia-dev/20101015/index.html create mode 100644 zarb-ml/mageia-dev/20101015/subject.html create mode 100644 zarb-ml/mageia-dev/20101015/thread.html (limited to 'zarb-ml/mageia-dev/20101015') diff --git a/zarb-ml/mageia-dev/20101015/001209.html b/zarb-ml/mageia-dev/20101015/001209.html new file mode 100644 index 000000000..795057d34 --- /dev/null +++ b/zarb-ml/mageia-dev/20101015/001209.html @@ -0,0 +1,190 @@ + + + + [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc + + + + + + + + + +

[Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc

+ Michael scherer + misc at zarb.org +
+ Fri Oct 15 01:18:37 CEST 2010 +

+
+ +
On Thu, Oct 14, 2010 at 09:57:03PM +0200, Olivier Méjean wrote:
+> Le jeudi 14 octobre 2010 20:55:01, Anssi Hannula a écrit :
+> > On Wednesday 13 October 2010 20:22:01 Michael Scherer wrote:
+> > > Le mardi 12 octobre 2010 à 18:02 +0300, Anssi Hannula a écrit :
+> > > > Hi all!
+> > > > 
+> > > > Do people have any thoughts on what kind of repository/media sectioning
+> > > > we should use on Mageia, and what should those sections contain?
+> > > > 
+> > > > Note that I won't talk about backports / private repositories in this
+> > > > post, only about the basic sectioning and packages in those.
+> > > > 
+> > > > Some points to consider (I've written my opinion in ones where I have
+> > > > one):
+> > > > 
+> > > > == Do we want a separated core repository?
+> > > > 
+> > > > No separated core: Fedora, Debian, Opensuse
+> > > > Separated core: Mandriva (main), Ubuntu (main), Arch (Core)
+> > > 
+> > > How do we decide what would be in core ?
+> > 
+> > AFAICS the only reasonable reason would be to separate 'supported' and
+> > 'unsupported' packages (whatever the definition we will choose for those).
+> > 
+> 
+> What is a supported package or what is an unsupported package ?
+> 
+> For Mandriva it was clear, packages on which Mandriva provides support is in 
+> main, if not it's in contrib.
+
+No, since there was unsupported packages in main ( think stuff like ld.so1.2 ),
+and support could perfectly answer to questions depending on the contract, even 
+on packages in contribs.
+
+There is also weird stuff like php-yp ( in contrib ), who was built from the same source than others
+php packages, who was thus in main and supported.
+
+No to mention that there was no process for deciding what goes in main, except that it was required
+by something else in main. There is also issues of old packages that were never moved out of
+main, despites not really supported.
+
+So no, it was not clear. 
+ 
+> > > > == What about patents?
+> > > > 
+> > > > Almost no software with patents: Fedora, Opensuse
+> > > > 
+> > > >  - Essentially no media codecs except theora/vorbis/ogg/vp8 etc.
+> > > >  - Strange exception: libXft, Cairo and Qt4 are shipped with LCD
+> > > >  filtering
+> > > >  
+> > > >    support enabled, even if it is disabled in freetype
+> > > > 
+> > > > No software with enforced patents: Debian
+> > > > 
+> > > >  - not included (at least): x264 (encoder), lame mp3 (encoder)
+> > > >  - included (at least): MPEG/x decoders, H.264 decoders, MP3 decoders,
+> > > >  
+> > > >    AAC decoders, AMR decoders, DTS decoders, AC3 decoders,
+> > > >    WMV/WMA decoders, realvideo decoders, etc
+> > > > 
+> > > > Some software covered by patents not included: Mandriva
+> > > > 
+> > > >  - see below for more information
+> > > > 
+> > > > All software covered by patents allowed: Arch, Ubuntu
+> > > > 
+> > > > 
+> > > > IMO we should alter our policy to match either Fedora, Debian or
+> > > > Ubuntu.. The Mandriva policy makes no sense (for example, no AAC
+> > > > decoder but yes for H.264 decoder and MPEG-4 encoder?).
+> > > > I'm really not sure which way we should go, though. WDYT?
+> > > 
+> > > I would go the Debian way.
+> > > Ubuntu and Fedora are tied to companies, and Debian is not, so their
+> > > policies are likely more adapted to our own model.
+> > > 
+> > > Debian way seems to be more pragmatic that Ubuntu/Fedora on that matter.
+> > 
+> > Indeed, Debian's situation seems closer to ours.
+> > 
+> > However, a bit more investigation shows that the Debian policy "no enforced
+> > patents" is not really a written policy and what it means in practice is
+> > not 100% clear. A clarification request [1] has gone unanswered for 1.5
+> > years, and "missing" packages x264,lame,xvidcore are sitting in the NEW
+> > queue [2] without having been accepted or rejected yet (it has "only" been
+> > 2.5 months, though).
+> > 
+> > 
+> > BTW, other related 'missing' packages in debian are "mjpegtools", "faac",
+> > "transcode", but the first two are missing due to license reasons instead
+> > of patent issues:
+> > 
+> > mjpegtools contains source files that are "All Rights Reserved" by
+> > "MPEG/audio software simulation group" (Ubuntu has the package in
+> > multiverse, Mandriva in main)
+> > 
+> > faac contains a limitation that it is not allowed to be used in software
+> > not conforming to MPEG-2/MPEG-4 Audio standards, which makes it
+> > non-opensource (Ubuntu has the package in multiverse, Mandriva doesn't
+> > have it).
+> > 
+> > transcode is missing, but there's been no recent activity on it that would
+> > explain why it isn't there (IIRC its supported codecs are a subset of
+> > ffmpeg ones, and ffmpeg is in Debian).
+> > 
+> > 
+> > [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=522373
+> > (note that debian had some encoders disabled in ffmpeg at the time of the
+> > above report; those have since been enabled)
+> > [2] http://ftp-master.debian.org/new.html
+> 
+> Questions about patents is related to which law applies to Mageia. No answers 
+> to which law then no clear policy can be applied.
+>
+> For me, since Mageia.org will lead the project (and will own Mageia 
+> trademarks) is located in France, since build system of Mageia will be in 
+> France
+
+There is no guarantee that the BS will always be located in France. So I think you should
+not make assumptions like this.
+
+> then French law is the law we have to consider for Mageia. Debian runs 
+> under SPI organization located in the state of New York, USA, thus is ruled by 
+> US Laws.
+
+Since the only people who will have issue with this are the president ( aka Anne )
+and the people who distribute this ( ie mirrors admins ), I think we should
+ask them and follow their opinions, and only theirs. Because
+we can speak of "we have no problem", we will have nothing what ever we do, because we
+are likely not liable. Anne and mirrors owners are. So their words is what does count.
+
+-- 
+Michael Scherer
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20101015/001210.html b/zarb-ml/mageia-dev/20101015/001210.html new file mode 100644 index 000000000..a093f490e --- /dev/null +++ b/zarb-ml/mageia-dev/20101015/001210.html @@ -0,0 +1,83 @@ + + + + [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc + + + + + + + + + +

[Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Fri Oct 15 03:55:56 CEST 2010 +

+
+ +
2010/10/14 Marc Paré <marc at marcpare.com>:
+>
+> So, it sounds to me, that a core group individual, should, as an official
+> representative of the Mageia project, approach these organisations and FSF
+> to check and to get advice/opinons. Just to make sure.
+
+Although I may not speak as an official Mageia rep I will present this
+issue on the next meeting of our FSFE (FSF Europe) group (I'm a FSFE
+Fellow). Maybe I can report back some helpful facts to this
+discussion.
+
+-- 
+wobo
+
+ + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20101015/001211.html b/zarb-ml/mageia-dev/20101015/001211.html new file mode 100644 index 000000000..60c228385 --- /dev/null +++ b/zarb-ml/mageia-dev/20101015/001211.html @@ -0,0 +1,89 @@ + + + + [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc + + + + + + + + + +

[Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc

+ Marc Paré + marc at marcpare.com +
+ Fri Oct 15 04:11:45 CEST 2010 +

+
+ +
Le 2010-10-14 21:55, Wolfgang Bornath a écrit :
+> 2010/10/14 Marc Paré<marc at marcpare.com>:
+>>
+>> So, it sounds to me, that a core group individual, should, as an official
+>> representative of the Mageia project, approach these organisations and FSF
+>> to check and to get advice/opinons. Just to make sure.
+>
+> Although I may not speak as an official Mageia rep I will present this
+> issue on the next meeting of our FSFE (FSF Europe) group (I'm a FSFE
+> Fellow). Maybe I can report back some helpful facts to this
+> discussion.
+>
+
+Sound good to me. If there is a Megeia core group lurking on this 
+thread, could we delegate this task to Wolfgang or if it more of a 
+pressing matter, someone could speak to the FSF directly for an opinion?
+
+Marc
+
+
+ + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20101015/001212.html b/zarb-ml/mageia-dev/20101015/001212.html new file mode 100644 index 000000000..884b35a67 --- /dev/null +++ b/zarb-ml/mageia-dev/20101015/001212.html @@ -0,0 +1,165 @@ + + + + [Mageia-dev] How will be the realese cycle? + + + + + + + + + +

[Mageia-dev] How will be the realese cycle?

+ Fernando Parra + gato2707 at yahoo.com.mx +
+ Fri Oct 15 04:48:56 CEST 2010 +

+
+ +
Hi everybody.
+
+I feel that the concept of a new way, as it exist into my mind is not completely understood. Let me try to re-explain again. Please be patient and excuses any mistake with my English (I'm totally out of practice):
+
+I'm talking about to liberate to novice/novel/without experience user, about concepts like backports, but I'm not talking about close/disappear/eliminate/forgot backports.
+
+Why? because a big share of them will arrive from a very different environment (especially windows), and as you now, in there those concepts are not only estrange, they simply don't exists.
+When a Windows user wants/needs to update a program, as much the only thing that he/she must do is unninstall the old/previous version and then install the new one.
+
+What programs? Following the same idea, about these kind of users, we should ask: what programs they usually upgrade? The answer could be found asking to the user's themselves, but certainly could be another ways.
+
+Why not all backports? Reason 1: Because a lot of them don't care about the new version of CUPS (in example) or the new version of Maxima (I'm sure there are a lot clearly examples).
+Reason 2: Because there are packages that may causes some incidents after upgrade them.
+
+How we can solve this situation? Offering a default automatic upgrade for a small group of packages, especially when they change in an important way, in example Firefox 3.6x 3.6x+ or to 4.x
+
+With this in mind:
+
+> What aspects of the Mandriva backports solution are not satisfactory?
+
+> -The fact that not everything is available as a backport?
+
+Not all are in backports, more these users don't want/understand a big share of them
+
+> -That users don't know how to request a backport?
+
+That is true, more, they don't want to learn about that, they only want a new version of their favourite program.
+
+> -That too many backports are available?
+
+This is matter of who are revising backports, for novice? Yes there are to many. For the geek or the expert? Maybe never there will enough of them.
+ 
+> -That all users don't get them by default?
+> -That users doing network installs by default don't get the backport on 
+> initial installation?
+
+No, they are not get them if we will use a potentially problematic repository.
+
+> -That users aren't aware of backports?
+> -Something else?
+
+Panic? Fear? Baal, Luzbel and other demons in their minds?
+
+> Technically speaking?
+> Less than 'urpmi --searchmedia Backports chromium' ?
+
+If I was a novice my answer will be: What hell is that?
+
+> Again, before we can decide what *more* we should do (what significant 
+> resources we need to commit), maybe we should first understand why the 
+> existing features (which have significant effort behind them) are not 
+> resulting in user satisfaction.
+
+More and more reasons to prepare very carefully our offer. All we here appreciate those efforts and there are no way to send them to trash
+
+> Personally I think a poll without educating everyone about what exactly
+> each choice would mean is useless. We first need to elaborate detailed
+> alternatives before anyone can make an informed choice.
+
+IMHO, a democracy without education is not democracy, is populism. I agree at all, we need first elaborate a well structured alternatives and then, explicitly after inform and educate our community we can run a poll, or prepare a council, or any other appropriated way. 
+
+> backports should be supported for security patches and bug fixes just like
+> the main packages (if not instead of the main packages).
+> Of course the security patch could be simply provided by backporting a
+> newer version of the package, no need to make patches for each version.
+
+That is essential, any upgrade must be supported (other valid reason for an small group of packages).
+
+> What I mean is basically when new updates get presented (which would
+> include new backports) the user could untick specific packages (as is
+> possible now) but also have a second tick-box to store the choice
+> permanently in the skip.list.
+> This would give the user more choice of which packages he wants to always
+> update to the newest version and wich ones he/she prefers to keep frozen
+> at the same version.
+
+Please try to explain that to my grandma, or maybe you could be lucky with some of my students.
+
+> New users who frequented the forums always got to know what backports
+> are pretty fast. And bugzilla is the perfect system for asking for a
+> backport, that worked pretty good.
+
+These users are walking to change into intermediate users, they are no longer basic users. This only for the simple fact that they are posting in a technical forum. Let me remind you: 1,300 millions of Hispanics and only 130 votes at the BlogDrake poll.
+
+> I was thinking about writing a proposal as you suggested, but so far I 
+> haven't found the time.
+> I don't think this is that urgent, since backports only become an issue 
+> once we have the first release out, but I will try to write up a 
+> proposal well before that.
+
+I'm writing a proposal as Tux99 does, I need find time for finish it and then translate it.
+
+Regards from México
+-- 
+Fernando Parra <gato2707 at yahoo.com.mx>
+
+ + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20101015/001213.html b/zarb-ml/mageia-dev/20101015/001213.html new file mode 100644 index 000000000..4c9c70bc5 --- /dev/null +++ b/zarb-ml/mageia-dev/20101015/001213.html @@ -0,0 +1,173 @@ + + + + [Mageia-dev] How will be the realese cycle? + + + + + + + + + +

[Mageia-dev] How will be the realese cycle?

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Fri Oct 15 06:32:13 CEST 2010 +

+
+ +
On 15 October 2010 04:48, Fernando Parra <gato2707 at yahoo.com.mx> wrote:
+> Hi everybody.
+>
+> I feel that the concept of a new way, as it exist into my mind is not completely understood. Let me try to re-explain again. Please be patient and excuses any mistake with my English (I'm totally out of practice):
+>
+> I'm talking about to liberate to novice/novel/without experience user, about concepts like backports, but I'm not talking about close/disappear/eliminate/forgot backports.
+>
+> Why? because a big share of them will arrive from a very different environment (especially windows), and as you now, in there those concepts are not only estrange, they simply don't exists.
+> When a Windows user wants/needs to update a program, as much the only thing that he/she must do is unninstall the old/previous version and then install the new one.
+>
+> What programs? Following the same idea, about these kind of users, we should ask: what programs they usually upgrade? The answer could be found asking to the user's themselves, but certainly could be another ways.
+>
+> Why not all backports? Reason 1: Because a lot of them don't care about the new version of CUPS (in example) or the new version of Maxima (I'm sure there are a lot clearly examples).
+> Reason 2: Because there are packages that may causes some incidents after upgrade them.
+>
+> How we can solve this situation? Offering a default automatic upgrade for a small group of packages, especially when they change in an important way, in example Firefox 3.6x 3.6x+ or to 4.x
+>
+> With this in mind:
+>
+>> What aspects of the Mandriva backports solution are not satisfactory?
+>
+>> -The fact that not everything is available as a backport?
+>
+> Not all are in backports, more these users don't want/understand a big share of them
+>
+>> -That users don't know how to request a backport?
+>
+> That is true, more, they don't want to learn about that, they only want a new version of their favourite program.
+>
+>> -That too many backports are available?
+>
+> This is matter of who are revising backports, for novice? Yes there are to many. For the geek or the expert? Maybe never there will enough of them.
+>
+>> -That all users don't get them by default?
+>> -That users doing network installs by default don't get the backport on
+>> initial installation?
+>
+> No, they are not get them if we will use a potentially problematic repository.
+>
+>> -That users aren't aware of backports?
+>> -Something else?
+>
+> Panic? Fear? Baal, Luzbel and other demons in their minds?
+>
+>> Technically speaking?
+>> Less than 'urpmi --searchmedia Backports chromium' ?
+>
+> If I was a novice my answer will be: What hell is that?
+>
+>> Again, before we can decide what *more* we should do (what significant
+>> resources we need to commit), maybe we should first understand why the
+>> existing features (which have significant effort behind them) are not
+>> resulting in user satisfaction.
+>
+> More and more reasons to prepare very carefully our offer. All we here appreciate those efforts and there are no way to send them to trash
+>
+>> Personally I think a poll without educating everyone about what exactly
+>> each choice would mean is useless. We first need to elaborate detailed
+>> alternatives before anyone can make an informed choice.
+>
+> IMHO, a democracy without education is not democracy, is populism. I agree at all, we need first elaborate a well structured alternatives and then, explicitly after inform and educate our community we can run a poll, or prepare a council, or any other appropriated way.
+>
+>> backports should be supported for security patches and bug fixes just like
+>> the main packages (if not instead of the main packages).
+>> Of course the security patch could be simply provided by backporting a
+>> newer version of the package, no need to make patches for each version.
+>
+> That is essential, any upgrade must be supported (other valid reason for an small group of packages).
+>
+>> What I mean is basically when new updates get presented (which would
+>> include new backports) the user could untick specific packages (as is
+>> possible now) but also have a second tick-box to store the choice
+>> permanently in the skip.list.
+>> This would give the user more choice of which packages he wants to always
+>> update to the newest version and wich ones he/she prefers to keep frozen
+>> at the same version.
+>
+> Please try to explain that to my grandma, or maybe you could be lucky with some of my students.
+>
+>> New users who frequented the forums always got to know what backports
+>> are pretty fast. And bugzilla is the perfect system for asking for a
+>> backport, that worked pretty good.
+>
+> These users are walking to change into intermediate users, they are no longer basic users. This only for the simple fact that they are posting in a technical forum. Let me remind you: 1,300 millions of Hispanics and only 130 votes at the BlogDrake poll.
+>
+>> I was thinking about writing a proposal as you suggested, but so far I
+>> haven't found the time.
+>> I don't think this is that urgent, since backports only become an issue
+>> once we have the first release out, but I will try to write up a
+>> proposal well before that.
+>
+> I'm writing a proposal as Tux99 does, I need find time for finish it and then translate it.
+>
+> Regards from México
+> --
+> Fernando Parra <gato2707 at yahoo.com.mx>
+>
+
+Your reply doesn't show whom you're quoting. Please pay more attention
+to show whom you're quoting when quoting others' posts :)
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20101015/001214.html b/zarb-ml/mageia-dev/20101015/001214.html new file mode 100644 index 000000000..adc16bae7 --- /dev/null +++ b/zarb-ml/mageia-dev/20101015/001214.html @@ -0,0 +1,222 @@ + + + + [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc + + + + + + + + + +

[Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc

+ Olivier Méjean + omejean at yahoo.fr +
+ Fri Oct 15 07:43:34 CEST 2010 +

+
+ +
Le vendredi 15 octobre 2010 01:18:37, Michael scherer a écrit :
+> On Thu, Oct 14, 2010 at 09:57:03PM +0200, Olivier Méjean wrote:
+> > Le jeudi 14 octobre 2010 20:55:01, Anssi Hannula a écrit :
+> > > On Wednesday 13 October 2010 20:22:01 Michael Scherer wrote:
+> > > > Le mardi 12 octobre 2010 à 18:02 +0300, Anssi Hannula a écrit :
+> > > > > Hi all!
+> > > > > 
+> > > > > Do people have any thoughts on what kind of repository/media
+> > > > > sectioning we should use on Mageia, and what should those sections
+> > > > > contain?
+> > > > > 
+> > > > > Note that I won't talk about backports / private repositories in
+> > > > > this post, only about the basic sectioning and packages in those.
+> > > > > 
+> > > > > Some points to consider (I've written my opinion in ones where I
+> > > > > have one):
+> > > > > 
+> > > > > == Do we want a separated core repository?
+> > > > > 
+> > > > > No separated core: Fedora, Debian, Opensuse
+> > > > > Separated core: Mandriva (main), Ubuntu (main), Arch (Core)
+> > > > 
+> > > > How do we decide what would be in core ?
+> > > 
+> > > AFAICS the only reasonable reason would be to separate 'supported' and
+> > > 'unsupported' packages (whatever the definition we will choose for
+> > > those).
+> > 
+> > What is a supported package or what is an unsupported package ?
+> > 
+> > For Mandriva it was clear, packages on which Mandriva provides support is
+> > in main, if not it's in contrib.
+> 
+> No, since there was unsupported packages in main ( think stuff like
+> ld.so1.2 ), and support could perfectly answer to questions depending on
+> the contract, even on packages in contribs.
+> 
+> There is also weird stuff like php-yp ( in contrib ), who was built from
+> the same source than others php packages, who was thus in main and
+> supported.
+> 
+> No to mention that there was no process for deciding what goes in main,
+> except that it was required by something else in main. There is also
+> issues of old packages that were never moved out of main, despites not
+> really supported.
+> 
+> So no, it was not clear.
+
+http://wiki.mandriva.com/en/Policies/SoftwareMedia
+It seems clear that distinction of main and contrib was just related to 
+Mandriva wishes.
+
+> 
+> > > > > == What about patents?
+> > > > > 
+> > > > > Almost no software with patents: Fedora, Opensuse
+> > > > > 
+> > > > >  - Essentially no media codecs except theora/vorbis/ogg/vp8 etc.
+> > > > >  - Strange exception: libXft, Cairo and Qt4 are shipped with LCD
+> > > > >  filtering
+> > > > >  
+> > > > >    support enabled, even if it is disabled in freetype
+> > > > > 
+> > > > > No software with enforced patents: Debian
+> > > > > 
+> > > > >  - not included (at least): x264 (encoder), lame mp3 (encoder)
+> > > > >  - included (at least): MPEG/x decoders, H.264 decoders, MP3
+> > > > >  decoders,
+> > > > >  
+> > > > >    AAC decoders, AMR decoders, DTS decoders, AC3 decoders,
+> > > > >    WMV/WMA decoders, realvideo decoders, etc
+> > > > > 
+> > > > > Some software covered by patents not included: Mandriva
+> > > > > 
+> > > > >  - see below for more information
+> > > > > 
+> > > > > All software covered by patents allowed: Arch, Ubuntu
+> > > > > 
+> > > > > 
+> > > > > IMO we should alter our policy to match either Fedora, Debian or
+> > > > > Ubuntu.. The Mandriva policy makes no sense (for example, no AAC
+> > > > > decoder but yes for H.264 decoder and MPEG-4 encoder?).
+> > > > > I'm really not sure which way we should go, though. WDYT?
+> > > > 
+> > > > I would go the Debian way.
+> > > > Ubuntu and Fedora are tied to companies, and Debian is not, so their
+> > > > policies are likely more adapted to our own model.
+> > > > 
+> > > > Debian way seems to be more pragmatic that Ubuntu/Fedora on that
+> > > > matter.
+> > > 
+> > > Indeed, Debian's situation seems closer to ours.
+> > > 
+> > > However, a bit more investigation shows that the Debian policy "no
+> > > enforced patents" is not really a written policy and what it means in
+> > > practice is not 100% clear. A clarification request [1] has gone
+> > > unanswered for 1.5 years, and "missing" packages x264,lame,xvidcore
+> > > are sitting in the NEW queue [2] without having been accepted or
+> > > rejected yet (it has "only" been 2.5 months, though).
+> > > 
+> > > 
+> > > BTW, other related 'missing' packages in debian are "mjpegtools",
+> > > "faac", "transcode", but the first two are missing due to license
+> > > reasons instead of patent issues:
+> > > 
+> > > mjpegtools contains source files that are "All Rights Reserved" by
+> > > "MPEG/audio software simulation group" (Ubuntu has the package in
+> > > multiverse, Mandriva in main)
+> > > 
+> > > faac contains a limitation that it is not allowed to be used in
+> > > software not conforming to MPEG-2/MPEG-4 Audio standards, which makes
+> > > it non-opensource (Ubuntu has the package in multiverse, Mandriva
+> > > doesn't have it).
+> > > 
+> > > transcode is missing, but there's been no recent activity on it that
+> > > would explain why it isn't there (IIRC its supported codecs are a
+> > > subset of ffmpeg ones, and ffmpeg is in Debian).
+> > > 
+> > > 
+> > > [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=522373
+> > > (note that debian had some encoders disabled in ffmpeg at the time of
+> > > the above report; those have since been enabled)
+> > > [2] http://ftp-master.debian.org/new.html
+> > 
+> > Questions about patents is related to which law applies to Mageia. No
+> > answers to which law then no clear policy can be applied.
+> > 
+> > For me, since Mageia.org will lead the project (and will own Mageia
+> > trademarks) is located in France, since build system of Mageia will be in
+> > France
+> 
+> There is no guarantee that the BS will always be located in France. So I
+> think you should not make assumptions like this.
+> 
+> > then French law is the law we have to consider for Mageia. Debian runs
+> > under SPI organization located in the state of New York, USA, thus is
+> > ruled by US Laws.
+> 
+> Since the only people who will have issue with this are the president ( aka
+> Anne ) and the people who distribute this ( ie mirrors admins ), I think
+> we should ask them and follow their opinions, and only theirs. Because
+> we can speak of "we have no problem", we will have nothing what ever we do,
+> because we are likely not liable. Anne and mirrors owners are. So their
+> words is what does count.
+
+So is Mageia a community project or not ?
+Then when we will talk about Marketing stuff we will follow only marketing 
+group opinions ?
+
+Of course their views count, but there is a difference between the 
+responsability of Mageia association that must comply with French Laws and 
+mirrors admins that must comply with the laws of the country the mirror is 
+located. OpenBSD project is located in Canada to avoid some US law about 
+restriction for export (meanwhile for example Red Hat has a policy for its 
+employees not to answer by IRC to demand from an user located in countries 
+that are under export restriction due to US law)
+
+If the structure of the repos need to be adapted so one part can be not 
+mirrored in certain countries that could be a solution (let's call it export-
+restriction)
+
+I do quite accept that Fedora, OpenSuse, Debian comply with US Law since there 
+are located in the USA, thus accepting their policy about software patents. I 
+would like that the same occurs for Mageia that is located in France.
+
+Olivier
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20101015/001215.html b/zarb-ml/mageia-dev/20101015/001215.html new file mode 100644 index 000000000..6551c6a0a --- /dev/null +++ b/zarb-ml/mageia-dev/20101015/001215.html @@ -0,0 +1,112 @@ + + + + [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc + + + + + + + + + +

[Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc

+ Romain d'Alverny + rdalverny at gmail.com +
+ Fri Oct 15 10:44:16 CEST 2010 +

+
+ +
On Fri, Oct 15, 2010 at 07:43, Olivier Méjean <omejean at yahoo.fr> wrote:
+> Le vendredi 15 octobre 2010 01:18:37, Michael scherer a écrit :
+>> On Thu, Oct 14, 2010 at 09:57:03PM +0200, Olivier Méjean wrote:
+>> Since the only people who will have issue with this are the president ( aka
+>> Anne ) and the people who distribute this ( ie mirrors admins ), I think
+>> we should ask them and follow their opinions, and only theirs. Because
+>> we can speak of "we have no problem", we will have nothing what ever we do,
+>> because we are likely not liable. Anne and mirrors owners are. So their
+>> words is what does count.
+>
+> So is Mageia a community project or not ?
+
+Yes and? That doesn't prevent that there is an association that will
+own trademark, servers, manage money, etc. and that is a legal
+construction that may be liable, in France or in regard to
+international laws.
+
+> Then when we will talk about Marketing stuff we will follow only marketing
+> group opinions ?
+
+Who talks about marketing here? Please stay on topic. Misc is talking
+about official representatives, board members liability - not only in
+France, but abroad. We're not in Merovingian times where one was
+judged according to his original land's law.
+
+> Of course their views count, but there is a difference between the
+> responsability of Mageia association that must comply with French Laws
+
+Sure but we can't just say that. See below.
+
+> I do quite accept that Fedora, OpenSuse, Debian comply with US Law since there
+> are located in the USA, thus accepting their policy about software patents. I
+> would like that the same occurs for Mageia that is located in France.
+
+As misc said, there is no guarantee, neither definitive rule that the
+build system (or parts of it) would be only located in France. There
+is no guarantee that board members will always be in France. There is
+no guarantee that we won't setup affiliate not-for-profit orgs abroad.
+Etc.
+
+We're going to distribute software all around the world in several
+ways, potentially, so we must think global here, and not only local.
+
+If we were to follow the "let's only check local law", believe me, we
+wouldn't have located the association in France. There are other
+places far more interesting in this regard.
+
+So the question is not "where is it allowed?" and "is it allowed where
+we build it?" but:
+ - what do we _want_ to have in software repositories and _why_?
+ - what are legal constraints that we must deal with
+(building/packaging/distributing/using), and how?
+ - how can we make this a predictable process for future situations?
+
+
+Romain
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20101015/001216.html b/zarb-ml/mageia-dev/20101015/001216.html new file mode 100644 index 000000000..a23d5c6b5 --- /dev/null +++ b/zarb-ml/mageia-dev/20101015/001216.html @@ -0,0 +1,143 @@ + + + + [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc + + + + + + + + + +

[Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc

+ Tux99 + tux99-mga at uridium.org +
+ Fri Oct 15 11:40:49 CEST 2010 +

+
+ +
On Fri, 15 Oct 2010, Romain d'Alverny wrote:
+
+> > So is Mageia a community project or not ?
+> 
+> Yes and? That doesn't prevent that there is an association that will
+> own trademark, servers, manage money, etc. and that is a legal
+> construction that may be liable, in France or in regard to
+> international laws.
+
+No one said anything about breaking French laws, in fact what we said is 
+to follow French law.
+There is no such thing as international law, only international treaties 
+that might have been incorporated into French law.
+ 
+> Who talks about marketing here? Please stay on topic. Misc is talking
+> about official representatives, board members liability - not only in
+> France, but abroad. We're not in Merovingian times where one was
+> judged according to his original land's law.
+
+Assuming that a board member get's arrested in the US because Mageia 
+includes software that is covered by patents is laughable, especially 
+when that same software is mirrored without problems on US hosts.
+I think anyone who is that frightened shouldn't candidate him/herself as 
+board member.
+
+> As misc said, there is no guarantee, neither definitive rule that the
+> build system (or parts of it) would be only located in France.
+
+Moving the BS would only make sense if the countries it moves to 
+provides a better legal environment, not a worse one, so this argument 
+doesn't make sense.
+
+> There is no guarantee that board members will always be in France. 
+
+As I said no one is forced to be a board member.
+
+> There is no guarantee that we won't setup affiliate not-for-profit 
+> orgs abroad.
+> Etc.
+
+If for this reason Mageia has to be a crippled mediocre product then all 
+these precautions were a wast of time and efforts too.
+There is no point in making a grand, legally sound structure for a
+useless product with a fading community.
+
+> We're going to distribute software all around the world in several
+> ways, potentially, so we must think global here, and not only local.
+
+True, but take global corporations as example, corporations take 
+advantage legal evironments offered by specific countries to achieve 
+their aims, rather than dumb down their products and services so that 
+they comply with all laws in all countries.
+
+A successfull Mageia would strive to take advantage of the countries 
+with the best laws for it's interest rather than plan according to the 
+lowest common denominator.
+
+> wouldn't have located the association in France. There are other
+> places far more interesting in this regard.
+
+And if you want Mageia to be really successful you should take advantage 
+of those places.
+ 
+>  - what do we _want_ to have in software repositories and _why_?
+
+Easy, we want the best distro possible, with the best possible out of 
+the box experience, which for many people includes all necessary codecs 
+to play every possible media file, to enable transcoding, audio video 
+production, privacy tools, encryption, etc.
+
+In other words freedom and ease of use for the user.
+
+>  - what are legal constraints that we must deal with
+> (building/packaging/distributing/using), and how?
+
+We should strive to take advantage of the best legal environment to make 
+our targets possible.
+
+>  - how can we make this a predictable process for future situations?
+
+No one can predict the future, laws change all the time so the only way 
+is to base ourselves on current valid laws and keep frexible to move to 
+a better legal environment if necessary.
+
+Opportunities not fear should be the key word here.
+
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20101015/001217.html b/zarb-ml/mageia-dev/20101015/001217.html new file mode 100644 index 000000000..44eb89af6 --- /dev/null +++ b/zarb-ml/mageia-dev/20101015/001217.html @@ -0,0 +1,82 @@ + + + + [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc + + + + + + + + + +

[Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc

+ Anssi Hannula + anssi.hannula at iki.fi +
+ Fri Oct 15 13:30:35 CEST 2010 +

+
+ +
Michael scherer kirjoitti perjantai, 15. lokakuuta 2010 02:18:37:
+> On Thu, Oct 14, 2010 at 09:57:03PM +0200, Olivier Méjean wrote:
+> > then French law is the law we have to consider for Mageia. Debian runs
+> > under SPI organization located in the state of New York, USA, thus is
+> > ruled by US Laws.
+> 
+> Since the only people who will have issue with this are the president ( aka
+> Anne ) and the people who distribute this ( ie mirrors admins ), I think
+> we should ask them and follow their opinions, and only theirs. Because
+> we can speak of "we have no problem", we will have nothing what ever we do,
+> because we are likely not liable. Anne and mirrors owners are. So their
+> words is what does count.
+
+Seems sensible to ask the mirror owners. It is possible some of them have not 
+been aware of the problem at all, so I think we should make sure they 
+understand that Ubuntu, Debian, Arch, etc. also contain patented technologies 
+(to avoid the situation where they are willing to mirror Ubuntu/Debian/Arch 
+but not allow patented software in Mageia, just because the other 
+distributions didn't notify them of the issue; if they don't want to mirror 
+Mageia if it contained patent-encumbered software, they really shouldn't be 
+mirroring those other distributions either).
+
+-- 
+Anssi Hannula
+
+ + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20101015/001218.html b/zarb-ml/mageia-dev/20101015/001218.html new file mode 100644 index 000000000..9f022d156 --- /dev/null +++ b/zarb-ml/mageia-dev/20101015/001218.html @@ -0,0 +1,89 @@ + + + + [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc + + + + + + + + + +

[Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc

+ Tux99 + tux99-mga at uridium.org +
+ Fri Oct 15 13:45:53 CEST 2010 +

+
+ +
On Fri, 15 Oct 2010, Anssi Hannula wrote:
+
+> Seems sensible to ask the mirror owners. It is possible some of them have not 
+> been aware of the problem at all, so I think we should make sure they 
+> understand that Ubuntu, Debian, Arch, etc. also contain patented technologies 
+> (to avoid the situation where they are willing to mirror Ubuntu/Debian/Arch 
+> but not allow patented software in Mageia, just because the other 
+> distributions didn't notify them of the issue; if they don't want to mirror 
+> Mageia if it contained patent-encumbered software, they really shouldn't be 
+> mirroring those other distributions either).
+
+While you are right that we should point out that Ubuntu/Debian/Arch 
+contain the same potentially patent-infringing (in a few countries) 
+software as Mageia IN CASE THEY OBJECT to this in Mageia, I don't see 
+why we should stirr up a hornets nest in the first place. 
+
+The mirror maintainers are responsible adults, you don't need to point 
+out anything to them, it's their decision and their responsibility to 
+comply with local laws of their country.
+
+I assume none of us is a lawyer (especially not with expertise in the 
+laws of all countries), so giving legal advice to the mirror admins is 
+pointless and most likely counterproductive.
+
+Imagine how other distros will react if they find out that Mageia 
+induced some mirrors to drop their distros, now that would make Mageia 
+popular in the wider Linux community...
+
+
+ + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20101015/001219.html b/zarb-ml/mageia-dev/20101015/001219.html new file mode 100644 index 000000000..a743710fb --- /dev/null +++ b/zarb-ml/mageia-dev/20101015/001219.html @@ -0,0 +1,76 @@ + + + + [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc + + + + + + + + + +

[Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc

+ Romain d'Alverny + rdalverny at gmail.com +
+ Fri Oct 15 14:11:30 CEST 2010 +

+
+ +
On Fri, Oct 15, 2010 at 13:45, Tux99 <tux99-mga at uridium.org> wrote:
+> I assume none of us is a lawyer (especially not with expertise in the
+> laws of all countries), so giving legal advice to the mirror admins is
+> pointless and most likely counterproductive.
+
+Unless we set up a legal team partly for that. But that makes a
+serious load of work to consider here. To consider nonetheless.
+
+> Imagine how other distros will react if they find out that Mageia
+> induced some mirrors to drop their distros, now that would make Mageia
+> popular in the wider Linux community...
+
+Of course not an option... that's not even the topic... please.
+
+Romain
+
+ + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20101015/001220.html b/zarb-ml/mageia-dev/20101015/001220.html new file mode 100644 index 000000000..afbfab934 --- /dev/null +++ b/zarb-ml/mageia-dev/20101015/001220.html @@ -0,0 +1,105 @@ + + + + [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc + + + + + + + + + +

[Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc

+ yvan munoz + mr.yvan.munoz at gmail.com +
+ Fri Oct 15 14:22:39 CEST 2010 +

+
+ +
Hello list :)
+
+I now it's impossible to stop discussion for me, so i could only post my
+personnal point of view.
+
+First:
+I am Libre software user.
+I am pragmatic.
+
+Then :
+Please not use any non-free (as libre) software into Mageia distribution or
+repository. Never.
+There is, however, a very strict frontier : we could only include
+hardware imperative necessity, such as firmware for network cards.
+
+No nonfree drivers when free equivalent are possibles, no flash, no nonfree
+browser, no patent-troll tech : anything but free. And only exception for
+no-equivalent firmware hardware support.
+
+###
+
+Another point of view, on repo orga now :
+This is not Europe of supporting U.S. patents.
+But the U.S. repo sysadmin to be able to comply with law og their own
+countries.
+
+I think all non-free could be supported directly by users and accessibles
+through "users repo". Not in (only one please) Mageia Repo. And Users Repo
+could contains drivers, patent-troll techno, flash, etc, in additon with
+more classicals softwares into "users repo".
+
+benefits :
+Free for all
+Keep Mageia Free as Libre.
+Dont block Mageia install due to firmware cause. Important to have
+easy-as-possible hardware support.
+Open second repo for users, and give reasons in donate non-free softwares to
+users support.
+
+
+Regards
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20101015/e2ce36cb/attachment.html>
+
+ + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20101015/001221.html b/zarb-ml/mageia-dev/20101015/001221.html new file mode 100644 index 000000000..3d5463b43 --- /dev/null +++ b/zarb-ml/mageia-dev/20101015/001221.html @@ -0,0 +1,76 @@ + + + + [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc + + + + + + + + + +

[Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc

+ Tux99 + tux99-mga at uridium.org +
+ Fri Oct 15 14:29:21 CEST 2010 +

+
+ +
On Fri, 15 Oct 2010, yvan munoz wrote:
+
+> I think all non-free could be supported directly by users and accessibles
+> through "users repo". Not in (only one please) Mageia Repo. And Users Repo
+> could contains drivers, patent-troll techno, flash, etc, in additon with
+> more classicals softwares into "users repo".
+
+Mageia is a community distro which means made by users for users.
+Therefore a separate 'user' repo makes no sense at all, all Mageia repos 
+are user repos.
+
+And if you are such a freedom advocate then you should respect
+freedom OF CHOICE for other users too, you don't have to install the 
+non-libre software that might be in the repos or on the isos.
+
+
+ + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20101015/001222.html b/zarb-ml/mageia-dev/20101015/001222.html new file mode 100644 index 000000000..47a0f2f3b --- /dev/null +++ b/zarb-ml/mageia-dev/20101015/001222.html @@ -0,0 +1,68 @@ + + + + [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc + + + + + + + + + +

[Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc

+ yvan munoz + mr.yvan.munoz at gmail.com +
+ Fri Oct 15 14:31:09 CEST 2010 +

+
+ +
2010/10/15 Tux99 <tux99-mga at uridium.org>
+
+>
+I agree.
+it is a misuse of the word "user".
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20101015/6f4e6752/attachment.html>
+
+ + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20101015/001223.html b/zarb-ml/mageia-dev/20101015/001223.html new file mode 100644 index 000000000..5c8e443af --- /dev/null +++ b/zarb-ml/mageia-dev/20101015/001223.html @@ -0,0 +1,143 @@ + + + + [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc + + + + + + + + + +

[Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc

+ Romain d'Alverny + rdalverny at gmail.com +
+ Fri Oct 15 14:36:46 CEST 2010 +

+
+ +
On Fri, Oct 15, 2010 at 11:40, Tux99 <tux99-mga at uridium.org> wrote:
+> [...]
+
+Ok. This is, again, going nowhere. We don't even follow who is trying
+to make what point.
+
+> On Fri, 15 Oct 2010, Romain d'Alverny wrote:
+>> Who talks about marketing here? Please stay on topic. Misc is talking
+>> about official representatives, board members liability - not only in
+>> France, but abroad. We're not in Merovingian times where one was
+>> judged according to his original land's law.
+>
+> Assuming that a board member get's arrested in the US because Mageia
+
+Who talks about being arrested or "frightened"?... Being liable and
+being arrested are two distinct things...
+
+
+>> There is no guarantee that we won't setup affiliate not-for-profit
+>> orgs abroad.
+>> Etc.
+>
+> If for this reason Mageia has to be a crippled mediocre product then all
+> these precautions were a wast of time and efforts too.
+> There is no point in making a grand, legally sound structure for a
+> useless product with a fading community.
+
+...
+
+I don't understand your point, neither your attitude here...
+
+> A successfull Mageia would strive to take advantage of the countries
+> with the best laws for it's interest rather than plan according to the
+> lowest common denominator.
+
+Who said that was the plan?...
+
+>> wouldn't have located the association in France. There are other
+>> places far more interesting in this regard.
+>
+> And if you want Mageia to be really successful you should take advantage
+> of those places.
+
+Yes, right. :-) You know better the picture/history we (founders) are
+in. We're not going to incorporate right now at the other end of the
+world. :-)
+
+>>  - what do we _want_ to have in software repositories and _why_?
+>
+> Easy, we want the best distro possible, with the best possible out of
+> the box experience,
+
+That is a very vague statement. "I want it all". However, we will get
+to that in time, see my previous post (yesterday) about the goal(s) of
+Mageia.org.
+
+>>  - what are legal constraints that we must deal with
+>> (building/packaging/distributing/using), and how?
+>
+> We should strive to take advantage of the best legal environment to make
+> our targets possible.
+
+Sure. In a sustainable way.
+
+>>  - how can we make this a predictable process for future situations?
+>
+> No one can predict the future, laws change all the time so the only way
+> is to base ourselves on current valid laws and keep frexible to move to
+> a better legal environment if necessary.
+
+This was not relative to laws only, but to the project mission first.
+
+> Opportunities not fear should be the key word here.
+
+Who speaks about fear? we're speaking about finding a policy for the
+project here.
+
+And I believe we are all able to _discuss_ this calmly without being
+offensive... Again, this conversation is going nowhere.
+
+Please, guys, post a _proposal_ for comments somewhere in a fixed
+format (blog, wiki page, anything) before proposing it for comment in
+a mail discussion. Or... make sure to frame the conversation, in
+topic, in time and in language.
+
+Cheers,
+
+Romain
+
+ + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20101015/001224.html b/zarb-ml/mageia-dev/20101015/001224.html new file mode 100644 index 000000000..80e33f86a --- /dev/null +++ b/zarb-ml/mageia-dev/20101015/001224.html @@ -0,0 +1,228 @@ + + + + [Mageia-dev] How will be the realese cycle? + + + + + + + + + +

[Mageia-dev] How will be the realese cycle?

+ Buchan Milne + bgmilne at multilinks.com +
+ Fri Oct 15 13:42:03 CEST 2010 +

+
+ +
On Friday, 15 October 2010 03:48:56 Fernando Parra wrote:
+> Hi everybody.
+> 
+> I feel that the concept of a new way, as it exist into my mind is not
+> completely understood. Let me try to re-explain again. Please be patient
+> and excuses any mistake with my English (I'm totally out of practice):
+> 
+> I'm talking about to liberate to novice/novel/without experience user,
+> about concepts like backports, but I'm not talking about
+> close/disappear/eliminate/forgot backports.
+> 
+> Why? because a big share of them will arrive from a very different
+> environment (especially windows), and as you now, in there those concepts
+> are not only estrange, they simply don't exists. When a Windows user
+> wants/needs to update a program, as much the only thing that he/she must
+> do is unninstall the old/previous version and then install the new one.
+> 
+> What programs? Following the same idea, about these kind of users, we
+> should ask: what programs they usually upgrade? The answer could be found
+> asking to the user's themselves, but certainly could be another ways.
+> 
+> Why not all backports? Reason 1: Because a lot of them don't care about the
+> new version of CUPS (in example) or the new version of Maxima (I'm sure
+> there are a lot clearly examples). Reason 2: Because there are packages
+> that may causes some incidents after upgrade them.
+> 
+> How we can solve this situation? Offering a default automatic upgrade for a
+> small group of packages, especially when they change in an important way,
+> in example Firefox 3.6x 3.6x+ or to 4.x
+> 
+> With this in mind:
+> > What aspects of the Mandriva backports solution are not satisfactory?
+> > 
+> > -The fact that not everything is available as a backport?
+> 
+> Not all are in backports, more these users don't want/understand a big
+> share of them
+
+So, we must "dumb down" everything, and not provide openldap backports for 
+people running servers who want a convenient way to run the software version 
+that will allow them to file bugs upstream (OpenLDAP team doesn't respond to 
+bugs filed on non-current releases)?
+
+> > -That users don't know how to request a backport?
+> 
+> That is true, more, they don't want to learn about that, they only want a
+> new version of their favourite program.
+
+What do we do in the case where a new version of some software is available, 
+and has been sent to cooker? How do we decide whether it should go to 
+backports or not? And for which releases?
+
+(FYI, for Mandriva users can typically request backports in bugzilla or on 
+IRC, but we may need better means).
+
+> > -That too many backports are available?
+> 
+> This is matter of who are revising backports, for novice? Yes there are to
+> many. For the geek or the expert? Maybe never there will enough of them.
+> 
+> > -That all users don't get them by default?
+> > -That users doing network installs by default don't get the backport on
+> > initial installation?
+> 
+> No, they are not get them if we will use a potentially problematic
+> repository.
+> 
+> > -That users aren't aware of backports?
+> > -Something else?
+> 
+> Panic? Fear? Baal, Luzbel and other demons in their minds?
+> 
+> > Technically speaking?
+> > Less than 'urpmi --searchmedia Backports chromium' ?
+> 
+> If I was a novice my answer will be: What hell is that?
+
+This was a response to 'users must do less', not 'it must be very easy'. At 
+present, users need to do just one thing. We can fix the ease of doing that 
+one thing, if we understand the problem correctly.
+
+I note you chose to leave out:
+
+> > Or, should it be more obvious in rpmdrake or similar? How about
+> > commenting on my proposal for UI change in rpmdrake making backports
+> > more obvious?
+
+The proposal I refer to is:
+"
+Now, maybe the user interface needs to be improved. For example, maybe there 
+should be no dropdown box, but instead when searching for a package by name, 
+it should show you all the versions:
+
+============================================================================
+Find: | digikam         | In: ->Graphical applications   |By: ->Package Name
+----------------------------------------------------------------------------
+Package|                |Status                          | Action          
++digikam                |Security update recommended     |Update            |
+- 1.3.0-1mdv            |Installed                       |Uninstall         |
+- 1.3.0-1.1mdv          |Security Update                 |Update            |
+- 1.4.0-4mdv            |Unsupported upgrade (backport)  |Upgrade           |
+
+-----------------------------------------------------------------------------
+digikam - A KDE ........
+
+=============================================================================
+"
+
+Further, we could have some settings regarding what the user's preference is, 
+and possibly even per-package. For example, maybe the user would not like only 
+updates by default, except for chromium and pidgin where they want backports. 
+Or, maybe another user wants all backports, except OpenOffice.org, where they 
+just want  updates.
+
+> > Again, before we can decide what *more* we should do (what significant
+> > resources we need to commit), maybe we should first understand why the
+> > existing features (which have significant effort behind them) are not
+> > resulting in user satisfaction.
+> 
+> More and more reasons to prepare very carefully our offer. All we here
+> appreciate those efforts and there are no way to send them to trash
+> 
+> > Personally I think a poll without educating everyone about what exactly
+> > each choice would mean is useless. We first need to elaborate detailed
+> > alternatives before anyone can make an informed choice.
+> 
+> IMHO, a democracy without education is not democracy, is populism. I agree
+> at all, we need first elaborate a well structured alternatives and then,
+> explicitly after inform and educate our community we can run a poll, or
+> prepare a council, or any other appropriated way.
+> 
+> > backports should be supported for security patches and bug fixes just
+> > like the main packages (if not instead of the main packages).
+> > Of course the security patch could be simply provided by backporting a
+> > newer version of the package, no need to make patches for each version.
+> 
+> That is essential, any upgrade must be supported (other valid reason for an
+> small group of packages).
+
+Note that this can be difficult. For example, if (say) 2010.1 has shipped with 
+samba 3.5.3, and let's say we shipped samba 3.5.5 in backports, now a security 
+update is required, updates provides 3.5.3-1.1mdv with a patch, but 3.5.6 
+doesn't build without substantial work.
+
+Now, in order to provide a rapid update, the maintainer now needs to either:
+-apply the patch to 3.5.5 and ship this to cooker and backports, and later 
+work on 3.5.6 for cooker, and then send it to backports again
+-work on 3.5.6 until it works, and leave users without a security update for a 
+few days
+
+These decisions have quite an impact on the cost of supporting the distro ...
+
+> > What I mean is basically when new updates get presented (which would
+> > include new backports) the user could untick specific packages (as is
+> > possible now) but also have a second tick-box to store the choice
+> > permanently in the skip.list.
+> > This would give the user more choice of which packages he wants to always
+> > update to the newest version and wich ones he/she prefers to keep frozen
+> > at the same version.
+> 
+> Please try to explain that to my grandma, or maybe you could be lucky with
+> some of my students.
+
+How easy this is to use depends on the UI. For example, the updates window 
+could be reduced to be "Apply all recommended updates", "Apply only security 
+updates", and "Advanced", which would show the list of packages to update (and 
+provide options similar to the above, but slightly different). Your grandma 
+shouldn't click the "Advanced" button.
+
+Regards,
+Buchan
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20101015/001225.html b/zarb-ml/mageia-dev/20101015/001225.html new file mode 100644 index 000000000..c35292293 --- /dev/null +++ b/zarb-ml/mageia-dev/20101015/001225.html @@ -0,0 +1,82 @@ + + + + [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc + + + + + + + + + +

[Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Fri Oct 15 13:42:58 CEST 2010 +

+
+ +
2010/10/15 Anssi Hannula <anssi.hannula at iki.fi>:
+>
+> Seems sensible to ask the mirror owners. It is possible some of them have not
+> been aware of the problem at all, so I think we should make sure they
+> understand that Ubuntu, Debian, Arch, etc. also contain patented technologies
+> (to avoid the situation where they are willing to mirror Ubuntu/Debian/Arch
+> but not allow patented software in Mageia, just because the other
+> distributions didn't notify them of the issue; if they don't want to mirror
+> Mageia if it contained patent-encumbered software, they really shouldn't be
+> mirroring those other distributions either).
+
+As mirror maintainer/owner of Mandriva Linux and future Mageia
+(ftp.mandrivauser.de) I discussed this problem with my friends and we
+decided not to mirror PLF although a German university does
+(ftp.gwdg.de). The point is that our mirror is hosted on a private
+server where just one person is liable (me, unfortunately). But we
+also decided to mirror the non-free branch of Mandriva Linux. There is
+non-free and there is patented and/or legally unclear software - we
+will definitely stay away from the latter when mirroring Mageia.
+Making a difference between such software on the parent mirror will
+make it easy for mirrors such as ours. Distributing such software in
+the same branches as "normal" software will make it impossible to
+mirror Mageia.
+
+-- 
+wobo
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20101015/001226.html b/zarb-ml/mageia-dev/20101015/001226.html new file mode 100644 index 000000000..96a9d9598 --- /dev/null +++ b/zarb-ml/mageia-dev/20101015/001226.html @@ -0,0 +1,88 @@ + + + + [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc + + + + + + + + + +

[Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc

+ Tux99 + tux99-mga at uridium.org +
+ Fri Oct 15 16:27:51 CEST 2010 +

+
+ +
On Fri, 15 Oct 2010, Wolfgang Bornath wrote:
+
+> As mirror maintainer/owner of Mandriva Linux and future Mageia
+> (ftp.mandrivauser.de) I discussed this problem with my friends and we
+> decided not to mirror PLF although a German university does
+> (ftp.gwdg.de). The point is that our mirror is hosted on a private
+> server where just one person is liable (me, unfortunately). But we
+> also decided to mirror the non-free branch of Mandriva Linux. There is
+> non-free and there is patented and/or legally unclear software - we
+> will definitely stay away from the latter when mirroring Mageia.
+> Making a difference between such software on the parent mirror will
+> make it easy for mirrors such as ours. Distributing such software in
+> the same branches as "normal" software will make it impossible to
+> mirror Mageia.
+
+wobo, I perfectly understand your reasons especially since as you say 
+the server is privately owned by you, not an association or a company.
+
+OTOH I think your worry is unfounded, the patent issues are mostly US 
+issues, not so much European issues.
+
+Also separating out packages will be very difficult (I would say 
+impossible) since not even lawyers can know for sure which software has 
+patent issues and which one not.
+It's not just a problem with codecs, ANY software could have patent 
+issues (in the US at least).
+
+For example Microsoft is claiming that the Linux kernel is in breach of 
+several patents help by Microsoft.
+
+Do you want to not mirror the kernel?
+
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20101015/001227.html b/zarb-ml/mageia-dev/20101015/001227.html new file mode 100644 index 000000000..ea627da7a --- /dev/null +++ b/zarb-ml/mageia-dev/20101015/001227.html @@ -0,0 +1,92 @@ + + + + [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc + + + + + + + + + +

[Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc

+ Frank Griffin + ftg at roadrunner.com +
+ Fri Oct 15 17:25:57 CEST 2010 +

+
+ +
Tux99 wrote:
+> On Fri, 15 Oct 2010, Wolfgang Bornath wrote:
+>
+>   
+>> As mirror maintainer/owner of Mandriva Linux and future Mageia
+>> (ftp.mandrivauser.de) I discussed this problem with my friends and we
+>> decided not to mirror PLF although a German university does
+>> (ftp.gwdg.de). The point is that our mirror is hosted on a private
+>> server where just one person is liable (me, unfortunately). But we
+>> also decided to mirror the non-free branch of Mandriva Linux. There is
+>> non-free and there is patented and/or legally unclear software - we
+>> will definitely stay away from the latter when mirroring Mageia.
+>> Making a difference between such software on the parent mirror will
+>> make it easy for mirrors such as ours. Distributing such software in
+>> the same branches as "normal" software will make it impossible to
+>> mirror Mageia.
+>>     
+> wobo, I perfectly understand your reasons 
+
+IANAL, but as far as I know U.S. law exempts hosting sites from
+liability for things coming from the outside, provided they take the
+offending material down if the content owner requests it. 
+
+Now, there are some differences between that situation and this one.
+
+For one thing, a mirror maintainer chooses what to mirror.  In the case
+of choosing PLF, whose nature is no secret, I don't think a mirror maint
+could plead ignorance.  On the other hand, this could work for
+repositories that don't explicitly claim to be illegal, provided the
+mirror maint notifies Mageia so that the offending package can be moved
+to another repository if the claim is valid.
+
+For another, this is usually applied to copyrighted content, not
+software, although I seem to remember early requests of this type for
+dvdcss to be taken down.
+
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20101015/001228.html b/zarb-ml/mageia-dev/20101015/001228.html new file mode 100644 index 000000000..ede7914d3 --- /dev/null +++ b/zarb-ml/mageia-dev/20101015/001228.html @@ -0,0 +1,92 @@ + + + + [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc + + + + + + + + + +

[Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc

+ Marc Paré + marc at marcpare.com +
+ Fri Oct 15 21:05:16 CEST 2010 +

+
+ +
Le 2010-10-15 07:42, Wolfgang Bornath a écrit :
+> 2010/10/15 Anssi Hannula<anssi.hannula at iki.fi>:
+>>
+>> Seems sensible to ask the mirror owners. It is possible some of them have not
+>> been aware of the problem at all, so I think we should make sure they
+>> understand that Ubuntu, Debian, Arch, etc. also contain patented technologies
+>> (to avoid the situation where they are willing to mirror Ubuntu/Debian/Arch
+>> but not allow patented software in Mageia, just because the other
+>> distributions didn't notify them of the issue; if they don't want to mirror
+>> Mageia if it contained patent-encumbered software, they really shouldn't be
+>> mirroring those other distributions either).
+>
+> As mirror maintainer/owner of Mandriva Linux and future Mageia
+> (ftp.mandrivauser.de) I discussed this problem with my friends and we
+> decided not to mirror PLF although a German university does
+> (ftp.gwdg.de). The point is that our mirror is hosted on a private
+> server where just one person is liable (me, unfortunately). But we
+> also decided to mirror the non-free branch of Mandriva Linux. There is
+> non-free and there is patented and/or legally unclear software - we
+> will definitely stay away from the latter when mirroring Mageia.
+> Making a difference between such software on the parent mirror will
+> make it easy for mirrors such as ours. Distributing such software in
+> the same branches as "normal" software will make it impossible to
+> mirror Mageia.
+>
+
+Thanks for the post Wobo. You are the first response to this discussion 
+that has shown a "real life / concrete" example of the concern that one 
+has to consider when mirroring packages.
+
+I really think that this thread is leading nowhere and it obviously 
+needs to be discussed with the main devs and Mageia core group along 
+with individuals knowledgeable in international law, if we want to set 
+things straight right from the start.
+
+Marc
+
+
+ + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20101015/author.html b/zarb-ml/mageia-dev/20101015/author.html new file mode 100644 index 000000000..163f69414 --- /dev/null +++ b/zarb-ml/mageia-dev/20101015/author.html @@ -0,0 +1,147 @@ + + + + The Mageia-dev 15 October 2010 Archive by author + + + + + +

15 October 2010 Archives by author

+ +

Starting: Fri Oct 15 01:18:37 CEST 2010
+ Ending: Fri Oct 15 21:05:16 CEST 2010
+ Messages: 20

+

+

+ Last message date: + Fri Oct 15 21:05:16 CEST 2010
+ Archived on: Fri Oct 15 21:05:36 CEST 2010 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/zarb-ml/mageia-dev/20101015/date.html b/zarb-ml/mageia-dev/20101015/date.html new file mode 100644 index 000000000..625add810 --- /dev/null +++ b/zarb-ml/mageia-dev/20101015/date.html @@ -0,0 +1,147 @@ + + + + The Mageia-dev 15 October 2010 Archive by date + + + + + +

15 October 2010 Archives by date

+ +

Starting: Fri Oct 15 01:18:37 CEST 2010
+ Ending: Fri Oct 15 21:05:16 CEST 2010
+ Messages: 20

+

+

+ Last message date: + Fri Oct 15 21:05:16 CEST 2010
+ Archived on: Fri Oct 15 21:05:36 CEST 2010 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/zarb-ml/mageia-dev/20101015/index.html b/zarb-ml/mageia-dev/20101015/index.html new file mode 120000 index 000000000..db4b46f72 --- /dev/null +++ b/zarb-ml/mageia-dev/20101015/index.html @@ -0,0 +1 @@ +thread.html \ No newline at end of file diff --git a/zarb-ml/mageia-dev/20101015/subject.html b/zarb-ml/mageia-dev/20101015/subject.html new file mode 100644 index 000000000..f1bb151a1 --- /dev/null +++ b/zarb-ml/mageia-dev/20101015/subject.html @@ -0,0 +1,147 @@ + + + + The Mageia-dev 15 October 2010 Archive by subject + + + + + +

15 October 2010 Archives by subject

+ +

Starting: Fri Oct 15 01:18:37 CEST 2010
+ Ending: Fri Oct 15 21:05:16 CEST 2010
+ Messages: 20

+

+

+ Last message date: + Fri Oct 15 21:05:16 CEST 2010
+ Archived on: Fri Oct 15 21:05:36 CEST 2010 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/zarb-ml/mageia-dev/20101015/thread.html b/zarb-ml/mageia-dev/20101015/thread.html new file mode 100644 index 000000000..a82696e0a --- /dev/null +++ b/zarb-ml/mageia-dev/20101015/thread.html @@ -0,0 +1,183 @@ + + + + The Mageia-dev 15 October 2010 Archive by thread + + + + + +

15 October 2010 Archives by thread

+ +

Starting: Fri Oct 15 01:18:37 CEST 2010
+ Ending: Fri Oct 15 21:05:16 CEST 2010
+ Messages: 20

+

+

+ Last message date: + Fri Oct 15 21:05:16 CEST 2010
+ Archived on: Fri Oct 15 21:05:36 CEST 2010 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + -- cgit v1.2.1