Re: [Mageia-dev] Package removal proposal

2012-08-26 Thread Colin Guthrie
'Twas brillig, and Johnny A. Solbu at 25/08/12 02:42 did gyre and gimble:
 On Saturday 25 August 2012 02:33, Olivier Thauvin wrote:
 For me obsolete should be reserved for replacements or rename, nothing
 more.
 
 I agree on this.

So in two years time, we add a new package with the same filename as one
of these old package, we may get some very strange edge cases on package
upgrades/installer because keeping these old, no longer shipped packages
installed is still supported (of course this could happen even if the
old package were obsoleted properly, due to package install order on
upgrades)

What about when there are security issues in the old package? Do we just
drop it and then wash our hands of the whole affair and don't give a
crap when a user's system is completely compromised?

In my opinion we should run a tight ship. If users want to use something
we no longer ship, then they still have several choices:
 1. Don't install task-obsolete and add it to their skip.list.
 2. Do a local compile+install into /usr/local of the software in question
 3. Package it and become a contributor (assuming the reason for
dropping the package was due to a lack of maintainer rather than a
specific desire/reason (i.e. legal))

For all of these options the user is both informed and can make a very
clear, concious choice about how they want to proceed and know the
consequences of doing so.


Obsoletes in packages which genuinely replace the old one seem
reasonable and uncontroversial.

Col

-- 

Colin Guthrie
colin(at)mageia.org
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] Package removal proposal

2012-08-26 Thread Sander Lepik

Sander

26.08.2012 17:15, Colin Guthrie kirjutas:
 'Twas brillig, and Johnny A. Solbu at 25/08/12 02:42 did gyre and gimble:
 On Saturday 25 August 2012 02:33, Olivier Thauvin wrote:
 For me obsolete should be reserved for replacements or rename, nothing
 more.
 I agree on this.
 So in two years time, we add a new package with the same filename as one
 of these old package, we may get some very strange edge cases on package
 upgrades/installer because keeping these old, no longer shipped packages
 installed is still supported (of course this could happen even if the
 old package were obsoleted properly, due to package install order on
 upgrades)

 What about when there are security issues in the old package? Do we just
 drop it and then wash our hands of the whole affair and don't give a
 crap when a user's system is completely compromised?

 In my opinion we should run a tight ship. If users want to use something
 we no longer ship, then they still have several choices:
  1. Don't install task-obsolete and add it to their skip.list.
  2. Do a local compile+install into /usr/local of the software in question
  3. Package it and become a contributor (assuming the reason for
 dropping the package was due to a lack of maintainer rather than a
 specific desire/reason (i.e. legal))

 For all of these options the user is both informed and can make a very
 clear, concious choice about how they want to proceed and know the
 consequences of doing so.


 Obsoletes in packages which genuinely replace the old one seem
 reasonable and uncontroversial.

 Col

What about new feature. Some txt file (containing obsoleted package per line 
and probably
can be signed somehow) in the mirrors that can be updated by sysadmins. During 
update urpmi
will check this file and will compare with local file where user has marked 
what (s)he wants
to do with those packages (obsoleted package status: keep/remove per line). 
If urpmi
finds package that hasn't been listed in local file it will ask the user what 
to do with it
+ will show warning that all possible security problems are not our problem 
anymore.


Re: [Mageia-dev] Package removal proposal

2012-08-26 Thread Olivier Thauvin
* Colin Guthrie (mag...@colin.guthr.ie) wrote:
 In my opinion we should run a tight ship. If users want to use something
 we no longer ship, then they still have several choices:
  1. Don't install task-obsolete and add it to their skip.list.

As obsoletes are automatically promote, there is no way to keep a package
except adding it to skip.list.

  3. Package it and become a contributor (assuming the reason for
 dropping the package was due to a lack of maintainer rather than a
 specific desire/reason (i.e. legal))

Sys admin work is not to make package.

 
 For all of these options the user is both informed and can make a very
 clear, concious choice about how they want to proceed and know the
 consequences of doing so.

This system silently remove packages. I am pretty sure a lot of people
will wonder why some need libraries get removed from their system at
each update...

-- 

