Re: TrueType fonts packages maintenance team proposal

[Marcus Better]

Christian Perrier wrote:
> I have voluntarily limited the scope of the project to TTF fonts,
> which become more an more popular.

Perhaps the PostScript fonts in Debian could use some attention as well.
I've been trying to package a very simple PHP library which in the upstream
version includes copies of the "standard" Adobe fonts  (Courier, Times
etc). It turns out that these fonts are included in various Debian
packages, but unfortunately they don't make them available to other
applications in a uniform manner (especially not if you want to preserve
the association between .pfa and .afm files).



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Is Chris Anderson MIA?

[Marcus Better]

Hi,

does anyone have information on the whereabouts of Chris Anderson
<[EMAIL PROTECTED]>, the maintainer of php-date?

I'm trying to get the package updated because it's severely outdated, but I
haven't received any responses on either bug reports or private e-mail.

Marcus



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Best scheme for teams and Maintainer/Uploaders fields ?

[Marcus Better]

Pierre Habouzit wrote:
>   in the KDE Team we use: Maintainer , Uploaders  responsible for the packages>. The list beeing [EMAIL PROTECTED] or
> [EMAIL PROTECTED]

The Java team uses the same method, but it has IMHO the huge drawback
that "uploaders" sometimes stop paying attention to a package without
notice, and are never unlisted from the Uploaders field [1], until the
package is effectively orphaned. This scheme does not discourage
such "fire-and-forget" behaviour. I think it's a very good idea to have a
single lead Maintainer.

Marcus

[1] http://lists.debian.org/debian-java/2006/10/msg00021.html



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Best scheme for teams and Maintainer/Uploaders fields ?

[Marcus Better]

Christoph Berg wrote:
> Note that you can subscribe additional packages to any maintainer
> view. The GIS team does that:

Is there a way to subscribe a mailing list to receive bug reports also,
without having the mailing list in the Maintainer field?

Marcus



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using defoma for building package ?

[Marcus Better]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Josselin Mouette wrote:
> How about using fontconfig ? Even without using the API you can use it
> to look for a font:
> $ fc-match --verbose sans | awk '$1=="file:"'
> file: "/var/lib/defoma/fontconfig.d/D/DejaVu-Sans.ttf"(s)

Is there a way to use fc-match to locate a Type1 font (pfb) and also its
associated font metrics (the afm file)?

Marcus

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEVSFhXjXn6TzcAQkRAt1DAKCVI2yEibbdFoNp/pzK7YkbC1ApZACfZtrC
uRwegAoBJyh80IdKeosTrHk=
=CIAw
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Using defoma for building package ?

[Marcus Better]

Josselin Mouette wrote:
>> Is there a way to use fc-match to locate a Type1 font (pfb) and also its
>> associated font metrics (the afm file)?
> 
> I may be wrong, but as fontconfig was designed for Xft which doesn't
> make use of the .afm file but only uses the .pfb directly, I think
> fontconfig cannot locate the .afm.

Ok, do you know of some other way to do the above?

Marcus



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

svn package maintenance

[Marcus Better]

Hello,

I've recently started to use svn for package maintenance, both in order to
enable team maintenance and because it's a great way to keep track of the
code.

