On 12/02/11 at 15:29 -0600, Raphael Geissert wrote:
> Lars Wirzenius wrote:
> >
> > If we wanted to be serious about this, it would be nice for someone to
> > set up a maximal build chroot: something with as many packages installed
> > as possible. Then do test builds of all packages, and report p
On Sun, Feb 13, 2011 at 03:53:34AM +0100, gregor herrmann wrote:
> On Sat, 12 Feb 2011 20:17:35 -0600, Steve M. Robbins wrote:
>
> > Suddenly, I can't apply my quilt patches:
> >
> > steve@riemann{insighttoolkit-3.20.0}quilt push -a
> > Applying patch metaio-test-vtk_source.patch
> > patch:
On Sat, 12 Feb 2011 20:17:35 -0600, Steve M. Robbins wrote:
> Suddenly, I can't apply my quilt patches:
>
> steve@riemann{insighttoolkit-3.20.0}quilt push -a
> Applying patch metaio-test-vtk_source.patch
> patch: unrecognized option '--unified-reject-files'
> patch: Try `patch --help' for
On Wed, Feb 09, 2011 at 10:15:12AM +0100, Ga?tan Lehmann wrote:
>
> Steve, Luis,
>
> Splitting ImageToImageFilterB into smaller modules seems to be the
> way to go in ITK v3. The attached patch should help!
Thanks, Gaetan! I'm building ITK with this patch now for upload
to Debian so we'll know
Hi,
Suddenly, I can't apply my quilt patches:
steve@riemann{insighttoolkit-3.20.0}quilt push -a
Applying patch metaio-test-vtk_source.patch
patch: unrecognized option '--unified-reject-files'
patch: Try `patch --help' for more information.
Patch metaio-test-vtk_source.patch does not app
Package: wnpp
Severity: wishlist
Owner: Benjamin Mako Hill
* Package name: python-simplemediawiki
Version : 1.0.2
Upstream Author : Ian Weller
* URL : http://github.com/ianweller/python-simplemediawiki
* License : LGPL
Programming Lang: Python
Description
On Fri, Feb 04, 2011 at 07:02:33PM +0100, Tollef Fog Heen wrote:
> ]] Yaroslav Halchenko
> | please do not slap me too hard (only so that I feel your warm carrying
> | touch):
> | is there a rationale for: on amd64 Debian systems having
> | /lib64 -> /lib
> Yes, it's required by the ABI, unfor
On Sat, 2011-02-12 at 15:12 +0100, Jarek Kamiński wrote:
> Na grupie linux.debian.devel napisałe(a)ś:
> > Trying to run unmodified Debian on 64MB is a suicide, I'd say the weakest
> > type that are going to run stock Debian are chroots on n900, which, with
> > 256MB, can handle all the phony stuff
Package: wnpp
Severity: wishlist
Owner: Evan Broder
* Package name: reptyr
Version : 0.1+git.20110212t183758.d51bfc2d
Upstream Author : Nelson Elhage
* URL : http://github.com/nelhage/reptyr
* License : MIT/X
Programming Lang: C
Description : A tool fo
On Sat, Feb 12, 2011 at 08:57:12PM +, Roger Leigh wrote:
> If we have a guaranteed clean build environment + package build deps,
> we have as complete consistency as is practicable.
>
> If we have a random build environment + package build deps, we might
> occasionally find something that need
Roger Leigh wrote:
> The other side to this is that fixing such bugs gains us very litle.
>
> If we have a guaranteed clean build environment + package build deps,
> we have as complete consistency as is practicable.
>
> If we have a random build environment + package build deps, we might
> occasi
Lars Wirzenius wrote:
>
> If we wanted to be serious about this, it would be nice for someone to
> set up a maximal build chroot: something with as many packages installed
> as possible. Then do test builds of all packages, and report problems.
> (Then upgrade the chroot, install as many new packa
Hello,
There has been on-going work to port Debian on ARM devices with later
instruction set (armv7) and floating point support. New port [1]
is named 'armhf' after discussion on public debian-arm lists [2].
Debian-ports.org holds new port which it is almost at 90% of the archive
built [3].
On Sat, Feb 12, 2011 at 07:37:55PM +, Lars Wirzenius wrote:
> On la, 2011-02-12 at 20:22 +0100, Bernhard R. Link wrote:
> > If the packages used are only ever built in unnatural virgin
> > environments, there is basically no testing if building them on
> > a real user machine works. And things
On Sun, Feb 6, 2011 at 16:51:26 +0100, Andreas Tille wrote:
> 3. Whether changelogs should be branched for different Debian
> releases, be it testing-proposed-updates, backports or even
> derivatives as Ubuntu or others.
>
As the package itself is branched, the changelog should be, t
Roger Leigh writes:
> On Sun, Feb 06, 2011 at 10:23:00PM -0400, Joey Hess wrote:
>> Roger Leigh wrote:
>> > There are lots of Debian people out there using git, and some of them
>> > have expressed interest over the years in having the ability to use
>> > git as a filesystem in its own right (#47
Andreas Tille writes:
> [Reply-To set to debian-devel]
>
> Hi,
>
> on the Debian Med list a discussion about handling changelogs was started[1]
> which addressed the following questions:
>
> 1. What to do with pre-Debian-Release changelogs (if packaging
> needed some time and went through
]] Lars Wirzenius
| If we wanted to be serious about this, it would be nice for someone to
| set up a maximal build chroot: something with as many packages installed
| as possible. Then do test builds of all packages, and report problems.
| (Then upgrade the chroot, install as many new packages a
On la, 2011-02-12 at 20:22 +0100, Bernhard R. Link wrote:
> If the packages used are only ever built in unnatural virgin
> environments, there is basically no testing if building them on
> a real user machine works. And things not tested usually just stop
> working after some time...
Right now, su
* Don Armstrong [110211 23:01]:
> 3) uniform, known build environments
I think is a major disadvantage of this suggestion.
Free Software is about being able to modify what you run. The day a user
can no longer simply do a
apt-get build-dep name
apt-get source name
dpkg-so
Adam Borowski wrote:
> Trying to run unmodified Debian on 64MB is a suicide
The NSLU2 is still a supported platform, it runs in 32 mb. More or less
happily IME.
> Thus, I think there are no problems with enabling XZ on all architectures.
I see little benefit to enabling it on arm. Size of arm CD
Alexander Wirt schrieb am Friday, den 11. February 2011:
> Michal Čihař schrieb am Friday, den 11. February 2011:
>
> > Hi
> >
> > as I don't use MPD for quite a long time now, it somehow does not make
> > sense to maintain MPD related packages anymore. Simply I don't
> > have environment to tes
Package: wnpp
Severity: wishlist
Owner: andr...@an3as.eu
* Package name: jebl2
Version : SVN R6
Upstream Author : Andrew Rambaut
* URL : http://code.google.com/p/jebl2/
* License : LGPL
Programming Lang: Java
Description : Java Evolutionary Biology Libr
On Sat, Feb 12, 2011 at 10:17:59PM +0800, Paul Wise wrote:
> On Sat, Feb 12, 2011 at 9:57 PM, Adam Borowski wrote:
>
> > On ARM, it's 90MB, I guess MIPS should be similar.
> > The man page says 65MB even in -9, but I guess they didn't count in the
> > code, libc, buffers and the likes.
> >
> My O
Hi!
On Sat, 2011-02-12 at 13:15:47 +, Philipp Kern wrote:
> On 2011-02-11, Hideki Yamane wrote:
> > On Fri, 4 Feb 2011 08:20:02 +0100
> > Raphael Hertzog wrote:
> >> I have not seen any word about XZ support.
> >> When you deployed support for new source package formats, you forbid
> >> lzma
Hi!
On Fri, 2011-02-11 at 11:33:10 +0800, Paul Wise wrote:
> On Fri, Feb 11, 2011 at 5:58 AM, Ben Hutchings wrote:
> > Since there is no support for auto-building arch-independent binaries
>
> I would hope that throwing away developer built debs would also apply
> to arch-independent packages, I
On Fr, 11 Feb 2011, Josh Triplett wrote:
> See http://bugs.debian.org/612876 for the bug report. I encountered the
> same issue, and finally found the culprit through reading the
> chromium-browser changelog.
Umpf, I have removed the x-scheme-handler/http and x-scheme-handler/https
ffrom the chro
On Sat, 12 Feb 2011, Philipp Kern wrote:
> Do we have an idea how much more memory xz needs for decompression? I guess
> it wouldn't be feasible to switch dpkg's default on package builds on those
> architectures where we assume some more beefyness?
It depends on what compression level we use, th
Na grupie linux.debian.devel napisałe(a)ś:
> Trying to run unmodified Debian on 64MB is a suicide, I'd say the weakest
> type that are going to run stock Debian are chroots on n900, which, with
> 256MB, can handle all the phony stuff together with decompression just fine.
> If you allow for everyth
On Sat, Feb 12, 2011 at 3:06 PM, Andrey Rahmatullin wrote:
>> 128MB would work reasonably.
> I think that VPS'es with 128Mb RAM are still sold, not to mention existing
> installations.
May enable it on x64 first (those 128 mb VPSs are unlikely to run x64)
and then see about other archs later.
--
On Sat, Feb 12, 2011 at 9:57 PM, Adam Borowski wrote:
> On ARM, it's 90MB, I guess MIPS should be similar.
> The man page says 65MB even in -9, but I guess they didn't count in the
> code, libc, buffers and the likes.
>
> Trying to run unmodified Debian on 64MB is a suicide, I'd say the weakest
>
On Sat, Feb 12, 2011 at 02:57:59PM +0100, Adam Borowski wrote:
> Trying to run unmodified Debian on 64MB is a suicide, I'd say the weakest
> type that are going to run stock Debian are chroots on n900, which, with
> 256MB, can handle all the phony stuff together with decompression just fine.
> If y
On Sat, Feb 12, 2011 at 01:15:47PM +, Philipp Kern wrote:
> On 2011-02-11, Hideki Yamane wrote:
> > On Fri, 4 Feb 2011 08:20:02 +0100
> > Raphael Hertzog wrote:
> >> I have not seen any word about XZ support.
> > I want XZ support too, at least it reduce size for some font packages.
> > e.
On 2011-02-11, Hideki Yamane wrote:
> On Fri, 4 Feb 2011 08:20:02 +0100
> Raphael Hertzog wrote:
>> I have not seen any word about XZ support.
>> When you deployed support for new source package formats, you forbid
>> lzma because xz was coming along and you mentioned that wheezy could have
>> x
Package: wnpp
Severity: wishlist
Owner: Olivier Berger
* Package name: phpunit-mock-objects
Version : 1.0.8
Upstream Author : Sebastian Bergmann
* URL : https://github.com/sebastianbergmann/phpunit-mock-objects/
* License : BSD
Programming Lang: PHP
Descr
Package: wnpp
Severity: wishlist
Owner: Olivier Berger
* Package name: phpunit-dbunit
Version : 1.0.1
Upstream Author : Sebastian Bergmann
* URL : https://github.com/sebastianbergmann/dbunit/
* License : BSD
Programming Lang: PHP
Description : DbUnit
36 matches
Mail list logo
