Re: Bug#445866: ITP: perforce -- closed source revision control system

[Sam Clegg]

On Mon, 2007-10-08 at 14:42 -0700, Tyler MacDonald wrote:
> Florian Weimer <[EMAIL PROTECTED]> wrote:
> > Seems to me that this depends on Perforce.  D'oh.
> > 
> > (I don't know anything about Perforce.  Perhaps it's really dangerous
> > software.  But perhaps it's just non-free.)
> 
>   Perforce is an absolutely *excellent* VCS with the unfortunate
> distinction of being proprietary. SubVersion can do most (but not all) of
> what it does, albeit 10 times slower. Still, I've migrated all of my stuff
> over to subversion, because, well, subversion is free. Perforce is free (as
> in "free beer") for open source developers, if you want more than 2 users on
> one VCS server, you have to sign a contract, get a license, give the
> perforce people full access to your repo, sign a new contract whenever you
> server's IP address changes, and renew each year


Slightly off topic, but you don't need to give the perforce people
access to you repo (unless you really want them to come in a fix
something) and you don't need to renew each year (unless you want
support from them).



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

Re: Bug#445866: ITP: perforce -- closed source revision control system

[Sam Clegg]

On Tue, 2007-10-09 at 05:41 +0300, Faidon Liambotis wrote:
> Daniel Jacobowitz wrote:
> > On Mon, Oct 08, 2007 at 03:41:21PM -0400, Roberto C. S?nchez wrote:
> >> Given the great abundance of revision control systems already packaged
> >> for Debian, what is the point of adding another?  Especially when it is
> >> non-free.
> > 
> > How about "people use it"?  There's plenty of installations of
> > perforce; I think making it easier to use Debian with them is
> > within the mandate for non-free.
> I'd say upload only the client to non-free.
> 
> We should provide users a way to use their existent preforce servers but
> we should not encourage new installations of perforce.
> 
> Sounds like a compromise to me :)

Indeed, my primary aim was to make it easy for anyone wanting to run
debian in an org that uses perforce (i.e. people like myself).

I agree the server package is of less use in this respect, its simply
there to make it easy for people to choose debian on the server side as
well.  Pending the legal conclusions I'll upload just the client package
initially.


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

Re: Bug#445866: ITP: perforce -- closed source revision control system

[Tyler MacDonald]

Sam Clegg <[EMAIL PROTECTED]> wrote:
> > Perforce is an absolutely *excellent* VCS with the unfortunate
> > distinction of being proprietary. SubVersion can do most (but not all) of
> > what it does, albeit 10 times slower. Still, I've migrated all of my stuff
> > over to subversion, because, well, subversion is free. Perforce is free (as
> > in "free beer") for open source developers, if you want more than 2 users on
> > one VCS server, you have to sign a contract, get a license, give the
> > perforce people full access to your repo, sign a new contract whenever you
> > server's IP address changes, and renew each year
> Slightly off topic, but you don't need to give the perforce people
> access to you repo (unless you really want them to come in a fix
> something) and you don't need to renew each year (unless you want
> support from them).

  You don't need to go through all of that if you buy the product. If you
get a free open source developmnet license, they want you to renew every
year, and they want an account on your server so they can make sure you've
only got open source code on there.

- Tyler


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

Bug#445983: ITP: dialign-t -- Segment-based multiple sequence alignment

[Charles Plessy]

Package: wnpp
Severity: wishlist
Owner: Charles Plessy <[EMAIL PROTECTED]>

  Package name: dialign-t
  Version : 0.2.2
  Upstream Author : Amarendran R. Subramanian 

  URL : http://dialign-t.gobics.de/
  License : LGPL
  Programming Lang: C
  Description : Segment-based multiple sequence alignment

 DIALIGN-T is a command line tool to perform multiple alignment of protein or
 DNA sequences. It is a complete reimplementation of the segment-base approach
 including several new improvements and heuristics that significantly enhance
 the quality of the output alignments compared to DIALIGN 2.2. For pairwise
 alignment, DIALIGN-T uses a fragment-chaining algorithm that favours chains of
 low-scoring local alignments over isolated high-scoring fragments. For
 multiple alignment, DIALIGN-T uses an improved greedy procedure that is less
 sensitive to spurious local sequence similarities.  DIALIGN-T has been
 published in Amarendran R. Subramanian, Jan Weyer-Menkhoff, Michael Kaufmann,
 Burkhard Morgenstern: DIALIGN-T: An improved algorithm for segment-based
 multiple sequence alignment. BMC Bioinformatics 2005, 6:66.


DIALIGN-T is needed by dm_coffee, a special mode of t_coffee prepared
especially for Debian, in which non-free alignment software was replaced by
free alternatives.



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

Debian Menu transition status

[Bill Allombert]

Dear developers,

This is a status update for the Debian Menu transition.

1) About 25% of menu files had been updated to the new menu section.
This is promising, but unfortunately, only about 25% of menu files
in removed/split sections have been updated, so there is still a lot of
packages to change before the menus look good again.

2) Some common mistakes to avoid:

  - Do not put menu entries _directly_ under Applications/Science,
Applications/System and Applications/Network, but in one of
their subsections.

  - The longtitle need to be a valid menu entry if displayed alone,
and must identify uniquely the program. For that reason, it is
usually best if it includes the program name at the start, though
acronyms can be expanded.
  
  - Even if your menu entry section still exist in the new hierarchy,
maybe your menu entry would be better in one of the newly added
section, e.g. Applications/Office or Applications/Video.

