Bug#798744: nmu: promoe esperanza

2015-09-12 Thread Rémi Vanicat
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

xmms2 has been rebuild for the g++-v5 transition. Two package build
depend on libxmmsclient++-dev and need to be rebuild.

see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797646



nmu promoe_0.1.1-3+b1 . ALL . unstable . -m "rebuild for libxmmsclient++4v5"
nmu esperanza_0.4.0+git20091017-3 . ALL . unstable . -m "rebuild for 
libxmmsclient++4v5"


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (150,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.1.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
-- 
Rémi Vanicat



Bug#706798: transition: Libav 9

2013-10-01 Thread Rémi Vanicat
Julien Cristau jcris...@debian.org writes:

 On Sat, Sep 28, 2013 at 11:38:33 +0200, Rémi Vanicat wrote:

 Hello,
 
 A recent change in a build dependency (libmodplug 1:0.8.8.4-4[1]) of
 xmms2 make it FTBS[2]. As it is part of the libav transition and already
 have been rebuilt for it, I wanted to have you OK to upload the fixed
 version now
 
 I'm hoping to get new libav and most of its rdeps migrated within the
 next couple of days.  Can you check back after that (or just upload
 after you see xmms2 0.8+dfsg-6+b1 in testing)?

Okay. I will wait.

-- 
Rémi Vanicat


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87a9it5t2c@debian.org



Bug#706798: transition: Libav 9

2013-09-28 Thread Rémi Vanicat
Hello,

A recent change in a build dependency (libmodplug 1:0.8.8.4-4[1]) of
xmms2 make it FTBS[2]. As it is part of the libav transition and already
have been rebuilt for it, I wanted to have you OK to upload the fixed
version now

Note that xmms2 is also part of the liboost[3] transition, and do not have
yet been rebuilt for it, and this is also related to the ruby1.8-removal[4]

[1]:http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652139
[2]:http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724487
[3]:http://release.debian.org/transitions/html/boost1.54.html
[4]:http://release.debian.org/transitions/html/ruby1.8-removal.html
-- 
Rémi Vanicat


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87siwp2sme@gmail.com



Xmms2 in new

2012-06-27 Thread Rémi Vanicat
Hello

xmms2 is in new[1] and might not do it for freeze, and I was wondering
which option I should follow.

The last upload of xmms2 add support for client wrote in ruby1.9.1, and
change ruby package name and installed path to follow the new ruby
policy. 

It also fix one documentation bug, and add a fix that should help the
package to be more reliably build on kbsd architecture. 

The change are small (most of the binaries packages are unchanged, and
in particular not the core package and its plugins), and I believe useful
(ruby1.9.1 is the default ruby version for the next release, and
supporting seem to me to be important. The more reliable build on kbsd
could have security implication if we have to make a security upload in
the future).

So here are the option I see:
- upload a new version that don't follow ruby policy name for ruby
  package, putting ruby1.9.1 binding in the already existing
  libxmmsclient-ruby binary package.
- wait for the new queue to be processed, and hope to have a freeze
  exception latter for the xmms2 package

I would prefer the last one, but need some advice on it.

Thanks.

[1]:http://ftp-master.debian.org/new/xmms2_0.8+dfsg-4.html
-- 
Rémi Vanicat


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87y5n9b4u5@gmail.com



Xmms2, libcdio transition and ruby1.9

2012-06-19 Thread Rémi Vanicat
Hello,

I'm preparing a new upload of xmms2 that will (I hope) build both
ruby1.8 and ruby1.9 or (at least) only ruby1.9.

I would upload it very soon if xmms2 was not part of the libcdio[1]
transition. So I would like to have some advice on what to do 
 - wait with the risk that the deprecated ruby1.8 binding is the only
   one to be include in the release after the freeze
 - upload anyway, risking a problem with the transition

Note that the current xmms2 version has been re-compiled with success on
all arch for the libcdio transition.

[1] http://release.debian.org/transitions/html/libcdio.html
-- 
Rémi Vanicat


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87pq8v9t5m@debian.org



Bug#672820: failed attempt to build xmms2, blocking libcdio transition.

2012-06-18 Thread Rémi Vanicat
Hello Debian/BSD hackers,

I've recently upload an new version of xmms2 to fix an FTBS[1] and help
a libcdio transition[2]. But the build failed on both kfreebsd buildd
(fano[3] and finzi[4]) at very different stage of compilation, but in
both case waf or gcc hang, and the build was killed after some time.

Is there anything I should know/do about this problem on the kfreebsd
port?

Thanks

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676100
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672820
[3] 
https://buildd.debian.org/status/fetch.php?pkg=xmms2arch=kfreebsd-amd64ver=0.8%2Bdfsg-3stamp=1340024041
[4] 
https://buildd.debian.org/status/fetch.php?pkg=xmms2arch=kfreebsd-i386ver=0.8%2Bdfsg-3stamp=1340032320

-- 
Rémi Vanicat



--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878vfkbg1x@gmail.com



Re: Unblocking realtimebattle 1.0.8-8

2008-08-27 Thread Rémi Vanicat
2008/8/26 Luk Claes [EMAIL PROTECTED]:
 Rémi Vanicat wrote:
 Hello,

 could you please unblock realtimebattle 1.0.8-8 : it close a grave
 security bug (#496385,
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=496385).

 Any reason why you don't keep the log file in /var/log instead of
 getting rid of the log file in /tmp?

Because there is no reason to keep it. It contain only debugging
information, this perl script is only given as one example of a robot.
Of the several given example, it is the only one that has a logging
facilities. And most (if not all) information logged are given by the
user or visible on the screen of the simulation.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Unblocking realtimebattle 1.0.8-8

2008-08-26 Thread Rémi Vanicat
Hello,

could you please unblock realtimebattle 1.0.8-8 : it close a grave
security bug (#496385,
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=496385).

Thanks. (patch attached)
diff --git a/Robots/perl/perl.robot.in b/Robots/perl/perl.robot.in
index afd9c2c..75be6b9 100644
--- a/Robots/perl/perl.robot.in
+++ b/Robots/perl/perl.robot.in
@@ -119,8 +119,8 @@ my $QUIT = 0;
 my %OPTION;
 my %RDATA = (Energy = 100, RobotsLeft = 0);
 
-open(LOG,/tmp/perl.robot.log) || die Kann Logfile nicht öffnen: $!;
-LOG-autoflush(1);
+#open(LOG,/tmp/perl.robot.log) || die Kann Logfile nicht öffnen: $!;
+#LOG-autoflush(1);
 STDOUT-autoflush(1);
 STDERR-autoflush(1);
 
@@ -131,13 +131,13 @@ $SIG{USR1} = \check_message;
 $SIG{USR2} = 'IGNORE';
 $SIG{HUP}  = \quit_bot;
 
-print LOG Starting Roboter\n;
+#print LOG Starting Roboter\n;
 
 while(not $QUIT) {
   run_robot
 }
 
-print LOG Jetzt ist aber Ende\a\n;
+#print LOG Jetzt ist aber Ende\a\n;
 exit;
 ###
 
@@ -179,7 +179,8 @@ sub parse($) {
   elsif ($cmd eq Dead)   {Dead()}
   elsif ($cmd eq GameFinishes) {GameFinishes()}
   elsif ($cmd eq ExitRobot)  {ExitRobot()}
-  else {print LOG Unknown Command $input\n;
+  else {
+#print LOG Unknown Command $input\n;
 #print Print Unknown Command $input\n
}
 }
@@ -190,7 +191,7 @@ sub parse($) {
 sub Initialize($) {
   my $arg = shift;
   if ($arg ==1) {
-print LOG Initialising\n;
+#print LOG Initialising\n;
 Name($NAME);
 Colour($COLOR);
 Print(Ahh, awaken again...);
@@ -228,7 +229,7 @@ sub Radar($$$) {
 #  print LOG Radar: $dist, $obj, $angle\n;
   if ($obj == 0) {tac_fire($angle)}
   if ($obj == 2 or $obj == 4) {tac_wall($dist)}
-  print LOG Gotch: $obj\n if ($obj == 5);
+#  print LOG Gotch: $obj\n if ($obj == 5);
 }
 
 sub Info($$$) {
@@ -256,7 +257,7 @@ sub RobotsLeft($) {
   if ($RDATA{RobotsLeft}) {
 if ($robots  $RDATA{RobotsLeft}) {
   Print(Gotcha. Onother one's gone! :-));
-}  
+}
   }
   $RDATA{RobotsLeft} = $robots;
 }
@@ -265,13 +266,13 @@ sub Collision($$) {
   my $obj  = shift;
   my $angle= shift;
   if($obj == 4) {Print(Boom! Hit by a mine)}
-  elsif ($obj == 3) {Print(Yamm! Cookies Cookes!)}  
+  elsif ($obj == 3) {Print(Yamm! Cookies Cookes!)}
 }
 
 sub Warning($$) {
   my $type = shift;
   my $msg = join( ,@_);
-  print LOG WARN: ($type) $msg\n;
+#  print LOG WARN: ($type) $msg\n;
   Print(Someone's fucking me: ($type) $msg);
 }
 
@@ -293,13 +294,13 @@ sub ExitRobot() {
 # Tools
 sub dump_options() {
   $OPTION{'ROBOT_MAX_ROTATE'}=12;
-  print LOG RobotMaxRotate(): , $OPTION{ROBOT_MAX_ROTATE()},\n;
-  print LOG RobotMaxRotate: , $OPTION{ROBOT_MAX_ROTATE},\n;
-  print LOG RobotCannonMaxRotate: , $OPTION{ROBOT_CANNON_MAX_ROTATE()},\n;
-  print LOG RobotMaxAcceleration: , $OPTION{ROBOT_MAX_ACCELERATION()},\n;
-  print LOG RobotMinAcceleration: , $OPTION{ROBOT_MIN_ACCELERATION()},\n;
-  print LOG RobotStartEnergy: , $OPTION{ROBOT_START_ENERGY()},\n;
-  
+#   print LOG RobotMaxRotate(): , $OPTION{ROBOT_MAX_ROTATE()},\n;
+#   print LOG RobotMaxRotate: , $OPTION{ROBOT_MAX_ROTATE},\n;
+#   print LOG RobotCannonMaxRotate: , $OPTION{ROBOT_CANNON_MAX_ROTATE()},\n;
+#   print LOG RobotMaxAcceleration: , $OPTION{ROBOT_MAX_ACCELERATION()},\n;
+#   print LOG RobotMinAcceleration: , $OPTION{ROBOT_MIN_ACCELERATION()},\n;
+#   print LOG RobotStartEnergy: , $OPTION{ROBOT_START_ENERGY()},\n;
+
 }
 
 ##
diff --git a/debian/changelog b/debian/changelog
index e7ed9a0..b652629 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+realtimebattle (1.0.8-8) unstable; urgency=high
+
+  * Suppression of the logging in the perl robot as it may lead to a
+security risk (Closes: #496385).
+
+ -- Rémi Vanicat [EMAIL PROTECTED]  Tue, 26 Aug 2008 01:00:54 +0200
+
 realtimebattle (1.0.8-7) unstable; urgency=low
 
   * correction of a typo in build-indep dependency (closes: 473931)