Bug#78282: Kак бopoтьcя с депpeссuей? ссезэуоед ыэеяуеоа кеяуирлнт

[Вниманue!]

Каждый день одно и то же: работа - сидим за компьютером, дорога - сидим или стоим в душном транспорте, дом - опять сидим, то у телевизора, то за столом, опять у компьютера, да и едим непонятно что и непонятно как! А потом страдаем от головной боли и болей в спине, от болей в коленях и болей в сердце или желудке. Развивается синдром хронической усталости. Жизнь уже не кажется такой привлекательной, а утро уже не радует свежестью и бодростью во всём теле. В конечном счёте, плохое самочувствие постепенно повергает нас в депрессию. Неужели теперь так будет всегда? Хорошо бы найти волшебную таблетку, чтобы сразу избавиться от всех проблем со здоровьем! доэебюко амно нм
Но, как известно, чудес на свете не бывает и один препарат не может помочь при многих проблемах со здоровьем. Поэтому линия НЕСТАРИТ®, разработанная российскими учеными, состоит из 12 полностью натуральных препаратов, каждый из которых имеет определённое назначение, а вместе они способны навести порядок во всём организме. Препараты линии обладают быстродействием без побочных эффектов. Они созданы на основе активных океанических компонентов, которые быстро усваиваются организмом, способны находить более 300 "поломок" в человеческом организме и обеспечивать нормальную частоту обновления клеток человека даже в преклонном возрасте! Это значит, что депрессия, вызванная плохим самочувствием, будет побеждена!
Благодаря тому, что все препараты линии НЕСТАРИТ® сочетаются между собой, каждый клиент после подробного тестирования по телефону получает индивидуально подобранный оздоровительный курс и обеспечивается поддержкой личного консультанта, который курирует приём препаратов, анализирует результаты и отвечает на все возникающие вопросы. ылквдаю еакоер
НЕСТАРИТ® - натуральное средство против депрессии, вызванной плохим самочувствием!! итайтоои лдв еоята
Звоните нам по телефону в Москве 783-23-23 или по региональной линии 8-800-200-9-200 (бесплатный звонок из регионов) 
Обратите внимание! Заказав НЕСТАРИТ® в октябре, в дополнение к своему оздоровительному курсу Вы получите еще один эффективный препарат линии бесплатно!
Товар сертифицирован и запатентован.


нлал ьсба двстао ле

этнпнлрое эопюащетуа чзнм ротмолтсацн нвятао есвы ассятктпяй аетдель навбыс тьозллмойй ннлетдн

/usr/doc symlinks

[Chris Cheney]

I thought that it was planned that /usr/doc not exist for the sarge
release. However, I still see symlinks in /usr/doc is this considered a
bug or are we waiting until sarge+1 to do this?

BTW - I still see one package that installs files directly into /usr/doc

usr/doc/examples/ucbmpeg/mpeg_encode/nosearch.param   graphics/ucbmpeg

Chris Cheney


signature.asc
Description: Digital signature

Re: /usr/doc symlinks

[Santiago Vila]

On Sun, 5 Oct 2003, Chris Cheney wrote:

> I thought that it was planned that /usr/doc not exist for the sarge
> release. However, I still see symlinks in /usr/doc is this considered a
> bug or are we waiting until sarge+1 to do this?
>
> BTW - I still see one package that installs files directly into /usr/doc
>
> usr/doc/examples/ucbmpeg/mpeg_encode/nosearch.param   graphics/ucbmpeg

Yes, it's a bug. Please report it. Packages were already supposed to
have docs physically in /usr/share/doc in woody.

BTW: I would like to remove /usr/doc in base-files so that sarge
installs made from scratch do not have a /usr/doc at all. The only
thing which prevents me from doing that is that Manoj sort-of
convinced me that according to policy, packages may in principle
assume blindly that /usr/doc exists when creating/removing the
symlinks.

Does anyone have a good estimation about the number of packages which
currently do this? (That is, assume *blindly* that /usr/doc exists).

Re: /usr/doc symlinks

[Santiago Vila]

On Sun, 5 Oct 2003, Santiago Vila wrote:

> On Sun, 5 Oct 2003, Chris Cheney wrote:
>
> > I thought that it was planned that /usr/doc not exist for the sarge
> > release. However, I still see symlinks in /usr/doc is this considered a
> > bug or are we waiting until sarge+1 to do this?
> >
> > BTW - I still see one package that installs files directly into /usr/doc
> >
> > usr/doc/examples/ucbmpeg/mpeg_encode/nosearch.param   graphics/ucbmpeg
>
> Yes, it's a bug. Please report it. Packages were already supposed to
> have docs physically in /usr/share/doc in woody.

Clarification: It's a bug that there are still files in /usr/doc.
For removing the doc symlinks time has not come yet to report them as bugs.

Re: /usr/doc symlinks

[Colin Watson]

On Sun, Oct 05, 2003 at 01:59:10AM -0500, Chris Cheney wrote:
> BTW - I still see one package that installs files directly into /usr/doc
> 
> usr/doc/examples/ucbmpeg/mpeg_encode/nosearch.param   graphics/ucbmpeg

Where's this data from? The version of ucbmpeg in testing and unstable
appears to use /usr/share/doc as it's supposed to.

-- 
Colin Watson  [EMAIL PROTECTED]

Bug#214159: ITP: dict-cz-en -- Czech-English translation dictionary for dictd

[Antonin Kral]

Package: wnpp
Severity: wishlist

* Package name: dict-cz-en
  Version : 20031005-1
  Upstream Author : Milan Svoboda <[EMAIL PROTECTED]>
* URL : http://slovnik.zcu.cz/
* License : GNU/FDL
  Description : Czech-English translation dictionary for dictd

