Re: Automated mails to maintainers of packages with serious problems

[Colin Tuckley]

Lucas Nussbaum wrote:

> You will receive a mail:
> * if one of your packages has RC bugs older than 30 days in unstable

You need to check the "new" queue for an upload before sending a mail in
this case. It ought not to be really necessary, but stuff gets stuck in new
for quite a while sometimes.

regards,

Colin

-- 
Colin Tuckley  |  [EMAIL PROTECTED]  |  PGP/GnuPG Key Id
+44(0)1903 236872  |  +44(0)7799 143369  | 0x1B3045CE

"My mind free-associates far too much; I'm going to have to start charging it."


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

Re: Automated mails to maintainers of packages with serious problems

[Raphael Hertzog]

On Fri, 22 Jun 2007, Colin Tuckley wrote:
> Lucas Nussbaum wrote:
> 
> > You will receive a mail:
> > * if one of your packages has RC bugs older than 30 days in unstable
> 
> You need to check the "new" queue for an upload before sending a mail in
> this case. It ought not to be really necessary, but stuff gets stuck in new
> for quite a while sometimes.

No, you should tag your bugs pending and Lucas ought to ignore pending
bugs (maybe he already does).

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

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

[Matthew Johnson]

> As discussed during DebConf, I'd like to propose a new release goal:
> Packages should not only build in clean chroots, but also in non-clean
> environments.  Specifically, adding extra packages from the archive
> into the build environment (that are not in Build-Conflicts) should
> not affect the resulting package in any noticeable way.

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. These will build if only their build-depends are
installed or if their build system is the current alternative, but not
if they were installed in a different order.

Matt

--
Matthew Johnson


signature.asc
Description: Digital signature

Re: Automated mails to maintainers of packages with serious problems

[Frank Küster]

Raphael Hertzog <[EMAIL PROTECTED]> wrote:

> On Fri, 22 Jun 2007, Colin Tuckley wrote:
>> Lucas Nussbaum wrote:
>> 
>> > You will receive a mail:
>> > * if one of your packages has RC bugs older than 30 days in unstable
>> 
>> You need to check the "new" queue for an upload before sending a mail in
>> this case. It ought not to be really necessary, but stuff gets stuck in new
>> for quite a while sometimes.
>
> No, you should tag your bugs pending and Lucas ought to ignore pending
> bugs (maybe he already does).

Hm, but there a couple of bugs tagged "pending" which don't get an
upload for months.  Even RC ones, as I remember from the etch release
cycle.  And the kind of maintainer who does these things is the ideal
target for these e-mails...

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

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

[Lucas Nussbaum]

