Re: [Mageia-dev] proposal regarding (packager) mentoring program coordinator

[Daniel Kreuter]

Am 06/29/2011 11:27 PM, schrieb andre999:

Note that if someone shows an interest in getting involved with Mageia,
we don't have to focus only on packaging. We need all sorts of
contributions, and it would be useful to packagers to have other
experiences, such as bug triaging and QA. So far, it seems everyone it
the team is taking such an approach.



Someone who is only a developer should also have experience with packaging.

Re: [Mageia-dev] Anybody having high CPU by kded4 after upgrading to 4.6.90?

[Radu-Cristian FOTESCU]

> afaik ntrack, if that is a problem, why don't you try and recompile KDE 
> locally without ntrack? see if it improves stuff?

But _why_ is ntrack a *required* dependency of KDE as long as:
1. other distros don't have it, neither as required by KDE, nor as an 
independent library;
2. It is obviously *not* part of the KDE project.

No, I can't recompile KDE with my Celeron M-520, I am not suicidal.

R-C

Re: [Mageia-dev] [117096] rebuild

[Dexter Morgan]

On Fri, Jul 1, 2011 at 8:31 AM,   wrote:
> Revision 117096 Author fwang Date 2011-07-01 08:31:34 +0200 (Fri, 01 Jul
> 2011)
>
> Log Message
>
> rebuild
>

Please do not use only "rebuild" as log message.

We really should speak about a pre commit hook blocking this "simple" commit log

Re: [Mageia-dev] Anybody having high CPU by kded4 after upgrading to 4.6.90?

[Maarten Vanraes]

Op vrijdag 01 juli 2011 07:40:24 schreef Radu-Cristian FOTESCU:
> I was trying to investigate the kded4 high CPU load, and I started to
> investigate some upstream reports, even if not necessarily reported for
> 4.6.90.
> 
> Some such reports were related to ntrack, e.g. http://bugs.kde.org/268038
> 
> What the heck is ntrack and why do we need it? (The official description
> tells me exactly nothing).
> 
> There is *no* ntrack in either of Mandriva or Fedora -- it's actually
> likely to be an Ubuntu project; either way, it's definitely *not* part of
> the KDE4 project, as it's hosted on https://launchpad.net/ntrack
> 
> Then why the heck removing libntrack0 wants to remove *all* the KDE???
> 
> Is Mageia becoming Kubuntu?
> 
> All these excessive dependencies are making me sick. Everything depends on
> everything. Is dynamic loading of libraries, with dynamically getting
> pointers to functions and using them or not, depending on availability, a
> mechanism that only works in Windows?
> 
> Then, you'll excuse me, for the fist time in 9 days, I'll reboot into XP
> SP3.
> 
> And I'm doing that because, after having rebooted in F15, their plasma
> (4.6.3) crashed on me for 3 times in 5 minutes. This is unbearable.
> 
> Pissed off,
> R-C aka beranger

dude, it kind of pisses me off what i read here...

you're using "cauldron"; it's nice that you find these bugs so they can be 
fixed, but i mean... it's "cauldron", imho you can't expect s stable state in 
our "development version"... so please, do what everyone else does in 
cauldron:
 - use another DE if the current one is unworkable.

afaik ntrack, if that is a problem, why don't you try and recompile KDE 
locally without ntrack? see if it improves stuff?

Re: [Mageia-dev] Anybody having high CPU by kded4 after upgrading to 4.6.90?

[magnus]

2011/7/1 Marc Paré 

> Mine was doing this and I tried to stop it (I don't really know how to do
> this), so in the end I let it go. It has now stopped. Could it be that it is
> indexing all of your files? I know that I have 600 gigs of data, and, if
> KDE4 was trying to index all of these files (photos, music and larger
> LibreOffice files that it would take quite a while to index them.
>
> Maybe this is the problem? My CPU has returned to normal after a couple
> days of "churning". I also never log-out of my system.
>
> I don't believe.
My installation has no data.

One core is using continuously 100% (with sometimes switching the core)

Magnus

Re: [Mageia-dev] Anybody having high CPU by kded4 after upgrading to 4.6.90?

[Radu-Cristian FOTESCU]

I was trying to investigate the kded4 high CPU load, and I started to 
investigate some upstream reports, even if not necessarily reported for 4.6.90.

Some such reports were related to ntrack, e.g. http://bugs.kde.org/268038

What the heck is ntrack and why do we need it? (The official description tells 
me exactly nothing).

There is *no* ntrack in either of Mandriva or Fedora -- it's actually likely 
to be an Ubuntu project; either way, it's definitely *not* part of the KDE4 
project, as it's hosted on https://launchpad.net/ntrack

Then why the heck removing libntrack0 wants to remove *all* the KDE???

Is Mageia becoming Kubuntu?

All these excessive dependencies are making me sick. Everything depends on 
everything. Is dynamic loading of libraries, with dynamically getting pointers
to functions and using them or not, depending on availability, a mechanism 
that only works in Windows?

Then, you'll excuse me, for the fist time in 9 days, I'll reboot into XP SP3.

And I'm doing that because, after having rebooted in F15, their plasma (4.6.3)
crashed on me for 3 times in 5 minutes. This is unbearable.

Pissed off,
R-C aka beranger

[Mageia-dev] About the input method in KDE

[Kira]

https://bugs.mageia.org/show_bug.cgi?id=1836

There's a special plasmoid which can help with user experience of

those who used input method, but ever since the package request,

there's no response. Would someone help with this one?

Since we have determined to use iBus as the default input method,

then iBus version of kimpanel backend should be included, not just

scim version.

Re: [Mageia-dev] Anybody having high CPU by kded4 after upgrading to 4.6.90?

[Radu-Cristian FOTESCU]

> However here  killing this process does not seems to affect my plasmoids.

I'm surprised to see you writing it. After killing kded4:
1. Klipper was not reacting.
2. The keyboard layout systray icon was dead.
3. Any changes in the way the clock is displayed (hour/date format) were not 
applied.
4. Hibernation was completely broken (doing nothing), only logout, shutdown and 
restart worked.
5. Power Management profiles were not displayed and could not be editer, nor 
were they functional.

Other effects might have taken place, that was at first sight.

So kded4 is indeed a *vital* process of the KDE4 desktop.

> It could be an upstream bug but it would be nice to narrow it.
> @ first i was looking @ the nm applet, but a fresh install (by dropping all 
> package & only install the minimum aka kmail, dolphin,kdebase4-workspace)  
> does not fix the problem
> (there's an upstream bug related to kded with networkmanagement  kde 
> #220047)

Not easy to narrow it here either. 

If it's an upstream one (can't test 4.6.90 in other distro for now), then the 
upstream QA is non-existent.

R-C aka beranger

Re: [Mageia-dev] Anybody having high CPU by kded4 after upgrading to 4.6.90?

[Radu-Cristian FOTESCU]

> Well only kdepim is broken so it's not a big deal if you're not using 
> it.
> (You should be able to use akregator).

Yes, akregator works just fine.

R-C

Re: [Mageia-dev] Anybody having high CPU by kded4 after upgrading to 4.6.90?

[Radu-Cristian FOTESCU]

> Could it be that it is indexing all of your files? 

NOPE. I never ever use indexing, no matter what the OS is.

R-C

Re: [Mageia-dev] Anybody having high CPU by kded4 after upgrading to 4.6.90?

[Radu-Cristian FOTESCU]

>>  (This is making me crazy. Otherwise, I'll tell you some day about a
>>  bug/crash that was *accidentally* fixed by KDE 4.6.90.)
> 
> Which one ? ;o)

See
https://mageia.org/pipermail/mageia-dev/2011-July/006180.html

R-C

Re: [Mageia-dev] libperl not found

[Ahmad Samir]

