seeking co-maintainers for spamassassin

[Noah Meyerhans]

I still make active use of spamassassin, but I don't have the time these
days to spend keeping up with bug reports and feature requests. Aside
from the backlog, the package is generally in good shape and works well
for most users. The upstream development is fairly stable, with the most
recent code release happening about a year ago. Upstream rule updates
are still fairly common, and although they should probably be pulled in
to the package more frequently than they have, I imagine that most users
are relying on sa-update to keep up-to-date.

Spamassassin is written in perl, with an additional small C program
(spamc). The source is maintained in svn and uses quilt for patch
management.

I'm perfectly happy to see patches attached to some of the open bugs, so
please don't hesitate to send them in. Ideally I'd like to get a
co-maintainer or two, though. Preferably these would be people who run
spamassassin in production somewhere, and who are thus appropriately
sensitive to the issues that come with mucking with other peoples'
email.

Thanks.
noah



signature.asc
Description: Digital signature

Bug#676295: ITP: cellml-api -- The CellML API Reference Implementation lets you manipulate and simulate mathematical models in the CellML modelling language

[Andrew Miller]

Package: wnpp
Severity: wishlist
Owner: Andrew Miller 

* Package name: cellml-api
  Version : 1.11
  Upstream Author : Andrew Miller 
* URL : http://cellml-api.sf.net/
* License : LGPL / GPL / MPL tri-licensed
  Programming Lang: C++ with Java and Python bindings
  Description : The CellML API Reference Implementation lets you manipulate
and simulate mathematical models in the CellML modelling language



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120605234028.5601.35011.report...@bioeng44a.bioeng.auckland.ac.nz

Bug#676292: ITP: libperlx-maybe-perl -- return a pair only if they are both defined

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name: libperlx-maybe-perl
  Version : 0.002
  Upstream Author : Toby Inkster 
* URL : http://search.cpan.org/dist/PerlX-Maybe/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : return a pair only if they are both defined

 Moose classes (and some other classes) distinguish between an attribute
 being unset and the attribute being set to undef. Supplying a
 constructor arguments like this:
 .
 my $bob = Person->new(
name => $name,
age => $age,
);
 .
 Will result in the "name" and "age" attributes possibly being set to
 undef (if the corresponding $name and $age variables are not defined),
 which may violate the Person class' type constraints.
 .
 PerlX::Maybe checks that $x and $y are both defined. If they are, it
 returns them both as a list; otherwise it returns the empty list.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120605225830.13135.44065.report...@auryn.jones.dk

Re: this bug .. bugs me

[Lisandro Damián Nicanor Pérez Meyer]

On Mar 05 Jun 2012 17:12:31 Michael Gilbert escribió:
> > They are members of pkg-wine already, so I think they can make changes
> > that can improve the status but not limited to minimal changes for
> > NMU. If Mike don't want to "hijack" at least for now, team upload is
> > good enough.
> 
> Hopefully this will make some people happy: I pushed the first team
> upload of the 1.4 series to unstable about a half-an-hour ago :)

\o/

And the same goes for team-maintained packages in general :)

-- 
9: Que es el "Explorador" de Windows
* El tipo que le roba las ideas a MacOs
Damian Nadales
http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Bug#676285: ITP: bsod -- curses Blue Screen of Death Simulator.

[Marcel Partap]

Package: wnpp
Severity: wishlist
Owner: Marcel Partap 

* Package name: bsod
  Version : 0.1
  Upstream Author : Folkert van Heusden 
* URL : http://www.vanheusden.com/bsod/
* License : GPL-2.0+
  Programming Lang: C
  Description : curses Blue Screen of Death Simulator.

package is done already - changelog needs a valid ITP number though ;-)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120605210003.19884.84669.reportbug@localhost

Re: this bug .. bugs me

[Stefano Zacchiroli]

On Wed, Jun 06, 2012 at 03:56:56AM +0800, Thomas Goirand wrote:
> Please do this *now*. We've already discussed about Wine in this
> list few months ago, and the situation is still the same. At some
> point, we need to get things moving...

Please don't spread incorrect information.  The situation is by far not
the same (as in: it's *much* better now), and that is also thanks to the
discussion back then.  -devel FTW, ... sometimes :-)

Cheers.
-- 
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences   ..   http://upsilon.cc/zack   ..   . . o
Debian Project Leader...   @zack on identi.ca   ...o o o
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: this bug .. bugs me

[Michael Gilbert]

> They are members of pkg-wine already, so I think they can make changes
> that can improve the status but not limited to minimal changes for
> NMU. If Mike don't want to "hijack" at least for now, team upload is
> good enough.

Hopefully this will make some people happy: I pushed the first team
upload of the 1.4 series to unstable about a half-an-hour ago :)

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANTw=MPow3FdboOcfm7okJVz7eM3fZu-rOX16_ZZ--XBP=z...@mail.gmail.com

Re: this bug .. bugs me

[Aron Xu]

On Wed, Jun 6, 2012 at 3:56 AM, Thomas Goirand  wrote:
> On 06/06/2012 01:41 AM, Michael Gilbert wrote:
>> And even then, I plan
>> to defer the matter to the tech committee
> Please do this *now*. We've already discussed about Wine in this
> list few months ago, and the situation is still the same. At some
> point, we need to get things moving...
>
> Thomas
>

They are members of pkg-wine already, so I think they can make changes
that can improve the status but not limited to minimal changes for
NMU. If Mike don't want to "hijack" at least for now, team upload is
good enough.


-- 
Regards,
Aron Xu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w4j29og50jacldhwidg1be8lvozf5ukkcna0xkxkrf...@mail.gmail.com

Re: this bug .. bugs me

[Thomas Goirand]

On 06/06/2012 01:41 AM, Michael Gilbert wrote:
> And even then, I plan
> to defer the matter to the tech committee
Please do this *now*. We've already discussed about Wine in this
list few months ago, and the situation is still the same. At some
point, we need to get things moving...

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fce6488.4050...@debian.org

Re: [pkg-wine-party] Bug#585409: this bug .. bugs me

[Stephen Kitt]

Hi Mike,

