Re: [Mageia-dev] Freeze push: worldofpadman and worldofpadman-data
Hi, Please remove worldofpadman-1.6-4 from core/release, I mistakenly pushed it there instead of nonfree. Thanks. On Sat, Mar 2, 2013 at 7:16 PM, Olivier Blin mag...@blino.org wrote: Juan Luis Baptiste juan...@mageia.org writes: That's strange... I did a mgarepo sync with no errors, and if I run it now it doesn't try to upload the sources as they seem to be already uploaded: [mageia@dci-laptop worldofpadman-data]$ mgarepo sync [mageia@dci-laptop worldofpadman-data]$ But the sources don't seem to be recognized by svn: [mageia@dci-laptop SOURCES]$ ls README.install.urpmi sha1.lst wop-1.5-unified.zip wop-1.5.x-to-1.6-patch-unified.zip [mageia@dci-laptop SOURCES]$ svn status ? wop-1.5-unified.zip ? sha1.lst ? wop-1.5.x-to-1.6-patch-unified.zip How to fix this ? a svn add on those files ? You just have to svn add sha1.lst, the other files are binaries that should not be hosted on the svn repository. boklm: mgarepo sync should really do this automatically for us :-) -- Olivier Blin - blino -- Juancho
Re: [Mageia-dev] Freeze push: worldofpadman and worldofpadman-data
On Sat, Mar 2, 2013 at 7:40 AM, Guillaume Rousse guillomovi...@gmail.com wrote: error: command failed: ssh pkgsubmit.mageia.org /usr/local/bin/submit_package -t cauldron --define sid=673391e4-2d88-4d19-92dc-8960411f23ae -r 400681 svn+ssh://svn.mageia.org/svn/packages/cauldron/worldofpadman-data error: '/var/lib/schedbot/repsys/tmp/tmpVsTJ1M/SOURCES/sha1.lst' was not found That's strange... I did a mgarepo sync with no errors, and if I run it now it doesn't try to upload the sources as they seem to be already uploaded: [mageia@dci-laptop worldofpadman-data]$ mgarepo sync [mageia@dci-laptop worldofpadman-data]$ But the sources don't seem to be recognized by svn: [mageia@dci-laptop SOURCES]$ ls README.install.urpmi sha1.lst wop-1.5-unified.zip wop-1.5.x-to-1.6-patch-unified.zip [mageia@dci-laptop SOURCES]$ svn status ? wop-1.5-unified.zip ? sha1.lst ? wop-1.5.x-to-1.6-patch-unified.zip How to fix this ? a svn add on those files ? -- Juancho
Re: [Mageia-dev] Freeze push: worldofpadman and worldofpadman-data
On Sat, Mar 2, 2013 at 10:57 AM, nicolas vigier bo...@mars-attacks.org wrote: That's strange... I did a mgarepo sync with no errors, and if I run it now it doesn't try to upload the sources as they seem to be already uploaded: mgarepo sync will update the sha1.lst file but will not commit it. Fixed but I did commit after doing the sync, so I don't get why sha1.lst wasn't uploaded... -- Juancho
Re: [Mageia-dev] Freeze push: worldofpadman and worldofpadman-data
On Feb 28, 2013 4:25 PM, Juan Luis Baptiste juan...@mageia.org wrote: Hi, According to what was discussed some days ago about this game[1], I modified worldofpadman package to package the original World of Padman engine, and packaged the data files in worldofpadman-data. As now we're including the data files which aren't completely free software, both packages need to go into nonfree. This means that the current package worldofpadman package on core/release needs to be removed from that repo before someone pushes worldofpadman-1.6-3 and worldofpadman-data-1.6-1 to nonfree. Thanks !! [1] http://article.gmane.org/gmane.linux.mageia.devel/22918 -- Juancho Ping?
[Mageia-dev] Freeze push: worldofpadman and worldofpadman-data
Hi, According to what was discussed some days ago about this game[1], I modified worldofpadman package to package the original World of Padman engine, and packaged the data files in worldofpadman-data. As now we're including the data files which aren't completely free software, both packages need to go into nonfree. This means that the current package worldofpadman package on core/release needs to be removed from that repo before someone pushes worldofpadman-1.6-3 and worldofpadman-data-1.6-1 to nonfree. Thanks !! [1] http://article.gmane.org/gmane.linux.mageia.devel/22918 -- Juancho
[Mageia-dev] About bug 6676
Hi, There's this bug about world of padman: https://bugs.mageia.org/show_bug.cgi?id=6676 The problem has to do with the use of the ioquake3 binary instead of WoP own binary. I wrote to the game devs and they basically said that using the official ioquake3 binary isn't supported and I should use the WoP binary instead. So I propose to package the whole game and put it in non-free instead of how it is currently packaged, which is using ioquake3 engine and an autodownloader to download and setup the game data files. WDYT ? -- Juancho
Re: [Mageia-dev] About bug 6676
On Wed, Feb 20, 2013 at 5:11 PM, zezinho lists.jjo...@free.fr wrote: http://wiki.debian.org/Games/Suggested#World_of_Padman says that game engine is open-source, so it should not go to non-free! Yeah but AFAIK the game data isn't free, that's why fedora doesn't include it and uses the autodownloader (I'll double check this) . Anyway, that's not the point here. :) it's more if everyone is okay on including the game complete wether it's on core or non free, instead of reusing the ioq3 engine. -- Juancho
[Mageia-dev] Freeze push: httping
Please push httping which fixes one bug: 1.5.7 fix a NULL pointer segfault that occures when a time-out happens (thanks to Tomas Psika) Oden had updated it like a month ago, but I'm not sure why he didn't ask for the push. -- Juancho
[Mageia-dev] Freeze push: cantata 0.9.2
Bugfix release. -- Juancho
[Mageia-dev] Freeze push: mangler 1.2.5
Bugfix release. -- Juancho
[Mageia-dev] Freeze push: sauerbraten
Hi, Please push Sauerbraten, another bugfix only release: * Fixes crash with server console on Windows * Fixes crash with demo recording Thanks. -- Juancho
Re: [Mageia-dev] Freeze push: Sauerbraten
On Tue, Jan 22, 2013 at 12:07 PM, Juan Luis Baptiste juan...@mageia.org wrote: Please push again, new bugfix only release, 2013_01_20, fixes the following stuff: * server teamkillkick bugs * server map rotation bugs * missing map rotation for SP maps * map sounds playing after disconnect * random sounds playing if someone else has a modified map * ragdolls not re-created properly while spectating someone Ping ? -- Juancho
Re: [Mageia-dev] Freeze push: Sauerbraten
On Wed, Jan 23, 2013 at 12:31 PM, Juan Luis Baptiste juan...@mageia.org wrote: On Tue, Jan 22, 2013 at 12:07 PM, Juan Luis Baptiste juan...@mageia.org wrote: Please push again, new bugfix only release, 2013_01_20, fixes the following stuff: * server teamkillkick bugs * server map rotation bugs * missing map rotation for SP maps * map sounds playing after disconnect * random sounds playing if someone else has a modified map * ragdolls not re-created properly while spectating someone Ping ? Pong ? -- Juancho
Re: [Mageia-dev] Freeze push: Sauerbraten
Please push again, new bugfix only release, 2013_01_20, fixes the following stuff: * server teamkillkick bugs * server map rotation bugs * missing map rotation for SP maps * map sounds playing after disconnect * random sounds playing if someone else has a modified map * ragdolls not re-created properly while spectating someone On Sun, Jan 20, 2013 at 1:09 PM, Thomas Backlund t...@mageia.org wrote: Juan Luis Baptiste skrev 20.1.2013 20:04: On Fri, Jan 18, 2013 at 4:20 PM, Juan Luis Baptiste juan...@mageia.org wrote: It's a bugfix only release: Ping ? Submitted. -- Thomas -- Juancho
Re: [Mageia-dev] What's the point of the latest nvidia update?
On Sun, Jan 20, 2013 at 11:30 AM, Robert Wood robert.w...@apostrophe.co.uk wrote: Thanks for the reply, but it doesn't really make sense or seem to answer the question. I was wondering why bother with v295 when you could go for a more recent (ie most up to date) release?! Because of our updates policy: For the most part, an update should consist of a patched build of the same version of the package released with the distribution, with a few exceptions: - Bug fix only release. There is no point in shipping all the fixes as patches if the new version does not contain any new feature. - Software versions that are no longer supported upstream with updates (firefox and thunderbird seem to fall into this category these days) - Software that is version-bound to an online service (games, virus scanners?) and will only work with the latest version. We will make exceptions for packages that did not make it into mga1 and are additions to the distribution, provided they do not impact any other packages and can pass full QA. Updates are not the appropriate place for packages created to satisfy certain user's urges for the latest. These types of builds belong in backports. https://wiki.mageia.org/en/Updates_policy#Version_Policy New releases only go on next verson or in backports (once they're open). P.S.: Please don't top post next time. -- Juancho
Re: [Mageia-dev] Freeze push: Sauerbraten
On Fri, Jan 18, 2013 at 4:20 PM, Juan Luis Baptiste juan...@mageia.org wrote: It's a bugfix only release: Ping ? -- Juancho
Re: [Mageia-dev] What's the point of the latest nvidia update?
On Sat, Jan 19, 2013 at 9:44 AM, AL13N al...@rmail.be wrote: if for mga2 you want a newer driver you should ask for a backport request, ie: to have 310 on mga2 as well. plz file such requests at https://bugs.mageia.org/ This means that backports at last are opened ?? -- Juancho
[Mageia-dev] Freeze push: Sauerbraten
It's a bugfix only release: * fix build issues with clang * fix building of master server * add teamcolortext/teamcolorfrags vars for disabling team-colored game and frag messages if desired * workaround for minimap not showing properly if the map changes while the game is minimized * adjusted server browser columns width to avoid twitching * fix ctftkpenalty not working * fix issues with the @ character appearing in names * fix blob shadows showing on the underside of geometry * fix kickbans not banning * fix clip/waypoint bugs in damnation * fix clip on phosgene and nucleus * fix map credits in eternal_valley * fix noclip causing shadows * bump score limit in collect modes to 50 * fix spawnwait handling in server * fix ctf map listing * include missing server-init.cfg -- Juancho
Re: [Mageia-dev] web virtual management solution
On Wed, Jan 9, 2013 at 3:23 AM, Guillaume Rousse guillomovi...@gmail.comwrote: version freeze only prevent you to update an existing package, not to introduce a new one. Ah I didn't knew this, thanks !! For new packages, when would be the deadline ? -- Juancho
Re: [Mageia-dev] Help with package
On Sat, Jan 5, 2013 at 2:02 AM, Juan Luis Baptiste juan...@mageia.orgwrote:
Got it working with:
for i in `%{_datadir}/warsow/basewsw/*`;
do
file=`basename $i`
ln -sf $i %{gamelibdir}/basewsw/$file
done
The game name in the for loop was wrong.
Well, it worked on x86_64, but on i586 the symlinks are created under
/usr/lib64/games/warsow/basewsw instead of /usr/lib/games/warsow/basewsw
but I don't understand why, it seems that for some reason, the %{_libdir}
macro is expanding to /usr/lib64 on the BS. This is the spec if someone
wants to take a look:
http://svnweb.mageia.org/packages/cauldron/warsow-data/current/SPECS/warsow-data.spec?revision=338836view=markup
--
Juancho
Re: [Mageia-dev] ANN: glibc-2.17 landing on cauldron...
On Tue, Jan 1, 2013 at 2:44 PM, Thomas Backlund t...@mageia.org wrote: And glibc-2.17-1 and locales-2.17-1 are now built and should soon show up on the mirrors and it should be safe to update then... And now on one of my cauldron boxes I can't update glibc, thus blocking the rest of updates: The following package has to be removed for others to be upgraded: glibc-2.17-1.mga3.x86_64 (in order to install glibc-2.17-1.mga3.x86_64) installing glibc-devel-2.17-1.mga3.x86_64.rpm meta-task-3-22.mga3.noarch.rpm rpm-build-4.11.0-0.beta1.7.mga3.x86_64.rpm lib64rpm3-4.11.0-0.beta1.7.mga3.x86_64.rpm rpm-4.11.0-0.beta1.7.mga3.x86_64.rpm python-rpm-4.11.0-0.beta1.7.mga3.x86_64.rpm glibc-2.17-1.mga3.x86_64.rpm from /var/cache/urpmi/rpms Preparing... ### Installation failed:package glibc-6:2.17-1.mga3.x86_64 is already installed -- Juancho
Re: [Mageia-dev] outdated packages missed by youri
On Sun, Jan 6, 2013 at 5:04 PM, David Walser luigiwal...@yahoo.com wrote: In honor of the upcoming version freeze in Cauldron (this week according to current planning), I went looking for packages with newer versions available, that are NOT seen by our youri tool, and therefore will not be seen here: http://check.mageia.org/cauldron/updates.html Because of that, some of you may be interested in some of these packages and be unaware that newer versions are available. I compiled the list over the past two days, and queried the Sophie bot for the maintainers, so they're listed below by the IRC log. Sorry if you're on IRC and got pinged 50 times this weekend :o) Done mines, thanks for the info :) -- Juancho
Re: [Mageia-dev] ANN: glibc-2.17 landing on cauldron...
On Mon, Jan 7, 2013 at 9:22 AM, Thomas Spuhler tho...@btspuhler.com wrote: Try to do a urpmi --replacepkgs glibc I had some of these when I upgrade an old mga2 install. It did the trick. That did the trick, although when doing it remotely through an ssh connection, the connection was closed and the installation can't finish. Fortunately it's a vbox vm which I have rdp access so I was able to run that command locally. This ssh closed connection issue I have seen it since a long time, is there any way to avoid it ? it sometimes breaks the update process of that remote vm. -- Juancho
Re: [Mageia-dev] Help with package
Hi Colin,
On Mon, Jan 7, 2013 at 5:53 AM, Colin Guthrie mag...@colin.guthr.ie wrote:
Well, it worked on x86_64, but on i586 the symlinks are created under
/usr/lib64/games/warsow/basewsw instead of /usr/lib/games/warsow/basewsw
but I don't understand why, it seems that for some reason, the
%{_libdir} macro is expanding to /usr/lib64 on the BS. This is the spec
if someone wants to take a look:
http://svnweb.mageia.org/packages/cauldron/warsow-data/current/SPECS/warsow-data.spec?revision=338836view=markup
%_libdir expands to the given architecture's libdir. On i586 it's
/usr/lib, on x86_64 it's /usr/lib64.
I know, that's why it's strange to me why when the package is built on the
BS the links end up on /usr/lib64 on the i586 package.
Looking at the spec, I think you're doing it a bit wrong.
It's in the %post for a start which is wrong. It should be done as part
of package build, not install. Doing it during install will mean the
files are not owned by the package so users cannot tell where they
come from.
Well, that was just a suggestion from someone on this thread and it looked
to me like the right place too. On this particular case what I'm doing here
is not installing some files but creating some symlinks that the other
warsow package needs.
Also as you use %_libdir, your package cannot be noarch.
The warsow-data package contains the data files of the game which are
arch independent. The warsow package contains all the binaries and libs,
but to be able to run the game, the binary expects to find the data files
on the same directory where the libs are, if not then the angelscript
module will fail loading. So, what I'm trying to accomplish is that when
warsow-data is installed, symlinks of the files in the data directory
(/usr/share/warsow/basewsw/*) are created on
/usr/lib{64}/games/warsow/basewsw/. It works on x86_64 but on i586 is
creating the links on lib64 instead of lib and I don't get why, you saw the
code in the spec, I'm not hardcoding any path on it:
%define gamelibdir %{_libdir}/games/warsow
%post
#Add symbolic links of the contents of basewsw to the directory were the
#package warsow install the libs, if not then angelscript fails to load.
for i in %{_datadir}/warsow/basewsw/*;
do
file=`basename $i`
ln -sf $i %{gamelibdir}/basewsw/$file
done
%postun
rm -rf %{gamelibdir}/basewsw
If you want to use /usr/lib all the time then do so (if that's what the
game binary expects) via %{_prefix}/lib not via %_libdir.
That's not the case, as explained before, the symlinks have to be created
at /usr/lib for i586 and at /usr/lib64 for x86_64, but on i586 for some
reason isn't doing it.
Also your fdupes command seems to do nothing other than display
duplicate information, not actually resolve anything. So I'd just remove
it or add appropriate arguments to do hardlinking as needed. Unless this
package has a particular problem with duplicated data, then I'd just
kill it off completely.
I'll check this too.
Hope that gives you some hints.
Thanks for the comments.
--
Juancho
Re: [Mageia-dev] ANN: glibc-2.17 landing on cauldron...
On Mon, Jan 7, 2013 at 2:37 PM, Thomas Backlund t...@mageia.org wrote: This ssh closed connection issue I have seen it since a long time, is there any way to avoid it ? it sometimes breaks the update process of that remote vm. https://wiki.mageia.org/en/**Mageia_2_Errata#SSH_daemon_**issueshttps://wiki.mageia.org/en/Mageia_2_Errata#SSH_daemon_issues Thanks for the link but I have UsePAM=no commented on /et/ssh/sshd_config, I suppose that's the default sshd configuration, I have never touched that file on that machine. -- Juancho
Re: [Mageia-dev] ANN: glibc-2.17 landing on cauldron...
On Mon, Jan 7, 2013 at 5:15 PM, Sander Lepik sander.le...@eesti.ee wrote: 07.01.2013 21:19, Juan Luis Baptiste kirjutas: This ssh closed connection issue I have seen it since a long time, is there any way to avoid it ? it sometimes breaks the update process of that remote vm. If i'm afraid that something might blow my connection during update then i use screen. It might drop me out but update will continue and usually quite soon i'm able to reconnect. I use screen too and the problem is that the user session is finished, so the screen process is finished too. -- Juancho
Re: [Mageia-dev] Help with package
On Fri, Jan 4, 2013 at 7:11 AM, sardine sardine...@sfr.fr wrote:
Hi,
This should work :
pushd %{buildroot}%{_datadir}/%{name}/basewsw
for i in *;
do
file=`basename $i`
ln -sf %{_datadir}/%{name}/basewsw/$i
%{buildroot}%{gamelibdir}/basewsw/$file
done
popd
Got it working with:
for i in `%{_datadir}/warsow/basewsw/*`;
do
file=`basename $i`
ln -sf $i %{gamelibdir}/basewsw/$file
done
The game name in the for loop was wrong.
Cheers,
--
Juancho
[Mageia-dev] Help with package
Hi,
I'm having a strange problem with warsow's package. To fix bug #8103 I need
to symlink the game data contents from warsow-data into the same directory
were the game libraries are located. The problem is that when I build the
package in my local cauldron installation, the symlinks are correctly
created, but when it's built by the BS they end up broken. I have tried two
ways to create the symlinks, both work fine on my machine but not on the BS:
ln -sf %{_datadir}/%{name}/basewsw/* %{buildroot}%{gamelibdir}/basewsw
or:
for i in %{_datadir}/%{name}/basewsw/*;
do
file=`basename $i`
ln -sf $i %{buildroot}%{gamelibdir}/basewsw/$file
done
With any of those two ways in my machine the symlinks are correctly created:
[root@cauldron-laptop cauldron]# ll /usr/lib64/games/warsow/basewsw/
total 28
lrwxrwxrwx 1 root root 47 Jan 3 16:42 configs -
../../../../../usr/share/warsow/basewsw/configs/
lrwxrwxrwx 1 root root 52 Jan 3 16:42 data0_10.pk3 -
../../../../../usr/share/warsow/basewsw/data0_10.pk3
lrwxrwxrwx 1 root root 56 Jan 3 16:42 data0_10pure.pk3 -
../../../../../usr/share/warsow/basewsw/data0_10pure.pk3
lrwxrwxrwx 1 root root 52 Jan 3 16:42 data1_10.pk3 -
../../../../../usr/share/warsow/basewsw/data1_10.pk3
[...]
But on the BS this is the result:
[root@localhost juancho]# ls -l /usr/lib64/games/warsow/basewsw/
total 0
lrwxrwxrwx 1 root root 41 Jan 3 11:13 * -
../../../../../usr/share/warsow/basewsw/*
A broken link to '*'. What can be causing this ?
Thanks.
--
Juancho
Re: [Mageia-dev] Help with package
On Thu, Jan 3, 2013 at 5:23 PM, David Walser luigiwal...@yahoo.com wrote:
for i in %{_datadir}/%{name}/basewsw/*;
do
file=`basename $i`
ln -sf $i %{buildroot}%{gamelibdir}/basewsw/$file
done
Looks better, that should make relative links.
The problem is in the first line, the %{_datadir}/%{name}/basewsw/*
should have a %{buildroot} at the beginning of it. Otherwise, it's
matching
against files on your actual system already installed at that location,
which of course won't be there on the build system. That's why the *
doesn't
match anything, and becomes a literal *.
I had tried that before, but on that case, on my local build the symlinks
are created like this:
ll /usr/lib64/games/warsow/basewsw/
total 4
lrwxrwxrwx 1 root root 114 Jan 3 18:01 * -
../../../../../home/cauldron/mageia/cauldron/warsow/BUILDROOT/warsow-1.02-5.mga3.x86_64/usr/share/warsow/basewsw/*
--
Juancho
Re: [Mageia-dev] Help with package
On Thu, Jan 3, 2013 at 6:10 PM, Charles A Edwards c...@eslrahc.com wrote:.
Why not have it created in post by the warsow-data rpm?
%post
ln -sf %{_datadir}/warsow/basewsw/* %{gamelibdir}/basewsw
%postun
rm -rf %{gamelibdir}/basewsw
Good idea, going to try this.
--
Juancho
Re: [Mageia-dev] Help with package
On Thu, Jan 3, 2013 at 6:22 PM, Juan Luis Baptiste juan...@mageia.orgwrote:
On Thu, Jan 3, 2013 at 6:10 PM, Charles A Edwards c...@eslrahc.comwrote:.
Why not have it created in post by the warsow-data rpm?
%post
ln -sf %{_datadir}/warsow/basewsw/* %{gamelibdir}/basewsw
%postun
rm -rf %{gamelibdir}/basewsw
Good idea, going to try this.
Nope it didn't work either, with Charle's suggestion I get this error:
ln: target ‘/usr/lib64/games/warsow/basewsw/’ is not a directory: No such
file or directory
Which I don't understand why it says no such file or directory if that's
the link I want to create. And /usr/lib64/games/warsow exists. I also tried
the for loop option with no success either:
for i in `%{_datadir}/%{name}/basewsw/*`;
do
file=`basename $i`
ln -sf $i %{gamelibdir}/basewsw/$file
done
/var/tmp/rpm-tmp.HdlyUk: line 7: /usr/share/warsow-data/basewsw/*: No such
file or directory
It seems as if the expression `%{_datadir}/%{name}/basewsw/*` (don't mind
the left quotes, it happens the same with them or not) of the for loop
wasn't being expanded and $i ends with the literal value '*'.
Any other suggestions ?
--
Juancho
Re: [Mageia-dev] Question about mysql-workbench documentation license
On Tue, Nov 20, 2012 at 12:54 AM, andre999 andre999...@laposte.net wrote: An alternate approach would be to package and distribute the documentation separately (as nonfree). Oracle permits this as long as it is only available on the same media or sites as mysql-workbench -- which concurs with our current practices. Then the mysql-workbench package itself would still be GPL. So I'd go for the second option. Maybe adding a comment in the mysql-workbench description indicating that due to licensing restrictions, the documentation is available in non-free. Ok but a adding a Suggest to mysql-workbench for the documentation would be ok ? -- Juancho
Re: [Mageia-dev] Question about mysql-workbench documentation license
On Tue, Nov 20, 2012 at 11:20 PM, Juan Luis Baptiste juan...@mageia.orgwrote: On Tue, Nov 20, 2012 at 12:54 AM, andre999 andre999...@laposte.netwrote: An alternate approach would be to package and distribute the documentation separately (as nonfree). Oracle permits this as long as it is only available on the same media or sites as mysql-workbench -- which concurs with our current practices. Then the mysql-workbench package itself would still be GPL. So I'd go for the second option. Maybe adding a comment in the mysql-workbench description indicating that due to licensing restrictions, the documentation is available in non-free. Giving it a second thought, I think this isn't a good idea because if I split the documentation into a separate package that would mean that I would need to have mysql-workbench sources also in the documentation package to be able to build it. And looking more closely at the Fedora patch, they remove the documentation but patch the program to open the online version of the documentation. IMO, if we can't include the doc in the same mysql-workbench package then the online approach is better. -- Juancho
[Mageia-dev] Question about mysql-workbench documentation license
Hi, In Fedora the bundled documentation of mysql-workbench has been removed because it isn't distributed under a GPL license. However, according to this parte of the license, it seems that it can be distributed if it's distributed along with mysql-workbench: -- This documentation is NOT distributed under a GPL license. Use of this documentation is subject to the following terms: You may create a printed copy of this documentation solely for your own personal use. Conversion to other formats is allowed as long as the actual content is not altered or edited in any way. You shall not publish or distribute this documentation in any form or on any media, except if you distribute the documentation in a manner similar to how Oracle disseminates it (that is, electronically for download on a Web site with the software) or on a CD-ROM or similar medium, provided however that the documentation is disseminated together with the software on the same medium. Any other use, such as any dissemination of printed copies or use of this documentation, in whole or in part, in another publication, requires the prior written consent from an authorized representative of Oracle. Oracle and/or its affiliates reserve any and all rights to this documentation not expressly granted above. -- My interpretation is that even if it isn't GPL'd we can distribute it if it's bundled with mysql-workbench. Is this correct ? if not then I'll apply the patch form Fedora to remove it too. Cheers, -- Juancho
Re: [Mageia-dev] Question about mysql-workbench documentation license
Ooops forgot to put the link from where the licence comes from: http://dev.mysql.com/doc/workbench/en/wb-preface.html On Mon, Nov 19, 2012 at 9:41 PM, Juan Luis Baptiste juan...@mageia.orgwrote: Hi, In Fedora the bundled documentation of mysql-workbench has been removed because it isn't distributed under a GPL license. However, according to this parte of the license, it seems that it can be distributed if it's distributed along with mysql-workbench: -- This documentation is NOT distributed under a GPL license. Use of this documentation is subject to the following terms: You may create a printed copy of this documentation solely for your own personal use. Conversion to other formats is allowed as long as the actual content is not altered or edited in any way. You shall not publish or distribute this documentation in any form or on any media, except if you distribute the documentation in a manner similar to how Oracle disseminates it (that is, electronically for download on a Web site with the software) or on a CD-ROM or similar medium, provided however that the documentation is disseminated together with the software on the same medium. Any other use, such as any dissemination of printed copies or use of this documentation, in whole or in part, in another publication, requires the prior written consent from an authorized representative of Oracle. Oracle and/or its affiliates reserve any and all rights to this documentation not expressly granted above. -- My interpretation is that even if it isn't GPL'd we can distribute it if it's bundled with mysql-workbench. Is this correct ? if not then I'll apply the patch form Fedora to remove it too. Cheers, -- Juancho -- Juancho
[Mageia-dev] Remove mysql-workbench packages from core/updates_testing
Hi, Can please an admin remove from core/updates_testing the following mysql-workbench packages ? I forgot to add the %subrel and incremented the %mkrel instead: source rpm: mysql-workbench-5.2.36-3.mga2.src.rpm binary rpms: mysql-workbench-5.2.36-3.mga2.x86_64.rpm mysql-utilities-1.0.0-0.5.2.36.2.mga2.noarch.rpm mysql-workbench-debug-5.2.36-3.mga2.x86_64.rpm Thanks. -- Juancho
Re: [Mageia-dev] Remove mysql-workbench packages from core/updates_testing
On Thu, Nov 8, 2012 at 7:02 PM, Colin Guthrie mag...@colin.guthr.ie wrote: Done. Thanks Col :) -- Juancho
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release synkron-1.6.2-1.mga3
On Mon, Nov 5, 2012 at 4:02 PM, Damien Lallement mag...@damsweb.net wrote: Le 05/11/2012 21:59, juancho a écrit : Synkron is a cross-platform application and runs on Mac OS X, Linux and Windows. Synkron is distributed under the terms of the GPL v2 licence. I think this is useless in %description. :-) Fixed. -- Juancho
Re: [Mageia-dev] Welcome Götz!
On Mon, Oct 22, 2012 at 4:15 PM, Olivier Blin mag...@blino.org wrote: Hi, After uncountable years as a packager and maintainer in the Mandriva Linux distribution, providing a huge number of impeccable contributions, Götz Waschk is now joining us as a Mageia packager. Please welcome him aboard! Welcome !! Cheers, -- JLB
Re: [Mageia-dev] iDevices support (was Re: [changelog] [RPM] cauldron core/release libimobiledevice-1.1.4-2.mga3)
On Tue, Oct 9, 2012 at 5:24 PM, Olivier Blin mag...@blino.org wrote: But in a default install, it still won't be recognized in nautilus, because we don't install gvfs-iphone by default. Is this something that we can suggest in libimobiledevice or nautilus? We already pull a bunch of libimobiledevice things anyway (thanks upower, er?!...), and having iDevices working out of the box is probably something that is expected by end-users. This is more a question for mikala but, how is currently the support for iDevices in cauldron's KDE ? (I don't have a local cauldron install or VM ATM to test). -- Juancho
Re: [Mageia-dev] Final set of isos for Mageia 3
On Tue, Oct 2, 2012 at 10:58 AM, Anne Nicolas enna...@gmail.com wrote: 2 liveCDs: - GNOME 700M i586 - english only - Nonfree - KDE 700M i586 - english only - Nonfree These are mainly targetted for distribution during events or for Newspapers What about having an option in the installer to download and install additional languages (don't know if this is already possible) ? -- Juancho
Re: [Mageia-dev] Looking for a mentor
Hi, On Sun, Sep 16, 2012 at 2:32 PM, Anne Nicolas enna...@gmail.com wrote: Please welcome him and raise hand to mentor him :) Welcome !! I can take him if there's no one else waiting for a mentor before him. -- Juancho
Re: [Mageia-dev] Update of the rpm group policy
On Sat, Sep 8, 2012 at 8:58 PM, Johnny A. Solbu coo...@solbu.net wrote: On Saturday 08 September 2012 20:07, Pierre-Malo Deniélou wrote: * Games/First Person Shooters (or simply Games/Shoot) Why not simply Games/Action ? That will also include all kinds of action games, both shooters and none shooters alike. Well then in that case put them all in Games/Other that already exist and that's it. The idea is to be able to find First Person Shooter like games, and we have already a lot of them (10+), IMO they deserve their own category. -- Juancho
Re: [Mageia-dev] Update of the rpm group policy
On Fri, Sep 7, 2012 at 7:13 PM, Pierre-Malo Deniélou pierre-malo.denie...@rhul.ac.uk wrote: If you agree, I will amend our http://wiki.mageia.org/en/RPM_groups_policy with these two changes and get in touch with the appropriate packagers/maintainers to do the group change (which is a trivial spec change). Could you also add a group Games/First Person Shooters ? currently that kind of games are on Games/Arcade, and they aren't really arcade. Thanks. -- Juancho
Re: [Mageia-dev] Package removal proposal
On Tue, Aug 21, 2012 at 2:20 AM, Guillaume Rousse guillomovi...@gmail.com wrote: We're working on these two packages with one of my apprentices, so there's no need to drop them. So just take over maintainership. we're working on it is not a clear status. Done. -- Juancho
Re: [Mageia-dev] Package removal proposal
On Mon, Aug 20, 2012 at 3:17 PM, Guillaume Rousse guillomovi...@gmail.com wrote: Le 20/08/2012 21:20, Damien Lallement a écrit : - ocsinventory-server and ocsinventory-agent: unmaintained, several pending security updates, better alternatives available (glpi + fusioninventory-agent) Noo, I'm using it for a customer of my company. I think that it's hard to remove this package as glpi/funsioninventory are better alternatives, sure, but not compatible with ocsinventory-*. So, for me, it's not an alternative but an other solution. Meaning you're volonteering for maintainership ? We're working on these two packages with one of my apprentices, so there's no need to drop them. Cheers, -- Juancho
Re: [Mageia-dev] File location in mono packages
On Sat, Aug 11, 2012 at 2:43 PM, Nicolas Lécureuil
nicolas.lecure...@free.fr wrote:
Hi,
%{_prefix}/lib is the correct path ( i looked on kimono spec file to confirm
)
Yeah, I looked at several mono packages and all of them do it like
that, regarless that rpmlint doesn't like it.
--
Juancho
[Mageia-dev] Welcome new packager: vaci0
Hi, I'm proud to announce that Cesar Vargas (vaci0), one of blogdrake's packagers just got submit rights and will be leaving the padawan ranks to become another jedi :D Please welcome to the Mageia packaging team !! Cheers, -- Juancho
Re: [Mageia-dev] [Mageia-artwork] Mageia 2 beta 3 available for tests
On Wed, Apr 18, 2012 at 4:43 PM, tumbeliina tumbeli...@yahoo.com wrote: I tried download http://www.mageia.org/en/downloads/get/?q=Mageia-2-beta3-LiveCD-KDE4-Europe2-i586-CD.isotorrent=1 I got only faliled to change direcototry etc :( That's because that's an old link for beta release, Mageia 2 final was released on May 22. You can get the final version from: http://www.mageia.org/en/downloads/ -- Juancho
Re: [Mageia-dev] Remove packages
Thanks. On Jun 6, 2012 10:19 AM, nicolas vigier bo...@mars-attacks.org wrote: On Tue, 05 Jun 2012, Juan Luis Baptiste wrote: Hi, Can someone please remove the following packages ? I had a typo in the lib name and they where created with the wrong name (already fixed and resubmitted): lib64chromapaint0-0.6-1.mga3.x86_64.rpm lib64chromapaint0-devel-0.6-1.mga3.x86_64.rpm Ok, removed.
[Mageia-dev] Remove packages
Hi, Can someone please remove the following packages ? I had a typo in the lib name and they where created with the wrong name (already fixed and resubmitted): lib64chromapaint0-0.6-1.mga3.x86_64.rpm lib64chromapaint0-devel-0.6-1.mga3.x86_64.rpm Thanks -- Juancho
Re: [Mageia-dev] remove moonlight
On Sun, Jun 3, 2012 at 4:28 PM, D.Morgan dmorga...@gmail.com wrote: hi, i read that moonlight is discontinued now. Do we still keep it or drop it ? as it seems that most of the websites doesn't work with our moonlight ( too old ) Where did you read that ? -- Juancho
Re: [Mageia-dev] Mageia 2 final release is out
On Wed, May 23, 2012 at 12:45 AM, zezinho lists.jjo...@free.fr wrote: Em 22-05-2012 22:39, Anne Nicolas escreveu: Looks like i18n was broken : french download page is in english, the same for portuguese http://www.mageia.org/fr/downloads/ The same for spanish with main page, about, downloads, support and community. -- Juancho
Re: [Mageia-dev] RFT: x11-driver-video-intel-2.19.0-1.mga2
On Wed, May 2, 2012 at 5:00 AM, Thomas Backlund t...@mageia.org wrote: Hi, There is finally a new x11 driver for Intel that I'd like to have for Mageia 2 final as it brings important fixes especially for Sandy Ivy bridge. And to quote upstream release manager: More stability fixes for UXA and support for another variant of IvyBridge. Given the severity of the stability fixes, I strongly recommend everybody to upgrade to 2.19.0. Full changelog here: http://lists.x.org/archives/xorg-announce/2012-May/001943.html But as we are this close to final release, we need testers to see that it does not introduce regressions... So, I'd like everyone that can and have Intel graphics to test: x11-driver-video-intel-2.19.0-1.mga2 that is available in Core Updates Testing. And report in this thread success/failure. -- Thomas Bugs 5278 and 5244 fixed with this version on: 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller]) -- Juancho
Re: [Mageia-dev] Freeze push: turtlearena 0.6
On Wed, Apr 25, 2012 at 6:16 PM, Juan Luis Baptiste juan...@mageia.org wrote: On Tue, Apr 24, 2012 at 7:45 PM, Juan Luis Baptiste juan...@mageia.org wrote: Hi, I just updated the game Turtle Arena to latest version 0.6, please push it, these are the reasons: 1. The developer says this: Turtle Arena 0.6 was released April 13 2012. It would be nice to update the version in Mageia 2 if possible. I hadn't planned to support 0.5.3 long term as it was a beta release leading to 0.6. 2. Turtle Arena was imported after mga 1 so it has been only present on cauldron so no breakage for anyone ;) Ping ? Ping ?? -- Juancho
Re: [Mageia-dev] Freeze push: turtlearena 0.6
On Thu, Apr 26, 2012 at 2:00 PM, nicolas vigier bo...@mars-attacks.org wrote: On Tue, 24 Apr 2012, Juan Luis Baptiste wrote: Hi, I just updated the game Turtle Arena to latest version 0.6, please push it, these are the reasons: Submitted. Thank you. -- Juancho
Re: [Mageia-dev] Freeze push: turtlearena 0.6
On Thu, Apr 26, 2012 at 4:08 PM, zezinho lists.jjo...@free.fr wrote: Looks like you forgot turtlearena-data : Um pacote pedido não pode ser instalado: turtlearena-0.6-1.mga2.x86_64 (devido a não satisfazer turtlearena-data[= 0.6]) Oooops... Updated, please push turtlearena-data too. Thanks -- Juancho
Re: [Mageia-dev] Freeze push: turtlearena 0.6
On Tue, Apr 24, 2012 at 7:45 PM, Juan Luis Baptiste juan...@mageia.org wrote: Hi, I just updated the game Turtle Arena to latest version 0.6, please push it, these are the reasons: 1. The developer says this: Turtle Arena 0.6 was released April 13 2012. It would be nice to update the version in Mageia 2 if possible. I hadn't planned to support 0.5.3 long term as it was a beta release leading to 0.6. 2. Turtle Arena was imported after mga 1 so it has been only present on cauldron so no breakage for anyone ;) Ping ? -- Juancho
[Mageia-dev] Freeze push: turtlearena 0.6
Hi, I just updated the game Turtle Arena to latest version 0.6, please push it, these are the reasons: 1. The developer says this: Turtle Arena 0.6 was released April 13 2012. It would be nice to update the version in Mageia 2 if possible. I hadn't planned to support 0.5.3 long term as it was a beta release leading to 0.6. 2. Turtle Arena was imported after mga 1 so it has been only present on cauldron so no breakage for anyone ;) Thanks. -- Juancho
Re: [Mageia-dev] skype4linux
On Mon, Apr 23, 2012 at 11:56 AM, Johnny A. Solbu coo...@solbu.net wrote: On Monday 23 April 2012 18:26, Sander Lepik wrote: Why? Isn't the API public? The encryption and protocol needed to use it is prorpietary, hence it is non-free as it depends on Nonfree software to work. Well, kopete has this functionality since a long time without any additional plugin, you just configure a Skype account in kopete (of course, skype has to be installed for this to work) and it will use Skype's public API to launch it and control it. And kopete is on core repo :D -- Juancho
Re: [Mageia-dev] dropping mysql-workbench
On Fri, Mar 30, 2012 at 10:46 AM, Remco Rijnders re...@webconquest.com wrote: Not arguing about this... but I think the attached patch fixes at least (part) of the build problem (for the new maintainer to look into ;-) See also http://bugs.mysql.com/bug.php?id=63898 Yup I found that too, now I'm dealing with other error. -- Juancho
Re: [Mageia-dev] dropping mysql-workbench
On Sun, Apr 1, 2012 at 7:57 PM, Luis Daniel Lucio Quiroz dlu...@okay.com.mx wrote: Dont drop it. Im fixing it in laptop. Seems that it compiles, more than 2 hrs working Don't worry, I've working on it since yesterday and almost have it ready, it already builds, it just needs some little fixes and it's ready. -- Juancho
Re: [Mageia-dev] dropping mysql-workbench
On Sun, Apr 1, 2012 at 8:11 PM, Luis Daniel Lucio Quiroz
dlu...@okay.com.mx wrote:
Will look for you in irc, i fixed without that patch
Me too.
Whats your nickname?
Maeztro.
This is the error with which the build fails now:
{standard input}: Assembler messages:
{standard input}:162559: Warning: end of file not at end of a line;
newline inserted
{standard input}:163265: Error: unknown pseudo-op: `.lo'
g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugs.mageia.org/ for instructions.
make[3]: *** [wb_context_model.o] Error 4
make[3]: *** Waiting for unfinished jobs
mv -f .deps/wb_component_physical.Tpo .deps/wb_component_physical.Po
it happens only when using the %configure2_5x macro, if I invoke
./configure directly the build doesn't fail. What could be setting
that macro that could be triggering this compiler error ?
--
Juancho
Re: [Mageia-dev] dropping mysql-workbench
On Thu, Mar 29, 2012 at 3:57 PM, Maarten Vanraes al...@rmail.be wrote: someone asked me to see about https://bugs.mageia.org/show_bug.cgi?id=5146 it looks like it needed a rebuild, but the rebuild failed with automake errors of some kind... tbh: i don't really care about this package, and have no idea if anyone (except reporter) actually uses this, is it even useful? This program is REALLY useful for web developers and database admins, I use it, so I'll get maintainership of it and try to fix the errors as soon as I can (swamped with work lately). See what it's useful for: http://www.mysql.com/downloads/workbench/ -- Juancho
Re: [Mageia-dev] [Freeze] please let in xonotic
On Thu, Mar 15, 2012 at 12:24 PM, Bertaux Xavier berta...@yahoo.fr wrote: If this is the case, then I say that xonotic should be allowed to be updated. I'm not about to be okay with that, a version Freeze only accepts updates on bug fixes and security warnings, so RC to Release is OK but not to revision's change, otherwise that would mean that if fate xonotic in version 0.7 just before the Release we should built. To me this should be pushed Backport, to limit the update after Release Backports are for new versions, not bug fixes. In this case even as this is a new version, the use of an older version of the game client with a new game server version could bring issues to users, so that makes this release more of a bug fix release, because we are trying to avoid any possible problem to our users, not because we want to have the latest version of the game. If we leave the current version and then a user reports a problem while playing the game, the 0.6 or 0.7 or whatever version is available at the time would be pushed as an update, not as a backport. -- Juancho
Re: [Mageia-dev] [Freeze] please let in xonotic
On Sun, Mar 11, 2012 at 7:21 AM, Michael Scherer m...@zarb.org wrote: Le samedi 10 mars 2012 à 10:26 +0100, Thierry Vignaud a écrit : Hi please let in xonotic-0.6.0 It's just a game that impacts nothing else. Niet. That's bugfix or security fixes. Well I vote to be updated, why ? global game servers are currently running 0.6.0, and by personal experience over several years (omg how much time wasted on this) these FPS games need to have the same client/server version, in some cases different versions won't work at all (ie. Urban Terror 3.7 - 4.0 - 4.1, Warsow 0.5 - 0.8 etc). I just did the test of running a 0.5.0 client on a 0.6.0 server and it works, but a big and annoying yellow announce floats across the screen remaining you that a new version is available. I also talked with one dev over IRC and he told me that there could be issues when running different client/server versions. So just to be on the safe side this new version should be pushed. If not then probably we will need to do it later as an update if any problems arise. I commit my self to test the new version, I know very well how this game works. -- Juancho
Re: [Mageia-dev] xonotic and nexuiz
On Sun, Mar 11, 2012 at 12:48 AM, Charles A Edwards c...@eslrahc.com wrote: Is it intentional that we package/provides both xonotic; the successor, and nexuiz classic; now owned by IllFonic and being compl etely rewritten for a different engine? Both are now completely different games, xonotic is not compatible with nexuiz servers, is still in a very early stage of it's development and has a really small community compared to Nexuiz. Also Nexuiz classic development hasn't stopped, there have been efforts by it's community to continue development from the last GPL release (2.5.2), and since some time there's been a 2.5.3 unoffcial pre-release floating around[1]. So, to answer your question, Xonotic wont ever replace Nexuiz, they have become two different games. [1] http://eatseakittens.com/forum/server-details-maps-settings-bans-etc/unofficial-nexuiz-2-5-3-release Cheers, -- Juancho
Re: [Mageia-dev] Deprecating startx
On Wed, Mar 7, 2012 at 4:34 PM, Samuel Verschelde sto...@laposte.net wrote: I apparently missed a few meetings or e-mails where this was discussed, but wasn't the initial plan to keep sysvinit by default in mga2 and switch to systemd by default in mga3? Wasn't the switch to systemd by default in cauldron a temporary switch in order to get more testing? Yeah, many have asked about this, if this was decided it seems this decision wasn't announced to this list, I can't find the email talking about this, just about ppl like you and Maarten asking when did this change. Cheers, -- Juancho
Re: [Mageia-dev] Deprecating startx
On Wed, Mar 7, 2012 at 6:34 PM, Colin Guthrie mag...@colin.guthr.ie wrote: As I said last time to this question, I'd certainly be extremely annoyed if mga2 does not default to systemd. I've given up a massive amount of my free time over this cycle working towards this. I would be massively annoyed if this effort was ultimately towards a secondary option. Don't worry, no one has said that it shouldn't :), but it's clear there's a confusion as you have seen, many people understood that systemd would come as an alternative to mga2 and sysvinit as default, and systemd as default in mga3. I also remember reading last year this but never the change of plans, maybe it was decided on the meetinfgs, but as I can't attend to them because of the schedule I missed the announcement. -- Juancho
Re: [Mageia-dev] Problem with latest network manager
On Sat, Mar 3, 2012 at 12:27 PM, Colin Guthrie mag...@colin.guthr.ie wrote: Seems the latest network manager is busted... Won't start or stop properly nor allow networks to actually work... Not sure exactly what is wrong, but I'll try and look into it if noone else does. C I'm working right now on updating it to 0.9 final released at the beginning of this week, give me a couple hours to finish and test with this one. -- Juancho
Re: [Mageia-dev] Problem with latest network manager
On Sat, Mar 3, 2012 at 5:25 PM, John Balcaen mik...@mageia.org wrote: I guess Colin is talking about NetworkManager not knetworkmanager :) Well anyway I'm already finishing :P -- Juancho
Re: [Mageia-dev] Bug 107
On Thu, Mar 1, 2012 at 2:10 AM, Oliver Burger obgr_sen...@mageia.org wrote: Well, I would need aworking solution so the icon cache does get regenerated on installing the desktop-common-data update on Mga1. The update does work on all other desktops, only KDE keeps the old icons, because they are stored in the user's cache as described on that bug. Ok, I just finished reading all the bug comments. I'll start looking at this tomorrow (2:20 am here :P). cheers, -- Juancho
Re: [Mageia-dev] Can't switch to virtual consoles
On Wed, Feb 15, 2012 at 2:18 PM, andre999 andre999...@laposte.net wrote: As I understood it, it was explicitly decided that systemd was to be an option for mga2, with sysvinit remaining the default. And hopefully systemd was to be the default for mga3, with sysvinit removed. Also, cauldron switched temporarily to systemd as default in order to more fully test it. But to revert to sysvinit as the default for mga2 release. When did this change ? Exactly, that was what I thought was going to happen, I don't remember reading when this changed, at least I don't remember to have been mentioned on the list. -- Juancho
Re: [Mageia-dev] Can't switch to virtual consoles
On Tue, Feb 14, 2012 at 1:39 PM, Thierry Vignaud thierry.vign...@gmail.com wrote: I've seen that occasionally over the years. Definitively not new. I think it's related to bootstraping not being finished. Hard to debug... Can you check if systemd has forked mingetty for the text consoles yet? I'm using sysvinit not systemd. -- Juancho
Re: [Mageia-dev] Can't switch to virtual consoles
On Tue, Feb 14, 2012 at 2:45 PM, Guillaume Rousse guillomovi...@gmail.com wrote: Le 14/02/2012 19:58, Juan Luis Baptiste a écrit : Can you check if systemd has forked mingetty for the text consoles yet? I'm using sysvinit not systemd. Try systemd then... But isn't sysvinit to be the default for mga 2 and the switch to systemd is going to be for mga 3 ? or I'm missing something ? -- Juancho
Re: [Mageia-dev] Can't switch to virtual consoles
On Tue, Feb 14, 2012 at 2:46 PM, Luc Menut lme...@free.fr wrote: Le 14/02/2012 19:58, Juan Luis Baptiste a écrit : Can you try to comment the line corresponding to tty1 in /etc/inittab? ... That worked. -- Juancho
Re: [Mageia-dev] Can't switch to virtual consoles
On Tue, Feb 14, 2012 at 2:53 PM, Thomas Backlund t...@mageia.org wrote: 14.02.2012 21:50, Juan Luis Baptiste skrev: systemd will be default for Mageia 2 sysvinit is only a fallback for systems that dont work with systemd yet... sysvinit (and mkinitrd) will be completely removed as soon as Cauldron opens up again after Mageia 2 release. Ahh ok, what I remembered from some months ago was what I said, I didn't knew that was changed. I'm going to test again with systemd. -- Juancho
Re: [Mageia-dev] Adding a new license to rpmlint
On Wed, Feb 8, 2012 at 1:35 AM, Dan Fandrich d...@coneharvesters.com wrote: It's very likely a missing dependency in the make files. The build server uses the make -j24 flag, so it's going to build the various modules in a very different order than without that flag. Ideally, you would find the missing dependecy and patch the make files, but you could also just remove the -j24 and have make build it sequentially instead (at up to 24 times slower, of course). But how do I remove that tag ? you mean by not using the %make macro and call make directly instead ? -- Juancho
Re: [Mageia-dev] Adding a new license to rpmlint
On Wed, Feb 8, 2012 at 1:16 PM, zezinho lists.jjo...@free.fr wrote: Le mercredi 8 février 2012 18:44:32, Juan Luis Baptiste a écrit : But how do I remove that tag ? you mean by not using the %make macro and call make directly instead ? Exactly. This is often done for buggy makefiles. Ok, I'll push it again without %make and see what happenss... -- Juancho
Re: [Mageia-dev] Adding a new license to rpmlint
On Wed, Feb 8, 2012 at 1:21 PM, Juan Luis Baptiste juan...@mageia.org wrote: On Wed, Feb 8, 2012 at 1:19 PM, Pascal Terjan pter...@gmail.com wrote: On Wed, Feb 8, 2012 at 18:16, zezinho lists.jjo...@free.fr wrote: Le mercredi 8 février 2012 18:44:32, Juan Luis Baptiste a écrit : But how do I remove that tag ? you mean by not using the %make macro and call make directly instead ? Exactly. This is often done for buggy makefiles. Fixing them is better :) At least reporting the bug upstream Of course, If I knew what the problem is :S It passed !! but I have no clue what happens when using %make macro to make the build fail. -- Juancho
Re: [Mageia-dev] Adding a new license to rpmlint
On Wed, Feb 8, 2012 at 3:05 PM, Juan Luis Baptiste juan...@mageia.org wrote: It passed !! but I have no clue what happens when using %make macro to make the build fail. Dammit, I pushed it to the wrong place, it should have gone to nonfree. Can someone please move it ? Thanks. -- Juancho
Re: [Mageia-dev] Adding a new license to rpmlint
On Fri, Feb 3, 2012 at 12:00 AM, Juan Luis Baptiste juan...@mageia.org wrote: Sorry for the late reply, I went into vacations just after this... On Fri, Jan 20, 2012 at 11:13 AM, Balcaen John mik...@mageia.org wrote: On Friday 20 January 2012 10:39:18 Juan Luis Baptiste wrote : g++: error: ../libsrcs/angelscript/angelSVN/sdk/angelscript/lib/libangelscript.a: No such file or directory make: *** [release/libs/angelwrap_x86_64.so] Error 1 The error seems to be here. I'm not sure that's the error as I have seen it too with my local build and still builds fine. Any other ideas ? I'm stuck with this.. :S I did a clean mga2 alpha3 install, updated it to cauldron, and just installed mgarepo, bm and warsow's spec BR and again it builds fine. arrgghhh I don't know why it fails on the BS !! the only thing I noticed comparing the build logs from the local build against the BS build is that stuff is built in a different order, also the linking, but I really don't have a clue of what's going on :( Can someone please please pretty please take a look ? here are the logs: http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20120201173847.juancho.valstar.7315/ Thanks in advance. -- Juancho
Re: [Mageia-dev] Adding a new license to rpmlint
Sorry for the late reply, I went into vacations just after this... On Fri, Jan 20, 2012 at 11:13 AM, Balcaen John mik...@mageia.org wrote: On Friday 20 January 2012 10:39:18 Juan Luis Baptiste wrote : g++: error: ../libsrcs/angelscript/angelSVN/sdk/angelscript/lib/libangelscript.a: No such file or directory make: *** [release/libs/angelwrap_x86_64.so] Error 1 The error seems to be here. I'm not sure that's the error as I have seen it too with my local build and still builds fine. Any other ideas ? I'm stuck with this.. :S -- Juancho
Re: [Mageia-dev] Adding a new license to rpmlint
On Fri, Jan 20, 2012 at 2:23 AM, Anssi Hannula an...@mageia.org wrote: It is a non-free redistributable license and should thus use the Freeware license tag, see: https://wiki.mageia.org/en/Licensing_policy Ahh ok thanks, I'll fix and push to the BS then :) -- Juancho
Re: [Mageia-dev] Adding a new license to rpmlint
h pushed the first package, warsow, and got this build error but the message doesn't say much: Done. As root, type make install to install the library. make[1]: Leaving directory `/home/iurt/rpm/BUILD/warsow-0.61/libsrcs/angelscript/angelSVN/sdk/angelscript/projects/gnuc' * Done building angelscript library. * * Continuing angelwrap building... error: Bad exit status from /home/iurt/rpm/tmp/rpm-tmp.BsF5my (%build) Here is the build output: http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20120120142833.juancho.valstar.14706/log/botcmd.1327069742.jonund.log Any ideas ? I suppose I'm missing a BR but locally it builds fine. -- Juancho On Fri, Jan 20, 2012 at 9:06 AM, Juan Luis Baptiste juan...@mageia.org wrote: On Fri, Jan 20, 2012 at 2:23 AM, Anssi Hannula an...@mageia.org wrote: It is a non-free redistributable license and should thus use the Freeware license tag, see: https://wiki.mageia.org/en/Licensing_policy Ahh ok thanks, I'll fix and push to the BS then :) -- Juancho
[Mageia-dev] Adding a new license to rpmlint
Hi, I have packaged Warsow[1], which it's engine is open source but as with other games I have packaged, the data files are licensed with a non-free license called Warsow Content License [2], which allows unmodified distribution of the data files in different formats like rpm, deb, etc (clause 3). I have imported the warsow and warsow-data packages to subversion but I haven't pushed them to the BS (to nonfree/release of course) because the data package will be rejected because of the license. It's feasible to add this license to rpmlint checks ? the other solution would be to make the game use autodownloader for the data files as I did for other games. Thanks, [1] http://www.warsow.net/ [2] http://www.calculate-linux.org/packages/licenses/warsow -- Juancho
Re: [Mageia-dev] [changelog] [RPM] 1 core/updates_testing terminator-0.96-2.mga1
On Mon, Jan 16, 2012 at 2:43 PM, Jani Välimaa jani.vali...@gmail.com wrote: 2012/1/16 lebedov buildsystem-dae...@mageia.org: URL : http://www.tenshu.net/terminator/ And the URL is broken, the correct one is http://www.tenshu.net/p/terminator.html -- Juancho
Re: [Mageia-dev] please stop doing bugs for updating magia 1
On Thu, Jan 12, 2012 at 1:01 PM, Christian Lohmaier lohmaier+mag...@googlemail.com wrote: On Wed, Jan 11, 2012 at 10:09 PM, Juan Luis Baptiste juan...@mageia.org wrote: [..] As I said, no one is talking about picking up a fix if there's a bug fix only release, it's for when it isn't and we need to reduce the chance of regressions by taking the modifications that *exactly* fix that bug. I strongly disagree. The policy is stating the exact opposite. And also Michael seems to defend the policy as it is written, and not your interpretation here. No, I'm doing exactly as the policy says, patch current stable version. The thing about bugfix only releases is something that it seems packagers have been doing implicitly as pterjan said before, and needs to be added to the policy. That again you might have a different understanding of bugfix-only-release. I think I stated mine often enough (increase in micro version when package follows major.minor.micro versioning scheme and no new features are introduced in micro releases). This isn't always the case, some projects include both bug fixes and new minor features in a micro version bump release. So you have to check first the Changelog to be sure it only includes bug fixes (which I do not completely agree for some cases, but that's another topic). So please change the wording of the update policy accordingly https://wiki.mageia.org/en/Updates_policy reads: ## [...] ## I read it as no version bumb is allowed (except for the three exception-cases listed) - bugs are only fixed using patches, and I don't see the interpretational freedom to allow upstream's bugfix releases. Updating from 1.3.2 to 1.3.3 would not be in compliance with the policy (if not in one of the three exception cases) - this is what I have called stupid policy (and still do). Yes, this must be added to the policy to avoid more confusions. -- Juancho
Re: [Mageia-dev] please stop doing bugs for updating magia 1
On Thu, Jan 12, 2012 at 2:10 PM, Christian Lohmaier lohmaier+mag...@googlemail.com wrote: No, I'm doing exactly as the policy says, patch current stable version. But then you're *not* doing as the policy says, as policy says: same version of the package *released with the distribution* So whatever version that ended up in the initial release of the distro. Not what is available upstream. Were do you get that ? have you even went through the updates I have sent and found one that was a new version ? if you do will see that ALL of my updates are a patched mga 1 version. -- Juancho
Re: [Mageia-dev] please stop doing bugs for updating magia 1
On Thu, Jan 12, 2012 at 3:02 PM, Christian Lohmaier lohmaier+mag...@googlemail.com wrote: You should learn to use unambiguous words then. Where I get that from is in this quote: No, I'm doing exactly as the policy says, patch current stable version. Ahh ok, I meant current stable version in Mageia, I thought that was implicit :P -- Juancho
Re: [Mageia-dev] please stop doing bugs for updating magia 1
On Thu, Jan 12, 2012 at 3:25 PM, Christian Lohmaier lohmaier+mag...@googlemail.com wrote: Hi Florian, On Thu, Jan 12, 2012 at 8:42 PM, Florian Hubold doktor5...@arcor.de wrote: Am 12.01.2012 19:01, schrieb Christian Lohmaier: [..] PS: Maybe next time you could improve on your wording, the policy may currently be incorrect, not reflecting good packaging practices, but as it's only a policy written by humans, it's not dumb. Just a hint. ;) No, I disagree. The policy as written is dumb in my opinion. But that doesn't mean I consider the people who edited the wiki to be dumb. That is a huge difference in my opinion. If I tell someone Ugh, that's an ugly shirt you're wearing today it is not the same as telling the person you are ugly - but people on this list do get it that way. Continuing with your example, yes, you aren't telling them that they're ugly, you are telling them that they have bad taste, and for some that can be insulting and for others not. You could have made your point by saying that *you* don't like that t-shirt because of x and y motives and if he had chosen another one with Y characteristics would look much better on him. Do you see the difference on wording ? you are expressing the same idea but in a more polite way. The same applies here. Your point about the problem in the policy is totally valid and needs to be addressed, but the way you expressed it is not, no matter you if you think it was. If it was, then no one had felt insulted on the first place ;) -- Juancho
Re: [Mageia-dev] please stop doing bugs for updating magia 1
On Wed, Jan 11, 2012 at 3:43 AM, Florian Hubold doktor5...@arcor.de wrote: Well, 2) and 3) are not valid reasons here, because backports should get a similar amount of QA testing as normal update candidates, and for the updates policy require a bugreport for validation through QA. I think this is unrealistic in practice. For updates, QA will be testing one bug fix, with a backport you will have dozens or more new features to test, you can't expect for QA to test all of them to be able to give the OK, more if they even don't use the backported app in a daily basis. Testing of a backport has to be more relaxed and compromise to test some basic stuff like that it installs and starts correctly, maybe the package maintainer can give some hints on what else to test, but the rest we will have to trust in the maintainer's judgement. If you think that all version backports should be tested in the same way as updates by QA, then all versions upgrades in cauldron should be tested by QA before pushing them to the BS right ? why risk for a bug on a program when updating to a new mga version and not when doing a backport ?, it's exactly the same situation. -- Juancho
Re: [Mageia-dev] please stop doing bugs for updating magia 1
On Wed, Jan 11, 2012 at 11:48 AM, Christian Lohmaier lohmaier+mag...@googlemail.com wrote: Welcome to distro-isolation, putting burden on maintainers, giving them all the reason to deny a reasonable request for a bugfix release because it just is too much work to hunt for a specific commit that fixed bug x. You don't do packaging, right ? it isn't that hard and is how all distro's do it. Look at Fedora or SuSE's packages and you will see a lot of patch files fixing single bugs. It's a matter of following upstream bugzilla reports and see which commit fixes the issue in question, create a patch from it and apply it to the package. Most of the time you can get the patches to fix single bugs from other distros packages. If there's a bugfix-only release it's better as it will be easier to update, but many times they aren't and include new features which could introduce regressions so we have to cherry pick those fixes. Also many times there isn't a new release from upstream so the only option we have is to backport a single fix. A bug may vary from a typo in a man page to a critical security update, And a typo-fix is not worthwhile to have? I think that what was meant here is that there are priorities for QA, where a security update is much more important and deserves more attention than a typo-fix. Of course, you are welcome to join the QA team to help them test those not so critical fixes if you really care that much about them. Sure, you cannot be save of regressions, but what makes you think you are smarter than upstream? What makes you so sure that not the one commit you add as a patch to your package is the one that causes the regressions? Because as I said earlier, we backport the commit that fixes that single issue, based on the info found on the bugzilla report of the upstream project. Also as you say most of the times upstream is not a bunch of clueless idiots so they will document very well each commit, making it easier for us to find those fixes. Cheers, -- Juancho
Re: [Mageia-dev] please stop doing bugs for updating magia 1
On Wed, Jan 11, 2012 at 1:22 PM, Antoine Pitrou solip...@pitrou.net wrote: On Wed, 11 Jan 2012 12:43:35 -0500 But how do you choose which patches you want to backport from the stream of bugfixes done by upstream? Because normally a single commit fixes a single bug and the commit message says it clearly, so it's easy to spot the fixes. Should the packager monitor all bug fixing activity? (sure (s)he *can*, but that's a lot of work) No we don't need to, we just need to look for the fix we are interested in as I described before. Just because someone doesn't file a bug against Mageia doesn't mean the bug doesn't bother anybody, because many users don't report upstream bugs to the distro's tracker. (also, other users don't bother reporting bugs at all :-)) Don't think that when we get a bug report in mga bugzilla is because only mga users are affected ;) most of the time there's already an upstream bug report so we start following it and give any useful information we have about it. If it isn't we create it and follow it. -- Juancho
Re: [Mageia-dev] please stop doing bugs for updating magia 1
On Wed, Jan 11, 2012 at 2:19 PM, Antoine Pitrou solip...@pitrou.net wrote: On Wed, 11 Jan 2012 13:33:41 -0500 No we don't need to, we just need to look for the fix we are interested in as I described before. Uh, you have a hard time understanding a question don't you? And you a hard time understanding an answer, don't you ? pfff... I specifically asked *how* you come to be interested in a particular fix, rather than all of them. As I said, when there's a bug report on mga, we start investigating the problem and go and look at upstream for a bug report there for *that* particular bug. Then, when we see it fixed we go to the control versioning system ang create a patch from the commit that fixed *that* bug according to the upstream report and apply it to the mga package, what isn't clear about that ? So, again, do you monitor all commits or is there another heuristic you apply to avoid that O(n) process? Again, read with attention what I said before and on this answer. -- Juancho
Re: [Mageia-dev] please stop doing bugs for updating magia 1
On Wed, Jan 11, 2012 at 2:38 PM, Johnny A. Solbu coo...@solbu.net wrote: On Wednesday 11 January 2012 19:33, Juan Luis Baptiste wrote: And how do one do that without monitoring most bugfixing activity or reviewing them, hunting for a particular fix? To some people, that magic trick is not obvious. As I said before, the upstream bug report will tell you which commit fixed the bug, so you go ahead and get that particular revision and create a patch to apply to the packages, there's no need to monitor *all* bugfixing activity, you just look for what you need when you need to. -- Juancho
Re: [Mageia-dev] please stop doing bugs for updating magia 1
On Wed, Jan 11, 2012 at 2:10 PM, Michael Scherer m...@zarb.org wrote: Le mercredi 11 janvier 2012 à 11:24 -0500, Juan Luis Baptiste a écrit : So trusting and having bugs are totally unrelated. And if you doubt that bugs appear, just see our bugzilla. We trust upstream ( most of them ), and yet there is bugs. No, they're not totally unrelated when we don't have the man power to do through QA on every package, we need to trust on the packager (and upstream of course) that he did his best to test the new version without expecting him to have tested all the new features, Or do you expect that a QA member get a list of all the new features of a backport and start testing them one by one ? that's what I call unrealistic in practice. If you think that all version backports should be tested in the same way as updates by QA, then all versions upgrades in cauldron should be tested by QA before pushing them to the BS right ? No, they should be tested before being put in the stable release. And that's exactly what we do by freezing and testing before release. Of course but again, we can't test *all* the new features of *all* the programs that are going to a new release, we do our best for most of them. Critical components like installer, kernel, drak* tools, etc need more testing and that's where (our very small team) QA should spend their time after a freeze. The rest we have to do our best to test after each version update of a package. why risk for a bug on a program when updating to a new mga version and not when doing a backport ?, it's exactly the same situation. That was already extensively discussed in the past, but if we do the same stuff than in Mandriva, we will end with the same result than in Mandriva. - people don't test backports, because that's not mandatory = some bugs slips. Of course and that will also happen when updating packages during the development cycle of cauldron. Yes, we do freeze to be able to test, but we cant test every new feature of all applications. We test the most critical stuff which we can't risk to have bugs (and they also slip some times). In the end, users complain that distribution is broken, and that impact our image. We cannot tell do not mix, because we cannot tell them to update backports without fear, as that would be lying. And in the end, saying this is not supported, but we offer to you is just sending a confusing message. If we start to give low quality stuff as Mageia, people will just think Mageia is low quality. Users will complain anyway, they will complain because there aren't backports of their favorite application or because a backported version has a bug, so we need to find a balance between those two. Expecting to do the same amount of testing to a backport will put too much burden on QA and will make the process of backporting a version too slow for the users. So we need to have more lax tests for backports, enough to guarantee that the application works for it's main features and doesn't put too much burnden on QA, than for updates which need to gurantee that a bug is really fixed. How to define which should be those tests ? that's the issue as I see it. We could have a backports team thought, that would do QA for backports without taking time from the updates QA team... Also the other problem is the third-party repos which brings lots of problems because packages are of low quality and don't follow our standards, and if we don't have our own backports and move fast enough users will continue to use those third-party repos, which will also bring the Mageia is of low quality problem. -- Juancho
Re: [Mageia-dev] please stop doing bugs for updating magia 1
On Wed, Jan 11, 2012 at 3:05 PM, Antoine Pitrou solip...@pitrou.net wrote: “Just because someone doesn't file a bug against Mageia doesn't mean the bug doesn't bother anybody, because many users don't report upstream bugs to the distro's tracker.” Simple, we won't fix bugs that aren't reported or noticed by us, that's unrealistic, someone needs to bring the attention to us if they want it to be fixed. -- Juancho
Re: [Mageia-dev] please stop doing bugs for updating magia 1
On Wed, Jan 11, 2012 at 3:44 PM, Antoine Pitrou solip...@pitrou.net wrote: And my point is that these bugs are fixed automatically if you follow bugfix releases from upstream... Apparently you like to create work for yourself, though :) No, it seems that you like to read what you like to read, On this thread has been clear that if there's a bugfix *only* release then we will update to that version, *but* when it isn't then we *can't* update to it, and we'll have to cherry pick fixes as I have described, according to the reported bugs. That's how we and any distro does it. -- Juancho
Re: [Mageia-dev] please stop doing bugs for updating magia 1
On Wed, Jan 11, 2012 at 3:53 PM, Christian Lohmaier lohmaier+mag...@googlemail.com wrote: adding patches to the packages and releasing them instead of waiting for a new upstream release is different from having the policy to stick with whatever release was used when releasing the distro and then only apply fixes via patches. Some times you can't wait for an upstream release, think for example of a security update. Also not all projects do bugfix only releases, but include new features as well so per our policy, we can't update to that version and that's when we have to cherry pick updates to apply to package in the stable version of mga. The problem seems to be that that isn't clear on the policy. I'm not saying that you must not use patches to fix bugs. There are cases where a bug is homegrown/specific to the distro and thus not suitable for fixing upstream, there are cases where development cylce is too slow/it is not sensible to wait for upstream. Exactly, plus the other case I just said. It is not a question whether it is possible. It is a question whether it makes sense in the first place. And no doubt it creates a lot more work for package maintainers. Both for initially hunting for the commit that fixes the bug, and later when patches conflict, and later when a package is updated to a new release. As I said, no one is talking about picking up a fix if there's a bug fix only release, it's for when it isn't and we need to reduce the chance of regressions by taking the modifications that *exactly* fix that bug. Because as I said earlier, we backport the commit that fixes that single issue, Every change, also those that introduce a regression is a commit. So implicitly you're saying that you will only fix the easy bugs, but anything that involves more than touching 10lines of code will not be chosen, since it might introduce regressions. No, I'm saying that we will look for the commit that fixes the issue in question and not anything else, it doesn't matter if the fix is one, 10, 50 lines and/or touches 1, 2 or 10 files. And again, if there's a bugfix *only* release available when we are working on a bug, or we know that there will be one soon, then we can update to that version. In the other cases we have to go the long route and patch the packges with individual fixes. -- Juancho