On 1 July 2011 05:35, Thomas Spuhler  wrote:
> On Thursday, June 30, 2011 08:08:48 pm Ahmad Samir wrote:
>> On 1 July 2011 03:24, Thomas Spuhler  wrote:
>> > On Thursday, June 30, 2011 12:16:47 am Cazzaniga Sandro wrote:
>> >> Le 30/06/2011 06:54, Ahmad Samir a écrit :
>> >> > It seems libperl.so is hiding
>> >> >
>> >> >> It is wehre it should be but cyrus-imap cannot find it.
>> >>
>> >> Maybe we have to check cyrus-imap instead of libperl.so, so.
>> >
>> > it gives the pretty much same error if you want to rebuild it. I remember
>> > it still work with perl-514.0 but not with 5.14.1
>> >
>> > Below is the message
>> > # service cyrus-imapd start
>> > Starting cyrus-imapd: /usr/lib/cyrus-imapd/cyrus-master: error while
>> > loading shared libraries: libperl.so: cannot open shared object file: No
>> > such file or directory
>> >
>> > --
>> > Thomas
>>
>> net-snmp hardcodes the path to libperl.so, so it needed a rebuild,
>> I've submitted it.
> Thanks Ahmad
> Just curious, how did you find out?
>
> --
> Thomas
>

I sort of remembered from a previous perl upgrade that net-snmp was
the culprit behind cyrus-imapd didn't work after the upgrade, that
and:
$ ldd /usr/lib64/libnetsnmpagent.so.25
linux-vdso.so.1 =>  (0x7fff2c5ff000)
libnetsnmp.so.25 => /usr/lib64/libnetsnmp.so.25 (0x7f242c5ad000)
libwrap.so.0 => /lib64/libwrap.so.0 (0x7f242c3a2000)
libperl.so => not found
libpthread.so.0 => /lib64/libpthread.so.0 (0x7f242c186000)
libc.so.6 => /lib64/libc.so.6 (0x7f242be14000)
libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0 (0x7f242ba29000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x7f242b81)
/lib64/ld-linux-x86-64.so.2 (0x7f242cb1a000)
libdl.so.2 => /lib64/libdl.so.2 (0x7f242b60b000)

-- 
Ahmad Samir

Re: [Mageia-dev] libperl not found

[Thomas Spuhler]

On Thursday, June 30, 2011 08:08:48 pm Ahmad Samir wrote:
> On 1 July 2011 03:24, Thomas Spuhler  wrote:
> > On Thursday, June 30, 2011 12:16:47 am Cazzaniga Sandro wrote:
> >> Le 30/06/2011 06:54, Ahmad Samir a écrit :
> >> > It seems libperl.so is hiding
> >> > 
> >> >> It is wehre it should be but cyrus-imap cannot find it.
> >> 
> >> Maybe we have to check cyrus-imap instead of libperl.so, so.
> > 
> > it gives the pretty much same error if you want to rebuild it. I remember
> > it still work with perl-514.0 but not with 5.14.1
> > 
> > Below is the message
> > # service cyrus-imapd start
> > Starting cyrus-imapd: /usr/lib/cyrus-imapd/cyrus-master: error while
> > loading shared libraries: libperl.so: cannot open shared object file: No
> > such file or directory
> > 
> > --
> > Thomas
> 
> net-snmp hardcodes the path to libperl.so, so it needed a rebuild,
> I've submitted it.
Thanks Ahmad
Just curious, how did you find out?

-- 
Thomas

Re: [Mageia-dev] libperl not found

[Ahmad Samir]

On 1 July 2011 03:24, Thomas Spuhler  wrote:
> On Thursday, June 30, 2011 12:16:47 am Cazzaniga Sandro wrote:
>> Le 30/06/2011 06:54, Ahmad Samir a écrit :
>> > It seems libperl.so is hiding
>> >
>> >> It is wehre it should be but cyrus-imap cannot find it.
>>
>> Maybe we have to check cyrus-imap instead of libperl.so, so.
> it gives the pretty much same error if you want to rebuild it. I remember it
> still work with perl-514.0 but not with 5.14.1
>
> Below is the message
> # service cyrus-imapd start
> Starting cyrus-imapd: /usr/lib/cyrus-imapd/cyrus-master: error while loading
> shared libraries: libperl.so: cannot open shared object file: No such file or
> directory
>
> --
> Thomas
>

net-snmp hardcodes the path to libperl.so, so it needed a rebuild,
I've submitted it.

-- 
Ahmad Samir

Re: [Mageia-dev] Anybody having high CPU by kded4 after upgrading to 4.6.90?

[Thomas Spuhler]

