Re: [Mageia-dev] GLUT (part of mesa srpm) is not GPL... and is quite obsolete ! (bis)

2011-01-26 Thread Colin Guthrie
'Twas brillig, and Philippe DIDIER at 23/01/11 22:38 did gyre and gimble:
> I send this message again because it did not appear in the mailing-list
> after I sent it on january 18th
> As it concerns a basis rpm upon which others are built, I thought
> there's some emergency
> This seems to have at least convinced Mandriva team... and might improve
> Mageia too, reaching some common standard with all the other distributions.
> 
> Here it is :
> 
> Hi everybody !
> 
> I don't know if it's the right place to post this, and I don't want to
> fill this mail list with long mesages...
> 
> If someone needs to see what i'm talking about there's an old bug report
> on Mandriva bugzilla that was recently resuscitated (I know Thierry
> Vignaud had a glance on it...)
> https://qa.mandriva.com/show_bug.cgi?id=47090
> 
> Perhaps it would be more sane and safe to start on a universal basis
> with freeglut (that is used by every distribution), and build packages
> with it (but that means a temporary problem of compatibility with
> Mandriva...)
> 
> Hope this will help

Yeah I've been following this in Mdv myself. I'll try and take a look
when time frees itself from other tasks I'm involved in.

I don't see any problems with the various improvements made in the
packaging in mdv, so see no reason not to adopt them here.

Col


-- 

Colin Guthrie
mageia(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]


[Mageia-dev] 26/01/2011 meeting

2011-01-26 Thread Anne nicolas
Hi there

Next meeting will happen tonight on #mageia-dev at 20h UTC.

Here are the topics:

- Last review on build system and distro bootstrap
- Mentoring process and how to help new comers: please have a look
before meeting on
http://mageia.org/wiki/doku.php?id=rpm_start
http://mageia.org/wiki/doku.php?id=packager_start
http://mageia.org/wiki/doku.php?id=mentoring_start

And prepare any proposals, comments
- coming roadmap packaging / isos
- triage team: how we can help and get sufficient numbers
- Review on policies import

As usual feel free to propose any other topic provided our meeting
stay in human timetable :).

Cheers

-- 
Anne
http://www.mageia.org


Re: [Mageia-dev] 26/01/2011 meeting

2011-01-26 Thread Marcello Anni
> Hi there
> 
> 
> As usual feel free to propose any other topic provided our meeting
> stay in human timetable :).
> 

hi Anne,
we will be able to create a LiveCD version of Mageia for this alpha release? 
this is really important as interested people that don't want problems may 
want to try it and then install it only when a stable release is ready for 
everyday use.



> Cheers
>  
> Anne
> http://www.mageia.org
> 


cheers,
Marcello


Re: [Mageia-dev] 26/01/2011 meeting

2011-01-26 Thread Wolfgang Bornath
2011/1/26 Marcello Anni :
>> Hi there
>>
>>
>> As usual feel free to propose any other topic provided our meeting
>> stay in human timetable :).
>>
>
> hi Anne,
> we will be able to create a LiveCD version of Mageia for this alpha release?
> this is really important as interested people that don't want problems may
> want to try it and then install it only when a stable release is ready for
> everyday use.

As pointed out several times (and will be underlined in all
announcements) this Alpha 1 is
 - NOT a stable release
 - NOT for the average user, it's a developper release
 - NOT ready for everyday use

-- 
wobo


Re: [Mageia-dev] 26/01/2011 meeting

2011-01-26 Thread Marcello Anni
> 2011/1/26 Marcello Anni :
> >> Hi there
> >>
> >>
> >> As usual feel free to propose any other topic provided our meeting
> >> stay in human timetable :).
> >>
> >
> > hi Anne,
> > we will be able to create a LiveCD version of Mageia for this alpha 
release?
> > this is really important as interested people that don't want problems may
> > want to try it and then install it only when a stable release is ready for
> > everyday use.
> 
> As pointed out several times (and will be underlined in all
> announcements) this Alpha 1 is
>  - NOT a stable release
>  - NOT for the average user, it's a developper release
>  - NOT ready for everyday use
> 
> -- 
> wobo
> 

