Re: [Mageia-dev] [RPM] cauldron core/release bluefish-2.0.3-1.mga1

2011-04-14 Thread Thierry Vignaud 
On 15 April 2011 00:21, Mageia Team  wrote:
> ahmad  2.0.3-1.mga1:
> + Revision: 85548
> - Update to 2.0.3
> - Add BR libxml2-utils, needed for validating RELAX NG
> - Add BR man, needed for checking manpages
> - Add post/postun scriptlets for registring XML Catalog (thanks to Fedora for 
> the
>  exact syntax to do so)

Maybe should we consider file triggers for those?
I don't know how many packages use them.

Re: [Mageia-dev] [RPM] cauldron core/release libnice-0.1.0-1.mga1

2011-04-14 Thread Thierry Vignaud 
On 14 April 2011 05:13, Mageia Team  wrote:
> dams  0.1.0-1.mga1:
> + Revision: 85006
> - Update to 0.1.0

installing lib64mission-control-plugins0-5.7.9-1.mga1.x86_64.rpm
lib64readline6-6.2-1.mga1.x86_64.rpm
lib64atkmm1.6_1-2.22.5-1.mga1.x86_64.rpm
lib64nice1-0.1.0-1.mga1.x86_64.rpm
lib64cairomm1.0_1-1.9.8-1.mga1.x86_64.rpm
telepathy-gabble-0.11.10-1.mga1.x86_64.rpm
lib64pangomm2.4_1-2.28.2-1.mga1.x86_64.rpm
telepathy-mission-control-5.7.9-1.mga1.x86_64.rpm from
/mageia/x86_64/media/core/release
Preparing...

Installation failed:file /usr/lib64/gstreamer-0.10/libgstnice.so
from install of lib64nice1-0.1.0-1.mga1.x86_64 conflicts with file
from package lib64nice0-0.0.13-2.mga1.x86_64

Re: [Mageia-dev] dhcp-client is borked as of today

2011-04-14 Thread Frank Griffin 

On 04/14/2011 06:14 PM, Michael Scherer wrote:

IMHO, that's worth a addition to some errata or upgrade notes.


There was also a previous issue on either the cooker or mageia-dev list 
(probably cooker) where the poster had a situation where a newer (Cisco) 
DHCP server was returning only the first domain in the DHCP domain item 
and the full list in the multiple-domain item, and the older Linux 
client was seeing only the older single-domain item and missing the 
other domains.  Windows clients recognized the newer multiple-domain 
item, and worked correctly.  FWIW.

Re: [Mageia-dev] dhcp-client is borked as of today

2011-04-14 Thread Michael Scherer 
Le jeudi 14 avril 2011 à 16:21 -0400, Frank Griffin a écrit :
> On 04/14/2011 01:07 PM, Thierry Vignaud wrote:
> >
> > A NM issue then?
> >
> 
> I don't think so, because of the non-NM behavior.  After testing by 
> removing the second domain from the DHCP server configuration, it works 
> fine.  It looks like dhcp-client used to allow the non-standard usage of 
> putting multiple search domains in the domain field, but now that DHCP 
> supports a separate multiple-domain list transfer item, it is showing 
> unpredictable behavior with a multiple-entry single domain field.

IMHO, that's worth a addition to some errata or upgrade notes.
-- 
Michael Scherer

Re: [Mageia-dev] dhcp-client is borked as of today

2011-04-14 Thread Frank Griffin 

On 04/14/2011 01:07 PM, Thierry Vignaud wrote:


A NM issue then?



I don't think so, because of the non-NM behavior.  After testing by 
removing the second domain from the DHCP server configuration, it works 
fine.  It looks like dhcp-client used to allow the non-standard usage of 
putting multiple search domains in the domain field, but now that DHCP 
supports a separate multiple-domain list transfer item, it is showing 
unpredictable behavior with a multiple-entry single domain field.

Re: [Mageia-dev] Tainted Software - once more