Olivier Thauvin
CNRS  -  LATMOS
♖ ♘ ♗ ♕ ♔ ♗ ♘ ♖


pgpZbZplvQTXW.pgp
Description: PGP signature


Re: [Mageia-dev] Package removal proposal

2012-08-26 Thread Charles A Edwards
On Sun, 26 Aug 2012 15:15:04 +0100
Colin Guthrie wrote:

 Obsoletes in packages which genuinely replace the old one seem
 reasonable and uncontroversial.

It is both reasonable and uncontroversial because the User is given the
choice.

With obsoletes in packages Before any installation or package removal
via urpmi/rpmdrake
1)  user is informed that rpm A must be removed for other rpms to
be updated
2)  user is given the option y/n before the installation/removal
proceeds.

If using task-obsolete 
1)  user does not know Which or When rpm/s will be removed
2)  user does not know Why the rpm must be removed
3)  user has no choice as this is all occurring in secret   


Charles


-- 
// Minor lesson: don't fuck about with something you don't fully
understand -- the dosdoom source code
--
Mageia release 3 (Cauldron) for x86_64$
On SuperSizehttp://www.eslrahc.com
Registered Linux user #182463
3.5.2-tmb-server-1.mga3 x86_64
--


signature.asc
Description: PGP signature


Re: [Mageia-dev] Package removal proposal

2012-08-24 Thread Guillaume Rousse

Le 24/08/2012 16:43, Colin Guthrie a écrit :

'Twas brillig, and Guillaume Rousse at 23/08/12 20:01 did gyre and gimble:

Le 20/08/2012 20:49, Guillaume Rousse a écrit :

Unless someone step it to fix pending issues, those packages should
better get dropped.

I just removed madwifi-sources, apache-mod_python and apache-mod_ruby
from the subversion repository. I need an admin to remove the
corresponding packages (including the debug ones) from the distribution
tree.


By removed do you mean svn mv'ed to the obsolete folder?

No, svn rm'ed.



I think that's generally better than removing (and we can potentially
use it to prevent people importing packages that are listed there should
they come in without knowing).

Agreed. Hence the point of writing the procedure somewhere.

--
If you improve or tinker with something long enough, eventually it will 
break or malfunction

-- Murphy's In Laws n°8


Re: [Mageia-dev] Package removal proposal

2012-08-24 Thread Luis Daniel Lucio Quiroz
I think removing mod python and ruby is an error

Enviado desde mi DROID 4G LTE de Verizon Wireless

Colin Guthrie mag...@colin.guthr.ie escribió:

'Twas brillig, and Guillaume Rousse at 23/08/12 20:01 did gyre and gimble:
 Le 20/08/2012 20:49, Guillaume Rousse a écrit :
 Unless someone step it to fix pending issues, those packages should
 better get dropped.
 I just removed madwifi-sources, apache-mod_python and apache-mod_ruby
 from the subversion repository. I need an admin to remove the
 corresponding packages (including the debug ones) from the distribution
 tree.

By removed do you mean svn mv'ed to the obsolete folder?

I think that's generally better than removing (and we can potentially
use it to prevent people importing packages that are listed there should
they come in without knowing).

Col


-- 

Colin Guthrie
colin(at)mageia.org
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/
Email Shield provided by NOCWorldWide.com


Re: [Mageia-dev] Package removal proposal

2012-08-24 Thread Olivier Blin
Guillaume Rousse guillomovi...@gmail.com writes:

 Le 24/08/2012 16:43, Colin Guthrie a écrit :
 'Twas brillig, and Guillaume Rousse at 23/08/12 20:01 did gyre and gimble:
 Le 20/08/2012 20:49, Guillaume Rousse a écrit :
 Unless someone step it to fix pending issues, those packages should
 better get dropped.
 I just removed madwifi-sources, apache-mod_python and apache-mod_ruby
 from the subversion repository. I need an admin to remove the
 corresponding packages (including the debug ones) from the distribution
 tree.

 By removed do you mean svn mv'ed to the obsolete folder?
 No, svn rm'ed.

 I think that's generally better than removing (and we can potentially
 use it to prevent people importing packages that are listed there should
 they come in without knowing).
 Agreed. Hence the point of writing the procedure somewhere.

