Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
nmu fso-deviced_0.9.5+git20120214-1 . ALL . -m rebuild against
libfsotransport1
nmu fso-gsmd_0.5.0+git20120305-1 . ALL . -m rebuild against libfsotransport1
libfsotransport
Riku Voipio wrote (ao):
On Mon, May 21, 2012 at 10:00:53AM +0200, Luk Claes wrote:
How long would it take to have better machines than ancina so it could
just get fased out btw?
Sigh, I year ago when armhf buildd's were being chosen, I was expecting
to see significantly faster HW
On Tue, May 22, 2012 at 23:05:59 -0500, Steve M. Robbins wrote:
Quoting Luca Falavigna:
we're struggling with a bunch of uncoordinated transitions at the
moment, with extra fun thanks to an uncoordinated switch to gcc
4.7, and its extra hundreds of RC bugs;
On Fri, 2012-05-18 at 22:31 +0200, Andreas Barth wrote:
mipsel buildds: In the last month, we had two buildds eating their hard
disk, so all the time only three buildds are active. The three can just
keep up but are obviously not how it should be. The currently broken buildd
is the non-DSAed,
On Wed, 2012-05-16 at 13:38 +0100, Steven Chamberlain wrote:
The table seems to be missing portbox: io
As KiBi mentioned they porter boxes are not administered by DSA *yet*.
Thanks to DSA, this is no longer the case - falla and fischer now exist.
Regards,
Adam
--
To UNSUBSCRIBE, email to
Your message dated Wed, 23 May 2012 19:25:40 +0100
with message-id 1337797540.16492.5.ca...@jacala.jungle.funky-badger.org
and subject line Re: Bug#674128: nmu: fso-deviced_0.9.5+git20120214-1
fso-gsmd_0.5.0+git20120305-1
has caused the Debian Bug report #674128,
regarding nmu:
On Wed, 2012-05-16 at 13:19 +0100, Adam D. Barratt wrote:
With the sound of the ever approaching freeze ringing loudly in our ears,
we're (somewhat belatedly) looking at finalising the list of release
architectures for the Wheezy release.
Comments on / additions and corrections to the
On Wed, 2012-05-16 at 13:19 +0100, Adam D. Barratt wrote:
With the sound of the ever approaching freeze ringing loudly in our ears,
we're (somewhat belatedly) looking at finalising the list of release
architectures for the Wheezy release.
Comments on / additions and corrections to the
On Wed, 2012-05-16 at 13:19 +0100, Adam D. Barratt wrote:
With the sound of the ever approaching freeze ringing loudly in our ears,
we're (somewhat belatedly) looking at finalising the list of release
architectures for the Wheezy release.
Comments on / additions and corrections to the
On Wed, 2012-05-16 at 13:19 +0100, Adam D. Barratt wrote:
With the sound of the ever approaching freeze ringing loudly in our ears,
we're (somewhat belatedly) looking at finalising the list of release
architectures for the Wheezy release.
Comments on / additions and corrections to the
On Wed, May 23, 2012 at 07:32:17PM +0100, Adam D. Barratt wrote:
On Wed, 2012-05-16 at 13:19 +0100, Adam D. Barratt wrote:
With the sound of the ever approaching freeze ringing loudly in our ears,
we're (somewhat belatedly) looking at finalising the list of release
architectures for the
* Adam D. Barratt (a...@adam-barratt.org.uk) [120523 20:36]:
On Fri, 2012-05-18 at 22:31 +0200, Andreas Barth wrote:
mipsel buildds: In the last month, we had two buildds eating their hard
disk, so all the time only three buildds are active. The three can just
keep up but are obviously not
Adam,
I didn't see where GCC was dropping 32-bit sparc upstream in the
changelogs. This seems inaccurate since a 64-bit userland has negative
performance implications, and this is true for both Solaris and Linux and
not recommended by anyone. A 64-bit userland is barely available for Linux
--
I just found this:
http://boundarydevices.com/products-2/sabre-lite-imx6-sbc/
Highlights of the platform include:
o Quad-Core ARM Cortex A9 processor at 1GHz
Nice :)
o 1GByte of 64-bit wide DDR3 @ 532MHz
This is better than the average arm board but it's the same as
debian's current
On Wed, 2012-05-23 at 13:44 -0500, Patrick Baggett wrote:
I didn't see where GCC was dropping 32-bit sparc upstream in the
changelogs. This seems inaccurate since a 64-bit userland has negative
performance implications, and this is true for both Solaris and Linux
and not recommended by anyone.
On Wed, May 23, 2012 at 2:08 PM, Adam D. Barratt
a...@adam-barratt.org.ukwrote:
On Wed, 2012-05-23 at 13:44 -0500, Patrick Baggett wrote:
I didn't see where GCC was dropping 32-bit sparc upstream in the
changelogs. This seems inaccurate since a 64-bit userland has negative
performance
On Wed, May 23, 2012 at 07:42:32PM +0100, Roger Leigh wrote:
I am still a regular powerpc user, and I should have sufficient time to
assist with porting issues for the foreseeable future, which I haven't
done for the last couple of releases but will now be able to. So feel
free to put me down
* Lennart Sorensen (lsore...@csclub.uwaterloo.ca) [120523 21:21]:
On Wed, May 23, 2012 at 07:42:32PM +0100, Roger Leigh wrote:
I am still a regular powerpc user, and I should have sufficient time to
assist with porting issues for the foreseeable future, which I haven't
done for the last
peter green wrote (ao):
I just found this:
http://boundarydevices.com/products-2/sabre-lite-imx6-sbc/
Highlights of the platform include:
o Quad-Core ARM Cortex A9 processor at 1GHz
Nice :)
o 1GByte of 64-bit wide DDR3 @ 532MHz
This is better than the average arm board but it's the
On Mon, 2012-05-21 at 17:15 +0300, Riku Voipio wrote:
If we really want to replace ancina quickly, we could get some i.mx53
quick start boards like the ones currently used as armhf buildd's. I'd
like not to introduce new hardware models as buildd's unless they are
significantly faster as the
Processing commands for cont...@bugs.debian.org:
block 671115 by 674210
Bug #671115 [release.debian.org] transition: mysql-5.5
671115 was blocked by: 672765 673260 673528 673183 667428 673161 673263 649638
668232 673153 650058 649955 651110 672824 650060 672714 672950 672619 666331
672716
On Wed, May 23, 2012 at 09:02:33PM +0100, Tixy wrote:
I may be being naive, but could an X86 PC be used with an ARM chroot and
qemu-arm-static to emulate ARM instructions? Or is qemu not stable
enough, or the emulated environment different enough that package
building would fail (e.g. through
Hi Pascal,
it seems like we have an uncoordinated transition, from libsox1b to
libsox2. That can be seen on the excuses page, and that explains why
your package isn't migrating:
| sox (14.3.2-3 to 14.4.0-3)
|
| Maintainer: Pascal Giard
| 17 days old (needed 10 days)
| out of date on
Hi Debian FreeSmartphone.Org Team,
it seems like we have an uncoordinated transition, from libfsotransport0
to libfsotransport1. That can be seen on the excuses page, and that
explains why your package isn't migrating:
| libfsotransport (0.9.8+git20110805-1 to 0.9.8+git20120308-1)
|
|
Hi,
it seems like we have an uncoordinated transition, from libh323-1.21.0
to libh323-1.24.0. The following packages need binNMUs:
| # Broken Depends:
| openam: openam [amd64 armel armhf i386 ia64 mips mipsel powerpc s390 s390x
sparc]
| openmcu: openmcu [amd64 armel armhf i386 ia64 mips mipsel
Hi Dirk,
it seems like we have an uncoordinated transition, from libquantlib-1.1
to libquantlib-1.2. That can be seen on the excuses page, and that
explains why your package isn't migrating:
| quantlib (1.1-2 to 1.2-2)
|
| Maintainer: Dirk Eddelbuettel
| 69 days old (needed 10 days)
|
On Wed, May 23, 2012 at 11:31:33PM +0300, Touko Korpela wrote:
This bug blocks lvm2 from migrating to testing. Maybe cryptmount should
temporarily removed from testing? Or are tools wrong, and lvm2 update
don't make situation any worse than it's now?
Has release managers opinion about this?
Hi Cyril,
On 24 May 2012 at 01:34, Cyril Brulebois wrote:
| Hi Dirk,
|
| it seems like we have an uncoordinated transition, from libquantlib-1.1
| to libquantlib-1.2. That can be seen on the excuses page, and that
My packages (listed below) are the only users of libquantlib. In the past (as
Hi Cyril,
On Wed, May 23, 2012 at 6:58 PM, Cyril Brulebois k...@debian.org wrote:
Hi Pascal,
it seems like we have an uncoordinated transition, from libsox1b to
libsox2. That can be seen on the excuses page, and that explains why
your package isn't migrating:
| sox (14.3.2-3 to 14.4.0-3)
|
Hello dear release team,
With libsox2 in the archive, we can start the transition (late but
hopefully not too late) so that the new SoX can make it into testing.
The following source packages need to be rebuilt:
ebook-speaker
imagination
IIUC, the transition has the following parameters:
30 matches
Mail list logo