On Thursday, June 30, 2011 05:23:58 pm Marc Paré wrote:
> Le 2011-06-30 18:34, Radu-Cristian FOTESCU a écrit :
> > This is making me crazy. After upgrading to KDE 4.6.90 (cauldron, of
> > course), the bloody m*f*er kded4 (the worse idea in KDE4) constantly
> > takes 55-75% CPU.
> > 
> > Of course, killing it is possible, but this affects the plasmoids. (E.g.
> > it made me inadvertently filling an invalid bug report 1981, which
> > disappeared once I let kded4 live.)
> > 
> > Really, isn't anybody experiencing high CPU from kded4?
> > 
> > (This is making me crazy. Otherwise, I'll tell you some day about a
> > bug/crash that was *accidentally* fixed by KDE 4.6.90.)
> > 
> > Thanks,
> > R-C aka beranger
> 
> Mine was doing this and I tried to stop it (I don't really know how to
> do this), so in the end I let it go. It has now stopped. Could it be
> that it is indexing all of your files? I know that I have 600 gigs of
> data, and, if KDE4 was trying to index all of these files (photos, music
> and larger LibreOffice files that it would take quite a while to index
> them.
> 
> Maybe this is the problem? My CPU has returned to normal after a couple
> days of "churning". I also never log-out of my system.
> 
> Cheers
> 
> Marc
I get 50% on a VM
-- 
Thomas

Re: [Mageia-dev] libperl not found

[Thomas Spuhler]

On Thursday, June 30, 2011 12:16:47 am Cazzaniga Sandro wrote:
> Le 30/06/2011 06:54, Ahmad Samir a écrit :
> > It seems libperl.so is hiding
> > 
> >> It is wehre it should be but cyrus-imap cannot find it.
> 
> Maybe we have to check cyrus-imap instead of libperl.so, so.
it gives the pretty much same error if you want to rebuild it. I remember it 
still work with perl-514.0 but not with 5.14.1

Below is the message
# service cyrus-imapd start
Starting cyrus-imapd: /usr/lib/cyrus-imapd/cyrus-master: error while loading 
shared libraries: libperl.so: cannot open shared object file: No such file or 
directory

-- 
Thomas

Re: [Mageia-dev] Anybody having high CPU by kded4 after upgrading to 4.6.90?

[Marc Paré]

Le 2011-06-30 18:34, Radu-Cristian FOTESCU a écrit :

This is making me crazy. After upgrading to KDE 4.6.90 (cauldron, of
course), the bloody m*f*er kded4 (the worse idea in KDE4) constantly
takes 55-75% CPU.

Of course, killing it is possible, but this affects the plasmoids. (E.g.
it made me inadvertently filling an invalid bug report 1981, which
disappeared once I let kded4 live.)

Really, isn't anybody experiencing high CPU from kded4?

(This is making me crazy. Otherwise, I'll tell you some day about a
bug/crash that was *accidentally* fixed by KDE 4.6.90.)

Thanks,
R-C aka beranger


Mine was doing this and I tried to stop it (I don't really know how to 
do this), so in the end I let it go. It has now stopped. Could it be 
that it is indexing all of your files? I know that I have 600 gigs of 
data, and, if KDE4 was trying to index all of these files (photos, music 
and larger LibreOffice files that it would take quite a while to index them.


Maybe this is the problem? My CPU has returned to normal after a couple 
days of "churning". I also never log-out of my system.


Cheers

Marc

Re: [Mageia-dev] Anybody having high CPU by kded4 after upgrading to 4.6.90?

[Balcaen John]

On Thursday 30 June 2011 16:10:46 Radu-Cristian FOTESCU wrote:
[...]
> Now, I know my KDE is somewhat b0rken, because akonadiserver can't start --
> but I could live just fine this way in KDE 4.6.3-4.6.4, if not even better
> than with it.
> 
Well only kdepim is broken so it's not a big deal if you're not using it.
(You should be able to use akregator).

-- 
Balcaen John
Jabber ID: mik...@jabber.littleboboy.net

Re: [Mageia-dev] Anybody having high CPU by kded4 after upgrading to 4.6.90?

[Balcaen John]

On Thursday 30 June 2011 15:34:50 Radu-Cristian FOTESCU wrote:
> This is making me crazy. After upgrading to KDE 4.6.90 (cauldron, of
> course), the bloody m*f*er kded4 (the worse idea in KDE4) constantly takes
> 55-75% CPU.

> Of course, killing it is possible, but this affects the plasmoids. (E.g. it
> made me inadvertently filling an invalid bug report 1981, which disappeared
> once I let kded4 live.)

> Really, isn't anybody experiencing high CPU from kded4?
Nop you're not the only one.
However here  killing this process does not seems to affect my plasmoids.
It could be an upstream bug but it would be nice to narrow it.
@ first i was looking @ the nm applet, but a fresh install (by dropping all 
package & only install the minimum aka kmail, dolphin,kdebase4-workspace)  
does not fix the problem
 (there's an upstream bug related to kded with networkmanagement  kde #220047)

> 
> (This is making me crazy. Otherwise, I'll tell you some day about a
> bug/crash that was *accidentally* fixed by KDE 4.6.90.)

Which one ? ;o)

-- 
Balcaen John
Jabber ID: mik...@jabber.littleboboy.net

Re: [Mageia-dev] [115962]

[Zé]

2011/6/30 Balcaen John :
> On Thursday 30 June 2011 22:09:15 Zé wrote:
>> 2011/6/29 John Balcaen :
>> > 2011/6/29  :
>> >> Revision 115962 Author ze Date 2011-06-29 15:57:57 +0200 (Wed, 29 Jun
>> >> 2011)
>> >>
>> >> Log Message
>> >>
>> >> - no need to buildrequire and use kde-macros
>> >> - use rpm native macros and not variables
>> >
>> > [...]
>> > We were using kde4-macros especially because attica is maintained &
>> > requires by KDE, so it's easier to follow it (like a urpmf --requires
>> > kde4-macros Core_Release_SRPMS )
>>
>> Since attica only needs qt4 theres no need to use kde-macros, thats
>> why you also have qt cmake macros like %cmake_qt4
> I know that it's just using qt4 but we're using kde4 macros as convention here
> following our kde's spec layout.

But that layout is to apply for kde packages and for the ones that
require kde, when thats not the case why is there any need to apply
kde macros?
I dont see the point for that.


> --
> Balcaen John
> Jabber ID: mik...@jabber.littleboboy.net
>



-- 
Zé

Re: [Mageia-dev] Anybody having high CPU by kded4 after upgrading to 4.6.90?

[Eugeni Dodonov]

On Thu, Jun 30, 2011 at 20:10, Radu-Cristian FOTESCU
wrote:

>
> > The solution which worked most of the time for such issues in kde 4.6.xx
> was:
> > 1. open a terminal
> > 2. run killall plasma-desktop
> > 3. plasma-desktop
> >
> > the plasmoids and the desktop come back, and kded4 stops using that much
> CPU.
> >
> > Last time I looked what it was looking CPU at, it was caused by some
> run-away timer loop
>
> > deep in kdelibs, but as those issues are quite random I haven't figured
> out what exactly causes this.
>
>
> Евгений, thank you, but this is not a solution.
>
> It is not a solution because, as soon as plasma-desktop is back, kded4
> takes the same 55...75% CPU.
>
>
This is a different issues from the one had in mind than, nevermind, I think
you should wait from a proper fix from KDE for this :).

-- 
Eugeni Dodonov
http://eugeni.dodonov.net/

Re: [Mageia-dev] Anybody having high CPU by kded4 after upgrading to 4.6.90?

[Radu-Cristian FOTESCU]

> The solution which worked most of the time for such issues in kde 4.6.xx was:
> 1. open a terminal
> 2. run killall plasma-desktop
> 3. plasma-desktop
>
> the plasmoids and the desktop come back, and kded4 stops using that much CPU.
>
> Last time I looked what it was looking CPU at, it was caused by some run-away 
> timer loop 

> deep in kdelibs, but as those issues are quite random I haven't figured out 
> what exactly causes this. 


Евгений, thank you, but this is not a solution.

It is not a solution because, as soon as plasma-desktop is back, kded4 takes 
the same 55...75% CPU.

It is not a solution because, even if it were a temporary fix, it needed to be 
run after each and every login.

Now, I know my KDE is somewhat b0rken, because akonadiserver can't start -- but 
I could live just fine this way in KDE 4.6.3-4.6.4, if not even better than 
with it.

So I should report this as a bug, however I won't do it as long as I'm the only 
Cauldron user to experience it.

OTOH, let me tell you how to crash *any* KDE4 version (have to report it 
upstream, works on F15 too):
1. Folder View for the Desktop.
2. Click on a desktop icon, F2 (rename), select the text, right-click (as a 
reflex to find a menu with Copy);
3. plasma-desktop glorious crash.

Here's the KDE bug that was fixed by accident in KDE 4.6.90:
Upstream bug 235020, with duplicates 228036, 236800, 256257, 255393, 256993, 
257591, 262912, 264287, 264664, 265064, 265823, 266245, 270591, 272198, 272662, 
274792, 274135, 274659, 275301, 275906, 275906, 276020, 276261.
In short: KCharSelect crashes in some circumstances.
How to make KCharSelect crash on any version up to and including 4.6.4:
1. Open KCharSelect and make it have the minimum horizontal size (it should 
display 18 characters on a row; if it doesn't, keep it at this size 
nevertheless);
2. Select the "DejaVu Sans" or any other DejaVu typeface.
3. Keep "European Alphabets" in the first drop-down list.
4. In the second drop-down list, start to switch the code pages between the 
available ones, in order:
-- Basic Latin
-- Latin-1 Supplement
-- Latin Extended A
-- Latin Extended B
-- Latin Extended Additional
-- Latin Extended C
-- Latin Extended D
and so on.
5. It should have crashed by now. If not, keep switching back and forth between 
the code pages until it does!
The bug is actually triggered by unknown errors in some fonts (the DejaVu 
family being one of them).

It's funny to use KDE4 (I was a GNOME guy, that is, until GNOME Shell was 
announced). Except that kded4 is not funny.

Best regards,
R-C aka beranger

Re: [Mageia-dev] [RFC] Update to Gnome 3.1

[Dexter Morgan]

On Fri, Jul 1, 2011 at 12:41 AM, nicolas vigier  wrote:
> On Thu, 30 Jun 2011, Dexter Morgan wrote:
>
>> Hello,
>>
>> i would like us to update to gnome 3.1 ( which will give gnome 3.2 ).
>
> When is the release of gnome 3.2 planned ?
>
>

in october so  we will at least have gnome 3.2.x   in mageia 2

Re: [Mageia-dev] Anybody having high CPU by kded4 after upgrading to 4.6.90?

[Eugeni Dodonov]

On Thu, Jun 30, 2011 at 19:34, Radu-Cristian FOTESCU
wrote:

> This is making me crazy. After upgrading to KDE 4.6.90 (cauldron, of
> course), the bloody m*f*er kded4 (the worse idea in KDE4) constantly takes
> 55-75% CPU.
>
> Of course, killing it is possible, but this affects the plasmoids. (E.g. it
> made me inadvertently filling an invalid bug report 1981, which disappeared
> once I let kded4 live.)
>

The solution which worked most of the time for such issues in kde 4.6.xx
was:
1. open a terminal
2. run killall plasma-desktop
3. plasma-desktop

the plasmoids and the desktop come back, and kded4 stops using that much
CPU.

Last time I looked what it was looking CPU at, it was caused by some
run-away timer loop deep in kdelibs, but as those issues are quite random I
haven't figured out what exactly causes this.

-- 
Eugeni Dodonov
http://eugeni.dodonov.net/

Re: [Mageia-dev] [RFC] Update to Gnome 3.1

[nicolas vigier]

On Thu, 30 Jun 2011, Dexter Morgan wrote:

> Hello,
> 
> i would like us to update to gnome 3.1 ( which will give gnome 3.2 ).

When is the release of gnome 3.2 planned ?

[Mageia-dev] Anybody having high CPU by kded4 after upgrading to 4.6.90?

[Radu-Cristian FOTESCU]

This is making me crazy. After upgrading to KDE 4.6.90 (cauldron, of course), 
the bloody m*f*er kded4 (the worse idea in KDE4) constantly takes 55-75% CPU.

Of course, killing it is possible, but this affects the plasmoids. (E.g. it 
made me inadvertently filling an invalid bug report 1981, which disappeared 
once I let kded4 live.)

Really, isn't anybody experiencing high CPU from kded4? 


(This is making me crazy. Otherwise, I'll tell you some day about a bug/crash 
that was *accidentally* fixed by KDE 4.6.90.)


Thanks,
R-C aka beranger

Re: [Mageia-dev] Firefox 5

[nicolas vigier]

On Thu, 23 Jun 2011, Luc Menut wrote:

> Le 23/06/2011 07:58, Dexter Morgan a écrit :
>> On Thu, Jun 23, 2011 at 7:29 AM, Thierry Vignaud
>>   wrote:
>>> On 22 June 2011 19:41, Florian Hubold  wrote:
> Well, it's quite possible that we have to include that in Mageia 1 as
> well, as this will be security update for Firefox 4. If we don't want to
> patch every CVE then we have to include it into Mageia 1 as well..
>
>
> ...
>>
>> But i think sec team need to speak of FF5 first because i think this
>> will be a candidate for updates regarding new firefox upstream policy
>>
>
> Yes, I think Firefox 5 should be an updates.
> Firefox 5 is a security update for Firefox 4 and 4.0.1. There will be no 
> Firefox 4.0.2.

Yes, as patch to fix security are not provided for firefox 4, and not
easy to backport, it needs to be updated to version 5. It is listed as
an exception on the updates policy page :
http://mageia.org/wiki/doku.php?id=updates_policy

Re: [Mageia-dev] Update of backport, policy proposal

[andre999]

Samuel Verschelde a écrit :


Le mardi 28 juin 2011 03:44:24, andre999 a écrit :


2) Backports would not be removed from repos when a newer backport arrives,
except those affected by security updates.
This allows reverting to previous backports if a user finds a problem with
a backport on their system.


I'd prefer that we don't keep multiple backports versions in the repositories,
for the sake of simplicity. Users who ask for the latest must accept that
sometimes the latest is not the greatest. Plus, we have the backports_testing
repos so that users can test and spot bugs before the old backport is replaced
with the new one.

I want stable : don't use backports.
I want the latest : use backports.
I want an intermediate version : no, sorry, your need is too specific. You can
still compile it.


I'm trying to consider the needs of a typical backport user, who needs to revert 
to a previous version of a backport already installed, due to problems with a 
newer backport.
A problem which will often affect only some users installing the particular 
backport.


They won't activate the backport repository.  So when installing backports, they 
will only see a list of backports (at least via rpmdrake).

They are not necessarily familiar with compiling (unlike most of us).

Suppose for a package release A we have issued backports B and C.
If B causes problems on a particular system, the user reverts to A.
No problem.
If a user has installed B, which worked well for them,
 and subsequently installes C which has problems,
 they would like to revert to B.
(Reverting to A could cause a loss of data as well as functionality.)

So why tell the user that they can't revert to a backport version that already 
worked for them ?


I would suggest a message such as :
"users installing backports should install the latest version for the package 
unless they need to revert to a previous version due to problems"

(To appear only when they have chosen to install backports.)

I realise that this complicates the presentation, and maybe another solution 
could be found.
(For example, saving all backports packages installed on a system, so that they 
can be reinstalled.)
(A case-by-case analysis of new backports could show which previous backports 
could be safely removed, for minor changes such as simple bug fixes.)


Or maybe make these backports only visible with urpmi, so that users of the 
graphic interfaces won't see them.  (As someone else suggested.)
This would of course require the graphic interfaces to avoid displaying these 
older backports, but would provide the other advantages of keeping the backports.


Keeping previous backports would facilitate producing security updates for all 
backports actually installed on various user's systems.

This adds some complexity for security updates, in exchange for greater 
security.


Samuel


--
André

Re: [Mageia-dev] [115962]

[Balcaen John]

On Thursday 30 June 2011 22:09:15 Zé wrote:
> 2011/6/29 John Balcaen :
> > 2011/6/29  :
> >> Revision 115962 Author ze Date 2011-06-29 15:57:57 +0200 (Wed, 29 Jun
> >> 2011)
> >> 
> >> Log Message
> >> 
> >> - no need to buildrequire and use kde-macros
> >> - use rpm native macros and not variables
> > 
> > [...]
> > We were using kde4-macros especially because attica is maintained &
> > requires by KDE, so it's easier to follow it (like a urpmf --requires
> > kde4-macros Core_Release_SRPMS )
> 
> Since attica only needs qt4 theres no need to use kde-macros, thats
> why you also have qt cmake macros like %cmake_qt4
I know that it's just using qt4 but we're using kde4 macros as convention here 
following our kde's spec layout.

-- 
Balcaen John
Jabber ID: mik...@jabber.littleboboy.net

Re: [Mageia-dev] [115561] add versioned requires for common package

[Zé]

2011/6/29 John Balcaen :
> 2011/6/29  :
>> Revision 115561 Author fwang Date 2011-06-29 06:48:40 +0200 (Wed, 29 Jun
> [...]
>> Modified: cauldron/libkipi/current/SPECS/libkipi.spec
>> ===
>> --- cauldron/libkipi/current/SPECS/libkipi.spec       2011-06-29 04:47:46 
>> UTC (rev
>> 115560)
>> +++ cauldron/libkipi/current/SPECS/libkipi.spec       2011-06-29 04:48:40 
>> UTC (rev
>> 115561)
>> @@ -39,7 +39,7 @@
>>  %package -n %{libkipi}
>>  Summary: libkipi library
>>  Group: System/Libraries
>> -Requires: kipi-common
>> +Requires: kipi-common = %{epoch}:%{version}
> [...]
> Should we really have a library requiring an other package ? (via an
> explicit Requires i mean)
> (maybe we should move this requires to somewhere else ? )
>

I remember we did agreed on this, that a lib package having explicite
requires is not a good idea, but since the require already existed
there i just set versioning

But as you now know this is being fixed :)

-- 
Zé

Re: [Mageia-dev] [115962]

[Zé]

2011/6/29 John Balcaen :
> 2011/6/29  :
>> Revision 115962 Author ze Date 2011-06-29 15:57:57 +0200 (Wed, 29 Jun 2011)
>>
>> Log Message
>>
>> - no need to buildrequire and use kde-macros
>> - use rpm native macros and not variables
>>
> [...]
> We were using kde4-macros especially because attica is maintained &
> requires by KDE, so it's easier to follow it (like a urpmf --requires
> kde4-macros Core_Release_SRPMS )