in fact, a livecd version allow to keep the "funny" side of linux without 
having any risk. so?


Re: [Mageia-dev] 26/01/2011 meeting

2011-01-26 Thread Romain d'Alverny
On Wed, Jan 26, 2011 at 16:35, Marcello Anni  wrote:
>> > we will be able to create a LiveCD version of Mageia for this alpha
> release?
>> > this is really important as interested people that don't want problems may
>> > want to try it and then install it only when a stable release is ready for
>> > everyday use.
>>
>> As pointed out several times (and will be underlined in all
>> announcements) this Alpha 1 is
>>  - NOT a stable release
>>  - NOT for the average user, it's a developper release
>>  - NOT ready for everyday use
>
> in fact, a livecd version allow to keep the "funny" side of linux without
> having any risk. so?

Again, that's not the focus of this alpha release. We don't want
people to try it around just to see what Mageia has in reserve,
because they will be disappointed in this regard: take this alpha as
an alpha-developer/packager-technical-raw-preview. It will be ugly. It
will scare Santa Claus. It will make the rain vaporize. It may even
break your neighbour's TV set.

Moverover, for future alpha/beta/finale release, formats to be
released (live, non-live, cd, dvd, other) _have to_ be specified on
the release roadmap/features page (so obviously, there needs to be a
discussion about this for the next alpha). And a livecd will be fine
as soon as we near the final release (or maybe not, that's to be
discussed).

Romain


Re: [Mageia-dev] 26/01/2011 meeting

2011-01-26 Thread Thorsten van Lil

Am 26.01.2011 16:35, schrieb Marcello Anni:


As pointed out several times (and will be underlined in all
announcements) this Alpha 1 is
  - NOT a stable release
  - NOT for the average user, it's a developper release
  - NOT ready for everyday use

--
wobo



in fact, a livecd version allow to keep the "funny" side of linux without
having any risk. so?



Correct me of I'm wrong, but afaik the alpha will be just the base of 
the upcoming mageia, without any DE or X.


Regards,
Thorsten


Re: [Mageia-dev] 26/01/2011 meeting

2011-01-26 Thread Wolfgang Bornath
2011/1/26 Marcello Anni :
>> 2011/1/26 Marcello Anni :
>> >> Hi there
>> >>
>> >>
>> >> As usual feel free to propose any other topic provided our meeting
>> >> stay in human timetable :).
>> >>
>> >
>> > hi Anne,
>> > we will be able to create a LiveCD version of Mageia for this alpha
> release?
>> > this is really important as interested people that don't want problems may
>> > want to try it and then install it only when a stable release is ready for
>> > everyday use.
>>
>> As pointed out several times (and will be underlined in all
>> announcements) this Alpha 1 is
>>  - NOT a stable release
>>  - NOT for the average user, it's a developper release
>>  - NOT ready for everyday use
>>
>> --
>> wobo
>>
>
> in fact, a livecd version allow to keep the "funny" side of linux without
> having any risk. so?

I am not sure what this means in this context, but the time for
discussion about live CDs will certainly come sooner or later.

This first Alpha is meant to

 - test the build system in all its parts up to a release
 - test the bootstrapping process

 - (last but not least) show the progress of the project.

Correct me if I'm wrong, but I think it will net even have a graphical
interface (x server).

-- 
wobo


Re: [Mageia-dev] 26/01/2011 meeting

2011-01-26 Thread Michael scherer
On Wed, Jan 26, 2011 at 03:11:25PM +0100, Anne nicolas wrote:
> Hi there
> 
> Next meeting will happen tonight on #mageia-dev at 20h UTC.
> 
> Here are the topics:
> 
> - Last review on build system and distro bootstrap
> - Mentoring process and how to help new comers: please have a look
> before meeting on
> http://mageia.org/wiki/doku.php?id=rpm_start
> http://mageia.org/wiki/doku.php?id=packager_start
> http://mageia.org/wiki/doku.php?id=mentoring_start
> 
> And prepare any proposals, comments
> - coming roadmap packaging / isos
> - triage team: how we can help and get sufficient numbers
> - Review on policies import
> 
> As usual feel free to propose any other topic provided our meeting

