Hi all.
In my ocsinventory.spec file:
Requires php-gd
ocsinventory builds successfully
When I install the package with urpmi:
[root@cualdron64 noarch]# urpmi ocsinventory-*
Para satisfacer la dependencia «php-gd», se necesita uno de los paquetes
siguientes:
1- php-gd-5.3.15-1.mga2.x86_64: GD
'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
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
On Sunday, August 26, 2012 03:52:24 AM Bersuit Vera wrote:
Hi all.
In my ocsinventory.spec file:
Requires php-gd
ocsinventory builds successfully
When I install the package with urpmi:
[root@cualdron64 noarch]# urpmi ocsinventory-*
Para satisfacer la dependencia «php-gd», se necesita
* 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
On 26 August 2012 19:07, eatdirt dirt...@gmail.com wrote:
Hi there,
package A is on mga2 and run at uninstall
%_preun_service myserv
package B (different name) obsoletes package A and at install run
%_post_service myserv
same name for myserv.
When I run this, the old package %preun
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
On Mon, 27 Aug 2012 02:10:04 +0200 (CEST)
tmb wrote:
Name: kernel-tmb Relocations: (not
relocatable) Version : 3.5.3 Vendor:
Mageia.Org Release : 1.mga3Build Date:
Mon Aug 27 00:41:55 2012 Install Date: (not
On 15 August 2012 16:05, pterjan buildsystem-dae...@mageia.org wrote:
pterjan pterjan 0.6.6-1.r5364.1.mga3:
+ Revision: 281419
- Update to new svn snapshot
* Fixes default media name (s/Main/Core/)
* Improves chroot handling
* Support using btrfs snaphots
can we please do real releases?
On 8 August 2012 10:56, Pascal Terjan pter...@gmail.com wrote:
Initial btrfs support
In case someone is interested:
- It works fine here
Errr, I've some serious doubts...
You added a 'config' parameter to clean_all_chroot_tmp()
... but you never pass it
some sudo commands will just fail
Is it a big change from mga2?
I did test 3 months ago in a 2tb disk, eventually i lost info.
Enviado desde mi DROID 4G LTE de Verizon Wireless
Thierry Vignaud thierry.vign...@gmail.com escribió:
On 8 August 2012 10:56, Pascal Terjan pter...@gmail.com wrote:
Initial btrfs support
In case
11 matches
Mail list logo