Based upon the work of volunteers, this is a Czech-English and
English-Czech translation dictionary for the dictd server. It contains
approximately 61,000 entries.

More informations is at http://slovnik.zcu.cz


-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux bobek 2.4.23-pre2 #3 Sun Aug 31 23:50:47 CEST 2003 i686
Locale: LANG=C, LC_CTYPE=cs_CZ

Re: /usr/doc symlinks

[Chris Cheney]

On Sun, Oct 05, 2003 at 08:57:37AM +0100, Colin Watson wrote:
> On Sun, Oct 05, 2003 at 01:59:10AM -0500, Chris Cheney wrote:
> > BTW - I still see one package that installs files directly into /usr/doc
> > 
> > usr/doc/examples/ucbmpeg/mpeg_encode/nosearch.param   graphics/ucbmpeg
> 
> Where's this data from? The version of ucbmpeg in testing and unstable
> appears to use /usr/share/doc as it's supposed to.

I grepped a current Contents-i386.gz for usr/doc, and after examining
the file itself I notice it is from a comment in the front of
Contents-i386.gz... ARGH!!!

Sorry about the confusion.

Chris


The best way to search quickly for a file is with the Unix `grep'
utility, as in `grep  CONTENTS':

 $ grep nose Contents
 etc/nosendfile  net/sendfile
 usr/X11R6/bin/noseguy   x11/xscreensaver
 usr/X11R6/man/man1/noseguy.1x.gzx11/xscreensaver
 usr/doc/examples/ucbmpeg/mpeg_encode/nosearch.param graphics/ucbmpeg
 usr/lib/cfengine/bin/noseyparkeradmin/cfengine


signature.asc
Description: Digital signature

Re: /usr/doc symlinks

[Cameron Patrick]

On Sun, Oct 05, 2003 at 03:25:01AM -0500, Chris Cheney wrote:

| I grepped a current Contents-i386.gz for usr/doc, and after examining
| the file itself I notice it is from a comment in the front of
| Contents-i386.gz... ARGH!!!

>From the comment at the top of Contents-i386.gz:

This file maps each file available in the Debian GNU/Linux
system to the package from which it originates.  It includes
packages from the DIST distribution for the ARCH architecture.

Is it just me, or does this look like a template that was supposed to be
sed'ed to replace DIST and ARCH with something more sane (e.g. sid
and i386)?

Cameron.

Package verification ? (Best practice)

[Osamu Aoki]

Hmmm...

On Sun, Oct 05, 2003 at 09:38:30AM +1000, Brian May wrote:
> On Sat, Oct 04, 2003 at 01:42:36PM -0400, Fabien Ninoles wrote:
> > Although your proposition seems more complete, have you try
> > debsums and checksecurity?  debsums with the following
> > feature in /etc/apt/apt.conf
> > 
> > DPkg::Post-Invoke {
> > "debsums --generate=nocheck -sp /var/cache/apt/archives";
> > };
> > 
> > Can be very handy in creating md5sums (BTW, I think it's a bug
> > against policy to include md5sums in control files).
> 
> Is there some way you can do the same thing for packages installed with
> dpkg only and without apt-get? The apt-get layer would appear to be the
> wrong layer for this task IMHO.

Very true.

By the way(thus changing title), the equivalent for above less
interesting but still very good trick, I recommended:

  6.4.13 Verify installed package files

   debsums enables verification of installed package files against MD5
   checksums. Some packages do not have available MD5 checksums. A possible
   temporary fix for sysadmins:

  # cat >>/etc/apt/apt.conf.d/90debsums
  DPkg::Post-Install-Pkgs {"xargs /usr/bin/debsums -sg";};
  ^D

   per Joerg Wendland [EMAIL PROTECTED] (untested).


This one is better since it will be more compatible package upgrade by using
apt.conf.d/ .  But "-p" option maybe needed. "--generate=nocheck"  seems good 
idea.  

Post-Install-Pkgs withxargs 
Post-Install  without xargs 

I do not know which is better.

Anyone have better suggestion?

(Maybe adding "apt-get --reinstall -d install `debsums -l`" trick is
also needed.)

Osamu

PS: Full section of above quote is available as:
 http://www.debian.org/doc/manuals/reference/ch-package.en.html#s-debsums

Re: Looking for a co-maintainer for adduser

[Marc Haber]

On Sat, 04 Oct 2003 15:58:46 -0500, John Hasler <[EMAIL PROTECTED]>
wrote:
>But it would not be nice to not have the things that would leave with it.

Generally, it would be a good thing to have Debian base installable
without perl. That way, security-aware administrators would have the
right to choose whether they need $BELL or $WHISTLE that makes perl
appear.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber  |   " Questions are the | Mailadresse im Header
Karlsruhe, Germany  | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature  | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29

Re: Looking for a co-maintainer for adduser

[Colin Watson]

On Sun, Oct 05, 2003 at 01:41:56PM +0200, Marc Haber wrote:
> On Sat, 04 Oct 2003 15:58:46 -0500, John Hasler <[EMAIL PROTECTED]>
> wrote:
> >But it would not be nice to not have the things that would leave with it.
> 
> Generally, it would be a good thing to have Debian base installable
> without perl. That way, security-aware administrators would have the
> right to choose whether they need $BELL or $WHISTLE that makes perl
> appear.

I'd rather that the tools in Debian base were written in a high-level
language where available. Take away Perl and you've got only shell, C,
and C++ left; I don't think that's going to improve security in
practice.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Ideas about allowing Co-maintainer

[Martin Michlmayr]

* Goswin von Brederlow <[EMAIL PROTECTED]> [2003-08-14 16:26]:
> Will you sponsor an NMU for util-linux?
> 
> It has ~150 bugs collected over the last 5 years, several of those
> with patches and some policy violations. Bugs ranging from grave to

