Re: netkit-inetd in sarge

[Matt Zimmerman]

On Sat, Oct 18, 2003 at 11:04:31AM +1000, Andrew Pollock wrote:

> To cap it off, the discard service seems to be enabled out of the box. So
> is daytime. Daytime's not too bad, but discard? I personally believe we
> should be shipping sarge such that it installs offering the smallest
> number of network services by default, and the user should explicitly
> enable the ones they want. I can't see any reason for the discard service
> on an Internet facing box in this day and age.

I would like to see inetd leave the base system as well, but what problem
could you possibly have with the discard service?

> My personal preference would be for xinetd to be the default inet daemon
> installed, as if you use Red Hat's model of having an /etc/xinet.d/ (or
> whatever it is) it becomes trivial to be able to manage 
> (de)activation of individual services offered by xinetd.

It's pretty trivial with netkit-inetd as well; you edit /etc/inetd.conf and
comment out what you don't want.

> I've got a bit of spare time up my sleeves at the moment, and would like 
> to help make netkit-inetd not part of a base install. What would it take?

http://bugs.debian.org/87240

-- 
 - mdz

Re: Bug#215556: ITP: gsysutils -- Set of utilities useful to system administrators

[Bob Proulx]

Mathieu Roy wrote:
> The current sysutils contains:
> 
>  * procinfo - Displays system information from /proc (v17).
>  *   memtest - Test system memory for errors (v2.93.1).
>  *  bogomips - Shows the current bogomips rating without rebooting (v1.2).
>  * tofromdos - Converts DOS <-> Unix text files (v1.4).
> 
> http://packages.debian.org/stable/utils/sysutils.html
> 
> (anyway what's the difference between tofromdos and
> dos2unix/unix2dos?)  

Curiosity got me.  I pulled the source and looked.

One is a program and the others are symlinks to it.  They are aliases
to the same program providing different names.

ln -s fromdos $(tempdir)/$(package)/usr/bin/todos
ln -s fromdos $(tempdir)/$(package)/usr/bin/dos2unix
ln -s fromdos $(tempdir)/$(package)/usr/bin/unix2dos

Bob

Re: nethack popularity contest - number_pad?

[David Nusinow]

On Thu, Oct 16, 2003 at 06:30:26PM -0700, Joshua Kwan wrote:
>It's too trivial to ask a debconf question
> about it upon install so it boils down to a popularity contest.

As an aside, you might want to make this a low priority debconf
question. It might be trivial, but it's obviously generating a decent
amount of controversy, so having a question available for
dpkg-reconfigure'ing or control freaks might be handy.

And, as for the meat of the question, I like the number pad myself, but 
then again I have a laptop, so it's hjkl for me.

 - David Nusinow

Re: Package which uses jam (instead make)

[Chris Cheney]

On Fri, Oct 17, 2003 at 08:24:20PM +0200, Josip Rodin 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.

It would?