2011-04-14 Thread Michael Scherer 
Le jeudi 14 avril 2011 à 17:47 +0200, Romain d'Alverny a écrit :
> On Thu, Apr 14, 2011 at 16:02, Frank Griffin  wrote:
> > On 04/14/2011 07:28 AM, Tux99 wrote:
> >>
> >> Does anyone know what the status of the buildsystem with regards to
> >> building dual core/tainted packages from a single source rpm is?
> 
> Not done yet. It's in sysadmin team's TODO (the usual "sysadmin team
> members welcomes people to help" is still valid).

People can just subscribe to 
https://bugs.mageia.org/show_bug.cgi?id=338

-- 
Michael Scherer

Re: [Mageia-dev] [RPM] cauldron core/release zeromq-2.1.4-1.mga1

2011-04-14 Thread Pascal Terjan 
On Thu, Apr 14, 2011 at 00:59, Mageia Team
 wrote:
> Name        : zeromq                       Relocations: (not relocatable)
> Version     : 2.1.4                             Vendor: Mageia.Org
> Release     : 1.mga1                        Build Date: Thu Apr 14 01:58:16 
> 2011
> Install Date: (not installed)               Build Host: ecosse
> Group       : Development/Other             Source RPM: (none)
> Size        : 1864901                          License: LGPLv3+
> Signature   : (none)
> Packager    : Mageia Team 
> URL         : http://www.zeromq.org
> Summary     : Software library for fast, message-based applications
> Description :
> The 0MQ lightweight messaging kernel is a library which extends the
> standard socket interfaces with features traditionally provided by
> specialized messaging middle-ware products. 0MQ sockets provide an
> abstraction of asynchronous message queues, multiple messaging
> patterns, message filtering (subscriptions), seamless access to
> multiple transport protocols and more.
>
> dams  2.1.4-1.mga1:
> + Revision: 84840
> - update to 2.1.4

It seems zeromq-utils no longer exists, should it be obsoleted?

zeromq  zeromq-utilsi5862.0.10-1.mga1   Obsolete binaries 
(source
2.1.4-2.mga1 found)
zeromq-utilsx86_64  2.0.10-1.mga1   Obsolete
binaries (source 2.1.4-2.mga1 found)

Re: [Mageia-dev] [RPM] cauldron core/release tesseract-3.00-1.mga1

2011-04-14 Thread Pascal Terjan 
On Thu, Apr 14, 2011 at 16:32, Mageia Team
 wrote:
> Name        : tesseract                    Relocations: (not relocatable)
> Version     : 3.00                              Vendor: Mageia.Org
> Release     : 1.mga1                        Build Date: Thu Apr 14 17:30:09 
> 2011
> Install Date: (not installed)               Build Host: jonund
> Group       : Graphics                      Source RPM: (none)
> Size        : 14392037                         License: Apache
> Signature   : (none)
> Packager    : Mageia Team 
> URL         : http://code.google.com/p/tesseract-ocr/
> Summary     : A high-performance OCR engine
> Description :
> The Tesseract OCR engine was one of the top 3 engines in the 1995
> UNLV Accuracy test. Since then it has had little work done on it,
> but it is probably one of the most accurate open source OCR engines
> available. The source code will read a binary, grey or color image
> and output text. A tiff reader is built in that will read
> uncompressed TIFF images, or libtiff can be added to read compressed
> images.
>
> tv  3.00-1.mga1:
> + Revision: 85208
> - new release
> - sync with mdv:
>  o Fix requires in the devel package
>  o make it build
>  o Fix file list
>  o Do not package .la/.a files
>  o use configure
>  o Remove deprecated patches

I guess some obsoletes are needed

libtesseract_full2  i5862.04-6.mga1 Obsolete binaries (source 
3.00-1.mga1 found)
tesseract-deu   i5862.04-6.mga1 Obsolete binaries (source 3.00-1.mga1 
found)
tesseract-eng   i5862.04-6.mga1 Obsolete binaries (source 3.00-1.mga1 
found)
tesseract-fra   i5862.04-6.mga1 Obsolete binaries (source 3.00-1.mga1 
found)
tesseract-ita   i5862.04-6.mga1 Obsolete binaries (source 3.00-1.mga1 
found)
tesseract-nld   i5862.04-6.mga1 Obsolete binaries (source 3.00-1.mga1 
found)
tesseract-spa   i5862.04-6.mga1 Obsolete binaries (source 3.00-1.mga1 
found)
lib64tesseract_full2x86_64  2.04-6.mga1 Obsolete binaries (source
3.00-1.mga1 found)
tesseract-deu   x86_64  2.04-6.mga1 Obsolete binaries (source 3.00-1.mga1 
found)
tesseract-eng   x86_64  2.04-6.mga1 Obsolete binaries (source 3.00-1.mga1 
found)
tesseract-fra   x86_64  2.04-6.mga1 Obsolete binaries (source 3.00-1.mga1 
found)
tesseract-ita   x86_64  2.04-6.mga1 Obsolete binaries (source 3.00-1.mga1 
found)
tesseract-nld   x86_64  2.04-6.mga1 Obsolete binaries (source 3.00-1.mga1 
found)
tesseract-spa   x86_64  2.04-6.mga1 Obsolete binaries (source 3.00-1.mga1 
found)

Re: [Mageia-dev] dhcp-client is borked as of today

2011-04-14 Thread Thierry Vignaud 
On 14 April 2011 01:46, Frank Griffin  wrote:
>> It writes a "search" line to /etc/resolv.conf of the not-fully-qualified
>> hostname rather than the domain names returned by the DHCP server.
>>
>> For instance, if the hostname is "ftglap" and the domain names returned by
>> the server are "x.y.z y.z", you get "search ftglap" rather than  "search
>> x.y.z y.z" as you used to get prior to the last update.
>>
>> Ring a bell with anyone ?  I'm not sure if this is worth a bug report,
>> unless it was a conscious decision that needs to be contested.
>>
> This was for an NM-controlled wireless NIC.  On a desktop host for a wired
> NIC not controlled by NM, there is now no "search" line at all.

A NM issue then?

Re: [Mageia-dev] libdrm-2.4.25 and libva-1.0.12

2011-04-14 Thread Thierry Vignaud 
On 14 April 2011 17:30, Thomas Backlund  wrote:
> According to:
> http://intellinuxgraphics.org/2011Q1.html
>
> We need libdrm-2.4.25 and libva-1.0.12 + few kernel patches to get Intel
> Sandy Bridge support in good shape for Mageia 1
>
> Any objections ?
>
> If not, I will push them this weekend...
> (unless someone beats me to it for libdrm & libva part)

For the record, I've discussed about this with Colin before he left
and we both agree we should update it

Re: [Mageia-dev] libdrm-2.4.25 and libva-1.0.12

2011-04-14 Thread Anssi Hannula 
On 14.04.2011 18:30, Thomas Backlund wrote:
> Hi,
> 
> According to:
> http://intellinuxgraphics.org/2011Q1.html
> 
> We need libdrm-2.4.25 and libva-1.0.12 + few kernel patches to get Intel
> Sandy Bridge support in good shape for Mageia 1
> 
> Any objections ?

Nope.

> If not, I will push them this weekend...
> (unless someone beats me to it for libdrm & libva part)
> 
> -- 
> Thomas
> 


-- 
Anssi Hannula

Re: [Mageia-dev] Tainted Software - once more

2011-04-14 Thread Romain d'Alverny 
On Thu, Apr 14, 2011 at 16:02, Frank Griffin  wrote:
> On 04/14/2011 07:28 AM, Tux99 wrote:
>>
>> Does anyone know what the status of the buildsystem with regards to
>> building dual core/tainted packages from a single source rpm is?

Not done yet. It's in sysadmin team's TODO (the usual "sysadmin team
members welcomes people to help" is still valid).

> And to re-ask a related question that was never resolved: is "tainted"
> supposed to be a replacement for PLF, or will PLF still be required for
> those who want/need packages with legal limitations ?

We still need to improve on that yes (would it be only for Tier2
mirrors). To be discussed at the next Council?

Anyway, there's no general rule for that, further than: what goes here is:
 - what is either free software or not (could go in core or nonfree),
 - but that may not be redistributable in some areas (because of
software patents or other issues).

Defining what is the valid reference area to allow redistribution is
not done yet, but we can aim at Europe/France (this is where the
primary mirror is) - the only main threat I can see here is the coming
European Patent initiative, however I am not sure what stance this one
will take regarding the possibility of software patents.

That in turn doesn't mean that redistribution of tainted _is_
forbidden out of this reference area. But it means that software that
could be forbidden, may be included in tainted.

Others may confirm that this will cover most of what PLF provides
already - but that there will be some packages left anyway.

For all the rest (stuff we can't, for certain, legally distribute
within EU/France), you'll need a separate repository Mageia.Org can't

Now, what the precise list of packages in tainted is... depends on
packagers. See current:
http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/cauldron/i586/media/tainted/release/

However, for sure, there should be a list maintained somewhere of the
list of software that cannot be added in tainted, and for what reason
(and what the resolution of it would need to be). So that each request
for a potential package in tainted gets documented.

Romain

[Mageia-dev] libdrm-2.4.25 and libva-1.0.12

2011-04-14 Thread Thomas Backlund 

Hi,

According to:
http://intellinuxgraphics.org/2011Q1.html

We need libdrm-2.4.25 and libva-1.0.12 + few kernel patches to get Intel 
Sandy Bridge support in good shape for Mageia 1


Any objections ?

If not, I will push them this weekend...
(unless someone beats me to it for libdrm & libva part)

--
Thomas

Re: [Mageia-dev] Maintainers policy

2011-04-14 Thread Angelo Naselli 
> I don't think we should have a "games" group. It makes sense to have
> groups for packages that needs to be maintained together, for instance
> KDE apps and KDE libraries should be maintained by the same group of
> people. But for games, it is independent applications that could be
> maintained by different people, so I don't think all games should be
> maintained by the same group.
It was only an example, not a group suggestion ;)
But another example could be kde-devel libs and other c-c++ devel libs
(e.g. commoncpp2, ucommon, boost,...).
Anyway i agree on the fact that game could not be useful :)