1.5 Months are over, and yet I don't see any patches sent to you to
utill-linux's bugs.

-- 
Martin Michlmayr
[EMAIL PROTECTED]

Re: Ideas about allowing Co-maintainer

[Goswin von Brederlow]

Martin Michlmayr <[EMAIL PROTECTED]> writes:

> * Goswin von Brederlow <[EMAIL PROTECTED]> [2003-08-14 16:26]:
> > Will you sponsor an NMU for util-linux?
> > 
> > It has ~150 bugs collected over the last 5 years, several of those
> > with patches and some policy violations. Bugs ranging from grave to
> 
> 1.5 Months are over, and yet I don't see any patches sent to you to
> utill-linux's bugs.
> 
> -- 
> Martin Michlmayr
> [EMAIL PROTECTED]

I'm still waiting for an answere from the maitainer when he will be
done hollidaying and have time to care about patches.

I also was told to rather get upstream to include patches to keep
debian changes minimal.

There is no point for me working on those bugs if the patches will
just rod in the bts or be thrown out so as not to differ from
upstream. As I said before I won't work on the debian package again
without an assurance by the maintainer that he will look at it.

MfG
Goswin

迎国庆大优惠[特卖]

[郑杨悟]

尊敬的debian-devel： 
 迎国庆大优惠[特卖] ！

因艾商城为了答谢新老顾客的厚爱！决定在2003年09月25日―2003年10月30日
VP-RX阴茎增大疗程装 9 折大优惠。欢迎新老顾客光临选购！注册会员订购有产品增送！

详细介绍和图片请看：http://www.yinlove.net/product_detail.asp?id=169 

电话订购：021-56728806

联系人：  李小姐

QQ咨询：  202963

Bug#214187: ITP: qmailadmin -- web interface for managing a qmail system with virtual domains

[Filippo Giunchedi]

Package: wnpp
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: qmailadmin
  Version : 1.0.6
  Upstream Author : Inter7 <[EMAIL PROTECTED]>
* URL : http://www.inter7.com/qmailadmin.html
* License : GPL
  Description : web interface for managing a qmail system with virtual 
domains

qmailAdmin provides a web interface for managing a qmail system with
virtual domains. A version is available now for use with the vpopmail
program. It provides admin for adding/deleting users, Aliases, Forwards,
Mailing lists and Autoresponders.

- -- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux zoidberg 2.4.21 #4 Mon Sep 1 18:26:30 CEST 2003 i686
Locale: LANG=C, LC_CTYPE=C

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

iD8DBQE/gA+wABzeamt51AERAqfjAKCwJiJRMcKwLuyBt8/OoKE8OuKr1gCgk4ch
utF5IANuk+8sC75viVb/DfU=
=yuHS
-END PGP SIGNATURE-

Re: Ideas about allowing Co-maintainer

[Mark Brown]

On Sun, Oct 05, 2003 at 01:13:55PM +0200, Goswin von Brederlow wrote:

> There is no point for me working on those bugs if the patches will
> just rod in the bts or be thrown out so as not to differ from
> upstream. As I said before I won't work on the debian package again
> without an assurance by the maintainer that he will look at it.

Have you tried working directly with upstream on these bugs?  I don't
know about the maintainer of util-linux but for me that would be the
most convenient way to handle something like this.  Forwarding things on
is not a problem but when there's a lot of work going on you may as well
cut out the middleman.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."

Re: Debian should not modify the kernels!

[Tollef Fog Heen]

* Herbert Xu 

| Very few people really need cramfs if they're building custom kernels.
| This is because initrd only makes sense when you're building for a
| large number of machines.  If you're building a custom kernel, just
| compile in all the drivers you need for mounting root and that's that.

Except if you want to use EVMS or similar on /, in which case you need
the evms userspace tools on the initrd.  (Using 2.6, that is, in 2.4
the discovery is done in kernel-space.)

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

Re: local Release

[Andreas Metzler]

Marcos Dione <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 01, 2003 at 11:34:10PM +0200, Andreas Metzler wrote:
>> Marcos Dione <[EMAIL PROTECTED]> wrote:
>> [...]
>> >*but*... now I set up atp.conf to have 'frankie' as the default
>> > release, but when I try to install galeon, it tries to get the unstable
>> > ones. if I try to get the frankie version w/ 'apt-get install
>> > galeon/frankie' I get:

>>> E: Release 'frankie' for 'galeon' not found

>^^^
>yes, I did mispelled that one; was copied by hand...

>> Provide a Release file (in the same location as Packages.gz). Take a
>> look at your favorite Debian mirror for examples.

>Yes, I have one... it's:

> [EMAIL PROTECTED]:~$ cat 
> /var/www/local/dists/frankie/main/binary-i386/Release 
> Archive: frankie
> Component: main
> Origin: Credicoop
> Label: Debian
> Architecture: i386

>anything wrong?

I don't think so, but apt-cache policy might be helpful for debugging.
  cu andreas

bug data mining

[John Belmonte]

Hello,
I didn't have any luck asking this question on debian-mentors, so I hope 
it's ok to try here.

Is there some resource that lets me find "overlooked" bugs-- for
example, RC bugs older than 2 weeks and having no follow-up messages?
If not, what is the best way to generate such a list on my own?
Thanks,
-John
--
http:// if   le.o  /

Re: Ideas about allowing Co-maintainer

[Martin Michlmayr]

* Mark Brown <[EMAIL PROTECTED]> [2003-10-05 14:14]:
> Have you tried working directly with upstream on these bugs?  I don't
> know about the maintainer of util-linux but for me that would be the
> most convenient way to handle something like this.  Forwarding things on