On 22/06/07 at 01:49 +0200, Steinar H. Gunderson wrote:
> As discussed during DebConf, I'd like to propose a new release goal: Packages
> should not only build in clean chroots, but also in non-clean environments.
> Specifically, adding extra packages from the archive into the build
> environment (that are not in Build-Conflicts) should not affect the resulting
> package in any noticeable way.
> 
> To this end, I've set up the "build daemon from Hell" (BDFH) on my machine,
> currently doing script testing. (Joey Hess has kindly promised to donate CPU
> time on a four-CPU machine so we can push through the entire archive at
> reasonable speeds at regular intervals; the setup will be moved there as soon
> as it's stable.) The idea is to build a package both in a pbuilder and in
> a really filled chroot -- it currently contains 18GB of packages, which is
> most of the "devel" and "libdevel" sections. What is compared is:
> 
>  - The list of Depends.
>  - The list of Recommends.
>  - The list of filenames.

I really like the idea.

However, with this setup, you only check that building packages in
non-clean environments doesn't significantly affect the package. It
would be interesting to check as well if the resulting package matches
what is in the archive, to some point. Obviously, packages can't match
perfectly:

- binaries should depend on the same package, but could depend on different
  versions (even if Raphael's work will probably mitigate this)
- some files will differ, because of:
  + date/time information
  + newer compiler versions causing better optimization
  + ...

In january, I worked on a script that compares two build results (both sources
and binaries packages), and compared the content of the archive with the result
of one of my rebuilds. The differences were quite huge. Some examples (back
from January of course):

acepack:
 r-cran-acepack's depends differ:
  -Depends: libc6 , libg2c0 , libgcc1 , r-base-core 
  +Depends: libc6 , libgcc1 , libgfortran1 , r-base-core

alamin:
 alamin-client's postinst differs:
 if [ -x "/etc/init.d/alamin-server" ]; then
update-rc.d alamin-server defaults >/dev/null
if [ -x "`which invoke-rc.d 2>/dev/null`" ]; then
-   invoke-rc.d alamin-server start || exit 0
+   invoke-rc.d alamin-server start || exit $?
else
-   /etc/init.d/alamin-server start || exit 0
+   /etc/init.d/alamin-server start || exit $?
fi
 fi

ada-mode:
 files list differ:
-./usr/share/doc/ada-mode/html/Using-non-standard-file-names.html
+./usr/share/doc/ada-mode/html/Using-non_002dstandard-file-names.html

af:
 files list differ:
-./usr/lib/menu
-./usr/lib/menu/af
+./usr/share/menu
+./usr/share/menu/af

etc. (you get the idea)

So, I'd like to extend this release goal to something like "binary packages
predictability (to some extend)". This would mostly result in a lot of binNMUs
to update the binary packages to the current state of unstable, so in most
cases, it shouldn't put a lot of load on maintainers.
The number of issues is unknown ; it depends on how close we want packages
to match.

Do you think it's a good idea?

Steinar, do you want to merge your release goal with that one, or do you prefer
me to file a seperate release goal? The main reason why I think they should be
merged is that the way to detect issues is similar.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


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

Re: Archive rebuild with improved dpkg-shlibdeps

[Raphael Hertzog]

On Thu, 21 Jun 2007, Peter Samuelson wrote:
> 
> [Raphael Hertzog]
> > If you encounter any strangeness, please report it so that we can
> > check.  Those warnings could be the base of some mass-bug filings
> > althought we might want to start with the second one (those are real
> > bugs, while the other are not creating any technical problem (except
> > useless dependencies)).
> 
> Please do not file bugs for unnecessary linking _except_ where this
> actually changes the Depends line.  In many cases upstream might link
> several binaries against a fixed list of libraries, where not every
> binary needs every library.  This is generally quite annoying to "fix",
> and is not worth the trouble, since it doesn't affect package
> relationships or install/remove/upgrade scenarios.

Ack. I should add a similar warning at the package level instead of at the
binary level.

> Also, please omit @Base from the log messages, it adds visual clutter
> without adding information.

Well, it can be worthwhile to know which version the symbol is attached
to. If I remove it, I only remove @Base and not @GLIBC_2.4 or any other
versions.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

Re: Automated mails to maintainers of packages with serious problems

[Lucas Nussbaum]

On 22/06/07 at 11:27 +0200, Frank Küster wrote:
> Raphael Hertzog <[EMAIL PROTECTED]> wrote:
> 
> > On Fri, 22 Jun 2007, Colin Tuckley wrote:
> >> Lucas Nussbaum wrote:
> >> 
> >> > You will receive a mail:
> >> > * if one of your packages has RC bugs older than 30 days in unstable
> >> 
> >> You need to check the "new" queue for an upload before sending a mail in
> >> this case. It ought not to be really necessary, but stuff gets stuck in new
> >> for quite a while sometimes.
> >
> > No, you should tag your bugs pending and Lucas ought to ignore pending
> > bugs (maybe he already does).
> 
> Hm, but there a couple of bugs tagged "pending" which don't get an
> upload for months.  Even RC ones, as I remember from the etch release
> cycle.  And the kind of maintainer who does these things is the ideal
> target for these e-mails...

Hi,

Checking for packages in NEW looks complex: I would have to look at the
changes file to see if the bugs I'm going to mail about are actually
being closed. And I can't extrapolate whether the upload will be able to
migrate to testing eventually.

So I think that I'll just ignore NEW for now. But if I get many replies
about that, I will reconsider that of course.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


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

Re: Using standardized SI prefixes

[Russell Coker]

On Friday 22 June 2007 07:29, Ivan Jager <[EMAIL PROTECTED]> wrote:
> > CD-ROMs have 2304 byte raw sectors.
>
> 2048 + 256 for ECC, both of which are powers of two. Even if you use the
> 2304 raw bytes, that is a multiple of 2^8 bytes, and not even divisible by
> 10^1.

Powers of 2 are everywhere.  I have 8+2 toes, both of which are powers of two.  
How did humans even start counting in base 10 when it's obvious that there 
are 8+2 digits to count with (and that's both powers of 2).  :-#

-- 
[EMAIL PROTECTED]
http://etbe.coker.com.au/  My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development


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

Re: Automated mails to maintainers of packages with serious problems

[Andreas Barth]

* Russ Allbery ([EMAIL PROTECTED]) [070622 11:55]:
> Mike Hommey <[EMAIL PROTECTED]> writes:
> 
> > Now the BTS supports versioning, couldn't dak just close the bugs when a
> > package gets uploaded, whether it ends up in NEW or incoming ?
> 
> Weird things would happen if the package was rejected from NEW and then
> reuploaded with the same version number but with a different set of bugs
> closed.

The only way to allow bugs being closed if the package appears in NEW is
that we track that versions, and never allow upload of another package
with the same version number.


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


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

Re: Automated mails to maintainers of packages with serious problems

[fourmond]

On Fri, Jun 22, 2007 at 11:41:22AM +0200, Lucas Nussbaum wrote:
> Checking for packages in NEW looks complex: I would have to look at the
> changes file to see if the bugs I'm going to mail about are actually
> being closed. 

  You actually just need to parse

http://ftp-master.debian.org/new.html

  It should be fairly trivial, and you don't need to give a look at changes 
files.

  Regards,

Vincent Fourmond

PS: very good idea, I say !


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

Re: Automated mails to maintainers of packages with serious problems

[Lucas Nussbaum]

On 22/06/07 at 00:36 +0200, Nico Golde wrote:
> Hi,
> * Lucas Nussbaum <[EMAIL PROTECTED]> [2007-06-22 00:17]:
> > During my talk today at debconf, I discussed the idea of sending mails
> > to maintainers of packages with serious problems. The audience
> > welcomed the idea, so I will send the first mails soon.
> 
> That sounds good to me!
> 
> > You will receive a mail:
> > * if one of your packages has RC bugs older than 30 days in unstable
> [...] 
> > I plan to send such mails on a monthly basis. Depending on how well it
> > is received, the criterias will be enlarged to include more packages,
> > while staying reasonable.
> [...] 
> > You will only receive one mail (per e-mail address), listing the
> > problems in all your packages, not one mail per package. If all your
> > packages are OK (according to the criterias above), you won't receive
> > anything.
> 
> I propose to change this a bit for RC bugs. Assume you get a 
> mail on 2nd of a month and get an RC bug on the 3rd day.
> Then you get the mail for the RC bug nearly after 2 months 
> since it is not 30 days old on the 2nd of next month.

I don't think this is avoidable. I have to draw the line somewhere, and
someone could make the point that if I send mails on the 1st, and a bug
is reported on the 10th, one will have to wait until the bug is 50 days
old to receive a mail.

Those mails are not supposed to supposed to replace the BTS mails,
anyway! :-)

> But the service seems to be a great service for maintainers 
> in my opinion.

Thank you:)
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


signature.asc
Description: Digital signature

Re: Automated mails to maintainers of packages with serious problems

[Russ Allbery]

Mike Hommey <[EMAIL PROTECTED]> writes:

> Now the BTS supports versioning, couldn't dak just close the bugs when a
> package gets uploaded, whether it ends up in NEW or incoming ?

Weird things would happen if the package was rejected from NEW and then
reuploaded with the same version number but with a different set of bugs
closed.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Bug#430086: ITP: libscope-guard-perl -- lexically scoped resource management

[Krzysztof Krzyzaniak (eloy)]

Package: wnpp
Severity: wishlist
Owner: "Krzysztof Krzyzaniak (eloy)" <[EMAIL PROTECTED]>


* Package name: libscope-guard-perl
  Version : 0.03
  Upstream Author : chocolateboy, <[EMAIL PROTECTED]>
* URL : http://www.cpan.org/
* License : Perl: Artistic/GPL
  Programming Lang: Perl
  Description : lexically scoped resource management

 Scope::Guear provides a convenient way to perform cleanup or other forms of 
 resource management at the end of a scope. It is particularly useful when 
 dealing with exceptions.
 The Scope::Guard constructor takes a reference to a subroutine that is 
 guaranteed to be called even if the thread of execution is aborted 
prematurely. 
 This effectively allows lexically-scoped "promises" to be made that are 
 automatically honoured by perl's garbage collector.
 .
 For more information, see: 
 http://www.cuj.com/documents/s=8000/cujcexp1812alexandr/

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.18-4-686 (SMP w/1 CPU core)
Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2)
Shell: /bin/sh linked to /bin/bash


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

Re: Automated mails to maintainers of packages with serious problems

[Mike Hommey]

On Fri, Jun 22, 2007 at 11:41:22AM +0200, Lucas Nussbaum <[EMAIL PROTECTED]> 
wrote:
> Hi,
> 
> Checking for packages in NEW looks complex: I would have to look at the
> changes file to see if the bugs I'm going to mail about are actually
> being closed. And I can't extrapolate whether the upload will be able to
> migrate to testing eventually.
> 
> So I think that I'll just ignore NEW for now. But if I get many replies
> about that, I will reconsider that of course.

Now the BTS supports versioning, couldn't dak just close the bugs when a
package gets uploaded, whether it ends up in NEW or incoming ?