Since attica only needs qt4 theres no need to use kde-macros, thats
why you also have qt cmake macros like %cmake_qt4


> --
> --
> Balcaen John
>



-- 
Zé

[Mageia-dev] [RFC] Update to Gnome 3.1

[Dexter Morgan]

Hello,

i would like us to update to gnome 3.1 ( which will give gnome 3.2 ).

Is there someone against ?

Re: [Mageia-dev] Need mentor(s) to become a Mageia packager

[magnus]

2011/6/30 Vincent 

> Hi All,
>
> I would like to participate to your project and to help you by packaging
> rpms.
>
> As I don't know what needs to be packed, I've tried to make rpm for
> ZoneMinder 1.24.4. But it fails to install into BUILDROOT environment. I
> must have done something wrong while setting installation destinations.
>
> Attached is the spec file, and the patch to make it compiled.
>
> If any mentor could help me, or assign me something else to pack, I would
> be glad.
>
> Regards
>
> Thanks for your proposal, of course any help on packaging side is welcome.
Here are some wiki page to read about mentoring process:
http://mageia.org/wiki/doku.php?id=packaging&s[]=mentor#packagers_organization
http://mageia.org/wiki/doku.php?id=packaging&s[]=mentor#resources
http://mageia.org/wiki/doku.php?id=packages_mentoring
and
http://mageia.org/wiki/doku.php?id=packager_start

You can apply here on -dev ML looking for a mentor

Also we have weekly meeting on IRC you can attend if you are around

Welcome on board (or in hell as you want)

At the moment we are organizing a mentoring team.
Please have some patience.

Regards

Magnus


> Vincent
>

[Mageia-dev] Need mentor(s) to become a Mageia packager

[Vincent]

Hi All,

I would like to participate to your project and to help you by packaging
rpms.

As I don't know what needs to be packed, I've tried to make rpm for
ZoneMinder 1.24.4. But it fails to install into BUILDROOT environment. I
must have done something wrong while setting installation destinations.

Attached is the spec file, and the patch to make it compiled.

If any mentor could help me, or assign me something else to pack, I would be
glad.

Regards


Vincent
--- ./src/zm_rtsp.cpp.orig	2011-06-30 13:37:20.175609094 -0400
+++ ./src/zm_rtsp.cpp	2011-06-30 13:37:46.618610480 -0400
@@ -311,7 +311,7 @@
 }
 catch( const Exception &e )
 {
-Error( e.getMessage().c_str() );
+Error( "%s", e.getMessage().c_str() );
 return( -1 );
 }
 
--- ./src/zm_signal.cpp.orig	2011-06-30 13:44:42.850610241 -0400
+++ ./src/zm_signal.cpp	2011-06-30 13:48:02.785610651 -0400
@@ -109,7 +109,7 @@
 	char **messages = backtrace_symbols( trace, trace_size );
 if ( size_t offset = strcspn( messages[trace_size-1], " " ) )
 {
-snprintf( cmd_ptr, sizeof(cmd)-(cmd_ptr-cmd), messages[trace_size-1] );
+snprintf( cmd_ptr, sizeof(cmd)-(cmd_ptr-cmd), "%s", messages[trace_size-1] );
 cmd_ptr += offset;
 }
 else
@@ -123,7 +123,7 @@
 cmd_ptr += snprintf( cmd_ptr, sizeof(cmd)-(cmd_ptr-cmd), " %p", trace[i] );
 }
 	Info( "Backtrace complete, please execute the following command for more information" );
-Info( cmd );
+Info( "%s", cmd );
 #endif // HAVE_DECL_BACKTRACE
 #endif // ( HAVE_SIGINFO_T && HAVE_UCONTEXT_T ) || HAVE_STRUCT_SIGCONTEXT
 #endif // ZM_NO_CRASHTRACE
%define	name	ZoneMinder
%define version 1.24.4
%define release %mkrel 1

Summary:	ZoneMinder, the all-in one Linux GPL'd security camera solution.
Name:		%{name}
Version:	%{version}
Release:	%{release}
URL:		http://www.zoneminder.com/
Source0:	http://www2.zoneminder.com/downloads/%{name}-%{version}.tar.gz
Patch0: ZoneMinder-1.24.4-src.patch
License:	GPLV2 or later
Group:		Multimedia

BuildRequires: automake
BuildRequires: ffmpeg
BuildRequires: gnutls-devel
BuildRequires: %{_lib}ffmpeg-devel
BuildRequires: %{_lib}gnutls-devel
BuildRequires: %{_lib}jpeg-devel
BuildRequires: %{_lib}mysql-devel
BuildRequires: %{_lib}pcre-devel
BuildRequires: perl(Archive::Tar)
BuildRequires: perl(Archive::Zip)
BuildRequires: perl(Date::Manip)
BuildRequires: perl(DBD::mysql)
BuildRequires: perl(Device::SerialPort)
BuildRequires: perl(MIME::Lite)


%description
Welcome to ZoneMinder, the all-in-one Linux GPL'd security camera solution.
A while back my garage was burgled and all my power tools were stolen! I realized shortly after that if I'd just had a camera overlooking the door then at least I'd have know exactly when and who did the dirty deed. And so ZoneMinder was born. It's still relatively new but hopefully it has developed into something that can be genuinely useful and prevent similar incidents or even perhaps bring some perpetrators to justice.
PROPOSED ADDITION Most commercial "security systems" are designed as a monitoring system that also records. Recording quality can vary from bad to unusable, locating the relevant video can range from challenging to impractical, and exporting can often only be done with the manual present. ZoneMinder was designed primarily to record, and allow easy searches and exporting. Recordings are of the best possible quality, easy to filter and find, and simple to export using any system with a web browser. It also monitors.
ZoneMinder is designed around a series of independent components that only function when necessary limiting any wasted resource and maximising the efficiency of your machine. A fairly ancient Pentium II PC should be able to track one camera per device at up to 25 frames per second with this dropping by half approximately for each additional camera on the same device. Additional cameras on other devices do not interact so can maintain this frame rate. Even monitoring several cameras still will not overload the CPU as frame processing is designed to synchronise with capture and not stall it.
As well as being fast ZoneMinder is designed to be friendly and even more than that, actually useful. As well as the fast video interface core it also comes with a user friendly and comprehensive PHP based web interface allowing you to control and monitor your cameras from home, at work, on the road, or even a web enabled cell phone. It supports variable web capabilities based on available bandwidth. The web interface also allows you to view events that your cameras have captured and archive them or review them time and again, or delete the ones you no longer wish to keep. The web pages directly interact with the core daemons ensuring full co-operation at all times. ZoneMinder can even be installed as a system service ensuring it is right there if your computer has to reboot for any reason.
The core of ZoneMinder is the capture and analysis of images and ther

Re: [Mageia-dev] Update of backport, policy proposal

[Olivier]

> Le mardi 28 juin 2011 03:44:24, andre999 a écrit :
> > 2) Backports would not be removed from repos when a newer backport
> > arrives, except those affected by security updates.
> > This allows reverting to previous backports if a user finds a problem
> > with a backport on their system.
> 
> I'd prefer that we don't keep multiple backports versions in the
> repositories, for the sake of simplicity. Users who ask for the latest
> must accept that sometimes the latest is not the greatest. Plus, we have
> the backports_testing repos so that users can test and spot bugs before
> the old backport is replaced with the new one.
> 
> I want stable : don't use backports.
> I want the latest : use backports.
> I want an intermediate version : no, sorry, your need is too specific. You
> can still compile it.
> 
> Samuel
Le mardi 28 juin 2011 03:44:24, andre999 a écrit :
> 
> 2) Backports would not be removed from repos when a newer backport arrives,
> except those affected by security updates.
> This allows reverting to previous backports if a user finds a problem with
> a backport on their system.