The upstream maintainer of util-linux is usually a pleasure to work
with, and I told that Goswin several times.

-- 
Martin Michlmayr
[EMAIL PROTECTED]

Re: Ideas about allowing Co-maintainer

[Martin Michlmayr]

* Goswin von Brederlow <[EMAIL PROTECTED]> [2003-10-05 13:13]:
> I also was told to rather get upstream to include patches to keep
> debian changes minimal.
> 
> There is no point for me working on those bugs if the patches will
> just rod in the bts or be thrown out so as not to differ from
> upstream. As I said before I won't work on the debian package again
> without an assurance by the maintainer that he will look at it.

Well, so have you forwarded patches to the upstream maintainer then?
-- 
Martin Michlmayr
[EMAIL PROTECTED]

Bug#53121: basketball carbuncje s hy brqab n nmu

[Herminia Mclain]

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

http://www.rxdiscountusa.biz/medical



















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


med

idtbbavxyxpuxsiotik
 sjf
 nk
uahdcdmd
nvobqdrbe im
 pz u t
dbk  f  hha yk ut s dymuaq
a

Re: Looking for a co-maintainer for adduser

[John Belmonte]

Colin Watson wrote:
I'd rather that the tools in Debian base were written in a high-level
language where available. Take away Perl and you've got only shell, C,
and C++ left; I don't think that's going to improve security in
practice.
Lua is a modern high-level language.  Its 15K stand-alone interpreter 
depends on only two libraries which total less than 200K.  The 
functionality of its standard libraries are limited by ANSI C, but there 
are are third party libraries for talking to the OS, such as a POSIX 
library.

Someone less averse to prefix notation than I might make the same 
argument about scsh.  It's larger and has more dependencies, but on the 
other hand has full library support for system programming.

Why not consider tiny languages?

--
http:// if   le.o  /

Re: On package description quality

[Tom]

On Sun, Oct 05, 2003 at 02:25:57PM +, debacle wrote:
> Hi,
> 
> sometimes I read package descriptions I'm not happy with.
> E.g. the description starts: "Foobar is a GTK+ application,
> that enables blah..." where foobar is a user application,
> not mainly for GTK+ programmers.  Of course, the user
> doesn't/shouldn't care about GTK+ - and if, there's the
> dependencies listed anyway.  I remember, that we have some
> guidelines on package description, where you can read about
> this basics, but I cannot remember the URI.  Could someone
> help me, so that I can cite this guideline when filing a bug
> against such packages?
> 
> Cheers,
> -- 
> W. Borgert <[EMAIL PROTECTED]>
> 

I disagree.  GUI apps in Linux are so wildly disparate that knowing the 
basic architecture is pretty important for me to decide whether or not I 
want it.

Re: On package description quality

[Mathieu Roy]

debacle <[EMAIL PROTECTED]> a tapoté :

> Hi,
> 
> sometimes I read package descriptions I'm not happy with.
> E.g. the description starts: "Foobar is a GTK+ application,
> that enables blah..." where foobar is a user application,
> not mainly for GTK+ programmers.  Of course, the user
> doesn't/shouldn't care about GTK+ - and if, there's the
> dependencies listed anyway.  I remember, that we have some
> guidelines on package description, where you can read about
> this basics, but I cannot remember the URI.  Could someone
> help me, so that I can cite this guideline when filing a bug
> against such packages?

Check the debian policy.

(Well, why do you expect someone else to search thru the documentation
what you are looking for?)

This page may be helpful, however it's not official.


-- 
Mathieu Roy
 
  Homepage:
http://yeupou.coleumes.org
  Not a native english speaker: 
http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english

Re: On package description quality

[Mathieu Roy]

Tom <[EMAIL PROTECTED]> a tapoté :

> I disagree.  GUI apps in Linux are so wildly disparate that knowing the 
> basic architecture is pretty important for me to decide whether or not I 
> want it.

What a normal user care about is the purpose and features of software,
not the libraries (toolkit) used to build this software.

As said by Debacle, the user that cares about the toolkit used should
not have any problem to determine by other means than the description
which toolkit is used.

Talking about "GTK+" is confusing for a non-developer users. Well,
most Debian users should not be confused (if they are able to install
Debian, they are already very familiar with GNU/Linux) but even if
Debian currently have this specific audience (which knows the
difference between GTK, Qt, Tcl/tk, Motif, Lesstif (etc.)), packages
should not be built in the idea of keeping such a specific audience.

Debian packages should be usable with an apt frontend like synaptic by
end-users that frankly do not give a toss about toolkits.

(Side note: by GUI apps in Linux, are you talking about the GUI used by
make xconfig? The project Linux itself does not provide any GUI, your
phrase is very confusing.) 

Regards,  

-- 
Mathieu Roy
 
  Homepage:
http://yeupou.coleumes.org
  Not a native english speaker: 
http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english

Re: On package description quality

[John Hasler]

Tom writes:
> I disagree.  GUI apps in Linux are so wildly disparate that knowing the
> basic architecture is pretty important for me to decide whether or not I
> want it.

Only a small minority of users know what GTK+ means.  Those that do also
know how to check the dependencies.
-- 
John Hasler
[EMAIL PROTECTED] (John Hasler)
Dancing Horse Hill
Elmwood, WI

Re: On package description quality

[Tom Badran]

On Sunday 05 October 2003 15:45, Tom wrote:
> I disagree.  GUI apps in Linux are so wildly disparate that knowing the
> basic architecture is pretty important for me to decide whether or not I
> want it.

I second that, i consider that a very good guideline for how likely a package 
is going to integrate well with a particular DE. It also allows me to quickly 
determine that some package will have a major cascading dependency tree that 
i may or may not have installed. I also frequently will do a search for say 
"kde mail client" or such like and having kde/gtk/whatever in the description 
helps greatly on this.