3) menu 2.1.36 includes menu sections translations for Basque,
Bulgarian, French, Gujarati, Nepali, Portuguese, Tamil, Thai and
Vietnamese. Thanks goes to the translators and Christian Perrier.

4) Lintian has been updated for the new structure [0]. Thanks goes to 
Russ Allbery.

[0] http://lintian.debian.org/reports/Tmenu-item-creates-new-section.html

5) We decided to put clocks in Games/Toys because most of them are
mostly eye-candy.

   If you did not migrate to the new structure already:
   

What you should do:
===

  Look up the new hierarchy in the menu manual [1] and update your
menu files to use the new hierarchy. The manual include example packages
for each sections.  A summary of change is provided below. If you are
not sure where to put your menu entry, please send an email to the
debian-policy list.

[1] http://www.debian.org/doc/packaging-manuals/menu.html/ch3.html#s3.5

Thanks in advance with your effort in carrying out this transition.

REMOVED SECTIONS

Apps/Tools
Games/Sports
Screen/Root-window

SPLIT SECTIONS:
Apps/Net [now Applications/Network]
Apps/Science [now Applications/Science]
Apps/System  [now Applications/System]

NEW SECTIONS

Applications
  Accessibility [new]
  File Management [new]
  Mobile Devices [new]
  Network
 Network/Communication [new]
 Network/File Transfer [new]
 Network/Monitoring [new]
 Network/Web Browsing [new]
 Network/Web News [new]
  Office [new]
  Project Management [new]
  Science
 Science/Astronomy [new]
 Science/Biology [new]
 Science/Chemistry [new]
 Science/Data Analysis [new]
 Science/Engineering [new]
 Science/Geoscience [new]
 Science/Medicine [new]
 Science/Physics [new]
 Science/Social [new]
  System
 System/Hardware [new]
 System/Monitoring [new]
 System/Package Management [new]
 System/Security [new]
  TV and Radio [new]
  Video [new]
  Web Development [new]
Games
  Tools [new]
Window Maker [new]

RENAMED SECTIONS

Applications [was:Apps]
  Amateur Radio [was:Hamradio]
  Data Management [was:Databases]
  Network [was:Net]
  Science
 Science/Electronics [was:Technical]
 Science/Mathematics [was:Math]
  System
 System/Administration [was:Admin]
 System/Language Environment [was:Language-Environment]
  Terminal Emulators [was:XShells]
Games
  Action [was:Arcade]
  Blocks [was:Tetris-like]
Screen
  Saving [was:Save]
  Locking [was:Lock]
Window Managers [was:WindowManagers]
FVWM Modules [was:WindowManagers/Modules]

Older transitions:
===

1) /usr/lib/menu-> /usr/share/menu
There are still 174 packages with menu entries in /usr/lib/menu.
Please fix them. I will consider such packages NMU candidates.

2) /usr/sbin/su-to-root -> /usr/bin/su-to-root
Actually, please just use "su-to-root". There is no need to
hard-code the path.

3) /usr/sbin/install-menu -> /usr/bin/install-menu
There are still 22 packages using #! /usr/sbin/install-menu.
Please change to #! /usr/bin/install-menu

Others changes:
===

-- Use this update as an opportunity to improve the title and the longtitle.
In particular, please capitalize them properly.
Translations of title and longtitle will be available if we reach a
sufficiently high quality.

-- Menu support a new format called "menu-2" since 8 years. In this
format lines break are not significant, but logical lines end by a
semi-comma:

This is an example:

!C menu-2
?package(pari-gp):
  section="Applications/Science/Mathematics"
  needs="text"
  title="PARI/GP"
  command="gp"
;

I do not have strong opinion about this format, but feel free to use it.
Since even potato support menu-2, there are no upgrade or backport
issue, however this might break the lintian code to parse menu file.

menu-2 is also available for menu-methods, through the definition
compat="menu-2". I highly recommend its use for menu-methods.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 



signature.asc

Re: Debian Menu transition status

[Luk Claes]

On Tue, Oct 09, 2007 at 06:12:33PM +0200, Bill Allombert wrote:

> This is a status update for the Debian Menu transition.

> 2) Some common mistakes to avoid:
> 
>   - Do not put menu entries _directly_ under Applications/Science,
> Applications/System and Applications/Network, but in one of
> their subsections.

I guess these subsections are because there are possibly many entries in
the above mentioned sections? Unfortunately many of the most used
graphical programs reside in these sections. Would it be possible to
have a section of recently used programs so one doesn't need to go
through three niveaus before one reaches frequently used programs? If
not would it be possible to consider making a section with the most used
installed programs (based on popcon for instance)?

Cheers

Luk


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

Re: Bits from the listmasters

[Kurt Roeckx]

On Tue, Oct 09, 2007 at 01:44:47PM +0200, Martin Zobel-Helas wrote:
> How to help listmasters against spam
> 
> 
>* If you notice a spam in the list archives, press the 'Report As
>  Spam'-Button.

I don't see such a button on the list archives.  I only see it
on the BTS.

>* Report spam that gets to you through our filters to
>  [EMAIL PROTECTED]

What should we do with spam send to the BTS that then gets forwarded
to some list?  I think this only happens with pseudo packages, and a
few others like apt and glibc.  Do we report it twice?

Will spam that was send to the list be removed from the archives?


Kurt


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

Re: Bits from the listmasters

[Lars Wirzenius]

