> > Is it possible for an arm porter to try to bring some input on the
> > build failure, and possibly help solving that issue? That is of course
> > needed for us, shadow maitnainers, to get shadow in testing.
> >
>
> It builds correctly on my machine, so it's is probably a transient
> problem wi
Hello,
Bug #394418 is a report filed regarding a recurring build problem with mono
on arm that results from mono generating code that's incompatible with the
arm v3 instruction set. Likewise, it appears shadow fails to build on elara
(one of the netwinder buildds) due to an illegal instruction fr
Christian Perrier a écrit :
> The latest shadow upload fixes a RC bug (#394182) but, for some
> strange (at least to me and Nicolas François, the package
> co-maintainer) reason, failed to build on arm.
>
> Is it possible for an arm porter to try to bring some input on the
> build failure, and pos
On Sat, Oct 28, 2006 at 11:34:24AM +1000, Anthony Towns wrote:
> (d) over time, improve the promotion rules for testing-m68k to be
> a proper m68k-only britney run with appropriate criteria for
> m68k (for example, counting debian-68k@lists.debian.org:m68k-rc
> usertagged bugs a
On Saturday 28 October 2006 03:34, Anthony Towns wrote:
> (a) move m68k from etch to testing-m68k
>
> (b) automatically promote m68k packages from unstable to testing-m68k
> when the same version gets promoted into etch.
(b1) Get the installer to support the testing-m68k and possibly als
On Fri, Oct 27, 2006 at 05:55:13PM +0200, Michael Schmitz wrote:
> > testing-m68k == having something that updates from unstable at its own
> > pace for m68k only. That might mean lagging behind the real testing if
> > there are toolchain problems, eg. If you wanted it to, it could mean
> > advanci
On Fri, Oct 27, 2006 at 05:55:13PM +0200, Michael Schmitz wrote:
> On Fri, 27 Oct 2006, Anthony Towns wrote:
> > > Isn't it going to be so that we'd be able to do our own
> > > arch-specific NMUs in both cases? Or is it in both cases going to be a
> > > matter of deciding which package will be part
Hi Anibal,
On Saturday 28 October 2006 03:01, Aníbal Monsalve Salazar wrote:
> Please allow libpng (with udeb) in testing.
Already hinted. See my mail to d-release a bit earlier today.
Cheers,
FJP
pgpGF2he4zKJZ.pgp
Description: PGP signature
On Sat, Oct 28, 2006 at 11:01:49AM +1000, Aníbal Monsalve Salazar wrote:
> Please allow libpng (with udeb) in testing.
Already in, per Frans earlier today.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can mo
A bit overdue, but here goes.
The release is going more or less as planned; we're only a few days behind
schedule. There has been an excellent response from translators to the
string freeze which means we will have 46 fully translated languages in
RC1.
We have also seen quite a few installatio
Hello,
Please allow libpng (with udeb) in testing.
Closes: 356252 377298 378463 393109
Changes:
libpng (1.2.8rel-7) unstable; urgency=low
.
* New maintainer. Closes: #393109.
* ACK NMUs. Closes: #378463, #377298, #356252.
* debian/control:
- set Standards-Version to 3.7.2
On Fri, Oct 27, 2006 at 10:22:27PM +0200, Frans Pop wrote:
> Please remove the following packages from the testing/hints/freeze file:
> # No longer has udebs
> console-setup
> # Removed from the archive
> linux-kernel-di-arm
> linux-kernel-di-i386
> linux-kernel-di-m68k
> linux-kernel-di-mips
> l
Dear RMs,
Please remove the following packages from the testing/hints/freeze file:
# No longer has udebs
console-setup
# Removed from the archive
linux-kernel-di-arm
linux-kernel-di-i386
linux-kernel-di-m68k
linux-kernel-di-mips
linux-kernel-di-mipsel
linux-kernel-di-powerpc
linux-kernel-di-s390
On Fri, Oct 27, 2006 at 07:10:42PM +0200, Christian Perrier wrote:
> The latest shadow upload fixes a RC bug (#394182) but, for some
> strange (at least to me and Nicolas Fran?ois, the package
> co-maintainer) reason, failed to build on arm.
>
> Is it possible for an arm porter to try to bring som
The latest shadow upload fixes a RC bug (#394182) but, for some
strange (at least to me and Nicolas François, the package
co-maintainer) reason, failed to build on arm.
Is it possible for an arm porter to try to bring some input on the
build failure, and possibly help solving that issue? That is o
On Fri, 27 Oct 2006, Anthony Towns wrote:
> On Fri, Oct 27, 2006 at 02:13:03PM +0200, Wouter Verhelst wrote:
> > Um, I think I've missed something. What'd be the functional difference
> > between the two?
>
> testing-m68k == having something that updates from unstable at its own
> pace for m68k onl
Anthony Towns writes:
> On Fri, Oct 27, 2006 at 02:13:03PM +0200, Wouter Verhelst wrote:
>> Um, I think I've missed something. What'd be the functional difference
>> between the two?
>
> testing-m68k == having something that updates from unstable at its own
> pace for m68k only. That might mean
On Fri, Oct 27, 2006 at 02:13:03PM +0200, Wouter Verhelst wrote:
> Um, I think I've missed something. What'd be the functional difference
> between the two?
testing-m68k == having something that updates from unstable at its own
pace for m68k only. That might mean lagging behind the real testing i
Anthony Towns writes:
> On Fri, Oct 27, 2006 at 12:47:19PM +0200, Roman Zippel wrote:
>> On Fri, 27 Oct 2006, Anthony Towns wrote:
>> > Personally, I think m68k would be better served by having a testing-m68k
>> > and taking occassional snapshots which serve as the supported stable-m68k
>> > rele
No man can serve two masters. Owt for nowt, and a penny change. Truth will out.
Try not to become a man of success but a man of value. No pain, no gay
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Hi,
On Fri, 27 Oct 2006, Anthony Towns wrote:
> On Fri, Oct 27, 2006 at 12:47:19PM +0200, Roman Zippel wrote:
> > On Fri, 27 Oct 2006, Anthony Towns wrote:
> > > Personally, I think m68k would be better served by having a testing-m68k
> > > and taking occassional snapshots which serve as the supp
On Fri, Oct 27, 2006 at 06:38:55PM +1000, Anthony Towns wrote:
> On Fri, Oct 20, 2006 at 08:21:15PM -0500, Stephen R Marenka wrote:
> > >(c) not bother with an etch-equivalent release for m68k
> > I'm not sure about this. I'd sure like to have some form of stable, even
> > if we only do base an
On Fri, Oct 27, 2006 at 02:12:56PM +0200, Marc 'HE' Brockschmidt wrote:
> Marc Haber <[EMAIL PROTECTED]> writes:
> > please approve adduser 3.99 for etch. It fixes a bug in option
> > parsing, allows building with later perl versions, makes life easier
> > for mail server administrators and include
On Fri, Oct 27, 2006 at 09:43:44PM +1000, Anthony Towns wrote:
> > The only problem right now is our backlog and we'll hopefully
> > see soon how quickly it can be reduced via distcc.
> FWIW, that would be a lot more convincing if it had happened a year ago
> when it was last suggested...
> http:
Marc Haber <[EMAIL PROTECTED]> writes:
> please approve adduser 3.99 for etch. It fixes a bug in option
> parsing, allows building with later perl versions, makes life easier
> for mail server administrators and includes many new translations.
Done.
Marc
--
BOFH #170:
popper unable to process ju
severity 387783 serious
thanks
#include
* Andreas Barth [Thu, Oct 19 2006, 11:27:36AM]:
> * Markus Laire ([EMAIL PROTECTED]) [061019 10:49]:
> > ps. Since the decision to downgrade[2] this bug was done by Andreas
> > Barth, I don't think I have the authority to restore the severity to
> > serious
On Fri, Oct 27, 2006 at 12:47:19PM +0200, Roman Zippel wrote:
> On Fri, 27 Oct 2006, Anthony Towns wrote:
> > Personally, I think m68k would be better served by having a testing-m68k
> > and taking occassional snapshots which serve as the supported stable-m68k
> > release, rather than worrying abou
Hi,
On Fri, 27 Oct 2006, Anthony Towns wrote:
> Personally, I think m68k would be better served by having a testing-m68k
> and taking occassional snapshots which serve as the supported stable-m68k
> release, rather than worrying about something equivalent to etch itself.
Why should we do this? A
On Fri, Oct 20, 2006 at 08:21:15PM -0500, Stephen R Marenka wrote:
> >(c) not bother with an etch-equivalent release for m68k
> I'm not sure about this. I'd sure like to have some form of stable, even
> if we only do base and security-support base-type packages. I'd hate to
> have to maintain
Hi,
please approve adduser 3.99 for etch. It fixes a bug in option
parsing, allows building with later perl versions, makes life easier
for mail server administrators and includes many new translations.
Greetings
Marc
--
--
Le jeudi 26 octobre 2006 à 17:38 -0700, Steve Langasek a écrit :
> On Thu, Oct 26, 2006 at 02:33:38PM +0200, Josselin Mouette wrote:
> > Unless this is an issue for d-i, could you please allow udev 0.100-2.1
> > in testing? The only change is a fix for #369479 which introduces
> > prompting with de
31 matches
Mail list logo