Previously I used dpatch or quilt for the Debian changes. However with svn
(or any other version control system) it really doesn't make sense to use
that. The VCS is great at keeping track of changesets. Keeping patches in
svn effectively circumvents the whole point of VCS. (This is probably
obvious to anyone who has tried it, so I won't elaborate on it here.)

I'm now trying to replicate the advantages of quilt with svn. Some of these
advantages are:

*Keep track of separate changesets (sets of changes which logically belong
together).
*Individual changesets can be extracted for review or for sending upstream.
*Helps with updating the changesets for new upstream versions.

The best way to handle this in svn seems to be to use feature/integration
branches as mentioned in this talk (p. 23 ff.):
http://martin-krafft.net/phd/talks/fosdem2006-workflow.pdf

This leads to the first question: What is the recommended repository layout?
I'm currently using something like this:

branches/upstream/1.2  (upstream source v1.2) 
branches/feature/fix-a-bug (branch from upstream source for a feature)
branches/feature/change-path-names
branches/feature/debian(debian/ directory is also a feature)
trunk  (integration branch, for merging features)
tags/1.2-1 (Debian release)
tags/1.2-2

Of course any similar layout works equally well. The point of having a
common standard is that it would be possible to write support tools that
make this layout less cumbersome to work with. I am thinking of something
like quilt/stgit, but implemented for svn, that would understand this
repository layout, keep better track of the various branches and make it
easier to switch between them, update to new upstream versions, etc.

Does anyone else have thoughts in this direction?

Marcus



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn package maintenance

[Marcus Better]

martin f krafft wrote:
> Well, ideally the support tool should not impose on the structure

Yes, svn-buildpackage is quite nice since it's easy to tell it about your
layout. Something like that could work here as well.

> SVN does not track merges across branches, unless you do it in the
> changelog.

I know, it's a pain in the neck. But still it's a good step forward over
CVS, and seems to be quite popular in Debian. I hope svn will improve in
this area.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#546370: general: KDE provokes Xorg to take too much CPU and RAM

[Marcus Better]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I have a lenny/sid/experimental amd64 system with KDE 4.3.1 and latest
X.org, and it certainly looks like X.org is often taking an inordinate
amount of CPU. The system becomes slow an unworkable after a few days,
with X.org CPU usage climbing from the "normal" 4% to several times that
(permently), according to the KDE system activity monitor. I don't know
if this is due to KDE or something else.

This is a Thinkpad T61 laptop, Intel Core 2 Duo, 4 GB memory.

Cheers,

Marcus
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkquAT4ACgkQXjXn6TzcAQklhQCg46a832n5NxNrjUijNsBLBRln
ul8AoL004KqTPSAR6z1GKZlPEcRXrCPy
=ZHnL
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

ITP: libjs-extjs -- a cross-browser JavaScript library

[Marcus Better]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

This is non-free. Please keep it out of Debian.

Surely you are aware of the huge controversy around Ext JS licensing.
There is no need to repeat that story here, let me just point to this page:
  http://www.extjs.com/company/dual.php

Here they make claims that directly contravene parts of GPL-3:

"If you derive a commercial advantage by having a closed source
solution, you must purchase an appropriate number of commercial licenses
from Ext."

And this:

"If you wish to use the open source license of an Ext product, you must
contribute all your source code to the open source community and you
must give them the right to share it with everyone too."

Cheers,

Marcus
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkrMkP8ACgkQXjXn6TzcAQnSQACgsS7QYWk1A7wnFbGiicmT1Xi9
eEMAoM+dtmYBb9d6W73/rL1tvmVTIDvw
=j+pZ
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#550031: ITP: libjs-extjs -- a cross-browser JavaScript library

[Marcus Better]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thomas Goirand skrev:
>> Surely you are aware of the huge controversy around Ext JS licensing.

> Hell, I missed it.

Oh well :-)

> This doesn't appear at all on the license.txt. Do you
> think I could still package it for the non-free archive?

I don't know. But your first remark illustrates one problem with their
licensing policies - they are simply unclear and ambiguous, and by now
one must assume that it is intentional.

For example it is not clear what it means to license something under GPL
"with strings attached". It seems (to me) that their interpretation is
that users who get Ext under the GPL will *not* be able to redistribute
it freely, likewise under the GPL. (In fact that would circumvent their
whole "dual-licensing" policy.)

Cheers,

Marcus

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkrMoi0ACgkQXjXn6TzcAQmf3gCfUEP6rXAiJ8/sFpEaK6y+IzdF
ksMAn2rSvjEYAJm8np2RyDmEDYyeygms
=E9zo
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#550031: ITP: libjs-extjs -- a cross-browser JavaScript library