Tom


pgpgZVj8Lbjui.pgp
Description: signature

Re: On package description quality

[Tom]

On Sun, Oct 05, 2003 at 05:03:54PM +0200, Mathieu Roy wrote:
> Tom <[EMAIL PROTECTED]> a tapot? :
> 
> > I disagree.  GUI apps in Linux are so wildly disparate that knowing the 
> > basic architecture is pretty important for me to decide whether or not I 
> > want it.
> 
> What a normal user care about is the purpose and features of software,
> not the libraries (toolkit) used to build this software.
> 

This is true.  However, as Microsoft and Apple seem to believe, it's not 
a nutty idea to believe that people care about how fonts look, clipboard 
operations work, and what the keyboard shortcut for File|Save is.  Call 
me nutty for buying into this.

Whether or not an app is GTK1, GTK2, Tcl/Tk, or QT3 makes a big 
difference to this.  So yes, the library doesn't matter, but the core 
feature set is kinda relevant.  Maybe you could find another way to 
describe it.

Re: Ideas about allowing Co-maintainer

[Thomas Hood]

On Sun, 2003-10-05 at 15:14, Mark Brown wrote:
> Have you tried working directly with upstream on these bugs?

The upstream maintainer is Andries Brouwer.  He says that he is
_very_ busy and that patches sent to him should be thoroughly
tested for several months before he will consider applying them.
It doesn't sound to me as if one works _with_ him on util-linux.

-- 
Thomas Hood <[EMAIL PROTECTED]>

Re: On package description quality

[Mathieu Roy]

Tom Badran <[EMAIL PROTECTED]> a tapoté :

> On Sunday 05 October 2003 15:45, Tom wrote:
> > I disagree.  GUI apps in Linux are so wildly disparate that knowing the
> > basic architecture is pretty important for me to decide whether or not I
> > want it.
> 
> I second that, i consider that a very good guideline for how likely a package 
> is going to integrate well with a particular DE. It also allows me to quickly 
> determine that some package will have a major cascading dependency tree that 
> i may or may not have installed. I also frequently will do a search for say 
> "kde mail client" or such like and having kde/gtk/whatever in the description 
> helps greatly on this.

KDE in the description makes more sense, IMHO, than Qt. The same goes
for GTK+ and GNOME.

A user should know which enviromnent he picked -- while he may totally
ignore that KDE is using Qt, for instance.

Descriptions should only care, I think, about full desktop environment,
not toolkit -- defined GUI style instead of libraries. If a software
is only GTK+, not _for_ GNOME, there are many reasons to believe that
this software does not follow the "tremendous" UI of GNOME.

Regards,



-- 
Mathieu Roy
 
  Homepage:
http://yeupou.coleumes.org
  Not a native english speaker: 
http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english

Re: On package description quality

[Tom Badran]

On Sunday 05 October 2003 16:22, Mathieu Roy wrote:
> KDE in the description makes more sense, IMHO, than Qt. The same goes
> gtk+ and GNOME.

Agree.

> A user should know which enviromnent he picked -- while he may totally
> ignore that KDE is using Qt, for instance.
>
> Descriptions should only care, I think, about full desktop environment,
> not toolkit -- defined GUI style instead of libraries. If a software
> is only GTK+, not _for_ GNOME, there are many reasons to believe that
> this software does not follow the "tremendous" UI of GNOME.

This is probably the best way i think. This sames to be the best compromise 
between having enough information without being over zealous in description.

Tom


pgpn2PglGefp7.pgp
Description: signature

Re: Discussion - Free the Debian Open Use logo

[Josip Rodin]

On Sat, Oct 04, 2003 at 05:35:14PM -0400, Simon Law wrote:
> The old Open Use logo was not DFSG-free, so we really shouldn't be
> shipping it in main.

Where are we shipping it in main? And even if we are (possibly somewhere in
the installation docs), who cares? It's our logo, for crying out loud, it's
not part of the operating system.

-- 
 2. That which causes joy or happiness.

Re: Discussion - Free the Debian Open Use logo

[Josip Rodin]

Hi,

Also, this is offtopic on -devel, -project is the right list.

-- 
 2. That which causes joy or happiness.

Bug#214246: ITP: aap -- make-like build system with Python scripting

[Cory Dodt]

Package: wnpp
Version: N/A; reported 2003-10-05
Severity: wishlist

* Package name: aap
  Version : 1.032 (or newer, upstream updates frequently)
  Upstream Author : Bram Moolenaar <[EMAIL PROTECTED]>
* URL : http://www.a-a-p.org/
* License : GPL
  Description : make-like build system with Python scripting
 A-A-P is a replacement for make, implemented in Python and with Python
 scripting by the author of ViM.  It has robust support for version
 control systems, can retrieve and publishing files via various network
 protocols, and has intelligent dependency generation.
 
 This package has an RFP, bug #198833.
 

-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux siena 2.4.18-bf2.4 #1 Son Apr 14 09:53:28 CEST 2002 i686
Locale: LANG=C, LC_CTYPE=C

Re: bug data mining

[Steve Langasek]

On Sun, Oct 05, 2003 at 09:38:56AM -0400, John Belmonte wrote:

> I didn't have any luck asking this question on debian-mentors, so I hope 
> it's ok to try here.

> Is there some resource that lets me find "overlooked" bugs-- for
> example, RC bugs older than 2 weeks and having no follow-up messages?
> If not, what is the best way to generate such a list on my own?

Generally, I think people are using
http://bugs.debian.org/release-critical/ and looking through the bugs
with ids lower than x.  I think you'll find that the majority of older
bugs there fall into this category (or have had follow-ups, but the
follow-ups themselves are older than 2 weeks), so it's a relatively
reasonable approximation.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Looking for a co-maintainer for adduser