I would like to speak of the work and the Nuremberg meeting ( I have a 
blog post to be published, but I am currently unable to do it, not having 
enough time ).
This is mostly to expose what we did ( but Stormi already posted the mail 
before me ) and so dispatch some work.

-- 
Michael Scherer


Re: [Mageia-dev] 26/01/2011 meeting

2011-01-26 Thread Thomas Backlund

Wolfgang Bornath skrev 26.1.2011 17:48:

2011/1/26 Marcello Anni:

2011/1/26 Marcello Anni:

Hi there


As usual feel free to propose any other topic provided our meeting
stay in human timetable :).



hi Anne,
we will be able to create a LiveCD version of Mageia for this alpha

release?

this is really important as interested people that don't want problems may
want to try it and then install it only when a stable release is ready for
everyday use.


As pointed out several times (and will be underlined in all
announcements) this Alpha 1 is
  - NOT a stable release
  - NOT for the average user, it's a developper release
  - NOT ready for everyday use

--
wobo



in fact, a livecd version allow to keep the "funny" side of linux without
having any risk. so?


I am not sure what this means in this context, but the time for
discussion about live CDs will certainly come sooner or later.

This first Alpha is meant to

  - test the build system in all its parts up to a release
  - test the bootstrapping process

  - (last but not least) show the progress of the project.

Correct me if I'm wrong, but I think it will net even have a graphical
interface (x server).



Actually a 2010.2 upgraded to current bootstrap seems to work...
so you never know... but no promises yet... :)

--
Thomas




Re: [Mageia-dev] 26/01/2011 meeting

2011-01-26 Thread Ahmad Samir
On 26 January 2011 17:46, Thorsten van Lil  wrote:
> Am 26.01.2011 16:35, schrieb Marcello Anni:
>
>>> As pointed out several times (and will be underlined in all
>>> announcements) this Alpha 1 is
>>>  - NOT a stable release
>>>  - NOT for the average user, it's a developper release
>>>  - NOT ready for everyday use
>>>
>>> --
>>> wobo
>>>
>>
>> in fact, a livecd version allow to keep the "funny" side of linux without
>> having any risk. so?
>>
>
> Correct me of I'm wrong, but afaik the alpha will be just the base of the
> upcoming mageia, without any DE or X.
>
> Regards,
> Thorsten
>

Nope, X, KDE4 and GNOME are all already available.

More DE's will be in soon; note that the big hurdle of importing the
most basic packages is over, so importing packages now is much easier
:)

-- 
Ahmad Samir


Re: [Mageia-dev] 26/01/2011 meeting

2011-01-26 Thread Marcello Anni
> On Wed, Jan 26, 2011 at 16:35, Marcello Anni  wrote:
> >> > we will be able to create a LiveCD version of Mageia for this alpha
> > release?
> >> > this is really important as interested people that don't want problems 
may
> >> > want to try it and then install it only when a stable release is ready 
for
> >> > everyday use.
> >>
> >> As pointed out several times (and will be underlined in all
> >> announcements) this Alpha 1 is
> >>  - NOT a stable release
> >>  - NOT for the average user, it's a developper release
> >>  - NOT ready for everyday use
> >
> > in fact, a livecd version allow to keep the "funny" side of linux without
> > having any risk. so?
> 
> Again, that's not the focus of this alpha release. We don't want
> people to try it around just to see what Mageia has in reserve,
> because they will be disappointed in this regard: take this alpha as
> an alpha-developer/packager-technical-raw-preview. It will be ugly. It
> will scare Santa Claus. It will make the rain vaporize. It may even
> break your neighbour's TV set.

ah ah : ) ok then, i've understood i can't try it : )
> 
> Moverover, for future alpha/beta/finale release, formats to be
> released (live, non-live, cd, dvd, other) _have to_ be specified on
> the release roadmap/features page (so obviously, there needs to be a
> discussion about this for the next alpha). And a livecd will be fine
> as soon as we near the final release (or maybe not, that's to be
> discussed).
> 

