+
+ -- Romain Beauxis to...@rastageeks.org Sat, 03 Nov 2012 16:40:31 +0100
+
mingw-ocaml (3.12.1+debian2) unstable; urgency=low
* Fixed typo in dummy transitional package..
diff -Nru mingw-ocaml-3.12.1+debian2/debian/control
mingw-ocaml-3.12.1+debian3/debian/control
--- mingw-ocaml-3.12.1
Hi Adam and thanks for your response,
2012/7/16 Adam D. Barratt a...@adam-barratt.org.uk:
On Wed, 2012-07-04 at 18:34 +0200, Romain Beauxis wrote:
Our bugfix release of liquidsoap has been caught in the middle of
the freeze.. We had already uploaded ocaml-dtools 0.3.0 and ocaml-flac
0.1.1
Hi Adam,
2012/7/4 Romain Beauxis to...@rastageeks.org:
2012/7/4 Adam D. Barratt a...@adam-barratt.org.uk:
On 04.07.2012 17:54, Romain Beauxis wrote:
Hi,
2012/7/4 Adam D. Barratt a...@adam-barratt.org.uk:
On 04.07.2012 17:34, Romain Beauxis wrote:
Our bugfix release of liquidsoap has
Hi Cyri,
2012/7/15 Cyril Brulebois k...@debian.org:
Romain Beauxis to...@rastageeks.org (15/07/2012):
Any news on this one?
Please allow him to get back from debconf. Also, you aren't the only one
with a pending request, so please be patient.
I am patient, don't worry :-)
R
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: freeze-exception
Please unblock package liquidsoap
Hi Release team!
Our bugfix release of liquidsoap has been caught in the middle of
the freeze.. We had already uploaded ocaml-dtools 0.3.0 and
Hi,
2012/7/4 Adam D. Barratt a...@adam-barratt.org.uk:
On 04.07.2012 17:34, Romain Beauxis wrote:
Our bugfix release of liquidsoap has been caught in the middle of
the freeze.. We had already uploaded ocaml-dtools 0.3.0 and ocaml-flac
0.1.1 when the freeze happened. However, liquidsoap 1.0.0
2012/7/4 Adam D. Barratt a...@adam-barratt.org.uk:
On 04.07.2012 17:54, Romain Beauxis wrote:
Hi,
2012/7/4 Adam D. Barratt a...@adam-barratt.org.uk:
On 04.07.2012 17:34, Romain Beauxis wrote:
Our bugfix release of liquidsoap has been caught in the middle of
the freeze.. We had already
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
Hi,
The following packages need to be rebuilt against the new ocaml-ogg:
nmu ocaml-speex_0.2.0-1 . ALL . -m Rebuild against ocaml-ogg 0.4.3-1
dw ocaml-speex_0.2.0-1 . ALL . -m
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
Hi!
Ocaml-lastfm needs to be rebuilt against the newest xmlplaylist.
nmu ocaml-lastfm_0.3.0-1 . ALL . -m Rebuild against ocaml-xmlplaylist 0.1.3-1
-- System Information:
Debian Release:
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
I have just uploaded a new package for spip that fixes two recent security
issues (#609212 and #610016).
The update consists in the addition of a single file named ecran_securite.php
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: freeze-exception
Hi !
Spip 2.1.2 has been released a couple of day ago.
It consists of a one-liner fix for an int overflow
on 32 bit machines in the articles' published date.
A release-critical
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
User: release.debian@packages.debian.org
Usertags: binnmu
nmu wikidiff2_0.0.1+svn55737-1.1 . amd64 . -m Rebuild against latest php-* ABI
-- System Information:
Debian Release:
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm
Hi !
The peercast package has been unmaintained upstream for months
now. I do not wish to maintain it during the next stable and have
found no one to take it over.
Hence, I would like
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
nmu liquidsoap_0.9.2-1 . ALL . -m Rebuild against ocaml-cry 0.1.2
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1,
Hi !
Le Wednesday 22 April 2009 09:07:58 Jan Wagner, vous avez écrit :
I've requested a slot at DebConf to discuss this into detail, though
feel free to start a discussion already on debian-devel.
sorry for coming around with another issue. While reading your comment
without giving
Hi all !
I fail to understand why fglrx-driver just entered testing today. It suffers
from a grave bug, namely #476844.
The only reason why it could be the case is that this bug has been tagged
as pending since the new package, sitting in NEW at the moment, fixes the
issue.
If this
Le Thursday 29 May 2008 19:54:32 Julien Cristau, vous avez écrit :
If this is the case, then I think it's a major bug in the update script,
and it would be good to fix it...
Thankfully, this isn't the case.
Yes, I had the answer quickly after sending the mail (as usual...).
Still I don't
Le Thursday 29 May 2008 20:37:56 Romain Beauxis, vous avez écrit :
Still I don't understand why it took more than a month to move to testing
then, while the i386 build was done at least on the 20th of april, based on
ftp.debian.org...
Hummm... It seems it's my day for making unecessary noise
Le lundi 19 mars 2007 19:10, Steve Langasek a écrit :
If it is ok for you, then I'll upload it..
Yes, this is ok. (FWIW, sending a debdiff to the list is going to get you
a quicker review than a link to a source package will...)
Thanks Steve,
The package is just being uploaded now,
Le samedi 17 mars 2007 21:09, Steve Langasek a écrit :
I'm afraid the time for translation updates is over. So please only
remove the dependencies in your upload.
Well, if an update is needed anyway, I don't object to the inclusion of
l10n changes. I just won't grant exceptions for l10n
Hi release managers !
Following with bug #414885 and so issue duck had while upgrading from
mediawiki 1.7 with pgsql, we have come to the conclusion that mediawiki1.7
should not be shipped in eth with its current pgsql dependencies since its
support seems not to be complete enough...
Le samedi 24 février 2007 12:46, vous avez écrit :
Ok, it was my understanding from previous comments in the bug history
that this couldn't be done non-intrusively, because mediawiki would then
look up the real directory and use that value for things that it
shouldn't?
In fact it's easy,
Le samedi 24 février 2007 17:02, vous avez écrit :
Frank, if you think this can be solved cleanly in mediawiki1.7 why don't
you just put up a complete patch instead of only one of the things to do
? If then it looks good, I would apply it happily.
Hm, I didn't do it mostly because if I
Le jeudi 8 février 2007 22:17, Steve Langasek a écrit :
I think the bug #388616 should be granted this etc-ignore. The
configuration file is never shiped with the package nor generated by the
software. It is generated in config/ directory, and happen normaly only
at first install.
My
Le mercredi 21 février 2007 12:54, Frank Küster a écrit :
To me that looks a bit more complicated than one would like, but still
quite manageable, and acceptable for fixing a RC bug in etch.
Not that I don't see any solution, but I would prefer to correct this
situation with the forthcoming
Le jeudi 8 février 2007 03:03, Filipus Klutiero a écrit :
Under the circumstances, I would be willing to grant an etch-ignore
exception for the file location. If the location of the file is still
causing upgrade errors (which seems possible, since the symlinks under
/etc/mediawiki1.7 are
Le jeudi 8 février 2007 15:22, Romain Beauxis a écrit :
Le jeudi 8 février 2007 03:03, Filipus Klutiero a écrit :
Under the circumstances, I would be willing to grant an etch-ignore
exception for the file location. If the location of the file is still
causing upgrade errors (which seems
Le jeudi 8 février 2007 22:17, Steve Langasek a écrit :
I think the bug #388616 should be granted this etc-ignore. The
configuration file is never shiped with the package nor generated by the
software. It is generated in config/ directory, and happen normaly only
at first install.
My
Hi !
Le mercredi 10 janvier 2007 11:43, vous avez écrit :
However, now a new upstream 1.7.2 has been published today to correct a
security issue in 1.7.x branch. Given that the changelog not only
includes a security fix, I don't know what should be done for
mediawiki1.7 in etch.
Hi release managers !
On a previous mail discussion, you accepted that mediawiki1.7 was to be
updated to current package in sid (1.7.1-5), but since then it has not yet
been moved to etch.
However, now a new upstream 1.7.2 has been published today to correct a
security issue in 1.7.x
Hi RMs !
I have two packages that may enter testing before etch is released:
geekast: Last updated has removed dependencies on gstreamer0.8 and hence would
allow to remove gstreamer0.8 before etch is released
linuxdcpp: Upstream has corrected a security issue, according to [1]
This
Le samedi 16 décembre 2006 14:48, Marc 'HE' Brockschmidt a écrit :
linuxdcpp: Upstream has corrected a security issue, according to [1]
This package may add two additional issues that I have to tell you about:
* The dcpp core has been updated, hence the binary package name should be
Hi release managers !
Together with the mediawiki packaging team, we have prepared an update for
mediawiki which solves two bugs, namely #401808 and #399886.
This update is only a change in the debian/control file, it does not introduce
any change, and will help the package to fit
33 matches
Mail list logo