You mean like already done here? :)
https://wiki.mageia.org/en/Packaging_guidelines#Obsoleting_a_package

-- 
Olivier Blin - blino


Re: [Mageia-dev] Package removal proposal

2012-08-24 Thread Guillaume Rousse

Le 24/08/2012 16:58, Luis Daniel Lucio Quiroz a écrit :

I think removing mod python and ruby is an error
Well, that's a bit late... However, feel free to resurect them from the 
subversion repository, if you're ready to take maintainership of course.


--
BOFH excuse #341:

HTTPD Error 666 : BOFH was here


Re: [Mageia-dev] Package removal proposal

2012-08-24 Thread Guillaume Rousse

Le 24/08/2012 17:04, Olivier Blin a écrit :

Agreed. Hence the point of writing the procedure somewhere.


You mean like already done here? :)
https://wiki.mageia.org/en/Packaging_guidelines#Obsoleting_a_package
Ah, great. Excepted that I disagree with the 'thou shall force users to 
remove the package also', by using obsolete tags.


--
BOFH excuse #436:

Daemon escaped from pentagram


Re: [Mageia-dev] Package removal proposal

2012-08-24 Thread Johnny A. Solbu
On Saturday 25 August 2012 02:33, Olivier Thauvin wrote:
 For me obsolete should be reserved for replacements or rename, nothing
 more.

I agree on this.

-- 
Johnny A. Solbu
PGP key ID: 0xFA687324


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


Re: [Mageia-dev] Package removal proposal

2012-08-23 Thread Guillaume Rousse

Le 20/08/2012 20:49, Guillaume Rousse a écrit :

Unless someone step it to fix pending issues, those packages should
better get dropped.
I just removed madwifi-sources, apache-mod_python and apache-mod_ruby 
from the subversion repository. I need an admin to remove the 
corresponding packages (including the debug ones) from the distribution 
tree.


--
BOFH excuse #19:

floating point processor overflow


Re: [Mageia-dev] Package removal proposal

2012-08-21 Thread Bersuit Vera
Hi
The agent is ready and the server will be asap.
I'm a eager rookie and so I'll do my best, but bare in mind that I'm just a
rookie that juancho decides

Salut Bersuit.

2012/8/21 Guillaume Rousse guillomovi...@gmail.com

 Le 21/08/2012 02:44, Juan Luis Baptiste a écrit :

  On Mon, Aug 20, 2012 at 3:17 PM, Guillaume Rousse
 guillomovi...@gmail.com wrote:

 Le 20/08/2012 21:20, Damien Lallement a écrit :

 - ocsinventory-server and ocsinventory-agent: unmaintained, several
 pending security updates, better alternatives available (glpi +
 fusioninventory-agent)



 Noo, I'm using it for a customer of my company.
 I think that it's hard to remove this package as glpi/funsioninventory
 are better alternatives, sure, but not compatible with ocsinventory-*.
 So, for me, it's not an alternative but an other solution.


 Meaning you're volonteering for maintainership ?


 We're working on these two packages with one of my apprentices, so
 there's no need to drop them.

 So just take over maintainership. we're working on it is not a clear
 status.

 --
 BOFH excuse #61:

 not approved by the FCC



Re: [Mageia-dev] Package removal proposal

2012-08-21 Thread Thierry Vignaud
On 20 August 2012 21:15, David Walser luigiwal...@yahoo.com wrote:
 abrt/libreport/btparser - tool for sending bug reports to RedHat, does not 
 seem
   to belong in Mageia, our drakxtools have their own tool for sending crash
   reports to our bugzilla, unpatched security issues.
   https://bugs.mageia.org/show_bug.cgi?id=6523

These actually help me to catch some segfault in some gnome packages
from times to times.


Re: [Mageia-dev] Package removal proposal

2012-08-21 Thread Juan Luis Baptiste
On Tue, Aug 21, 2012 at 2:20 AM, Guillaume Rousse
guillomovi...@gmail.com wrote:

 We're working on these two packages with one of my apprentices, so
 there's no need to drop them.

 So just take over maintainership. we're working on it is not a clear
 status.