I'd prefer that we don't keep multiple backports versions in the repositories, 
for the sake of simplicity. Users who ask for the latest must accept that 
sometimes the latest is not the greatest. Plus, we have the backports_testing 
repos so that users can test and spot bugs before the old backport is replaced 
with the new one. 

I want stable : don't use backports.
I want the latest : use backports.
I want an intermediate version : no, sorry, your need is too specific. You can 
still compile it.

Samuel

Well sometimes latest version comes with bug corrections so it may be 
considered as more stable than the previous version.

Olivier

Re: [Mageia-dev] Update of backport, policy proposal

[nicolas vigier]

On Thu, 30 Jun 2011, Samuel Verschelde wrote:

> 
> Le mardi 28 juin 2011 03:44:24, andre999 a écrit :
> > 
> > 2) Backports would not be removed from repos when a newer backport arrives,
> > except those affected by security updates.
> > This allows reverting to previous backports if a user finds a problem with
> > a backport on their system.
> 
> I'd prefer that we don't keep multiple backports versions in the 
> repositories, 
> for the sake of simplicity. Users who ask for the latest must accept that 
> sometimes the latest is not the greatest. Plus, we have the backports_testing 
> repos so that users can test and spot bugs before the old backport is 
> replaced 
> with the new one. 
> 
> I want stable : don't use backports.
> I want the latest : use backports.
> I want an intermediate version : no, sorry, your need is too specific. You 
> can 
> still compile it.

I think we can still keep the old versions on the repository. urpmi will
install the last one, but allow advanced users to use rpm manually to
install an older version if needed. However I don't think we should make
updates on older versions.

Re: [Mageia-dev] Update of backport, policy proposal

[Samuel Verschelde]

Le jeudi 30 juin 2011 15:59:21, Samuel Verschelde a écrit :
> Le vendredi 24 juin 2011 02:15:03, Michael Scherer a écrit :
> > However, this mean that someone will have to check if the bug
> > is fixed, and the question is "who" ( and I do not have a answer that I
> > find good enough yet ). This could even be more tricky if we consider
> > that this can be a version upgrade, and a security fix. Even if we trust
> > the upstream to fix the security issue, we still want to have it
> > working.
> 
> That's a good question, given that priority will be given to stable updates
> testing rather than backports. With a big security team I would say "the
> security team", but for now I would trust the upstream here.

Or rather, "the packager who backported the software, with the help of the 
security team and/or QA team if needed".

Samuel

Re: [Mageia-dev] Update of backport, policy proposal

[Samuel Verschelde]

Le mardi 28 juin 2011 03:44:24, andre999 a écrit :
> 
> 2) Backports would not be removed from repos when a newer backport arrives,
> except those affected by security updates.
> This allows reverting to previous backports if a user finds a problem with
> a backport on their system.

I'd prefer that we don't keep multiple backports versions in the repositories, 
for the sake of simplicity. Users who ask for the latest must accept that 
sometimes the latest is not the greatest. Plus, we have the backports_testing 
repos so that users can test and spot bugs before the old backport is replaced 
with the new one. 

I want stable : don't use backports.
I want the latest : use backports.
I want an intermediate version : no, sorry, your need is too specific. You can 
still compile it.

Samuel

Re: [Mageia-dev] Update of backport, policy proposal

[Samuel Verschelde]

Le vendredi 24 juin 2011 02:15:03, Michael Scherer a écrit :
> Hi,
> 
> The last mail from the backport trilogy. And like all good trilogy,
> that's where the suspens is present ( as for the 1 and 2 part, you know
> there is another episode )
> 
> This mail is about handling update on the backport repository. Either
> new version, or bugfix, or security upgrade.
> 
> Everybody was focused on "should we do patch, or should we do more
> backport" issue, but the real problem is not really here.
> 
> First, we have to decide what kind of update do we want to see, among
> the 3 types :
> - bugfixes
> - security bug fixes,
> - new version

As I said in another thread, I think that for backports we can allow ourselves 
to rely more heavily on the upstream projects than we do for stable updates.

- we try to provide the new upstream stable versions when asked for and 
conform to the policy
- we guarantee support for packaging bugs (those are "our" bugs)
- for bugs :
-- they are fixed in a new upstream stable version : we provide it.
-- they are not : we don't fix them. We're providing the latest from upstream, 
those bugs have to be fixed upstream.
-- complex cases : fix available upstream but in a development branch and no 
release soon, or new version non backportable for technical or policy reasons 
=> we patch
-- of course nothing prevents diligent packagers from going farther and 
putting more energy in bug fixing when upstream is failing, but it's not what 
we promise to do for all backports.
- security bugs : I see 2 options. The easier for us is to treat them like the 
other bugs : rely on upstream fixes. Maybe this gives an acceptable level of 
risk. The other solution is a "full" security process similar to the one we 
have for stable updates. I would start with the first one and see later if we 
can switch to the second one.

For comparison, the level of support for stable updates is :
- we try to bring as little changes to the package as possible, with the ideal 
situation being not having to issue updates at all,
- we guarantee support for packaging bugs (those are "our" bugs)
- for bugs :
-- they are fixed upstream : we backport patches from upstream newer releases, 
or provide upstream new stable bugfix-only releases. Occasionnally a non bugfix-
only new version can be provided, with a sufficient amount of QA and if the new 
version doesn't change users habits too much.
-- they are not fixed upstream : we try to fix it ourselves or get patches from 
other distributions
- security bugs : fully supported, even more than standard bugs, and without 
waiting for users to report security bugs.

As we have to explain what the differences in terms of support between updates 
and backports is, to ourselves but also to users, here is how I would describe 
it :
- "updates : report bugs to us first."
- "backports : ask for a newer stable version if a bug has been fixed there, or 
report bugs to both the software's developers and us"


> 
> Then as we want to have working backports, I think we need to do test,
> like we do for normal backports, or updates. This mean someone need to
> test, besides the packagers.
> 
> For the first one, we can assume that if there is a bug, someone will
> fill it. Then we can assign it to the one that backported to fix the
> packages, and ask the reporter to test.

Agreed.

> 
> 
> For the 3rd one, I guess we can use the same as 1st one. If no one ask,
> do nothing. If someone ask, do the same as others backports, and erase
> the previous one.

Agreed.

> 
> 
> For the 2nd one, it all depend on how we find out about security issues.
> A tool like the one used by debian/ubuntu that check for each package if
> the version is vulnerable or not could help packager to know if a
> backport requires a fix or not, like this is done for the others
> packages. 

That could help indeed, such a tool could automatically create a bug report in 
bugzilla via XML-RPC for example. Useful for stable updates also of course.

> However, this mean that someone will have to check if the bug
> is fixed, and the question is "who" ( and I do not have a answer that I
> find good enough yet ). This could even be more tricky if we consider
> that this can be a version upgrade, and a security fix. Even if we trust
> the upstream to fix the security issue, we still want to have it
> working.

That's a good question, given that priority will be given to stable updates 
testing rather than backports. With a big security team I would say "the 
security team", but for now I would trust the upstream here.

> 
> But besides this question, there is a more important problem. If we
> think that some packages updates are important enough to be sent to user
> without them asking for explicitly, we cannot let people pick only some
> packages on demand by disabling backports.
> 
> Either backports source is enabled in urpmi, and this would mean that
> backports are treated like update from a user point of view, or the
> 

Re: [Mageia-dev] updates-announce mailing list

[nicolas vigier]

On Thu, 30 Jun 2011, Manuel Hiebel wrote:

> Le jeudi 30 juin 2011 à 14:33 +0200, nicolas vigier a écrit :
> > Hello,
> > 
> > People who want to receive notifications of updates on the stable release
> > can subscribe to the updates-announce mailing list :
> > https://ml.mageia.org/wwsympa-wrapper.fcgi/info/updates-announce
> > 
> Is there a simple web page planned? like
> http://www.mandriva.com/fr/support/security/advisories/?dis=2010.1