ti, 2007-10-09 kello 18:33 +0200, Kurt Roeckx kirjoitti:
> On Tue, Oct 09, 2007 at 01:44:47PM +0200, Martin Zobel-Helas wrote:
> > How to help listmasters against spam
> > 
> > 
> >* If you notice a spam in the list archives, press the 'Report As
> >  Spam'-Button.
> 
> I don't see such a button on the list archives.  I only see it
> on the BTS.

There's a button in the upper right hand corner when I look at a
message. There's one on
http://lists.debian.org/debian-accessibility/2007/10/msg5.html for
example, as a random example.

If this is a case where the button sometimes is there and sometimes not,
it's a bug that needs fixing, but perhaps it's a case of the button
being too easy to miss?

-- 
That which does not kill us makes us stranger


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

Bug#445998: ITP: eaccelerator -- PHP accelerator, optimizer, and dynamic content cache

[Alexander Gerasiov]

Package: wnpp
Severity: wishlist
Owner: Alexander Gerasiov <[EMAIL PROTECTED]>

* Package name: eaccelerator
  Version : 0.9.5.2
  Upstream Author : eaccelerator team http://eaccelerator.net/wiki/Team
* URL : http://eaccelerator.net
* License : GPL
  Programming Lang: C
  Description : PHP accelerator, optimizer, and dynamic content cache

eAccelerator is a free open-source PHP accelerator, optimizer, and
dynamic content cache. It increases the performance of PHP scripts by
caching them in their compiled state, so that the overhead of compiling
is almost completely eliminated. It also optimizes scripts to speed up
their execution. eAccelerator typically reduces server load and
increases the speed of your PHP code by 1-10 times.


Some dummy packages available for now in my repository at
http://gq.net.ru/debian

I'm going to upload it after fixing some packaging issues. Feel free to
kick me by mail, if I'm too slow.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing-proposed-updates
  APT policy: (700, 'testing-proposed-updates'), (700, 'testing'), (670, 
'proposed-updates'), (670, 'stable'), (600, 'unstable'), (550, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-2-vserver-686 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R)
Shell: /bin/sh linked to /bin/bash



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

Re: Bits from the listmasters

[Thijs Kinkhorst]

On Tue, October 9, 2007 18:33, Kurt Roeckx wrote:
> I don't see such a button on the list archives.  I only see it
> on the BTS.

Check out the top-right of this page:
http://lists.debian.org/debian-devel/2007/10/msg00318.html


Thijs


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

seeking: Ian Jackson

[martin f krafft]

[EMAIL PROTECTED] expands to a greenend.org.uk address, and the mx for that
domain refuses to accept my mail.

: host
mx-relay.chiark.greenend.org.uk[212.13.197.229] said: 550
invalid MAIL-FROM: Error during DNS MX lookup for
lapse.madduck.net: DNS alias found where canonical name wanted
[Irritated] (in reply to RCPT TO command)

Yes, lapse.madduck.net is a CNAME (*c*anonical *name*) to an MX RR,
and that's RFC-compliant ttbomk. If it is not, I would appreciate if
someone shoved the relevant sections into my face.

In the mean time, I'd be grateful if Ian gave me a means to
communicate with him. Or if someone would offer to relay a message
to him.

The spammers have long won if people put such boulders in the way of
communication. Oh wait, I doubt spammers use CNAMEs...