4.8. Main building script: `debian/rules'
-

 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.

Chris


signature.asc
Description: Digital signature

何不付2天的薪水雇佣一名忠诚高效的业务员?

[张先生]

debian-devel:您好!何不付2天的薪水雇佣一名忠诚高效的业务员?

工作能力：一、整套的营销方案，低成本高效率。
  二、任何网上可以找到的客户，我都可以联系上。
  三、让更多的客户主动来点击公司的网站。

本工作室铁定是您最佳的合作伙伴，给您带来很多客户资源，我们的目标是降低公司40%的广
告成本、成为公司销售第一名。请您联系我，没有我做不到，只有我想不到，如果您没有联系
我，我不会灰心，我会继续联系您，请原谅我的坚持，因为这是我的个性。

个人简历：
姓名：创艺网络营销工作室（三亿二千万邮件地址库，邮件群发软件，信息发布软件、
  定行业、定地区、定国家邮件地址搜索)
年龄：1岁
爱好：开发新客户，挖掘任何网上有价值的信息。
特点：找到任何行业、地区、国家的客户邮箱地址，做到高效、完全个性化的群发邮件
  （文字、图片、网页、附件）。
学习情况：2位大学毕业生2年时间不断探索网络新生。
工作情况：在1年内不断积累经验自我完善,至今倍受好评。
我的要求：给我一个演示的机会

 联系方式：0519-6996612（晚6点后）
 http://www.cework.com/email.asp



致
礼!
  　　 张先生
  　　 [EMAIL PROTECTED]
  　　 2003-10-18

Re: Pre-Depends for postgresql

[David B Harris]

On Fri, 17 Oct 2003 02:18:00 +0100
Colin Watson <[EMAIL PROTECTED]> wrote:
> Uid 31 is reserved forever (speaking as the base-passwd maintainer), but
> new installations of postgresql should have a uid in the system range,
> namely 100-999, as created by 'adduser --system'. See the changelog for
> base-passwd 3.5.0.

What for, out of curiosity? Just part of the "standard" range of 0-99?


pgpZoZaNdEesN.pgp
Description: PGP signature

Unidentified subject!

[Danish Saeed]

Dear Sir,
  
  We introduce ourselves as importer, exporter & traders of general 
commodities in Pakistan as you are aware of the fact that Pakistan is a large 
importer of raw cotton and exporter of finished goods to the other European 
countries. For these reasons we are in need of Raw cotton from your country 
therefore please quote your best possible prices and shipment time at your 
earliest as I am in need of the material urgently.

Prompt action in the above said matter will be highly appreciated.

Thanks & Regards

Danish Saeed

S S Corporation 
2/118 Kutchi gali no. 2 
Marriott road 
Karachi.
PAKISTAN
PH: 92-21-2441646,2434098
FAX: 92-21-2414088
CELL: 92-320-476

-- 
__
Sign-up for your own personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

CareerBuilder.com has over 400,000 jobs. Be smarter about your job search
http://corp.mail.com/careers

Re: Pre-Depends for postgresql

[Colin Watson]

On Sat, Oct 18, 2003 at 04:29:37AM -0400, David B Harris wrote:
> On Fri, 17 Oct 2003 02:18:00 +0100
> Colin Watson <[EMAIL PROTECTED]> wrote:
> > Uid 31 is reserved forever (speaking as the base-passwd maintainer), but
> > new installations of postgresql should have a uid in the system range,
> > namely 100-999, as created by 'adduser --system'. See the changelog for
> > base-passwd 3.5.0.
> 
> What for, out of curiosity? Just part of the "standard" range of 0-99?

Ids in 0-99 that have once been allocated for a particular purpose are
reserved for that purpose forever even if they're no longer created,
because it's very difficult to deallocate a global static id once it's
been installed on people's systems and packages have started using it
for random files they create. This is one reason why it's much better to
use dynamic ids where possible.

const struct _info specialusers[] = {
[...]
{ 31, (FL_NOAUTOREMOVE) },  /* postgres */
[...]
};

const struct _info specialgroups[] = {
[...]
{ 32, (FL_NOAUTOREMOVE) },  /* postgres */
[...]
};

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]

Re: nethack popularity contest - number_pad?

[Colin Watson]

On Sat, Oct 18, 2003 at 02:47:38AM -0400, David Nusinow wrote:
> On Thu, Oct 16, 2003 at 06:30:26PM -0700, Joshua Kwan wrote:
> >It's too trivial to ask a debconf question
> > about it upon install so it boils down to a popularity contest.
> 
> As an aside, you might want to make this a low priority debconf
> question. It might be trivial, but it's obviously generating a decent
> amount of controversy, so having a question available for
> dpkg-reconfigure'ing or control freaks might be handy.

It's trivial to reconfigure it in nethack's option screen, just like any
other option. I'm not sure why this one should be special.

IMO, leave it at the upstream default; you'll surprise nethack players
coming from non-Debian systems less that way. And it's not like nethack
doesn't have a host of other quirks. :)

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]

debian-devel@lists.debian.org

[Jens Goedeke]

Dir sirs,
sorry if this is not the correct address for feature requests, but I don't know 
where to send this mail to.

I've installed a debian system (knoppix 3.2) with kernel 2.4.20 on my toshiba 
laptop (satellite pro 2100).
Under KDE in any application I've got a offen occuring repeating error.
If I hit a key the letter somethimes appears up to 3 times (with only one hit).
This problem is know by some developers...
(http://www.met.ed.ac.uk/~hcp/t9000.html -> "Dealing with the bouncy keys" )
(I found further instructions who tell me to edit the keyboard.c and recompile 
the kernel)
But I'm no system adminstrator and have not the knowlege to recompile a whole 
kernel.

So I want you to ask, if a further release (>2.4.20) has implemented this 
bugfix so that I'm 
able to reinstall the whole release (that's quite easier for me).

Thanks a lot for this great free linux system.
regards
Jens

__
Bestes Testergebnis: Stiftung Warentest Doppelsieg fur WEB.DE FreeMail
und WEB.DE Club. Nur fuer unsere Nutzer! http://f.web.de/?mc=021182

Re: netkit-inetd in sarge

[Marco d'Itri]

On Oct 18, Andrew Pollock <[EMAIL PROTECTED]> wrote:

 >I've got a bit of spare time up my sleeves at the moment, and would like 
 >to help make netkit-inetd not part of a base install. What would it take?
Helping to complete the update-inetd rewrite.
If you are really so much interested please send me mail or look for me
on IRC.

-- 
ciao, |
Marco | [2463 maHghFCpQml2k]


signature.asc
Description: Digital signature

Re: Source only uploads?

[Andrew Suffield]

On Fri, Oct 17, 2003 at 04:30:03PM +0200, Sven Luther wrote:
> Sure, the ideal would be to rebuild everything in pbuilder

Stop.

Who has been perpetrating this myth? It's idiotic.

The objective is not to create Debian packages that build in an
artificial environment. The objective is to create Debian packages
that build on any Debian host that is running the same release.

The worst thing we could possibly do, short of never building the
packages, is to build them all in an artificial environment. Since the
buildds are by their nature artificial, it falls to the maintainer to
build the package on a real-world system.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: Package which uses jam (instead make)

[Tollef Fog Heen]

* 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.

Nope:

4.8. Main building script: `debian/rules'
-

 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.