[Scott James Remnant]

On Sun, 2003-10-05 at 12:41, Marc Haber wrote:
> On Sat, 04 Oct 2003 15:58:46 -0500, John Hasler <[EMAIL PROTECTED]>
> wrote:
> >But it would not be nice to not have the things that would leave with it

Re: bug data mining

[John Belmonte]

Steve Langasek wrote:
Generally, I think people are using
http://bugs.debian.org/release-critical/ and looking through the bugs
with ids lower than x.  I think you'll find that the majority of older
bugs there fall into this category (or have had follow-ups, but the
follow-ups themselves are older than 2 weeks), so it's a relatively
reasonable approximation.
Given bugs with no activity in 2 weeks, there's a huge difference 
between a bug with 50 follow-ups and a bug with no follow-ups.  I'd like 
to find an existing solution, or create a solution, to making these 
kinds of queries.

--
http:// if   le.o  /

Status of ruby transition in testing

[Steve Langasek]

The following is a summary of the state of the  ruby 1.6 -> 1.8
transition currently in progress.  For the most part, this is a soft
transition, with individual packages making the jump to testing as they
become ready, so a full transition is by no means mandatory for sarge.
However, a few of the packages may be of interest because of connections
to other library packages; and if people want ruby1.8 to be the default
ruby in sarge, there's a fair amount of work still needing to be done
because of the shuffling of binary package names between source
packages.


These packages are more or less ready to go:

libeb-ruby: eligible in spite of 212282 because there are no out-of-date
  binaries; however, it's waiting for eblook to be a valid candidate.
  An NMU is in DELAYED/3-day -- a maintainer upload would speed things
  up, otherwise this should all be ready by 10/18.
libwrap-ruby: too young, needs one more day day.
libxmms-ruby: valid candidate once the powerpc build is in (tomorrow).


These packages are ready on their own, but need ruby-defaults to be
ready at the same time because of other packages which depend on both
ruby and libstrscan-ruby:

libstrscan-ruby
libtmail-ruby
racc-runtime


These packages have no RC bugs and are up to date on all archs, but they
have dependencies on other packages that are not yet valid candidates.
Two of these are specifically tied up with the ruby-defaults knot.

rubymagick: waits on imagemagick, ruby-defaults.  We may want to remove
  rubymagick from testing, so that imagemagick et al. can be moved in
  the meantime.
libapache-mod-ruby: waiting on apache.  Should be rebuilt once
  apache 1.3.28 hits the archive (to use the new module package
  interface), but this won't hold it out.
libzlib-ruby: waits for apt-listbugs to be a valid candidate, which
  requires ruby1.6 on mips first.  Also invalidates debpartial, which
  needs libzlib-ruby (binary package), which now comes from
  ruby-defaults.


These packages all have outstanding RC bugs in unstable which keep the
respective packages out of testing:

libdb-ruby: 212103
libgd-ruby: 212105
libiconv-ruby: 214035
libpcap-ruby: 212265
libsdl-ruby: 212266
libshadow-ruby: 212268
libsufary-ruby: 212269
xmlrpc4r: 212298
vim: 211710; also out of date on sparc due to what looks like buildd
  breakage, and waiting on python2.3.


These packages are out of date on some architectures due to bug
#212282, which appears to now be fixed thanks to upstream.  They will
need to be re-queued on powerpc and/or arm.

eruby
libfam-ruby
libmysql-ruby
widestudio


These packages are also out of date on mips, because they build-dep on
ruby1.6 which has never been built there.  There's no sign that the
build has problems on mips, it's simply never been attempted.  Since
mips has been lagging behind recently, this will just need to run its
course, unless a decision is made to ignore mips for now.

gnome-ruby
libdbi-ruby
libexif-ruby
libpgsql-ruby
libvorbisfile-ruby
quantlib-ruby
mhc-utils


The ruby-defaults source package, which replaces the ruby source package
in testing, provides a number of binary packages previously provided by
other source packages.  These packages must therefore all be ready to go
into testing at the same time.  Maintainers of any of the packages
listed below are encouraged to exert peer pressure to get the rest of
the packages into order. :)

libstrscan-ruby
libtmail-ruby
racc
libiconv-ruby
libzlib-ruby

These packages also need to be updated in testing before ruby-defaults
can go in, although they don't have to be hinted in at the same time.
(Two of them should make it in tomorrow, in fact.)

libpcap-ruby
libpgsql-ruby
libshadow-ruby
libsufary-ruby
libwrap-ruby
libxmms-ruby
mhc-utils


Cheers,
-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Looking for a co-maintainer for adduser

[Marc Haber]

On Sun, 5 Oct 2003 10:54:50 +0100, Colin Watson <[EMAIL PROTECTED]>
wrote:
>I'd rather that the tools in Debian base were written in a high-level
>language where available. Take away Perl and you've got only shell, C,
>and C++ left; I don't think that's going to improve security in
>practice.

Well-written C++ using well tested class libraries tend to do a pretty
good job, security-wise.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber  |   " Questions are the | Mailadresse im Header
Karlsruhe, Germany  | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature  | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29

Re: On package description quality

[Josef Spillner]

On Sunday 05 October 2003 17:10, Tom wrote:
> Whether or not an app is GTK1, GTK2, Tcl/Tk, or QT3 makes a big
> difference to this.  So yes, the library doesn't matter, but the core
> feature set is kinda relevant.  Maybe you could find another way to
> describe it.

That's what package tags can be used for.

http://debian.vitavonni.de/packagebrowser/?tags=ui

Josef