-- 
 .''`.   martin f. krafft <[EMAIL PROTECTED]>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
"although occasionally there is something to be said for solitude."
  -- special agent dale cooper


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: Bits from the listmasters

[Don Armstrong]

On Tue, 09 Oct 2007, Kurt Roeckx wrote:
> What should we do with spam send to the BTS that then gets forwarded
> to some list? I think this only happens with pseudo packages, and a
> few others like apt and glibc. Do we report it twice?

For BTS spam, if it's been removed from the bug log already, there's
no real need to report it. That almost always means Blars (or less
often, myself) have looked at the spam comming through and added rules
to deal with it (which now get added to the lists set of rules too.)

For adjustment of the list archives, you'll have to click on the
button in the list archives.

 
Don Armstrong

-- 
If a nation values anything more than freedom, it will lose its
freedom; and the irony of it is that if it is comfort or money it
values more, it will lose that, too.
 -- W. Somerset Maugham

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


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

Re: Bug#445998: ITP: eaccelerator -- PHP accelerator, optimizer, and dynamic content cache

[Tim Dijkstra]

On Tue, 09 Oct 2007 21:29:38 +0400
Alexander Gerasiov <[EMAIL PROTECTED]> wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Alexander Gerasiov <[EMAIL PROTECTED]>
> 
> * Package name: eaccelerator
>   Version : 0.9.5.2
>   Upstream Author : eaccelerator team http://eaccelerator.net/wiki/Team
> * URL : http://eaccelerator.net
> * License : GPL
>   Programming Lang: C
>   Description : PHP accelerator, optimizer, and dynamic content cache

> Some dummy packages available for now in my repository at
> http://gq.net.ru/debian
>
> I'm going to upload it after fixing some packaging issues. Feel free to
> kick me by mail, if I'm too slow.

Are the license issues finally solved then? Last time I checked
binaries were not distributable, see for example:

http://www.mailarchives.org/list/debian-devel/msg/2005/08164

grts Tim


signature.asc
Description: PGP signature

Re: Bits from the listmasters

[Kurt Roeckx]

On Tue, Oct 09, 2007 at 08:15:58PM +0300, Lars Wirzenius wrote:
> ti, 2007-10-09 kello 18:33 +0200, Kurt Roeckx kirjoitti:
> > On Tue, Oct 09, 2007 at 01:44:47PM +0200, Martin Zobel-Helas wrote:
> > > How to help listmasters against spam
> > > 
> > > 
> > >* If you notice a spam in the list archives, press the 'Report As
> > >  Spam'-Button.
> > 
> > I don't see such a button on the list archives.  I only see it
> > on the BTS.
> 
> There's a button in the upper right hand corner when I look at a
> message. There's one on
> http://lists.debian.org/debian-accessibility/2007/10/msg5.html for
> example, as a random example.

For some reason I've missed it. 

> If this is a case where the button sometimes is there and sometimes not,
> it's a bug that needs fixing, but perhaps it's a case of the button
> being too easy to miss?

Well, I use lynx, and it's actually the first thing on the page itself.
I guess I wasn't looking there for it.


Kurt


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

Re: seeking: Ian Jackson

[Simon Josefsson]

martin f krafft <[EMAIL PROTECTED]> writes:

> [EMAIL PROTECTED] expands to a greenend.org.uk address, and the mx for that
> domain refuses to accept my mail.
>
> : host
> mx-relay.chiark.greenend.org.uk[212.13.197.229] said: 550
> invalid MAIL-FROM: Error during DNS MX lookup for
> lapse.madduck.net: DNS alias found where canonical name wanted
> [Irritated] (in reply to RCPT TO command)
>
> Yes, lapse.madduck.net is a CNAME (*c*anonical *name*) to an MX RR,
> and that's RFC-compliant ttbomk. If it is not, I would appreciate if
> someone shoved the relevant sections into my face.

RFC 1034 section 3.6.2:

  Domain names in RRs which point at another name should always point at
  the primary name and not the alias.  This avoids extra indirections in
  accessing information.

See also RFC 1912 section 2.4:

   Don't use CNAMEs in combination with RRs which point to other names
   like MX, CNAME, PTR and NS.  (PTR is an exception if you want to
   implement classless in-addr delegation.)  For example, this is
   strongly discouraged:

   podunk.xx.  IN  MX  mailhost
   mailhostIN  CNAME   mary
   maryIN  A   1.2.3.4


   [RFC 1034] in section 3.6.2 says this should not be done, and [RFC
   974] explicitly states that MX records shall not point to an alias
   defined by a CNAME.  This results in unnecessary indirection in
   accessing the data, and DNS resolvers and servers need to work more
   to get the answer.  If you really want to do this, you can accomplish
   the same thing by using a preprocessor such as m4 on your host files.

There is some disagreement though:

http://www.mengwong.com/misc/rfc1912-is-wrong.html

/Simon


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

mail from and CNAMEs (was: seeking: Ian Jackson)

[martin f krafft]

I don't really think we need to have this discussion on
debian-devel. Sorry for not setting reply-to. I will not post more
than this one reply, which I hope sets things straight.

also sprach Simon Josefsson <[EMAIL PROTECTED]> [2007.10.09.2015 +0100]:
> RFC 1034 section 3.6.2:
> 
>   Domain names in RRs which point at another name should always
>   point at the primary name and not the alias.  This avoids extra
>   indirections in accessing information.

I read that as: CNAMEs should not point at other CNAMEs, and MX/NS
RRs should point at A records, not CNAMEs. Not that an email
address' domain cannot be a CNAME (to an MX RR, which links to two
A RRs).

> See also RFC 1912 section 2.4:
> 
>Don't use CNAMEs in combination with RRs which point to other names
>like MX, CNAME, PTR and NS.  (PTR is an exception if you want to
>implement classless in-addr delegation.)  For example, this is
>strongly discouraged:
> 
>podunk.xx.  IN  MX  mailhost
>mailhostIN  CNAME   mary
>maryIN  A   1.2.3.4

I don't do that.

lapse.madduck.net is an alias for rw.madduck.net.
rw.madduck.net mail is handled by 99 b.mx.madduck.net.
rw.madduck.net mail is handled by 10 a.mx.madduck.net.

What they say is that it should not be

lapse.madduck.net is an alias for rw.madduck.net.
lapse.madduck.net mail is handled by 99 b.mx.madduck.net.
lapse.madduck.net mail is handled by 10 a.mx.madduck.net.
^
which makes perfect sense since it would be impossible to decide
which MX to use if rw.madduck.net also had MX RRs.

>[RFC 1034] in section 3.6.2 says this should not be done, and [RFC
>974] explicitly states that MX records shall not point to an alias
>defined by a CNAME. 

I don't do either.

-- 
 .''`.   martin f. krafft <[EMAIL PROTECTED]>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
"africa is a nation..."
  - george w. bush


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: seeking: Ian Jackson

[Martin Zobel-Helas]

Hi, 

On Tue Oct 09, 2007 at 19:36:49 +0100, martin f krafft wrote:
> [EMAIL PROTECTED] expands to a greenend.org.uk address, and the mx for that
> domain refuses to accept my mail.
> 
> : host
> mx-relay.chiark.greenend.org.uk[212.13.197.229] said: 550
> invalid MAIL-FROM: Error during DNS MX lookup for
> lapse.madduck.net: DNS alias found where canonical name wanted
> [Irritated] (in reply to RCPT TO command)
> 
> Yes, lapse.madduck.net is a CNAME (*c*anonical *name*) to an MX RR,
> and that's RFC-compliant ttbomk. If it is not, I would appreciate if
> someone shoved the relevant sections into my face.
> 
> In the mean time, I'd be grateful if Ian gave me a means to
> communicate with him. Or if someone would offer to relay a message
> to him.
> 
> The spammers have long won if people put such boulders in the way of
> communication. Oh wait, I doubt spammers use CNAMEs...