Obviously, the BTS wouldn't show the bug closed for the unstable distribution
until the package gets out of NEW...

Mike


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

Re: Automated mails to maintainers of packages with serious problems

[Frank Küster]

Lucas Nussbaum <[EMAIL PROTECTED]> wrote:

> On 22/06/07 at 11:27 +0200, Frank Küster wrote:
>> Raphael Hertzog <[EMAIL PROTECTED]> wrote:
>> 
>> > On Fri, 22 Jun 2007, Colin Tuckley wrote:
>> >> Lucas Nussbaum wrote:
>> >> 
>> >> > You will receive a mail:
>> >> > * if one of your packages has RC bugs older than 30 days in unstable
>> >> 
>> >> You need to check the "new" queue for an upload before sending a mail in
>> >> this case. It ought not to be really necessary, but stuff gets stuck in 
>> >> new
>> >> for quite a while sometimes.
>> >
>> > No, you should tag your bugs pending and Lucas ought to ignore pending
>> > bugs (maybe he already does).
>> 
>> Hm, but there a couple of bugs tagged "pending" which don't get an
>> upload for months.  Even RC ones, as I remember from the etch release
>> cycle.  And the kind of maintainer who does these things is the ideal
>> target for these e-mails...
[...]
> So I think that I'll just ignore NEW for now. But if I get many replies
> about that, I will reconsider that of course.

As long as you don't treat "pending" as a reason for not sending the
mail, I'm fine with that.

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: Automated mails to maintainers of packages with serious problems

[Frans Pop]

On Friday 22 June 2007 00:15, Lucas Nussbaum wrote:
> During my talk today at debconf, I discussed the idea of sending mails
> to maintainers of packages with serious problems. The audience
> welcomed the idea, so I will send the first mails soon.

Please include at least the packages the bugs affect and the titles of the 
BRs in the mails. Without that the mails are basically contentless IMO.

Also nice would be links to the BTS.

Cheers,
FJP


pgpb2tl8vZhHu.pgp
Description: PGP signature

Re: Automated mails to maintainers of packages with serious problems

[Pierre Habouzit]

On Fri, Jun 22, 2007 at 02:55:14AM -0700, Russ Allbery wrote:
> Mike Hommey <[EMAIL PROTECTED]> writes:
> 
> > Now the BTS supports versioning, couldn't dak just close the bugs when a
> > package gets uploaded, whether it ends up in NEW or incoming ?
> 
> Weird things would happen if the package was rejected from NEW and then
> reuploaded with the same version number but with a different set of bugs
> closed.

  alternatively, REJECT scripts can be updated to reopen bugs they
closed in that case.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpup51xn435s.pgp
Description: PGP signature

BTS is taking a lot of time to process emails recently

[Touko Korpela]

Emails to control server address take a lot of time to
process. This started some days ago. Temporarily it worked fast but again it
has problems. Is it spam detection or some other cause?
I noticed that it uses SpamAssassin version 2.60 that is old. New versions
(3.2.0+) support sa-compile to speed up processing.


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

Re: Automated mails to maintainers of packages with serious problems

[Lucas Nussbaum]

On 22/06/07 at 13:51 +0200, Frans Pop wrote:
> On Friday 22 June 2007 00:15, Lucas Nussbaum wrote:
> > During my talk today at debconf, I discussed the idea of sending mails
> > to maintainers of packages with serious problems. The audience
> > welcomed the idea, so I will send the first mails soon.
> 
> Please include at least the packages

You mean the binary packages, right?

> the bugs affect and the titles of the 
> BRs in the mails. Without that the mails are basically contentless IMO.

I'll improve that before the next run.

> Also nice would be links to the BTS.

Well, links in text emails use a lot of space...
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |

Re: BTS is taking a lot of time to process emails recently

[Don Armstrong]

On Fri, 22 Jun 2007, Touko Korpela wrote:
> Emails to control server address take a lot of time to
> process. This started some days ago.

A few days ago I was running the archive scripts,[1] which took about
36 hours to complete the backlog, with interruptions every 2 or so
hours to allow messages which had queued to get processed. [Expiration
takes out locks which block all but the most trivial modifications.]