Yes. It is not done yet, but it is planned.

https://www.mageia.org/pipermail/mageia-dev/2011-June/006092.html

Re: [Mageia-dev] updates-announce mailing list

[Manuel Hiebel]

Le jeudi 30 juin 2011 à 14:33 +0200, nicolas vigier a écrit :
> Hello,
> 
> People who want to receive notifications of updates on the stable release
> can subscribe to the updates-announce mailing list :
> https://ml.mageia.org/wwsympa-wrapper.fcgi/info/updates-announce
> 
Is there a simple web page planned? like
http://www.mandriva.com/fr/support/security/advisories/?dis=2010.1

[Mageia-dev] updates-announce mailing list

[nicolas vigier]

Hello,

People who want to receive notifications of updates on the stable release
can subscribe to the updates-announce mailing list :
https://ml.mageia.org/wwsympa-wrapper.fcgi/info/updates-announce

Re: [Mageia-dev] [RPM] cauldron core/release libkdeedu-4.6.90-4.mga2

[Dexter Morgan]

On Thu, Jun 30, 2011 at 1:01 PM, Funda Wang  wrote:
> 2011/6/30 Balcaen John :
>> On Thursday 30 June 2011 04:45:15 Mageia Team wrote:
>>> Name        : libkdeedu                    Relocations: (not relocatable)
>>> Version     : 4.6.90                            Vendor: Mageia.Org
>>> Release     : 4.mga2                        Build Date: Thu Jun 30 04:40:17
>>> 2011 Install Date: (not installed)               Build Host: ecosse
>>> Group       : Graphical desktop/KDE         Source RPM: (none)
>>> Size        : 204136                           License: GPLv2
>>> Signature   : (none)
>>> Packager    : Mageia Team 
>>> URL         : http://edu.kde.org
>>> Summary     : Free Educational Software based on the KDE technologies
>>> Description :
>>> Runtime library for KDE Education Application
>>>
>>> fwang  4.6.90-4.mga2:
>>> + Revision: 116239
>>> - do not obsolete old packages
>>
>> I do understand that you don't wont to obsolete kdeedu,but without the
>> obsolete kdeedu-core & kdeedu-devel would have been stick for ever on the
>> mirror until a sysadmin intervention.
> Agree. But such a task shouldn't be pushed into packaging, and we have
> already push needed conflicts so that it won't affect users.



don't forget to tell to your lovely sysadmin team the packages you
want to be removed ;)

Re: [Mageia-dev] [RPM] cauldron core/release libkdeedu-4.6.90-4.mga2

[Balcaen John]

On Thursday 30 June 2011 04:45:15 Mageia Team wrote:
> Name: libkdeeduRelocations: (not relocatable)
> Version : 4.6.90Vendor: Mageia.Org
> Release : 4.mga2Build Date: Thu Jun 30 04:40:17
> 2011 Install Date: (not installed)   Build Host: ecosse
> Group   : Graphical desktop/KDE Source RPM: (none)
> Size: 204136   License: GPLv2
> Signature   : (none)
> Packager: Mageia Team 
> URL : http://edu.kde.org
> Summary : Free Educational Software based on the KDE technologies
> Description :
> Runtime library for KDE Education Application
> 
> fwang  4.6.90-4.mga2:
> + Revision: 116239
> - do not obsolete old packages

I do understand that you don't wont to obsolete kdeedu,but without the 
obsolete kdeedu-core & kdeedu-devel would have been stick for ever on the 
mirror until a sysadmin intervention.

-- 
Balcaen John
Jabber ID: mik...@jabber.littleboboy.net

Re: [Mageia-dev] [RPM] cauldron core/release libkdeedu-4.6.90-4.mga2

[Funda Wang]

2011/6/30 Balcaen John :
> On Thursday 30 June 2011 04:45:15 Mageia Team wrote:
>> Name        : libkdeedu                    Relocations: (not relocatable)
>> Version     : 4.6.90                            Vendor: Mageia.Org
>> Release     : 4.mga2                        Build Date: Thu Jun 30 04:40:17
>> 2011 Install Date: (not installed)               Build Host: ecosse
>> Group       : Graphical desktop/KDE         Source RPM: (none)
>> Size        : 204136                           License: GPLv2
>> Signature   : (none)
>> Packager    : Mageia Team 
>> URL         : http://edu.kde.org
>> Summary     : Free Educational Software based on the KDE technologies
>> Description :
>> Runtime library for KDE Education Application
>>
>> fwang  4.6.90-4.mga2:
>> + Revision: 116239
>> - do not obsolete old packages
>
> I do understand that you don't wont to obsolete kdeedu,but without the
> obsolete kdeedu-core & kdeedu-devel would have been stick for ever on the
> mirror until a sysadmin intervention.
Agree. But such a task shouldn't be pushed into packaging, and we have
already push needed conflicts so that it won't affect users.

>
> --
> Balcaen John
> Jabber ID: mik...@jabber.littleboboy.net
>

Re: [Mageia-dev] How is the obsoleted binaries be removed?

[Colin Guthrie]

'Twas brillig, and Michael Scherer at 30/06/11 10:08 did gyre and gimble:
> Le jeudi 30 juin 2011 à 09:41 +0100, Colin Guthrie a écrit :
>> 'Twas brillig, and Funda Wang at 30/06/11 00:11 did gyre and gimble:
>>> 2011/6/30 Dexter Morgan :
 On Wed, Jun 29, 2011 at 7:42 PM, Zé  wrote:
> 2011/6/27 Funda Wang :
>> Hello,
>>
>> How is the obsoleted binaries be removed currently in Mageia? Does the
>> maintainer need to call for this? If yes, please remove
>> lib{,64}devhelp-2_1 from cauldron.
>>
>> Thanks.
>>
> whats current problem?
>
> You can obsolete it through BS, add an entry in the spec about it.
>

 our policy is to not obsolete libs.
>>> Then the repository will contain a lot of orphan libs.
>>
>> I think Dexter was just replying to Ze rather than yourself Funda.
>> Meaning we don't obsolete libs in the spec file (as was true in mdv), so
>> removing old libs no longer used internally is still a manual
>> (rpmctl-type) task.
> 
> I do not know if I proposed that already, but what about moving rpms
> without source rpms after 2 weeks ( or 1 month ) ?
> 
> ( and later remove the file after 1 month ). This let us the time to
> rebuild everything, and provides automated cleaning ?

I agree in principle, but I would say:

 1. Move rpms with no src.rpm after 2 weeks when there are no
(unobsoleted) rpms that depend on it.
 2. If other rpms do depend on it, send an automated mail to cauldron to
tell people to rebuild them against the newer lib.

Other than that small caveat... yeah it seems like a nice idea!

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/]

Re: [Mageia-dev] [116351]

[Dexter Morgan]

On Thu, Jun 30, 2011 at 11:24 AM,   wrote:
> Revision 116351 Author ze Date 2011-06-30 11:24:58 +0200 (Thu, 30 Jun 2011)
>
> Log Message
>
> - set default files attibutes

No this is useless, please remove them

Re: [Mageia-dev] How is the obsoleted binaries be removed?

[Dexter Morgan]