how about sending mails from master.debian.org with either
[EMAIL PROTECTED] or [EMAIL PROTECTED] :)

Greetings
Martin

PS: i know, that solution is too simple... :)
-- 
[EMAIL PROTECTED] /root]# man real-life
No manual entry for real-life


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

Re: Testing parallel builds

[Ben Hutchings]

On Mon, 2007-10-08 at 14:36 +0200, Bernd Zeimetz wrote:
> >> Anyway, I'm aware a lot of packages will probably break at the moment, 
> >> which 
> >> is why I'm using wishlist.
> > 
> >   I still believe that you should not file such bugs, I still fail to
> > see how it improves debian, as if we really need to build more packages
> > at the same time, we could run many sbuild instances on the same
> > machine.
> 
> Some years ago I've used -j sometimes to speed up building on Solaris
> (using gmake and gcc) on multiprocessor machines, very often with the
> result that the build went trough fine, but the resulting binary was
> broken. Since that time I've avoided to use -j, except to test things.
> But probably those problems were fixed in the meantime

These problems are the result of bugs in the makefiles, not in make.  So
they can only be fixed there.  (Well, there is a Solaris bug that
affects parallel builds using gmake over NFS, but that causes spurious
failures, not silently broken results.)

Ben.

-- 
Ben Hutchings
I haven't lost my mind; it's backed up on tape somewhere.


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

Re: Bug#445998: ITP: eaccelerator -- PHP accelerator, optimizer, and dynamic content cache

[Roberto C . Sánchez]

On Tue, Oct 09, 2007 at 09:24:14PM +0200, Tim Dijkstra wrote:
> On Tue, 09 Oct 2007 21:29:38 +0400
> Alexander Gerasiov <[EMAIL PROTECTED]> wrote:
> 
> > Package: wnpp
> > Severity: wishlist
> > Owner: Alexander Gerasiov <[EMAIL PROTECTED]>
> > 
> > * Package name: eaccelerator
> >   Version : 0.9.5.2
> >   Upstream Author : eaccelerator team http://eaccelerator.net/wiki/Team
> > * URL : http://eaccelerator.net
> > * License : GPL
> >   Programming Lang: C
> >   Description : PHP accelerator, optimizer, and dynamic content cache
> 
> > Some dummy packages available for now in my repository at
> > http://gq.net.ru/debian
> >
> > I'm going to upload it after fixing some packaging issues. Feel free to
> > kick me by mail, if I'm too slow.
> 
> Are the license issues finally solved then? Last time I checked
> binaries were not distributable, see for example:
> 
> http://www.mailarchives.org/list/debian-devel/msg/2005/08164
> 
> grts Tim

Also, in one of the many discussions about this piece of software it
came out that original author of turck-mmcache (the software on which
eaccelerator is based) now works for Zend.  Zend produces a proprietary
(and expensive) accelerator-sort of product for PHP.  It is doubtful
that they would enable the distribution of something that they would see
as competing with their product.

I seem to recall that the people who took over eaccelerator had it in
mind to do a complete rewrite of the eccalerator code to break any link
with turck-mmcache, allowing them to relicense eaccelerator.  If that
rewrite is complete, then the software may be distributable.  However, I
have not looked into it for quite a while.

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: seeking: Ian Jackson

[martin f krafft]

also sprach Martin Zobel-Helas <[EMAIL PROTECTED]> [2007.10.09.2026 +0100]:
> how about sending mails from master.debian.org with either
> [EMAIL PROTECTED] or [EMAIL PROTECTED] :)

I couldn't sign those messages. But I could temporarily set mutt's
$envelope_from_address. Thanks for the hint.