ok, thank you for these infos 

> Romain
> 

cheers,
Marcello


Re: [Mageia-dev] 26/01/2011 meeting

2011-01-26 Thread Michael Scherer
Le mercredi 26 janvier 2011 à 18:13 +0200, Ahmad Samir a écrit :
> On 26 January 2011 17:46, Thorsten van Lil  wrote:

> Nope, X, KDE4 and GNOME are all already available.

Yep, but we didn't really test yet, and that's what the first iso will
be for, test and see if it work. It may totally eat your hard dis and
open a door to hell ( or worst, to Microsoft ).

> More DE's will be in soon; note that the big hurdle of importing the
> most basic packages is over, so importing packages now is much easier
> :)

Yeah, but personally, i would prefer to see that people focus more on
cleaning ( and sending patches upstream ) than importing

-- 
Michael Scherer



[Mageia-dev] Dev Team Call To Action...

2011-01-26 Thread Maarten Vanraes
Hi,

I know -dev team doesn't exist yet, but in spite of that: some of us may be 
needed.

Yesterday in the packaging meeting[1], misc and Stormi talked about the 3days 
they went to a Cross-Distro App Installer Meeting[2]. As far as I understood, 
our involvement in AppStream[3] is 4 part:
 - mageia-app-db would like to use the metadata to display on the site.
 - sophie would like some of the metadata too.
 - mageia could work on making packagekit support work (it does not replace 
rpm or urpmi in any way, it is cross-distro and just delegates the work to 
urpmi (in our case).)
 - mageia would then package AppStream in the distro. (Nothing is being said 
as being used by default: Note that AppStream only does Applications, while 
eg: rpmdrake installs packages).

Since this concerns mostly packaging, it has had a start-discussion in the 
packagers' meeting.

However:
 - mageia-app-db (Stormi: PHP) would like some help.
 - sophie (Nanar: Perl) would like some help.
 - packagekit support (misc: Perl) would need to be finalized.
( requires intimate knowledge of perl-URPM )
 - someone will have to package AppStream eventually.


afaik shikamaru would help with sophie, so i think that is covered.

So this leaves:
 - PHP for mageia-app-db
 - Perl-URPMI related stuff for packagekit support (i might have some time for 
this, not sure yet)

Now then, if there is anyone from -dev team who is inclined to help out, 
please, tell us :-)

Regards,

Maarten (aka AL13N)


[1]: http://www.mageia.org/wiki/doku.php?id=meetings#packaging_team
[2]: http://www.mageia.org/pipermail/mageia-discuss/20110126/003418.html
[3]: http://distributions.freedesktop.org/wiki/AppStream/MetadataNotes


Re: [Mageia-dev] Java-Policy first draft published

2011-01-26 Thread piep
Refection about Java_Packaging_Policy : what about a jpackage project 
for mageia java based rpm ?


like others I am still a "padawan" packager, but I also plan to work on 
java (and music) packages


I follow this thread with interest for few days and I wonder why nobody 
thinks to just import java packages from jpackage repositories ?



1) For many years jpackage.org project provides strong rpm packages of 
java based applications. These packages are used on the professional 
platform : Red Hat Enterprise Linux.


 Last project, "jpp6", provides rpm packages built on java6 
(JavaRuntimeEnvironment 1.6) and more than 2700 packages are ready to be 
installed on any rpm based system.

see : http://www.jpackage.org/browser/browse.php?jppversion=6.0

This is not the 400 packages of Mandriva project. Jpackage provides most 
of all java applications from the apache foundation (tomcat, maven, 
glassfish, hibernate, jakarta etc...) but also the J2EE application 
server "jboss" (from Red Hat now).


"jpp6" project is still under "Work In Progress" (WIP) state but I guess 
the number of package will reach the number of the actual "stable" 
version 5 : 3327 rpms.

see : http://www.jpackage.org/browser/browse.php?jppversion=5.0


