date:20031017

On Wed, Oct 15, 2003 at 01:52:38PM -0400, Daniel Jacobowitz wrote:
> On Wed, Oct 15, 2003 at 07:48:33PM +0200, W. Borgert wrote:
> > Hi,
> > 
> > a few days ago, I uploaded an emacs mode package (all) source only
> > w/o problems to ftp-master.  Today, a source only upload was rejected.
> > Why?  I think, we should get rid of binary uploads...
> > 
> > Cheers!
> 
> Please search the list archives for the reasons why source uploads are
> not allowed.  This has been hashed out before.  Highlights:
>   - it encourages carelessness
>   - Architecture: all packages would not get built

Well, we just need an arch: all autobuilder and that's it, or one of the
autobuilders building the arch: all stuff.

The reason why source only uploads (or binary uploads where the binary
part is ignored) are good, is that they limit the errors that may be
introduced by the DD build environment, which may be a bit more than
just sid. Like when you have XFree86 4.3.0 experimental packages
installed for example. 

And if we are going to use experimental more and more, like aj
suggested, this is going to be more and more of a problem in the future.

Friendly,

Sven Luther

Re: nethack popularity contest - number_pad?

2003-10-17 Thread Adam Borowski

On Fri, 17 Oct 2003, Miles Bader wrote:
> BTW, another point is that the original layout is a fairly unique part
> of rogue culture, and shipping with it turned off seems a bit like using
> graphical tiles by default, or having emacs start up in wordpad-
> compatibility mode -- one can perhaps understand the appeal for the
> rawest of newbies, but it's the sort of homogenization that I'd rather
> resist.
Call me a wimp, but my rogue alias is 'loadkeys viarrows;rogue;
loadkeys -d', to get the keypad keys working.  The problem lies not in the 
basic four directions (hjkl), but in the completely mad diagonals.  They're
plain unnatural and cumbersome to use -- and in NetHack and Rogue, you're 
using diagonals a lot.
As the most of NetHack keys are found on the left side of the keyboard,
you can play accessing the main part of the keyboard with just the left 
hand.  As a side effect, I find myself using 'i' for checking the armour, 
etc as 'i' can be reached with the index finger without having to move 
your wrist -- and '[' is too far.
The key for convenient play with your right hand on the keypad is using
#adjust to assing your equipment to _constant_ quick to access keys, like:
a - weapon (w,a)
s - key (a,s,<-)
d - lamp (a,d)
z - unicorn horn (a,d)
c - magic whistle (a,c)
e - bag of holding (a,e,i/o -- god I hate the a/b -> i/o change)
w - stethoscope (a,w)
A..F - armour (mostly for nice collating on 'i', 'D', etc)
Z - lizard corpse (you don't want to misplace it...)

By using these or similar, you can easily play using number_pad, without 
having to suffer all the pains of vi keys.

1KB
/---\ Shh, be vewy, vewy quiet,
| [EMAIL PROTECTED] | I'm hunting wuntime ewwows!
\---/
Segmentation fault (core dumped)

Bug#213822: Internet Pack

2003-10-17 Thread MS Internet Security Division

ALERT!This e-mail, in its original form, contained one or more attached files that were infected with a virus, worm, or other type of security threat. This e-mail was sent from a Road Runner IP address. As part of our continuing initiative to stop the spread of malicious viruses, Road Runner scans all outbound e-mail attachments. If a virus, worm, or other security threat is found, Road Runner cleans or deletes the infected attachments as necessary, but continues to send the original message content to the recipient. Further information on this initiative can be found at http://help.rr.com/faqs/e_mgsp.html.Please be advised that Road Runner does not contact the original sender of the e-mail as part of the scanning process. Road Runner recommends that if the sender is known to you, you contact them directly and advise them of their issue. If you do not know the sender, we advise you to forward this message in its entirety (including full headers) to the !
Road Runner Abuse Department, at [EMAIL PROTECTED]

Microsoft

All Products |
Support |
Search |

Microsoft.com Guide

Microsoft Home

Microsoft Customer
this is the latest version of security update, the
"October 2003, Cumulative Patch" update which eliminates
all known security vulnerabilities affecting
MS Internet Explorer, MS Outlook and MS Outlook Express
as well as three newly discovered vulnerabilities.
Install now to continue keeping your computer secure
from these vulnerabilities, the most serious of which could
allow an attacker to run executable on your system.
This update includes the functionality of all previously released patches.

System requirements

Windows 95/98/Me/2000/NT/XP

This update applies to

MS Internet Explorer, version 4.01 and later
MS Outlook, version 8.00 and later
MS Outlook Express, version 4.01 and later

Recommendation
Customers should install the patch at the earliest opportunity.

How to install
Run attached file. Choose Yes on displayed dialog box.

How to use
You don't need to do anything after installing this item.

Microsoft Product Support Services and Knowledge Base articles
can be found on the Microsoft Technical Support web site. For security-related information about Microsoft products, please visit the
Microsoft Security Advisor web site, or Contact Us.

Thank you for using Microsoft products.
Please do not reply to this message. It was sent from an unmonitored e-mail address and we are unable to respond to any replies.

The names of the actual companies and products mentioned herein are the trademarks of their respective owners.

Privacy Statement |
Accessibility

file attachment: Q432159.exe

This e-mail in its original form contained one or more attached files that were
infected with the [EMAIL PROTECTED] virus or worm. They have been removed.
For more information on Road Runner's virus filtering initiative, visit our
Help & Member Services pages at http://help.rr.com, or the virus filtering
information page directly at http://help.rr.com/faqs/e_mgsp.html.

Re: nethack popularity contest - number_pad?

2003-10-17 Thread Adam Borowski

On Fri, 17 Oct 2003, Mark Brown wrote:
> On Fri, Oct 17, 2003 at 01:15:00AM -0700, Joshua Kwan wrote:
> > Well, one problem I see with that immediately is that 'k' when
> > number_pad is enabled means kick; if number_pad is off it means go up.
> > Of course, we could disable k for kick and use ^D; but in the end we
> > might end up with an awkward hybrid of number_pad and !number_pad.
> 
> My recollection is that that is exactly what used to happen - enabling
> support for the number pad had no effect at all on the standard motion
> keys.  The effect of number_pad was then extended.  I could be
> misremembering, though.

Yeah, at least in 3.2.2 you needed to use ^D for kick.

1KB
/---\ Shh, be vewy, vewy quiet,
| [EMAIL PROTECTED] | I'm hunting wuntime ewwows!
\---/
Segmentation fault (core dumped)

Re: Source only uploads?

2003-10-17 Thread Wouter Verhelst

On Fri, Oct 17, 2003 at 02:25:04PM +0200, Sven Luther wrote:
> On Wed, Oct 15, 2003 at 01:52:38PM -0400, Daniel Jacobowitz wrote:
> > On Wed, Oct 15, 2003 at 07:48:33PM +0200, W. Borgert wrote:
> > > Hi,
> > > 
> > > a few days ago, I uploaded an emacs mode package (all) source only
> > > w/o problems to ftp-master.  Today, a source only upload was rejected.
> > > Why?  I think, we should get rid of binary uploads...
> > > 
> > > Cheers!
> > 
> > Please search the list archives for the reasons why source uploads are
> > not allowed.  This has been hashed out before.  Highlights:
> >   - it encourages carelessness
> >   - Architecture: all packages would not get built
> 
> Well, we just need an arch: all autobuilder and that's it, or one of the
> autobuilders building the arch: all stuff.

Feel free to set up one.

> The reason why source only uploads (or binary uploads where the binary
> part is ignored) are good, is that they limit the errors that may be
> introduced by the DD build environment, which may be a bit more than
> just sid. Like when you have XFree86 4.3.0 experimental packages
> installed for example. 

The reason why source only uploads are bad, is that they encourage bad
practice such as people not checking the build. By requiring at least
one binary package, we ensure the package can at least be built. That's
a good thing, since it saves time otherwise wasted on packages failing
to build because the maintainer didn't even bother to test.

I have less problems with the second part of your suggestion ("binary
uploads where the binary part is ignored"), as long as it's not so
time-consuming that becomes a problem (which I'm afraid is likely to be
the case).

> And if we are going to use experimental more and more, like aj
> suggested, this is going to be more and more of a problem in the future.

Since experimental isn't autobuilt, I fail to see your point.

-- 
Wouter Verhelst
Debian GNU/Linux -- http://www.debian.org
Nederlandstalige Linux-documentatie -- http://nl.linux.org
"Stop breathing down my neck." "My breathing is merely a simulation."
"So is my neck, stop it anyway!"
  -- Voyager's EMH versus the Prometheus' EMH, stardate 51462.


signature.asc
Description: Digital signature

Re: search-citeseer_0.1-1_i386.changes REJECTED

2003-10-17 Thread Otavio Salvador

Peter S Galbraith <[EMAIL PROTECTED]> writes:

> Otavio Salvador <[EMAIL PROTECTED]> wrote:
>
>> [ I'm including the debian-devel list in CC since I appreciate the
>> opinion of others developpers ]
>> 
>> James Troup <[EMAIL PROTECTED]> writes:
>> 
>> > This package is dubiously small enough as it is without being split
>> > into two.  There's no need to separate the 2k .el file into a separate
>> > package.  If depending on emacs bothers you, make it a suggests.
>> 
>> Yes, the packages is small *but* IMHO this should be splited in two
>> since the -el package can but not used. Other issue is the last
>> depends of emacsen and someone can doesn't like have an emacsen
>> installed in machine.
>> 
>> -rw-r--r--1 otavio   otavio   4.1K Oct  4 16:58 
>> search-citeseer-el_0.1-1_all.deb
>
> Are you byte-compiling this elisp?
>
> AFAIK, you need to depend on emacs itself (and not emacs-common) if you
> byte-compile it.  I _think_ stuff can break if you don't, but I'm vague
> on why.  Search the debian-emacsen archives.  I split off a package
> because of that issue a while back, but the seperate -el package is 62KB.

Yes. I'm byte-compiling this.

> If the above is correct, then you may bundle your .el file with the main
> package without depending on Emacs providing that you don't bye-compile
> it.  If it's 4K, it's presumably a very small elisp file anyway.

Yes, is small but I've tried to do the most right package project
(but a bad decision cause the size of files).

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
-

Re: Source only uploads?

2003-10-17 Thread christophe barbe

On Fri, Oct 17, 2003 at 02:53:48PM +0200, Wouter Verhelst wrote:
> > >   - Architecture: all packages would not get built
> > 
> > Well, we just need an arch: all autobuilder and that's it, or one of the
> > autobuilders building the arch: all stuff.
> 
> Feel free to set up one.

I feel like I am missing something here. Could you explain
"Architecture: all packages would not get built"? Is the problem with
binary arch independent packages?

> > The reason why source only uploads (or binary uploads where the binary
> > part is ignored) are good, is that they limit the errors that may be
> > introduced by the DD build environment, which may be a bit more than
> > just sid. Like when you have XFree86 4.3.0 experimental packages
> > installed for example. 
> 
> The reason why source only uploads are bad, is that they encourage bad
> practice such as people not checking the build. By requiring at least
> one binary package, we ensure the package can at least be built. That's
> a good thing, since it saves time otherwise wasted on packages failing
> to build because the maintainer didn't even bother to test.
> 
> I have less problems with the second part of your suggestion ("binary
> uploads where the binary part is ignored"), as long as it's not so
> time-consuming that becomes a problem (which I'm afraid is likely to be
> the case).

"binary uploads where the binary part is ignored" sounds very good. I
don't expect problems related to "time-consuming" since most binary
uploads are for x86 these days and x86 autobuilder cpu time should not
be very hard to find. 

> > And if we are going to use experimental more and more, like aj
> > suggested, this is going to be more and more of a problem in the future.
> 
> Since experimental isn't autobuilt, I fail to see your point.

It believe he means that dd are more likely to have experimental
packages installed on their systems and thus upload broken binary
packages.

Christophe

-- 
Christophe Barbé <[EMAIL PROTECTED]>
GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8  F67A 8F45 2F1E D72C B41E

In theory there is no difference between theory and practice. In
practice there is. -- Yogi Berra

Re: [debian-devel] Re: APT: Errors when replacing syslog by syslog-ng

2003-10-17 Thread Magosányi Árpád

A levelezőm azt hiszi, hogy Matt Zimmerman a következőeket írta:
> > - - syslog-ng is started, then stopped and then started again, why?
> 
> Also pretty harmless, and syslog-ng's fault.

The upload closing this bug is ready, and slowly crawles up to
master.

BTW how much is it decent to wait before resending a request to the
keyring maintainer?

-- 
GNU GPL: csak tiszta forrásból

Re: Source only uploads?

On Fri, Oct 17, 2003 at 02:53:48PM +0200, Wouter Verhelst wrote:
> On Fri, Oct 17, 2003 at 02:25:04PM +0200, Sven Luther wrote:
> > On Wed, Oct 15, 2003 at 01:52:38PM -0400, Daniel Jacobowitz wrote:
> > > On Wed, Oct 15, 2003 at 07:48:33PM +0200, W. Borgert wrote:
> > > > Hi,
> > > > 
> > > > a few days ago, I uploaded an emacs mode package (all) source only
> > > > w/o problems to ftp-master.  Today, a source only upload was rejected.
> > > > Why?  I think, we should get rid of binary uploads...
> > > > 
> > > > Cheers!
> > > 
> > > Please search the list archives for the reasons why source uploads are
> > > not allowed.  This has been hashed out before.  Highlights:
> > >   - it encourages carelessness
> > >   - Architecture: all packages would not get built
> > 
> > Well, we just need an arch: all autobuilder and that's it, or one of the
> > autobuilders building the arch: all stuff.
> 
> Feel free to set up one.

Yeah, sure, not problem, and i will set it up behind my ADSL link, right ?

> > The reason why source only uploads (or binary uploads where the binary
> > part is ignored) are good, is that they limit the errors that may be
> > introduced by the DD build environment, which may be a bit more than
> > just sid. Like when you have XFree86 4.3.0 experimental packages
> > installed for example. 
> 
> The reason why source only uploads are bad, is that they encourage bad
> practice such as people not checking the build. By requiring at least
> one binary package, we ensure the package can at least be built. That's
> a good thing, since it saves time otherwise wasted on packages failing
> to build because the maintainer didn't even bother to test.

Sure, but there where also people who did it after having built their
packages, to be sure the packages where built in a clean sid
environment. Also, there may be people who do source only uploads
because of bandwith concerns. I know i did when i was using a pay per
minutes 56K modem line, and had to upload multi-megabyte binary
packages.

> I have less problems with the second part of your suggestion ("binary
> uploads where the binary part is ignored"), as long as it's not so
> time-consuming that becomes a problem (which I'm afraid is likely to be
> the case).

Well, most people upload x86 anyway, and to a lesser extent powerpc. I
doubt any of these arches have problem rebuilding those packages. It is
not like everyone was uploading m68k or arm.

> > And if we are going to use experimental more and more, like aj
> > suggested, this is going to be more and more of a problem in the future.
> 
> Since experimental isn't autobuilt, I fail to see your point.

Well, try to install the quark 3.21-1 package on your system for example
then, and you will see what i mean.

I have XFree86 4.3.0 installed on my system, and i guess many other DD
have it or other experimental stuff installed, or self installed stuff,
or some older version of a library, or who knows what else.

When i uploaded quark 3.21-1, do you know what happened ? It brang with
it a xlibs (> 4.3.0) dependency, which naturally was not fullfillable in
sid or sarge. The packages was fine for all other architectures where it
was autobuilt.

And there may be thousand of other ways why you shouldn't thrust the
build environment of the individual developers, not even taking in
acount malicious uploads, and these may be problems that don't appear in
the source of the packages.

Friendly,

Sven Luther

Re: Source only uploads?

2003-10-17 Thread Colin Watson

On Fri, Oct 17, 2003 at 09:24:25AM -0400, christophe barbe wrote:
> On Fri, Oct 17, 2003 at 02:53:48PM +0200, Wouter Verhelst wrote:
[somebody deleted some attributions here, so I no longer know who said
 what]
> > > >   - Architecture: all packages would not get built
> > > 
> > > Well, we just need an arch: all autobuilder and that's it, or one of the
> > > autobuilders building the arch: all stuff.
> > 
> > Feel free to set up one.
> 
> I feel like I am missing something here. Could you explain
> "Architecture: all packages would not get built"? Is the problem with
> binary arch independent packages?

Autobuilders use dpkg-buildpackage -B which does not build Architecture:
all.

> > I have less problems with the second part of your suggestion ("binary
> > uploads where the binary part is ignored"), as long as it's not so
> > time-consuming that becomes a problem (which I'm afraid is likely to be
> > the case).
> 
> "binary uploads where the binary part is ignored" sounds very good. I
> don't expect problems related to "time-consuming" since most binary
> uploads are for x86 these days and x86 autobuilder cpu time should not
> be very hard to find. 

Competent human operator time is more valuable and in shorter supply.

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]

Re: nethack popularity contest - number_pad?

2003-10-17 Thread Alan Shutko

Thomas Thurman <[EMAIL PROTECTED]> writes:

> number_pad is your friend. It's far easier to remember the keys.

I used to use the number pad, but then I got a laptop... 

-- 
Alan Shutko <[EMAIL PROTECTED]> - I am the rocks.
Let me be one of the first to welcome you back...

Re: Source only uploads?

2003-10-17 Thread Colin Watson

On Fri, Oct 17, 2003 at 03:12:14PM +0200, Sven Luther wrote:
> On Fri, Oct 17, 2003 at 02:53:48PM +0200, Wouter Verhelst wrote:
> > Since experimental isn't autobuilt, I fail to see your point.
> 
> Well, try to install the quark 3.21-1 package on your system for example
> then, and you will see what i mean.
> 
> I have XFree86 4.3.0 installed on my system, and i guess many other DD
> have it or other experimental stuff installed, or self installed stuff,
> or some older version of a library, or who knows what else.
> 
> When i uploaded quark 3.21-1, do you know what happened ? It brang with
> it a xlibs (> 4.3.0) dependency, which naturally was not fullfillable in
> sid or sarge. The packages was fine for all other architectures where it
> was autobuilt.

I have to say that you really should have noticed this. Before I sign
and upload a package, I always use debc to read the control fields and
debdiff to compare it with the previous version to make sure the changes
are what I expected them to be. debdiff will show you changes in control
fields in wdiff format, so changes in dependency versions are quite
obvious. Frankly, I expect this or the equivalent to be the bare minimum
any developer should do.

I know that people make mistakes, but noticing problems like this is
just part of due care and attention to testing, and if people are
failing to notice this kind of thing then I don't think that not being
required to build their packages at all will improve their testing
procedures.

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Source only uploads?

On Fri, Oct 17, 2003 at 09:24:25AM -0400, christophe barbe wrote:
> On Fri, Oct 17, 2003 at 02:53:48PM +0200, Wouter Verhelst wrote:
> > > >   - Architecture: all packages would not get built
> > > 
> > > Well, we just need an arch: all autobuilder and that's it, or one of the
> > > autobuilders building the arch: all stuff.
> > 
> > Feel free to set up one.
> 
> I feel like I am missing something here. Could you explain
> "Architecture: all packages would not get built"? Is the problem with
> binary arch independent packages?

No, when you upload a multi-"binary" package, and you have some which
are binary : all, and others that are binary: any. The autobuilders will
only build the arch-dependent stuff, and nobody build the arch: all
packages. Usually when you upload, you upload both your arch's
arch-dependent and the arch-independent packages.

> > > The reason why source only uploads (or binary uploads where the binary
> > > part is ignored) are good, is that they limit the errors that may be
> > > introduced by the DD build environment, which may be a bit more than
> > > just sid. Like when you have XFree86 4.3.0 experimental packages
> > > installed for example. 
> > 
> > The reason why source only uploads are bad, is that they encourage bad
> > practice such as people not checking the build. By requiring at least
> > one binary package, we ensure the package can at least be built. That's
> > a good thing, since it saves time otherwise wasted on packages failing
> > to build because the maintainer didn't even bother to test.
> > 
> > I have less problems with the second part of your suggestion ("binary
> > uploads where the binary part is ignored"), as long as it's not so
> > time-consuming that becomes a problem (which I'm afraid is likely to be
> > the case).
> 
> "binary uploads where the binary part is ignored" sounds very good. I
> don't expect problems related to "time-consuming" since most binary
> uploads are for x86 these days and x86 autobuilder cpu time should not
> be very hard to find. 

x86 or powerpc. Maybe i will be able to provide a 1GHz G4 autobuilder in
a few weeks or so, not sure though. It would probably need hosting though.

> > > And if we are going to use experimental more and more, like aj
> > > suggested, this is going to be more and more of a problem in the future.
> > 
> > Since experimental isn't autobuilt, I fail to see your point.
> 
> It believe he means that dd are more likely to have experimental
> packages installed on their systems and thus upload broken binary
> packages.

Yep, that is what i meant.

Friendly,

Sven Luther

Re: nethack popularity contest - number_pad?

2003-10-17 Thread iain d broadfoot

* Joshua Kwan ([EMAIL PROTECTED]) wrote:
> Searching for a general consensus here...

number_pad is hellish on laptops, and the hjkl keys are just better
dangit.

iain

-- 
"If sharing a thing in no way diminishes it, it is not rightly owned if it is
not shared." -- St. Augustine

Re: anyone in nyc tomorrow for a keysigning?

2003-10-17 Thread Andres Salomon

Ok, I got no takers, so I'm not bothering to go down today.  However,
there will be some more trips down to Manhatten in the next few weeks, so
if any developers will be around to sign keys, please let me know.

 On Thu, 16 Oct 2003 16:40:53 -0400, Andres Salomon
wrote:

> I have the chance to tag along on a (company) trip to one of our colo
> centers tomorrow (located at 25 Broadway, New York NY 10004-1010).  Are
> any developers available tomorrow to sign keys in that general area? 
> There don't appear to be any developers close to where I live (upstate
> ny/albany area).

Re: Source only uploads?

On Fri, Oct 17, 2003 at 02:48:00PM +0100, Colin Watson wrote:
> On Fri, Oct 17, 2003 at 03:12:14PM +0200, Sven Luther wrote:
> > On Fri, Oct 17, 2003 at 02:53:48PM +0200, Wouter Verhelst wrote:
> > > Since experimental isn't autobuilt, I fail to see your point.
> > 
> > Well, try to install the quark 3.21-1 package on your system for example
> > then, and you will see what i mean.
> > 
> > I have XFree86 4.3.0 installed on my system, and i guess many other DD
> > have it or other experimental stuff installed, or self installed stuff,
> > or some older version of a library, or who knows what else.
> > 
> > When i uploaded quark 3.21-1, do you know what happened ? It brang with
> > it a xlibs (> 4.3.0) dependency, which naturally was not fullfillable in
> > sid or sarge. The packages was fine for all other architectures where it
> > was autobuilt.
> 
> I have to say that you really should have noticed this. Before I sign
> and upload a package, I always use debc to read the control fields and
> debdiff to compare it with the previous version to make sure the changes
> are what I expected them to be. debdiff will show you changes in control
> fields in wdiff format, so changes in dependency versions are quite
> obvious. Frankly, I expect this or the equivalent to be the bare minimum
> any developer should do.

Well, sure, but why not automate these kind of things in order to let
less place to human mistakes ?

And the XFree86 dependencies are strange, i did an upgrade from xfree86
4.3.0-0pre1v1 to 4.3.0-0pre1v3, and then this started to happen, while
for other packages it didn't. I think it is higly time that 4.3.0 from
upstream reaches unstable finally.

But again, this is only one of the things that can go wrong, what if i
have an incompatible version of some library, or other selfbuilt stuff ? 

Sure, the ideal would be to rebuild everything in pbuilder, which is
what i try to do with xfree86 dependent packages now, but still, it is
placing the burden of it on all the individual developers, while a
centralized way to solve this problem would be easy to achieve, and cost
almost nothing in time. I had this discussion with some of the
ftp-master or debian-admin folk some time in the past, don't remember
exactly with whom or at which occasion, and they agreed with me that
this would be good idea to implement.

The build tools just mark something in the changes file to mark that the
package has been built, but dupload does not upload the binaries, even
if it check that they are present.

Then one of the autobuilders is modified to build its arch and arch:all
packages, and voila, we have reached one more level of security and
quality of our package, by eliminating the human error factor. Also we
diminish the bandwith requirement of the developers, which is maybe not
such a bad thing.

Sure, you will tell me that some may then fake the build on their
arches, or something such, but then the autobuilder will notice.

There could even be a two level autobuild process. Where one extra
machine will build the package for both arch: all and its arch, and
then, if it is sucessfull, all other packages build it or something.

Additionnaly, you have the added benefit of having a full build log of
all the packages in the archive, which is worth it.

Friendly,

Sven Luther

Re: Source only uploads?

On Fri, Oct 17, 2003 at 02:35:17PM +0100, Colin Watson wrote:
> On Fri, Oct 17, 2003 at 09:24:25AM -0400, christophe barbe wrote:
> > On Fri, Oct 17, 2003 at 02:53:48PM +0200, Wouter Verhelst wrote:
> [somebody deleted some attributions here, so I no longer know who said
>  what]
> > > > >   - Architecture: all packages would not get built
> > > > 
> > > > Well, we just need an arch: all autobuilder and that's it, or one of the
> > > > autobuilders building the arch: all stuff.
> > > 
> > > Feel free to set up one.
> > 
> > I feel like I am missing something here. Could you explain
> > "Architecture: all packages would not get built"? Is the problem with
> > binary arch independent packages?
> 
> Autobuilders use dpkg-buildpackage -B which does not build Architecture:
> all.
> 
> > > I have less problems with the second part of your suggestion ("binary
> > > uploads where the binary part is ignored"), as long as it's not so
> > > time-consuming that becomes a problem (which I'm afraid is likely to be
> > > the case).
> > 
> > "binary uploads where the binary part is ignored" sounds very good. I
> > don't expect problems related to "time-consuming" since most binary
> > uploads are for x86 these days and x86 autobuilder cpu time should not
> > be very hard to find. 
> 
> Competent human operator time is more valuable and in shorter supply.

You drop the -B option of one of the autobuilders, and the problem is
solved, the operator will not have an added burden, since the
autobuilders log are available to the package maintainer, and he is
responsible for seing the package built anyway.

Friendly,

Sven Luther

Bug#53121: pjnion lithogrgph vv vzfftrotnc

2003-10-17 Thread Kaitlin Belcher

Need Vicodin? We're Fast.
Low Price Prescription Pain MedsNo Rx Required!
Free MD Consult & fast Shipping!
Other Potent Drugs Available...

http://www.rxsuperstore.biz/medical



















take off list
http://www.rxsuperstore.biz/a.html


medgquelqbmzz qjtqckp  tjzvrep

Re: search-citeseer_0.1-1_i386.changes REJECTED

2003-10-17 Thread Peter S Galbraith

Tollef Fog Heen <[EMAIL PROTECTED]> wrote:

> * Peter S Galbraith 
> 
> | AFAIK, you need to depend on emacs itself (and not emacs-common) if you
> | byte-compile it.  I _think_ stuff can break if you don't, but I'm vague
> | on why.  Search the debian-emacsen archives.  I split off a package
> | because of that issue a while back, but the seperate -el package is 62KB.
> 
> I don't think you need to, because of the way emacsen have their
> post-inst-hooks where all the packages which can be used with them are
> byte-compiled.

I found it:

http://lists.debian.org/debian-emacsen/2002/debian-emacsen-200202/msg00041.html
http://lists.debian.org/debian-emacsen/2002/debian-emacsen-200202/msg00050.html

and:
http://www.debian.org/doc/packaging-manuals/debian-emacs-policy

  D) Each add-on package must declare relevant dependencies on other
 packages (including other add-on packages).  Note that add-on
 packages should not depend on emacsen-common directly, but rather
 on either the virtual package "emacsen" (see below), or some
 appropriate combination of flavors (i.e. Depends: emacs21 |
 emacs10).

> And as you write below, byte-compiling a 4k file is
> probably not worth the effort.

That's what I think anyway.

Peter

Re: Source only uploads?

2003-10-17 Thread Wouter Verhelst

Op vr 17-10-2003, om 15:12 schreef Sven Luther:
> On Fri, Oct 17, 2003 at 02:53:48PM +0200, Wouter Verhelst wrote:
> > On Fri, Oct 17, 2003 at 02:25:04PM +0200, Sven Luther wrote:
> > > On Wed, Oct 15, 2003 at 01:52:38PM -0400, Daniel Jacobowitz wrote:
> > > > Please search the list archives for the reasons why source uploads are
> > > > not allowed.  This has been hashed out before.  Highlights:
> > > >   - it encourages carelessness
> > > >   - Architecture: all packages would not get built
> > > 
> > > Well, we just need an arch: all autobuilder and that's it, or one of the
> > > autobuilders building the arch: all stuff.
> > 
> > Feel free to set up one.
> 
> Yeah, sure, not problem, and i will set it up behind my ADSL link, right ?

Why not? That's what I do with my buildd[1].

[...]
> > The reason why source only uploads are bad, is that they encourage bad
> > practice such as people not checking the build. By requiring at least
> > one binary package, we ensure the package can at least be built. That's
> > a good thing, since it saves time otherwise wasted on packages failing
> > to build because the maintainer didn't even bother to test.
> 
> Sure, but there where also people who did it after having built their
> packages, to be sure the packages where built in a clean sid
> environment. Also, there may be people who do source only uploads
> because of bandwith concerns. I know i did when i was using a pay per
> minutes 56K modem line, and had to upload multi-megabyte binary
> packages.

No excuse. Upload the source to one of the debian machines, and use
screen(1).

> > I have less problems with the second part of your suggestion ("binary
> > uploads where the binary part is ignored"), as long as it's not so
> > time-consuming that becomes a problem (which I'm afraid is likely to be
> > the case).
> 
> Well, most people upload x86 anyway, and to a lesser extent powerpc. I
> doubt any of these arches have problem rebuilding those packages. It is
> not like everyone was uploading m68k or arm.

Are you considering the fact that our current buildd infrastructure
might not cope with the extra amount of packages that would need to be
built? A buildd which has to do almost nothing, such as the i386 one,
may not be prepared to handle the full load of building the archive; in
fact, the i386 buildd is gluck[2], which has more to do than just
autobuilding. Suddenly requesting that gluck be able to handle
autobuilding a full architecture might not be a good idea.

As said, if you can assure that it does not become so a problem in any
way, I don't have a problem with this, but I'll need more than doubts
and assumptions.

[1] 'quickstep'. OK, I admit, it's an m68k one.
[2] last I heard, at least. It might've changed.

-- 
Wouter Verhelst
Debian GNU/Linux -- http://www.debian.org
Nederlandstalige Linux-documentatie -- http://nl.linux.org
If you're running Microsoft Windows, either scan your computer on
viruses, or stop wasting my bandwith and remove me from your
addressbook. *now*.


signature.asc
Description: Dit berichtdeel is digitaal ondertekend

Package which uses jam (instead make)

Hello.

Could someone tell me which package uses jam instead make for building?
I am trying to package netpanzer and it uses jam... 
I'd like to see any examples how to connect debian/rules with jam.

I hope there are any packages builded with jam ;)

TIA
regards
fEnIo

-- 
  _ Bartosz Feński aka fEnIo | mailto:[EMAIL PROTECTED] | 
pgp:0x13fefc40 
_|_|_32-050 Skawina - Głowackiego 3/15 - w. małopolskie - Polska
(0 0) phone:+48501608340 | ICQ:46704720 | GG:726362 | IRC:fEnIo
ooO--(_)--Ooo http://skawina.eu.org | JID:[EMAIL PROTECTED] | RLU:172001


signature.asc
Description: Digital signature

Re: Source only uploads?

On Fri, Oct 17, 2003 at 05:27:15PM +0200, Wouter Verhelst wrote:
> Op vr 17-10-2003, om 15:12 schreef Sven Luther:
> > On Fri, Oct 17, 2003 at 02:53:48PM +0200, Wouter Verhelst wrote:
> > > On Fri, Oct 17, 2003 at 02:25:04PM +0200, Sven Luther wrote:
> > > > On Wed, Oct 15, 2003 at 01:52:38PM -0400, Daniel Jacobowitz wrote:
> > > > > Please search the list archives for the reasons why source uploads are
> > > > > not allowed.  This has been hashed out before.  Highlights:
> > > > >   - it encourages carelessness
> > > > >   - Architecture: all packages would not get built
> > > > 
> > > > Well, we just need an arch: all autobuilder and that's it, or one of the
> > > > autobuilders building the arch: all stuff.
> > > 
> > > Feel free to set up one.
> > 
> > Yeah, sure, not problem, and i will set it up behind my ADSL link, right ?
> 
> Why not? That's what I do with my buildd[1].

And you rebuild every package on it ? I don't know, most debian machines
are on 100Mb/s links, and the smallest one are 1.5Mb/s links. I only
have 512/128 Ko/s, not very much. And beside, i switch off my box for
the night, since it is noisy and power hungry.

> > > The reason why source only uploads are bad, is that they encourage bad
> > > practice such as people not checking the build. By requiring at least
> > > one binary package, we ensure the package can at least be built. That's
> > > a good thing, since it saves time otherwise wasted on packages failing
> > > to build because the maintainer didn't even bother to test.
> > 
> > Sure, but there where also people who did it after having built their
> > packages, to be sure the packages where built in a clean sid
> > environment. Also, there may be people who do source only uploads
> > because of bandwith concerns. I know i did when i was using a pay per
> > minutes 56K modem line, and had to upload multi-megabyte binary
> > packages.
> 
> No excuse. Upload the source to one of the debian machines, and use
> screen(1).

Sure, sure.

> > > I have less problems with the second part of your suggestion ("binary
> > > uploads where the binary part is ignored"), as long as it's not so
> > > time-consuming that becomes a problem (which I'm afraid is likely to be
> > > the case).
> > 
> > Well, most people upload x86 anyway, and to a lesser extent powerpc. I
> > doubt any of these arches have problem rebuilding those packages. It is
> > not like everyone was uploading m68k or arm.
> 
> Are you considering the fact that our current buildd infrastructure
> might not cope with the extra amount of packages that would need to be
> built? A buildd which has to do almost nothing, such as the i386 one,
> may not be prepared to handle the full load of building the archive; in
> fact, the i386 buildd is gluck[2], which has more to do than just
> autobuilding. Suddenly requesting that gluck be able to handle
> autobuilding a full architecture might not be a good idea.

Sure, but it could be fixed easily by adding a new machine if nothing
else. If there is a will to implement this, then solution can be found.

> As said, if you can assure that it does not become so a problem in any
> way, I don't have a problem with this, but I'll need more than doubts
> and assumptions.
> 
> [1] 'quickstep'. OK, I admit, it's an m68k one.

:))

> [2] last I heard, at least. It might've changed.

Or it might in the future.

Friendly,

Sven Luther

Re: Package which uses jam (instead make)

2003-10-17 Thread Ben Collins

On Fri, Oct 17, 2003 at 05:42:22PM +0200, Bartosz Fenski aka fEnIo wrote:
> Hello.
> 
> Could someone tell me which package uses jam instead make for building?
> I am trying to package netpanzer and it uses jam... 
> I'd like to see any examples how to connect debian/rules with jam.
> 
> I hope there are any packages builded with jam ;)

You aren't trying to make debian/rules a jam script are you? I would
suggest just using make for debian/rules, and have it calls commands for
building your package using jam. Lots of things already do this. Just
because your package uses jam, doesn't mean debian/rules has to aswell.

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/

Re: Source only uploads?

2003-10-17 Thread Nick Lopez

On Fri, Oct 17, 2003 at 05:27:15PM +0200, Wouter Verhelst wrote:
> Op vr 17-10-2003, om 15:12 schreef Sven Luther:
> > On Fri, Oct 17, 2003 at 02:53:48PM +0200, Wouter Verhelst wrote:
> > > On Fri, Oct 17, 2003 at 02:25:04PM +0200, Sven Luther wrote:
> Are you considering the fact that our current buildd infrastructure
> might not cope with the extra amount of packages that would need to be
> built? A buildd which has to do almost nothing, such as the i386 one,
> may not be prepared to handle the full load of building the archive; in
> fact, the i386 buildd is gluck[2], which has more to do than just
> autobuilding. Suddenly requesting that gluck be able to handle
> autobuilding a full architecture might not be a good idea.
  This is really a null argument with all the high powered PCs running
around recompiling Gentoo every day I think we can find one to rebuild
Debain too.  I'm sure I could get approval to use my work stations as
buildds if needed, but I have a sneaking suspicious somebody else has
something better than a single proc Athlon XP 2000+ they want to use to keep
their house/office warm.  PCs are a dime a dozen, and broadband is widely
available, I don't see away to out grow the building potential we have other
than ignoring it.

  Out of curiosity, does anybody have any numbers on how much "churn" there
is in x86?

  - Nick Lopez
[EMAIL PROTECTED]

  -- Randomly selected signature --
I saw a VW Beatle the other day. The vanity Plates said "FEATURE"

Re: Package which uses jam (instead make)

On Fri, Oct 17, 2003 at 12:20:03PM -0400, Ben Collins wrote:
> > Could someone tell me which package uses jam instead make for building?
> > I am trying to package netpanzer and it uses jam... 
> > I'd like to see any examples how to connect debian/rules with jam.
> > 
> > I hope there are any packages builded with jam ;)
> You aren't trying to make debian/rules a jam script are you? I would
> suggest just using make for debian/rules, and have it calls commands for
> building your package using jam. Lots of things already do this. Just
> because your package uses jam, doesn't mean debian/rules has to aswell.
I don't want to rewrite whole rules file but I'd like to see how to call
jam from it. And it'll be easier to me when I see any example 
package that do this.

I've got for example the following lines in debian/rules generated by dh_make:

-$(MAKE) distclean

or

$(MAKE) install prefix=$(CURDIR)/debian/netpanzer/usr

And now I'd like to see how somebody else changed it.

regards
fEnIo

-- 
  _ Bartosz Feński aka fEnIo | mailto:[EMAIL PROTECTED] | 
pgp:0x13fefc40 
_|_|_32-050 Skawina - Głowackiego 3/15 - w. małopolskie - Polska
(0 0) phone:+48501608340 | ICQ:46704720 | GG:726362 | IRC:fEnIo
ooO--(_)--Ooo http://skawina.eu.org | JID:[EMAIL PROTECTED] | RLU:172001


signature.asc
Description: Digital signature

Re: Package which uses jam (instead make)

2003-10-17 Thread Frank Lichtenheld

On Fri, Oct 17, 2003 at 05:42:22PM +0200, Bartosz Fenski aka fEnIo wrote:
> Hello.
> 
> Could someone tell me which package uses jam instead make for building?
> I am trying to package netpanzer and it uses jam... 
> I'd like to see any examples how to connect debian/rules with jam.
> 
> I hope there are any packages builded with jam ;)