-- 
 .''`.   martin f. krafft <[EMAIL PROTECTED]>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
"the human brain is like an enormous fish --
 it is flat and slimy
 and has gills through which it can see."
   -- monty python


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: seeking: Ian Jackson

[Ian Jackson]

martin f krafft writes ("seeking: Ian Jackson"):
> In the mean time, I'd be grateful if Ian gave me a means to
> communicate with him. Or if someone would offer to relay a message
> to him.

A few people have drawn my attention to this thread, thanks.  For
future reference, my db.debian.org entry ought to have my phone number
in it and I think it's fine to use that when email fails.

I've added a hole in my filter for *.madduck.net so martin should be
able to email me now.


> Yes, lapse.madduck.net is a CNAME (*c*anonical *name*) to an MX RR,
> and that's RFC-compliant ttbomk. If it is not, I would appreciate if
> someone shoved the relevant sections into my face.

The prevailing IETF standard for mail transmission over the Internet
is STD-10 (RFC821), which says:

   3.7.  DOMAINS
...
  Whenever domain names are used in SMTP only the official names are
  used, the use of nicknames or aliases is not allowed.

"CNAME" in CNAME RR means "the lhs domain is an alias; the canonical
name is as follows".  So
  lapse.madduck.net. CNAME rw.madduck.net.
means
  "lapse.madduck.net's canonical name is rw.madduck.net"
ie that lapse.madduck.net is _not_ a canonical name but an alias.

RFC2181 is helpful on this point:

 10.1.1. CNAME terminology

It has been traditional to refer to the label of a CNAME record as "a
CNAME".  This is unfortunate, as "CNAME" is an abbreviation of
"canonical name", and the label of a CNAME record is most certainly
not a canonical name.  It is, however, an entrenched usage.  Care
must therefore be taken to be very clear whether the label, or the
value (the canonical name) of a CNAME resource record is intended.
In this document, the label of a CNAME resource record will always be
referred to as an alias.

If you have a suggestion for improving the error message I'd be happy
to hear it - but preferably not anything much longer than the existing
message "DNS alias found where canonical name wanted" which is already
rather on the long side.

> The spammers have long won if people put such boulders in the way of
> communication. Oh wait, I doubt spammers use CNAMEs...

Statistics for this cause of rejection for last week:

-chiark:~> grep 'DNS alias found where canonical name wanted' 
/var/log/sauce/reject.log.0 | wc -l
19893
-chiark:~> 

This includes attempts which would also have been rejected for some
other reason, but it gives an idea of the prevalence.

And yes, I'm afraid I agree with you - the spammers have indeed won.
I regret the inconvenience.

Regards,
Ian.


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

RFC 2?821 and CNAMEs (was: seeking: Ian Jackson)

[martin f krafft]

Thanks, Ian, for your reply. I don't quite agree with it though.

also sprach Ian Jackson <[EMAIL PROTECTED]> [2007.10.09.2102 +0100]:
> The prevailing IETF standard for mail transmission over the Internet
> is STD-10 (RFC821), which says:

RFC 2821 obsoletes STD-10, and says:

3.6 Domains

   Only resolvable, fully-qualified, domain names (FQDNs) are permitted
   when domain names are used in SMTP.  In other words, names that can
   be resolved to MX RRs or A RRs (as discussed in section 5) are
   permitted, as are CNAME RRs whose targets can be resolved, in turn,
  
   to MX or A RRs.
   ^^^

Though I guess it gets interesting when we start to look at the
meaning of "obsoletes":

Abstract

   This document is a self-contained specification of the basic protocol
   for the Internet electronic mail transport.  It consolidates, updates
   and clarifies, but doesn't add new or change existing functionality
   of the following:  

   -  the original SMTP (Simple Mail Transfer Protocol) specification of
  RFC 821 [30],

yes, one could argue.

> RFC2181 is helpful on this point:
> 
>  10.1.1. CNAME terminology

This is interesting for I really always thought it was the other way
around. Now I have to adjust the way I use that word in day to day
parlance.

> And yes, I'm afraid I agree with you - the spammers have indeed won.
> I regret the inconvenience.

No problem; I appreciate your time and the hole you punched for me.

-- 
 .''`.   martin f. krafft <[EMAIL PROTECTED]>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
"heuristic is computer science jargon for 'doesn't actually work.'"
 -- charlie reiman


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: Bug#445998: ITP: eaccelerator -- PHP accelerator, optimizer, and dynamic content cache

[Alexander GQ Gerasiov]

На Tue, 9 Oct 2007 15:53:36 -0400
"Roberto C. Sánchez" <[EMAIL PROTECTED]> записано:

> On Tue, Oct 09, 2007 at 09:24:14PM +0200, Tim Dijkstra wrote:
> > On Tue, 09 Oct 2007 21:29:38 +0400
> > Alexander Gerasiov <[EMAIL PROTECTED]> wrote:
> > 
> > > Package: wnpp
> > > Severity: wishlist
> > > Owner: Alexander Gerasiov <[EMAIL PROTECTED]>
> > > 
> > > * Package name: eaccelerator
> > >   Version : 0.9.5.2
> > >   Upstream Author : eaccelerator team
> > > http://eaccelerator.net/wiki/Team
> > > * URL : http://eaccelerator.net
> > > * License : GPL
> > >   Programming Lang: C
> > >   Description : PHP accelerator, optimizer, and dynamic
> > > content cache
> > 
> > > Some dummy packages available for now in my repository at
> > > http://gq.net.ru/debian
> > >
> > > I'm going to upload it after fixing some packaging issues. Feel
> > > free to kick me by mail, if I'm too slow.
> > 
> > Are the license issues finally solved then? Last time I checked
> > binaries were not distributable, see for example:
> > 
> > http://www.mailarchives.org/list/debian-devel/msg/2005/08164
> > 
> > grts Tim
> 
> Also, in one of the many discussions about this piece of software it
> came out that original author of turck-mmcache (the software on which
> eaccelerator is based) now works for Zend.  Zend produces a
> proprietary (and expensive) accelerator-sort of product for PHP.  It
> is doubtful that they would enable the distribution of something that
> they would see as competing with their product.
> 
> I seem to recall that the people who took over eaccelerator had it in
> mind to do a complete rewrite of the eccalerator code to break any
> link with turck-mmcache, allowing them to relicense eaccelerator.  If
> that rewrite is complete, then the software may be distributable.
> However, I have not looked into it for quite a while.

OMG! That's why it's still unavailable in Debian =\ I didn't knew
about PHP Licence incompatibility with GPL before.

So what do you guys think about wrapper package, which allows installing
eaccelerator like 
$ make-eaccelerator-package
?

As I understand all this legal issues it will be ok.

-- 
Best regards,
 Alexander GQ Gerasiov

 Contacts:
 e-mail: [EMAIL PROTECTED]
 Homepage: http://gq.net.ru

Re: RFC 2?821 and CNAMEs

[Russ Allbery]