2) JavaRuntimeEnvironment 1.6 aka java6 VM is the version provided in 
Mandriva cooker (and now Mageia caultron I guess) and it already 
provides the "jpackage-utils" package which is necessary to run packages 
from a jpackage repository.

Jpackage now (jpp6) uses java compiler : openjdk

Despite the arguments why Mandriva developers left the jpackage project 
to build their own java packages.
http://wiki.mandriva.com/en/Java_Packaging_Policy#Compatibility_with_proprietary_Java_stacks 



	We are at the beginning of a new rpm based distribution. It would be 
stupid and suicidal to work on our own java packages and reinvent the 
wheel again and again. If we want Mageia becomes a major distribution on 
java application servers also, we have to consider jpackage as source of 
java packages. Then we can concentrate our java packagers to improve the 
"time to market" of jpackage applications and on  desktop application 
(tuxguitar, sweethome3d, JOSM, homeplayer etc..) and all java 
application that lack in jpackage  and why not try to provide them to 
jpackage.




3) If you want to test the jpackage repository on your actual distro.

3.1) add a jpackage repository in mandriva cooker. (test on mdv cooker 
dec 2010)


3.1.1) add the jpackage key

# rpm --import http://www.jpackage.org/jpackage.asc

(ref : http://jpackage.org/gpgkey.php)

3.1.2) replace jpackage-utils-1.7.5 by jpackage-utils-5.0.0
(I guess final version will be jpackage-utils-6.0.0)

# rpm -Uvh 
http://vesta.informatik.rwth-aachen.de/ftp/pub/comp/Linux/jpackage/6.0/generic/free/RPMS/jpackage-utils-5.0.0-2.jpp6.noarch.rpm


3.1.3) add the jpackage-6.0-generic-free depot

The standard command provides an error :
# urpmi.addmedia jpackage-6.0-generic 
http://vesta.informatik.rwth-aachen.de/ftp/pub/comp/Linux/jpackage/6.0/generic/free 
with hdlist.cz

adding medium "jpackage-6.0-generic"
...retrieving failed: curl failed: exited with 22

no metadata found for medium

This is because urpmi runs the following command :
/usr/bin/curl -q -s --location-trusted -R -f --disable-epsv 
--connect-timeout 60 --anyauth --stderr - -O 
http://vesta.informatik.rwth-aachen.de/ftp/pub/comp/Linux/jpackage/6.0/generic/free/reconfig.urpmi


and this reconfig.urpmi does not exist on the jpackage depot (I guess 
this is a mismatch between "urpmi" version)


solution :
# urpmi.addmedia --probe-synthesis jpackage-6.0-generic-free 
http://vesta.informatik.rwth-aachen.de/ftp/pub/comp/Linux/jpackage/6.0/generic/free/RPMS


3.1.4) add the jpackage-6.0-generic-non-free depot (empty depot on 
2010-dec but can be useful)
# urpmi.addmedia --probe-synthesis jpackage-6.0-generic-non-free 
http://vesta.informatik.rwth-aachen.de/ftp/pub/comp/Linux/jpackage/6.0/generic/non-free/RPMS




4) some major application already packaged on jpp6 :
ant
glassfish
hibernate
jakarta
jboss
log4j
lucene
maven
saxon
tomcat
xerces
xalan
wsdl4j
etc...

see "Available Groups" for more details
http://mirrors.dotsrc.org/jpackage/6.0/generic/free/repoview/index.html


5) some old links found about Co-existence_with_JPackage:
http://wiki.mandriva.com/en/Java_Packaging_Policy#Co-existence_with_JPackage
http://wiki.mandriva.com/en/Policies/Java/JPackage


6) So why don't we consider "jpackage" with the new eye of a new distro 
and consider it as an external java application repository like we 
already use "plf" ?
Why don't we work closer with the jpackage team to improve the urpmi 
connection ?



long life to Mageia,
Pierrick Hervé


Re: [Mageia-dev] Dev Team Call To Action...