[Marcus Better]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thomas Goirand skrev:
> Please do not start a 100 post thread in this ITP if this has been
> discussed in the past (let's not loose time twice on a bad license). I
> just would like to have a link here to the archive of the old discussion
> about if one of you can find it.

I didn't mean to imply that this has been discussed within Debian. There
has been a fair amount of discussion on the web though, with several
controversial issues:

* The previous licensing under LGPL-with-strings-attached [1]
* The sudden relicensing from LGPL to GPL [2]
* The current GPL-with-conditions license.

In particular see the comments by Ext JS founder Jack Slocum [1], who
was clearly opposed to redistribution under LGPL (this was before the
switch to GPL).

See also the Wikipedia talk page [3].

Cheers,

Marcus

[1] http://mjg59.livejournal.com/84586.html
[2]
http://graemerocher.blogspot.com/2008/04/choosing-and-oss-license-and-ext-js.html
[3] http://en.wikipedia.org/wiki/Talk:Ext_(JavaScript_library)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkrM5z4ACgkQXjXn6TzcAQkeiQCfRtVUesvt02pCotsrCRVDsMw0
kxUAnjACf9VeBXc4IJJk8tqr0D/4XPHz
=OQ0I
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: defaulting to net.ipv6.bindv6only=1 for squeeze

[Marcus Better]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Marco d'Itri wrote:
> On Oct 24, Marco d'Itri  wrote:
>> I am proposing to set net.ipv6.bindv6only=1 by default for new
>> installations
> Done, let's see what breaks. :-)

All of Java, it seems [1]. I'm very surprised this breakage was known in 
advance [2] but no bugs were filed (TTBOMK) before making this change.

Hoping it can be fixed quickly.

Cheers,

Marcus

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560056
[2] http://lists.debian.org/debian-devel/2009/10/msg00573.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAksfkwsACgkQXjXn6TzcAQnXCgCgv9Xfp/lolYlCiHtdKPAd5EbQ
RVcAoMc3QmI/7BckQzkWjn3UbLn2lAAG
=J5Kj
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#420165: ITP: commons-configuration -- Java based library providing a generic configuration interface

[Marcus Better]

Torsten Werner wrote:
> I call the binary package
> libcommons-configuration-java but not the source package.

This is one of the two conventions used by the Java packaging team (and IMHO
the best option), cf. commons-logging and commons-daemon packages. The
other common option is to name both source and binary packages
libsomething-java.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

RFA: tikiwiki -- groupware and content management system

[Marcus Better]

retitle 370592 RFA: tikiwiki -- groupware and content management system
thanks

I am looking for someone to take over maintenance of Tikiwiki.

The package works nicely and does not take much time to maintain. However I 
don't use it anymore, and also I'm a bit frustrated with the lack of progress 
upstream on the a long-standing RC bug, a licensing issue [3] related to 
non-free icons. (Upstream has expressed intention to replace those icons with 
free ones.)

The package has had a string of security issues [1], and security fixes were 
not always coordinated with packagers in a timely manner.

There is an Alioth project [2] and a mailing list for coordinating the 
packaging, but nobody has been willing to work on it much.

Unless someone steps forward to maintain it, I am going to shut down the 
Alioth project and possibly request removal of the package from the archive 
due to the unresolved licensing issue.

Marcus

[1] 
http://packages.debian.org/changelogs/pool/main/t/tikiwiki/tikiwiki_1.9.7+dfsg-1/changelog
[2] https://alioth.debian.org/projects/pkg-tikiwiki/
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=377943


smime.p7s
Description: S/MIME cryptographic signature

Re: krb5 transition: upgrading to krb5 1.6.1

[Marcus Better]

Russ Allbery wrote:
> Correct.  In general, you never want to have Kerberos keys in your KDC for
> a service principal for enctypes that that service doesn't support.

Is there an easy way to find out which enctypes a service supports? (And why
does the poor admin have to worry about this at all?)

Marcus



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Building packages twice in a row

[Marcus Better]

Norbert Preining wrote:
> Now at a second build time we have changes in the binary .gmo files
> which cannot be represented.
> 
> What is the preferred solution for such a case?

I usually save upstream's generated files somewhere in debian/rules during
build, and copy them back in the clean target. It's cumbersome but it
works. Sometimes it's easier to convince the tools to put output in some
other place and not stomp over the upstream generated files.

Marcus



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again

[Marcus Better]

Magnus Holmgren wrote:
> Now, how do you combine these? Several people have thought: "The VCS
> can handle the changesets. Putting patches under VCS is silly!"

I fully agree. Unfortunately Subversion doesn't make it easy for you. You
can keep your "patches" in different "feature branches", but it gets messy
since Subversion doens't keep track of merges.

> However, he can read debian/copyright and
> debian/README.Debian to find out where the maintainer keeps his
> repository,

Or check the PTS, if you use XS-Vcs-* control fields.

> I my dreams you can tag individual commits and the VCS lets you extract
> separate patches,

Have you looked at stgit?

Marcus



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again

[Marcus Better]

Frank Küster wrote:
>> "The VCS can handle the changesets. Putting patches under VCS is silly!" 

> I don't agree.  With patches in debian/patches, you can give names to 
> those files.

With a VCS you can also name branches, or changesets (stgit).

Marcus



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again

[Marcus Better]

Magnus Holmgren wrote:
> I have now. IIUC, it lets you group and name diffs vs. a particular state
> of the source code, but the end result is a normal .diff.gz, meaning that
> everyone else has to use stgit too to get all the benefits, right?

Yes. People working on the same project team should use the same tools
anyway. For external people, such as when sending patches upstream, it is
trivial to extract patches.

It wouldn't be difficult to hack up a web frontend that presents the patches
in a nice way. Don't know if it exist already.

Marcus



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again

[Marcus Better]

Frank Küster wrote:
> Personally, I don't like branches very much.  Nobody ever explained to
> me a good receipe to handle them in the case where development proceeds
> in both, and important fixes are copied from one to the other.

I believe git handles that, it should work nicely in most cases.

Marcus



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Group maintainance howto and role of uploaders

[Marcus Better]

Andreas Tille wrote:
> Another question would be whether it would be reasonable if
> Uploaders should be included in BTS mail in any case

I think so, see #397761.

Marcus



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Group maintainance howto and role of uploaders

[Marcus Better]

Andreas Metzler wrote:
>> I think so, see #397761.

> I do not think so, since this would result in duplicat mail for all
> packages with maintainer=mailinglist.

That's a minor problem that is very easily solved with a filter rule in the
MUA. Duplicates are not exactly rare, what with messages that are
cross-posted etc...

(Some people read mailing lists through Gmane or some other method, so they
don't even need to receive list mail directly.)

Marcus



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ITP: pysycache-- Educational game to teach children to move the mouse

[Marcus Better]

José L. Redrejo wrote:
> The activities make children practice on clicking, double-clicking, drag
> and drop, moving and identify the mouse buttons.

Since children probably learn this by age five or so with or without help,
perhaps the author should focus on making a similar tool for adults
instead. :-)

Marcus



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#428877: ITP: callweaver -- Community-driven open source PBX software

[Marcus Better]

Santiago Ruano Rincón wrote:
> CallWeaver is a community-driven vendor-independent cross-platform open
> source PBX software project (formerly known as OpenPBX.org). It was
> originally derived from Asterisk. Now it supports analog and digital
> PSTN telephony, multi-protocol voice over IP telephony, fax,

It would be helpful to know how it differs from Asterisk, since Asterisk too
supports many of the features you list.

Marcus



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Proposed new release goal: Dependency/file list predictability

[Marcus Better]

Matthew Johnson wrote:
> Also, you should consider build systems which switch using the
> alternatives system. Debian Java policy says that debian/rules must
> specify the build system to use explicitly, but there are a number of
> packages which don't.

If you know of any such packages, please file bug reports. That should
really be fixed.

Marcus



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#494928: ITP: sflphone -- SIP and IAX2 compatible VoIP phone

[Marcus Better]

Francois Marier wrote:
> SFLphone is a SIP/IAX2 compatible softphone for Linux. The SFLphone
> project's goal is to create a robust enterprise-class desktop phone.

And how close is it to realising this goal? Because Debian has plenty of crappy 
SIP and IAX softphones that work half of the time in half of the scenarios. 
(Ekiga, Twinkle, WengoPhone, kphone, linphone...), so adding another one is 
probably only useful if it is significantly better.

Cheers,

Marcus



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#446656: ITP: libjbosscache1-java -- cache frequently accessed Java objects

[Marcus Better]

Torsten Werner wrote:
> * Package name: libjbosscache1-java

Are you aware of #386108 and the rest of the JBoss effort?

Regards,

Marcus



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: FOP: Objects for Formatting Objects ?

[Marcus Better]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Nikita V. Youshchenko wrote:
>> 
>> 

> Perhaps that is because of technical, not legal, issues?

More likely because Donald Knuth does not want the behaviour of TeX to 
change.

Marcus
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAktgHfAACgkQXjXn6TzcAQlLOwCg1k8LWaOVqOOL9RZg23NgceTN
RygAn1HebdmCSJIv59z/1IkZbJGFX2C+
=4eDS
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#575953: ITP: gmock -- Google's framework for writing and using C++ mock classes

[Marcus Better]

Fredrik Hallenberg wrote:
> * Package name: gmock

>   Description : Google's framework for writing and using C++ mock
>   classes

This is a bad choice of package name, since gmock is also the name of a 
Groovy-based mocking framework:

  http://code.google.com/p/gmock/

Cheers,

Marcus



-- 
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/hp8sqv$2c...@dough.gmane.org

Bug#579121: RFP: guice -- lightweight dependency injection framework for Java

[Marcus Better]

Package: wnpp
Severity: wishlist

* Package name: guice
  Version : 2.0
  Upstream Author : Google, Inc.
* URL or Web page : http://code.google.com/p/google-guice/
* License : Apache License 2.0
  Description : lightweight dependency injection framework for Java

Needed as dependency for TestNG 5.12.



-- 
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/20100425134311.9dfd7f...@better.bindows.net

Bug#581488: general: lower vm.swappiness by default for desktop installations

[Marcus Better]

Package: general
Severity: wishlist

I have been plagued by long delays with an unresponsive laptop,
waiting for it to swap in Eclipse for several minutes at a time,
several times per day. This is a Thinkpad T61 with 4 GB of RAM,
squeeze/sid, X.org, KDE and Eclipse. (4 GB ought to be enough for
everyone, right?)

Recently I got the advice [1] to set vm.swappiness to 0, rather than
the default 60. This improved things dramatically. Apparently Eclipse
is no longer being swapped out preemptively all the time. The
difference in perceived responsiveness is spectacular.

Shouldn't we provide a lower swappiness by default for desktop
installs, at least those with a fair amount of RAM? This could improve
the user experience on most modern desktop systems. Most users will
probably never find out to tune this on their own. Ubuntu recommends a
value of 10 for desktop systems [2, 3] (but ship with the default
value).

I realise that I don't have any solid evidence that this is a good
move, maybe others can fill in with their experience. The goal here is
to improve desktop responsiveness when multi-tasking, especially on
machines with reasonably large RAM and one or more large applications.

[1] http://lists.debian.org/debian-kde/2010/05/msg00313.html
[2] 
[3] http://brainstorm.ubuntu.com/idea/5481/

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.33.2-melech (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
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/20100512192226.234eaf...@better.bindows.net

Re: cryptdisks(-early) initscripts, dependencies and loops

[Marcus Better]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

Jonas Meurer wrote:
> the problem is that loads of possible setups are possible, all
> introducing different required initscript order. either another
> initscript needs to be invoked before, or after, or between the
> cryptdisks-early and cryptdisks initscripts.

What we have here is a dependency tree of arbitrary height, with each node 
requiring an invocation of cryptsetup, lvm, mdadm, nbd or pretty much 
anything else. So it's clear that you can never cover all possibilites with 
a finite number of init scripts that run in a sequence.

An event-based system might be able handle this, but only if it allows the 
same script to be invoked multiple times, taking different actions each 
time.

Perhaps we need a little script that walks the dependency tree, and just 
calls the necessary helper script for each node in turn.

Cheers,

Marcus
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkwItRYACgkQXjXn6TzcAQnjoACbBXIU2d8ZJ/VeXj/5p+M1t8Uy
hLIAnRzCMC587mrKfRvmLwwepe6hL6zq
=P0c4
-END PGP SIGNATURE-



-- 
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/huaceo$h6...@dough.gmane.org

Re: cryptdisks(-early) initscripts, dependencies and loops

[Marcus Better]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

C. Gatzemeier wrote:
> The defined order in /etc/init/cryptdisks-udev.conf is simply "start on
> block-device-added ID_FS_USAGE=crypto".

Good, how does the next step work? For example, after cryptsetup ran, we 
found an LVM volume and must now run lvm.

Cheers,

Marcus
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkwI+t0ACgkQXjXn6TzcAQlwZgCgvVmZzEx6+wRUdv3WR4b3nO7X
MYEAoKzkmLhF7Hti5g6fOPHWi/9N2ioc
=iTKE
-END PGP SIGNATURE-



-- 
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/huatsv$d7...@dough.gmane.org

Re: all twitter client should support OAuth before they will drop Basic Auth in August

[Marcus Better]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Sune Vuorela wrote:
> plasma-widgets-addons (microblog widget)

OAuth support added upstream:

https://bugs.kde.org/show_bug.cgi?id=242048

Cheers,

Marcus
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkwqP1sACgkQXjXn6TzcAQn11QCgkJHNUDvLEmZ0AXtCwvD9OePD
ySsAoPmR170pgBG7FHT6OLAqjRfO0+fr
=Otmz
-END PGP SIGNATURE-



-- 
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/i0df12$u0...@dough.gmane.org

Bug#514757: ITP: ivy -- dependency manager

[Marcus Better]

Package: wnpp
Owner: Marcus Better 
Severity: wishlist

* Package name: ivy
  Version : 2.0.0
  Upstream Author : Xavier Hanin  Maarten Coene, Nicolas Lalevee, Gilles Scokart
* URL or Web page : http://ant.apache.org
* License : Apache License v2.0
  Description : agile dependency manager

Ivy is a powerful tool for managing dependencies in software
projects. Its main characteristics are flexibility, configurability
and tight integration with Apache Ant.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#516488: RFH: kernel-patch-exec-shield -- protection against stack smashing and other attacks

[Marcus Better]

Package: wnpp
Severity: normal

This kernel patch provides exec-shield, a security feature for the
Linux kernel on i386 (it is not relevant for x86_64). The patch is
present in Fedora kernels, which is also the upstream maintainer.

Since I hardly use i386 machines anymore, I need help with any of the
following:

  * Co-maintaining the package
  * Testing patches for new versions of the Debian kernel

The package is maintained in the collab-maint svn repository.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#519003: ITP: xca -- x509 Certification Authority management tool based on QT4

[Marcus Better]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Tino Keitel wrote:

> * Package name: xca
>   Description : x509 Certification Authority management tool based on
>   QT4

Is there anything significant that distinguishes this from TinyCA?

Cheers,

Marcus

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkm1h5cACgkQXjXn6TzcAQmvjwCfXYKtIRBgccuS2MAwH5Hn44kM
BkYAoJ669C/cQYFoN74PrP0yN0o8t3MZ
=bY3K
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#519118: ITP: libcommons-java-java -- common java library used to support other developments

[Marcus Better]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

gregor herrmann wrote:
> * Package name: libcommons-java-java
>   Version : 1.5.5
>   Upstream Author : TiongHiang Lee
> * URL : http://onemind-commons.sourceforge.net/commons-java/

The libcommons-foo-java package names usually refer to Apache Commons. I 
think it could be confusing to use the same naming convention for other 
packages unrelated to Apache. How about "onemind-commons-foo" for the source 
package and "libonemind-commons-foo-java" for the binary?

Cheers,

Marcus

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkm2otkACgkQXjXn6TzcAQlb9wCdHrpiykiGhKXzhW40qDPNmpg5
+XMAn24I3QYIdtBTsgynMCRsTAildMvU
=zmhE
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#522914: ITP: agda -- a dependently typed functional programming language and proof assistant

[Marcus Better]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Iain Lane wrote:
> Swedish logician Per Martin-Lf.

That's Per Martin-Löf.

Cheers,

Marcus

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAknoiiwACgkQXjXn6TzcAQkTtwCaAl4DbHwHVUHwqcXC9pFf1YWW
/zUAnR1n3HM8abbxGXEJHShGf1LUhq4I
=ByEd
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#528061: ITP: obexd -- OBEX client and server

[Marcus Better]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hendrik Sattler wrote:
> And upcoming kdebluetooth4 uses solid

BTW, is anyone working on that? (The RFP is #491580.)

Cheers,

Marcus
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoKeO0ACgkQXjXn6TzcAQmRXACg3Ux8I0eqWKhee/VzD+839+SE
0gsAoOjSlBMIx3QQDoHZppkHvH2l6Swv
=+wS/
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org