Hi.
I'm browsing through http://check.mageia.org/cauldron/dependencies.html,
looking for maintainer-less packages to fix before the comming version freeze.
«mageia-maintainers-database» is one of the packages I've found, and I'm
puzzled as to why it have an explicit version requirement on ruby-
On Fri, Jan 4, 2013 at 7:11 AM, sardine 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
On Saturday 5. January 2013 01.35, Christiaan Welvaart wrote:
> There are currently about 800 packages that don't build,
> see http://pkgsubmit.mageia.org/autobuild/
That page should be redone. untill I saw your mail, I thought the autobuild vas
disabled or stopped because there was No content.
hi,
AFAICT nothing depends on fftw2 and glitz libraries, should they be
removed (they don't currently build)? I have not checked for build
dependencies.
Note that packages that cannot be built from source in cauldron
core/tainted can't be released in mageia 3. There are currently about
800
i didn't want to be seen as offensive here, this was just a remark from what
i've seen, and was odd TO ME. and i'm definately not the allknowing god here.
wrt to the specifics, that's not what i'm talking about. if i thought these
were bugs that *needed* fixing, it'd have filed them as such, the
Op vrijdag 4 januari 2013 21:13:57 schreef Angelo Naselli:
> Il 04/01/2013 18:45, AL13N ha scritto:
> > 6. about gwenview, does it actually use these kipi-plugins all the
> > time? does it use all of them, or just some kipi-plugins (if they
> > are available). if latter, it might be better to sugge
On Fri, 4 Jan 2013, Frank Griffin wrote:
1 installation transactions failed
There was a problem during the installation:
file /usr/bin/gdbus-codegen from install of
libglib2.0-devel-2.34.3-2.mga3.i586 conflicts with file from package
lib64glib2.0-devel-2.34.3-2.mga3.x86_64
file /usr/bin/gl
1 installation transactions failed
There was a problem during the installation:
file /usr/bin/gdbus-codegen from install of
libglib2.0-devel-2.34.3-2.mga3.i586 conflicts with file from package
lib64glib2.0-devel-2.34.3-2.mga3.x86_64
file /usr/bin/glib-genmarshal from install of
libglib2.0-d
Le 04/01/2013 17:49, AL13N a écrit :
[...]
5. hugin requires make
[...]
5. hugin directly requires make... why would a gui require a buildtool?
yes, it's surprising, but hugin required make to stitch panorama, and
it's probably still true.
see https://qa.mandriva.com/show_bug.cgi?id=44648
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 04/01/2013 18:45, AL13N ha scritto:
> 6. about gwenview, does it actually use these kipi-plugins all the
> time? does it use all of them, or just some kipi-plugins (if they
> are available). if latter, it might be better to suggest the
> specific on
On Fri, 04 Jan 2013 07:18:05 -0500, Thomas Backlund wrote:
root-odjjhxpcy38dnm+yrof...@public.gmane.org skrev 4.1.2013 12:29:
-# Original source
http://www.bouncycastle.org/download/bcprov-%{archivever}.tar.gz
-# is modified to
-# bcprov-%{archivever}-FEDORA.tar.gz with patented algorithms re
Le 04/01/2013 19:29, David Walser a écrit :
2, i understand for skype, but it's quite the dirty solution, perhaps a getter
with requirements is better than just having everyone installing 32deps...
If something is required by skype, shouldn't it be required by the get-skype
package, so it's onl
AL13N writes:
> 1. this more that xscreensaver requires chbg (does kscreensaver use this
> part?
> if not, maybe xscreensaver can be packaged separately), or chbg requires
> gtk+ code (maybe recode would be better to be gtk/qt independant)
chbg is used by the default screensaver we ship with xsc
1- do you think we have manpower for this ? i think not and that we have more
import pbs to deal with, as we have firefox requiring gtk, mcc,
system-config-printer, ... so kscreensaver too i don't think this is a big deal
6- gwenview can use ALL kipi-plugins and this is a suggests, i WON'T remov
i completely understand your point, i'm not saying these are packaging
mistakes at all.
but for something qt, it doesn't make much sense to have gnome-keyring code,
except for when there would be kwallet and gnome-keyring plugins.
1. this more that xscreensaver requires chbg (does kscreensaver
i have not answered to all, but nothing weird at all for me here, except if you
want to recode all to remove the deps you don't like.
1- xscreensaver is needed by kscreensaver, so nothing weird on the packaging
side.
2- this is needed for skype, if we don't this will not work this is needed.
Le 04/01/2013 16:50, oden a écrit :
Name: iozone Relocations: (not relocatable)
Version : 3.414 Vendor: Mageia.Org
Release : 1.mga3Build Date: Fri Jan 4 16:49:26 2013
Install Date: (not installed)
1. KDE requires gtk+
2. pulseaudio suggests it's i586 counterparts (plz don't)
3. qtwebkit requires gstreamer (not phonon)
4. KDE requires packagekit
5. hugin requires make
6. kipi-plugins suggested by gwenview
7. system-config-printer pulls in quite some gnome
8. transfugdrake required by userdrak
On Thu, Jan 03, 2013 at 11:41:26PM +0100, vaci0 wrote:
> vaci0 3.7.1-1.mga3:
> + Revision: 338403
> - Updated new version 3.7.1
> - Fix License tag to GPLv2+
The stable version won't be out before Mageia 3, so wonder why? Also
there is the possibility that it will depend on a development version
root-odjjhxpcy38dnm+yrof...@public.gmane.org skrev 4.1.2013 12:29:
Revision
338616
Author
dmorgan
Date
2013-01-04 11:29:56 +0100 (Fri, 04 Jan 2013)
Log Message
Use official tarball
[...]
-# Original source
http://www.bouncycastle.org/download/bcprov-%{archivever}.tar.gz
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
Message du : 03/01/2013 23:00
De : "Juan Luis Baptiste
On 04/01/13 09:15, Jochen Breuer wrote:
> 2013/1/4 Guillaume Rousse
>
>> We already run existing tests suite during package build... Running them
>> again on a different host would just change the execution environment to
>> use runtime dependencies instead of build time dependencies. I don't kno
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 04/01/2013 02:37, Pierre Jarillon ha scritto:
> How to disable it? How a standard user can know the name of the
> service ? It is hidden in the kde center manager. I never use it. I
> don't need it. I dare to say that!
IIRC it's in the same nepomuk/
Hi Thomas,
On 4 January 2013 04:41, Thomas Backlund wrote:
> Glen Ogilvie skrev 3.1.2013 13:10:
>
>> Hi,
>>
>> Has anyone got Mageia 2 or Mageia 3 beta running on Amazon EC2?
>>
>> I have been having a go, but not quite got there yet, so thought I'd ask
>> if anyone has already done it?
>>
>
> T
Le 04/01/2013 10:15, Jochen Breuer a écrit :
2013/1/4 Guillaume Rousse mailto:guillomovi...@gmail.com>>
We already run existing tests suite during package build... Running
them again on a different host would just change the execution
environment to use runtime dependencies instead
2013/1/4 Guillaume Rousse
> We already run existing tests suite during package build... Running them
> again on a different host would just change the execution environment to
> use runtime dependencies instead of build time dependencies. I don't know
> if the potential results are worth the addi
Op donderdag 3 januari 2013 22:14:51 schreef AL13N:
[...]
> next steps are:
> - install a splash/booting graphic (gfxboot/plymouth?)
[ ]# urpmi --no-suggests --urpmi-root /chroot/mga3 plymouth
the initrd is trying to redo, but with the current mga2 kernel which doesn't
exist in the chroot. so a
On Thu, Jan 03, 2013 at 08:10:21PM +, David Walser wrote:
> Also, while we're on the subject of gvfs, it needs updated to 1.15.0
GNOME uses x.y.z
If y == uneven, this means it is a development version, AKA: no go.
--
Regards,
Olav
Le 04/01/2013 09:11, Jochen Breuer a écrit :
Hi everyone,
I've already posted this to the Mageia forum, but doktor5000 suggested
to also post this to the mailing list.
I'd like to ask if it would make sense for Mageia to automatically test
generated RPM packages. The idea isn't new. Ubuntu is u
Hi everyone,
I've already posted this to the Mageia forum, but doktor5000 suggested to
also post this to the mailing list.
I'd like to ask if it would make sense for Mageia to automatically test
generated RPM packages. The idea isn't new. Ubuntu is using regression
tests with python-unit for a lo
30 matches
Mail list logo
