* Adeodato Simó [Wed, 28 May 2008 15:25:26 +0200]:
> Hello,
> gcc-defaults is almost ready to migrate to testing (finally!), and since
> I would really hate to see this delayed any further, I've put one of
> these "block uploads" thingies in place for the packages below.
> Thanks in advance for
Hello,
Interesting matter ! Multiarch :-)
I have experienced the same treatment from binutils maintainer, he did
not answer to my mails or bug reports (393841,432772). Tired of this
and as it is an upstream matter i sent a patch upstream and it got
accepted. For my surprise, it is very close to 3
* Russ Allbery [Fri, 30 May 2008 10:52:25 -0700]:
> Santiago Vila <[EMAIL PROTECTED]> writes:
> > On Fri, 30 May 2008, Adeodato Simó wrote:
> >> * Santiago Vila [Fri, 30 May 2008 11:12:16 +0200]:
> >> Hello, Santiago.
> >> > base-files (4.0.4) unstable; urgency=low
> >> > * Added Apache-2.0 t
Santiago Vila <[EMAIL PROTECTED]> writes:
> On Fri, 30 May 2008, Adeodato Simó wrote:
>> * Santiago Vila [Fri, 30 May 2008 11:12:16 +0200]:
>> Hello, Santiago.
>> > base-files (4.0.4) unstable; urgency=low
>>
>> > * Added Apache-2.0 to common-licenses. Closes: #471736.
>> > Retrieved from
On Fri, 30 May 2008, Adeodato Simó wrote:
> * Santiago Vila [Fri, 30 May 2008 11:12:16 +0200]:
>
> Hello, Santiago.
>
> > base-files (4.0.4) unstable; urgency=low
>
> > * Added Apache-2.0 to common-licenses. Closes: #471736.
> > Retrieved from http://www.apache.org/licenses/LICENSE-2.0.tx
Hi,
On Fri, May 30, 2008 at 04:54:01PM +0200, maximilian attems wrote:
> please review for a stable release those 2 changes,
> cherry picked from master
> http://git.debian.org/?p=kernel/initramfs-tools.git;a=shortlog;h=refs/heads/etch
>
> [...]
>
> the later one has been debugged today by axel
hello,
please review for a stable release those 2 changes,
cherry picked from master
http://git.debian.org/?p=kernel/initramfs-tools.git;a=shortlog;h=refs/heads/etch
the Xen boot fix is needed for partial upgrades,
as none of the newer linux-images depends on latest initramfs-tools.
the later on
* Santiago Vila [Fri, 30 May 2008 11:12:16 +0200]:
Hello, Santiago.
> base-files (4.0.4) unstable; urgency=low
> * Added Apache-2.0 to common-licenses. Closes: #471736.
> Retrieved from http://www.apache.org/licenses/LICENSE-2.0.txt.
I don't see the Apache license mentioned in the current
* Vagrant Cascadian [Fri, 30 May 2008 00:32:55 -0700]:
> ltsp is again blocked from migrating into testing, likely due to the
> ltsp-client-builder udeb, though this udeb is not used by
> debian-installer by default.
> it has been in unstable for 7 days now, without introducing new
> problems, an
On Fri, May 30, 2008 at 01:22:12PM +0200, Axel Beckert wrote:
>
> Sorry, but this bug is neither fixed in Sid nor in Etch (where it is
> also present). In Etch the bug breaks dist-upgrades from Sarge to Etch
> at least if previously a devfs kernel, lilo and md was used. Just had
> such a case yest
Am Donnerstag, den 29.05.2008, 11:31 -0700 schrieb Kevin B. McCarty:
> > Adeodato Simó wrote:
> >> So, to get this moving, who does the archive inspection?
>
> I wrote:
> > As it happens, I already had a script prepared that did something very
> > similar (for the purpose of looking for mis-compil
reopen 469312 !
found 469312 0.92a
found 469312 0.85h
notfixed 469312 0.91d
severity 469312 grave
tag 469312 +etch
thanks
Sorry, but this bug is neither fixed in Sid nor in Etch (where it is
also present). In Etch the bug breaks dist-upgrades from Sarge to Etch
at least if previously a devfs kerne
Here's the patch. I'm sorry, I don't know what this changelog entry is. I'm
not so familiar with the packaging terms. Perhaps this is a description of
the patch and why i added it? It was added to fix #418176 in etch. It is
copied as is from the 0.5.11-1 version.
Is anything else needed?
I'm C
On Mon, May 19, 2008 at 10:19:34AM +0200, Thijs Kinkhorst wrote:
> Hi SRMs,
>
Hi Thijs, sorry for the delay in replying.
[snip openssl issue]
> Is there a current schedule for the next point update? Do you think it can be
> pulled forward?
>
Unfortunately, the next point release is planned t
Dawn,
am Fri, May 30, 2008 at 11:26:26AM +0300 hast du folgendes geschrieben:
> Would it be possible to add this fix to etch r4?
>
> I'm talking about doing what I've described in
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=418176#67
>
> I've tested it and it works. I see no problems.
i
base-files (4.0.4) unstable; urgency=low
* Added Apache-2.0 to common-licenses. Closes: #471736.
Retrieved from http://www.apache.org/licenses/LICENSE-2.0.txt.
* Fixed typo in README.base. Closes: #475201.
Item 1 is already policy according to the debian-policy package in lenny.
Item 2 is
On Friday 30 May 2008, Martin Zobel-Helas wrote:
> On Fri May 30, 2008 at 00:32:55 -0700, Vagrant Cascadian wrote:
> > ltsp is again blocked from migrating into testing, likely due to the
> > ltsp-client-builder udeb, though this udeb is not used by
> > debian-installer by default.
> >
> > it has b
Hello!
Would it be possible to add this fix to etch r4?
I'm talking about doing what I've described in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=418176#67
I've tested it and it works. I see no problems.
--
Shachar Or | שחר אור
http://ox.freeallweb.org/
--
To UNSUBSCRIBE, email to [EMA
Fellow earthicans,
I have just updated the libweather-com-perl package [0] because since
beginning of May it has stopped working due to a protocol change of the
used internet service. The fix is a one-line patch between 0.5.3-1.1 and
0.5.3-2. It addresses this problem: [1]. Is this worth an upd
Hi,
On Fri May 30, 2008 at 00:32:55 -0700, Vagrant Cascadian wrote:
> ltsp is again blocked from migrating into testing, likely due to the
> ltsp-client-builder udeb, though this udeb is not used by
> debian-installer by default.
>
> it has been in unstable for 7 days now, without introducing ne
ltsp is again blocked from migrating into testing, likely due to the
ltsp-client-builder udeb, though this udeb is not used by
debian-installer by default.
it has been in unstable for 7 days now, without introducing new
problems, and fixes several bugs.
thanks for your work.
live well,
vagrant
Security team:
Bryan Donlan discovered a security hole in the interaction between apt
and aptitude. apt provides a function GetLock() as a convenient way to
obtain an exclusive lock using a lockfile. aptitude uses this to create
a lock file controlling its own state, which since version 0.4.
22 matches
Mail list logo