On Tue, Jun 05, 2012 at 01:41:42PM -0400, Michael Gilbert wrote:
> On Tue, Jun 5, 2012 at 1:17 PM, Christian PERRIER wrote:
> > You mean, besides completely hijacking the package?
> >
> > The last maintainer upload is dated 2010/05/23.
> >
> > So, from my POV, you (Michael) and Hilko Bengen seem to be the real
> > package maintainers for wine.
> >
> > My suggestion: do a maintainer upload of 1.4 in unstable, unless it
> > would affect some transition. And do it now.
> 
> I prefer cordiality.  I would rather give Ove a fairly significant
> amount of time before pursuing any such change. And even then, I plan
> to defer the matter to the tech committee because I believe initiating
> a takeover on my own is a conflict of interest, and again I am one for
> cordiality.

I don't know whether you'd noticed - you and I have been added to the
Wine packaging team on Alioth, so technically our uploads now are no
longer NMUs but team uploads!

Regards,

Stephen


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120605181751.gc14...@sk2.org

Re: this bug .. bugs me

[Simon McVittie]

On 05/06/12 16:52, Joey Hess wrote:
> This bug is a textbook example of making the perfect the enemy of
> the good.

Yes, pretty much. On the bright side, multiarch and a modern Wine
version have both arrived (Wine 1.4 is admittedly only in experimental
right now, but I hope it'll reach testing before we freeze), meaning
this can finally work:

archetype% dpkg --print-architecture
amd64
archetype% wine --version
wine-1.4
archetype% dpkg -s wine|grep Arch
Architecture: i386
archetype% dpkg -s ia32-libs
Package `ia32-libs' is not installed and no info is available.

... so, thanks to everyone whose work and perseverance made that possible!

S


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fce4e72.10...@debian.org

Bug#676257: ITP: libseccomp -- High level interface to the Linux Kernel's seccomp filter

[Kees Cook]

Package: wnpp
Severity: wishlist
Owner: Kees Cook 

* Package name: libseccomp
  Version : 0.1.0
  Upstream Author : Paul Moore 
* URL : https://sourceforge.net/projects/libseccomp/
* License : LGPLv2
  Programming Lang: C
  Description : High level interface to the Linux Kernel's seccomp filter

This library provides a high level interface to constructing, analyzing
and installing seccomp filters via a BPF passed to the Linux Kernel's
prctl() syscall.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120605180741.17371.60183.reportbug@localhost6.localdomain6

Re: this bug .. bugs me

[Andrey Rahmatullin]

On Tue, Jun 05, 2012 at 01:41:42PM -0400, Michael Gilbert wrote:
> > You mean, besides completely hijacking the package?
> >
> > The last maintainer upload is dated 2010/05/23.
> >
> > So, from my POV, you (Michael) and Hilko Bengen seem to be the real
> > package maintainers for wine.
> >
> > My suggestion: do a maintainer upload of 1.4 in unstable, unless it
> > would affect some transition. And do it now.
> 
> I prefer cordiality.  I would rather give Ove a fairly significant
> amount of time before pursuing any such change. And even then, I plan
> to defer the matter to the tech committee because I believe initiating
> a takeover on my own is a conflict of interest, and again I am one for
> cordiality.
Please don't forget that the freeze is near.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: this bug .. bugs me

[Joey Hess]

Andreas Barth wrote:
> * Joey Hess (jo...@debian.org) [120605 17:53]:
> > I've read over this entire bug, and while there are clearly some hard
> > problems and a lot of good work shown here, I'm seeing a concerning
> > trend throughout it.
> 
> I think the issues are now getting way better, with e.g. hillu
> uploading new wine versions to unstable. So while it bugs me as well,
> I don't think we need to discuss much about it for this package
> anymore as of now, as the right actions now take place. It might have
> taken too long to arrive there, but now we are there.

I'm less concerned about wine specifically (though there's still some
potential to release wheezy without the current 1.4 stable release, it
seems). This bug seems to illustrate some general problems with
prioritisation, which is why I brought it up on -devel.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Bug#171208: ITP: tlpr -- a Trivial LPR client

[Kurt Johnson]

Quick fix:

in the option section for "i - interface.
Change:
ip=malloc(sizeof(optarg)+1);
to
ip=malloc(strlen(optarg)+1);

Kurt

-- 
- 

Kurt Johnson
The KD Consulting Group Inc.
Voice: (513) 795-0901
Fax:   (740) 201-6437
http://www.kdconsulting.com 
gpg public key:  http://www.kdconsulting.com/KurtJohnson.asc


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fce4418.6010...@kdconsulting.com

Re: this bug .. bugs me

[Michael Gilbert]

On Tue, Jun 5, 2012 at 1:17 PM, Christian PERRIER wrote:
> You mean, besides completely hijacking the package?
>
> The last maintainer upload is dated 2010/05/23.
>
> So, from my POV, you (Michael) and Hilko Bengen seem to be the real
> package maintainers for wine.
>
> My suggestion: do a maintainer upload of 1.4 in unstable, unless it
> would affect some transition. And do it now.

I prefer cordiality.  I would rather give Ove a fairly significant
amount of time before pursuing any such change. And even then, I plan
to defer the matter to the tech committee because I believe initiating
a takeover on my own is a conflict of interest, and again I am one for
cordiality.

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANTw=moyq6g5dsqbm81+9iodumhvh7e7nggngemsupk0bwf...@mail.gmail.com

Re: this bug .. bugs me

[Christian PERRIER]

(No CC, please, I'm subscribed to -devel)

Quoting Michael Gilbert (mgilb...@debian.org):

> Anyway, we've had recent threads on the continuing issues with strong
> package maintenance, and from what I can tell, there is no clear
> direction.  The solution I'm pursuing is a liberal application of
> NMUs, and it seems to be working (albeit a bit slowly).  Do you have
> ideas on other more effective solutions?


You mean, besides completely hijacking the package? 

The last maintainer upload is dated 2010/05/23. 

So, from my POV, you (Michael) and Hilko Bengen seem to be the real
package maintainers for wine.

My suggestion: do a maintainer upload of 1.4 in unstable, unless it
would affect some transition. And do it now.

PS: I have no particular interest in wine, but, really, from what I
see, this seems to be the only solution to bring  more life to the
package.  And, of course, I have no authority (except my ignorance)
for suggesting this. Just giving my advice..:)





signature.asc
Description: Digital signature

Re: this bug .. bugs me

[Michael Gilbert]

On Tue, Jun 5, 2012 at 1:25 PM, Andrey Rahmatullin wrote:
> On Tue, Jun 05, 2012 at 12:46:46PM -0400, Michael Gilbert wrote:
>> Not sure what to say other than when I became a DD and gained the
>> power to NMU, I started fixing this.  Before that, Ove's contributor
>> rejections blocked myself and many other non-DDs from effectively
>> helping.
> I would also be glad to hear opinions on whether regularly NMUing a
> package with a formally active maintainer is acceptable and whether it can
> be called a takeover.

We are announcing our deferred uploads at least 10 days in advance
(unless RC) with git commit references, so Ove can review and/or
cancel/reject our work at any point.  Thus, we haven't taken any of
his power away and it really can't be viewed as a "takeover".  A few
of us are choosing to do the necessary work and review while Ove
doesn't have the time to do either himself.

Best wishes,
Mike


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANTw=mo+kfpk9756z7qoe+cjvw+_kp176wqfb28yhctu0qq...@mail.gmail.com

Re: this bug .. bugs me

[Andrey Rahmatullin]

On Tue, Jun 05, 2012 at 12:46:46PM -0400, Michael Gilbert wrote:
> Not sure what to say other than when I became a DD and gained the
> power to NMU, I started fixing this.  Before that, Ove's contributor
> rejections blocked myself and many other non-DDs from effectively
> helping.
I would also be glad to hear opinions on whether regularly NMUing a
package with a formally active maintainer is acceptable and whether it can
be called a takeover.
Not that I'm against a recent wine in the repos, quite the opposite.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: this bug .. bugs me

[Andreas Barth]

* Joey Hess (jo...@debian.org) [120605 17:53]:
> I've read over this entire bug, and while there are clearly some hard
> problems and a lot of good work shown here, I'm seeing a concerning
> trend throughout it.

I think the issues are now getting way better, with e.g. hillu
uploading new wine versions to unstable. So while it bugs me as well,
I don't think we need to discuss much about it for this package
anymore as of now, as the right actions now take place. It might have
taken too long to arrive there, but now we are there.


Andi


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120605170933.gv2...@mails.so.argh.org

unsubscibe

[JT]

Am 01.06.2012 12:17, schrieb Goswin von Brederlow:

m...@linux.it (Marco d'Itri) writes:


On May 18, Russ Allbery  wrote:


I do this work in cases where keeping the patches separate is useful for
some reason, but mostly it's not.

Some of my packages have 30-60 patches ("mature" software...), and
merging them would make them impossibile to understand.
Is there a VCS workflow which would make such packages easier to manage
than with quilt? (I like quilt, BTW.)

--
ciao,
Marco

Check out gitpkg. It has hooks to create the quilt patches from a set of
feature branches in some form.

Also note that in this scheme where you produce a single debian patch
you would not be working on the single debian patch. You would still
work on your 30-60 feature branches (or whatever else you use instead of
a patch queue). The single debian patch would just be the fallback for
people that can't access your VCS.

The single patch would be hard to understand but it would be unfair to
compare it to 30-60 patches in a patch queue. What you have to compare
the single patch with is a single debian diff.gz. Obviously if you can
make a meaningfull patch queue with seperate patches that is
preferable. The single patch method is for situations where you can't.

MfG
 Goswin





--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fce3c46.3000...@dresden-pieschen.de

Re: this bug .. bugs me

[Michael Gilbert]

On Tue, Jun 5, 2012 at 11:52 AM, Joey Hess wrote:
> 10 Jun 2010  a bug was filed wanting wine 1.2 packaged in time for squeeze.
> 12 Aug 2010  packages of 1.2 were available .. but not in Debian.
>  6 Feb 2011  squeeze shipped with the same wine version that shipped in lenny.
>  7 Mar 2012  wine 1.4 was released as the new upstream stable release
> 25 May 2012  wine 1.2 was finally made available in unstable
>
> I've read over this entire bug, and while there are clearly some hard
> problems and a lot of good work shown here, I'm seeing a concerning
> trend throughout it.
>
> We seem to have a problem with being willing to trade off simple
> solutions that will greatly benefit users, for doing things "right",
> even when doing things "right" benefits users *less*.
>
> Examples of that seen in this bug include:
>
> * An idea that every old release of wine needs to be packaged in sequence,
>  so it'll be available in snapshots, so users can pull down an old
>  version as needed for maximal ability to find one that works. That's
>  the theory, the actual end result is that users had no modern
>  wine version at all to use, for many years.
>
>  This is a simple tradeoff of benefits to sets of users,
>  and the set of users who know how to use snapshot.debian.org, need
>  a two year old version of wine there, and can find the right version is
>  clearly much smaller than the set of users who would like the latest
>  wine to see if it runs some program.
>
> * Wanting to support multiarch coinstallability, plus wine and
>  wine-unstable coinstallability. Nice goal, but again it prioritises
>  some small set of users who need 2 or even 4 versions of wine
>  coinstalled over the larger set of users who just want the newest wine
>  version.
>
> * Not using existing Ubuntu packages of wine despite them being
>  available for a long time at newer versions.
>
> * People doing work allowing themselves to be blocked for a long time on
>  some minor procedural point, like whether they have commit access to a
>  particular git repository, or are not being added as a member of some
>  particular team, or whether infrequent and apologetic posts by a package
>  maintainer are enough to keep them from being considered MIA.
>
> This bug is a textbook example of making the perfect the enemy of the good.
> It's disconcerting that we, or our users, are willing to put up with this.

Not sure what to say other than when I became a DD and gained the
power to NMU, I started fixing this.  Before that, Ove's contributor
rejections blocked myself and many other non-DDs from effectively
helping.

Anyway, we've had recent threads on the continuing issues with strong
package maintenance, and from what I can tell, there is no clear
direction.  The solution I'm pursuing is a liberal application of
NMUs, and it seems to be working (albeit a bit slowly).  Do you have
ideas on other more effective solutions?

Best wishes,
Mike


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANTw=mmqh9wd7nsye8vzslrhux1f+wo-cjnkhqgjc2hzho4...@mail.gmail.com

Re: Packaging on GitHub ?

[Thorsten Glaser]

Bernd Zeimetz  bzed.de> writes:

> On 05/29/2012 08:07 AM, Yao Wei (魏銘廷) wrote:
> > I am thinking about a more general topic like:
> > Managing packaging on VCS services other than Alioth
> 
> The other way rounds works well, too - package wherever you like to and
> mirror it on Alioth, for example in your personal git folder in your home.

The idea, in principle, is nice, but I’ve seen packages where
I suspect the primary maintainer (don’t want to write names
here) maintains it in his DVCS copy and pushes to the official
mirror listed in the VCS-* headers only rarely, so they are
out of date and not suitable for e.g. submitting patches. (Even
saw one where he had the VCS-* headers pointed to the previous
upstream major version branch, and while the branch for the
current upstream major version existed, it was out of date.)

Okay, this is a general problem with DVCSes, but mirroring, if
not done reliably-automatically, might (possibly even will) make
it worse.

People seem to dislike Alioth, mostly due to issues in the past
and load issues. Not sure whether anything can be done about that.
(Count me in for some of my packages though, where I’m developing
them in my own (but published) CVS repository… others I’ve put up
on Alioth though. But that’s mostly nostalgy. And dogfooding, since
I maintain that beast. Nothing against Alioth in its current in-
carnation, as long as the load issues don’t remain/come back. I’m
actually considering putting future packages of mine up there.)

bye,
//mirabilos
-- 
13:37⎜«Natureshadow» Deep inside, I hate mirabilos. I mean, he's a good
guy. But he's always right! In every fsckin' situation, he's right. Even
with his deeply perverted taste in software and borked ambition towards
broken OSes - in the end, he's damn right about it :(! […] works in mksh



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/loom.20120605t181356-...@post.gmane.org

this bug .. bugs me

[Joey Hess]

10 Jun 2010  a bug was filed wanting wine 1.2 packaged in time for squeeze.
12 Aug 2010  packages of 1.2 were available .. but not in Debian.
 6 Feb 2011  squeeze shipped with the same wine version that shipped in lenny.
 7 Mar 2012  wine 1.4 was released as the new upstream stable release
25 May 2012  wine 1.2 was finally made available in unstable

I've read over this entire bug, and while there are clearly some hard
problems and a lot of good work shown here, I'm seeing a concerning
trend throughout it.

We seem to have a problem with being willing to trade off simple
solutions that will greatly benefit users, for doing things "right",
even when doing things "right" benefits users *less*.

Examples of that seen in this bug include:

* An idea that every old release of wine needs to be packaged in sequence,
  so it'll be available in snapshots, so users can pull down an old
  version as needed for maximal ability to find one that works. That's
  the theory, the actual end result is that users had no modern
  wine version at all to use, for many years.
  
  This is a simple tradeoff of benefits to sets of users,
  and the set of users who know how to use snapshot.debian.org, need
  a two year old version of wine there, and can find the right version is
  clearly much smaller than the set of users who would like the latest
  wine to see if it runs some program.

* Wanting to support multiarch coinstallability, plus wine and
  wine-unstable coinstallability. Nice goal, but again it prioritises
  some small set of users who need 2 or even 4 versions of wine
  coinstalled over the larger set of users who just want the newest wine
  version.

* Not using existing Ubuntu packages of wine despite them being
  available for a long time at newer versions.

* People doing work allowing themselves to be blocked for a long time on
  some minor procedural point, like whether they have commit access to a
  particular git repository, or are not being added as a member of some
  particular team, or whether infrequent and apologetic posts by a package
  maintainer are enough to keep them from being considered MIA.

This bug is a textbook example of making the perfect the enemy of the good.
It's disconcerting that we, or our users, are willing to put up with this.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Moving /tmp to tmpfs makes it useless

[Uoti Urpala]

Goswin von Brederlow wrote:
> Uoti Urpala  writes:
> > I haven't read the relevant kernel code, but that doesn't match the
> > behavior I see. Reading a large file from tmpfs and then allocating
> > memory results in large swap writes every time, even if the newly
> > allocated memory is not itself immediately swapped out and the file
> > should already be in swap from before.
> 
> But does it rewrite the pages it has just read back? Or does it swap out
> some other pages it didn't have swapped out before?
> 
> It might consider a page it just had to swap in to be more valuable than
> a page it had lying around for a long time and rather swap out the old
> page than forget the just read page. So this doesn't proof that data in
> tmpfs is rewritten again and again.

There shouldn't be gigabytes of "other pages" to write. The set of
changing pages in memory that would always differ from what has already
been written to swap shouldn't be that large.


> > The script below can be used to test the behavior. It creates a file,
> > then loops alternatively reading the file and allocating+freeing memory.
> > It's noteworthy that sometimes the read performance also drops over
> > iterations (maybe the swap layout becomes more fragmented?). I used the
> > given sizes for testing on a machine with 8 GiB memory. This load does
> > run faster on ext4 than tmpfs.
> 
> What kernel?

I initially tested it on some older kernel; retried on 3.3.

Did you not try the script yourself if you expected different results?
If you did test, what results did you get?



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1338900090.21597.60.camel@glyph.nonexistent.invalid

Bug#676212: ITP: yubikey-personalization-gui -- GUI configuration tool for YubiKey tokens

[Klas Lindfors]

Package: wnpp
Severity: wishlist
Owner: Klas Lindfors 


* Package name: yubikey-personalization-gui
  Version : 3.0.5
  Upstream Author : Yubico Open Source Maintainers 
* URL : https://github.com/Yubico/yubikey-personalization-gui
* License : BSD-2-clause
  Programming Lang: C++
  Description : GUI configuration tool for YubiKey tokens

YubiKeys are USB tokens that act like keyboards and generate one-time
passwords, static passwords or work in challenge-response mode.

This is a graphical tool to customize the token with your own
cryptographic key and options.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120605115310.6108.7756.report...@debian.lan

Re: Starting services automatically after install

[Vincent Lefevre]

On 2012-06-03 08:21:34 +0200, Bernhard R. Link wrote:
> Try to see it from the other side: I don't understand why you would a
> like a service not started by default. The daemon is there to be run,
> so running it is the most sensible approach in almost all cases[1].

Well, a mail server daemon must not be run until it is completely
configured, in particular when manual configuration is needed,
e.g. to set up aliases and/or to check if some disk is mounted.
Otherwise this means that mail will be rejected. Because of that,
I potentially lost mail on an Ubuntu machine. But I think that
Debian has/had the same problem.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120605115705.ga3...@xvii.vinc17.org

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

[Stephan Seitz]

On Tue, Jun 05, 2012 at 10:33:13AM +0200, Goswin von Brederlow wrote:

Personally I thing DVD ISO images (downloaded) belong in your $HOME


Don’t you think this is getting quite ridiculous? Big temporary files 
belong in your $HOME, but small temporary files in /tmp? Only to switch 
/tmp from disk to RAM?



somewhere. And locally generated should just pipe the image to the
burner unless you want to upload the image somewhere, in which case


Or you want to keep it safe, until you are sure the burned DVD is 
working.


Of course, if I want to keep the ISO it will be stored in $HOME, but then 
it isn’t a *temporary* file anymore. And /tmp *is* for temporary files.



$HOME again. Just imagine a power failure after you painstackingly
uploaded 99.9% of the iso and then you have to start from scratch again
because a reboot cleans /tmp.


TMPTIME exists and can be set according to your needs and your safety 
concern.



Just out of interest: Do you have /tmp on /? Because if you do already
have a seperate /tmp partition then that obviously stays used.


I always have separate partitions for /, /usr, /var, /tmp, /usr/local and 
/home (allright, with crappy software like udev and Co. which starts 
wanting files in /usr needlessy at the early boot stages, I will merge 
/ and /usr in time). It isn’t a problem for me.


But we are talking about defaults. You wish to tell new users that there 
two TB disk can’t really be used as they wish because Debian has 
a strange distinction between temporary files belonging in /tmp and 
temporary files don’t belonging in /tmp?


According to the discussion the installer will create one partition for 
swap and one for /. If this is true then the standard user has far more 
space on disk than he has RAM.


Shade and sweet water!

Stephan

--
| Stephan Seitz  E-Mail: s...@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature

Re: Moving /tmp to tmpfs makes it useful

[Serge]

2012/6/5 Goswin von Brederlow wrote:

> You keep claiming tmpfs compromises system stability. Can you show a
> kernel oops of a crash caused by tmpfs?

No crashes, system just becomes slow and hard/impossible to use. See the
Stefan Lippers-Hollmann email about tmpfs vs disk writes. System that
does not respond to mouse clicks I called "less stable". I don't mind if
you suggest a better name for it.

> A short-livd file goes to cache, as dirty pages. dirty pages are then
> written to disk in the background. Are you claiming that filesystem do
> un-dirty pages when a file is deleted before it was actually written to
> disk?

Yes, I tested that. It's easy to test, run:
  dd if=/dev/zero of=testfile bs=1M count=20; rm -f testfile
then check /proc/diskstats or `iostat -k` for actually written bytes.

> As Mike says any fsync on the same filesystem generaly will force write
> the files in /tmp too.

It does not (Mike, are you sure?). I wrote a small test to check fsync
speed. Certainly fsync becomes slower on a heavily loaded disk. But it
becomes about same slower when I READ from disk instead of writing to it.
Fsync also does not cause the data to be flushed (there was about 50MB
of data in cache, but fsync usually took <0.1s, my disk is not that fast).
Can you actually reproduce that on your system?

>> 5. if you build a package, you can add it to global build options
>
> Not the default and you were talking about inexperienced users.

If the user is experienced enough to build a package, he can write:
  APPEND CFLAGS -pipe
  APPEND CXXFLAGS -pipe
to the /etc/dpkg/buildflags.conf as well. :)
(maybe it should be there by default, btw?)

> I think more than "nobody" has an SSD disk nowadays and they will only
> become more popular. At best ignoring SSDs is short sighted.

Ehm... I don't understand you. There're a lot of blind people there, and
ignoring them is also not the best idea. But how is that related to /tmp
on tmpfs? It does almost no help for SSD disks, because most writes are
not done to /tmp.

I don't know any people, who care about disk writes AND build packages
on SSD disks. But I think you're right, that they will become more and
more popular. At the same time they become more reliable, so if we're
talking about future — we don't have to worry about SSD at all, because
even modern SSD disks are supposed to live for 50+ years. :) [1]

> Unfortunately that limit seems to simply not work AT ALL. Writing to a
> slow filesystem like NFS or a USB stick just keeps writing and writing
> and writing till there is no more ram. With the obvious result of stuff
> blocking.

I don't have NFS to check, but I often write to USB disks, that are much
slower than my HDD, and get no swapping/blocking.

> Also shouldn't/couldn't tmpfs fall under the same ratio (or equivalent
> setting). No more than dirty_ratio pages should be dirty in tmpfs and
> then it could start swapping them out even without memory pressure?

IMHO, tmpfs is a filesystem in RAM, not a cache for "swap filesystem", so
dirty pages should be "flushed" to RAM, not to swap.

>> It won't, I tried. As long as there's enough RAM they don't get swapped.
>
> Well, worked here.

Maybe you have some unusual sysctl settings, e.g. vm.swappiness?

>> Which of them becomes faster with /tmp on tmpfs? Can you suggest a use
>> case, that I can test with /tmp on disk and on tmpfs myself and see them
>> becoming faster?
>
> All of them. In mc use the feature to look into tar/rpm/deb files.
> And try running apt-get upgrade in parallel for extra fsync()s.

I can't reproduce the fsync() problem, see above. Can you?
(also, mc does not unpack rpm/deb to /tmp when looking into it :))

[1] http://www.storagesearch.com/ssdmyths-endurance.html
-- 
  Serge


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caoveneo8cqm9p3cksqi6xpg05cczpgt-qzmb56+kmh761xg...@mail.gmail.com

Re: Upgrade path for packages that dropped ia32-libs for wheezy

[Goswin von Brederlow]

Scott Howard  writes:

> Hello,
>
> I have a non-free package that is distributable but comes precompiled
> for i386. Squeeze (and previous) released an amd64 package that
> depended on ia32-libs. For wheezy we've been able to use multiarched
> libraries to drop the dependency. Is there a mechanism that will make
> the upgrade to wheezy work for the package? Right now dpkg uninstalls
> the package (because it sees the data package, which is "all" but

Side note: Is the data package of any use other than for your binary?
Why have it arch:all if it is only usefull for the :i386 binary.

> can't find the corresponding binary package in amd64), users are
> confused, find a bug report on the BTS or the changelog on a debian
> site telling them to enable i386 in dpkg, then they install the :i386
> package and it works.
>
> This may just be a non-free issue people have to deal with, I just
> wanted to see if there was a better way or plan in place to handle
> this.
>
> Regards,
> Scott

I'm afraid there isn't a good solution. Users will need to enable
multiarch to upgrade those packages. And that needs apt/dpkg upgraded
first.

What I will do for ia32-libs is to use 2 packages something like this:

Package: ia32-libs
Depends: ia32-libs-i386
Architecture: amd64
Description: ia32-libs transitional package
 This package transitions the runtime libraries for the ia32/i386
 architecture, configured for use on an amd64 running a 64-bit kernel to
 use the new multiarch feature. It can be safely removed once nothing
 depends on it anymore.
 .
 To install/upgrade you need to enable multiarch first by running:
 + dpkg --add-architecture i386
 + apt-get update

Package: ia32-libs-i386
Architecture: i386
Depends: libfoo, libbar, libbaz
Description: ia32-libs transitional package
 This package transitions the runtime libraries for the ia32/i386
 architecture, configured for use on an amd64 running a 64-bit kernel to
 use the new multiarch feature. It can be safely removed once nothing
 depends on it anymore.
 .
 For use on amd64 systems with multiarch only.


By having 2 packages, one for amd64 and one for i386, I can have a
cross-architecture dependency. Using Depends: foo:i386 is not allowed in
wheezy and this is the next best thing.

I'm not sure wether such a dummy/transitional package would help in
your case. Prior to enabling multiarch the package will be uninstallable
so might be removed on upgrades the same as you have now. But that's the
best solution I've seen so far.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87hauqcfej.fsf@frosties.localnet

Re: Target path variables in debian/rules

[Goswin von Brederlow]

Ole Wolf  writes:

> I am building a package where I'm overriding the man page generation to
> include man pages that are generated at build time. A simplified version
> of the override in my debian/rules is:
>
> override_dh_installman:
> dh_installman --
> /somepath/create-a-man-page > ${mandir}/man1/packagename.1
>
> However, I don't know how to specify the target path for the man pages,
> which I've tentatively indicated by ${mandir} in the above snippet. I'm
> not using autoconf, which seems to set some path variables.
>
> What should I write instead of ${mandir} to get the proper path (so that
> the entire path on my particular system becomes
> debian/packagename/usr/share/man/man1/packagename.1)?

Why not reverse the two commands:

override_dh_installman:
/somepath/create-a-man-page > debian/packagename.1
dh_installman --

You then need to delete debian/packagename.1 in clean but you don't have
to muck around with the install part. Let dh_installman install the
generated manpage.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87lik2cfy2.fsf@frosties.localnet

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

[Goswin von Brederlow]

Stephan Seitz  writes:

> On Fri, Jun 01, 2012 at 02:19:53PM +0200, Goswin von Brederlow wrote:
>>In general your option assumes that you need the maximum amount of free
>>space in /tmp. That is simply not true. In most cases a small /tmp is
>>just peachy. Because of this it is hard to set a minimum size where
>>tmpfs would be too small to be usefull. For some user that would be
>>100MB, for others it is 100GB.
>
> /tmp is for temporary files, so I expect my /tmp to hold all these
> files, in my case DVD ISO images (downloaded or localy generated) that
> I will burn and then delete. So my /tmp is at least 20GB. BluRay users
> may need more.

So you are one of the 100GB users.

Personally I thing DVD ISO images (downloaded) belong in your $HOME
somewhere. And locally generated should just pipe the image to the
burner unless you want to upload the image somewhere, in which case
$HOME again. Just imagine a power failure after you painstackingly
uploaded 99.9% of the iso and then you have to start from scratch again
because a reboot cleans /tmp.

> If this is not the meaning of /tmp, then rename it.
>
> Diskspace is cheap and easier to spare than my RAM. So, yes, if
> someone has one 3TB partition which is writeable, then /tmp belongs to
> disk not to RAM.
>
> Shade and sweet water!
>
>   Stephan

Just out of interest: Do you have /tmp on /? Because if you do already
have a seperate /tmp partition then that obviously stays used.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87pq9ecg52.fsf@frosties.localnet

Re: Moving /tmp to tmpfs makes it useful

[Goswin von Brederlow]

Serge  writes:

> 2012/6/1 Goswin von Brederlow wrote:
>
>> All the complaints about /tmp as tmpfs come down to one simple issue:
>> The size of the tmpfs isn't chosen well.
>
> Mounting /tmp to tmpfs not just breaks a lot of apps and reduces system
> stability, but it actually does nothing else. You get no benefits from
> /tmp being on tmpfs.
> That's the complaint: the change makes something bad and nothing good.

You keep claiming tmpfs compromises system stability. Can you show a
kernel oops of a crash caused by tmpfs?

>> It also saves on wear of the disk if the files are small and short
>> lived, like temp files for gcc.
>
> I guess you talk about SSD-like disks. Then...
> 1. short-lived files remain in cache and don't hit the disk.

A short-livd file goes to cache, as dirty pages. dirty pages are then
written to disk in the background.

Are you claiming that filesystem do un-dirty pages when a file is
deleted before it was actually written to disk? Do they remove the pages
from the write queue when they are already picked up for write out?

> 2. gcc does not use fsync, does it?

As Mike says any fsync on the same filesystem generaly will force write
the files in /tmp too.

> 3. gcc with -pipe option does not use /tmp
> 4. if you manually build something, you can add -pipe option to CFLAGS
> 5. if you build a package, you can add it to global build options

Not the default and you were talking about inexperienced users.

> 6. this doesn't matter, since pretty much nobody builds apps on SSD disks
> So this is not even a corner case. :)

I think more than "nobody" has an SSD disk nowadays and they will only
become more popular. At best ignoring SSDs is short sighted.

>>> Yes because writing that on disk will only block the thread performing the
>>> write, not every thread that tries to allocate memory.
>>
>> Wrong.
> Not that much.
>> The thread doing the write will just write to cache and not block
>> at all. That is until you run out of cache.
> Until you run out of dirty_ratio, which is usually less than entire cache. :)

Unfortunately that limit seems to simply not work AT ALL. Writing to a
slow filesystem like NFS or a USB stick just keeps writing and writing
and writing till there is no more ram. With the obvious result of stuff
blocking.

Also shouldn't/couldn't tmpfs fall under the same ratio (or equivalent
setting). No more than dirty_ratio pages should be dirty in tmpfs and
then it could start swapping them out even without memory pressure?

>> No, tmpfs will be swapped out if you don't use a file for a while but
>> something else uses memory, including IO caching.
>
> It won't, I tried. I put a few hundreds MB on tmpfs and started reading
> and copying gigabytes of files, tar/untar archives. I was still getting
> no swap usage. As long as there's enough RAM they don't get swapped.

Well, worked here. I know swap usage/behaviour widely varries between
kernel versions. I've seen kernels that didn't use swap even after a
week but also kernels that used swap after an hour all with the pretty
much the same usage pattern on my desktop.

>>> I'm asking for *popular* apps, that create files in /tmp, *never put
>>> large files* there, and become *noticeably* faster with /tmp on tmpfs?
>>
>> gcc, ocamlopt, mc, lintian
>
> Which of them becomes faster with /tmp on tmpfs? Can you suggest a use
> case, that I can test with /tmp on disk and on tmpfs myself and see them
> becoming faster?

All of them. In mc use the feature to look into tar/rpm/deb files.
And try running apt-get upgrade in parallel for extra fsync()s.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87txyqcgp8.fsf@frosties.localnet

Re: Moving /tmp to tmpfs makes it useful

[Goswin von Brederlow]

Mike Hommey  writes:

> On Tue, Jun 05, 2012 at 09:29:46AM +0300, Serge wrote:
>> 2012/6/1 Goswin von Brederlow wrote:
>> 
>> > All the complaints about /tmp as tmpfs come down to one simple issue:
>> > The size of the tmpfs isn't chosen well.
>> 
>> Mounting /tmp to tmpfs not just breaks a lot of apps and reduces system
>> stability, but it actually does nothing else. You get no benefits from
>> /tmp being on tmpfs.
>> That's the complaint: the change makes something bad and nothing good.
>> 
>> > Even without load it is much faster because fsync() becomes a NOP.
>> 
>> Yes, it is. So it's a good idea to use tmpfs for some apps, that
>> heavily use fsync() on files that fit in RAM. But... wait... no app
>> is heavily using fsync() on files in /tmp. So it's useless to put
>> /tmp on tmpfs.
>
> It takes one application using fsync on any file in / for all files in
> /tmp to be flushed to disk if it's the same filesystem. It doesn't need
> to be the application using /tmp doing fsync.
>
> Mike

For example runing "apt-get upgrade" while doing other stuff that uses
/tmp.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87y5o2chhx.fsf@frosties.localnet

Bug#676166: ITP: cpputest -- C/C++ based unit test framework

[Raphaël Hertzog]

Package: wnpp
Severity: wishlist
Owner: "Raphaël Hertzog" 

* Package name: cpputest
  Version : 3.1
  Upstream Author : James Grenning & Bas Vodde
* URL : http://www.cpputest.org/
* License : BSD
  Programming Lang: C++
  Description : C/C++ based unit test framework

CppUTest is a C/C++ based unit xUnit test framework for unit testing and
for test-driving your code. It is written in C++ but is used in C and C++
projects and frequently used in embedded systems.

CppUTest has a couple design principles:
 * Simple to use and small
 * Portable to old and new platforms

CppUTest also has support for building mocks and can be used by
practitioners of Test Driven Development.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120605073718.25873.26663.reportbug@rivendell.localdomain

Re: Moving /tmp to tmpfs makes it useless

[Goswin von Brederlow]

Uoti Urpala  writes:

> Goswin von Brederlow wrote:
>> > Le vendredi 25 mai 2012 à 16:01 +0300, Uoti Urpala a écrit : 
>> >> There is one significant difference though. When you read data back to
>> >> memory from swap, the kernel does not remember that it already exists on
>> >> disk; when the data is evicted from memory again, it is unnecessarily
>> >> rewritten to disk rather than just dropped. Thus, if you do multiple
>> >> read iterations through a large set of data (which does not fit in
>> >> memory) on tmpfs, each iteration does disk read AND write rather than
>> >> just read.
>
>> Linux certainly has a notion of cached swap, i.e. pages from swap that
>> are also unmodified in memory. As long as you have enough swap the
>> kernel should not reap the swapped data and know that it is already on
>> disk when it wants to evict the page.
>
> I haven't read the relevant kernel code, but that doesn't match the
> behavior I see. Reading a large file from tmpfs and then allocating
> memory results in large swap writes every time, even if the newly
> allocated memory is not itself immediately swapped out and the file
> should already be in swap from before.

But does it rewrite the pages it has just read back? Or does it swap out
some other pages it didn't have swapped out before?

It might consider a page it just had to swap in to be more valuable than
a page it had lying around for a long time and rather swap out the old
page than forget the just read page. So this doesn't proof that data in
tmpfs is rewritten again and again.

> The script below can be used to test the behavior. It creates a file,
> then loops alternatively reading the file and allocating+freeing memory.
> It's noteworthy that sometimes the read performance also drops over
> iterations (maybe the swap layout becomes more fragmented?). I used the
> given sizes for testing on a machine with 8 GiB memory. This load does
> run faster on ext4 than tmpfs.

What kernel?

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87396adwof.fsf@frosties.localnet

Re: Moving /tmp to tmpfs makes it useless

[Goswin von Brederlow]

Salvo Tomaselli  writes:

>> No, tmpfs will be swapped out if you don't use a file for a while but
>> something else uses memory, including IO caching. 
> unless too many things want to use memory, then tmpfs gives a great 
> contribution in taking down the machine.
>
> As you pointed out yourself in another email, under memory pressure the 
> kernel 
> starts doing odd choices.
>
> So the point is: is it correct to enforce a default setting that will break 
> many software that would otherwise work flawlessy, and that makes the machine 
> less reliable but faster for certain kind of tasks?

You're still ignoring that a disk based filesystem puts up the same
memory pressure, even more so for the journal and metadata overhead.

As I pointed out the tipping point can be easily recreated by writing to
NFS. A slow USB device works too if you have one big enough. I haven't
seen the same behaviour with tmpfs but then again I don't put files much
much larger than my ram in /tmp.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877gvmdwv8.fsf@frosties.localnet

Re: Moving /tmp to tmpfs makes it useless

[Goswin von Brederlow]

Ben Hutchings  writes:

> On Fri, Jun 01, 2012 at 11:19:40PM +0200, Carlos Alberto Lopez Perez wrote:
>> On 01/06/12 13:33, Goswin von Brederlow wrote:
>> >> > I don't know the ultimate reason behind this ugly behaviour of Linux
>> >> > when the swapping process is happening, but I know this is real and it
>> >> > happens because I have experimented this situation myself more than a
>> >> > couple of times.
>> > It's a matter of that gets swapped and linux choosing the wrong thing to
>> > swap (far too often). There is some "bug" in linux that when you have
>> > lots and lots of IO at some point the swap heuristics tip over and start
>> > swapping apps and usefull data to create more cache space for
>> > IO. Doesn't matter that you already have 3GB for cache, it still swaps
>> > out your mouse cursor and then things go real bad.
>> 
>> This makes sense. Many times I have experimented this situation while
>> copying a large file from a quick device (hdd) to a very slow device
>> (cheap usb stick)
>> 
>> IMHO The logical way of behaving in such situation is to slow-down the
>> IO bandwidth of the processes that are filling the cache, by sending to
>> sleep any process that requests more IO while the cache is full instead
>> of trying to free RAM by swapping out things from the RAM to the swap.
>> 
>> Do you know any way to avoid (or mitigate) this? Perhaps some sysctl
>> variable?

There are 2 settings for that, one to limit the number of dirty pages
before writing them starts and one to limit the number of dirty pages
being written (being on-the-fly) at any one time. The defaults are iirc
30% and 10% but none of that seems to matter. A process writing to a
slow devcie isn't put to sleep if the limits are exceeded so it keeps
eating up memory with dirty pages.
 
>> Can't Linux be configured to just block (sleep) any process that
>> requests IO while the cache is full?
>>
>> Perhaps a good idea would be to limit the cache size on a per-PID basis
>> and block (sleep) the pid while its cache is full.
>
> I don't think it makes any sense to have a hard per-process limit.
> Also, it's not generally possible to account dirty pages to specific
> processes exactly.  But I think you will be pleased with this change
> that was included in Linux 3.2:
>
> http://lwn.net/Articles/456904/
>
> Ben.

Hui, lets hope that works better.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87bokydx4p.fsf@frosties.localnet

Re: Moving /tmp to tmpfs makes it useless

[Goswin von Brederlow]

Salvo Tomaselli  writes:

>> If anyone wants to experience that then write out some GB of data over
>> NFS. After a short while processes will hang while others keep running.
>
> True, that's what i was saying.
> But if there is not enough memory, it's not only one process that will hang. 
> It's everything.
> So i think that adding pressure on the RAM, which is absolutely not as 
> aboundant as disk space is a mistake, for a generic configuration.
> If you know that you aren't going to hit that high memory allocation then.. 
> free to use tmpfs.

Doesn't matter if the pressure is from IO to a disk based filesystem or
IO to tmpfs. They both go to the same buffer cache anyway.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87fwaadxjs.fsf@frosties.localnet

Re: debuild/dpkg-buildpackage behaves not as expected

[Goswin von Brederlow]

debian-de...@liska.ath.cx (Olе Streicher) writes:

> Goswin von Brederlow  writes:
>> debian-de...@liska.ath.cx (Ole Streicher) writes:
>>> I think the best way would be that debuild/dpkg-buildpackage would not
>>> automatically unapply the patches (so it would leave the source in the
>
>> It doesn't automatically unapply the patches. It only restores the state
>> you had before the dpkg-buildpackage was called.
>
> It does not since it keeps the compiled files. If you mean it serious
> with "restoring the state", you should call clean here, too.

The state of the patches.

>>> or hook that does this for those who really need it (and know what they
>>> are doing).
>> Which would mean that you would have to unapply patches every time you
>> try to build while working on a patch. With the current behaviour I can do
>>
>> quilt push foo.patch   (foo.patch being somewhere in the middle)
>> edit file
>> quilt refresh
>> debuild
> [...]
>
> You can do the same even if either "clean" is called before the
> unpatching was done, or if neither clean nor unpatching was done, since
> quilt recognizes the state.

If the patches aren't rolled back to foo.patch after build then the
files will differ. If you still have the file open in an editor then
editing it will destroy stuf. And quilt refresh will refresh the topmost
patch and not foo.patch as intended.

So no, you can't do the same without the patch state being restored.

> The point is really: The state
> * compiled files (*.o etc.) from a patched package, but
> * unpatched source files
> is inconsistent. 

In a good way. :)

> Best regards
>
> Ole

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k3zmdxvd.fsf@frosties.localnet