martin f krafft <[EMAIL PROTECTED]> writes:

> RFC 2821 obsoletes STD-10, and says:

> 3.6 Domains

>Only resolvable, fully-qualified, domain names (FQDNs) are permitted
>when domain names are used in SMTP.  In other words, names that can
>be resolved to MX RRs or A RRs (as discussed in section 5) are
>permitted, as are CNAME RRs whose targets can be resolved, in turn,
>   
>to MX or A RRs.
>^^^

> Though I guess it gets interesting when we start to look at the
> meaning of "obsoletes":

As someone who was on the RFC 2821 working group and vaguely remembers
this, I seem to recall that this was one of those cases where everyone was
already doing this and it didn't cause interoperability problems, so RFC
2821 backed off the strength of the requirement.

Note, though, that STD-10 is a Standard whereas RFC 2821 is still only a
Proposed Standard.  IIRC, formally the obsolete only fully applies once
RFC 2821 reaches the same level in the standards process.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: RFC 2?821 and CNAMEs

[martin f krafft]

also sprach Russ Allbery <[EMAIL PROTECTED]> [2007.10.09.2243 +0100]:
> Note, though, that STD-10 is a Standard whereas RFC 2821 is still
> only a Proposed Standard.  IIRC, formally the obsolete only fully
> applies once RFC 2821 reaches the same level in the standards
> process.

Does that mean I ought to be changing my DNS setup?

-- 
 .''`.   martin f. krafft <[EMAIL PROTECTED]>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
if you are walking on thin ice, you might as well dance!


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: Bug#445866: ITP: perforce -- closed source revision control system

[Steinar H. Gunderson]

On Mon, Oct 08, 2007 at 03:41:21PM -0400, Roberto C. Sánchez wrote:
> Given the great abundance of revision control systems already packaged
> for Debian, what is the point of adding another?

I don't see the relevance of this argument, really, but if you really think
it's a problem: What if someone needed to access an existing Perforce
repository?

/* Steinar */
-- 
Homepage: http://www.sesse.net/


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

Re: Bug#445866: ITP: perforce -- closed source revision control system

[Roberto C . Sánchez]

On Mon, Oct 08, 2007 at 11:15:38PM +0200, Steinar H. Gunderson wrote:
> On Mon, Oct 08, 2007 at 03:41:21PM -0400, Roberto C. Sánchez wrote:
> > Given the great abundance of revision control systems already packaged
> > for Debian, what is the point of adding another?
> 
> I don't see the relevance of this argument, really, but if you really think
> it's a problem: What if someone needed to access an existing Perforce
> repository?
> 
I did not realize that this was only for the client.

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: RFC 2?821 and CNAMEs

[Russ Allbery]

martin f krafft <[EMAIL PROTECTED]> writes:
> also sprach Russ Allbery <[EMAIL PROTECTED]> [2007.10.09.2243 +0100]:

>> Note, though, that STD-10 is a Standard whereas RFC 2821 is still
>> only a Proposed Standard.  IIRC, formally the obsolete only fully
>> applies once RFC 2821 reaches the same level in the standards
>> process.

> Does that mean I ought to be changing my DNS setup?

The only thing RFC 821 cares about is what hostnames you use in MAIL FROM
and RCPT TO.  If you can ensure that your mail setup uses the canonical
name rather than the alias in the RHS of addresses in MAIL FROM, that will
make the problem go away without changing your DNS.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Bug#446030: RFA: kbd -- Linux console font and keytable utilities

[Anton Zinoviev]

Package: wnpp
Severity: normal

[Please add me to your CC list.]

I request an adopter for the "kbd" package.

Actually it was never my intention to maintain "kbd", but its
maintainer was the group "Console utilities maintainers" and it seems
currently I am the only member of this group... :)

Here are the reasons why I am unable to maintain "kbd" properly and
why a new maintainer is wanted:

  1. I have absolutely no experience in compiling utilities like the
 utilities in "kbd".  I am not sure I will be able to fix
 any compilation errors if such errors occur.

  2. While I have some experience in the script part of the package, I
 can not effectively watch these scripts because their effect is
 canceled by the scripts in the package console-setup (which I
 maintain).

  3. (This is not a kbd-related problem.)  Recently I am unable to
 process the email messages I receive as promptly, as a Debian
 maintainer should do.

I think the package is currently in a more or less clean state.  I
haven't fixed #443645 and #443606 because I think the new maintainer
should decide what should be done (these bugs are easy to fix but they
allow two alternative solutions).  There are patches in BTS about
#190385, #190386 and may be #190387 but I haven't tried to fix things
I don't understand.  As of #399531, in BTS there is a suggestion how
to fix.  And the only bug without a solution in BTS is #437248.

Anton Zinoviev



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

Bug#446030: RFA: kbd -- Linux console font and keytable utilities

[Kurt Roeckx]

On Wed, Oct 10, 2007 at 02:10:37AM +0300, Anton Zinoviev wrote:
> Package: wnpp
> Severity: normal
> 
> [Please add me to your CC list.]
> 
> I request an adopter for the "kbd" package.
> 
> Actually it was never my intention to maintain "kbd", but its
> maintainer was the group "Console utilities maintainers" and it seems
> currently I am the only member of this group... :)

Is there a reason to still keep kbd around?  Is there something in
kbd that console-tools doesn't do?


Kurt




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

Re: seeking: Ian Jackson

[Jörg Sommer]

Hello martin,

martin f krafft <[EMAIL PROTECTED]> wrote:
> also sprach Martin Zobel-Helas <[EMAIL PROTECTED]> [2007.10.09.2026 +0100]:
>> how about sending mails from master.debian.org with either
>> [EMAIL PROTECTED] or [EMAIL PROTECTED] :)
>
> I couldn't sign those messages.

Give mutt a new sendmail:
set sendmail="/usr/bin/ssh debian /usr/sbin/sendmail -oem -oi"

Bye, Jörg.
-- 
Real programmers don't comment their code.  It was hard to write,
it should be hard to understand.


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

Re: RFC 2?821 and CNAMEs

[martin f krafft]

also sprach Russ Allbery <[EMAIL PROTECTED]> [2007.10.10.0024 +0100]:
> The only thing RFC 821 cares about is what hostnames you use in
> MAIL FROM and RCPT TO.  If you can ensure that your mail setup
> uses the canonical name rather than the alias in the RHS of
> addresses in MAIL FROM, that will make the problem go away without
> changing your DNS.

Of course I can ensure that, and that's what I had a while ago: for
each of my road-warriors (rw.madduck.net; 19 of them; no, not all
laptops; long story), I had a separate pair of MX RRs.

I sought to simplify that and created rw.madduck.net with two MX RRs
and CNAMEd the 19 domain names to that, *after* reading the RFCs and
determining that it was okay (but reading RFC2821 as having
obsoleted STD-010; your argument makes sense though).

I'd much rather change my DNS than configure the 19 machines to use
the same mail-from-domain. Thanks for this thread, which showed me
that apparently this is what I have to do.

I can't believe DNS (or SMTP for that matter) hasn't moved along in
decades... at least not since people started to understand that data
redundancy (not caching!) is a bad thing.

Sorry for the noise on d-devel.

-- 
 .''`.   martin f. krafft <[EMAIL PROTECTED]>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
