Bug#768112: fixed in slurm-llnl 14.03.9-4

2014-11-28 Thread Mehdi Dogguy 

Hi Adam,

Thanks for adding the tag and for the unblock!

Le 2014-11-26 20:08, Adam D. Barratt a écrit :


I'm not sure acceptable is really the right word, and I've argued 
with

myself a bunch over this, particularly given that sinfo+slurm-llnl is
basically a closed set for dependency purposes, with a combined popcon
of ~100.



FWIW, slurm-llnl falls in the case of the packages usually installed in
environments without any internet connectivity or where popcon is 
disabled.
At work here, FWIW, we have _thousands_ of machines using this package. 
I
also know a few similar places with the same size and configuration. 
Slurm

is the most used job scheduler in the HPC world. It became a reference
in the field.

So really, popcon should not be a way to appreciate the importance of 
the

package. I agree it is not easy though since we don't always have the
necessary data to measure that.

Regards,

--
Mehdi


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#768112: fixed in slurm-llnl 14.03.9-4

2014-11-26 Thread Adam D. Barratt 
Control: tags -1 + jessie-ignore

On Sat, 2014-11-08 at 16:24 +0100, Mehdi Dogguy wrote:
 Le 2014-11-08 10:53, Adam D. Barratt a écrit :
  Control: reopen -1
  
  On 2014-11-06 10:21, Gennaro Oliva wrote:
  Source: slurm-llnl
  Source-Version: 14.03.9-4
  We believe that the bug you reported is fixed in the latest version 
  of
  slurm-llnl, which is due to be installed in the Debian FTP archive.
  [...]
   slurm-llnl (14.03.9-4) unstable; urgency=medium
   .
 * Declaring slurm-client conflict with sinfo (Closes: #768112)
  
  No. Please re-read policy (specifically 10.1) - you don't get to
  conflict with other packages just because you both want to use the
  same file path.
  
 
 I think that Gennaro fixed it that way because we were aware of this
 issue (which is here since before Lenny, fwiw) and we agreed with 
 Gaudenz (sinfo's co-maintainer) to find a real solution to implement in 
 Jessie+1.
[...]
 So, is it acceptable to keep this workaround for Jessie and work on a 
 better one for Jessie+1? That way, we hope to find time enough time to work 
 this in coordination with both upstreams.

I'm not sure acceptable is really the right word, and I've argued with
myself a bunch over this, particularly given that sinfo+slurm-llnl is
basically a closed set for dependency purposes, with a combined popcon
of ~100.

However, before I change my mind yet again, I'm willing to give this a
one-time explicit waiver. This is on the assumption both that slurm-llnl
14.03.9-5 remains releasable for jessie and that this issue really is
fixed for stretch in a sane and policy-compliant way, the earlier in the
cycle the better.

Regards,

Adam


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Processed: Re: Bug#768112: fixed in slurm-llnl 14.03.9-4

2014-11-26 Thread Debian Bug Tracking System 
Processing control commands:

 tags -1 + jessie-ignore
Bug #768112 [slurm-client] slurm-client: fails to upgrade from 'wheezy' - 
trying to overwrite /usr/bin/sinfo
Added tag(s) jessie-ignore.

-- 
768112: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768112
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Processed: Re: Bug#768112: fixed in slurm-llnl 14.03.9-4

2014-11-08 Thread Debian Bug Tracking System 
Processing control commands:

 reopen -1
Bug #768112 {Done: Gennaro Oliva oliv...@na.icar.cnr.it} [slurm-client] 
slurm-client: fails to upgrade from 'wheezy' - trying to overwrite 
/usr/bin/sinfo
'reopen' may be inappropriate when a bug has been closed with a version;
all fixed versions will be cleared, and you may need to re-add them.
Bug reopened
No longer marked as fixed in versions slurm-llnl/14.03.9-4.

-- 
768112: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768112
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#768112: fixed in slurm-llnl 14.03.9-4

2014-11-08 Thread Adam D. Barratt 

Control: reopen -1

On 2014-11-06 10:21, Gennaro Oliva wrote:

Source: slurm-llnl
Source-Version: 14.03.9-4

We believe that the bug you reported is fixed in the latest version of
slurm-llnl, which is due to be installed in the Debian FTP archive.

[...]

 slurm-llnl (14.03.9-4) unstable; urgency=medium
 .
   * Declaring slurm-client conflict with sinfo (Closes: #768112)


No. Please re-read policy (specifically 10.1) - you don't get to 
conflict with other packages just because you both want to use the same 
file path.


Regards,

Adam


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#768112: fixed in slurm-llnl 14.03.9-4

2014-11-08 Thread Mehdi Dogguy 

Le 2014-11-08 10:53, Adam D. Barratt a écrit :

Control: reopen -1

On 2014-11-06 10:21, Gennaro Oliva wrote:

Source: slurm-llnl
Source-Version: 14.03.9-4
We believe that the bug you reported is fixed in the latest version 
of

slurm-llnl, which is due to be installed in the Debian FTP archive.

[...]

 slurm-llnl (14.03.9-4) unstable; urgency=medium
 .
   * Declaring slurm-client conflict with sinfo (Closes: #768112)


No. Please re-read policy (specifically 10.1) - you don't get to
conflict with other packages just because you both want to use the
same file path.



I think that Gennaro fixed it that way because we were aware of this
issue (which is here since before Lenny, fwiw) and we agreed with 
Gaudenz
(sinfo's co-maintainer) to find a real solution to implement in 
Jessie+1.
Gaudenz has also some trouble contacting the other co-maintainer of 
sinfo
and wasn't able to explain its name. So we were a bit stuck. Besides, 
since
the conflicts is already present in previous releases of Debian and 
since
we need to support upgrades, don't we need a conflicts statement 
anyway?

(Maybe a versioned one if the situation is sorted out before the freeze
but still)

So, is it acceptable to keep this workaround for Jessie and work on a 
better
one for Jessie+1? That way, we hope to find time enough time to work 
this

in coordination with both upstreams.

Kind regards,

--
Mehdi


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org