Re: [Mageia-dev] RFC: Improvements for ioquake3 package and related games
On Sat, Dec 10, 2011 at 8:51 PM, Olivier Blin wrote: > Why not just package the proprietary data in non-free? > Because I'm not sure if all games licenses allow redistribution, I'm basing my decisions on Fedora gaming policy[1] and why they choose to not include a game. I'm not sure if they don't have a non-free media and if that's the reason to use the autodownload feature. Also autodownloading will save a lot of space in mirrors,as most FPS game data is around ~700MB per game (UrT 1GB, WoP 800MB, SG 350MB, Sauerbraten 500MB etc) so we are talking of close to 3GB on just the games I'm packaging, but if it is ok to include them on non-free, *if* game data license allows redistribution, then I agree that the non-free media would be a better solution than autodownloading the game data. [1] http://fedoraproject.org/wiki/SIGs/Games#List_of_games_we_will_NOT_package -- Juancho
Re: [Mageia-dev] Need for a clear policy on translated man pages
W dniu 10.12.2011 17:33, Olivier Blin pisze: Kamil Rytarowski writes: Is it possible to handle multiple man pages in different languages with some macro? %find_lang --with-man ? I think this is broken in Mageia. I've attached a patch to do it my-way :) and it works after some tests.. https://bugs.mageia.org/show_bug.cgi?id=3697 Quote: [..] I've encountered wrong working of find-lang with --with-man parameter. It can work with --all-name or without it. I'm working with my local copy of scrotwm.spec and: With --all-name it produces (debug mode on): DEBUG: OUT: %lang(es) /usr/share/man/es DEBUG: OUT: %lang(it) /usr/share/man/it DEBUG: OUT: %lang(pt) /usr/share/man/pt DEBUG: OUT: %lang(ru) /usr/share/man/ru And this is fine! It then catches automatically every file in these directories. And without --all-name: DEBUG: OUT: %dir %lang(es) /usr/share/man/es DEBUG: OUT: %dir %lang(es) /usr/share/man/es/man1 DEBUG: OUT: %lang(es) /usr/share/man/es/man1/scrotwm.* DEBUG: OUT: %dir %lang(it) /usr/share/man/it DEBUG: OUT: %dir %lang(it) /usr/share/man/it/man1 DEBUG: OUT: %lang(it) /usr/share/man/it/man1/scrotwm.* DEBUG: OUT: %dir %lang(pt) /usr/share/man/pt DEBUG: OUT: %dir %lang(pt) /usr/share/man/pt/man1 DEBUG: OUT: %lang(pt) /usr/share/man/pt/man1/scrotwm.* DEBUG: OUT: %dir %lang(ru) /usr/share/man/ru DEBUG: OUT: %dir %lang(ru) /usr/share/man/ru/man1 DEBUG: OUT: %lang(ru) /usr/share/man/ru/man1/scrotwm.* And this result is wrong! And there are also warnings during the build process (saying that some files are listed multiple times in %file). IMO the right result is only: DEBUG: OUT: %lang(es) /usr/share/man/es/man1/scrotwm.* DEBUG: OUT: %lang(it) /usr/share/man/it/man1/scrotwm.* DEBUG: OUT: %lang(pt) /usr/share/man/pt/man1/scrotwm.* DEBUG: OUT: %lang(ru) /usr/share/man/ru/man1/scrotwm.* This is right because the script catches ONLY a man page for the specific package
Re: [Mageia-dev] [soft-commits] [2362] timezone must be on livecds (#3497)
Thierry Vignaud writes: > On 10 December 2011 18:54, wrote: >> Revision 2362 Author tmb Date 2011-12-10 18:54:21 +0100 (Sat, 10 Dec 2011) >> >> Log Message >> >> timezone must be on livecds (#3497) > > Why is it needed? Isn't timezone already on live CDs ? see: > > $ rpm -e timezone > error: Failed dependencies: > timezone is needed by (installed) basesystem-minimal-1:2-3.mga2.x86_64 Right, this did not fix any issue :) There was an issue about basesystem (and lots of packages) being unselected on Gnome live CDs, we've fixed this properly later in live-config SVN. -- Olivier Blin - blino
Re: [Mageia-dev] RFC: Improvements for ioquake3 package and related games
Juan Luis Baptiste writes: > As a FPS game lover, I do play a lot of ioquake3's derived games and > want to improve the support of them in Mageia. Fedora has an ioquake3 > package which support several Quake III derived games with proprietary > license data. This are the games supported by this package: > - Official Quake III demo > - Urban Terror > - World Of Padman > > The ioquake3 package creates a sub package for ioquake3 and each of > the supported games, and each of this packages include a script to > auto-download the proprietary license game data at first run of the > game using the autodownloader program. When any of the games listed > above is run, a window will popup displaying the game license and upon > agreeing on it, the script will download the game data from a > predefined list of mirrors and install it in the proper place. Why not just package the proprietary data in non-free? -- Olivier Blin - blino
Re: [Mageia-dev] Where to report mageia 2 alpha 1 problems?
On Sat, 10 Dec 2011 15:51:28 -0500, David W. Hodgins wrote about Re: [Mageia-dev] Where to report mageia 2 alpha 1 problems?: >On Sat, 10 Dec 2011 10:01:38 -0500, Franklin Weng > wrote: > >> 2011/12/10 Manuel Hiebel : >>> Le samedi 10 décembre 2011 à 21:23 +0800, Franklin Weng a écrit : >>> https://wiki.mageia.org/en/Mageia_2_alpha1 is up and there is a link to >>> https://wiki.mageia.org/en/Mageia_2_alpha1#Bug_reporting > >> I still failed to connect to wiki.mageia.org. > >Any chance you're using a dsn server with dnssec enabled? > >I had problems when using my own name server with a combination >of ad blocking, and dnssec turned on. At first I thought it was >one of the host names I was blocking, but it turned out that >turning off dnssec fixed the problem for me. > >Haven't had time to trace it down and report the problem yet. Once upon a time I had the same prob with some sites and changed my /etc/sysctl.conf, adding: quote # for more agressive network throughput as per # http://blogs.techrepublic.com.com/opensource/?p=62 dvg early 2008 net.ipv4.tcp_syncookies = 1 net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 65536 16777216 unquote HTH Cheers, =Dick Gevers=
Re: [Mageia-dev] [soft-commits] [2359] coding style update (perl_checker)
On Sat, Dec 10, 2011 at 20:37, Thierry Vignaud
wrote:
> On 10 December 2011 20:25, Romain d'Alverny wrote:
>>> if ((@info{qw(name version release variant arch medium build
>>> ext)}) = $name =~
>>>
>>> m/^(Mageia)-(\d+)-((?:alpha|beta|RC)\d*)?(-(?:.*))?-(i586|x86_64|dual)?(?:-(CD|DVD|BD))?(?:-(build_\w+))?\.(.*)$/)
>>> {
>>> $info{full} = $name;
>>> }
>>
>> Looks much more compact, thanks. Added a "else { %info = (); }" to
>> satisfy the expected behaviour (empty array returned if no match).
>
> This is wrong.
> Once declared (aka "my %info"), %info is initialized and is equal to "()".
Yes, but otherwise, testing the code you provided, even if the regexp
test fails, returned %info is still populated with keys, pointing to
undef values.
>> By the way, is there a "best" Web-based doc for MDK Perl libraries?
>> (could find one, but not at once, and I didn't count many). Or shall
>> we think about it?
>
> perldoc MDK::Common
Thanks, this is cool for a local access. Looking for a way to export
this into HTML.
Re: [Mageia-dev] Where to report mageia 2 alpha 1 problems?
On Sat, 10 Dec 2011 10:01:38 -0500, Franklin Weng wrote: 2011/12/10 Manuel Hiebel : Le samedi 10 décembre 2011 à 21:23 +0800, Franklin Weng a écrit : https://wiki.mageia.org/en/Mageia_2_alpha1 is up and there is a link to https://wiki.mageia.org/en/Mageia_2_alpha1#Bug_reporting I still failed to connect to wiki.mageia.org. Any chance you're using a dsn server with dnssec enabled? I had problems when using my own name server with a combination of ad blocking, and dnssec turned on. At first I thought it was one of the host names I was blocking, but it turned out that turning off dnssec fixed the problem for me. Haven't had time to trace it down and report the problem yet. Regards, Dave Hodgins
Re: [Mageia-dev] [soft-commits] [2359] coding style update (perl_checker)
On 10 December 2011 20:25, Romain d'Alverny wrote:
>> just do sg like this:
>> [...]
>> if ((@info{qw(name version release variant arch medium build
>> ext)}) = $name =~
>>
>> m/^(Mageia)-(\d+)-((?:alpha|beta|RC)\d*)?(-(?:.*))?-(i586|x86_64|dual)?(?:-(CD|DVD|BD))?(?:-(build_\w+))?\.(.*)$/)
>> {
>> $info{full} = $name;
>> }
>> [...]
>
> Looks much more compact, thanks. Added a "else { %info = (); }" to
> satisfy the expected behaviour (empty array returned if no match).
This is wrong.
Once declared (aka "my %info"), %info is initialized and is equal to "()".
>>> open(my $file, "temp_media_on_iso.log") if -r "temp_media_on_iso.log";
>>>
>>> while ($media = <$file>) {
>>
>> just reuse cat_() from MDK::Common (simpler, easier to read)
>
> Thanks!
>
> By the way, is there a "best" Web-based doc for MDK Perl libraries?
> (could find one, but not at once, and I didn't count many). Or shall
> we think about it?
perldoc MDK::Common
I've locally a branch adding doc for drakx but it's not finished.
Re: [Mageia-dev] Build-in or stand-alone module for X to support Y
Manuel Hiebel a écrit : Le samedi 10 décembre 2011 à 14:48 +0100, Maarten Vanraes a écrit : Op zaterdag 10 december 2011 14:41:30 schreef Kamil Rytarowski: W dniu 10.12.2011 14:11, Maarten Vanraes pisze: [...] look at other packages, like mysql, they generate a README.install.urpmi file which show this text in rpmdrake Rpmdrake ? are you sure it's not only in urpmi ? (cli There are warnings like that with rpmdrake. (Not used very much, but seen from time to time.) -- André
Re: [Mageia-dev] [soft-commits] [2359] coding style update (perl_checker)
On Sat, Dec 10, 2011 at 18:59, Thierry Vignaud
wrote:
> On 10 December 2011 18:29, wrote:
>> coding style update (perl_checker)
>
> uh? Tools.pm doesn't currently pass perl_checker
Right; but I couldn't see why that was a syntax error at that point
(and the script did work). Anyway, now it looks much better (but for
used modules or "not recognised yet").
> just do sg like this:
> [...]
> if ((@info{qw(name version release variant arch medium build
> ext)}) = $name =~
>
> m/^(Mageia)-(\d+)-((?:alpha|beta|RC)\d*)?(-(?:.*))?-(i586|x86_64|dual)?(?:-(CD|DVD|BD))?(?:-(build_\w+))?\.(.*)$/)
> {
> $info{full} = $name;
> }
> [...]
Looks much more compact, thanks. Added a "else { %info = (); }" to
satisfy the expected behaviour (empty array returned if no match).
>> open(my $file, "temp_media_on_iso.log") if -r "temp_media_on_iso.log";
>>
>> while ($media = <$file>) {
>
> just reuse cat_() from MDK::Common (simpler, easier to read)
Thanks!
By the way, is there a "best" Web-based doc for MDK Perl libraries?
(could find one, but not at once, and I didn't count many). Or shall
we think about it?
Re: [Mageia-dev] Package adoption campaign, 3 months later
Samuel Verschelde a écrit : Le jeudi 8 décembre 2011 11:51:46, Funda Wang a écrit : 2011/12/8 Samuel Verschelde: His/her work would be the following: - identifiy (with bugsquad's help) the orphan packages that have lots of unresolved bugs or are severely outdated, - do the same for packages that have a maintainer but are in a similar situation, - try to find packagers or apprentices to take care of them. Not necessarily make them become maintainer, but at least solve users bugs. - try to find maintainers for orphan packages. I would suggest that registering nobody as a mailing list, so that every interested packagers could join to help. I forgot about this idea, and support it without hesitation. Maybe a better idea, would to have "[orphan alert]" (or something similar) in the subject of postes to the mageia-dev list. That way no need to subscribe to another mailing list, and those particularly interested in orphaned packages could filter their messages to put these in a separate folder. And of course, everyone interested in packaging/development would see these posts. Just an idea :) -- André
Re: [Mageia-dev] [soft-commits] [2362] timezone must be on livecds (#3497)
Thierry Vignaud skrev 10.12.2011 20:26: On 10 December 2011 19:13, Thomas Backlund wrote: Log Message timezone must be on livecds (#3497) Why is it needed? Isn't timezone already on live CDs ? see: $ rpm -e timezone error: Failed dependencies: timezone is needed by (installed) basesystem-minimal-1:2-3.mga2.x86_64 ??? Hmmm, seems to be a problem on livecd build... basesystem-minimal is not on Gnome livecd either :/ Time to check the buildlogs. This is the root issue that has to be fixed instead of workarounding it since we might get other similar issues :-) I guess the correct package to force is basesystem. its already on the kde livecds... -- Thomas
Re: [Mageia-dev] Package adoption campaign, 3 months later
Le samedi 10 décembre 2011 12:14:56, Samuel Verschelde a écrit : > Le samedi 10 décembre 2011 11:14:38, Michael Scherer a écrit : > > A free-for-all pool is just a mess. > > You're explaining why having orphan packages is bad and it's hard to > disagree, but I fail to see why such a mailing list for people who are > ready to devote some time to orphan packages would make things worse. It's > not because it's not the ideal solution that it's bad, is it? > Well, I understand misc : if anyone can do, often no one does. This ML is a way to keep things as they are, and even making people unmaintain some packages. So a not ideal solution can be a bad solution.
Re: [Mageia-dev] [soft-commits] [2362] timezone must be on livecds (#3497)
On 10 December 2011 19:13, Thomas Backlund wrote: >>> Log Message >>> >>> timezone must be on livecds (#3497) >> >> Why is it needed? Isn't timezone already on live CDs ? see: >> >> $ rpm -e timezone >> error: Failed dependencies: >> timezone is needed by (installed) >> basesystem-minimal-1:2-3.mga2.x86_64 >> >> ??? > > Hmmm, seems to be a problem on livecd build... basesystem-minimal is not on > Gnome livecd either :/ > > Time to check the buildlogs. This is the root issue that has to be fixed instead of workarounding it since we might get other similar issues :-)
Re: [Mageia-dev] [soft-commits] [2362] timezone must be on livecds (#3497)
Thierry Vignaud skrev 10.12.2011 20:04: On 10 December 2011 18:54, wrote: Revision 2362 Author tmb Date 2011-12-10 18:54:21 +0100 (Sat, 10 Dec 2011) Log Message timezone must be on livecds (#3497) Why is it needed? Isn't timezone already on live CDs ? see: $ rpm -e timezone error: Failed dependencies: timezone is needed by (installed) basesystem-minimal-1:2-3.mga2.x86_64 ??? Hmmm, seems to be a problem on livecd build... basesystem-minimal is not on Gnome livecd either :/ Time to check the buildlogs. -- Thomas
Re: [Mageia-dev] [soft-commits] [2362] timezone must be on livecds (#3497)
On 10 December 2011 18:54, wrote: > Revision 2362 Author tmb Date 2011-12-10 18:54:21 +0100 (Sat, 10 Dec 2011) > > Log Message > > timezone must be on livecds (#3497) Why is it needed? Isn't timezone already on live CDs ? see: $ rpm -e timezone error: Failed dependencies: timezone is needed by (installed) basesystem-minimal-1:2-3.mga2.x86_64 ???
Re: [Mageia-dev] [soft-commits] [2359] coding style update (perl_checker)
On 10 December 2011 18:29, wrote:
> Revision 2359 Author rda Date 2011-12-10 18:29:07 +0100 (Sat, 10 Dec 2011)
>
> Log Message
>
> coding style update (perl_checker)
uh? Tools.pm doesn't currently pass perl_checker
> Modified Paths
>
> isocheck/trunk/Tools.pm
> isocheck/trunk/t/003_is_hybrid.t
> isocheck/trunk/t_install_iso/010_check_autorun.t
> isocheck/trunk/t_install_iso/012_check_ids.t
> isocheck/trunk/t_install_iso/013_check_rpms.t
> isocheck/trunk/t_install_iso/016_check_pubkey.t
>
> Modified: isocheck/trunk/Tools.pm
> ===
> --- isocheck/trunk/Tools.pm 2011-12-10 17:27:16 UTC (rev 2358)
> +++ isocheck/trunk/Tools.pm 2011-12-10 17:29:07 UTC (rev 2359)
> @@ -33,18 +33,18 @@
>
> sub parse_mageia_iso_name {
> my ($name) = @_;
> -my %info = ();
> +my %info;
>
> -if ($name =~
> m/^(Mageia)-(\d+)(-(alpha|beta|RC)(\d*))?(-(.*))?-(i586|x86_64|dual)?(-(CD|DVD|BD))?(-(build\_\w+))?\.(.*)$/)
> {
> -$info{"full"}= $name;
> -$info{"name"}= $1 if defined $1;
> -$info{"version"} = $2 if defined $2;
> -$info{"release"} = "$4$5" if defined $4;
> -$info{"variant"} = $7 if defined $7;
> -$info{"arch"}= $8 if defined $8;
> -$info{"medium"} = $10 if defined $10;
> -$info{"build"} = $12 if defined $12;
> -$info{"ext"} = $13 if defined $13;
> +if ($name =~
> m/^(Mageia)-(\d+)(-(alpha|beta|RC)(\d*))?(-(.*))?-(i586|x86_64|dual)?(-(CD|DVD|BD))?(-(build_\w+))?\.(.*)$/)
> {
> +$info{full}= $name;
> +$info{name}= $1 if defined $1;
> +$info{version} = $2 if defined $2;
> +$info{release} = "$4$5" if defined $4;
> +$info{variant} = $7 if defined $7;
> +$info{arch}= $8 if defined $8;
> +$info{medium} = $10 if defined $10;
> +$info{build} = $12 if defined $12;
> +$info{ext} = $13 if defined $13;
You don't need all those tests since you already checked if the regexp
matched or not.
You only have to check for ()? groups.
What's more your checks are inconsistant anyway (eg you don't check for $5)
just do sg like this:
sub parse_mageia_iso_name {
my ($name) = @_;
my %info;
if ((@info{qw(name version release variant arch medium build
ext)}) = $name =~
m/^(Mageia)-(\d+)-((?:alpha|beta|RC)\d*)?(-(?:.*))?-(i586|x86_64|dual)?(?:-(CD|DVD|BD))?(?:-(build_\w+))?\.(.*)$/)
{
$info{full} = $name;
}
return %info;
}
> Modified: isocheck/trunk/t/003_is_hybrid.t
> ===
> --- isocheck/trunk/t/003_is_hybrid.t 2011-12-10 17:27:16 UTC (rev 2358)
> +++ isocheck/trunk/t/003_is_hybrid.t 2011-12-10 17:29:07 UTC (rev 2359)
> @@ -24,7 +24,7 @@
>
> my ($image_path) = @ARGV;
>
> -ok (is_hybrid($image_path, 0), "Is hybrid");
> +ok is_hybrid($image_path, 0), "Is hybrid";
please keep (), it's clearer. just remove the space between "ok" and "("
> Modified: isocheck/trunk/t_install_iso/016_check_pubkey.t
> ===
> --- isocheck/trunk/t_install_iso/016_check_pubkey.t 2011-12-10 17:27:16 UTC
> (rev 2358)
> +++ isocheck/trunk/t_install_iso/016_check_pubkey.t 2011-12-10 17:29:07 UTC
> (rev 2359)
> @@ -39,17 +39,17 @@
> system "ls /media/iso_check/i586/media/ > temp_media_on_iso.log" if -r
> "/media/iso_check/i586/media/";
> system "ls /media/iso_check/x86_64/media/ >> temp_media_on_iso.log" if -r
> "/media/iso_check/x86_64/media/";
>
> -ok (-r "temp_media_on_iso.log", "Got a log for media contents");
> +ok -r "temp_media_on_iso.log", "Got a log for media contents";
>
> open(my $file, "temp_media_on_iso.log") if -r "temp_media_on_iso.log";
>
> while ($media = <$file>) {
just reuse cat_() from MDK::Common (simpler, easier to read)
Re: [Mageia-dev] Need for a clear policy on translated man pages
W dniu 10.12.2011 17:33, Olivier Blin pisze: Kamil Rytarowski writes: Is it possible to handle multiple man pages in different languages with some macro? %find_lang --with-man ? Ah.. so please make it clear for everybody in our policies and guidelines.
Re: [Mageia-dev] [changelog] [RPM] 1 core/updates_testing drakx-net-0.97.2-1.mga1
Thierry Vignaud writes: > On 5 December 2011 12:07, Mageia Team wrote: >> zezinho 0.97.2-1.mga1: >> + Revision: 176878 >> - fix squid configuration when sharing internet connection (#1353) > > you forgot some of the changes (strings not tagged as translatable) And we should directly push drakx-net 1.1 to Mageia 1/updates, all fixes apply to Mageia 1 -- Olivier Blin - blino
Re: [Mageia-dev] Need for a clear policy on translated man pages
Kamil Rytarowski writes: > Is it possible to handle multiple man pages in different languages > with some macro? %find_lang --with-man ? -- Olivier Blin - blino
[Mageia-dev] Need for a clear policy on translated man pages
Hello!
Please make it clear, at least for newcomers, how to package translated
man pages in Mageia. Our policies and guidelines aren't clear.
https://wiki.mageia.org/en/Packaging_guidelines#Handling_Locale_Files
suggested, before the latest changes, with "If the package includes
translations, add BuildRequires: gettext If you don't, your package
could fail to generate translation files in the buildroot." that this
section is also about man pages. Translated man pages are
_translations_, aren't they?
In the "Packaging localisation policy" it's more clear. But still
expressions like "some cases" aren't clear. I wouldn't say that *all*
man pages are counted as "some [special] case". Aren't I right?
Is it possible to handle multiple man pages in different languages with
some macro? At times it's bit complicated, for example for amule it's
done like this:
%lang(de) %{_mandir}/de/man1/alc.1*
%lang(es) %{_mandir}/es/man1/alc.1*
%lang(hu) %{_mandir}/hu/man1/alc.1*
%lang(de) %{_mandir}/de/man1/amule.1*
%lang(it) %{_mandir}/it/man1/amule.1*
%lang(de) %{_mandir}/de/man1/amulegui.1*
%lang(it) %{_mandir}/it/man1/amulegui.1*
%lang(de) %{_mandir}/de/man1/cas.1*
%lang(de) %{_mandir}/de/man1/ed2k.1*
%lang(de) %{_mandir}/de/man1/wxcas.1*
%lang(de) %{_mandir}/de/man1/xas.1*
%lang(es) %{_mandir}/es/man1/amule.1*
%lang(es) %{_mandir}/es/man1/amulegui.1*
%lang(es) %{_mandir}/es/man1/cas.1*
%lang(es) %{_mandir}/es/man1/ed2k.1*
%lang(es) %{_mandir}/es/man1/wxcas.1*
%lang(es) %{_mandir}/es/man1/xas.1*
%lang(fr) %{_mandir}/fr/man1/alc.1*
%lang(fr) %{_mandir}/fr/man1/amule.1*
%lang(fr) %{_mandir}/fr/man1/ed2k.1*
%lang(fr) %{_mandir}/fr/man1/cas.1*
%lang(fr) %{_mandir}/fr/man1/xas.1*
%lang(fr) %{_mandir}/fr/man1/amulegui.1*
%lang(fr) %{_mandir}/fr/man1/wxcas.1*
%lang(hu) %{_mandir}/hu/man1/amule.1*
%lang(hu) %{_mandir}/hu/man1/cas.1*
%lang(hu) %{_mandir}/hu/man1/ed2k.1*
%lang(it) %{_mandir}/it/man1/ed2k.1*
%lang(it) %{_mandir}/it/man1/alc.1*
%lang(it) %{_mandir}/it/man1/cas.1*
%lang(it) %{_mandir}/it/man1/wxcas.1*
%lang(it) %{_mandir}/it/man1/xas.1*
%lang(hu) %{_mandir}/hu/man1/amulegui.1*
%lang(hu) %{_mandir}/hu/man1/wxcas.1*
%lang(hu) %{_mandir}/hu/man1/xas.1*
%lang(ru) %{_mandir}/ru/man1/alc.1*
%lang(ru) %{_mandir}/ru/man1/amule.1*
%lang(ru) %{_mandir}/ru/man1/amulegui.1*
%lang(ru) %{_mandir}/ru/man1/cas.1*
%lang(ru) %{_mandir}/ru/man1/ed2k.1*
%lang(ru) %{_mandir}/ru/man1/wxcas.1*
%lang(ru) %{_mandir}/ru/man1/xas.1*
%lang(de) %{_mandir}/de/man1/alcc.1*
%lang(es) %{_mandir}/es/man1/alcc.1*
%lang(fr) %{_mandir}/fr/man1/alcc.1*
%lang(it) %{_mandir}/it/man1/alcc.1*
%lang(ru) %{_mandir}/ru/man1/alcc.1*
%lang(hu) %{_mandir}/hu/man1/alcc.1*
%lang(de) %{_mandir}/de/man1/amulecmd.1*
%lang(es) %{_mandir}/es/man1/amulecmd.1*
%lang(fr) %{_mandir}/fr/man1/amulecmd.1*
%lang(hu) %{_mandir}/hu/man1/amulecmd.1*
%lang(it) %{_mandir}/it/man1/amulecmd.1*
%lang(ru) %{_mandir}/ru/man1/amulecmd.1*
%lang(de) %{_mandir}/de/man1/amuled.1*
%lang(es) %{_mandir}/es/man1/amuled.1*
%lang(fr) %{_mandir}/fr/man1/amuled.1*
%lang(hu) %{_mandir}/hu/man1/amuled.1*
%lang(it) %{_mandir}/it/man1/amuled.1*
%lang(ru) %{_mandir}/ru/man1/amuled.1*
%lang(de) %{_mandir}/de/man1/amuleweb.1*
%lang(es) %{_mandir}/es/man1/amuleweb.1*
%lang(fr) %{_mandir}/fr/man1/amuleweb.1*
%lang(hu) %{_mandir}/hu/man1/amuleweb.1*
%lang(it) %{_mandir}/it/man1/amuleweb.1*
%lang(ru) %{_mandir}/ru/man1/amuleweb.1*
PS. The policy suggest to follow numlock.spec and in the file we read in
the 1st like as follows "# WARNING THIS HAS TO BE EDITED IN THE
SVN !!!" - is this a provocation? The file was untouched for 10
months :)
Re: [Mageia-dev] RFC: Opening Backports (once again...)
Michael Scherer skrev 10.12.2011 13:32:
Le mardi 06 décembre 2011 à 00:56 +0200, Thomas Backlund a écrit :
Now,
here comes the question about backports once again.
We are now 6+ months into Mageia 1, and we are nowhere closer to opening
backports that we were at Mageia 1 release time.
Because of that there are 3rdparty repos popping up everywhere...,
something we hoped to avoid atleast partly when starting this project.
Well, the backport issue ( ie :
- no garantee of keep the distribution upgradable
Policy is to always keep Cauldron with atleast higher release,
so next release will be ok.
I guess when we have 2 releases we must extend the policy to
state that if you backport to Mageia 1 you also must backport
to Mageia 2 in order to keep upgrading fully possible.
- no security )
Well, that's the same as with current stable relase,
maintainer/backporter submits security fixes to backports_testing
QA validates, update gets pushed.
have also not been fixed, so that's rather unfair to
And at current rate we will probably release Mageia "infinity"
before backports is opened.
It has been delayed because of needed infrastructure changes,
something no-one have had time to do so far...
I know there is "only some coding missing" and "someone should
do it", buth truthfully there are only a few that knows the
code used in the buildsystem enough to actually make it happend,
and they are already othervise busy or overloaded...
(this is no rant against them, as all here are using their
personal free time to help out)
And to be honest I dont see that changing anytime soon...
Then we have a bigger problem to solve.
Yep, no argument here
So here is a suggestion to get some value to our endusers:
we add a backports branch on svn
So packages for backports would use:
svn.mageia.org/packages/backports/1//{current,pristine,releases}
and allow that to be used for backports.
Using a separate branch is also a cleaner way of providing
backports, and makes it easy to separate changes needed only
for Cauldron (or backports).
Then in practice, that mean having a 2nd/3rd distribution ( because
there is a separate 2nd svn branch, and a 3rd one for later ) and so
that's a big no for me. Having 2+ branchs is just asking for trouble
when they are not in sync ( and since keeping everything in sync
properly with svn is a pain if there is a divergence, this will not be
done ).
Worst, if we do like in mdv and propose 2 way of backporting ( submit
from cauldron, submit from a branch ), this will create a mess of having
some packages from cauldron, some from the branch, and people having no
way from knowing where does a package come from. This also make the
system harder to maintain and to follow, and rather impossible to script
properly.
So that's also to be avoided.
Well, branching is needed, regardless if it's done in a whole separate
branch as I suggested, or in a branch per package when needed.
Having a separate branch where people can write also remove the only
incentive I have seen for backports, ie, wider testing of our packages,
because they may not really the same as in cauldron.
It cant always be the same in cauldron and backports.
So here is what I propose :
- have X branchs, but do not let anyone commit on it, besides a system
user. When a package is submitted to cauldron, it is also copied to this
branch, ie, we make sure current is in sync. The same goes for version
N-1 being copied from N once a backported rpm have been submitted to be
used by people. Once a distribution is no longer supported, we close the
branch, and disable the sync.
If you cant commit to the branch, it's useless.
- backports are only submitted from the branch, with separate
markrelease, tags, whatever. This let us have proper audit of backports,
and who did what.
the same auditing is available in any branch or cauldron.
- packagers still need to commit and submit on cauldron before any
backports. So we miss no fixes or anything by mistake. We also make sure
that cauldron is always the highest version possible, thus permitting at
least some form of upgrade. ( either stable to stable, provided
backports are used, or stable to cauldron ). And we also ensure that
backports are done first on the most recent stable version, for the same
reason ( ensure some form of upgrade path, as asked several time by
users ).
Sorry, buth this wont work in reality...
Consider this:
version X in Mageia 1
version X+1 in Cauldron
version X+1 gets backported.
version X+2 uploaded in Cauldron
version X+2 cant be backported (depends on updated libs/packages in
Cauldron, and we dont backport libs that can break working setups)
version X+1 in backports need to be fixed (security/maintenance fix)
(here your logic breaks down, there is no place to fix it)
And since we aim for quality backports, the maintainer may want to
stay with version X+1 in backports even if X+2 could be backported
if maintainer thi
Re: [Mageia-dev] Where to report mageia 2 alpha 1 problems?
On Sat, 10 Dec 2011 15:20:09 +0100, Manuel Hiebel wrote about Re: [Mageia-dev] Where to report mageia 2 alpha 1 problems?: >https://wiki.mageia.org/en/Mageia_2_alpha1 is up and there is a link to >https://wiki.mageia.org/en/Mageia_2_alpha1#Bug_reporting My guess is the '1' should be a '2' at the end of the URL Ciao, =Dick Gevers=
Re: [Mageia-dev] Where to report mageia 2 alpha 1 problems?
2011/12/10 Franklin Weng : > 2011/12/10 Manuel Hiebel : >> Le samedi 10 décembre 2011 à 21:23 +0800, Franklin Weng a écrit : >>> Hi list, >>> >>> >>> I tested mageia 2 alpha 1 (KDE live CD) for the audio problem (bug >>> 2437) and at the same time I found another two problems. >>> >>> Where can I report it? The wiki pages seem to be down for now. >> >> Which wiki page is down ? >> >> https://wiki.mageia.org/en/Mageia_2_alpha1 is up and there is a link to >> https://wiki.mageia.org/en/Mageia_2_alpha1#Bug_reporting >> > > I still failed to connect to wiki.mageia.org. This must be a lokal area problem - I have no problems connecting to that address. -- wobo
Re: [Mageia-dev] Where to report mageia 2 alpha 1 problems?
2011/12/10 Manuel Hiebel : > Le samedi 10 décembre 2011 à 21:23 +0800, Franklin Weng a écrit : >> Hi list, >> >> >> I tested mageia 2 alpha 1 (KDE live CD) for the audio problem (bug >> 2437) and at the same time I found another two problems. >> >> Where can I report it? The wiki pages seem to be down for now. > > Which wiki page is down ? > > https://wiki.mageia.org/en/Mageia_2_alpha1 is up and there is a link to > https://wiki.mageia.org/en/Mageia_2_alpha1#Bug_reporting > I still failed to connect to wiki.mageia.org. Franklin
Re: [Mageia-dev] Where to report mageia 2 alpha 1 problems?
Le samedi 10 décembre 2011 à 21:23 +0800, Franklin Weng a écrit : > Hi list, > > > I tested mageia 2 alpha 1 (KDE live CD) for the audio problem (bug > 2437) and at the same time I found another two problems. > > Where can I report it? The wiki pages seem to be down for now. Which wiki page is down ? https://wiki.mageia.org/en/Mageia_2_alpha1 is up and there is a link to https://wiki.mageia.org/en/Mageia_2_alpha1#Bug_reporting > > 1. When I launched Telepathy account manager I got an error message > saying that, "Something went terribly wrong and the IM system could > not be initialized. It is likely your system is missing Telepathy > Mission Control package." So there is no telepathy mission control > package in KDE live cd, is there? > > 2. If I turned "Screenshot" KDE desktop effect on, I still got > problems getting screenshot with ksnapshot. It is an old problem in > mageia 1. > > Please tell me where I can report these problem. I'll report it again > to where it should go. I have not check if we have already a bug report for each one but feel free to do them. (or ping/ reopen if there is one) > > Thanks, > Franklin
Re: [Mageia-dev] Where to report mageia 2 alpha 1 problems?
10.12.2011 15:23, Franklin Weng kirjutas: Hi list, I tested mageia 2 alpha 1 (KDE live CD) for the audio problem (bug 2437) and at the same time I found another two problems. Where can I report it? The wiki pages seem to be down for now. https://bugs.mageia.org 2. If I turned "Screenshot" KDE desktop effect on, I still got problems getting screenshot with ksnapshot. It is an old problem in mageia 1. This is upstream bug and you should report it there. Tho' i believe it's already reported. -- Sander
Re: [Mageia-dev] Build-in or stand-alone module for X to support Y
Le samedi 10 décembre 2011 à 14:48 +0100, Maarten Vanraes a écrit : > Op zaterdag 10 december 2011 14:41:30 schreef Kamil Rytarowski: > > W dniu 10.12.2011 14:11, Maarten Vanraes pisze: > > > Op zaterdag 10 december 2011 14:06:18 schreef Kamil Rytarowski: > > >> W dniu 10.12.2011 13:45, Maarten Vanraes pisze: > > >>> Op zaterdag 10 december 2011 13:12:52 schreef Kamil Rytarowski: > > Hello! [...] > look at other packages, like mysql, they generate a README.install.urpmi file > which show this text in rpmdrake Rpmdrake ? are you sure it's not only in urpmi ? (cli) -- Manuel Hiebel http://netiquette.fr/
Re: [Mageia-dev] [2302] ide_cd_mod does not exist anymore (thanks aginies)
On 10 December 2011 10:08, D.Morgan wrote: >>> Revision >>> 2302 >>> Author >>> ennael >>> Date >>> 2011-12-07 11:35:48 +0100 (Wed, 07 Dec 2011) >>> >>> >>> Log Message >>> >>> ide_cd_mod does not exist anymore (thanks aginies) >> >> Oh yes it does! >> >> It's only in mdv they have disabled all ide drivers without thinking of >> those where the pata drivers dont work... >> > should this be reverted then ? Indeed. What's more mdv's change is bogus as sd_mod is already loaded when needed. Actually most of their changes are made for us to laugh...
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release drakconf-12.22.1-1.mga2
Le samedi 10 décembre 2011 à 13:16 +0100, Thierry Vignaud a écrit : > On 10 December 2011 13:11, Mageia Team wrote: > > tv 12.22.1-1.mga2: > > + Revision: 180273 > > - rebuild with new ldetect-lst > > oops: bogus changelog: "further update Release Notes URL" > > Maybe should we push drakconf-12.22.1 as updates in order to have > fixed entries in help menu now that have the proper entries in the wiki? Yep and iirc there is also some minor fix no ?
Re: [Mageia-dev] Build-in or stand-alone module for X to support Y
Op zaterdag 10 december 2011 14:41:30 schreef Kamil Rytarowski:
> W dniu 10.12.2011 14:11, Maarten Vanraes pisze:
> > Op zaterdag 10 december 2011 14:06:18 schreef Kamil Rytarowski:
> >> W dniu 10.12.2011 13:45, Maarten Vanraes pisze:
> >>> Op zaterdag 10 december 2011 13:12:52 schreef Kamil Rytarowski:
> Hello!
>
> Situation:
> A package X may have support for a package Y, by a module as a build
> in X or stand-alone package. All modules are possible to turn-on and
> to turn-off in a menu of X.
>
> And there is a discussion because there is no Y at all in Mageia.
> Person A says:
> - include the module, even if there is no Y in Mageia (and maybe never
> will be included), because an end-user can install Y from alternative
> source or compile it from sources; and don't add Suggests/Requires for
> Y in the package, because it's obvious that this is to support Y;
> also installing Y from alternative sources/self-compilation is much
> simpler than reinstalling X with support for Y
> Person B says:
> - don't include the module, because Y is a dependency for the module
> of X - and we don't ship broken packages that aren't self-contained;
> so it must be excluded from X or the nobody has package Y and
> maintain it
>
> Neither A nor B want to work with Y package.
>
> Who is right?
> >>>
> >>> imho, if Y is wanted by some people, and X works more of less fine
> >>> without Y even if it's support is compiled, and sometimes a get-Y
> >>> package is fine.
> >>>
> >>> imho it's maintainer's preference, if maintainer is fine to also
> >>> "support the Y-module for X" even if depends on Y and Y is not allowed
> >>> in mageia, or even if Y is in nonfree... it's fine by me.
> >>
> >>> let's get into specifics:
> >> Well here there is no nonfree, demo, shareware, license issue. Just Y is
> >> yet another media-player. Importing Y is not a case for neiher A nor B.
> >> There is a question to include or not include a module (as an external
> >> package %{name}-module-mediaplayer_Y) for X. X is working perfectly
> >> without Y - Y is just adding some extra features. But the module for X
> >> is NOT working without Y. Well it's probably not breaking X, there will
> >> be an error message "error loading module-mediaplayer_Y".
> >
> > you could find a way to configure it as disabled?
>
> Yes
>
> > or move it to a subdir of sorts with a mention that if they do have Y
> > that
> >
> > they can put this file in the other dir.
> >
> > or... have a subpackage for this module and don't suggest it. plus have a
> > warning in it to say that it requires bla.
> >
> > so my vote is for A)
>
> I like the idea with URPMI warning at the install time, this would solve
> the problem. "If you need Y support for X, we include the module, but
> obtain Y at your own."
look at other packages, like mysql, they generate a README.install.urpmi file
which show this text in rpmdrake
Re: [Mageia-dev] Build-in or stand-alone module for X to support Y
W dniu 10.12.2011 14:11, Maarten Vanraes pisze:
Op zaterdag 10 december 2011 14:06:18 schreef Kamil Rytarowski:
W dniu 10.12.2011 13:45, Maarten Vanraes pisze:
Op zaterdag 10 december 2011 13:12:52 schreef Kamil Rytarowski:
Hello!
Situation:
A package X may have support for a package Y, by a module as a build in
X or stand-alone package. All modules are possible to turn-on and to
turn-off in a menu of X.
And there is a discussion because there is no Y at all in Mageia.
Person A says:
- include the module, even if there is no Y in Mageia (and maybe never
will be included), because an end-user can install Y from alternative
source or compile it from sources; and don't add Suggests/Requires for Y
in the package, because it's obvious that this is to support Y; also
installing Y from alternative sources/self-compilation is much simpler
than reinstalling X with support for Y
Person B says:
- don't include the module, because Y is a dependency for the module of
X - and we don't ship broken packages that aren't self-contained; so it
must be excluded from X or the nobody has package Y and maintain it
Neither A nor B want to work with Y package.
Who is right?
imho, if Y is wanted by some people, and X works more of less fine
without Y even if it's support is compiled, and sometimes a get-Y
package is fine.
imho it's maintainer's preference, if maintainer is fine to also "support
the Y-module for X" even if depends on Y and Y is not allowed in mageia,
or even if Y is in nonfree... it's fine by me.
let's get into specifics:
Well here there is no nonfree, demo, shareware, license issue. Just Y is
yet another media-player. Importing Y is not a case for neiher A nor B.
There is a question to include or not include a module (as an external
package %{name}-module-mediaplayer_Y) for X. X is working perfectly
without Y - Y is just adding some extra features. But the module for X
is NOT working without Y. Well it's probably not breaking X, there will
be an error message "error loading module-mediaplayer_Y".
you could find a way to configure it as disabled?
Yes
or move it to a subdir of sorts with a mention that if they do have Y that
they can put this file in the other dir.
or... have a subpackage for this module and don't suggest it. plus have a
warning in it to say that it requires bla.
so my vote is for A)
I like the idea with URPMI warning at the install time, this would solve
the problem. "If you need Y support for X, we include the module, but
obtain Y at your own."
[Mageia-dev] Where to report mageia 2 alpha 1 problems?
Hi list, I tested mageia 2 alpha 1 (KDE live CD) for the audio problem (bug 2437) and at the same time I found another two problems. Where can I report it? The wiki pages seem to be down for now. 1. When I launched Telepathy account manager I got an error message saying that, "Something went terribly wrong and the IM system could not be initialized. It is likely your system is missing Telepathy Mission Control package." So there is no telepathy mission control package in KDE live cd, is there? 2. If I turned "Screenshot" KDE desktop effect on, I still got problems getting screenshot with ksnapshot. It is an old problem in mageia 1. Please tell me where I can report these problem. I'll report it again to where it should go. Thanks, Franklin
Re: [Mageia-dev] Build-in or stand-alone module for X to support Y
Op zaterdag 10 december 2011 14:06:18 schreef Kamil Rytarowski:
> W dniu 10.12.2011 13:45, Maarten Vanraes pisze:
> > Op zaterdag 10 december 2011 13:12:52 schreef Kamil Rytarowski:
> >> Hello!
> >>
> >> Situation:
> >> A package X may have support for a package Y, by a module as a build in
> >> X or stand-alone package. All modules are possible to turn-on and to
> >> turn-off in a menu of X.
> >>
> >> And there is a discussion because there is no Y at all in Mageia.
> >> Person A says:
> >> - include the module, even if there is no Y in Mageia (and maybe never
> >> will be included), because an end-user can install Y from alternative
> >> source or compile it from sources; and don't add Suggests/Requires for Y
> >> in the package, because it's obvious that this is to support Y; also
> >> installing Y from alternative sources/self-compilation is much simpler
> >> than reinstalling X with support for Y
> >> Person B says:
> >> - don't include the module, because Y is a dependency for the module of
> >> X - and we don't ship broken packages that aren't self-contained; so it
> >> must be excluded from X or the nobody has package Y and maintain it
> >>
> >> Neither A nor B want to work with Y package.
> >>
> >> Who is right?
> >
> > imho, if Y is wanted by some people, and X works more of less fine
> > without Y even if it's support is compiled, and sometimes a get-Y
> > package is fine.
> >
> > imho it's maintainer's preference, if maintainer is fine to also "support
> > the Y-module for X" even if depends on Y and Y is not allowed in mageia,
> > or even if Y is in nonfree... it's fine by me.
>
> > let's get into specifics:
> Well here there is no nonfree, demo, shareware, license issue. Just Y is
> yet another media-player. Importing Y is not a case for neiher A nor B.
> There is a question to include or not include a module (as an external
> package %{name}-module-mediaplayer_Y) for X. X is working perfectly
> without Y - Y is just adding some extra features. But the module for X
> is NOT working without Y. Well it's probably not breaking X, there will
> be an error message "error loading module-mediaplayer_Y".
you could find a way to configure it as disabled?
or move it to a subdir of sorts with a mention that if they do have Y that
they can put this file in the other dir.
or... have a subpackage for this module and don't suggest it. plus have a
warning in it to say that it requires bla.
so my vote is for A)
Re: [Mageia-dev] Build-in or stand-alone module for X to support Y
W dniu 10.12.2011 13:45, Maarten Vanraes pisze:
Op zaterdag 10 december 2011 13:12:52 schreef Kamil Rytarowski:
Hello!
Situation:
A package X may have support for a package Y, by a module as a build in
X or stand-alone package. All modules are possible to turn-on and to
turn-off in a menu of X.
And there is a discussion because there is no Y at all in Mageia.
Person A says:
- include the module, even if there is no Y in Mageia (and maybe never
will be included), because an end-user can install Y from alternative
source or compile it from sources; and don't add Suggests/Requires for Y
in the package, because it's obvious that this is to support Y; also
installing Y from alternative sources/self-compilation is much simpler
than reinstalling X with support for Y
Person B says:
- don't include the module, because Y is a dependency for the module of
X - and we don't ship broken packages that aren't self-contained; so it
must be excluded from X or the nobody has package Y and maintain it
Neither A nor B want to work with Y package.
Who is right?
imho, if Y is wanted by some people, and X works more of less fine without Y
even if it's support is compiled, and sometimes a get-Y package is fine.
imho it's maintainer's preference, if maintainer is fine to also "support the
Y-module for X" even if depends on Y and Y is not allowed in mageia, or even
if Y is in nonfree... it's fine by me.
let's get into specifics:
Well here there is no nonfree, demo, shareware, license issue. Just Y is
yet another media-player. Importing Y is not a case for neiher A nor B.
There is a question to include or not include a module (as an external
package %{name}-module-mediaplayer_Y) for X. X is working perfectly
without Y - Y is just adding some extra features. But the module for X
is NOT working without Y. Well it's probably not breaking X, there will
be an error message "error loading module-mediaplayer_Y".
Re: [Mageia-dev] RFC: Opening Backports (once again...)
Op zaterdag 10 december 2011 12:32:12 schreef Michael Scherer: > Le mardi 06 décembre 2011 à 00:56 +0200, Thomas Backlund a écrit : > > Now, > > > > here comes the question about backports once again. > > > > We are now 6+ months into Mageia 1, and we are nowhere closer to opening > > backports that we were at Mageia 1 release time. > > > > Because of that there are 3rdparty repos popping up everywhere..., > > something we hoped to avoid atleast partly when starting this project. [...] > > And to be honest I dont see that changing anytime soon... > > Then we have a bigger problem to solve. This is likely correct, i think we have shortage of people in various parts, but perhaps sysadmin (which is arguably the most important team), has not enough active people to follow up all the issues (or they are busy with other teams). because other teams are counting on sysadmin team and even though it's all on svn, it's not that easy (i think; at least for me) to learn this system and put some patches for sysadmin to follow, perhaps sysadmin team should grow a bit more people. [...] > > Using a separate branch is also a cleaner way of providing > > backports, and makes it easy to separate changes needed only > > for Cauldron (or backports). > > Then in practice, that mean having a 2nd/3rd distribution ( because > there is a separate 2nd svn branch, and a 3rd one for later ) and so > that's a big no for me. Having 2+ branchs is just asking for trouble > when they are not in sync ( and since keeping everything in sync > properly with svn is a pain if there is a divergence, this will not be > done ). > > Worst, if we do like in mdv and propose 2 way of backporting ( submit > from cauldron, submit from a branch ), this will create a mess of having > some packages from cauldron, some from the branch, and people having no > way from knowing where does a package come from. This also make the > system harder to maintain and to follow, and rather impossible to script > properly. > > So that's also to be avoided. > > Having a separate branch where people can write also remove the only > incentive I have seen for backports, ie, wider testing of our packages, > because they may not really the same as in cauldron. I think there are more incentives than just that for backports, at least imho. plus, if the problem is you don't know where it's from, perhaps we should fix that problem instead of having an arguably less flexible solution. also, iirc, when branching svn, afaik it mentions where it's been branched from? > So here is what I propose : > > - have X branchs, but do not let anyone commit on it, besides a system > user. When a package is submitted to cauldron, it is also copied to this > branch, ie, we make sure current is in sync. The same goes for version > N-1 being copied from N once a backported rpm have been submitted to be > used by people. Once a distribution is no longer supported, we close the > branch, and disable the sync. > > - backports are only submitted from the branch, with separate > markrelease, tags, whatever. This let us have proper audit of backports, > and who did what. > > - packagers still need to commit and submit on cauldron before any > backports. So we miss no fixes or anything by mistake. We also make sure > that cauldron is always the highest version possible, thus permitting at > least some form of upgrade. ( either stable to stable, provided > backports are used, or stable to cauldron ). And we also ensure that > backports are done first on the most recent stable version, for the same > reason ( ensure some form of upgrade path, as asked several time by > users ). > > And we can still use %ifdef if a need arise for a different spec between > distribution versions. While that make spec less readable, that's more > readable than having forked specs 2 or 3 times. > > This requires : > > - 1 youri action to copy the package to current backport branch ( can be > done based on the markrelease action and the others ) > > - 1 svn configuration to prevent people from writing directly there ( or > just say to not do it, and burn people who do it ) > > - youri config to let people submit from backports to backports_testing. for me this solution would be ok, but iirc tmb requires for kernel a bit more flexibility? and tbh, having a more dirty spec file is not something i'd wish for... but, even if this is a nice solution, we still have the problem listed above that we'd get backports since before mageia1 and it's still not here? since it's also not the priority (updates are more important) what chances do we have of actually having backports before mga2?
Re: [Mageia-dev] Build-in or stand-alone module for X to support Y
Op zaterdag 10 december 2011 13:12:52 schreef Kamil Rytarowski: > Hello! > > Situation: > A package X may have support for a package Y, by a module as a build in > X or stand-alone package. All modules are possible to turn-on and to > turn-off in a menu of X. > > And there is a discussion because there is no Y at all in Mageia. > Person A says: > - include the module, even if there is no Y in Mageia (and maybe never > will be included), because an end-user can install Y from alternative > source or compile it from sources; and don't add Suggests/Requires for Y > in the package, because it's obvious that this is to support Y; also > installing Y from alternative sources/self-compilation is much simpler > than reinstalling X with support for Y > Person B says: > - don't include the module, because Y is a dependency for the module of > X - and we don't ship broken packages that aren't self-contained; so it > must be excluded from X or the nobody has package Y and maintain it > > Neither A nor B want to work with Y package. > > Who is right? imho, if Y is wanted by some people, and X works more of less fine without Y even if it's support is compiled, and sometimes a get-Y package is fine. imho it's maintainer's preference, if maintainer is fine to also "support the Y-module for X" even if depends on Y and Y is not allowed in mageia, or even if Y is in nonfree... it's fine by me. let's get into specifics: eg: X = eduke32 (free) Y = content from CDROM (non-redistributable and must be bought) Y' = eduke32-hrp (nonfree, but redistributable, may arguably depend on Y, may in future become free, company holding the license of the few files has gone away, the few files may be redone or become GPL-compatible) Y'' = demo-data (nonfree, but redistributable) (also there are other mods who may serve as Y''') Y' supposedly doens't work without Y; but maybe it does more or less Y'' is shareware what users want is usually X + Y' thus in such cases i want to provide X in core, Y' in nonfree and perhaps Y'' in nonfree as well. this may all seem complicated, but: businesses aren't necessarily wrong, i mean, they provide programs for windows/mac, if we want them to also provide for linux, we should make a step towards them. furthermore, any step towards opensource should be encouraged, thus i feel that "free engines" should still be free. i think a README.install.urpmi should be attached to those and noted that Y is required for it. furthermore Y' should be suggested, even if it's in nonfree repos. just my €0.02
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release drakconf-12.22.1-1.mga2
On 10 December 2011 13:11, Mageia Team wrote: > tv 12.22.1-1.mga2: > + Revision: 180273 > - rebuild with new ldetect-lst oops: bogus changelog: "further update Release Notes URL" Maybe should we push drakconf-12.22.1 as updates in order to have fixed entries in help menu now that have the proper entries in the wiki?
[Mageia-dev] Build-in or stand-alone module for X to support Y
Hello! Situation: A package X may have support for a package Y, by a module as a build in X or stand-alone package. All modules are possible to turn-on and to turn-off in a menu of X. And there is a discussion because there is no Y at all in Mageia. Person A says: - include the module, even if there is no Y in Mageia (and maybe never will be included), because an end-user can install Y from alternative source or compile it from sources; and don't add Suggests/Requires for Y in the package, because it's obvious that this is to support Y; also installing Y from alternative sources/self-compilation is much simpler than reinstalling X with support for Y Person B says: - don't include the module, because Y is a dependency for the module of X - and we don't ship broken packages that aren't self-contained; so it must be excluded from X or the nobody has package Y and maintain it Neither A nor B want to work with Y package. Who is right?
Re: [Mageia-dev] RFC: Opening Backports (once again...)
Le mardi 06 décembre 2011 à 00:56 +0200, Thomas Backlund a écrit :
> Now,
>
> here comes the question about backports once again.
>
> We are now 6+ months into Mageia 1, and we are nowhere closer to opening
> backports that we were at Mageia 1 release time.
>
> Because of that there are 3rdparty repos popping up everywhere...,
> something we hoped to avoid atleast partly when starting this project.
Well, the backport issue ( ie :
- no garantee of keep the distribution upgradable
- no security )
have also not been fixed, so that's rather unfair to
> And at current rate we will probably release Mageia "infinity"
> before backports is opened.
>
>
> It has been delayed because of needed infrastructure changes,
> something no-one have had time to do so far...
>
> I know there is "only some coding missing" and "someone should
> do it", buth truthfully there are only a few that knows the
> code used in the buildsystem enough to actually make it happend,
> and they are already othervise busy or overloaded...
> (this is no rant against them, as all here are using their
> personal free time to help out)
>
> And to be honest I dont see that changing anytime soon...
Then we have a bigger problem to solve.
> So here is a suggestion to get some value to our endusers:
>
> we add a backports branch on svn
>
> So packages for backports would use:
>
> svn.mageia.org/packages/backports/1//{current,pristine,releases}
>
> and allow that to be used for backports.
>
> Using a separate branch is also a cleaner way of providing
> backports, and makes it easy to separate changes needed only
> for Cauldron (or backports).
Then in practice, that mean having a 2nd/3rd distribution ( because
there is a separate 2nd svn branch, and a 3rd one for later ) and so
that's a big no for me. Having 2+ branchs is just asking for trouble
when they are not in sync ( and since keeping everything in sync
properly with svn is a pain if there is a divergence, this will not be
done ).
Worst, if we do like in mdv and propose 2 way of backporting ( submit
from cauldron, submit from a branch ), this will create a mess of having
some packages from cauldron, some from the branch, and people having no
way from knowing where does a package come from. This also make the
system harder to maintain and to follow, and rather impossible to script
properly.
So that's also to be avoided.
Having a separate branch where people can write also remove the only
incentive I have seen for backports, ie, wider testing of our packages,
because they may not really the same as in cauldron.
So here is what I propose :
- have X branchs, but do not let anyone commit on it, besides a system
user. When a package is submitted to cauldron, it is also copied to this
branch, ie, we make sure current is in sync. The same goes for version
N-1 being copied from N once a backported rpm have been submitted to be
used by people. Once a distribution is no longer supported, we close the
branch, and disable the sync.
- backports are only submitted from the branch, with separate
markrelease, tags, whatever. This let us have proper audit of backports,
and who did what.
- packagers still need to commit and submit on cauldron before any
backports. So we miss no fixes or anything by mistake. We also make sure
that cauldron is always the highest version possible, thus permitting at
least some form of upgrade. ( either stable to stable, provided
backports are used, or stable to cauldron ). And we also ensure that
backports are done first on the most recent stable version, for the same
reason ( ensure some form of upgrade path, as asked several time by
users ).
And we can still use %ifdef if a need arise for a different spec between
distribution versions. While that make spec less readable, that's more
readable than having forked specs 2 or 3 times.
This requires :
- 1 youri action to copy the package to current backport branch ( can be
done based on the markrelease action and the others )
- 1 svn configuration to prevent people from writing directly there ( or
just say to not do it, and burn people who do it )
- youri config to let people submit from backports to backports_testing.
--
Michael Scherer
Re: [Mageia-dev] Package adoption campaign, 3 months later
Le samedi 10 décembre 2011 11:14:38, Michael Scherer a écrit : > Le jeudi 08 décembre 2011 à 18:51 +0800, Funda Wang a écrit : > > I would suggest that registering nobody as a mailing list, so that > > every interested packagers could join to help. > > No. > > For the reasons already highlighted several time, this would not work. > That's the situation at mandriva, and we know well the problem it cause > ( aka, obscure communication, no one really in charge of a rpm, so not > one feeling responsible for bugs or anything ). > > Either a package is maintained and should be marked as such, or it is > not, and should be marked as such, with a unfortunate fate for him > sooner or later. > > The goal is not to align lots of unmaintained packages, but to have a > maintained distribution. People have been complaining for quality since > a lot of time, and that's the only way to have it. > If not, this end like Mandriva, people see and fill bugs, they are not > fixed, and no one care. This greatly undermine the confidence in the > distribution in the long run, and so while having maintainer is not a > magic solution, this is a important step in the right direction. > > A free-for-all pool is just a mess. You're explaining why having orphan packages is bad and it's hard to disagree, but I fail to see why such a mailing list for people who are ready to devote some time to orphan packages would make things worse. It's not because it's not the ideal solution that it's bad, is it? Samuel
Re: [Mageia-dev] RFC: Opening Backports (once again...)
Le mardi 06 décembre 2011 à 01:29 +0200, Anssi Hannula a écrit : > The biggest problem for me is that it is really difficult to test any > changes, one'd need a mockup of the whole buildsystem... and I don't > want to propose any patches blind :) 2 vm + setup of puppet should be able to fully replicate the configuration. Despites being seen as a hot skill ( http://siliconangle.com/blog/2011/10/31/puppet-and-hadoop-among-the-hottest-it-skills/ ), I am rather surprised that no one take the opportunity to learn it and to help. -- Michael Scherer
Re: [Mageia-dev] Package adoption campaign, 3 months later
Le jeudi 08 décembre 2011 à 18:51 +0800, Funda Wang a écrit : > 2011/12/8 Samuel Verschelde : > > His/her work would be the following: > > - identifiy (with bugsquad's help) the orphan packages that have lots of > > unresolved bugs or are severely outdated, > > - do the same for packages that have a maintainer but are in a similar > > situation, > > - try to find packagers or apprentices to take care of them. Not necessarily > > make them become maintainer, but at least solve users bugs. > > - try to find maintainers for orphan packages. > I would suggest that registering nobody as a mailing list, so that > every interested packagers could join to help. No. For the reasons already highlighted several time, this would not work. That's the situation at mandriva, and we know well the problem it cause ( aka, obscure communication, no one really in charge of a rpm, so not one feeling responsible for bugs or anything ). Either a package is maintained and should be marked as such, or it is not, and should be marked as such, with a unfortunate fate for him sooner or later. The goal is not to align lots of unmaintained packages, but to have a maintained distribution. People have been complaining for quality since a lot of time, and that's the only way to have it. If not, this end like Mandriva, people see and fill bugs, they are not fixed, and no one care. This greatly undermine the confidence in the distribution in the long run, and so while having maintainer is not a magic solution, this is a important step in the right direction. A free-for-all pool is just a mess. -- Michael Scherer
Re: [Mageia-dev] [2302] ide_cd_mod does not exist anymore (thanks aginies)
On Wed, Dec 7, 2011 at 11:41 AM, Thomas Backlund wrote: > root-odjjhxpcy38dnm+yrof...@public.gmane.org skrev 7.12.2011 12:35: > >> Revision >> 2302 >> Author >> ennael >> Date >> 2011-12-07 11:35:48 +0100 (Wed, 07 Dec 2011) >> >> >> Log Message >> >> ide_cd_mod does not exist anymore (thanks aginies) >> > > Oh yes it does! > > It's only in mdv they have disabled all ide drivers without thinking of > those where the pata drivers dont work... > > -- > Thomas > > should this be reverted then ?