-- 
Play for fun, win for freedom.
Linux-Info-Tag Dresden 2003: http://www.linux-dresden.de

Re: Looking for a co-maintainer for adduser

[Mark Brown]

On Mon, Oct 06, 2003 at 01:01:52AM +0200, Marc Haber wrote:

> Well-written C++ using well tested class libraries tend to do a pretty
> good job, security-wise.

I often find that well written code does a good job.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."

Re: Proposal - Free the Debian Open Use logo

[Benj. Mako Hill]

On Sun, Oct 05, 2003 at 12:07:05PM -0400, Simon Law wrote:
>  Debian Open Use Logo License
> 
>  Copyright (c) 1999 Software in the Public Interest
> -This logo or a modified version may be used by anyone to refer to the
> -Debian project, but does not indicate endorsement by the project.
> +This logo or a modified version may be used by anyone, but does not
> +indicate endorsement by the Debian project.
> 
>  Note: we would appreciate that you make the image a link
>  to http://www.debian.org/ if you use it on a web page.
> +
> +Note: this copyright license does not grant a trademark license.  If
> +it is applied to a trademark, you should be sure that you are not
> +violating trademark rights.
> 
> 
> Rationale:
> The old Open Use logo was not DFSG-free, so we really shouldn't be
> shipping it in main.  The proposed license keeps the spirit of the old
> one, while not restricting the logo's use.
> 

Simon, there are a number of problems with Debian trademark policy and
the lack thereof and this only one. This was part of the rationale
behind the creation of a trademark committee over at SPI that is
trying to draft some new legal policy recommendations with the Debian
mark in mind (but hopefully not only useful for Debian). More
information about the committee and about project (including info on
joining) is in this thread:
  
http://lists.debian.org/debian-project/2003/debian-project-200309/msg4.html

The committee has been discussed at Debconf3, on -project (in the
Trusted Debian/Adamantix discussion) the SPI lists, and a couple other
places. The thread on -project highlighted the need for more
visibility so Martin Michlmayr and I have been preparing a formal
announcement for Debian.

Since there are already people working on this, I think that the most
constructive thing will be to follow up on the DPL's announcement in
regards to the trademark committee and to get involved in the efforts
already underway.

Regards,
Mako


-- 
Benjamin Mako Hill
[EMAIL PROTECTED]
http://mako.yukidoke.org/



pgpE8n2MQqvpa.pgp
Description: PGP signature

Re: Format of Release file and tools to create

[Guillem Jover]

Hi,