2011-01-26 Thread Per Øyvind Karlsen
2011/1/27 Maarten Vanraes :
> Hi,
>
> I know -dev team doesn't exist yet, but in spite of that: some of us may be
> needed.
>
> Yesterday in the packaging meeting[1], misc and Stormi talked about the 3days
> they went to a Cross-Distro App Installer Meeting[2]. As far as I understood,
> our involvement in AppStream[3] is 4 part:
>  - mageia-app-db would like to use the metadata to display on the site.
>  - sophie would like some of the metadata too.
>  - mageia could work on making packagekit support work (it does not replace
> rpm or urpmi in any way, it is cross-distro and just delegates the work to
> urpmi (in our case).)
>  - mageia would then package AppStream in the distro. (Nothing is being said
> as being used by default: Note that AppStream only does Applications, while
> eg: rpmdrake installs packages).
>
> Since this concerns mostly packaging, it has had a start-discussion in the
> packagers' meeting.
>
> However:
>  - mageia-app-db (Stormi: PHP) would like some help.
>  - sophie (Nanar: Perl) would like some help.
>  - packagekit support (misc: Perl) would need to be finalized.
> ( requires intimate knowledge of perl-URPM )
Getting familiar with package kit is on my todo list, dunno much about
urpmi support
and if there's anything lacking or not. Lemme know if you have any questions on
perl-URPM or if there's any specific issues, I can likely fix them
within short time. :)

--
Regards,
Per Øyvind


Re: [Mageia-dev] Java-Policy first draft published

2011-01-26 Thread Michael Scherer
Le jeudi 27 janvier 2011 à 02:40 +0100, piep a écrit :
> Refection about Java_Packaging_Policy : what about a jpackage project 
> for mageia java based rpm ?
> 
> like others I am still a "padawan" packager, but I also plan to work on 
> java (and music) packages
> 
> I follow this thread with interest for few days and I wonder why nobody 
> thinks to just import java packages from jpackage repositories ?

Because we already use their rpms. And that's a complex mess of
dependencies, with unneeded complexity.

For example, if you look at
svn://svn.mageia.org/packages/cauldron/jakarta-commons-lang/current/SPECS/jakarta-commons-lang.spec
, you can see 
1) the copyright of jpackage ( hence my point, but check any java
package )
2) it support gcj and non gcj ( ie twice the work if we want to test )
3) a weird release ( 2.3.4 )

4) various %post that should have been converted to trigger ( but since
it is not uniform on all distro, they prefered to cut and paste ).

Another issue is they package several version of the same software
( like 5 releases of groovy, 3 versions of junit , etc ). This is
something requires more ressources.

> 1) For many years jpackage.org project provides strong rpm packages of 
> java based applications. These packages are used on the professional 
> platform : Red Hat Enterprise Linux.

Last time I remember, people from Jpackage were not happy because RHEL
people took their rpms and integrated them in Fedora. So I think people
on RHEL use RH rpm, not the one from jpackage.

> Despite the arguments why Mandriva developers left the jpackage project 
> to build their own java packages.
> http://wiki.mandriva.com/en/Java_Packaging_Policy#Compatibility_with_proprietary_Java_stacks
>  

Well, what is not written there is the java stack of Mandriva was done
mainly by David Walluck, who is .. a jpackage member. And jpackage was
also partially founded by Guillaume Rousse, who also left the project
because they were aiming for too complex and unmaintainable goals.

After David was hired by RH, Alexander Kurtakov stepped to maintain, to
be also hired by RH. The only Ansii fixed some stuff, mainly because he
needed to do.

>   We are at the beginning of a new rpm based distribution. It would be 
> stupid and suicidal to work on our own java packages and reinvent the 
> wheel again and again. 

No, what would be suicidal is to keep the current java packages, done by
jpackage whose goal do not correspond to ours. 

We are using the jpackage rpms, check the specs. So if we do have
problem in rebuilding the rpms, using more jpackage rpm do not seems
like a solution, except if the problem is "We have too much free time".