Done.


-- 
Juancho


[Mageia-dev] Package removal proposal

2012-08-20 Thread Guillaume Rousse

Here are several packages candidate for removal:

- apache-mod_python: doesn't build with apache 2.4, unmaintained 
upstream, dropped from fedora, no response from current maintainer 
(https://bugs.mageia.org/show_bug.cgi?id=7024)


- apache-mod_ruby: doesn't build with apache 2.4, unmaintained upstream

- ocsinventory-server and ocsinventory-agent: unmaintained, several 
pending security updates, better alternatives available (glpi + 
fusioninventory-agent)


- madwifi-sources: no maintainer, no binaries available in the 
distribution, considered as deprecated


Unless someone step it to fix pending issues, those packages should 
better get dropped.

--
BOFH excuse #180:

ether leak


Re: [Mageia-dev] Package removal proposal

2012-08-20 Thread David Walser
Guillaume Rousse guillomovitch@... writes:
 Here are several packages candidate for removal:
 - apache-mod_python
 - apache-mod_ruby
 - ocsinventory-server and ocsinventory-agent
 - madwifi-sources

Agreed, and there are surely other unmaintained packages that lack sufficient
need or interest to stay and should be dropped as well.

Furthermore, what is the procedure for dropping a package?  The wicd package is
broken and has unpatched security vulnerabilities[1].  It was previously asked
on this list if it should be dropped, nobody objected, a bug was filed asking
to drop it an assigned to sysadmin-b...@ml.mageia.org [2], but it hasn't been
dropped as far as I know.

[1] - https://bugs.mageia.org/show_bug.cgi?id=5608
[2] - https://bugs.mageia.org/show_bug.cgi?id=5926

Some other candidates for removal that come to mind:

abrt/libreport/btparser - tool for sending bug reports to RedHat, does not seem
  to belong in Mageia, our drakxtools have their own tool for sending crash
  reports to our bugzilla, unpatched security issues.
  https://bugs.mageia.org/show_bug.cgi?id=6523

sos - another RedHat-specific thing, unpatched security issues.
  https://bugs.mageia.org/show_bug.cgi?id=6525

libgnomesu - really old and unmaintained upstream, unpatched security issues,
  probably not needed.
  https://bugs.mageia.org/show_bug.cgi?id=7068

I'm sure there are plenty of other good candidates.



Re: [Mageia-dev] Package removal proposal

2012-08-20 Thread Antoine Pitrou
On Mon, 20 Aug 2012 20:49:05 +0200
Guillaume Rousse
guillomovi...@gmail.com wrote:
 Here are several packages candidate for removal:
 
 - apache-mod_python: doesn't build with apache 2.4, unmaintained 
 upstream, dropped from fedora, no response from current maintainer 
 (https://bugs.mageia.org/show_bug.cgi?id=7024)

Nobody uses mod_python anymore, mod_wsgi has been the official
superseder for years.

Regards

Antoine.


-- 
Software development and contracting: http://pro.pitrou.net




Re: [Mageia-dev] Package removal proposal

2012-08-20 Thread Damien Lallement

Le 20/08/2012 20:49, Guillaume Rousse a écrit :

Here are several packages candidate for removal:

[...]

- ocsinventory-server and ocsinventory-agent: unmaintained, several
pending security updates, better alternatives available (glpi +
fusioninventory-agent)


Noo, I'm using it for a customer of my company.
I think that it's hard to remove this package as glpi/funsioninventory 
are better alternatives, sure, but not compatible with ocsinventory-*.

So, for me, it's not an alternative but an other solution.


[...]


My 2cts
--
Damien Lallement
twitter: damsweb - IRC: damsweb/coincoin


Re: [Mageia-dev] Package removal proposal

2012-08-20 Thread Damien Lallement

Le 20/08/2012 22:17, Guillaume Rousse a écrit :

Le 20/08/2012 21:20, Damien Lallement a écrit :

Le 20/08/2012 20:49, Guillaume Rousse a écrit :

Here are several packages candidate for removal:

[...]

- ocsinventory-server and ocsinventory-agent: unmaintained, several
pending security updates, better alternatives available (glpi +
fusioninventory-agent)


Noo, I'm using it for a customer of my company.
I think that it's hard to remove this package as glpi/funsioninventory
are better alternatives, sure, but not compatible with ocsinventory-*.
So, for me, it's not an alternative but an other solution.

Meaning you're volonteering for maintainership ?


If I don't have any choice, I am.
/me hides :-)
--
Damien Lallement
twitter: damsweb - IRC: damsweb/coincoin


Re: [Mageia-dev] Package removal proposal

2012-08-20 Thread David Walser
Damien Lallement mageia@... writes:
 Le 20/08/2012 22:17, Guillaume Rousse a écrit :
  Meaning you're volonteering for maintainership ?
 
 If I don't have any choice, I am.
 /me hides 

Thanks Damien.  Here you go.
https://bugs.mageia.org/show_bug.cgi?id=5252
https://bugs.mageia.org/show_bug.cgi?id=2129



Re: [Mageia-dev] Package removal proposal

2012-08-20 Thread Manuel Hiebel

Le 2012-08-20 21:15, David Walser a écrit :

Guillaume Rousse guillomovitch@... writes:

Here are several packages candidate for removal:
- apache-mod_python
- apache-mod_ruby
- ocsinventory-server and ocsinventory-agent
- madwifi-sources


Agreed, and there are surely other unmaintained packages that lack 
sufficient

need or interest to stay and should be dropped as well.

Furthermore, what is the procedure for dropping a package?  The wicd
package is
broken and has unpatched security vulnerabilities[1].  It was
previously asked
on this list if it should be dropped, nobody objected, a bug was 
filed asking
to drop it an assigned to sysadmin-b...@ml.mageia.org [2], but it 
hasn't been

dropped as far as I know.

[1] - https://bugs.mageia.org/show_bug.cgi?id=5608
[2] - https://bugs.mageia.org/show_bug.cgi?id=5926

Some other candidates for removal that come to mind:

abrt/libreport/btparser - tool for sending bug reports to RedHat,
does not seem
  to belong in Mageia, our drakxtools have their own tool for sending 
crash

  reports to our bugzilla, unpatched security issues.
  https://bugs.mageia.org/show_bug.cgi?id=6523

sos - another RedHat-specific thing, unpatched security issues.
  https://bugs.mageia.org/show_bug.cgi?id=6525

libgnomesu - really old and unmaintained upstream, unpatched security 
issues,

  probably not needed.
  https://bugs.mageia.org/show_bug.cgi?id=7068

I'm sure there are plenty of other good candidates.


Some months ago, we were speaking of removing all unmainted packages, I 
guess this out of brain nowadays ?




Re: [Mageia-dev] Package removal proposal

2012-08-20 Thread Damien Lallement

Le 20/08/2012 22:56, David Walser a écrit :

Damien Lallement mageia@... writes:

Le 20/08/2012 22:17, Guillaume Rousse a écrit :

Meaning you're volonteering for maintainership ?


If I don't have any choice, I am.
/me hides


Thanks Damien.  Here you go.
https://bugs.mageia.org/show_bug.cgi?id=5252
https://bugs.mageia.org/show_bug.cgi?id=2129


Amazing but on my side, I'm not happy enough to thank you. ;-)


--
Damien Lallement
twitter: damsweb - IRC: damsweb/coincoin


Re: [Mageia-dev] Package removal proposal

2012-08-20 Thread Juan Luis Baptiste
On Mon, Aug 20, 2012 at 3:17 PM, Guillaume Rousse
guillomovi...@gmail.com wrote:
 Le 20/08/2012 21:20, Damien Lallement a écrit :
 - ocsinventory-server and ocsinventory-agent: unmaintained, several
 pending security updates, better alternatives available (glpi +
 fusioninventory-agent)


 Noo, I'm using it for a customer of my company.
 I think that it's hard to remove this package as glpi/funsioninventory
 are better alternatives, sure, but not compatible with ocsinventory-*.
 So, for me, it's not an alternative but an other solution.

 Meaning you're volonteering for maintainership ?

We're working on these two packages with one of my apprentices, so
there's no need to drop them.

Cheers,

-- 
Juancho