"the only difference between the saint and the sinner
 is that every saint has a past and every sinner has a future."
-- oscar wilde


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Photo Contest Results of Sep. and Topic of Oct.

[www.PhotoClub.uni.cc]

*** Final results for competition of September 2007 ***

http://kodakchallenge.110mb.com/forum/index.php?topic=1177.0

*** October Competition Topic *** {Movement and action}

http://kodakchallenge.110mb.com/forum/index.php?topic=1183.0

If you would like to join us follow this link:

http://kodakchallenge.110mb.com/forum/index.php?action=register;inviter=1

Regards,
The www.PhotoClub.uni.cc Team.

http://kodakchallenge.110mb.com/forum/

Bug#446028: ITP: tg3dfsg -- firmware free Broadcom Tigon3 network driver

[Robert Edmonds]

Package: wnpp
Owner: "Robert S. Edmonds" <[EMAIL PROTECTED]>
Severity: wishlist

* Package name: tg3dfsg
  Version : 3.81
  Upstream Author : Various
* URL : http://people.debian.org/~edmonds/tg3dfsg/
* License : GPLv2
  Programming Lang: C
  Description : firmware free Broadcom Tigon3 network driver

 This package provides the source code for the tg3dfsg kernel
 module.  Kernel source or headers are required to compile this module.

This driver complies with GR 2006-004 and should support all Tigon3
hardware except for 5701a0 chipsets.  I intend to upload it should
linux kernel images be uploaded which lack the tg3 driver.

-- 
Robert Edmonds
[EMAIL PROTECTED]


signature.asc
Description: Digital signature

Re: Bug#446028: ITP: tg3dfsg -- firmware free Broadcom Tigon3 network driver

[Faidon Liambotis]

Robert Edmonds wrote:
>  This package provides the source code for the tg3dfsg kernel
>  module.  Kernel source or headers are required to compile this module.
> 
> This driver complies with GR 2006-004 and should support all Tigon3
> hardware except for 5701a0 chipsets.  I intend to upload it should
> linux kernel images be uploaded which lack the tg3 driver.
This doesn't sound good.

Any reason why your 5701a0-removal patch can't be applied to our kernel
packages?
Or even better, why the driver can't be converted to use
request_firmware() instead of embedding the firmware to the source?

Regards,
Faidon


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

Re: RFC 2?821 and CNAMEs

[Russ Allbery]

martin f krafft <[EMAIL PROTECTED]> writes:

> I can't believe DNS (or SMTP for that matter) hasn't moved along in
> decades... at least not since people started to understand that data
> redundancy (not caching!) is a bad thing.

Yeah, both DNS and SMTP basically froze in stone a while back, and except
for the stuff that can be done with new RRs in DNS or extensions in SMTP,
really nothing changes.  Too much code out there that will break if any
little thing is different.  There are advantages to having a mature
standard, but it means that we get to live with all the mistakes and
marginal decisions forever and one ends up just memorizing them.

This is particularly bad in the area of SMTP because it's hard enough to
write a fully compliant to every last detail SMTP agent that it's a great
way of catching spamware, which is often written by incompetent
programmers or in a huge hurry.  So it's become quite popular to enforce
every little detail of the SMTP standard, no matter how obscure, because
the main Unix MTAs follow the standard in great detail and every new thing
that you can find rejects a bunch of spam.

For example, Stanford University rejects 80% (!!) of our incoming mail
just by requiring an RFC-2821-compliant HELO.

> Sorry for the noise on d-devel.

It's a little off-topic, but it's obscure enough stuff that affects enough
people that I think it's nice to repeat it periodically.  I end up
answering a ton of questions like this in my day job.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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