At thex time being, the BTS is processing messages every 3 minutes
again, so in most cases (when the BTS isn't being DoSed by spam) your
messages should be processed within minutes.


Don Armstrong

1: http://lists.debian.org/debian-devel-announce/2007/06/msg4.html
-- 
Never underestimate the power of human stupidity. 
 -- Robert Heinlein

http://www.donarmstrong.com  http://rzlab.ucr.edu


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

Re: Automated mails to maintainers of packages with serious problems

[Reinhard Tartler]

Frank Küster <[EMAIL PROTECTED]> writes:

>> No, you should tag your bugs pending and Lucas ought to ignore pending
>> bugs (maybe he already does).

> Raphael Hertzog <[EMAIL PROTECTED]> wrote:

> Hm, but there a couple of bugs tagged "pending" which don't get an
> upload for months.  Even RC ones, as I remember from the etch release
> cycle.  And the kind of maintainer who does these things is the ideal
> target for these e-mails...

Which is a problem on its own, for which we should find a way to deal
with independently to what's currently discussed in this thread...

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


pgpCrUERGLcQ9.pgp
Description: PGP signature

Re: Automated mails to maintainers of packages with serious problems

[Frans Pop]

On Friday 22 June 2007 15:54, Lucas Nussbaum wrote:
> > Please include at least the packages
>
> You mean the binary packages, right?

Or source if a BR is filed against a source package.

> > Also nice would be links to the BTS.
>
> Well, links in text emails use a lot of space...

It should be possible to add references and add the links at the bottom of 
the mail.


pgpPlFTWpXKjN.pgp
Description: PGP signature

Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator

[Russ Allbery]

Package: wnpp
Severity: wishlist
Owner: Russ Allbery <[EMAIL PROTECTED]>

* Package name: hoard
  Version : 3.6.2
  Upstream Author : Emery Berger <[EMAIL PROTECTED]>
* URL : http://www.hoard.org/
* License : GPL (with some docs under Apache 2.0)
  Programming Lang: C++
  Description : Fast, scalable, and efficient replacement memory allocator

Hoard is a replacement memory allocator that can be used instead of glibc
malloc without recompiling binaries.  It is faster and more efficient
under many load patterns than the default glibc malloc, and is particularly
good for multithreaded programs running on multiple processors.

I'm primarily packaging Hoard for use with OpenLDAP, where it increases
performance significantly over the default glibc allocator.

There are some papers included in the upstream source package under
non-free licenses which will be removed in the Debian package.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.18-4-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash


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

Re: transition of packages into testing

[Kurt Roeckx]

On Thu, Jun 21, 2007 at 11:29:32PM +0300, Lars Wirzenius wrote:
> 
> Another criterion is that it's built on all the architectures the
> previous version in testing is built on. It seems it's missing builds on
  ^^^

That should be unstable.

Anyway, the list of reasons why it doesn't migrate is at:
http://www.debian.org/devel/testing


Kurt


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

[EMAIL PROTECTED] Package

[Zachary Palmer]

Hello, all.  It has been my understanding that the reason that the 
[EMAIL PROTECTED] distributed computing software has not been made a Debian 
package is that the license under which it is released does not allow it 
to be free.  This software package has pretty much the best reason for 
being closed source that I've encountered; they want to prevent 
falsified results from damaging the research.


Of course, I understand that this means that we can't package up the 
[EMAIL PROTECTED] binary.  But if I put together a Debian package that would 
use the preinst script to go fetch the software from Stanford in a way 
similar to how the flashplugin-nonfree package fetches Macrodobe Flash 
9, would there be any interest?  I'd really enjoy a quick, low-hassle 
way to fetch and install [EMAIL PROTECTED] on my various computers as a 
service.  I see that there is a KDE applet, kfolding, that will handle 
[EMAIL PROTECTED], but it is dependent upon the existence of a KDE session 
(or at least a base KDE installation) and I'd like to install the 
software on my server as well as avoid messing with it if I somehow 
crash my GUI session.


So, in summary, is there anything I should know before I set out on this 
task?  And will people use it if I bother?


Thanks!

Zachary Palmer


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

I don't understand Debian

[ignatius]

I have two questions that really concerned me.

- Why it's Debian that fixes bugs and security holes? Why it isn't 
upstream developers? How can you be sure that all security holes will be 
found or revealed? (for instance an old software in stable can have a 
security issue which is not in the recent version, so upstream can't 
find it) Why upstream developers of important softwares do not sometimes 
provide stable versions of their programs (eg linux kernel, libc, xorg), 
instead of let Debian do the job for them?
I mean, with Windows® (sorry), things are sometimes more logical: the 
kernel, "xserver, xclient", etc. (important apps) are stable for years, 
but you can have the last firefox without update them (like a mix 
stable/unstable, except that stable softwares are maintained by uptream, 
not by a distribution).


- Why Debian isn't KISS (Keep It Simple, Stupid!) compliant? I mean, I 
never need to change my conf files. If I have a problem, I solve with 
apt-get or dpkg-reconfigure. I don't understand how things works and I'm 
too dependent on Debian. Futhermore, .deb are really complicated compare 
with other package tools. I like for instance Frugalware philosophy: "We 
try to ship fresh and stable software, as close to the original source 
as possible, because in our opinion most software is the best as is, and 
doesn't need patching."


Well, I don't like what is Linux today. Software developers don't care 
about stability, are not responsible, whereas each Linux distributions 
re-do the same jobs without cooperate. Linus should do something. It's 
too easy to create a kernel and then let it go alone.


Sorry for my English that is very bad compare to the real Ignatius 
Reilly's English.


ZORRO.

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

[Joey Hess]

Lucas Nussbaum wrote:
> acepack:
>  r-cran-acepack's depends differ:
>   -Depends: libc6 , libg2c0 , libgcc1 , r-base-core 
>   +Depends: libc6 , libgcc1 , libgfortran1 , r-base-core

Caught by the BDFH.

> alamin:
>  alamin-client's postinst differs:
>  if [ -x "/etc/init.d/alamin-server" ]; then
> update-rc.d alamin-server defaults >/dev/null
> if [ -x "`which invoke-rc.d 2>/dev/null`" ]; then
> -   invoke-rc.d alamin-server start || exit 0
> +   invoke-rc.d alamin-server start || exit $?

Newer debhelper.

> ada-mode:
>  files list differ:
> -./usr/share/doc/ada-mode/html/Using-non-standard-file-names.html
> +./usr/share/doc/ada-mode/html/Using-non_002dstandard-file-names.html

WTF?? :-)

> af:
>  files list differ:
> -./usr/lib/menu
> -./usr/lib/menu/af
> +./usr/share/menu
> +./usr/share/menu/af

Non-ancient debhelper.

-- 
see shy jo


signature.asc
Description: Digital signature

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

[Lucas Nussbaum]

On 22/06/07 at 20:08 +0100, Joey Hess wrote:
> Lucas Nussbaum wrote:
> > acepack:
> >  r-cran-acepack's depends differ:
> >   -Depends: libc6 , libg2c0 , libgcc1 , r-base-core 
> >   +Depends: libc6 , libgcc1 , libgfortran1 , r-base-core
> 
> Caught by the BDFH.

Ok, good to know.

> > alamin:
> >  alamin-client's postinst differs:
> >  if [ -x "/etc/init.d/alamin-server" ]; then
> > update-rc.d alamin-server defaults >/dev/null
> > if [ -x "`which invoke-rc.d 2>/dev/null`" ]; then
> > -   invoke-rc.d alamin-server start || exit 0
> > +   invoke-rc.d alamin-server start || exit $?
> 
> Newer debhelper.
> 
> > ada-mode:
> >  files list differ:
> > -./usr/share/doc/ada-mode/html/Using-non-standard-file-names.html
> > +./usr/share/doc/ada-mode/html/Using-non_002dstandard-file-names.html
> 
> WTF?? :-)
> 
> > af:
> >  files list differ:
> > -./usr/lib/menu
> > -./usr/lib/menu/af
> > +./usr/share/menu
> > +./usr/share/menu/af
> 
> Non-ancient debhelper.
 
Still, what do we want to do about those?
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


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

Re: [EMAIL PROTECTED] Package

[Kevin Mark]

On Fri, Jun 22, 2007 at 02:20:33PM -0400, Zachary Palmer wrote:
> Hello, all.  It has been my understanding that the reason that the 
> [EMAIL PROTECTED] distributed computing software has not been made a Debian 
> package is that the license under which it is released does not allow it 
> to be free.  This software package has pretty much the best reason for 
> being closed source that I've encountered; they want to prevent 
> falsified results from damaging the research.

> Of course, I understand that this means that we can't package up the 
> [EMAIL PROTECTED] binary.  

Debian focuses its resources on create DFSG-free software.
Non-dfsg-free software is also produced by DD's and others.

Also, most Debian users like all kinds of software but prefer DFSG
software. In cases where DFSG software is not possible, Debian provides
a non-free repo and some nice person, also a DD, makes
debian-multimedia.org for most of the patent-encumbered files. There are
also places where folks package debs for convienence, that are not in
Debian, like debian-mentors.net and backports.org. So there are a few
places where you can but deb packages for non-dfsg deb files.  


> But if I put together a Debian package that would 
> use the preinst script to go fetch the software from Stanford in a way 
> similar to how the flashplugin-nonfree package fetches Macrodobe Flash 
> 9, would there be any interest?

sure. Although, asking on debian-user would get you a better answer.