I think «makefile» here means «file to be executed using the «make»
program in the «make package» in Debian».  :)

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  

RE: recent spam to this list

[Julian Mehnle]

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.
> 
> [...]
> 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.  

Alternatively, you could still use <[EMAIL PROTECTED]> as the envelope-from 
when sending from *anywhere* -IF- you send through mailserver.mydomain.com 
using SMTP-Auth.

Other nethack options (Was: nethack popularity contest - number_pad?)

[Lukas Geyer]

Colin Watson <[EMAIL PROTECTED]> writes:

> It's trivial to reconfigure it in nethack's option screen, just like any
> other option. I'm not sure why this one should be special.
> 
> IMO, leave it at the upstream default; you'll surprise nethack players
> coming from non-Debian systems less that way. And it's not like nethack
> doesn't have a host of other quirks. :)

Right, that reminds me of a default option which I always change,
namely pickup_types. I don't know what the default is at the moment
(in woody it seems to be just $), but IMHO things to be auto-pickuped
are "$!?+/=, and some characters might even leave out the spellbooks,
though one can at least sell them for decent money. Making nethack
options debconf question seems a bit silly to me, but I don't see why
we should stick to upstream defaults when they are wrong...

Lukas

Re: Package which uses jam (instead make)

[Henning Makholm]

Scripsit Steve Greenland <[EMAIL PROTECTED]>

>Policy 4.8:
> 
>This file must be an executable makefile, and contains the

> I don't remember why we don't allow anything
> that meets the expected interface.

One reason that comes to mind is that it can sometimes be convenient
to assume that standard make command line options work for
debian/rules, e.g.
$ debian/rules -n binary-indep

It also gives NMUers a well-known interface for inserting last-minute
corrections to the packaging, say, if policy changes dicate a change
in installation directories and the original maintainer has gone AWOL.

-- 
Henning Makholm"What a hideous colour khaki is."

Re: Package which uses jam (instead make)

[Josip Rodin]

On Fri, Oct 17, 2003 at 04:00:19PM -0500, Steve Greenland 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.

Because we're fools. :)

The "must" in the new meaning is an accidental byproduct of conversion to
the new language.

-- 
 2. That which causes joy or happiness.

Re: Package which uses jam (instead make)

[Josip Rodin]

On Sat, Oct 18, 2003 at 02:31:07PM +0200, Henning Makholm wrote:
> One reason that comes to mind [...]

We've heard it all before. Kindly refer to bug #88029.

-- 
 2. That which causes joy or happiness.

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

[Henning Makholm]

Scripsit Agustin Martin Domingo <[EMAIL PROTECTED]>

> 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.

If that is true, shouldn't it be counsidered a bug in emacsen-common?

I think it ought to be perfectly acceptable to have some large package
that, beside its main contents, provides some elisp files that help
using the main contents from emacs. If the elisp files are
sufficiently large (yet not large enough to justify being spilt out as
a separate package), it might still be desirable to byte-compile them.