Angelo



signature.asc
Description: This is a digitally signed message part.

Re: [Mageia-dev] Mageia marketing plan is on the way, proposals and team reports needed

2011-04-14 Thread Marcello Anni 
> Hi,
> 
> i'm working on a Marketing plan for Mageia in order to define a coherent 
growth 
> of the project, both in the "hard"  side and in the "soft" side of it.
> 
> At this stage i need:
> 
> - a report for each team
> 
> * It should contain current manpower, level (and trend) of activities, 
current 
> tasks, available infos and statistics. 
> * if possibile it's better if made by the team leader (naturally he can 
share 
> all the members toughts)
> * about "sensitive data":  is better to send an e-mail directely to my e-
mail 
> adress (this)
> 
> - proposals to be added in the marketing plan
> 
> They should contain ideas about:
>  *  Vision (which needs mageia project should satisfy in a long-term 
> horizont?)
>  *  Mission (how can be satisfied these long-term needs in a mid-term 
> horizont?)
>  *  possible strategies (what can be done to satisfy these mid-term needs?)
>  *  action plan (which aspects should be improved in a short term horizont?)
>  *  threats and opportunities of the project
> 
> 
> Please, try to be short and precise. i'm waiting your inputs!
> 
> 
> cheers,
> Marcello
> __
> Mageia Marketing Team - mageia-market...@mageia.org