> If we want Mageia becomes a major distribution on 
> java application servers also, we have to consider jpackage as source of 
> java packages. Then we can concentrate our java packagers to improve the 
> "time to market" of jpackage applications and on  desktop application 
> (tuxguitar, sweethome3d, JOSM, homeplayer etc..) and all java 
> application that lack in jpackage  and why not try to provide them to 
> jpackage.

Personally, I do not want Mageia to become a major distribution on java
application servers, I want it to be sustainable. And sustainability as
clearly demonstrated by previous attempts is quite difficult to achieve
by using jpackage rpm. So let's start simple, we will have the time to
grow later.

Java was a weak point on Mandriva, and I think that seeing the problem
twice is enough to not want to see it a 3rd time.

Their goals differ totally from ours. First, they still aim to be usable
on more than one platform, which usually mean "be unintegrated on every
platform". In practice, they seems to rather be "usable only on RHEL",
but well. There would be various technical issues, like keep specs in
synchronisation, etc, various organizational issues like not being able
to decide our policy without asking to people outside of our
organisation, or having to handle out of our svn packages, etc.

So let's already take care of what we have. Once packager have
demonstrated that the 400 packages will not bitrot alone in the svn,
then we can start to think importing more IMHO. Pushing more rpm when
the foundation is not maintained is simply a bad idea, like constructing
a house on the sand.

> 6) So why don't we consider "jpackage" with the new eye of a new distro 
> and consider it as an external java application repository like we 
> already use "plf" ?
> Why don't we work closer with the jpackage team to improve the urpmi 
> connection ?

PLF was mainly done by mandrake linux people aiming to integrate with
mandrake linux, and quickly shared src.rpm, followed mandriva policies,
contributed to Mandriva, etc.

Jpackage was made based on the (IMHO flawed) assumption that the only
issue that prevented packages sharing was "binary compatibility", and
that it was solved by jvm. Both affirmation are quite wrong, as there is
lots of others problem to solve ( like rpm ve

Re: [Mageia-dev] Dev Team Call To Action...

2011-01-26 Thread Cazzaniga Sandro
Le 27/01/2011 01:17, Maarten Vanraes a écrit :
> Hi,
> 
> I know -dev team doesn't exist yet, but in spite of that: some of us may be 
> needed.
> 
> Yesterday in the packaging meeting[1], misc and Stormi talked about the 3days 
> they went to a Cross-Distro App Installer Meeting[2]. As far as I understood, 
> our involvement in AppStream[3] is 4 part:
>  - mageia-app-db would like to use the metadata to display on the site.
>  - sophie would like some of the metadata too.
>  - mageia could work on making packagekit support work (it does not replace 
> rpm or urpmi in any way, it is cross-distro and just delegates the work to 
> urpmi (in our case).)
>  - mageia would then package AppStream in the distro. (Nothing is being said 
> as being used by default: Note that AppStream only does Applications, while 
> eg: rpmdrake installs packages).
> 
> Since this concerns mostly packaging, it has had a start-discussion in the 
> packagers' meeting.
> 
> However:
>  - mageia-app-db (Stormi: PHP) would like some help.
>  - sophie (Nanar: Perl) would like some help.
>  - packagekit support (misc: Perl) would need to be finalized.
> ( requires intimate knowledge of perl-URPM )
I can help for packagekit, and sophie, all of perl :)
>  - someone will have to package AppStream eventually.
> 
> 
> afaik shikamaru would help with sophie, so i think that is covered.
> 
> So this leaves:
>  - PHP for mageia-app-db
>  - Perl-URPMI related stuff for packagekit support (i might have some time 
> for 
> this, not sure yet)
> 
> Now then, if there is anyone from -dev team who is inclined to help out, 
> please, tell us :-)
> 
> Regards,
> 
> Maarten (aka AL13N)
> 
> 
> [1]: http://www.mageia.org/wiki/doku.php?id=meetings#packaging_team
> [2]: http://www.mageia.org/pipermail/mageia-discuss/20110126/003418.html
> [3]: http://distributions.freedesktop.org/wiki/AppStream/MetadataNotes


-- 
Sandro Cazzaniga
IRC: Kharec (irc.freenode.net)
Twitter: @Kharec