On Wed, 28 Jun 2006, Adam Borowski wrote:
> On Wed, Jun 28, 2006 at 02:06:26AM -0700, Don Armstrong wrote:
> > On Wed, 28 Jun 2006, Adam Borowski wrote:
> > > Let's allow maintainers to use make -jX according to their common
> > > sense, requiring obeying an env variable to opt out.
> >
> > Why no
On Wed, 2006-06-28 at 10:36 +0200, Bill Allombert wrote:
> > Here, the only way seems to be putting an entry in NEWS.Debian (for
> > users script, ie things not under our control).
Good idea, Christian.
> In addition, I would suggest we reinstate the previous behaviour, but
> display a warning w
On Tue, 2006-06-27 at 13:09 +0200, Jeroen van Wolffelaar wrote:
> But on the other hand, according to the 'be strict in what you send,
> liberal in what you accept' mantra, it makes sense for tar to not create
> tarfiles which in the past have caused issues for certain programs while
> there's a p
On Tue, Jun 27, 2006 at 09:22:45PM +0100, Aigars Mahinovs wrote:
> Ian Jackson <[EMAIL PROTECTED]> said:
> > I'm one of the small minority of people who have a very negative
> > opinion about gmail. I realise I'm a bit of a kook on this subject
> > and I'd ideally I'd like to avoid having an enorm
Package: wnpp
Severity: wishlist
Owner: "Adeodato Simó" <[EMAIL PROTECTED]>
* Package name: libgetopt++
Version : 0.0.2-p22
Upstream Author : Robert Collins <[EMAIL PROTECTED]>
* URL :
http://people.ubuntu.com/~robertc/rbtcollins%40hotmail.com--barch/libgetoptplusplus/
On Tue, Jun 27, 2006 at 03:40:49PM +0200, Thijs Kinkhorst wrote:
> In that case just reverting the Debian change isn't the right way. If
> you think that the change is wrong, then you should make upstream fix
> it: changing behaviour of tar is one thing, but having different
> behaviour of a basic
On Wed, Jun 28, 2006 at 07:50:50PM +0300, Lars Wirzenius wrote:
> ke, 2006-06-28 kello 18:43 +0200, Adam Borowski kirjoitti:
> > What do you think about going with Don Armstrong's suggestion
> > ($CONCURRENCY_LEVEL), while handling the default (no env var) my
> > way (decent memory => parallel, lit
Hi,
Thank $DEITY for testers. We discovered another issue when root is
on LVM is on RAID. If that's your setup, please hold off on using
mdadm 2.5 until I managed to fix #375879. Sorry for the
inconvenience, and again, thanks to Alec Berryman for his help. He
also spotted the last issue.
--
Plea
ke, 2006-06-28 kello 18:43 +0200, Adam Borowski kirjoitti:
> What do you think about going with Don Armstrong's suggestion
> ($CONCURRENCY_LEVEL), while handling the default (no env var) my
> way (decent memory => parallel, little memory => -j 1) instead of
> Ingo's (-j 1 unless explicitely set)?
On Wed, Jun 28, 2006 at 03:42:07PM +0200, Wouter Verhelst wrote:
> SMP buildd systems currently run multiple instances of buildd at
> the same time, rather than expecting a package to specify make -j
> itself. Having three packages that specify 'make -j 4' on a
> multiprocessor buildd host that _al
Hi,
On Tue, Jun 27, 2006 at 09:22:45PM +0100, Aigars Mahinovs wrote:
> Ian Jackson <[EMAIL PROTECTED]> said:
> > I'm one of the small minority of people who have a very negative
> > opinion about gmail. I realise I'm a bit of a kook on this subject
> > and I'd ideally I'd like to avoid having an
Both sides in this discussion seem to have valid concerns:
FOR making --wildcard the default
- compatibility with upstream
- compatibility with standards
- compatibility with other distributions
- whatever reasons POSIX had for this were probably sensible
- upstream's judgement on
On Wed, Jun 28, 2006 at 12:01:31PM +0200, Adam Borowski wrote:
> On Wed, Jun 28, 2006 at 02:06:26AM -0700, Don Armstrong wrote:
> > This has the disadvantage of not automatically using -j for every
> > package and requiring maintainer buy in to see results... but
> > presumably those packages where
Hi again,
I am sorry, but there is a stupid, minor glitch in the
README.experimental file, which may lead to an unbootable system
with initramfs-tools << 0.65.
The cause of the problem is the sed call:
sed -i -e 's,^PREREQ=\"md\"$,PREREQ=\"mdadm\"$,' \
/usr/share/initramfs-tools/scripts/lo
On Wed, Jun 28, 2006 at 03:22:35PM +0200, Ingo Juergensmann wrote:
> On Wed, Jun 28, 2006 at 01:37:37PM +0200, Adam Borowski wrote:
> > The benefits on UP are small (~10%), but except for huge working
> > sets, non-negative. And the maintainer knows if the package handles
> > huge chunks at once o
On Wed, Jun 28, 2006 at 01:37:37PM +0200, Adam Borowski wrote:
> > Well, make -jX is not everywhere faster on UPs. It depends on other factors
> > as well. If you specify -j2 and the second make is causing lots of swapping,
> > you won't gain much if anything at all.
> Exactly, just like I said:
On Wed, Jun 28, 2006 at 12:38:51PM +0200, Ingo Juergensmann wrote:
> I don't think it's good to define an opt-out variable (*_NON_PARALLEL).
> Think positive! So, it would be better to define DEB_MAKE_PARALLEL, but even
> better it would be to use something existing: CONCURRENCY_LEVEL as Don
> Amst
On Tue, 27 Jun 2006 18:25:20 +0200
Wouter Verhelst <[EMAIL PROTECTED]> wrote:
> On Tue, Jun 27, 2006 at 02:08:57PM +0200, Michal Čihař wrote:
> > On Mon, 26 Jun 2006 21:35:19 +0200
> > Wouter Verhelst <[EMAIL PROTECTED]> wrote:
> >
> > > No. There is snd-pcm-oss.ko, which provides working OSS sou
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 22 Jun 2006 22:46:59 +0200 David Härdeman wrote:
> in debian-installer, there is a package - partman-auto-lvm - which
> can setup an entire disk to be used for the debian installation with
> the use of lvm for most partitions.
>
> Currently i
On Wed, Jun 28, 2006 at 12:38:51PM +0200, Ingo Juergensmann wrote:
> On Wed, Jun 28, 2006 at 10:31:54AM +0200, Adam Borowski wrote:
> > On the other hand, making builds significantly faster is not
> > something that you can shake a stick at. Typically make -jX is faster
> > even on uniprocessor, a
On Wed, Jun 28, 2006 at 12:44:50PM +0200, Alexander Sack wrote:
> On Wed, Jun 28, 2006 at 12:10:45PM +0200, Alexander Sack wrote:
> > On Tue, Jun 27, 2006 at 10:54:47PM -0400, Eric Dorland wrote:
> > > > >
> > > > > Could you send me a copy of your bookmarks.html file privately?
> > > >
> > > >
On Wed, Jun 28, 2006 at 12:10:45PM +0200, Alexander Sack wrote:
> On Tue, Jun 27, 2006 at 10:54:47PM -0400, Eric Dorland wrote:
> > > >
> > > > Could you send me a copy of your bookmarks.html file privately?
> > >
> > > Eric, was this reproducible?
> >
> > Unfortunately it was very reproducible
On Wed, Jun 28, 2006 at 02:06:26AM -0700, Don Armstrong wrote:
> Why not just have some ENV variable (CONCURRENCY_LEVEL?) which
> specifies the maximum -j; the package maintainer is free to choose any
> level equal to or below that.
> [...]
> This has the disadvantage of not automatically using -
On Wed, Jun 28, 2006 at 10:31:54AM +0200, Adam Borowski wrote:
> On the other hand, making builds significantly faster is not
> something that you can shake a stick at. Typically make -jX is faster
> even on uniprocessor, and I don't need to tell you why it's much
> faster on SMP.
Well, make -jX
On Tue, Jun 27, 2006 at 10:54:47PM -0400, Eric Dorland wrote:
> > >
> > > Could you send me a copy of your bookmarks.html file privately?
> >
> > Eric, was this reproducible?
>
> Unfortunately it was very reproducible :( I'm not sure how to
> proceed. Is anyone else using these patches that mig
On Wed, Jun 28, 2006 at 02:06:26AM -0700, Don Armstrong wrote:
> On Wed, 28 Jun 2006, Adam Borowski wrote:
> > Let's allow maintainers to use make -jX according to their common
> > sense, requiring obeying an env variable to opt out.
>
> Why not just have some ENV variable (CONCURRENCY_LEVEL?) whi
On Wed, 28 Jun 2006, Adam Borowski wrote:
> Let's allow maintainers to use make -jX according to their common
> sense, requiring obeying an env variable to opt out.
Why not just have some ENV variable (CONCURRENCY_LEVEL?) which
specifies the maximum -j; the package maintainer is free to choose any
Package: wnpp
Severity: wishlist
Owner: Piotr Ozarowski <[EMAIL PROTECTED]>
* Package name: python-chardet
Version : 1.0
Upstream Author : Mark Pilgrim <[EMAIL PROTECTED]>
* URL : http://chardet.feedparser.org/
* License : GPL
Programming Lang: Python
Descri
Meep.
I have done some major work on mdadm in experimental, which is now
at version 2.5.2-1. I still have not received enough success reports
to make me comfortable enough to upload to unstable, so here's
another request for testing (or else etch will ship with 2.4.1).
I am 95% confident that it'
On Wed, Jun 28, 2006 at 07:02:15AM +0200, Christian Perrier wrote:
> > Debian still has to provide an upgrade path for users upgrading from Sarge.
> > We cannot blindly break users scripts.
>
> Here, the only way seems to be putting an entry in NEWS.Debian (for
> users script, ie things not under
On Wed, Jun 28, 2006 at 03:17:27AM +0200, Henning Makholm wrote:
> > If package maintainer wants to build it faster on their own machine, I
> > would imagine that checking for an environment variable (DEB_MAKE_OPTS
> > or something, perhaps?) and using that would be the way to go. By
> > default, b
Package: wnpp
Severity: wishlist
Owner: alex bodnaru <[EMAIL PROTECTED]>
* Package name: zope-compositepack
Version : 1.0
Upstream Author : Godefroid Chapelle ([EMAIL PROTECTED])
* URL : http://plone.org/products/compositepack
* License : Zope Public License (Z
Package: wnpp
Severity: wishlist
Owner: alex bodnaru <[EMAIL PROTECTED]>
* Package name: zope-cmfcompositepage
Version : 0.2
Upstream Author : Shane Hathaway, Zope Corporation, <[EMAIL PROTECTED]>
* URL : http://hathawaymix.org/Software/CompositePage
* License
On Wed, Jun 28, 2006 at 03:17:27AM +0200, Henning Makholm wrote:
> Scripsit Lars Wirzenius <[EMAIL PROTECTED]>
>
> > If package maintainer wants to build it faster on their own machine, I
> > would imagine that checking for an environment variable (DEB_MAKE_OPTS
> > or something, perhaps?) and usi
34 matches
Mail list logo