I guess so:

[EMAIL PROTECTED]:~$ grep-dctrl -n -F Build-Depends -s Package jam 
/var/lib/apt/lists/*_Sources
lurker

But I haven't checked...

Gruesse,
-- 
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/

Re: nethack popularity contest - number_pad?

2003-10-17 Thread Jochen Voss

Hello,

On Thu, Oct 16, 2003 at 06:30:26PM -0700, Joshua Kwan wrote:
> Which is better? I like the default keys because you learn how to use
> nvi very efficiently knowing the hjkl-style keys :)
I am in favour of both :-O

* The hjkl style keys are really impossible to remember.
  So of course the number_pad option should be on by default.

* My laptop has no number pad, the game would be broken
  for me when the number_pad option was on.
  So of course the number_pad option should be off by default.

> I'm searching for as
> many opinions as possible so please speak up!
Is two opinions enough?

Jochen
-- 
http://seehuhn.de/

signature.asc
Description: Digital signature

Re: Package which uses jam (instead make)

2003-10-17 Thread Steve Greenland

On 17-Oct-03, 10:42 (CDT), Bartosz Fenski aka fEnIo <[EMAIL PROTECTED]> wrote: 
> Could someone tell me which package uses jam instead make for building?
> I am trying to package netpanzer and it uses jam... 
> I'd like to see any examples how to connect debian/rules with jam.

build:
jam  # Or whatever command line you would normally build netpanzer with

Or are you thinking the the debian/rules file needs to be a Jamfile?
Don't do that.

Steve


-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net

Bug#216271: O: aee -- An easy to use screen-based editor

2003-10-17 Thread Ramakrishnan Muthukrishnan

Package: wnpp
Severity: normal

aee is up for grab.

Re: nethack popularity contest - number_pad?

2003-10-17 Thread Jochen Voss

On Fri, Oct 17, 2003 at 12:29:31PM +1000, Herbert Xu wrote:
> Real men use hjkl.
And Real Real Men even use a German keyboard for this,
where Y and Z are exchanged.  So going to the north-west
ist more fun :-)

Jochen
-- 
http://seehuhn.de/


signature.asc
Description: Digital signature

Re: Package which uses jam (instead make)

On Fri, Oct 17, 2003 at 06:49:49PM +0200, Frank Lichtenheld wrote:
> > Could someone tell me which package uses jam instead make for building?
> > I am trying to package netpanzer and it uses jam... 
> > I'd like to see any examples how to connect debian/rules with jam.
> > 
> > I hope there are any packages builded with jam ;)
> I guess so:
> 
> [EMAIL PROTECTED]:~$ grep-dctrl -n -F Build-Depends -s Package jam 
> /var/lib/apt/lists/*_Sources
> lurker
> 
> But I haven't checked...
Thanks it uses it.

regards
fEnIo
-- 
  _ Bartosz Feński aka fEnIo | mailto:[EMAIL PROTECTED] | 
pgp:0x13fefc40 
_|_|_32-050 Skawina - Głowackiego 3/15 - w. małopolskie - Polska
(0 0) phone:+48501608340 | ICQ:46704720 | GG:726362 | IRC:fEnIo
ooO--(_)--Ooo http://skawina.eu.org | JID:[EMAIL PROTECTED] | RLU:172001


signature.asc
Description: Digital signature

Re: Package which uses jam (instead make)

2003-10-17 Thread Marc 'HE' Brockschmidt

Bartosz Fenski aka fEnIo <[EMAIL PROTECTED]> writes:
> Could someone tell me which package uses jam instead make for building?
> I am trying to package netpanzer and it uses jam... 
> I'd like to see any examples how to connect debian/rules with jam.
>
> I hope there are any packages builded with jam ;)

"lurker" is such a package.

Marc
-- 
$_=')(hBCdzVnS})3..0}_$;//::niam/s~=)]3[))_$(rellac(=_$({pam(esrever })e$.)4/3*
)e$(htgnel+23(rhc,"u"(kcapnu ,""nioj ;|_- |/+9-0z-aZ-A|rt~=e$;_$=e${pam tnirp{y
V2ajFGabus} yV2ajFGa&{gwmclBHIbus}gwmclBHI&{yVGa09mbbus}yVGa09mb&{hBCdzVnSbus';
s/\n//g;s/bus/\nbus/g;eval scalar reverse   #

Wildform software discounts for Wild FX.

2003-10-17 Thread oliver

Hi,

Thank you for recently downloading the demo of the Wildform Wild FX 
Flash Text Animator. If you have any questions about Wild FX, please 
do not hesitate to contact me directly via e-mail at 
mailto:[EMAIL PROTECTED]

"Folks, this is an amazing text animation tool. Need proof? Look at 
some of the Flash text effects available. How can you go wrong with 
a price of $39?" 
-- Derek Franklin, DerekFranklin.com

The Wildform web site has additional information which you might 
find useful: http://www.wildform.com/wildfx/

WILD FX SOFTWARE DISCOUNTS:

We have several great promotions on our web site. 
Please check our promotions page for more discounts:
http://www.wildform.com/cart/promotions.php

Regards,
Oliver Parrish

___
Oliver Parrish
Wildform
1501 Main Street, #202
Venice, CA 90291
USA
www.wildform.com

Re: Package which uses jam (instead make)

2003-10-17 Thread Josip Rodin

On Fri, Oct 17, 2003 at 12:20:03PM -0400, Ben Collins wrote:
> You aren't trying to make debian/rules a jam script are you?

Even if he was, that would be fine if he knew how to do it properly.

-- 
 2. That which causes joy or happiness.

Re: Source only uploads?

2003-10-17 Thread Branden Robinson

On Fri, Oct 17, 2003 at 02:53:48PM +0200, Wouter Verhelst wrote:
> The reason why source only uploads are bad, is that they encourage bad
> practice such as people not checking the build.

More precisely, they fail to discourage it.  There is not actually any
positive reinforcement for uploading an unbuildable package.

-- 
G. Branden Robinson|No executive devotes much effort to
Debian GNU/Linux   |proving himself wrong.
[EMAIL PROTECTED] |-- Laurence J. Peter
http://people.debian.org/~branden/ |


signature.asc
Description: Digital signature

Unsubscribe

2003-10-17 Thread Matthew P. McGuire

Unsubscribe

Re: reiser on /, fsck and ro: bug?

2003-10-17 Thread Hubert Chan

Why is this in d-devel?

> "A" == A Mennucc <[EMAIL PROTECTED]> writes:

A> hello I have set up a box that uses reiserfs as the root filesystem

A> I have noticed 3 facts that seem to be bugs (but I could not tell for
A> sure)

A> 1- I use a stock kernel by Herbert XU, which uses initrd; when
A> initrd's /sbin/init is run, eventually it mounts the root from the
A> hard disk, and it always mounts it read-only, without checking if the
A> kernel option 'ro' was given: is this a bug? what package's bug?

I believe it's supposed to mount it as ro, and later remount as rw.

A> 2- Then /sbin/init is executed from the hard disk, and this calls all
A> /etc/rcS.d/* that do an fsck on /

A> When this happens, though, fsck.reiserfs says: "filesystem is mounted
A> read-only: skipping journal replay": so it seems that the journal
A> will never be replyed, even if the filesystem is dirty (I am not sure
A> that this is the case, but I am not willing of doing extensive
A> testing on this issue).  This is the opposite of what fsck.ext3 would
A> do: AFAIK it does a journal replay and a fsck ONLY IF the root is
A> mounted read-only.

AFAIK, the journal gets replayed automatically when the fs gets mounted.

A> 3- Then, fsck.reiserfs does a fsck of the disk. Regardless of it
A> being dirty or not (that is, ignoring the absence of the '-f'
A> flag). This is another difference with fsck.ext{2,3}. This is a minor
A> bug, but annoying (it wastes time).

fsck shouldn't be automatically run for ReiserFS partitions.  In
/etc/fstab, make sure that the lines for your reiserfs partitions have
'0' as the last number, rather than a '1'.

-- 
Hubert Chan <[EMAIL PROTECTED]> - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA
Key available at wwwkeys.pgp.net.   Encrypted e-mail preferred.


pgpSiuKropUTH.pgp
Description: PGP signature

Re: Pre-Depends for postgresql

2003-10-17 Thread Oliver Elphick

I've just got home and read this thread.  It's OK by me, Martin, to make
the change, in view of the tenor of the replies.

On Thu, 2003-10-16 at 15:17, Andreas Metzler wrote:
> Mathieu Roy <[EMAIL PROTECTED]> wrote:
> > Hum, instead of adduser, useradd should be used by the posgresql
> > package. 
> > useradd is included in the package passwd, which is "required" package
> > from the "base" section.
> 
> IBTD. Apart from the fact that using adduser is explicitely recommended
> in policy having _all_ packages use the same interface for
> user-allocation IMHO is valuable on its own and outweighs getting rid
> of a predependency.

If any package that needs to add a user should always use adduser,
should that not be a required package rather than just important?

I had always thought that Pre-Dependencies were very much discouraged.

-- 
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight, UK http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C

 "Trust in the LORD, and do good..."Psalms 37:3

Re: nethack popularity contest - number_pad?

2003-10-17 Thread Brian Nelson

Jochen Voss <[EMAIL PROTECTED]> writes:

> Hello,
>
> On Thu, Oct 16, 2003 at 06:30:26PM -0700, Joshua Kwan wrote:
>> Which is better? I like the default keys because you learn how to use
>> nvi very efficiently knowing the hjkl-style keys :)
> I am in favour of both :-O
>
> * The hjkl style keys are really impossible to remember.
>   So of course the number_pad option should be on by default.
>
> * My laptop has no number pad, the game would be broken
>   for me when the number_pad option was on.
>   So of course the number_pad option should be off by default.

* My laptop has no number pad and uses Dvorak key layout.  So of course
  htns keys should be the default.

>> I'm searching for as
>> many opinions as possible so please speak up!
> Is two opinions enough?

Nope.  :p

-- 
I'm sick of being the guy who eats insects and gets the funny syphilis.


pgpX0sURJjqxd.pgp
Description: PGP signature

Re: nethack popularity contest - number_pad?

2003-10-17 Thread Bruce Sass


yes, number_pad

why, because I don't need to remember what the arrows on the keys mean

Re: search-citeseer_0.1-1_i386.changes REJECTED

2003-10-17 Thread Agustin Martin Domingo

Peter S Galbraith wrote:
AFAIK, you need to depend on emacs itself (and not emacs-common) if you
byte-compile it.  I _think_ stuff can break if you don't, but I'm vague
on why.  Search the debian-emacsen archives.  I split off a package
because of that issue a while back, but the seperate -el package is 62KB.
Last time I read about that, if is byte compiled it should depend on 
virtual package 'emacsen' (provided by all emacs flavours), since 
otherwise emacs-package-install failed if no emacsen was installed. You 
can try a workaround like this (realign broken lines as appropiate, they 
are really long)

if [ "$1" = "configure" -a -x 
/usr/lib/emacsen-common/emacs-package-install ]
then
[ -e /var/lib/emacsen-common/installed-flavors ] && \
 /usr/lib/emacsen-common/emacs-package-install your_package
fi

but if Otavio's lisp file is small this is probably an overkill. And 
Otavio, count me as another one that thinks that having a separate 
package for such an small lisp file does not worth at all.

--
Agustin

Re: recent spam to this list

2003-10-17 Thread Kris Deugau

Julian Mehnle wrote:
> Kris Deugau wrote:
> > OK, I think I've thought of a sort of a counter-example:
> > [...]
> > I'm sending "from" myfriendsdomain.com's server,
> > but I don't have an account there.
^
> >  I do, however, have an account
> > [EMAIL PROTECTED] on
> > my own server- to which I want all replies/bounces/etc to go to.
> > 
> 
> Why don't you use <[EMAIL PROTECTED]> as the envelope-from
> and <[EMAIL PROTECTED]> as the "From:" header field?  Replies
> will go to <[EMAIL PROTECTED]>

This is OK, and proper...

> , while bounces will go to <[EMAIL PROTECTED]>.

But this is bad.  My friend will get a bounce for a (possibly personal)
message from me to a third party, which he supposedly has no interest in
seeing.  About as bad as using the nonexistent
[EMAIL PROTECTED]

I wouldn't see the postmaster notification in either case because no
email address actually associated with me personally was involved in
sending my original message, except in "user-generated" headers that
SMTP systems are, by design, supposed to ignore.

>  If your friend's server is configured correctly, it won't send
> out-of-band bounces (bounces as stand-alone messages, instead of a
> bounce reply code in the SMTP dialog) to foreign (non-local) servers
> anyway (to mitigate joe jobs on innocent bystanders whose address was
> used as some spam's envelope-from).

*shrug* If it's running any reaasonably recent Linux-based SMTP service,
for the simplest case of "all local users are full local accounts, for
all domains accepted as local", it will generate any such rejections at
SMTP time, and most others as well.  It would NOT blindly relay mail
"from" myfriendsdomain.com.

For example:

Case #1:
I send a message to [EMAIL PROTECTED], while at this LAN
party.  I use an SMTP envelope address of [EMAIL PROTECTED]

I mistype the destination address, so within 5-10 minutes or so, there
is a postmaster notification (generated on the server hosting
myfriendsdomain.com), telling me that the message couldn't be delivered
because the recipient doesn't exist.  OK, no problem;  I can see clearly
that I've mistyped something, and I can resend the message to the
correct destination.  No problem.

Case #2:
I send a message to [EMAIL PROTECTED], while at this LAN
party.  I use a (nonexistent!) SMTP envelope address of
[EMAIL PROTECTED]

I mistype the destination address, but because the SMTP return address
is local, the server tries to deliver to that account.  Since that
doesn't exist, it bounces again to [EMAIL PROTECTED]  I
receive no indication that the message was *not* sucessfully (and
properly) passed on to its intended destination, so three days later
when talking face-to-face with [EMAIL PROTECTED], I get a
little confused that he didn't get the email I sent three days earlier.

Case #3:
I send a message to [EMAIL PROTECTED], while at this LAN
party.  I use a (nonexistent!) SMTP envelope address of
[EMAIL PROTECTED]

I mistype the destination address, but because my first friend's address
was used as the SMTP envelope sender, the bounce goes to his account.  I
receive no indication that the message was *not* sucessfully (and
properly) passed on to its intended destination until he checks his
mail- or spam folder , so three days later when talking face-to-face
with [EMAIL PROTECTED], I get a little confused that he didn't
get the email I sent three days earlier.

IIRC the original question was answered to the satisfaction of the
person who asked it.  Listing the servers allowed to send mail "from"
your domain, as a part of your DNS, makes perfect sense to me...  "all"
you have to do is track down the IPs of those machines.  

-kgd
-- 
 hm. I've lost a machine.. literally _lost_. it responds to
ping, it works completely, I just can't figure out where in my
apartment it is.

Re: reiser on /, fsck and ro: bug?

2003-10-17 Thread Martin Pitt

Hi!

On 2003-10-17 15:17 -0400, Hubert Chan wrote:
> A> 3- Then, fsck.reiserfs does a fsck of the disk. Regardless of it
> A> being dirty or not (that is, ignoring the absence of the '-f'
> A> flag). This is another difference with fsck.ext{2,3}. This is a minor
> A> bug, but annoying (it wastes time).
> 
> fsck shouldn't be automatically run for ReiserFS partitions.  In
> /etc/fstab, make sure that the lines for your reiserfs partitions have
> '0' as the last number, rather than a '1'.

I also thought about that because it also annoys be. But then again, I
_do_ want the partitions checked every now and then (e. g. every 25
mounts). Wouldn't this disable fsck completely? Or is the ckeck
triggered on a different place?

Have a nice weekend,

Martin
-- 
Martin Pitt
home:  www.piware.de
eMail: [EMAIL PROTECTED]


signature.asc
Description: Digital signature

Bug#216301: RFP: icewmcp -- a full-featured, multi-language, Gtk-based control panel targeted toward IceWM

2003-10-17 Thread Jerome Marant

Package: wnpp
Severity: wishlist

* Package name: icewmcp
  Version : 2.5
  Upstream Author : Erica Andrews 
* URL or Web page : http://icesoundmanager.sourceforge.net/
* License : GPL
  Description : a full-featured, multi-language, Gtk-based control panel
targeted toward IceWM

IceWM Control Panel (IceWMCP) is the first full-featured, Gtk-based
control panel for IceWM. It is meant to run in IceWM, but can be used
in ANY window manager as a general-purpose control panel. IceWMCP is
multi-lingual.

It provides up-to-date versions of IcePref (preferences editor)
and IceMe (Menu editor) as well as a theme editor and many other
configuration tools.

My Economist subscription

2003-10-17 Thread William H. Gaddes

Re: Economist subscription of W.H.Gaddes

Today in the mail I received a card entitled 'Customer Service
Reply'. It stated that they could not locate my September 20 payment and
asked me to call your customer service office "at the number below". There
was no number any where on the card so I looked up your customer service on
the internet and there were several addresses so I picked the one above with
the hope that this would get to the right person.

Summary:On September 15 I mailed a check for $ 72.23 and you
received it
  because I have received the cancelled check
from my bank. On   the back of the
check there are several numbers and "Bank One, CO.
  Denver, CO." There are several numbers which
no doubt have meaning   for the Bank.

Some one in your organization has given me credit for the check
because the date on my address label has been changed from 'Sept 20
03' to 'Feb. 28  04'.

If you want more clarification please provide me with an e-mail
address or a phone number for the person with whom I should communicate.

W.H.Gaddes

Re: Package which uses jam (instead make)

On Fri, Oct 17, 2003 at 08:24:20PM +0200, Josip Rodin wrote:
> > You aren't trying to make debian/rules a jam script are you?
> Even if he was, that would be fine if he knew how to do it properly.
I wasn't ;)

Nevermind... I still have problems with `jam install`. I don't know how
to pass to it directory prefix.

I've checked mentioned lurker but it seems that the way how is he doing
it is now obsoleted. Then I've read some manuals/documentation of jam and
I've found information about LOCATE viariable but this didn't work as
I expected. Is there any advanced user of jam here?
Or maybe not advanced but more advance than me? ;)

I can workaround this problem with dh_install but there has to be some
way to use jam for it.
In addition doing it with dh_install is simple for netpanzer because it
has only one binary file but netpanzer-data will have dozens of various
files and then using `jam install` would be very useful.

I could put my files on some website but building it requires liphysfs
which is absent in Debian archives :/

regards
fEnIo

-- 
  _ Bartosz Feński aka fEnIo | mailto:[EMAIL PROTECTED] | 
pgp:0x13fefc40 
_|_|_32-050 Skawina - Głowackiego 3/15 - w. małopolskie - Polska
(0 0) phone:+48501608340 | ICQ:46704720 | GG:726362 | IRC:fEnIo
ooO--(_)--Ooo http://skawina.eu.org | JID:[EMAIL PROTECTED] | RLU:172001

signature.asc
Description: Digital signature

Re: search-citeseer_0.1-1_i386.changes REJECTED

On Thu, Oct 16, 2003 at 08:44:01PM -0300, Otavio Salvador wrote:

> Yes. This way to show issues is the right one but the James way is
> not. He doesn't do a suggestion but an exigency. This is wrong.

He did the right thing.

> Yes. The reson of my first mail is exactly this. I want make some troube
> to warn the way of some Debian Developpers do their work. James have the
> better itention possible, to have small subset possible of packages and
> like but the way of request it is wrong.
> 
> James should be more cordial and try talk with developpers. We
> (developpers) are all tring to do a great distribution and we should
> always discuss that things and doesn't thing we are always right.

The best approach is to bring the subject up for discussion on -devel or
-mentors and ask other developers for their input before uploading,
splitting, etc.  So yes, there should be discussion, but no, it is not his
responsibility to initiate discussion, but the maintainer's (yours).

-- 
 - mdz

Re: search-citeseer_0.1-1_i386.changes REJECTED

On Thu, Oct 16, 2003 at 05:32:11PM -0300, Otavio Salvador wrote:

> Joerg Jaspert <[EMAIL PROTECTED]> writes:
> > Policy is not everything that counts. Just because policy doesnt say
> > something it means it is good to do it.
> 
> Of course but I think if the developper did something is because he
> think this is better and this should be respected (if doesn't broke
> the policy)

Respected, certainly.  Accepted without question?  Certainly not.

> More or less. Doesn't make sense include a depends of Emacs in
> search-citeseer and the -el part depends of this. The better option is
> split in two package each with your depends and needs.
>
> The sugestion of James is not right to include emacs like a suggets is
> not good since the package need emacsen to work.

This is exactly what Recommends and Suggests are for.

-- 
 - mdz

Re: Pre-Depends for postgresql

On Fri, Oct 17, 2003 at 08:27:17PM +0100, Oliver Elphick wrote:

> If any package that needs to add a user should always use adduser,
> should that not be a required package rather than just important?

The priority has nothing to do with how many packages use it; there is an
explicit definition in the policy manual.

http://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities

required
Packages which are necessary for the proper functioning of the system. You
must not remove these packages or your system may become totally broken and
you may not even be able to use dpkg to put things back. Systems with only
the required packages are probably unusable, but they do have enough
functionality to allow the sysadmin to boot and install more software. 

> I had always thought that Pre-Dependencies were very much discouraged.

Caution and review are the rules for pre-dependencies.  They are sometimes
necessary, but should not be used without good reason.

-- 
 - mdz

Re: Package which uses jam (instead make)

2003-10-17 Thread Steve Greenland

On 17-Oct-03, 13:24 (CDT), Josip Rodin <[EMAIL PROTECTED]> wrote: 
> On Fri, Oct 17, 2003 at 12:20:03PM -0400, Ben Collins wrote:
> > You aren't trying to make debian/rules a jam script are you?
> 
> Even if he was, that would be fine if he knew how to do it properly.

   Policy 4.8:

   This file must be an executable makefile, and contains the
   package-specific recipes for compiling the package and building
   binary package(s) from the source.

There was a lot of discussion of this some years ago (possibly in
relationship to shoop?). I don't remember why we don't allow anything
that meets the expected interface.

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net

Re: Package which uses jam (instead make)

2003-10-17 Thread Mikhail Sobolev

On Fri, Oct 17, 2003 at 10:56:49PM +0200, Bartosz Fenski aka fEnIo wrote:
> Nevermind... I still have problems with `jam install`. I don't know how
> to pass to it directory prefix.
Sorry, if this does not help.  What about the '-s' option?

--
Misha


signature.asc
Description: Digital signature

Re: nethack popularity contest - number_pad?