Re: [Mageia-dev] [RPM] cauldron core/release logrotate-3.8.0-1.mga2
On 4 July 2011 08:25, Mageia Team buildsystem-dae...@mageia.org wrote: Name : logrotate Relocations: (not relocatable) Version : 3.8.0 Vendor: Mageia.Org Release : 1.mga2 Build Date: Mon Jul 4 08:24:04 2011 Install Date: (not installed) Build Host: ecosse Group : File tools Source RPM: (none) Size : 55428 License: GPLv2 Signature : (none) Packager : Mageia Team http://www.mageia.org URL : https://fedorahosted.org/logrotate/ Summary : Rotates, compresses, removes and mails system log files Description : The logrotate utility is designed to simplify the administration of log files on a system which generates a lot of log files. Logrotate allows for the automatic rotation compression, removal and mailing of log files. Logrotate can be set to handle a log file daily, weekly, monthly or when the log file gets to a certain size. Normally, logrotate runs as a daily cron job. Install the logrotate package if you need a utility to deal with the log files on your system. ahmad ahmad 3.8.0-1.mga2: + Revision: 117993 - Update to 3.8.0, fixes: CVE-2011-1098 CVE-2011-1154 CVE-2011-1155 - Drop patch0, fixed upstream - Add BR acl-devel and compile with WITH_ACL - Put 'make test' in a %check section FWIW, I couldn't extract the commits from upstream SVN[1] that fixed those three CVE's (the upstream svn log isn't that clear to me..), so I can't backport the fixes to mga1. [1] http://svn.fedorahosted.org/svn/logrotate/ -- Ahmad Samir
Re: [Mageia-dev] [RPM] cauldron core/release logrotate-3.8.0-1.mga2
On Wed, 06 Jul 2011, Ahmad Samir wrote: On 4 July 2011 08:25, Mageia Team buildsystem-dae...@mageia.org wrote: Name : logrotate Relocations: (not relocatable) Version : 3.8.0 Vendor: Mageia.Org Release : 1.mga2 Build Date: Mon Jul 4 08:24:04 2011 Install Date: (not installed) Build Host: ecosse Group : File tools Source RPM: (none) Size : 55428 License: GPLv2 Signature : (none) Packager : Mageia Team http://www.mageia.org URL : https://fedorahosted.org/logrotate/ Summary : Rotates, compresses, removes and mails system log files Description : The logrotate utility is designed to simplify the administration of log files on a system which generates a lot of log files. Logrotate allows for the automatic rotation compression, removal and mailing of log files. Logrotate can be set to handle a log file daily, weekly, monthly or when the log file gets to a certain size. Normally, logrotate runs as a daily cron job. Install the logrotate package if you need a utility to deal with the log files on your system. ahmad ahmad 3.8.0-1.mga2: + Revision: 117993 - Update to 3.8.0, fixes: CVE-2011-1098 CVE-2011-1154 CVE-2011-1155 - Drop patch0, fixed upstream - Add BR acl-devel and compile with WITH_ACL - Put 'make test' in a %check section FWIW, I couldn't extract the commits from upstream SVN[1] that fixed those three CVE's (the upstream svn log isn't that clear to me..), so I can't backport the fixes to mga1. There are patchs on redhat bugzilla. CVE-2011-1098: https://bugzilla.redhat.com/show_bug.cgi?id=680798 CVE-2011-1154: https://bugzilla.redhat.com/show_bug.cgi?id=680796 CVE-2011-1155: https://bugzilla.redhat.com/show_bug.cgi?id=680797
[Mageia-dev] xcb-util update, which broke the BS
I updated xcb-util and stupidly obsoleted the old libs (which have been merged in the one lib), this broke the BS. First thing to do is rebuild startup-notification, but it fails, and I don't see why http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20110706093849.ahmad.valstar.8189/log/startup-notification-0.12-2.mga2/install_deps-1.0.20110706093902.log lib64xcb-util0[== 0.3.8-1.mga2] should be available already from xcb-utils-0.3.8... so help! -- Ahmad Samir
Re: [Mageia-dev] [RPM] cauldron core/release logrotate-3.8.0-1.mga2
On 6 July 2011 11:29, nicolas vigier bo...@mars-attacks.org wrote: On Wed, 06 Jul 2011, Ahmad Samir wrote: On 4 July 2011 08:25, Mageia Team buildsystem-dae...@mageia.org wrote: Name : logrotate Relocations: (not relocatable) Version : 3.8.0 Vendor: Mageia.Org Release : 1.mga2 Build Date: Mon Jul 4 08:24:04 2011 Install Date: (not installed) Build Host: ecosse Group : File tools Source RPM: (none) Size : 55428 License: GPLv2 Signature : (none) Packager : Mageia Team http://www.mageia.org URL : https://fedorahosted.org/logrotate/ Summary : Rotates, compresses, removes and mails system log files Description : The logrotate utility is designed to simplify the administration of log files on a system which generates a lot of log files. Logrotate allows for the automatic rotation compression, removal and mailing of log files. Logrotate can be set to handle a log file daily, weekly, monthly or when the log file gets to a certain size. Normally, logrotate runs as a daily cron job. Install the logrotate package if you need a utility to deal with the log files on your system. ahmad ahmad 3.8.0-1.mga2: + Revision: 117993 - Update to 3.8.0, fixes: CVE-2011-1098 CVE-2011-1154 CVE-2011-1155 - Drop patch0, fixed upstream - Add BR acl-devel and compile with WITH_ACL - Put 'make test' in a %check section FWIW, I couldn't extract the commits from upstream SVN[1] that fixed those three CVE's (the upstream svn log isn't that clear to me..), so I can't backport the fixes to mga1. There are patchs on redhat bugzilla. CVE-2011-1098: https://bugzilla.redhat.com/show_bug.cgi?id=680798 CVE-2011-1154: https://bugzilla.redhat.com/show_bug.cgi?id=680796 CVE-2011-1155: https://bugzilla.redhat.com/show_bug.cgi?id=680797 OK, thanks. -- Ahmad Samir
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
Am 17.03.2011 09:14, schrieb Samuel Verschelde: Le mardi 15 mars 2011 21:30:05, Michael Scherer a écrit : Le mardi 15 mars 2011 à 20:34 +0100, Tux99 a écrit : Quote: Michael Scherer wrote on Tue, 15 March 2011 20:21 Because some people do not care about patents and using tainted stuff, but do care about free licenses and do care about what it bring to them. I do. Stormi do ( or seems to do ). And I think that given we decided to split PLF for that precise reason, there is more than 2 of us to care. Putting tainted packages in nonfree just causes more confusion IMHO. As much as the reverse, it all depends on what you tell to people about the repository, what they expect and what you prefer to highlight. That's exactly why I suggested earlier in this thread that we need an additional repo for 'tainted+non-free' packages, that's the only solution that would satisfy every preference people might have and at the same time make things clear for everyone (packagers, mirror maintainers, users). Instead of moving stuff in non-free, you move them in non-free + tainted. That just bring more headaches, and more complexity. That's not a solution. Well, that would be a real solution if we really wanted to flag those packages both as tainted and as non-free, as some people give more importance to the fact that it is tainted and others to the fact that it is non-free. For now, I would propose either to put that package in non-free, explain to users that non-free packages may be tainted too, and envision after Mageia 1 to add a new media if the current solution really doesn't work, and maybe require a meta-package from tainted OR put it in tainted, explain that tainted can contain non-free packages, and require a dummy package from non- free, as Anssi proposed (on a second thought, I think that second option is better). Can we reach a decision ? (add this question to the next packagers meeting ?) *bump* As there was no decision reached, not even a concensus, how do we proceed now? As there is the next package (HandBrake) which also falls under both categories, tainted and non-free. The option of moving such packages to non-free, and requiring a package from tainted (or vice-versa) which explains shortly via a README.urpmi about the problem, and to enable the missing repo, sounds not that bad. (If you really want to go that far.) Regards
Re: [Mageia-dev] xcb-util update, which broke the BS
The problem is libxcb is obsoleting libxcb-util0: $ rpm -qp --obsoletes libxcb-dpms0-1.7-1.mga1.i586.rpm libxcb-util0 libxcb-util1 2011/7/6 Ahmad Samir ahmadsamir3...@gmail.com: I updated xcb-util and stupidly obsoleted the old libs (which have been merged in the one lib), this broke the BS. First thing to do is rebuild startup-notification, but it fails, and I don't see why http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20110706093849.ahmad.valstar.8189/log/startup-notification-0.12-2.mga2/install_deps-1.0.20110706093902.log lib64xcb-util0[== 0.3.8-1.mga2] should be available already from xcb-utils-0.3.8... so help! -- Ahmad Samir
Re: [Mageia-dev] xcb-util update, which broke the BS
On 6 July 2011 12:04, Ahmad Samir ahmadsamir3...@gmail.com wrote: On 6 July 2011 12:00, Funda Wang fundaw...@gmail.com wrote: The problem is libxcb is obsoleting libxcb-util0: $ rpm -qp --obsoletes libxcb-dpms0-1.7-1.mga1.i586.rpm libxcb-util0 libxcb-util1 So we need to bump the Epoch in xcb-util? Or remove the old obsoletes from libxcb. I think removing the old obsoletes is better. -- Ahmad Samir
Re: [Mageia-dev] xcb-util update, which broke the BS
2011/7/6 Ahmad Samir ahmadsamir3...@gmail.com: On 6 July 2011 12:00, Funda Wang fundaw...@gmail.com wrote: The problem is libxcb is obsoleting libxcb-util0: $ rpm -qp --obsoletes libxcb-dpms0-1.7-1.mga1.i586.rpm libxcb-util0 libxcb-util1 So we need to bump the Epoch in xcb-util? No, we need to drop libxcb's obsoletes at first. I guess will need to add some conflicts in libxcb-util so that it will upgrade libxcb at first when upgrading from previous distros. 2011/7/6 Ahmad Samir ahmadsamir3...@gmail.com: I updated xcb-util and stupidly obsoleted the old libs (which have been merged in the one lib), this broke the BS. First thing to do is rebuild startup-notification, but it fails, and I don't see why http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20110706093849.ahmad.valstar.8189/log/startup-notification-0.12-2.mga2/install_deps-1.0.20110706093902.log lib64xcb-util0[== 0.3.8-1.mga2] should be available already from xcb-utils-0.3.8... so help! -- Ahmad Samir -- Ahmad Samir
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
If we go back to the beginning of the discussion where to put such packages which were in PLF we made a clear difference: 1. All non-free goes into non-free 2. Software which may be illegal in some countries (mostly because of licensing) will go into tainted. That's all. Clear and simple. The question about GPL or other free licenses is not touched by tainted. So, everything which does not have to go to tainted will go to free (core) or non-free, depending on it's status. -- wobo
Re: [Mageia-dev] xcb-util update, which broke the BS
On 6 July 2011 12:08, Funda Wang fundaw...@gmail.com wrote: 2011/7/6 Ahmad Samir ahmadsamir3...@gmail.com: On 6 July 2011 12:00, Funda Wang fundaw...@gmail.com wrote: The problem is libxcb is obsoleting libxcb-util0: $ rpm -qp --obsoletes libxcb-dpms0-1.7-1.mga1.i586.rpm libxcb-util0 libxcb-util1 So we need to bump the Epoch in xcb-util? No, we need to drop libxcb's obsoletes at first. I guess will need to add some conflicts in libxcb-util so that it will upgrade libxcb at first when upgrading from previous distros. Yes, (you probably missed my previous email), anyway, we may needn't add the obsoletes back, it was added 2years+ ago http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages?view=revisionrevision=383043 I'll try and check more thoroughly though. Thanks a bunch for the fix. 2011/7/6 Ahmad Samir ahmadsamir3...@gmail.com: I updated xcb-util and stupidly obsoleted the old libs (which have been merged in the one lib), this broke the BS. First thing to do is rebuild startup-notification, but it fails, and I don't see why http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20110706093849.ahmad.valstar.8189/log/startup-notification-0.12-2.mga2/install_deps-1.0.20110706093902.log lib64xcb-util0[== 0.3.8-1.mga2] should be available already from xcb-utils-0.3.8... so help! -- Ahmad Samir -- Ahmad Samir -- Ahmad Samir
Re: [Mageia-dev] ksnapshot conflicts with kdegraphics4-devel
2011/7/5 Radu-Cristian FOTESCU beranger...@yahoo.ca: fwang, mikala, # urpmi kdegraphics4-devel The following package has to be removed for others to be upgraded: ksnapshot-4.6.90-1.mga2.i586 (due to conflicts with kdegraphics4-devel[= 2:4.6.90]) (y/N) The conflicts against kdegraphics4-devel was added because somes files were wrongly available in the « old » -devel package especially the -devel package was not expected to live again . Or, the other way around: # urmpi ksnapshot The following package has to be removed for others to be upgraded: kdegraphics4-devel-4.6.90-1.mga2.noarch (due to conflicts with ksnapshot-4.6.90-1.mga2.i586) (y/N) I admit I don't understand the new KDE 4.7 package fragmentation (why must they always change something upstream? I'm sick of this), but is this normal? I guess not. ksnapshot can coexist with kdegraphics4, but not with kdegraphics4-devel. In fact kdegraphics4-devel should not exist anymore, i'll remove it from the kdegraphics4 meta package. You should directly install the -devel package you need to build your package from libksane-devel , libkipi-devel, libkexiv2-devel or libkdcraw-devel Fwang i can understand that you want to keep an empty metapackage (even if i'm personnaly not agree as said earlier) for kdegraphics, but why adding a -devel metapackage here j ? I also noticed you did the same things for kdeedu so i'll remove it too. -- Balcaen John Jabber-id: mik...@jabber.littleboboy.net
Re: [Mageia-dev] ksnapshot conflicts with kdegraphics4-devel
2011/7/6 John Balcaen mik...@mageia.org: Fwang i can understand that you want to keep an empty metapackage (even if i'm personnaly not agree as said earlier) for kdegraphics, but why adding a -devel metapackage here j ? I also noticed you did the same things for kdeedu so i'll remove it too. Then please rebuild the relevant packages before doing this. And, obsoletes are not the correct place for solve such problems. -- Balcaen John Jabber-id: mik...@jabber.littleboboy.net
Re: [Mageia-dev] ksnapshot conflicts with kdegraphics4-devel
On Wednesday 06 July 2011 18:28:27 Funda Wang wrote: 2011/7/6 John Balcaen mik...@mageia.org: Fwang i can understand that you want to keep an empty metapackage (even if i'm personnaly not agree as said earlier) for kdegraphics, but why adding a -devel metapackage here j ? I also noticed you did the same things for kdeedu so i'll remove it too. Then please rebuild the relevant packages before doing this. It was expected but you suddenly start to change things. And, obsoletes are not the correct place for solve such problems. ksnapshot don't have any obsoletes but a conflict (which is probably indeed too much but was not expected to add any problem if you were not pushing again the -devel package) Regarding others obsoletes i put them in a specific library (for each project kdegraphics4 kdeeedu4) because i wanted to drop them from BS too in the same way but you removed them on the same movement when you pushed by the -devel package. -- Balcaen John Jabber ID: mik...@jabber.littleboboy.net
Re: [Mageia-dev] ksnapshot conflicts with kdegraphics4-devel
obsoletes are not the correct place for solve such problems. ksnapshot don't have any obsoletes but a conflict (which is probably indeed too much but was not expected to add any problem i Sorry to bother you, but since this is both about an upgrade and a change of package names (albeit via a fragmentation/split), why isn't Obsoletes a better choice? If I am not very wrong, technically Conflicts will cause the install/upgrade to fail and therefore forbids an installation/upgrade. Which is both annoying and it requires a multiple-step action from the end-user's part. In contrast, Obsoletes forces an upgrade to the new packages names, automatically removing the old packages. While in principle Obsoletes doesn't prevent the end-user from reinstalling the old package(s), this is not desired anyway. I mean, it's not like kdesomething-4.6.4 and kdesomesplitpackage-4.6.90 would coexist on the same machine -- it's either you upgraded from KDE 4.6.4 to 4.6.90, or you didn't. So I suppose you say Obsoletes is not the right thing to do _as a principle_ (as a principle, GOTO is considered harmful too), but why is it unsuitable for this very case of an evolving (cauldron) repository in a situation of a kinky upgrade? Of course, I am still waiting for a mentor, so I might be very, very wrong in my understanding of Conflicts vs Obsoletes. What I believe I know is that Obsoletes makes things transparent for the end-user, whereas Conflicts looks like an error... R-C aka beranger
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
Am 06.07.2011 12:10, schrieb Wolfgang Bornath: If we go back to the beginning of the discussion where to put such packages which were in PLF we made a clear difference: 1. All non-free goes into non-free 2. Software which may be illegal in some countries (mostly because of licensing) will go into tainted. That's all. Clear and simple. Doesn't seem so. If even Anssi asks me where this package should go, maybe this is not clear to everybody. Also if you reread this thread, there is no concesus here. Also regarding Ahmads answer. But if you tell me that is the status quo, and the others also say so, my question is anwered, and HandBrake should go to tainted.
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
On 6 July 2011 13:40, Florian Hubold doktor5...@arcor.de wrote: Am 06.07.2011 12:10, schrieb Wolfgang Bornath: If we go back to the beginning of the discussion where to put such packages which were in PLF we made a clear difference: 1. All non-free goes into non-free 2. Software which may be illegal in some countries (mostly because of licensing) will go into tainted. That's all. Clear and simple. Doesn't seem so. If even Anssi asks me where this package should go, maybe this is not clear to everybody. Also if you reread this thread, there is no concesus here. Also regarding Ahmads answer. But if you tell me that is the status quo, and the others also say so, my question is anwered, and HandBrake should go to tainted. If HandBrake has a bundled faac, then it shouldn't go anywhere in the official Mageia repos, unless the bundles faac is disabled IIUC. -- Ahmad Samir
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
On Wed, Jul 6, 2011 at 12:10, Wolfgang Bornath molc...@googlemail.com wrote: If we go back to the beginning of the discussion where to put such packages which were in PLF we made a clear difference: 1. All non-free goes into non-free 2. Software which may be illegal in some countries (mostly because of licensing) will go into tainted. That's all. Clear and simple. The question about GPL or other free licenses is not touched by tainted. So, everything which does not have to go to tainted will go to free (core) or non-free, depending on it's status. Indeed. http://mageia.org/wiki/doku.php?id=licensing_policy#acceptable_licenses says: The tainted section accepts software under a license that is might be free or open source and which cannot be redistributed publicly in certain areas in the world, or due to patents issues. Reformulating it in an other, more explicit way maybe: - core hosts 100% free software that can be redistributed anywhere (or almost, the world is a bit more complicated than that) - nonfree hosts non-free software that can be redistributed anywhere (same) - tainted hosts all the rest, be it free software or not. Romain
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
On 6 July 2011 13:58, Romain d'Alverny rdalve...@gmail.com wrote: On Wed, Jul 6, 2011 at 12:10, Wolfgang Bornath molc...@googlemail.com wrote: If we go back to the beginning of the discussion where to put such packages which were in PLF we made a clear difference: 1. All non-free goes into non-free 2. Software which may be illegal in some countries (mostly because of licensing) will go into tainted. That's all. Clear and simple. The question about GPL or other free licenses is not touched by tainted. So, everything which does not have to go to tainted will go to free (core) or non-free, depending on it's status. Indeed. http://mageia.org/wiki/doku.php?id=licensing_policy#acceptable_licenses says: The tainted section accepts software under a license that is might be free or open source and which cannot be redistributed publicly in certain areas in the world, or due to patents issues. Reformulating it in an other, more explicit way maybe: - core hosts 100% free software that can be redistributed anywhere (or almost, the world is a bit more complicated than that) - nonfree hosts non-free software that can be redistributed anywhere (same) - tainted hosts all the rest, be it free software or not. Third point is wrong, a license that is might be free or open source, which, I think, means only software with an open source software License. Although the wording should be clearer / more precise. Romain -- Ahmad Samir
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
Am 06.07.2011 14:04, schrieb Ahmad Samir: On 6 July 2011 13:58, Romain d'Alvernyrdalve...@gmail.com wrote: On Wed, Jul 6, 2011 at 12:10, Wolfgang Bornathmolc...@googlemail.com wrote: If we go back to the beginning of the discussion where to put such packages which were in PLF we made a clear difference: 1. All non-free goes into non-free 2. Software which may be illegal in some countries (mostly because of licensing) will go into tainted. That's all. Clear and simple. The question about GPL or other free licenses is not touched by tainted. So, everything which does not have to go to tainted will go to free (core) or non-free, depending on it's status. Indeed. http://mageia.org/wiki/doku.php?id=licensing_policy#acceptable_licenses says: The tainted section accepts software under a license that is might be free or open source and which cannot be redistributed publicly in certain areas in the world, or due to patents issues. Reformulating it in an other, more explicit way maybe: - core hosts 100% free software that can be redistributed anywhere (or almost, the world is a bit more complicated than that) - nonfree hosts non-free software that can be redistributed anywhere (same) - tainted hosts all the rest, be it free software or not. Third point is wrong, a license that is might be free or open source, which, I think, means only software with an open source software License. Although the wording should be clearer / more precise. The reason why we have tainted is, that there are patents, which restrain some user to use this software. So, it's a question of legality, which should get the higher priority. The differentiation if it's free or not-free is only a question of ideology. Therefore, for me the situation is very simple. If there are questionable patents for a software, we have to put it in tainted (otherwise we destroy the whole idea of core/non-free/tainted). There is no other option. We may can think about a tainted-free and tainted-nonfree (like PLF) but IMHO it's not needed and as long as we don't have such a repo, all tainted packages have to be put into tainted (no matter what license they use). Regards, Thorsten
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
On Wed, Jul 6, 2011 at 14:04, Ahmad Samir ahmadsamir3...@gmail.com wrote: On 6 July 2011 13:58, Romain d'Alverny rdalve...@gmail.com wrote: On Wed, Jul 6, 2011 at 12:10, Wolfgang Bornath molc...@googlemail.com wrote: If we go back to the beginning of the discussion where to put such packages which were in PLF we made a clear difference: 1. All non-free goes into non-free 2. Software which may be illegal in some countries (mostly because of licensing) will go into tainted. That's all. Clear and simple. The question about GPL or other free licenses is not touched by tainted. So, everything which does not have to go to tainted will go to free (core) or non-free, depending on it's status. Indeed. http://mageia.org/wiki/doku.php?id=licensing_policy#acceptable_licenses says: The tainted section accepts software under a license that is might be free or open source and which cannot be redistributed publicly in certain areas in the world, or due to patents issues. Reformulating it in an other, more explicit way maybe: - core hosts 100% free software that can be redistributed anywhere (or almost, the world is a bit more complicated than that) - nonfree hosts non-free software that can be redistributed anywhere (same) - tainted hosts all the rest, be it free software or not. Third point is wrong, a license that is might be free or open source, which, I think, means only software with an open source software License. I understand this as: software that might be free or open source = can be not free or open source. might expressed the possibility, not the requirement. IOW, tainted does not discriminate free and non free software. Although the wording should be clearer / more precise. Indeed. Romain
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
On 06/07/11 12:58, Romain d'Alverny wrote: On Wed, Jul 6, 2011 at 12:10, Wolfgang Bornathmolc...@googlemail.com wrote: If we go back to the beginning of the discussion where to put such packages which were in PLF we made a clear difference: 1. All non-free goes into non-free 2. Software which may be illegal in some countries (mostly because of licensing) will go into tainted. That's all. Clear and simple. The question about GPL or other free licenses is not touched by tainted. So, everything which does not have to go to tainted will go to free (core) or non-free, depending on it's status. Indeed. http://mageia.org/wiki/doku.php?id=licensing_policy#acceptable_licenses says: The tainted section accepts software under a license that is might be free or open source and which cannot be redistributed publicly in certain areas in the world, or due to patents issues. Reformulating it in an other, more explicit way maybe: - core hosts 100% free software that can be redistributed anywhere (or almost, the world is a bit more complicated than that) - nonfree hosts non-free software that can be redistributed anywhere (same) - tainted hosts all the rest, be it free software or not. I don't think that the last line is entirely consistent with what I understood was Mageia's commitment to provide a free distro for those users who want it. Such a user would have to investigate whether or not a tainted package was free or nonfree, or not use the tainted repo at all. Jim
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
On Wed, 06 Jul 2011, Thorsten van Lil wrote: The reason why we have tainted is, that there are patents, which restrain some user to use this software. So, it's a question of legality, which should get the higher priority. The differentiation if it's free or not-free is only a question of ideology. Therefore, for me the situation is very simple. If there are questionable patents for a software, we have to put it in tainted (otherwise we destroy the whole idea of core/non-free/tainted). There is no other option. We may There is other options. It would also be possible to not include nonfree patented software anywhere.
Re: [Mageia-dev] gstreamer packaging too split?
'Twas brillig, and Ahmad Samir at 05/07/11 10:50 did gyre and gimble:
I see packages like gstreamer0.10-soup installed as separate packages.
Is there any real gain from this split? Other than pulling in other
libraries etc, as it just causes potential problems for some packages
that do not require it. e.g. totem and rhythmbox both reqire the -soup
package but phonon-gstreamer does not (it should).
But really, should this library just be bundled into the main -good
package?
I agree about merging -soup, without it gst-based apps can't seem to
play online streams, this is a basic functionality, I guess.
Ditto for other overly split things, like the pulse plugin,
and the neon plugin in -bad
I dunno about pulse, it would pull pulseaudio on users' systems (I
know it's installed by default, but some do a minimal install and
don't install pulse, even if the some of pulse libs are too dug deep
down the whole stack :)).
Hmmm, gstreamer0.10-pulse requires pulseaudio = 0.9.7. Interesting.
I'm not sure why (it could easily be installed on a system that does not
have a PA daemon and operates as a thin client.
Wonder if we should just drop that require and then the gst-pulse plugin
only really requires libpulse which a *lot* of other things need anyway,
and thus no additional stuff pulled in. WDYT?
Has anyone sad down and thought about it a bit recently (here or in Mdv?)
(I have to admit, I didn't sit down and think about it before). Here goes:
===
-good:
$ urpmf --sourcerpm gstreamer0.10-plugins-good | awk -F: '{print $1}'
gstreamer0.10-caca
gstreamer0.10-raw1394
gstreamer0.10-soup
gstreamer0.10-plugins-good
gstreamer0.10-dv
gstreamer0.10-wavpack
gstreamer0.10-pulse
gstreamer0.10-jack
gstreamer0.10-speex
gstreamer0.10-aalib
gstreamer0.10-flac
I think these can be merged in addition to -soup:
-flac, an open format, expected to work o-o-t-b, IMHO
-jack, doesn't matter really, it won't pull any more requires as
libjack.so.0 is deep in the stack anyway (just tested with urpme
--test and it wanted to yank 174 packages).
As for the rest I am not sure, e.g. I've never used -wavpack, so I
think they can remain split.
Perhaps, but I'm just not convinced of the value of a split generally.
Sure you could argue that pulling in an extra lib here and there can
count for a lot of disk space, but then we end up with various problems
for other packages (like the soup issue - although granted, one as
obvious as that will likely not crop up with the more subtle extras -
until some user plugs in their dv video camera.. :p)
=
-ugly looks OK to me.
$ urpmf --sourcerpm gstreamer0.10-plugins-ugly | awk -F: '{print $1}'
gstreamer0.10-sid
gstreamer0.10-twolame
gstreamer0.10-a52dec
gstreamer0.10-cdio
gstreamer0.10-plugins-ugly
gstreamer0.10-mpeg
Though merging -a52dec looks like a good idea given how widely used
the AC-3 codec is.
==
I left the bad for last, they look OK too, each sub-package
pulls/requires a different lib (e.g. rtmp - librtmp.so.0), I guess
that's a good splitting criteria; I've never used -neon so I'll take
your word for it :)
$ urpmf --sourcerpm gstreamer0.10-plugins-bad | awk -F: '{print $1}' |
grep -v lib
gstreamer0.10-rtmp
gstreamer0.10-nas
gstreamer0.10-rsvg
gstreamer0.10-soundtouch
gstreamer0.10-musepack
gstreamer0.10-gsm
gstreamer0.10-resindvd
gstreamer0.10-kate
gstreamer0.10-neon
gstreamer0.10-voip
gstreamer0.10-jp2k
gstreamer0.10-ladspa
gstreamer0.10-plugins-bad-doc
gstreamer0.10-plugins-bad
gstreamer0.10-celt
gstreamer0.10-schroedinger
gstreamer0.10-mms
gstreamer0.10-dc1394
gstreamer0.10-directfb
gstreamer0.10-dirac
gstreamer0.10-ofa
gstreamer0.10-wildmidi
gstreamer0.10-gme
gstreamer0.10-vdpau
gstreamer0.10-mpeg2enc
gstreamer0.10-vp8
gstreamer0.10-cog
gstreamer0.10-curl
(A bit off-topic, I think -nas should be deprecated, NAS doesn't seem
that used lately?).
Yeah it is a bit of a grab-bag of stuff, but again, should we still just
bundle everything together anyway and sod the extra disk space needed?
It would be a lot simpler for users (oh you need $foo? sure, just
installed -ugly/-bad) which is advise they can get direct from upstream
without having to know our particular packaging quirks.
As someone who does upstream support for other projects, it's a pain to
put caveats in all your advice for distros you don't know.
That said, the trade off may be too much, hence the canvassing of
opinions here :)
Col
--
Colin Guthrie
mageia(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mageia Contributor [http://www.mageia.org/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
On 6 July 2011 14:27, Romain d'Alverny rdalve...@gmail.com wrote: On Wed, Jul 6, 2011 at 14:04, Ahmad Samir ahmadsamir3...@gmail.com wrote: On 6 July 2011 13:58, Romain d'Alverny rdalve...@gmail.com wrote: On Wed, Jul 6, 2011 at 12:10, Wolfgang Bornath molc...@googlemail.com wrote: If we go back to the beginning of the discussion where to put such packages which were in PLF we made a clear difference: 1. All non-free goes into non-free 2. Software which may be illegal in some countries (mostly because of licensing) will go into tainted. That's all. Clear and simple. The question about GPL or other free licenses is not touched by tainted. So, everything which does not have to go to tainted will go to free (core) or non-free, depending on it's status. Indeed. http://mageia.org/wiki/doku.php?id=licensing_policy#acceptable_licenses says: The tainted section accepts software under a license that is might be free or open source and which cannot be redistributed publicly in certain areas in the world, or due to patents issues. Reformulating it in an other, more explicit way maybe: - core hosts 100% free software that can be redistributed anywhere (or almost, the world is a bit more complicated than that) - nonfree hosts non-free software that can be redistributed anywhere (same) - tainted hosts all the rest, be it free software or not. Third point is wrong, a license that is might be free or open source, which, I think, means only software with an open source software License. I understand this as: software that might be free or open source = can be not free or open source. might expressed the possibility, not the requirement. IOW, tainted does not discriminate free and non free software. It does differentiate; given that Anssi is the one who worked on the tainted policy the most, and he doesn't think faac should be in tainted, is enough to say that the wording in the wiki needs to express our stance on the issue in a clearer way... Although the wording should be clearer / more precise. Indeed. Romain -- Ahmad Samir
[Mageia-dev] Looking for victim^w^wvolunteer for Texlive package
Hi there Here is an interesting topic :).Texlive is one of the biggest package we have for now. Of course split is needed but we postponed it after Mageia 1 to have a look on it. Now here we go! It needs first to have a look on the way we want to split it, Fedora one (zillions of sub-packages) or our own one based on the wau different components are used. Comments, proposals welcome -- Anne http://www.mageia.org
Re: [Mageia-dev] Looking for victim^w^wvolunteer for Texlive package
在 Wed, 06 Jul 2011 21:09:30 +0800, Anne nicolas enn...@mageia.org寫道: Hi there Here is an interesting topic :).Texlive is one of the biggest package we have for now. Of course split is needed but we postponed it after Mageia 1 to have a look on it. Now here we go! It needs first to have a look on the way we want to split it, Fedora one (zillions of sub-packages) or our own one based on the wau different components are used. Comments, proposals welcome First: Which version? Texlive 2007 or later ones build on luaTex? I have heard that after 2008, building texlive is almost impossible
Re: [Mageia-dev] gstreamer packaging too split?
On 6 July 2011 15:09, Christiaan Welvaart c...@daneel.dyndns.org wrote: On Wed, 6 Jul 2011, Colin Guthrie wrote: Yeah it is a bit of a grab-bag of stuff, but again, should we still just bundle everything together anyway and sod the extra disk space needed? It would be a lot simpler for users (oh you need $foo? sure, just installed -ugly/-bad) which is advise they can get direct from upstream without having to know our particular packaging quirks. As someone who does upstream support for other projects, it's a pain to put caveats in all your advice for distros you don't know. That said, the trade off may be too much, hence the canvassing of opinions here :) I think there are only 2 solutions: - Add a meta package, e.g. gstreamer-codecs-all that can be used to make sure all available codecs are installed. Some people complain about bad and ugly so using those names more is not a good idea. But that's how upstream calls them, hiding them won't work, since they're too popular already. FWIW, there's gstreamer0.10-decoders, a meta package in mdv (not imported yet in Mageia). - Use the packagekit gstreamer plugin, so players install the correct plugins on demand. ATM it doesn't work, the urpmi backend needs some love.. Christiaan -- Ahmad Samir
[Mageia-dev] Tonight's meeting
Hi there Here are the topics for tonight's meeting at 19h UTC on #mageia-dev - release cycle, backports policies - starting implementing specifications for Mageia2 - review of mentoring (andre555) - review of secteam (stewb) - support of Mageia 1 Cheers -- Anne http://www.mageia.org
Re: [Mageia-dev] Looking for victim^w^wvolunteer for Texlive package
On Wed, 6 Jul 2011, Kira wrote: 在 Wed, 06 Jul 2011 21:09:30 +0800, Anne nicolas enn...@mageia.org寫道: Hi there Here is an interesting topic :).Texlive is one of the biggest package we have for now. Of course split is needed but we postponed it after Mageia 1 to have a look on it. Now here we go! It needs first to have a look on the way we want to split it, Fedora one (zillions of sub-packages) or our own one based on the wau different components are used. Comments, proposals welcome First: Which version? Texlive 2007 or later ones build on luaTex? I have heard that after 2008, building texlive is almost impossible Texlive 2010 is already available in mageia, so I believe this is about improving the existing package(s). That consists mostly of splitting up texlive-texmf(?), but maybe also adding a dependency on a minimal set of fonts to texlive. Currently the texmf subpackage can be removed while most of the programs in the texlive package are probably useless without fonts. Christiaan
Re: [Mageia-dev] Looking for victim^w^wvolunteer for Texlive package
2011/7/6 Christiaan Welvaart c...@daneel.dyndns.org: On Wed, 6 Jul 2011, Kira wrote: 在 Wed, 06 Jul 2011 21:09:30 +0800, Anne nicolas enn...@mageia.org寫道: Hi there Here is an interesting topic :).Texlive is one of the biggest package we have for now. Of course split is needed but we postponed it after Mageia 1 to have a look on it. Now here we go! It needs first to have a look on the way we want to split it, Fedora one (zillions of sub-packages) or our own one based on the wau different components are used. Comments, proposals welcome First: Which version? Texlive 2007 or later ones build on luaTex? I have heard that after 2008, building texlive is almost impossible Texlive 2010 is already available in mageia, so I believe this is about improving the existing package(s). That consists mostly of splitting up texlive-texmf(?), but maybe also adding a dependency on a minimal set of fonts to texlive. Currently the texmf subpackage can be removed while most of the programs in the texlive package are probably useless without fonts. Indeed. Package is for now much too monolitic which does not help to reduce size of some installs. Christiaan -- Anne http://www.mageia.org
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
On Wed, Jul 6, 2011 at 15:04, Ahmad Samir ahmadsamir3...@gmail.com wrote: On 6 July 2011 14:27, Romain d'Alverny rdalve...@gmail.com wrote: I understand this as: software that might be free or open source = can be not free or open source. might expressed the possibility, not the requirement. IOW, tainted does not discriminate free and non free software. It does differentiate; given that Anssi is the one who worked on the tainted policy the most, and he doesn't think faac should be in tainted, is enough to say that the wording in the wiki needs to express our stance on the issue in a clearer way... Ok, fine then, fix this in the definition on the wiki. But make sure to explicit what becomes of software that is non free and questionable regarding patents (id est, it goes nowhere), so that the layout is clearer (here with a changed triage): - core: 100% free software - tainted: 100% free software, but locally subject to software patents or local legal terms - nonfree: non-free software - nowhere, we don't package/distribute this: non-free software, for which we may still have the source code or binaries, and a license to redistribute from author but patent law or other local provision may prevent to redistribute it anyway. (I am not taking sides here, just re-explaining your understanding) Romain
Re: [Mageia-dev] Tonight's meeting
Le mercredi 6 juillet 2011 15:30:30, Anne nicolas a écrit : Hi there Here are the topics for tonight's meeting at 19h UTC on #mageia-dev - release cycle, backports policies - starting implementing specifications for Mageia2 - review of mentoring (andre555) - review of secteam (stewb) - support of Mageia 1 Cheers I wont be able to attend this meeting which promises to be very interesting. Best regards Samuel
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
2011/7/6 Ahmad Samir ahmadsamir3...@gmail.com: On 6 July 2011 14:27, Romain d'Alverny rdalve...@gmail.com wrote: On Wed, Jul 6, 2011 at 14:04, Ahmad Samir ahmadsamir3...@gmail.com wrote: On 6 July 2011 13:58, Romain d'Alverny rdalve...@gmail.com wrote: On Wed, Jul 6, 2011 at 12:10, Wolfgang Bornath molc...@googlemail.com wrote: If we go back to the beginning of the discussion where to put such packages which were in PLF we made a clear difference: 1. All non-free goes into non-free 2. Software which may be illegal in some countries (mostly because of licensing) will go into tainted. That's all. Clear and simple. The question about GPL or other free licenses is not touched by tainted. So, everything which does not have to go to tainted will go to free (core) or non-free, depending on it's status. Indeed. http://mageia.org/wiki/doku.php?id=licensing_policy#acceptable_licenses says: The tainted section accepts software under a license that is might be free or open source and which cannot be redistributed publicly in certain areas in the world, or due to patents issues. Reformulating it in an other, more explicit way maybe: - core hosts 100% free software that can be redistributed anywhere (or almost, the world is a bit more complicated than that) - nonfree hosts non-free software that can be redistributed anywhere (same) - tainted hosts all the rest, be it free software or not. Third point is wrong, a license that is might be free or open source, which, I think, means only software with an open source software License. I understand this as: software that might be free or open source = can be not free or open source. might expressed the possibility, not the requirement. IOW, tainted does not discriminate free and non free software. It does differentiate; given that Anssi is the one who worked on the tainted policy the most, and he doesn't think faac should be in tainted, is enough to say that the wording in the wiki needs to express our stance on the issue in a clearer way... The point we made when discussing these issues was: - to provide a section where people who only want free software can have all free software (core) - to provide a section where people who want non-free software (mainly proprietary drivers, plugins, codecs) can have their drivers, plugins, whatever (non-free) - to provide a section where we can put software which may be illegal to use in certain countries (some codecs, libdvdcss2, etc.), so users and mirror maintainers in such countries can decide for themselves to use this or not (tainted) That's all. Now saying that faac should not be in tainted, where should it go if not in tainted? How does faac differ to other software which is in tainted? The only reason it should not be in tainted would be that we can not distribute it at all. This brings us back to the core of the discussion what kind of software Mageia should or should not provide. -- wobo
[Mageia-dev] Updates testing
Hello, A few package updates need testing on x86_64 (they have been tested on i586, thanks to Dave Hodgins) : https://bugs.mageia.org/show_bug.cgi?id=1944 https://bugs.mageia.org/show_bug.cgi?id=1485 https://bugs.mageia.org/show_bug.cgi?id=1892 https://bugs.mageia.org/show_bug.cgi?id=1939
Re: [Mageia-dev] Updates testing
2011/7/6 nicolas vigier bo...@mars-attacks.org: Hello, A few package updates need testing on x86_64 (they have been tested on i586, thanks to Dave Hodgins) : https://bugs.mageia.org/show_bug.cgi?id=1944 Successfully tested on Mageia 1 x86_64 (reported also in the bug report) -- wobo
Re: [Mageia-dev] Updates testing
Le mercredi 6 juillet 2011 18:12:44, nicolas vigier a écrit : Hello, A few package updates need testing on x86_64 (they have been tested on i586, thanks to Dave Hodgins) : https://bugs.mageia.org/show_bug.cgi?id=1944 https://bugs.mageia.org/show_bug.cgi?id=1485 https://bugs.mageia.org/show_bug.cgi?id=1892 https://bugs.mageia.org/show_bug.cgi?id=1939 All tested, but without a testcase, some are hard to test.
Re: [Mageia-dev] How to add package into backports_testing
Op dinsdag 05 juli 2011 01:15:52 schreef Eugeni Dodonov: On Mon, Jul 4, 2011 at 16:57, Maarten Vanraes maarten.vanr...@gmail.comwrote: Op maandag 04 juli 2011 20:31:41 schreef Dexter Morgan: On Mon, Jul 4, 2011 at 8:07 PM, Maarten Vanraes maarten.vanr...@gmail.com wrote: But skype was available for PWP, which i have. read again what misc wrote : - a package was present in Mandriva 2010.1/2 ( and only in Mandriva, not in 3rd party repository, not cooker ) skype wasn't in main nor contrib yes, again... it was in PWP (ie: the powerpack version? which _IS_ from mandriva? which had a _restricted_ repository? _not_ 3rd party??? i don't see where i'm misreading anything here... Perhaps Anne could clarify it better than I, but I think that you are misreading the part that Powerpack is/was part of Mandriva distribution. Powerpack media is *not* part of Mandriva distribution, it is a separate 3rd-party media (which happens to come from same company, but it is not part of Mandriva distribution), with access allowed only to paying customers, which is not shared with the Mandriva distribution. oic, so you're saying restricted was not a Mandriva distribution repository, but a 3rd party repository from the Mandriva company? Well, if it's like this, i do agree... but it isn't/wasn't all that clear to me as a customer of Mandriva. Thanks for clarifying this now.
Re: [Mageia-dev] Summary of the release cycle decision
Op woensdag 06 juli 2011 14:44:07 schreef Michael scherer: Hi So after reading all the feedback on the topic of release, here are the conclusion of the discussion made by Anne and me : [...] thanks for the good work!
Re: [Mageia-dev] gstreamer packaging too split?
2011/7/6 Ahmad Samir ahmadsamir3...@gmail.com: On 6 July 2011 15:09, Christiaan Welvaart c...@daneel.dyndns.org wrote: On Wed, 6 Jul 2011, Colin Guthrie wrote: Yeah it is a bit of a grab-bag of stuff, but again, should we still just bundle everything together anyway and sod the extra disk space needed? It would be a lot simpler for users (oh you need $foo? sure, just installed -ugly/-bad) which is advise they can get direct from upstream without having to know our particular packaging quirks. As someone who does upstream support for other projects, it's a pain to put caveats in all your advice for distros you don't know. That said, the trade off may be too much, hence the canvassing of opinions here :) I think there are only 2 solutions: - Add a meta package, e.g. gstreamer-codecs-all that can be used to make sure all available codecs are installed. Some people complain about bad and ugly so using those names more is not a good idea. But that's how upstream calls them, hiding them won't work, since they're too popular already. FWIW, there's gstreamer0.10-decoders, a meta package in mdv (not imported yet in Mageia). - Use the packagekit gstreamer plugin, so players install the correct plugins on demand. ATM it doesn't work, the urpmi backend needs some love.. I've already given it the tender, love care required already: https://gitorious.org/+rpm5distro/packagekit/rpm5distro-packagekit I *think* the backend itself should be working (ie. 'pkcon what-provides' behaves as expected), but when testing it with ie. totem, it'll fail installing. I kinda assumed I was the one to blame, but after discussing with packagekit upstream devs, they suspected it rather was kpackagekit in cooker that might be to blame for it's failure as the urpmi backend seemed to be okay.. I was just starting to poke around with gnome-packagekit before leaving the office today, so I haven't verified it to work with it, but perhaps some of you'll beat me to it before I get into work tomorrow..? :) Note: I've implemented several other features filters missing from the backend as well while at it, and I cannot guarantee that I haven't broken anything with older urpmi/URPM versions (I've tried not to and even fixed my code later on where I've realized doign so), so lemme know if anything breaks for ya.. (Of course, it would be *way* easier to coordinate any slightest change or what not with someone remotely interested in communicating) -- Regards, Per Øyvind
Re: [Mageia-dev] [RPM] cauldron core/release gnome-control-center-3.1.3-1.mga2
On Tuesday 05 July 2011 19:59:18 Mageia Team wrote: Name: gnome-control-center Relocations: (not relocatable) [...]. cjw cjw 3.1.3-1.mga2: + Revision: 118992 - 3.1.3 There's a file conflicts with gnome-color-manager : file /usr/lib64/control-center-1/panels/libcolor.so from install of gnome- control-center-3.1.3-2.mga2.x86_64 conflicts with file from package gnome- color-manager-3.0.0-1.mga2.x86_64 Regards, -- Balcaen John Jabber ID: mik...@jabber.littleboboy.net
Re: [Mageia-dev] [RPM] cauldron core/release gnome-settings-daemon-3.1.3-1.mga2
On Wednesday 06 July 2011 10:45:16 Mageia Team wrote: Name: gnome-settings-daemonRelocations: (not relocatable) Version : 3.1.3 Vendor: Mageia.Org Release : 1.mga2Build Date: Wed Jul 6 10:42:17 2011 Install Date: (not installed) Build Host: ecosse Group : Graphical desktop/GNOME Source RPM: (none) Size: 1355472 License: GPLv2+ Signature : (none) Packager: Mageia Team http://www.mageia.org URL : http://www.gnome.org/ Summary : GNOME Settings Daemon Description : GNOME settings daemon manages the configuration of the desktop in the background. cjw cjw 3.1.3-1.mga2: + Revision: 119250 - add BuildRequires: lcms2-devel - add BuildRequires: libcolord-devel - 3.1.3 There's a file conflicts with gnome-color-manager : file /usr/lib64/gnome-settings-daemon-3.0/color.gnome-settings-plugin from install of gnome-settings-daemon-3.1.3-1.mga2.x86_64 conflicts with file from package gnome-color-manager-3.0.0-1.mga2.x86_64 file /usr/lib64/gnome-settings-daemon-3.0/libcolor.so from install of gnome-settings-daemon-3.1.3-1.mga2.x86_64 conflicts with file from package gnome-color-manager-3.0.0-1.mga2.x86_64 file /usr/share/glib-2.0/schemas/org.gnome.settings- daemon.plugins.color.gschema.xml from install of gnome-settings- daemon-3.1.3-1.mga2.x86_64 conflicts with file from package gnome-color- manager-3.0.0-1.mga2.x86_64 Regards, -- Balcaen John Jabber ID: mik...@jabber.littleboboy.net
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
On 06.07.2011 16:04, Ahmad Samir wrote: On 6 July 2011 14:27, Romain d'Alverny rdalve...@gmail.com wrote: On Wed, Jul 6, 2011 at 14:04, Ahmad Samir ahmadsamir3...@gmail.com wrote: On 6 July 2011 13:58, Romain d'Alverny rdalve...@gmail.com wrote: On Wed, Jul 6, 2011 at 12:10, Wolfgang Bornath molc...@googlemail.com wrote: If we go back to the beginning of the discussion where to put such packages which were in PLF we made a clear difference: 1. All non-free goes into non-free 2. Software which may be illegal in some countries (mostly because of licensing) will go into tainted. That's all. Clear and simple. The question about GPL or other free licenses is not touched by tainted. So, everything which does not have to go to tainted will go to free (core) or non-free, depending on it's status. Indeed. http://mageia.org/wiki/doku.php?id=licensing_policy#acceptable_licenses says: The tainted section accepts software under a license that is might be free or open source and which cannot be redistributed publicly in certain areas in the world, or due to patents issues. Reformulating it in an other, more explicit way maybe: - core hosts 100% free software that can be redistributed anywhere (or almost, the world is a bit more complicated than that) - nonfree hosts non-free software that can be redistributed anywhere (same) - tainted hosts all the rest, be it free software or not. Third point is wrong, a license that is might be free or open source, which, I think, means only software with an open source software License. I understand this as: software that might be free or open source = can be not free or open source. might expressed the possibility, not the requirement. IOW, tainted does not discriminate free and non free software. It does differentiate; given that Anssi is the one who worked on the tainted policy the most, and he doesn't think faac should be in tainted, is enough to say that the wording in the wiki needs to express our stance on the issue in a clearer way... I don't remember saying that. Any consistent solution is acceptable to me (including put-in-nonfree, put-in-tainted, put-in-nowhere). There was opposition (from e.g. misc) to having nonfree stuff in tainted, though. -- Anssi Hannula
Re: [Mageia-dev] Arm, meeting, etc
Le lundi 04 juillet 2011 à 14:12 +0200, Michael Scherer a écrit : Hi, In order to discuss details in a more open fashion , a meeting have been planed for 6 juillet, in the afternoon around 13h UTC ( paris time, 15h ). We will use #mageia-meeting, and the goal is : 1) see who is interested by arm ( if you are but cannot be there, please say it on irc ) 2) see if the task decided for the previous IRL meeting have been caried So, no one came :( ( I blame the time we chose ). Anyway, discussing with rtp, he told me : - there is some issue with the pandaboard ( like oom killer without much reason ) - there is also some issue if we have external power and usb on the go So maybe we need to find another way to discuss this than irc ? -- Michael Scherer
Re: [Mageia-dev] Summary of the release cycle decision
On Wed, 06 Jul 2011 08:44:07 -0400, Michael scherer m...@zarb.org wrote: Since we took one month for various things ( such as discussing everything ), we propose the next release to be on 4th april, and start the cycle today. This is in the middle of the week on purpose, to avoid the weekend. Wasn't there a request some time ago to consider releasing just before the end of a month so people with monthly limits could choose to use up their current month's limit, or wait, depending on how close they were to the limit? Regards, Dave Hodgins
[Mageia-dev] extremetuxracer - Bug 1580. More testers wanted.
Can we get some more people testing etracer please? As per https://bugs.mageia.org/attachment.cgi?id=616 there is a problem with the fonts when I run it on my Mageia 1 install. I doesn't happen on my Cauldron install (I haven't been able to figure out why), or for anyone else participating in the bug report. If it works for most, without the font problem, I'm inclined to think it should go ahead into backports, and I'll open a separate bug report for the font problem. If others are seeing the font problem, then I think it should be held until we can figure out the cause, as it makes the game unplayable. Regards, Dave Hodgins
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
Anssi Hannula a écrit : On 06.07.2011 16:04, Ahmad Samir wrote: On 6 July 2011 14:27, Romain d'Alvernyrdalve...@gmail.com wrote: On Wed, Jul 6, 2011 at 14:04, Ahmad Samirahmadsamir3...@gmail.com wrote: On 6 July 2011 13:58, Romain d'Alvernyrdalve...@gmail.com wrote: On Wed, Jul 6, 2011 at 12:10, Wolfgang Bornathmolc...@googlemail.com wrote: If we go back to the beginning of the discussion where to put such packages which were in PLF we made a clear difference: 1. All non-free goes into non-free 2. Software which may be illegal in some countries (mostly because of licensing) will go into tainted. That's all. Clear and simple. The question about GPL or other free licenses is not touched by tainted. So, everything which does not have to go to tainted will go to free (core) or non-free, depending on it's status. Indeed. http://mageia.org/wiki/doku.php?id=licensing_policy#acceptable_licenses says: The tainted section accepts software under a license that is might be free or open source and which cannot be redistributed publicly in certain areas in the world, or due to patents issues. Reformulating it in an other, more explicit way maybe: - core hosts 100% free software that can be redistributed anywhere (or almost, the world is a bit more complicated than that) - nonfree hosts non-free software that can be redistributed anywhere (same) - tainted hosts all the rest, be it free software or not. Third point is wrong, a license that is might be free or open source, which, I think, means only software with an open source software License. I understand this as: software that might be free or open source = can be not free or open source. might expressed the possibility, not the requirement. IOW, tainted does not discriminate free and non free software. It does differentiate; given that Anssi is the one who worked on the tainted policy the most, and he doesn't think faac should be in tainted, is enough to say that the wording in the wiki needs to express our stance on the issue in a clearer way... I don't remember saying that. Any consistent solution is acceptable to me (including put-in-nonfree, put-in-tainted, put-in-nowhere). There was opposition (from e.g. misc) to having nonfree stuff in tainted, though. This discussion reminds me of the recent Oracle claims of patent infringement against Google, over Google's use of Java in Android. These patents were all issued by the US patent office. Google referred about 100 of these claims to the patent office for evaluation. The patent office invalidated all but 17. And these 17 may yet be invalidated by the courts. Google has not yet referred many other of the patent claims for examination by the patent office. So patent claims only _potentially_ result in legal problems. (As well as only in a few countries.) Which makes me think that the free/non-free distinction is probably much more important. My 2 cents :) -- André
Re: [Mageia-dev] gstreamer packaging too split?
Ahmad Samir a écrit : On 6 July 2011 15:09, Christiaan Welvaartc...@daneel.dyndns.org wrote: On Wed, 6 Jul 2011, Colin Guthrie wrote: Yeah it is a bit of a grab-bag of stuff, but again, should we still just bundle everything together anyway and sod the extra disk space needed? It would be a lot simpler for users (oh you need $foo? sure, just installed -ugly/-bad) which is advise they can get direct from upstream without having to know our particular packaging quirks. As someone who does upstream support for other projects, it's a pain to put caveats in all your advice for distros you don't know. That said, the trade off may be too much, hence the canvassing of opinions here :) I think there are only 2 solutions: - Add a meta package, e.g. gstreamer-codecs-all that can be used to make sure all available codecs are installed. Some people complain about bad and ugly so using those names more is not a good idea. But that's how upstream calls them, hiding them won't work, since they're too popular already. FWIW, there's gstreamer0.10-decoders, a meta package in mdv (not imported yet in Mageia). I like better using a meta package for bad and ugly. And I don't mind the names. Christiaan -- André
Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?
2011/7/7 andre999 and...@laposte.net: Anssi Hannula a écrit : On 06.07.2011 16:04, Ahmad Samir wrote: On 6 July 2011 14:27, Romain d'Alvernyrdalve...@gmail.com wrote: On Wed, Jul 6, 2011 at 14:04, Ahmad Samirahmadsamir3...@gmail.com wrote: On 6 July 2011 13:58, Romain d'Alvernyrdalve...@gmail.com wrote: On Wed, Jul 6, 2011 at 12:10, Wolfgang Bornathmolc...@googlemail.com wrote: If we go back to the beginning of the discussion where to put such packages which were in PLF we made a clear difference: 1. All non-free goes into non-free 2. Software which may be illegal in some countries (mostly because of licensing) will go into tainted. That's all. Clear and simple. The question about GPL or other free licenses is not touched by tainted. So, everything which does not have to go to tainted will go to free (core) or non-free, depending on it's status. Indeed. http://mageia.org/wiki/doku.php?id=licensing_policy#acceptable_licenses says: The tainted section accepts software under a license that is might be free or open source and which cannot be redistributed publicly in certain areas in the world, or due to patents issues. Reformulating it in an other, more explicit way maybe: - core hosts 100% free software that can be redistributed anywhere (or almost, the world is a bit more complicated than that) - nonfree hosts non-free software that can be redistributed anywhere (same) - tainted hosts all the rest, be it free software or not. Third point is wrong, a license that is might be free or open source, which, I think, means only software with an open source software License. I understand this as: software that might be free or open source = can be not free or open source. might expressed the possibility, not the requirement. IOW, tainted does not discriminate free and non free software. It does differentiate; given that Anssi is the one who worked on the tainted policy the most, and he doesn't think faac should be in tainted, is enough to say that the wording in the wiki needs to express our stance on the issue in a clearer way... I don't remember saying that. Any consistent solution is acceptable to me (including put-in-nonfree, put-in-tainted, put-in-nowhere). There was opposition (from e.g. misc) to having nonfree stuff in tainted, though. This discussion reminds me of the recent Oracle claims of patent infringement against Google, over Google's use of Java in Android. These patents were all issued by the US patent office. Google referred about 100 of these claims to the patent office for evaluation. The patent office invalidated all but 17. And these 17 may yet be invalidated by the courts. Google has not yet referred many other of the patent claims for examination by the patent office. So patent claims only _potentially_ result in legal problems. (As well as only in a few countries.) potentially and only in a few countries are not valid arguments - especially for those who live in such countries. Which makes me think that the free/non-free distinction is probably much more important. I must admit I do not understand the cause of this discussion, maybe I am thinking in too simple ways. Free goes in core, non-free goes in non-free. If a non-free software has a restrictive license it goes in tainted. A free software can not have a restrictive license, if it has it is not free and goes in tainted. -- wobo
[Mageia-dev] openldap-server needs rebuild agains new db51
openldap-server needs rebuild against new db51 otherwise a lot of packages want to be uninstalled -- Thomas
Re: [Mageia-dev] Summary of the release cycle decision
On Wed, Jul 06, 2011 at 07:47:49PM -0400, David W. Hodgins wrote: On Wed, 06 Jul 2011 08:44:07 -0400, Michael scherer m...@zarb.org wrote: Since we took one month for various things ( such as discussing everything ), we propose the next release to be on 4th april, and start the cycle today. This is in the middle of the week on purpose, to avoid the weekend. Wasn't there a request some time ago to consider releasing just before the end of a month so people with monthly limits could choose to use up their current month's limit, or wait, depending on how close they were to the limit? I don't recall seeing such a discussion... but I think we are now drifting too far off... I think the number of persons for which this is an issue is really limited and any date that we pick will be somewhat arbitrarily. That said, I believe April 1st will satisfy everyone as: - It is exactly 10 months after the first release; - People will have the entire month to decide if they want to up their month's limit or not; - Some people will only realise at the end of the month that the release was for real and not an April fools joke so they won't have this dilemma; - The release of mga2 will coincide with my nieces second birthday. Kind regards, Remco PS. Please take this entire post with a grain of salt :-) signature.asc Description: Digital signature