>   I'd really enjoy a quick, low-hassle 
> way to fetch and install [EMAIL PROTECTED] on my various computers as a 
> service.  I see that there is a KDE applet, kfolding, that will handle 
> [EMAIL PROTECTED], but it is dependent upon the existence of a KDE session 
> (or at least a base KDE installation) and I'd like to install the 
> software on my server as well as avoid messing with it if I somehow 
> crash my GUI session.
> 

> So, in summary, is there anything I should know before I set out on this 
> task?  And will people use it if I bother?And I'm

I'm sure many folks would like a deb for [EMAIL PROTECTED] wether its a wrapper 
to get
and install it (which may go in main (or contrib?))  or a deb that
contains the actual program packaged to meet Debian's policy guidelines
in non-free. 

-- 
|  .''`.  == Debian GNU/Linux == |   my web site:   |
| : :' :  The  Universal |mysite.verizon.net/kevin.mark/|
| `. `'  Operating System| go to counter.li.org and |
|   `-http://www.debian.org/ |be counted! #238656   |
|  my keyserver: subkeys.pgp.net | my NPO: cfsg.org |
|join the new debian-community.org to help Debian!  |
|___  Unless I ask to be CCd, assume I am subscribed ___|


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

Re: I don't understand Debian

[Kevin Mark]

On Fri, Jun 22, 2007 at 08:24:22PM +0200, ignatius wrote:
> I have two questions that really concerned me.
> 
> - Why it's Debian that fixes bugs and security holes? 

There are lots of differences between:
upstream and Debian release goals
upstream and Debian build environment (debian has 10+ archs vs upstream's
1 -- in most cases)
upstream and Debian package goals
bugs introduced when upstreams package is introduced into Debian's
distro of 16,000+ packages.
Also,
Debian's bug fixes introduces their own bugs (regular and security)
These are true for any distro, not just Debian.
 

> Why it isn't 
> upstream developers? How can you be sure that all security holes will be 
> found or revealed?  
No one can. So we rely on programer skill, user testing, QA testing and
other things to finding and fixing bugs. This is true for all distros
and upstreams.  Thus there is no perfect software. Of course, some folks
hide bugs and close the source, this makes things seem better sometimes.


> (for instance an old software in stable can have a 
> security issue which is not in the recent version, so upstream can't 
> find it) Why upstream developers of important softwares do not sometimes 
> provide stable versions of their programs (eg linux kernel, libc, xorg), 
> instead of let Debian do the job for them?
Debian has security support for a limited time for all its stable
distro. Also, there is the backporting of security fixes. And there are
(still unofficial) backports.org that has newer software made for stable
release.
> I mean, with Windows® (sorry), things are sometimes more logical: the 
> kernel, "xserver, xclient", etc. (important apps) are stable for years, 
> but you can have the last firefox without update them (like a mix 
> stable/unstable, except that stable softwares are maintained by uptream, 
> not by a distribution).
This is currenly done (more or less) by backports.org (or other similar
efforts).
> 
> - Why Debian isn't KISS (Keep It Simple, Stupid!) compliant?

Debian strives for this and may folks seem to think it does it well.  

> I mean, I never need to change my conf files. If I have a problem, I
> solve with apt-get or dpkg-reconfigure. I don't understand how things
> works and I'm too dependent on Debian. Futhermore, .deb are really
> complicated compare with other package tools.
the deb format is derived from the 'ar' packaging tool that is on every
UN*X system. That is not very complicated. Further more, all Debian
related files are conviently in one directory (/debian), so as to easily
differentiate it from the upstream source.

>  I like for instance
> Frugalware philosophy: "We try to ship fresh and stable software, as
> close to the original source as possible, because in our opinion most
> software is the best as is, and doesn't need patching."
That sounds more like Gentoo and its ebuilds. Debian distributes binary
packages.
> 
> Well, I don't like what is Linux today. Software developers don't care 
> about stability, are not responsible, whereas each Linux distributions 
> re-do the same jobs without cooperate. Linus should do something. It's 
> too easy to create a kernel and then let it go alone.
Its true that some areas could use better co-operation and many distros
don't communicated with upstream enough (where possible) to get their
changes upstream (where possible). But we do try.
> 
> Sorry for my English that is very bad compare to the real Ignatius 
> Reilly's English.
Most folks write english well enough to communicate their ideas and most
readers try to compensate for any lacking when they read their ideas.
So I think most folks understood what you wrote.

-- 
|  .''`.  == Debian GNU/Linux == |   my web site:   |
| : :' :  The  Universal |mysite.verizon.net/kevin.mark/|
| `. `'  Operating System| go to counter.li.org and |
|   `-http://www.debian.org/ |be counted! #238656   |
|  my keyserver: subkeys.pgp.net | my NPO: cfsg.org |
|join the new debian-community.org to help Debian!  |
|___  Unless I ask to be CCd, assume I am subscribed ___|

testing with stable of testing

[linux]

Hello all,

I want package software, and if I want to test, do I need stabel of testing to 
test the package?

Regards,
Polopolo


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

Re: [EMAIL PROTECTED] Package

[Luca Brivio]

Alle venerdì 22 giugno 2007, Zachary Palmer ha scritto:
> Hello, all.  It has been my understanding that the reason that the
> [EMAIL PROTECTED] distributed computing software has not been made a Debian
> package is that the license under which it is released does not allow it
> to be free.

No, it's that the license does not allow it to be re-distributed:

> Distribution of this software is prohibited. It may only be obtained by
> downloading from Stanford's web site (http://folding.stanford.edu and pages
> linked therein). 

while often other pieces of software that allow to be distributed (and thereon 
packaged) do enter the non-free section.

> This software package has pretty much the best reason for 
> being closed source that I've encountered; they want to prevent
> falsified results from damaging the research.