On Wed, Sep 24, 2003 at 08:39:06PM +, [EMAIL PROTECTED] wrote:
> where can I find the "official" definition for the Release
> file (http://ftp.us.debian.org/debian/dists/sarge/Release),
> e.g. a BNF or an informal description?
> 
> Which is the tool (of choice) to create the files?
> 
> How are the lines with the md5sums created?

The script is called ziyi is part of dak and can be found at:

  

regards,
guillem

Re: Debian and the GNU Free documentation license

[Manoj Srivastava]

Hi folks,

   It's been a few days since my last message. I have added a print
 style sheet, so one can use a free Browser (mozilla) to print the
 position statement. I have added a couple of new examples, an
 inchoate software documentation freedoms list, and I have started an
 outline of the formal position statement at the top of the docs.
 That should develop into the integrated position statement we'll put
 to vote.

The URL of the document is:
 http://people.debian.org/%7Esrivasta/Position_Statement.xhtml>

manoj
-- 
New Hampshire law forbids you to tap your feet, nod your head, or in
any way keep time to the music in a tavern, restaurant, or cafe.
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: Discussion - Free the Debian Open Use logo

[Simon Law]

M-F-T set to debian-project.

On Sun, Oct 05, 2003 at 06:23:40PM +0200, Josip Rodin wrote:
> On Sat, Oct 04, 2003 at 05:35:14PM -0400, Simon Law wrote:
> > The old Open Use logo was not DFSG-free, so we really shouldn't be
> > shipping it in main.
> 
> Where are we shipping it in main? And even if we are (possibly somewhere in
> the installation docs), who cares? It's our logo, for crying out loud, it's
> not part of the operating system.

We are including it with X display managers, as wallpaper, in
icons, and other assorted places throughout the main archive.  Since our
Open Use logo ships in main, it must be licensed in a DFSG-free manner.

Simon


pgpI9f02OmqY0.pgp
Description: PGP signature

Re: Debian should not modify the kernels!

[Herbert Xu]

Tollef Fog Heen <[EMAIL PROTECTED]> wrote:
> * Herbert Xu 
> 
> | Very few people really need cramfs if they're building custom kernels.
> | This is because initrd only makes sense when you're building for a
> | large number of machines.  If you're building a custom kernel, just
> | compile in all the drivers you need for mounting root and that's that.
> 
> Except if you want to use EVMS or similar on /, in which case you need
> the evms userspace tools on the initrd.  (Using 2.6, that is, in 2.4
> the discovery is done in kernel-space.)

That's right.

But even in that case you don't need cramfs as romfs should work.

Cheers,
-- 
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Looking for a co-maintainer for adduser

[Bob Proulx]

Marc Haber wrote:
> Colin Watson wrote:
> >I'd rather that the tools in Debian base were written in a high-level
> >language where available. Take away Perl and you've got only shell, C,
> >and C++ left; I don't think that's going to improve security in
> >practice.
> 
> Well-written C++ using well tested class libraries tend to do a pretty
> good job, security-wise.

Saying "well-written" is cheating.  Any well written program is always
good by definition or it is not be well written.  But what about
poorly written cruft?  Almost all languages are easy to write badly.
But some are easier than others.  Both C++ and Perl come to my mind
when I think of bad programming practices and swiss army chainsaws.

Bob


pgppvqBwloD23.pgp
Description: PGP signature

Re: Ideas about allowing Co-maintainer

[David B Harris]

On 05 Oct 2003 13:13:55 +0200
Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> There is no point for me working on those bugs if the patches will
> just rod in the bts or be thrown out so as not to differ from
> upstream. As I said before I won't work on the debian package again
> without an assurance by the maintainer that he will look at it.

I've occasionally helped out with util-linux, and I must say that
Debian's util-linux is already markedly different from upstream's, and
this isn't a good thing.

It's already bitten people once; for instance, it's unlikely that
cryptoloop volumes created with Debian's util-linux will work on other
machines (the passphrase is hashed before use in Debian's util-linux,
and I don't believe it's done elsewhere.)

As others have suggested, if you have fixes to upstream bugs, the best
place to send them is to upstream.

Failing that, you can always file them in the BTS and forward them
upstream yourself.


pgp9jP1FF6mg3.pgp
Description: PGP signature

Re: Bug#214248: info in unstable cannot find documentation

[Brian May]

On Sun, Oct 05, 2003 at 07:26:31PM +0200, Jeffrey Eugene Crawford wrote:
> Package: heimdal-docs
> Version: 0.6-3
> Severity: important
> File: heimdal-doc
> Tags: sid
> 
> After installing this package I could not read the info documentation even 
> when
> trying to read it with info's "-f" option. This makes the info documentation
> of "heimdal-doc" unusable.

Hello,

Are there any info experts how are able to help me with this bug?

It seems to work fine on stable.

Thanks in advance.
-- 
Brian May <[EMAIL PROTECTED]>

Re: Bug#214248: info in unstable cannot find documentation

[Peter S Galbraith]

Brian May <[EMAIL PROTECTED]> wrote:

> On Sun, Oct 05, 2003 at 07:26:31PM +0200, Jeffrey Eugene Crawford wrote:
> > Package: heimdal-docs
> > Version: 0.6-3
> > Severity: important
> > File: heimdal-doc
> > Tags: sid
> > 
> > After installing this package I could not read the info
> > documentation even when trying to read it with info's "-f"
> > option. This makes the info documentation of "heimdal-doc" unusable.
> 
> Hello,
> 
> Are there any info experts how are able to help me with this bug?
> 
> It seems to work fine on stable.

The heimdal.info file contains:

---
This is heimdal.info, produced by makeinfo version 4.0 from
heimdal.texi.

INFO-DIR-SECTION Heimdal
START-INFO-DIR-ENTRY
* Heimdal: (heimdal).   The Kerberos 5 distribution from KTH
END-INFO-DIR-ENTRY


Indirect:
heimdal.info-1: 210
heimdal.info-2: 47804
---

Yet the file is _not_ split in two.

Why?  I don't know.

Peter

Re: Looking for a co-maintainer for adduser

[steve]

On Sun, Oct 05, 2003 at 05:18:45PM -0600, Bob Proulx wrote:

> Saying "well-written" is cheating.  Any well written program is always
> good by definition or it is not be well written.  But what about
> poorly written cruft?  Almost all languages are easy to write badly.
> But some are easier than others.  Both C++ and Perl come to my mind
> when I think of bad programming practices and swiss army chainsaws.

  I think the point is that good code and bad code are possible in any
 language, and the panacea of switching to a particular language and 
 expecting all coding programs to go away is simplistic and unrealistic.

  Sure in some languages like Java there aren't going to be pointer
 problems, but other avenues of attack are just as likely; insecure use
 of temporary files, symlink attacks, signal attacks and etc.

Steve
--
# Debian Security Audit Project
http://www.steve.org.uk/Debian/

Re: /usr/doc symlinks

[Graham Wilson]

On Sun, Oct 05, 2003 at 09:50:41AM +0200, Santiago Vila wrote:
> Does anyone have a good estimation about the number of packages which
> currently do this? (That is, assume *blindly* that /usr/doc exists).

I have 687 packages on my system and 35 of them have symlinks in
/usr/doc. If the number on my system scales to the number of packages in
main (12209), that would make about 622 packages that still have
symlinks to /usr/doc.

This doesn't however, answer the question about how many packages
*blindly* assume that /usr/doc exists. For example, looking at the
postinst of one package on my system, it checks to see if /usr/doc is a
directory first before symlinking.

-- 
gram


signature.asc
Description: Digital signature

Kernel source 2.4.22 and ipvs problems

[Bao C. Ha]

Hello all,

I am trying to patch the kernel 2.4.22 and got into troubles.  It seems
that the Debian kernel has been patched to do away the pmtu field of
the struct dst_entry (include/net/dst.h).

Any sugegstions on how to get it working again.  The last working Debian 
kernel with IPVS is 2.4.20.

Thanks.
Bao
-- 
Best Regards.
Bao C. Ha
Hacom OpenBrick Distributor USA http://www.hacom.net
voice: (714) 530-8817 fax: (714) 530-8818
8D66 6672 7A9B 6879 85CD 42E0 9F6C 7908 ED95 6B38

Re: developers Japanese and Chinese names' original characters

[Dan Jacobson]

> Chinese names from different regions are romanized using
> incompatible schemes, sometimes even *inconsistent* schemes.  Only
> mainland Chinese use a consistent scheme (Pinyin).

Here in Taiwan they have placed a nut in charge of this.  He will be
gone after the  Mar. 2004 election
though. http://jidanni.org/lang/pinyin/

< I do think having a list of native DD names would be novel, at least,
< but it would have to be manually maintained.

Perhaps it could be put on the people.debian.org or developer lookup
/ search developer by region website...

Or maybe add a field for the developers name in unicode if non-ascii, on
the standard info webpage for each developer, that I recall seeing somewhere.