Hi, 

Patricia set up in the marketing wiki page:

http://www.mageia.org/wiki/doku.php?id=marketing

an appropriate space to share your ideas and proposals, partecipating in the 
mageia marketing plan is as easy as logging in in the wiki : )

here is it the link: 

http://www.mageia.org/wiki/doku.php?id=marketing#sandbox_for_developing_marketing_comms_ideas_texts_and_input


cheers,
Marcello

Re: [Mageia-dev] Tainted Software - once more

2011-04-14 Thread Frank Griffin 

On 04/14/2011 07:28 AM, Tux99 wrote:


Does anyone know what the status of the buildsystem with regards to
building dual core/tainted packages from a single source rpm is?


And to re-ask a related question that was never resolved: is "tainted" 
supposed to be a replacement for PLF, or will PLF still be required for 
those who want/need packages with legal limitations ?

Re: [Mageia-dev] Tainted Software - once more

2011-04-14 Thread Tux99 


Quote: Oliver Burger wrote on Mon, 28 March 2011 10:17

> What about packages, we need twice, once in core, once in
> tainted (media player come to mind)?
> Will the buildsystem be able to create both out of one single
> src.rpm? If not, how else to do it?

Does anyone know what the status of the buildsystem with regards to 
building dual core/tainted packages from a single source rpm is?

Is it now possible to build mplayer, gstreamer, vlc, xine with support for
'tainted' codecs?

Is this planned for Mageia1 or are 'tainted' codecs (for example h.264) not
considered important for Mageia1?

-- 
Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/

Re: [Mageia-dev] Maintainers policy

2011-04-14 Thread nicolas vigier 
On Thu, 14 Apr 2011, Angelo Naselli wrote:

> 
> But the real problem is that some packages could lay
> on more than a group. For insntace, game and kde games
> or educational and some games... and so on.

I don't think we should have a "games" group. It makes sense to have
groups for packages that needs to be maintained together, for instance
KDE apps and KDE libraries should be maintained by the same group of
people. But for games, it is independent applications that could be
maintained by different people, so I don't think all games should be
maintained by the same group.

Re: [Mageia-dev] Maintainers policy

2011-04-14 Thread Funda Wang 
2011/4/14 Anne nicolas :
> Hi there
>
> Following tonight's meeting, we will start one week discussion about
> maintainers policy. Some questions to be discussed:
>
> - shall we have ACL's on svn, submits?
> - what about having co-maintenership or teams? How shall we manage this?
> - what about sensitive packages ?
> ...
>
> Pleas make any comments and proposals we could discus to build it.
> Final decisions will be taken during next packagers meeting (20th of
> april)

If we are about to stick to subversion, then only maintainer could
submit certain package. Of course, if package don't have maintainer,
then anybody could submit it.

If we will turn to git, then everybody could have his own clone, but
the merge request should be reviewed by maintainer. After merging,
anybody could submit it. The problem is that, we couldn't assure every
package have a valid maintainer.

Re: [Mageia-dev] Maintainers policy

2011-04-14 Thread Angelo Naselli 
mercoledì 13 aprile 2011 alle 23:33, Anne nicolas ha scritto:
> - what about having co-maintenership or teams? How shall we manage this?
I'm not against of that. I believe it could be a good way out
when people leave or can't/stop to work on their packages. Missing
all members of a team is a little bit harder :D

I know some people prefer being the only owner, we could decide
case by case but finding packages that can be part of a group and
a team that can manage it could help either in bug management.

Easy groups could be for instance:
kde
gnome
developer libraries
toolchain & co.

But the real problem is that some packages could lay
on more than a group. For insntace, game and kde games
or educational and some games... and so on.

I thought that a first try could be to have mentor and their
padawans seen as a team to maintain packages they've released
togheter. From that it should be easy to move maintainership
from one team member to another. But as ennael said that
could be more work for mentors.

So i don't have a real solution :) but something to discuss on...

Cheers,
Angelo


signature.asc
Description: This is a digitally signed message part.

Re: [Mageia-dev] RFT: xen support

2011-04-14 Thread Maarten Vanraes 
> Hi,
>
> xen-4.1.0-1.mga1 is now avaliable in the repos.
>
> And as of kernel-2.6.38.2-4.mga1 there has been some cleanups and addons
> for xen:
>
> There is now a kernel-xen-pvops that also should work as dom0.
>
> Now this is mostly upstream kenel.org code so its not as fully
> featured as the old kernel-xen. You can see the features listed here:
> http://wiki.xensource.com/xenwiki/XenParavirtOps.
>
> There is one exception: our 2.6.38 kernel has xen-netback backend driver
> added.
>
> So those of you that have been using xen, please test atleast the
> following:
>
> - check that kernel-server still works as a xen guest
> - try to use kernel-xen-pvops as dom0 and see how it works
> (you can also try to use kernel-xen-pvops as a normal xen guest)
>
> Have fun...
>
> --
> Thomas
>

I tried testing on the laptop (i only have laptop, since i'm on holiday),
however:

i get the XEN messages from hypervisor, but after that, i get a blank
screen(nvidia chipset), even though it seems that the process goes
further. (i hear harddisk)

Now i always have trouble with nouveau, and nv seems to have removed my
9100M from supported devices, and i think i remember that nvidia mentioned
that their driver doesn't work with xen (that could have been changed)

since i have no other pc here, i cannot test ssh connections.

also, i'm not sure if it IS that, since i should be able to see the kernel
messages, no? (or is it the dualhead that is confusing xen and it's using
the external monitor port???)

anyways, after a while ~45secs, the numlock stops working, so i imagine X
is started and the keyb driver fails?

so i can't really test this kernel as dom0, which was my intention. but
doesn't it work due to XEN or due to this nvidia chipset???

on top of that, it seems that since the regular kernel update, my tty's
are now gone, and it seems to be staying in single user mode, even though
it boots level 5 and starts X.

that means F1 has messages, F7 has some others, and F8 has X, while F2-F6
no longer work...