Anyway this might likely not be enough for their purpose. :-( Am I wrong, 
right?

BTW, I would encourage them to (co-)maintain an unofficial Debian package with 
that software inside.

> And will people use it if I bother?

Less than 0.02% seems to have kfolding installed [1]. But I think a lot more 
people have (and run) the [EMAIL PROTECTED] client, and even more would do if 
such 
a package were provided.

> Thanks!

Thank you.

[1] source: http://popcon.debian.org/
--
Luca

Re: Archive rebuild with improved dpkg-shlibdeps

[Peter Samuelson]

[Raphael Hertzog]
> > Also, please omit @Base from the log messages, it adds visual clutter
> > without adding information.
> 
> Well, it can be worthwhile to know which version the symbol is attached
> to. If I remove it, I only remove @Base and not @GLIBC_2.4 or any other
> versions.

Yeah, I meant @Base specifically.  Of course it's useful to report on
other symbol versions.
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


signature.asc
Description: Digital signature

Re: I don't understand Debian

[Sam Leon]

ignatius wrote:

I have two questions that really concerned me.

- Why it's Debian that fixes bugs and security holes? Why it isn't 
upstream developers? How can you be sure that all security holes will 
be found or revealed? (for instance an old software in stable can have 
a security issue which is not in the recent version, so upstream can't 
find it) Why upstream developers of important softwares do not 
sometimes provide stable versions of their programs (eg linux kernel, 
libc, xorg), instead of let Debian do the job for them?
I mean, with Windows® (sorry), things are sometimes more logical: the 
kernel, "xserver, xclient", etc. (important apps) are stable for 
years, but you can have the last firefox without update them (like a 
mix stable/unstable, except that stable softwares are maintained by 
uptream, not by a distribution).


- Why Debian isn't KISS (Keep It Simple, Stupid!) compliant? I mean, I 
never need to change my conf files. If I have a problem, I solve with 
apt-get or dpkg-reconfigure. I don't understand how things works and 
I'm too dependent on Debian. Futhermore, .deb are really complicated 
compare with other package tools. I like for instance Frugalware 
philosophy: "We try to ship fresh and stable software, as close to the 
original source as possible, because in our opinion most software is 
the best as is, and doesn't need patching."


Well, I don't like what is Linux today. Software developers don't care 
about stability, are not responsible, whereas each Linux distributions 
re-do the same jobs without cooperate. Linus should do something. It's 
too easy to create a kernel and then let it go alone.


Sorry for my English that is very bad compare to the real Ignatius 
Reilly's English.


ZORRO.


There is nothing wrong with debian and if your are talking about windows 
then you are not even used to the "linux way"


If you want security patches, they are in Stable.  Unstable is updated 
everyday, so who cares?  Testing, err yea, they will get there when they 
are ready.



Sam


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

Re: Bug#429514: ITP: openoffice.org-ctl-he -- Turns on OO.org CTL support, and sets Hebrew as the default CTL locale

[Enrico Zini]

On Mon, Jun 18, 2007 at 03:43:45PM +0100, Lior Kaplan wrote:

>   Description : Turns on CTL support & sets Hebrew as the default CTL 
> locale
> 
> This package installs an OO.org extention which turns on CTL support, and sets
> Hebrew as the default language.
> 
> The user can overright these setting by changning them in the tools -> options
> -> language settings menu.

It sounds like a useful package, but please add to the description an
expansion of the CTL acronym.


Ciao,

Enrico

-- 
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: I don't understand Debian

[Andrew M.A. Cater]

On Fri, Jun 22, 2007 at 08:24:22PM +0200, ignatius wrote:
> I have two questions that really concerned me.
> 
> - Why it's Debian that fixes bugs and security holes? Why it isn't 
> upstream developers? How can you be sure that all security holes will be 
> found or revealed? (for instance an old software in stable can have a 
> security issue which is not in the recent version, so upstream can't 
> find it) Why upstream developers of important softwares do not sometimes 
> provide stable versions of their programs (eg linux kernel, libc, xorg), 
> instead of let Debian do the job for them?

This is clear: _users_ of Debian find bugs and security holes. Debian 
reports these back to upstream. Sometimes, the developers are able to 
fix these and supply patches with the bug reports.

At the same time, upstream are finding their own bugs. Sometimes, if the 
bug is major, it is easier/quicker/more straightforward to move to newer 
code: sometimes it is hard to patch old code. Taking Firefox as an 
example; Firefox 2.0.* is out: there is less incentive to patch 1.5.*

This was part of the core disagreement with Mozilla over Debian 
packaging which has led to the Debian version being rebranded iceweasel.

Debian wanted to maintain an essentially unchanged stable distribution 
over the life of the distribution: Mozilla disagreed and also disagreed 
with Debian's policy to backport security fixes wherever possible.

> I mean, with Windows® (sorry), things are sometimes more logical: the 
> kernel, "xserver, xclient", etc. (important apps) are stable for years, 
> but you can have the last firefox without update them (like a mix 
> stable/unstable, except that stable softwares are maintained by uptream, 
> not by a distribution).

Watch the speed of Microsoft patches :) Watch the subtle changes in 
underlying libraries. Now add Microsoft applications on top.
Given that, for example, games require new versions of DirectX ...
the outward Windows version may appear to remain the same, but 
internally all sorts of things may be happening :)
> 

Can I save the next part, which deserves full consideration, for a 
separate reply ?

> - Why Debian isn't KISS (Keep It Simple, Stupid!) compliant? I mean, I 
> never need to change my conf files. If I have a problem, I solve with 
> apt-get or dpkg-reconfigure. I don't understand how things works and I'm 
> too dependent on Debian. Futhermore, .deb are really complicated compare 
> with other package tools. I like for instance Frugalware philosophy: "We 
> try to ship fresh and stable software, as close to the original 
source 
> as possible, because in our opinion most software is the best as is, and 
> doesn't need patching."
> 
> Well, I don't like what is Linux today. Software developers don't care 
> about stability, are not responsible, whereas each Linux distributions 
> re-do the same jobs without cooperate. Linus should do something. It's 
> too easy to create a kernel and then let it go alone.
> 
> Sorry for my English that is very bad compare to the real Ignatius 
> Reilly's English.
> 
> ZORRO.

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

[Enrico Zini]

On Fri, Jun 22, 2007 at 01:49:25AM +0200, Steinar H. Gunderson wrote:

> as it's stable.) The idea is to build a package both in a pbuilder and in
> a really filled chroot -- it currently contains 18GB of packages, which is
> most of the "devel" and "libdevel" sections. What is compared is:

This is exciting!

Another evil idea that come to my mind is running piuparts preinstalling
all packages that a package conflicts on, or replaces.

This topic also triggers a continuous thought that I had since the RMLL
conference in France, that is to use EDOS' computed "SAT temperature" of
packages[1] to make testing even nastier.

  [1] SAT temperature: I'm not able to explain it precisely, but it's a
  number that ends up being proportional to how complex is the
  dependency tree of a package.

Ideas that come to my mind are:

 - testing in piuparts *couples* of packages, both with high SAT
   temperature;
 - during testing, solving dependencies so that when a package depends
   on A | B | C, the package with the highest SAT temperature is pulled
   in;
 - test/audit the dependencies of high-SAT-temperature packages more
   throughly;
 - compute a "delicateness" index of a package by summing the SAT
   temperature of all packages that depend on it, and then give special
   attention to the most "delicate" packages to see RC bugs, maintainer
   activity and so on.  I'm working on creating a sample data, but I'll
   be away for the week-end.


Ciao,

Enrico

-- 
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: I don't understand Debian

[Steve Kemp]

On Fri Jun 22, 2007 at 20:24:22 +0200, ignatius wrote:

> - Why it's Debian that fixes bugs and security holes? Why it isn't upstream 
> developers? 

  Generally upstream developers *will* fix security holes, however 
 Debian users generally get their software from *us*.

  So if we're shipping software in our stable release then for a fix
 to be sent to our users we need to release it.

  (Otherwise the upstream software project might release a fixed
 release; but 99% of the package users would not notice and still
 be installing the version from our repository.)