The large package should then depend on emacsen-common, which just
provides the infrastructure for scheduling byte-code compilation done
at the right time. A user might install the large package without an
actual emacsen, but if he later added an emacs, the elisp interfaces
would be byte-compiled automatically.

Emacs-policy does say

  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).

but this, at least understood literally, applies only to *add-on*
package consisting largely of elisp code. In that case, just depending
on emacsen-common instead of emacsen would be wrong, as policy says:

   The `Depends' field should be used if the depended-on package is
   required for the depending package to provide a significant
   amount of functionality.

However, when the elisp helper modules in a package is not "a
significant amount" of its functionality, the package ought to be able
to register those without depending on an entire emacsen. If
emacs-package-install does not support that, it is IMHO a shortcoming
of emacs-package-install.

> You can try a workaround like this

> if [ "$1" = "configure" -a -x \
> /usr/lib/emacsen-common/emacs-package-install ]

This wouldn't work - if the package was installed before
emacsen-common, its files would never be byte-compiled even
if emacs was later added to the system. (And there's no telling
whether things would break horribly if emacsen-common happened
to be unpacked but not yet configured when the postinst script
runs).

-- 
Henning Makholm "We're trying to get it into the
parts per billion range, but no luck still."

Bug#216395: general: qt applicatons don't use kde style

[Momes]

Package: general
Severity: normal

I've problems with qt applications (lyx, qtparted, ...) that do not use kde 
style, instead they always use the default qt style.
I've been searching the mailing lists as well as Debian bug report and found 
no reference to this problem, sorry.
I'm using Sid with latest qt/kde packages.

Thank you in advance.
  Momes


-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux euclides.hn.org 2.4.21-xfs-6.0gui #8 SMP Fri Oct 17 18:19:01 
CEST 2003 i686
Locale: LANG=en_US, LC_CTYPE=en_US

Bug#205457: ITP: waproamd -- wireless access point roaming daemon

[Thomas Hood]

* Package name: waproamd
  Version : 0.3b
  Upstream Author : [EMAIL PROTECTED] (Lennart Poettering)
* URL :
http://www.stud.uni-hamburg.de/~lennart/projects/waproamd/
* License : GPL v.2
  Description : wireless network roaming daemon

 Waproamd makes a specified Wi-Fi interface scan for wireless
 access points and runs a proxy script according to what it detects.
 The default proxy script sets the WEP key appropriate to the MAC
 address of the access point.  This allows automatic association
 to an arbitrary number of different wireless networks.
 .
 Waproamd works with IEEE 802.11b (Wi-Fi) cards whose drivers
 support the wireless extensions API.

Re: Source only uploads?

[Goswin von Brederlow]

Andrew Suffield <[EMAIL PROTECTED]> writes:

> On Fri, Oct 17, 2003 at 04:30:03PM +0200, Sven Luther wrote:
> > Sure, the ideal would be to rebuild everything in pbuilder
> 
> Stop.
> 
> Who has been perpetrating this myth? It's idiotic.
> 
> The objective is not to create Debian packages that build in an
> artificial environment. The objective is to create Debian packages
> that build on any Debian host that is running the same release.
> 
> The worst thing we could possibly do, short of never building the
> packages, is to build them all in an artificial environment. Since the
> buildds are by their nature artificial, it falls to the maintainer to
> build the package on a real-world system.

Uploads are different from building.

Who said the maintainer should stop building packages or test what
they do before uploading? They deserve to be shot.

Its good for the autobuilders to check again if a package builds in a
mainly minimal environment. Esspecially since binary-all packages are
never crosschecked with binary uploads.

MfG
Goswin

udev 0.3 package

[Marco d'Itri]

http://www.bofh.it/~md/debian/

-- 
ciao, |
Marco | [2477 ca6Z/n9AUWKfQ]

Howto find packages that build-depend on pkg

[Tom Cato Amundsen]

How can I find all packages that build-depends on a package?
In my case, I'm looking for packages that build-depends on
docbook-xml and docbook-xsl.

-- 
Tom Cato Amundsen <[EMAIL PROTECTED]>
GNU Solfege - free eartraining, http://www.gnu.org/software/solfege/

Re: Howto find packages that build-depend on pkg

[Goswin von Brederlow]

Tom Cato Amundsen <[EMAIL PROTECTED]> writes:

> How can I find all packages that build-depends on a package?
> In my case, I'm looking for packages that build-depends on
> docbook-xml and docbook-xsl.

apt-cache show grep-dctrl

MfG
Goswin

Re: Other nethack options (Was: nethack popularity contest - number_pad?)

[Steve C. Lamb]

On Sat, Oct 18, 2003 at 08:09:00AM -0400, Lukas Geyer wrote:
> Right, that reminds me of a default option which I always change,
> namely pickup_types. I don't know what the default is at the moment
> (in woody it seems to be just $), but IMHO things to be auto-pickuped
> are "$!?+/=, and some characters might even leave out the spellbooks,
> though one can at least sell them for decent money. Making nethack
> options debconf question seems a bit silly to me, but I don't see why
> we should stick to upstream defaults when they are wrong...

Define "right".  Opinions don't constitute "right".  If they did here's
"right": numberpad w/NO auto-pickup except for money.  I don't want my packs
full of crap; let me decide what to pick up and what to leave laying on the
ground.

Best to stick to upstream defaults because for those of us who know we
want it different than defaults will know what to change right off the bat.

-- 
 Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
   PGP Key: 8B6E99C5   | main connection to the switchboard of souls.
---+-


signature.asc
Description: Digital signature

Re: Package which uses jam (instead make)

[Bartosz Fenski aka fEnIo]

On Sat, Oct 18, 2003 at 01:17:27AM +0400, Mikhail Sobolev 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?
It didn't help. Or maybe I can't use it properly.
Well... I've just subscribed to jam's mailing list and I'll ask for help
there.

Thanks for help.

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: Howto find packages that build-depend on pkg

[Marcelo E. Magallon]

On Sat, Oct 18, 2003 at 05:55:22PM +0200, Tom Cato Amundsen wrote:

 > How can I find all packages that build-depends on a package?  In my
 > case, I'm looking for packages that build-depends on docbook-xml and
 > docbook-xsl.

 Please excuse the somewhat terse answer of our fellow Goswin...

 You need to download the Sources file for the corresponding
 distribution.  It's available in the same place as the Packages file.
 This file contains the information you need.  In order to extract it,
 the easiest way is to use grep-dctrl, like this:

 $ grep-dctrl -n -s Package -F Build-Depends docbook-xml /path/to/Sources

 $ man grep-dctrl

 for more details.

-- 
Marcelo

Re: Howto find packages that build-depend on pkg

[Tom Cato Amundsen]

On Sat, Oct 18, 2003 at 05:57:13PM +0200, Goswin von Brederlow wrote:
> Tom Cato Amundsen <[EMAIL PROTECTED]> writes:
> 
> > How can I find all packages that build-depends on a package?
> > In my case, I'm looking for packages that build-depends on
> > docbook-xml and docbook-xsl.
> 
> apt-cache show grep-dctrl
> 

The build-depends fields are not included in Packages files, so this
does not help.

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

-- 
Tom Cato Amundsen <[EMAIL PROTECTED]>
GNU Solfege - free eartraining, http://www.gnu.org/software/solfege/

Re: Other nethack options (Was: nethack popularity contest - number_pad?)

[Lukas Geyer]

"Steve C. Lamb" <[EMAIL PROTECTED]> writes:

> On Sat, Oct 18, 2003 at 08:09:00AM -0400, Lukas Geyer wrote:
> > Right, that reminds me of a default option which I always change,
> > namely pickup_types. I don't know what the default is at the moment
> > (in woody it seems to be just $), but IMHO things to be auto-pickuped
> > are "$!?+/=, and some characters might even leave out the spellbooks,
> > though one can at least sell them for decent money. Making nethack
> > options debconf question seems a bit silly to me, but I don't see why
> > we should stick to upstream defaults when they are wrong...
> 
> Define "right".  Opinions don't constitute "right".  If they did here's
> "right": numberpad w/NO auto-pickup except for money.  I don't want my packs
> full of crap; let me decide what to pick up and what to leave laying on the
> ground.

I didn't use "right" in the paragraph above (except for the very first
word, but I assume you don't want me to define that, it does not have
any meaning in that context), so why should I define it? And for your
preference of not picking up anything except money, that is very
dangerous if monsters pick things up instead. Think of wands of death,
wands of digging, scroll of create monster and stuff like that, or
amulet of life saving. And if you want to avoid getting burdened or
stressed by auto-pickup, then why pick up money? And auto-pickup for
money is also annoying when leprechauns are around etc. I find the
default of auto-pickup=$ hard to defend. Having auto-pickup turned off
is another matter, that would be fine with me, as long as pickup_types
is sane.

Lukas

P.S.: For the humor-impaired: Here are some smileys, feel free to
spread them over the text of this email: :) :) :) :)

Re: [debian-devel] Re: netkit-inetd in sarge

[Magosányi Árpád]

Hi!

If you are at it, please also arrange that netbase do not depend
on any network daemons. I guess lot of us want to have /etc/services,
but do not want inetd and portmapper.

Thank you.

2003-10-18, szo keltezéssel Marco d'Itri ezt írta:
> On Oct 18, Andrew Pollock <[EMAIL PROTECTED]> wrote:
> 
>  >I've got a bit of spare time up my sleeves at the moment, and would like 
>  >to help make netkit-inetd not part of a base install. What would it take?
> Helping to complete the update-inetd rewrite.
> If you are really so much interested please send me mail or look for me
> on IRC.
> 
> -- 
> ciao, |
> Marco | [2463 maHghFCpQml2k]
-- 
GNU GPL: csak tiszta forrásból

Re: Howto find packages that build-depend on pkg

[Goswin von Brederlow]

Tom Cato Amundsen <[EMAIL PROTECTED]> writes:

> On Sat, Oct 18, 2003 at 05:57:13PM +0200, Goswin von Brederlow wrote:
> > Tom Cato Amundsen <[EMAIL PROTECTED]> writes:
> > 
> > > How can I find all packages that build-depends on a package?
> > > In my case, I'm looking for packages that build-depends on
> > > docbook-xml and docbook-xsl.
> > 
> > apt-cache show grep-dctrl
> > 
> 
> The build-depends fields are not included in Packages files, so this
> does not help.

No?

% grep-dctrl -n -s Package -F Build-Depends docbook-xml 
/mnt/debian/mirror/debian/dists/sid/main/source/Sources
im-sdk
java-common
libsigc++-1.2
mldonkey
mrproject
pgi
scrollkeeper
solfege
utah-glx
xmlto
yaz

MfG
Goswin

Re: Source only uploads?

[Andrew Suffield]

On Sat, Oct 18, 2003 at 03:32:41PM +0200, Goswin von Brederlow wrote:
> Its good for the autobuilders to check again if a package builds in a
> mainly minimal environment.

That's an argument for building it *once* in such an environment. It
is definitely not an argument that it should only be built in such an
environment, which was the point in question.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: Howto find packages that build-depend on pkg

[Tom Cato Amundsen]

On Sat, Oct 18, 2003 at 09:37:34PM +0200, Goswin von Brederlow wrote:
> Tom Cato Amundsen <[EMAIL PROTECTED]> writes:
> 
> > On Sat, Oct 18, 2003 at 05:57:13PM +0200, Goswin von Brederlow wrote:
> > > Tom Cato Amundsen <[EMAIL PROTECTED]> writes:
> > > 
> > > > How can I find all packages that build-depends on a package?
> > > > In my case, I'm looking for packages that build-depends on
> > > > docbook-xml and docbook-xsl.
> > > 
> > > apt-cache show grep-dctrl
> > > 
> > 
> > The build-depends fields are not included in Packages files, so this
> > does not help.
> 
> No?
> 
> % grep-dctrl -n -s Package -F Build-Depends docbook-xml 
> /mnt/debian/mirror/debian/dists/sid/main/source/Sources

Of course. I was searching the Packages file, not Sources.

Thanks!

-- 
Tom Cato Amundsen <[EMAIL PROTECTED]>
GNU Solfege - free eartraining, http://www.gnu.org/software/solfege/

Re: Package which uses jam (instead make)

[Manoj Srivastava]

On Sat, 18 Oct 2003 15:02:10 +0200, Josip Rodin <[EMAIL PROTECTED]> said: 

> 88029

yeah well. That is not all the dfiscussion there was on it. In
 March 2001, we had more than those comments on it:

==

If people really think that calling scripts from Makefiles is
 hard, should they really be maintaining Debian packages? 

So far, the arguments I have heard for removing this
 restrictions have been
  a) This new mechanism is so cool
  b) Makefiles can be really hard to write!!
  c) Why not?

I guess my objection to this reduction of standardization is
 that there should be some inertia in policy, and that we need to see
 some stronger technical reasons to break the following practices:

  i) make -n -p -f ./debian/rules
 ii) in ./makefile:  include ./debian/rules
 change targets and or rules, and spit out some things set in
 ./debian/rules (I actually did this for debugging a rules file)

Yes, pretty arcane; but I contend that this argument is no
 weaker than any I have seen in support of this proposal.
   
 Wichert> I'll make this a proposal then:

 Wichert>   As such I propose that the statement that debian/rules has be to a
 Wichert>   makefile be removed.

I think I must object to this, on the grounds that we are now
 changing an published interface to the package building process.
 Indeed, I have used makefiles that include ./debian/rules and derive
 targets and tweak the make rules in the debian/rules process
 (security related experiments), and I would strongly object to the
 mechanisms being yanked out from under me.
==

I still think that what we have now is a long established
 interface to the build system; saying that the ./debian/rules file is
 a Makefile is a short hand for describing an extended version of the
 interface defined in Section 6: Software development Utilities Option
 of ISO/IEC 9945-2, ANSI/IEEE Std 1003.2, "Infornation technology -
 Portable Operating System Interface (POSIX) -- Part 2: Sheel and
 Utilities". Specifically, section 6.2 make -- Maintain, update, and
 regenrate groups of programs. The extentions include GNU Make
 extrenstions, and requirements for certain targets to exist.

A tacit part of the interface are how debugging works, how
 paths can be added to the build environment, how variables are set up
 and modified. 

Pretending that this is not an interface that we have now
 depended upon for years is hiding from the facts

manoj

-- 
"What is wanted is not the will to believe, but the will to find out,
which is the exact opposite." Bertrand Russell, _Sceptical_Essays_,
1928
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Package which uses jam (instead make)

[Manoj Srivastava]

On Sat, 18 Oct 2003 14:57:34 +0200, Josip Rodin <[EMAIL PROTECTED]> said: 

> On Fri, Oct 17, 2003 at 04:00:19PM -0500, Steve Greenland 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.

> Because we're fools. :)

We would be even more foolish to yank out a published
 interface to our build system.

> The "must" in the new meaning is an accidental byproduct of
> conversion to the new language.

Accidental or not, it has been an established part of the
 infrastructure for the whole life of ./debian/rules convention; and
 ought not to be easy ro change.

manoj
-- 
"The light that burns twice as bright lasts half as long, and you have
burned so very, very bright, Roy!" Doctor Eldon Tyrell, in Blade
Runner
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re:

[John Belmonte]

Jens Goedeke wrote:
sorry if this is not the correct address for feature requests, but I
don't know where to send this mail to.
I've installed a debian system (knoppix 3.2) with kernel 2.4.20 on my
toshiba laptop (satellite pro 2100). Under KDE in any application
I've got a offen occuring repeating error. If I hit a key the letter
somethimes appears up to 3 times (with only one hit). This problem is
know by some developers... (http://www.met.ed.ac.uk/~hcp/t9000.html
-> "Dealing with the bouncy keys" ) (I found further instructions who
tell me to edit the keyboard.c and recompile the kernel) But I'm no
system adminstrator and have not the knowlege to recompile a whole
kernel.
So I want you to ask, if a further release (>2.4.20) has implemented
this bugfix so that I'm able to reinstall the whole release (that's
quite easier for me).
The correct mailing list is .
The 2.6 kernel (still in development) is much better, although not 
perfect, about suppressing these spurious keys.  If you aren't 
technical, perhaps the best solution is to wait for a version of Knoppix 
that has the new kernel.

--
http:// if   le.o  /

Re: netkit-inetd in sarge

[Andrew Pollock]

On Sat, Oct 18, 2003 at 01:40:51AM -0400, Matt Zimmerman wrote:
> On Sat, Oct 18, 2003 at 11:04:31AM +1000, Andrew Pollock wrote:
> 
> > To cap it off, the discard service seems to be enabled out of the box. So
> > is daytime. Daytime's not too bad, but discard? I personally believe we
> > should be shipping sarge such that it installs offering the smallest
> > number of network services by default, and the user should explicitly
> > enable the ones they want. I can't see any reason for the discard service
> > on an Internet facing box in this day and age.
> 
> I would like to see inetd leave the base system as well, but what problem
> could you possibly have with the discard service?

Well it's been so long since I've seen it in the wild, but doesn't this 
service just eat whatever you throw at it? In a cents per meg scenario, 
someone malicious could use this service to cost the person running it 
some big dollars.

regards

Andrew

Re: netkit-inetd in sarge

[Matt Zimmerman]

On Sun, Oct 19, 2003 at 10:48:47AM +1000, Andrew Pollock wrote:

> On Sat, Oct 18, 2003 at 01:40:51AM -0400, Matt Zimmerman wrote:
> > I would like to see inetd leave the base system as well, but what problem
> > could you possibly have with the discard service?
> 
> Well it's been so long since I've seen it in the wild, but doesn't this 
> service just eat whatever you throw at it? In a cents per meg scenario, 
> someone malicious could use this service to cost the person running it 
> some big dollars.

Yes, it receives data from the network and throws it away.  But I don't see
how this figures into your example.  If you can give me an scenario where
this service would allow a malicious remote user to DoS anything other than
the discard service itself, that would be interesting.  Otherwise, I'm
inclined to say that it's quite harmless (and indeed useful).

-- 
 - mdz

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

[Graham Wilson]

On Fri, Oct 17, 2003 at 12:22:33PM +0200, Wouter Verhelst wrote:
> James is ftp-master, DAM, autobuilder admin, and part of the
> debian-admin team as well.

Wow!

-- 
gram


signature.asc
Description: Digital signature

Re: netkit-inetd in sarge

[Steve Langasek]

On Sun, Oct 19, 2003 at 10:48:47AM +1000, Andrew Pollock wrote:
> On Sat, Oct 18, 2003 at 01:40:51AM -0400, Matt Zimmerman wrote:
> > On Sat, Oct 18, 2003 at 11:04:31AM +1000, Andrew Pollock wrote:

> > > To cap it off, the discard service seems to be enabled out of the box. So
> > > is daytime. Daytime's not too bad, but discard? I personally believe we
> > > should be shipping sarge such that it installs offering the smallest
> > > number of network services by default, and the user should explicitly
> > > enable the ones they want. I can't see any reason for the discard service
> > > on an Internet facing box in this day and age.

> > I would like to see inetd leave the base system as well, but what problem
> > could you possibly have with the discard service?

> Well it's been so long since I've seen it in the wild, but doesn't this 
> service just eat whatever you throw at it? In a cents per meg scenario, 
> someone malicious could use this service to cost the person running it 
> some big dollars.

That's meaningless.  You can do the same whether or not the remote end
is actually listening on the port in question.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: netkit-inetd in sarge

[Andrew Pollock]

On Sat, Oct 18, 2003 at 09:32:54PM -0400, Matt Zimmerman wrote:
> On Sun, Oct 19, 2003 at 10:48:47AM +1000, Andrew Pollock wrote:
> 
> > On Sat, Oct 18, 2003 at 01:40:51AM -0400, Matt Zimmerman wrote:
> 
> Yes, it receives data from the network and throws it away.  But I don't see
> how this figures into your example.  If you can give me an scenario where
> this service would allow a malicious remote user to DoS anything other than
> the discard service itself, that would be interesting.  Otherwise, I'm
> inclined to say that it's quite harmless (and indeed useful).

Hmm, am I the only one that thinks

dd if=/dev/zero | nc victim discard

is a bad thing, in an environment where the victim is paying cents per meg 
for inbound traffic? I'm no so much talking about DoSing anything, but 
causing financial damage.

Andrew

Re: netkit-inetd in sarge

[Andrew Pollock]

On Sat, Oct 18, 2003 at 01:40:51AM -0400, Matt Zimmerman wrote:
> On Sat, Oct 18, 2003 at 11:04:31AM +1000, Andrew Pollock wrote:
> 
> It's pretty trivial with netkit-inetd as well; you edit /etc/inetd.conf and
> comment out what you don't want.
> 

Additional packages that wish to register an (x)inetd based service can 
just plonk a file in /etc/xinet.d, which is a bit more elegant than having 
to script modifying a flat config file though.

Andrew

Re: netkit-inetd in sarge

[Cameron Patrick]

On Sun, Oct 19, 2003 at 01:37:58PM +1000, Andrew Pollock wrote:

| Hmm, am I the only one that thinks
| 
| dd if=/dev/zero | nc victim discard
| 
| is a bad thing, in an environment where the victim is paying cents per meg 
| for inbound traffic? I'm no so much talking about DoSing anything, but 
| causing financial damage.

Yeah, but you can do that on any given port whether it's open or not. e.g.

cat /dev/zero | nc -u victim 12345

(nc in UDP mode seems to ignore "ICMP port unreachable" packets in my
testing...  if it doesn't you can always use iptables to make sure it
does.)

There's no way to /stop/ someone from sending you data, whether you want
it or not.

Cameron.