On Thu, Jun 30, 2011 at 11:08 AM, Michael Scherer  wrote:
> Le jeudi 30 juin 2011 à 09:41 +0100, Colin Guthrie a écrit :
>> 'Twas brillig, and Funda Wang at 30/06/11 00:11 did gyre and gimble:
>> > 2011/6/30 Dexter Morgan :
>> >> On Wed, Jun 29, 2011 at 7:42 PM, Zé  wrote:
>> >>> 2011/6/27 Funda Wang :
>>  Hello,
>> 
>>  How is the obsoleted binaries be removed currently in Mageia? Does the
>>  maintainer need to call for this? If yes, please remove
>>  lib{,64}devhelp-2_1 from cauldron.
>> 
>>  Thanks.
>> 
>> >>> whats current problem?
>> >>>
>> >>> You can obsolete it through BS, add an entry in the spec about it.
>> >>>
>> >>
>> >> our policy is to not obsolete libs.
>> > Then the repository will contain a lot of orphan libs.
>>
>> I think Dexter was just replying to Ze rather than yourself Funda.
>> Meaning we don't obsolete libs in the spec file (as was true in mdv), so
>> removing old libs no longer used internally is still a manual
>> (rpmctl-type) task.
>
> I do not know if I proposed that already, but what about moving rpms
> without source rpms after 2 weeks ( or 1 month ) ?
>
> ( and later remove the file after 1 month ). This let us the time to
> rebuild everything, and provides automated cleaning ?
>
> --
> Michael Scherer
>
>

i agree with this and as they are on old/ we still can revive some if
needed ( like a rebuild not done, ... )

Re: [Mageia-dev] How is the obsoleted binaries be removed?

[Michael Scherer]

Le jeudi 30 juin 2011 à 09:41 +0100, Colin Guthrie a écrit :
> 'Twas brillig, and Funda Wang at 30/06/11 00:11 did gyre and gimble:
> > 2011/6/30 Dexter Morgan :
> >> On Wed, Jun 29, 2011 at 7:42 PM, Zé  wrote:
> >>> 2011/6/27 Funda Wang :
>  Hello,
> 
>  How is the obsoleted binaries be removed currently in Mageia? Does the
>  maintainer need to call for this? If yes, please remove
>  lib{,64}devhelp-2_1 from cauldron.
> 
>  Thanks.
> 
> >>> whats current problem?
> >>>
> >>> You can obsolete it through BS, add an entry in the spec about it.
> >>>
> >>
> >> our policy is to not obsolete libs.
> > Then the repository will contain a lot of orphan libs.
> 
> I think Dexter was just replying to Ze rather than yourself Funda.
> Meaning we don't obsolete libs in the spec file (as was true in mdv), so
> removing old libs no longer used internally is still a manual
> (rpmctl-type) task.

I do not know if I proposed that already, but what about moving rpms
without source rpms after 2 weeks ( or 1 month ) ?

( and later remove the file after 1 month ). This let us the time to
rebuild everything, and provides automated cleaning ?

-- 
Michael Scherer

Re: [Mageia-dev] How is the obsoleted binaries be removed?

[Colin Guthrie]

'Twas brillig, and Funda Wang at 30/06/11 00:11 did gyre and gimble:
> 2011/6/30 Dexter Morgan :
>> On Wed, Jun 29, 2011 at 7:42 PM, Zé  wrote:
>>> 2011/6/27 Funda Wang :
 Hello,

 How is the obsoleted binaries be removed currently in Mageia? Does the
 maintainer need to call for this? If yes, please remove
 lib{,64}devhelp-2_1 from cauldron.

 Thanks.

>>> whats current problem?
>>>
>>> You can obsolete it through BS, add an entry in the spec about it.
>>>
>>
>> our policy is to not obsolete libs.
> Then the repository will contain a lot of orphan libs.

I think Dexter was just replying to Ze rather than yourself Funda.
Meaning we don't obsolete libs in the spec file (as was true in mdv), so
removing old libs no longer used internally is still a manual
(rpmctl-type) task.

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/]

Re: [Mageia-dev] [116308]

[Dexter Morgan]

On Thu, Jun 30, 2011 at 8:38 AM,   wrote:
> Revision 116308 Author ze Date 2011-06-30 08:38:32 +0200 (Thu, 30 Jun 2011)
>
> Log Message
>
> - add missing files
> - fix minor errors
> - list dirs so that can be removed in uninstall
>
> Modified Paths
>
> cauldron/kdenetwork4/current/SPECS/kdenetwork4.spec
>
> Modified: cauldron/kdenetwork4/current/SPECS/kdenetwork4.spec
> ===
> --- cauldron/kdenetwork4/current/SPECS/kdenetwork4.spec   2011-06-30 
> 06:13:28
> UTC (rev 116307)
> +++ cauldron/kdenetwork4/current/SPECS/kdenetwork4.spec   2011-06-30 
> 06:38:32
> UTC (rev 116308)
> @@ -95,15 +95,11 @@
>
>  %files -n kde4-filesharing
>  %defattr(-,root,root)
> -%_kde_libdir/kde4/fileshare_propsdlgplugin.so
> -%_kde_libdir/kde4/kcm_fileshare.so
> -%_kde_libdir/kde4/kcm_kcmsambaconf.so
> -%_kde_services/fileshare.desktop
> -%_kde_services/fileshare_propsdlgplugin.desktop
> -%_kde_services/kcmsambaconf.desktop
> +%_kde_libdir/kde4/sambausershareplugin.so
> +%_kde_services/sambausershareplugin.desktop
>  %_kde_services/ServiceMenus/smb2rdc.desktop
> -%_kde_iconsdir/*/*/apps/kcmsambaconf.*
>
> +
>  #-
>  %package -n kdnssd
>  Summary:   DNS-SD Service Discovery Monitor
> @@ -124,7 +120,7 @@
>  %_kde_services/zeroconf.protocol
>
>  #-
> -%define libkgetcore %mklibname kgetcore %{%major}
> +%define libkgetcore %mklibname kgetcore %{major}
>
>  %package -n %libkgetcore
>  Summary: Runtime library for KGET
> @@ -135,7 +131,7 @@
>
>  %files -n %libkgetcore
>  %defattr(-,root,root)
> -%_kde_libdir/libkgetcore.so.%{%major}*
> +%_kde_libdir/libkgetcore.so.%{major}*
>
>  #-
>  %package -n kget
> @@ -159,23 +155,28 @@
>  %defattr(-,root,root)
>  %_kde_bindir/kget
>  %_kde_appsdir/kget
> +%_kde_applicationsdir/kget.desktop
>  %_kde_libdir/kde4/krunner_kget.so
>  %_kde_libdir/kde4/kget_*
>  %_kde_libdir/kde4/plasma_engine_kget.so
>  %_kde_libdir/kde4/kcm_kget_checksumsearchfactory.so
>  %_kde_libdir/kde4/kcm_kget_metalinkfactory.so
>  %_kde_services/plasma-engine-kget.desktop
> -%_kde_datadir/applications/kde4/kget.desktop
>  %_kde_services/ServiceMenus/kget_download.desktop
>  %_kde_datadir/config.kcfg/kget*
>  %_kde_services/kget_*
>  %_kde_datadir/kde4/servicetypes/kget_*
> +%dir %_kde_appsdir/dolphinpart/kpartplugins/
>  %_kde_appsdir/dolphinpart/kpartplugins/kget_plug_in.rc
>  %_kde_appsdir/dolphinpart/kpartplugins/kget_plug_in.desktop
> +%dir %_kde_appsdir/khtml/kpartplugins/

Dirs must be owned by only one  rpm. Do you think clever to own those
ones by kdenetwork4 ? i don't think.

I will revert and fix a better way

Re: [Mageia-dev] libperl not found

[Cazzaniga Sandro]

Le 30/06/2011 06:54, Ahmad Samir a écrit :
> It seems libperl.so is hiding
>> It is wehre it should be but cyrus-imap cannot find it.
Maybe we have to check cyrus-imap instead of libperl.so, so.

-- 
Sandro Cazzaniga - https://lederniercoupdarchet.wordpress.com
IRC: Kharec (irc.freenode.net)
Software/Hardware geek
Conceptor
Magnum's Coordinator/editor (http://magnum.tuxfamily.org)
Mageia and Mandriva contributor