> How can you be sure that all security holes will be found or 
> revealed?

  We cannot.

  We sometimes have some people scanning for problems and reporting
 them, but there is absolutely no promise that a program we ship
 will be free of security issues.

  Since you use Windows in your mail then I could say "How can
 Microsoft promise that their software is security-hole free?".  The
 answer is that they cannot, and neither can we.

> (for instance an old software in stable can have a security issue 
> which is not in the recent version, so upstream can't find it) Why upstream 
> developers of important softwares do not sometimes provide stable versions of 
> their programs (eg linux kernel, libc, xorg), instead of let Debian do the 
> job 
> for them?

  You'll have to ask them.

  Some projects do release patches for old(er) versions.  Others, such
 as the Mozilla project, do not.

> I mean, with Windows? (sorry), things are sometimes more logical: the kernel, 
> "xserver, xclient", etc. (important apps) are stable for years, but you can 
> have the last firefox without update them (like a mix stable/unstable, except 
> that stable softwares are maintained by uptream, not by a distribution).

  This is tangential to security support, and security updates.
 Important windows DLLs *do* get changed for security fixes, but the
 public API doesn't change - so that the latest programs still run.
 This is the same as the Debian stable release system.

> - Why Debian isn't KISS (Keep It Simple, Stupid!) compliant? I mean, I never 
> need to change my conf files. If I have a problem, I solve with apt-get or 
> dpkg-reconfigure. I don't understand how things works and I'm too dependent 
> on 
> Debian.

  The problem with you being dependent upon Debian is with you, not with
 Debian.

> Futhermore, .deb are really complicated compare with other package 
> tools. I like for instance Frugalware philosophy: "We try to ship fresh and 
> stable software, as close to the original source as possible, because in our 
> opinion most software is the best as is, and doesn't need patching."

  They are simple and logical once you look at them.  However 99% of
 users will never need to look at the files manually.  So it doesn't
 matter.

  I don't understand RPMs, but I don't need to.  I just install them
 with "yum install emacs" and it works.  The complexity is hidden from
 me and with good reason.

> Well, I don't like what is Linux today. Software developers don't care about 
> stability, are not responsible, whereas each Linux distributions re-do the 
> same 
> jobs without cooperate. Linus should do something. It's too easy to create a 
> kernel and then let it go alone.

  Linus has no say in distributions, and most likely doesn't care.
  If you have an objection to the way things are currently working
 you need to persuade the people who make your distribution to change,
 not just say that "you don't like it".  If you do that too often
 people will, rightly, ignore you.

Steve
-- 
Debian GNU/Linux System Administration
http://www.debian-administration.org/


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

Bug#430176: ITP: sorting-hat -- program to sort Debian Developers

[Steinar H. Gunderson]

Package: wnpp
Severity: wishlist
Owner: "Steinar H. Gunderson" <[EMAIL PROTECTED]>

* Package name: sorting-hat
  Version : 1.0.0
  Upstream Author : Erinn Clark <[EMAIL PROTECTED]>
* URL : physical://across/the/room
* License : Unknown (we'll give her a beer or something, and
she'll figure out)
  Programming Lang: Perl
  Description : program to sort Debian Developers

sorting-hat sorts Debian developers into the appropriate house
(Griffindor, Ravenclaw, Hufflepuff or Slytherin).

"It uses both use strict _and_ warnings! It's awesome!" - quote helix

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

Kernel: Linux 2.6.20.4
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash


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

Re: Bug#430176: ITP: sorting-hat -- program to sort Debian Developers

[David Nusinow]

On Sat, Jun 23, 2007 at 02:50:44AM +0200, Steinar H. Gunderson wrote: > 
Package: wnpp
> Severity: wishlist
> Owner: "Steinar H. Gunderson" <[EMAIL PROTECTED]>
> 
> * Package name: sorting-hat
>   Version : 1.0.0
>   Upstream Author : Erinn Clark <[EMAIL PROTECTED]>
> * URL : physical://across/the/room
> * License : Unknown (we'll give her a beer or something, and
> she'll figure out)
>   Programming Lang: Perl
>   Description : program to sort Debian Developers
> 
> sorting-hat sorts Debian developers into the appropriate house
> (Griffindor, Ravenclaw, Hufflepuff or Slytherin).
> 
> "It uses both use strict _and_ warnings! It's awesome!" - quote helix

I'm planning a fork of sorting-hat called sorting-hat-totally-awesome.
It'll include the international houses. If you'd like to help maintain
this, keep an eye out.

 - David Nusinow


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

Re: Bug#429514: ITP: openoffice.org-ctl-he -- Turns on OO.org CTL support, and sets Hebrew as the default CTL locale

[Kevin Mark]

On Fri, Jun 22, 2007 at 09:11:04PM +0100, Enrico Zini wrote:
> On Mon, Jun 18, 2007 at 03:43:45PM +0100, Lior Kaplan wrote:
> 
> >   Description : Turns on CTL support & sets Hebrew as the default CTL 
> > locale
> > 
> > This package installs an OO.org extention which turns on CTL support, and 
> > sets
> > Hebrew as the default language.
> > 
> > The user can overright these setting by changning them in the tools -> 
> > options
> > -> language settings menu.
> 
> It sounds like a useful package, but please add to the description an
> expansion of the CTL acronym.
I think maybe he means RTL (right to left), which refers to the fact
that hebrew (and other languages) are read/written starting from the
right.

-- 
|  .''`.  == Debian GNU/Linux == |   my web site:   |
| : :' :  The  Universal |mysite.verizon.net/kevin.mark/|
| `. `'  Operating System| go to counter.li.org and |
|   `-http://www.debian.org/ |be counted! #238656   |
|  my keyserver: subkeys.pgp.net | my NPO: cfsg.org |
|join the new debian-community.org to help Debian!  |
|___  Unless I ask to be CCd, assume I am subscribed ___|


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

Re: Bug#430176: ITP: sorting-hat -- program to sort Debian Developers

[Kevin Mark]

On Sat, Jun 23, 2007 at 02:50:44AM +0200, Steinar H. Gunderson wrote:
> Package: wnpp
> Severity: wishlist
> Owner: "Steinar H. Gunderson" <[EMAIL PROTECTED]>
> 
> * Package name: sorting-hat
>   Version : 1.0.0
>   Upstream Author : Erinn Clark <[EMAIL PROTECTED]>
> * URL : physical://across/the/room
> * License : Unknown (we'll give her a beer or something, and
> she'll figure out)
>   Programming Lang: Perl
>   Description : program to sort Debian Developers
> 
> sorting-hat sorts Debian developers into the appropriate house
> (Griffindor, Ravenclaw, Hufflepuff or Slytherin).
> 
> "It uses both use strict _and_ warnings! It's awesome!" - quote helix
> 
> -- System Information:
> Debian Release: lenny/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 2.6.20.4
> Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/bash
> 
I would suspect that this business process has a few patents behind it as
well as the associated trademarks on the names, so may not clear with
the -legal crowd or the NEW queue. So it may not be a candidate for
'main'. Maybe it can be hosted on a server in the transnation republic?
-- 
|  .''`.  == Debian GNU/Linux == |   my web site:   |
| : :' :  The  Universal |mysite.verizon.net/kevin.mark/|
| `. `'  Operating System| go to counter.li.org and |
|   `-http://www.debian.org/ |be counted! #238656   |
|  my keyserver: subkeys.pgp.net | my NPO: cfsg.org |
|join the new debian-community.org to help Debian!  |
|___  Unless I ask to be CCd, assume I am subscribed ___|


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

Re: Bug#429514: ITP: openoffice.org-ctl-he -- Turns on OO.org CTL support, and sets Hebrew as the default CTL locale

[Jaldhar H. Vyas]

On Fri, 22 Jun 2007, Kevin Mark wrote:


I think maybe he means RTL (right to left), which refers to the fact
that hebrew (and other languages) are read/written starting from the
right.



No CTL means Complex Text Layout.  In CTL languages the order as well as 
the appearence of glyphs can change; they are not in a strict sequence. 
Indic languages for example are CTL but not RTL.  Hebrew and Arabic are 
both I suppose.


--
Jaldhar H. Vyas <[EMAIL PROTECTED]>
La Salle Debain - http://www.braincells.com/debian/


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

Re: Using standardized SI prefixes

[Hamish Moffatt]

On Thu, Jun 21, 2007 at 05:29:47PM -0400, Ivan Jager wrote:
> On Thu, 21 Jun 2007, Hamish Moffatt wrote:
> >On Wed, Jun 20, 2007 at 08:11:23PM -0400, Ivan Jager wrote:
> >You seem to claim that binary units (ie powers of 2) are natural
> >everywhere related to computers, but I disagree.
> 
> Not everywhere related to computers. Only when the unit is bytes.

Wow, what a concession!

> >It's natural for
> >memory and structures like it, but not for bitstream quantities like
> >network traffic.
> 
> Yes, for network traffic both are just as natural.

Except that our decimal prefixes (10^N) are part of our language and
therefore win by default.

> >Most NAND FLASH chips have 2062 byte
> >blocks, which even throws the memory device argument out the window.
> 
> I have no idea about this, but I would expect
> http://www.google.com/search?hl=en&q=2062+flash+nand&btnG=Search
> to have more results where the 2062 is a block size...

Sorry, I meant 2112.

> You forgot about ECC SDRAM which is 72 bits wide. So when you buy a 1GB 
> (72x128M)  DIMM, you're actually getting 1207959552 bytes of raw storage.

Actually the controllers don't memory-map the extra 8 bits per 64. The
existence of the extra bits is totally hidden between the RAM and the
controller.

For NAND flash however the whole 2112 byte blocks are memory mapped.
After every 2112 bytes there's a gap until the next 4K boundary.

> But even then, the powers of two are more natural than the powers of 10.

Yes for memory structures, I agree. You failed to address my point about
bitstream quantities like network traffic.

Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


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

Re: transition of packages into testing

[Lionel Elie Mamane]

On Thu, Jun 21, 2007 at 11:29:32PM +0300, Lars Wirzenius wrote:
> On to, 2007-06-21 at 14:40 -0400, Kamaraju S Kusumanchi wrote:

>> I am trying to figure out why texmacs has not entered into testing. I
>> visited http://bjorn.haxx.se/debian/testing.pl?package=texmacs but there I
>> was not able to find any useful information.

> It must be at least ten days old, but that is not the only
> criterion.  (...) You could check the buildd logs on
> buildd.debian.org to see if there's any problems.

I recommend the use of http://www.buildd.net/, which will give a nice
colour-coded table of status for different archs. Right now, you can
see that the hppa built happened since you asked, and that is was
uploaded, and that ia64 is in "dep-wait" status. This means that it is
waiting for a build-dependency to become satisfiable on
ia64. Scrolling down, you see:

ia64:
2007-06-23 04:43:19 +0200 last updated

editors/texmacs_1:1.0.6.10-1: Dep-Wait by buildd_ia64-caballero 
[optional:out-of-date]
  Dependencies: guile-1.8-dev
  Previous state was Building until 2007 Apr 18 12:34:06


So it is waiting on guile-1.8-dev to become available on ia64. Which
(if you go looking to its page) doesn't build because of an
arch-specific FTBFS. See the Debian bug and
http://lists.gnu.org/archive/html/guile-devel/2006-12/msg8.html .

-- 
Lionel


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

Re: [EMAIL PROTECTED] Package

[Charles Plessy]

Le Fri, Jun 22, 2007 at 02:20:33PM -0400, Zachary Palmer a écrit :
> Hello, all.  It has been my understanding that the reason that the 
> [EMAIL PROTECTED] distributed computing software has not been made a Debian 
> package is that the license under which it is released does not allow it 
> to be free.  This software package has pretty much the best reason for 
> being closed source that I've encountered; they want to prevent 
> falsified results from damaging the research.

Dear Zachary,

as said in another mail, [EMAIL PROTECTED] is definitely non-free. Hovever,
if Debian would become an "authorized distributor", the licence would be
suitable for non-free.

  You may only use unmodified versions of [EMAIL PROTECTED] obtained 
  through authorized distributors to connect to the [EMAIL PROTECTED] 
  servers. Use of other software to connect to the [EMAIL PROTECTED] 
  servers is strictly prohibited.
  
  Distribution of this software is prohibited. It may only be 
  obtained by downloading from Stanford's web site
  (http://folding.stanford.edu and pages linked therein).

I guess that in that case, there would be a link from the Stanford site to
packages.debian.org for instance.

However, one thing that you should make clear when contacting upstream is
that their software would eventually become released together with Debian
stable, and therefore not be upgraded (unless the stable relase team would
be OK, why not ?) This is also valid in the case of a wrapper: their
binary could require some libraries which are too old in stable, hence
breaking the wrapper.

Do they frequently upgrade ? How long can an old client connect ? In that
case, packaging would be commiting yourself to follow the upgrades
closely. I do not think that it would help our users if the Debian package
would periodically provide a binary which is not allowed to connect.

Maybe the Debian-Med packaging team could provide you a safety net by
co-maintaining the package and hosting the /debian dir in our SVN repo, so
that you can take holidays without coming back with an obsolete package
and angry users. However, would the package not be actively followed by a
dedicated person, it would be better removed (or not packaged at that
point)

Lastly, I am not sure that closed-sourceness is the best strategy against
cheating. I guess that the expertise area of [EMAIL PROTECTED] is structural
biology, wheras the expertise of cheaters is... well... cheating.

Have a nice day,

-- 
Charles Plessy
Debian-Med packaging team
Wako, Saitama, Japan


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