Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries

[Chris Cheney]

On Fri, Dec 12, 2003 at 05:47:17PM -0700, Bruce Sass wrote:
> On Fri, 12 Dec 2003, Chris Cheney wrote:
> > On Wed, Dec 10, 2003 at 01:28:51PM -0700, Bruce Sass wrote:
> <...>
> > .desktop files are not bloated... period. They include i18n which for
> > you is bloat since you obviously can communicate in English.
> 
> "not bloated... period", yet you admit the translations are bloat for
> someone who doesn't need them.  Can you also accept the X-KDE-* stuff
> is bloat for every menu data consumer except KDE (ditto for Gnome
> specials), and that in general freedesktop features are bloat for
> everyone who doesn't support the freedesktop standard.

Bloat is relative, since i18n is needed by a large amount of people,
certainly more than need english it is not really bloat. Certainly it
isn't bloat for the 5Bil+ people whose language isn't english. Something
you might determine is a critical feature someone else might consider
bloat. Yes, X-KDE-* could be considered to be bloat by some people.
However, the same people who have systems fast enough to actually run
Gnome or KDE also have large enough hard drives that it shouldn't even
be a consideration. Across all desktop files in the archive that
probably amounts to less than 100KB of additional space. Bitching about a
loss of 100KB when the same packages overall take 500MB+ is very petty.
And no I do not think that the freedesktop standard overall is bloat.

> > As I mentioned further down in this message Konqueror only uses 159
> > bytes when all i18n is stripped from it. I see many debian menu
> > files that are larger than this and they don't contain i18n either.
> 
> I suspect those files contain more than one menu entry; KDE has a file
> per entry, menu uses a file per package which contain multiple menu
> entries.

Yes that is true, so I went and got the konqueror menu file to compare.
Just the one entry for the file browser which is equivalent to the
.desktop file is bigger than the .desktop file without its i18n support.
And add to that the fact that the .menu description is shorter which
further disproves the point that .desktop files are larger.

.desktop - 159 bytes

[Desktop Entry]
Encoding=UTF-8
Type=Application
Exec=kfmclient openProfile webbrowsing
Icon=konqueror
DocPath=konqueror/index.html

Name=Konqueror Web Browser


.menu - 168 bytes

?package(konqueror):\
needs=X11\
section=Apps/Net\
hints="KDE,Web browsers"\
kderemove="y"\
title="Konqueror"\
command="/usr/bin/konqueror --profile webbrowsing"

> > If several KDE and Gnome developers got together and rewrote the
> > menu-methods for the various WM's would that satisfy you?
> 
> No, because it doesn't address the primary concern of (say) a Fluxbox
> user needing to process the KDE, Gnome, and freedesktop stuff which
> they don't have a use for.

I contend that the processing the time difference would not be sufficient
to tell the difference over extracting and installing packages on the
system. And the only time menus get rebuilt normally is when you are
installing new packages. Systems old enough to worry about this also
typically don't have hundreds of menu files to deal with as well since
their hd's are too small. As someone else stated regenerating all the
menu files included with KDE (which is several hundred iirc) takes less
than 10s on an Athlon 600, which is about a 5 year old system.

> > > 1 or 2 hundred bytes vs. a couple to few thousand bytes _per_entry_;
> > > what percentage of resources that takes depends on the system... it
> > > may be a drop in the bucket for KDE and Gnome users, who are likely to
> > > have very capable machines, but what about those who don't have the
> > > resources to run KDE or Gnome---why should they be stuck with
> > > processing useless stuff they likely can't afford and obviously don't
> > > want?  The entire menu hierarchy is regenerated everytime a package
> > > containing a menu entry is installed or removed.
> >
> > I call bullshit on this one. desktop files with no i18n are not several
> > thousand bytes _pre_entry_.  And the fact that those other WM's don't
> > support should be considered a bug not a feature... For example the
> > Konqueror .desktop file is 159 bytes with no i18n or 2234 with it. If as
> > we suggested earlier the Debian menu format gain i18n support then it
> > would be just as big as .desktop (probably actually since Debian has
> > very limited i18n support).
> 
> Ok, the .desktop file sizes are typically between 1 and 2K---but you
> don't have to look too hard to find 3 or 4K .desktop files, and some
> of the (admitedly KDE specific) files are over 10K.  Yup, that last
> bit is FUD: I fear it is the future of .desktop files, I'm uncertain
> they are atypical, and I doubt that 1-2K will be the norm...
> especially since the example (/usr/share/applnk/konqueror.desktop) you
> are holding up is 3748 bytes and incomplete (only 7 "Name" and over 3
> dozen "Comment" items) on my b

Re: Release-critical Bugreport for December 12, 2003

[Grzegorz B. Prokopski]

W liście z pią, 12-12-2003, godz. 07:30, BugScan reporter pisze: 
> Some bugs have an additional set of tags indicating they only apply
> to a particular release: O for oldstable (potato), S for stable (woody),
> T for testing (sarge) or U for unstable (sid). X indicates that the package
> is not in testing.

> Package: sablevm (debian/main)
> Maintainer: Grzegorz Prokopski (Debian Developer) <[EMAIL PROTECTED]>
>   215314 [] FTBFS on some platforms (SableVM*test* versions)

The thing is that #215314 has tag: sid bacause it only applies to
unstable version (upstream release is on its way and will close it).

Version in testing is clean and robust and I wouldn't want it to be
at some point removed from testing because of a bug in unstable.

So - shouldn't there be [U] mark for this bug? sth. like:

  215314 [] [U] FTBFS on some platforms (SableVM*test* versions)

Am I missing something?

Grzegorz B. Prokopski

-- 
Grzegorz B. Prokopski <[EMAIL PROTECTED]>
Debian GNU/Linux  http://www.debian.org
SableVM - LGPLed JVM  http://www.sablevm.org


signature.asc
Description: To jest =?iso-8859-2?Q?cz=EA=B6=E6?= listu podpisana	cyfrowo

Re: Nice multilingual environment with Debian menu

[Osamu Aoki]

Hi,

On Fri, Dec 12, 2003 at 02:21:25PM -0500, Joe Drew wrote:
> On Fri, 2003-12-12 at 12:43, Osamu Aoki wrote:
> >   * UTF-8 console with English locale
> >   * UTF-8 console with Japanese locale
> 
> Why are these different? 

Try "man man", "ls -l" or "date", you get different answers.

locale is not just encoding but sort order, message, time stamp style, 
... and more.

> It isn't really laid out in the document linked

I do not understand what you mean.

> does this mean different input methods?

Yes.

Actually, uxterm under ja_JP.UTF-8 brings out xim(kinput2 for me) but
not in en_US.UTF-8.  I guess in en_US.UTF-8, compose key is active to
make accented characters (not tested).

Since I start console programs in the customized locale, this change of
the console program behavior can be enjoyed.  If I were still using
hacks in my shell start up script[*1], I would not have enjoyed this in
uxterm.

Anyway, my point in posting this also in -devel was that Debian menu is
very useful tool if you know how to use it. 

Osamu

[*1] I used to detect console in ~/.bashrc by:
TERMPPID=$(ps --no-header -p $PPID |awk  '{ print $4 }')
TERMUXTERM=$(ps --no-header -Cp  $PPID | awk  '{ print $7 }')

mounting tmpfs (and sysfs) defaultly in sarge?

[GOTO Masanori]

Hi,

Tmpfs in Linux kernel 2.4, is formally known as shmfs (posix shared
memory filesystem).  It's useful for memory-based filesystem like
Solaris tmpfs.  However, if we support new Posix IPC like shm_open(3),
shm_unlink(3), to make debian posix compliant (and like other
distros), it should be mounted on /dev/shm.  In the past there were
some discussed, ex:


http://lists.debian.org/debian-devel/2001/debian-devel-200111/msg00706.html

So I propose:

  - /dev/MAKEDEV should have /dev/shm in "std" entry.
  - /etc/fstab should mount /dev/shm (tmpfs) in default.


BTW, the coming Linux kernel 2.6 will support sysfs, replacement for
procfs (/proc).  It's useful if we have /sys directory for kernel 2.6.
So I also think sysfsutils or base-files should create /sys and put
sysfs entry in /etc/fstab in the near feature.  It may be a bit early
to add, though.

Any comments?

Regards,
-- gotom

Re: Release-critical Bugreport for December 12, 2003

[Goswin von Brederlow]

Henning Makholm <[EMAIL PROTECTED]> writes:

> Scripsit Goswin von Brederlow <[EMAIL PROTECTED]>
> > BugScan reporter <[EMAIL PROTECTED]> writes:
> 
> > > Package: chrony (debian/main)
> > > Maintainer: John Hasler <[EMAIL PROTECTED]>
> > > [REMOVE]
> > >   223134 [] chrony: FTBFS: Errors in kernel headers
> 
> > Why is chrony getting removed?
> 
> AFAIU, the "[REMOVE]" tag means that the release manager thinks that
> *if* we do not succeed in fixing this bug, *then* it is reasonable to
> remove the package from sarge rather than letting it delay the
> release.  It does not imply that the bug is less likely to get fixed
> than bugs without the tag. (And if it does get fixed, of course it
> will not cause the package to be removed).

But the bug realy is caused by the brokenness of
linux-kernel-headers (which is still not renamed). If anything should
get removed its the broken glibc/linux-kernel-header combination.

I find it a bit strange to add a "remove" to foo if bar broke foo
yesterday.

> The first step in getting concrete information is always to look at
> the bug in the BTS. Here you'll find that the maintainer of crony is
> working on the bug and has filed three comments within the last week.
> 
> > >   223145 [] defrag: FTBFS: Errors in kernel headers
> 
> > (If the maintainer is unresponsive or something I would adopt either
> > package.)
> 
> This bug is less than a week old, so it's a little early to declare
> that the maintainer is unresponsive.

I saw activity from chrony. And I see that the defrag bug is about
minix which could be savely droped I think.

I'm just wondering who set the remove tag and why because I see
absolutely no reason for them due to the nature of the error and the
timeframe associated with the bug.

MfG
Goswin

Re: APT-Fu 0.2.3

[Herbert Xu]

Colin Walters <[EMAIL PROTECTED]> wrote:
> 
> But your message didn't include a Content-Type header specifying that,
> so it's likely to come through as garbage for most MUAs...

Right, here it is again

\xEF\xBB\xBF\xE8\xBE\xAD\xE6\xB5\xB7
-- 
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: mounting tmpfs (and sysfs) defaultly in sarge?

[Martin Pitt]

Hi!

On 2003-12-13 16:19 +0900, GOTO Masanori wrote:
> BTW, the coming Linux kernel 2.6 will support sysfs, replacement for
> procfs (/proc).  It's useful if we have /sys directory for kernel 2.6.
> So I also think sysfsutils or base-files should create /sys and put
> sysfs entry in /etc/fstab in the near feature.  It may be a bit early
> to add, though.

I already thought about this; when 2.6 becomes stable, I intent to
upload a new revision. But I still have some questions:

- may the package libsysfs alter /etc/fstab? According to 
  'dpkg -S /etc/fstab' it does not really belong to a specific package
  (in this case modification would be prohibited IIRC). ATM my
  favourite solution is to have a debconf question. What do you think?
  normal/default yes, important/default no or even normal/default no?

- I sometimes switch to my old 2.4 for testing purposes. Then of
  course mounting /sys will fail and the user will get an error
  message (it doesn't harm, though). This problem could only be
  circumvented by not mounting /sys in /etc/fstab, but doing that in
  an init script which checks which kernel version runs ATM. Do you
  think that it is worth the effort?

- By now I don't allow sysfsutils to go into Sarge because it isn't
  used yet (udev, diagnostics...). My personal feeling is to wait
  until kernel 2.6 stable is in sarge and udev is in unstable and
  works.

I appreciate any hints and comments.

Have a nice weekend!

Martin
-- 
Martin Pitt Debian GNU/Linux Developer
[EMAIL PROTECTED]  [EMAIL PROTECTED]
http://www.piware.de http://www.debian.org


signature.asc
Description: Digital signature

Ваш адрес заблокирован.

[Organelle M. Cowardliness]

ПРЕДЛОЖЕНИЯ ПО ВЫДЕЛЕННЫМ СЕРВЕРАМ (дата-центры заубежа и России).
icq 510642, e-mail: [EMAIL PROTECTED]


AMD Duron™ 800MHZ (95$/месяц)

AMD Duron™ 800MHZ
Memory: 256MB PC133 SDRAM
Hard Drive: 30GB IDE или 9GB SCSI
Трафик: 100GB/MONTH
IP Addresses: 5
Port: 10/100MBPS SWITCHED VLAN
Management: FULLY MANAGED
$30.00 установка  $ 95.00 ежемесячно

ранд
-

Intel Celeron™ 1.0GHZ (105$/месяц)

Intel Celeron™ 1.0GHZ
Memory: 256MB PC133 SDRAM
Hard Drive: 30GB IDE or 9GB SCSI
Трафик: 100GB/MONTH
IP Addresses: 5
Port: 10/100MBPS SWITCHED VLAN
Management: BASIC MANAGED
$30.00 установка  $105.00 ежемесяно

Дфиток
-

AMD Athlon™ XP 1700 1.47GHZ (130$/месяц)

AMD Athlon™ XP 1700 1.47GHZ
Memory: 256MB PC133 SDRAM
Hard Drive: 40GB IDE or 18GB SCSI
Трафик: 100GB/MONTH
IP Addresses: 5
Port: 10/100MBPS SWITCHED VLAN
Management: BASIC MANAGED
$30.00 установка  $130.00 ежемесячно

Кеукро
-

Intel Pentium™ 4 1.5GHZ (160$/месяц)

Intel Pentium™ 4 1.5GHZ
Memory: 256MB PC133 SDRAM
Трафик: 40GB IDE or 18GB SCSI
Bandwidth: 1000GB/MONTH
IP Addresses: 5
Port: 10/100MBPS SWITCHED VLAN
Management: BASIC MANAGED
$30.00 установка  $160.00 ежемесячно

Элилаволд
-

Intel Pentium™ 4 1.7GHZ  (170$/месяц)

Intel Pentium 4™ 1.7GHZ
Memory: 512MB DDR RAM
Hard Drive: 60GB IDE or 9GB SCSI
Трафик: 1000GB/MONTH
IP Addresses: 5
Port: 10/100MBPS SWITCHED VLAN
Management: FULLY MANAGED
$100.00 установка $170.00 ежемесячно

Мхауаре
-

Intel Celeron™ 2.4GHZ (170$/месяц)

Intel Celeron™ 2.4GHZ
Memory: 512MB DDR RAM
Hard Drive: 60GB IDE or 9GB SCSI
Трафик: 1000GB/MONTH
IP Addresses: 5
Port: 10/100MBPS SWITCHED VLAN 
Management: FULLY MANAGED
$100.00 установка $170.00 ежемесячно

Твивил
-

Intel Pentium 4™ 2.4MHZ (215$/месяц)

Intel Pentium 4™ 2.4GHZ
Memory: 512MB DDR RAM
Hard Drive: 80GB IDE or 36GB SCSI
Трафик: 1000GB/MONTH
IP Addresses: 5
Port: 10/100MBPS SWITCHED VLAN
Management: FULLY MANAGED
$200.00 установка  $215.00 ежемесячно

Юслвунек
-

DUAL Intel Pentium 3™ 800MHZ (200$/месяц)

Intel Pentium 3™ DUAL 800MH
Memory: 256MB PC133 SDRAM
Hard Drive: 40GB IDE or 18GB SCSI
Трафик: 1000GB/MONTH
IP Addresses: 5
Port: 10/100MBPS SWITCHED VLAN
Management: BASIC MANAGED
$100.00 установка  $200.00 ежемесячно

Уукил



:::CЕРВРЕА В РОССИИ, не ограниченный* траффик:

Ниркен


Pentium IV Celeron 1.7GHz (179$/месяц)

Pentium IV Celeron 1.7GHz
Memory: 512Mb RAM
Hard Drive: 20Gb IDE
Трафик: неограничен*
$100.00 установка  $179.00 ежемесячно

Уяситог
-

Pentium IV 2.4GHz (249$/месяц)

Pentium IV 2.4GHz 
Memory: 1Gb RAM
Hard Drive: 40Gb IDE
Трафик: неограничен*
$150.00 установка  $249.00 ежемесячно

Лолбюз
-

Dual Pentium III 1.26GHz (310$/месяц)

Dual Pentium III 1.26GHz
Memory: 1Gb RAM
Hard Drive: 36Gb UW SCSI
Трафик: неограничен*
$150.00 установка  $310.00 ежемесячно

Лолома
-


но  и  вмешательства со  стороны  соседки, впервые  предложившей  мне  более

Re: Release-critical Bugreport for December 12, 2003

[Mark Howard]

I think the distinction between sid RC bugs and all RC bugs was removed
at some point, without telling us. Take a look at the gjdoc package -
there are two RC bugs tagged sarge and one tagged sid, but the testing
scripts are not upgrading the version in testing, even though it would
close two rc bugs and reduce the number of rc bugs for sarge.

On Sat, Dec 13, 2003 at 01:13:23AM -0500, Grzegorz B. Prokopski wrote:
> The thing is that #215314 has tag: sid bacause it only applies to
> unstable version (upstream release is on its way and will close it).
> 
> Version in testing is clean and robust and I wouldn't want it to be
> at some point removed from testing because of a bug in unstable.
> 
> So - shouldn't there be [U] mark for this bug? sth. like:

-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] 


signature.asc
Description: Digital signature

Re: mounting tmpfs (and sysfs) defaultly in sarge?

[Roger Leigh]

GOTO Masanori <[EMAIL PROTECTED]> writes:

> Tmpfs in Linux kernel 2.4, is formally known as shmfs (posix shared
> memory filesystem).  It's useful for memory-based filesystem like
> Solaris tmpfs.  However, if we support new Posix IPC like shm_open(3),
> shm_unlink(3), to make debian posix compliant (and like other
> distros), it should be mounted on /dev/shm.  In the past there were
> some discussed, ex:
>
>   
> http://lists.debian.org/debian-devel/2001/debian-devel-200111/msg00706.html
>
> So I propose:
>
>   - /dev/MAKEDEV should have /dev/shm in "std" entry.
>   - /etc/fstab should mount /dev/shm (tmpfs) in default.

Please make sure that when this is added, you do default to a sensible
size option.  For example:

none/dev/shmtmpfsdefaults,size=500M00

If you don't specify a default limit, any user can kill the system by
creating a huge file in there.  It's much nicer to get ENOSPC than a
kernel panic.  The installer could pick a sensible limit based on, for
example, 20% of the combined core+swap size.


-- 
Roger Leigh

Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.

Re: Bug#223781: [RFA]: usemod-wiki -- Perl-based Wiki clone

[Peter Gervai]

Hello Julian,

On Sat, Dec 13, 2003 at 12:33:19AM +0100, Julian Mehnle wrote:
> Alexander Wirt wrote:
> > Am Fr, den 12.12.2003 schrieb Julian Mehnle um 15:32:
> > > Benjamin Drieu wrote:
> > > > I no longer use usemod-wiki and thus have no time to maintain it.
> > > > Package is in good shape, no serious bugs.  Very few work is needed
> > > > to maintain it as release cycle is quite long.
> > > > 
> > > > The only one todo item is to package version 1.0, which requires
> > > > some changes to the wiki database.  Peter Gervai <[EMAIL PROTECTED]>
> > > > has already made a package for this and is going to NMU
> > > > usemod-wiki.  But as he does not have time to adopt it, we need a
> > > > new maintainer. 
> > > 
> > > As I'm using UseMod Wiki on a slew of Debian machines, I'd be more
> > > than willing to continue maintaining usemod-wiki, but I'm no Debian
> > > Developer, so I'd need a sponsor until I decide and manage to become
> > > one. 
> > 
> > I use it on some systems too, so I would be pleased to be your sponsor.
> > Get in touch with me if you have packages ready for upload/inspection.
> 
> Are you going to do an NMU wrt usemod-wiki 1.0?

I would like to avoid to adopt another package if possible, so if you want
to have it please be our guest.

>  If yes, are you going to
> include an automatic upgrade mechanism for old singlebyte Wikis?  If yes,
> I'll wait for that NMU before starting my own packaging work.

Well no. But what's funny is that I just installed 1.0, changed it to utf8,
did what the readme told me and it worked... 

> Otherwise, would you mind sending me whatever you have packaged up for
> 1.0, so I can add an automatic upgrade mechanism (which I'd really like to
> include with the initial release of the 1.0 Debian package)?

Of course I don't mind, feel free to use it!

see: http://narya.grin.hu/cgi-bin/viewcvs.cgi/trunk/usemod-wiki/ if you
wonder what did I change, or ftp://narya.grin.hu/pub/debian/ to get all the
stuff.

Best wishes,
Peter

Bug#223856: ITP: cslh -- a live support chat system.

[Neil McGovern]

Package: wnpp
Severity: wishlist

  Package name: cslh
  Version : 2.8
  Upstream Author : Eric <[EMAIL PROTECTED]>
  URL : http://www.craftysyntax.com/CSLH/
  License : GPL
  Description : A live support chat system.

Crafty Syntax Live Support (cslh) is a live help support chat system
that allows the operators of the websites to monitor their visitors as
they are browsing the site and proactively open a chat session with the
visitor. 
Other features include Mysql database, chat notification, user is typing
message, multiple chat sessions, referer tracking, page view tracking
and multiple operators.

你知道我们吗

[[EMAIL PROTECTED]]

www.centuryweb.net世纪网络-先试用　后付款

[EMAIL PROTECTED]
   
　　
网络实名注册

国内虚拟主机租用价格 ：   

1. 140元＝1年国际域名＋300mb＋10个email

2. 180元＝1年国际域名＋200mb＋10个email(支持cgi.asp)

3. 240元＝1年国际域名＋300mb＋20个email(支持cgi.asp)；

4. 360元＝1年国际域名＋500mb＋30个email(支持cgi.asp)；

5. 260元＝2年国际域名＋300mb＋10个email

6. 340元＝2年国际域名＋200mb＋10个email(支持cgi.asp)

7. 480元＝2年国际域名＋300mb＋20个email(支持asp、php)；

8. 660元＝2年国际域名＋500mb＋30个email(支持asp、php)

为了保护您的域名权利，我公司现办理由美国eNom公司授权颁发的国际域名证书，证书费用为60元/个（另付）。

 　　
　---服务器主机托管，租用报价

? 服务器机房直接连接于ChinaNet骨干网高度，接入方式：100M LAN共享
◆ 服务器主机托管： 
   高度 国内报价 　　　1U、2U、4U及组装　　　￥ 5800元/年 

   主机托管月付680元。

◆ 服务器主机租用(主机租用期?壹年后，主机归租用人所用)
   高度　国内报价 
1U 　￥ 11000元/年 
2U 　￥ 17000元/年 
? 服务器配置：
　CPU P4 1.6G内存 512M DDR   硬盘 40GHD 


*免费提供机架、免费提供1个IP地址、提供7*24小时的网络监控、
 主机系统监测服务 ，硬件可按客户要求另行配置 


主题：虚拟主机130元/300M空间 主机托管5800/年/台 先试用后付款
详情：www.centuryweb.net 
[EMAIL PROTECTED]
本邮件只发一次，如有打扰万望海涵！

Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries

[Moritz Moeller-Herrmann]

Cameron Patrick wrote:

> On Fri, Dec 12, 2003 at 04:12:58AM +0100, Moritz Moeller-Herrmann wrote:

> | This is not true. Almost all features are being used in current KDE and
> | to some degree by current GNOME. Could you please give examples?
 
> The Categories= field (to place .desktop files into menu hierarchies) is
> AFAIK not used at all by KDE, although I think Gnome may support it.
> The freedesktop 'menu' standard (where sub-menus can be generated from
> the categories in the .desktop files, and which also claims to allow
> "legacy" menus to be merged with the new standard) doesn't seem to have
> been adopted yet by anyone. 

It is supported and used in KDE-3.2beta. KDE-3.2 should be released in
January.

> The worst part, though, is that currently 
> both KDE and Gnome store their .desktop files in different places, so
> that a .desktop that is available to KDE (and placed in /usr/lib/applnk)
> won't automatically appear in the Gnome menu, which looks in
> /usr/lib/applications.  I presume that these things are being worked on
> in later releases of KDE and Gnome, but I don't know where to look for
> the current status of their adoption of the freedesktop.org standards.

Again, please have a look at KDE-3.2. I am currently using the KDE CVS
debian snapshots. KDE stores all it's desktop files in /usr/share
applications and GNOME uses the same directory. 
Of course the system can and will be improved, once it is generally adopted.

> I have also noticed what might be considered as 'abuse' of these
> standards, presumably due to poor implementation of some fields.  For
> example, /usr/share/applications/epiphany.desktop lists its Name as "Web
> Browser"; it should more correctly list its name as "Epiphany" and have
> a GenericName field containing "Web Browser".

Not all desktop files are perfect yet. Especially those not part of the DE.
But this should not be fixed downstream.

Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries

[Cameron Patrick]

On Fri, Dec 12, 2003 at 01:11:12PM +0100, Moritz Moeller-Herrmann wrote:

| It is supported and used in KDE-3.2beta. KDE-3.2 should be released in
| January.
[...]
| Again, please have a look at KDE-3.2. I am currently using the KDE CVS
| debian snapshots. KDE stores all it's desktop files in /usr/share
| applications and GNOME uses the same directory. 

Woo, good to hear it!  I stand corrected, then. :-)

Cameron.

自由空间迎元旦特增开100MB我精简免费邮箱

[365集团]

  我们服务栏目如下：
  邮箱业务： 免费性100MB/1  开放日期 2003/12/15~2003/12/31  申请网址: 
http://www.f365.com.cn
  免费电影下载： http://www.f365.com.cn/movie/
  虚拟主机业务： 特酬宾 6 折
  music : 200万首音乐下载
  网站制作： 从2003/12/15起所有网站制作免费赠送域名
  个人主页空间： 100兆提供！！！

Re: mounting tmpfs (and sysfs) defaultly in sarge?

[Miquel van Smoorenburg]

In article <[EMAIL PROTECTED]>,
Martin Pitt  <[EMAIL PROTECTED]> wrote:
>- I sometimes switch to my old 2.4 for testing purposes. Then of
>  course mounting /sys will fail and the user will get an error
>  message (it doesn't harm, though). This problem could only be
>  circumvented by not mounting /sys in /etc/fstab, but doing that in
>  an init script which checks which kernel version runs ATM. Do you
>  think that it is worth the effort?

There is existing practice here; see /etc/init.d/devpts.sh

Mike.
-- 
When life hands you lemons, grab the salt and pass the tequila.

寻求合作

[trewq]

您好！很荣幸能够认识您：

目前我公司有多余的发票需要代开出去，如果您有这方面的需求，请跟我联系。谢谢！

联系人：吴先生

电  话：（0）13924619860




   顺颂商祺

 

Proposed change to debian release system

[Scott Minns]

Hiya all,
First of all let me introduce myself, my name is Scott Minns, i'm a
debian
user, not a developer.  That most likely makes you question why i'm
using
thins mailing list at all, let alone having the gall to propose
altering a well
established testing and release system.

Here is my proposal and I would like to hear your thoughts on it, In
addition
to the present releases- stable, testing and unstable. We add a release
called
current. 

For my general servers stable is too old and lacks features and
software that I
need, I hate using back ports or software from other releases, it seems
to
always eventually cause problems.  Yet for my web servers stable is
perfect, its rock solid :) However I would not trust testing or
unstable on a
production server. My suggestion would be this

Stable - released when the software is rock sold and very mature
Current - This is software that has been in testing for six months and
experienced
no critical bugs, floors or dependency problems. A new version is
released
every six months - supported by a security team.  After
1 year the current version becomes
stable.
Testing - Software in the queue to enter current – otherwise as it is
at
present
Unstable - new software, no testing for those that like to live
dangerously
-  as it is at present

My reason for suggesting this change is that I love using debian, but
I’m
currently having to evaluate other distros and OS's such as slack and
FreeBSD
to get the features, stability and security that we need.
 
I will be interested to hear you feedback and
thought on the
matter.
Best regards
Scott

Mass bug filing potential: (x-)www-browser Provides

[Rene Engelhard]

[ Cc: ing debian-policy wrt virtual-packages-list ]

Hi,

We want to suggest Browsers for X (those providing the x-www-browser
alternative):

But:

$ grep-available -FProvides x-www-browser | grep Package:
Package: mozilla-firebird

$ grep-available -FProvides www-browser | grep Package:
Package: dillo
Package: w3mmee
Package: galeon
Package: chimera2
Package: mozilla-browser
Package: xemacs21-gnome-mule-canna-wnn
Package: mozilla-browser-snapshot
Package: emacs21-nox
Package: epiphany-browser
Package: xemacs21-nomule
Package: lynx
Package: xemacs21-gnome-nomule
Package: links
Package: emacs20
Package: emacs21
Package: elinks
Package: xemacs21-gnome-mule
Package: xemacs21-mule-canna-wnn
Package: netrik
Package: lynx-cur
Package: xemacs21-mule
Package: w3m
Package: links-ssl
Package: konqueror
Package: mozilla-firebird <-- matches because it suggests x-www-browser,
  it does _not_ provide www-browser

So there at the moment is no way to Suggests: x-www-browser to just
Suggest browsers for X.

x-www-browser isn't listed in virtual-packages-list, though. Maybe it
should be added. Would make sense IMHO. [ To be consequent,
text-www-browser would then make sense, too ...]

IMHO, suggesting a console program from an X program makes no sense -
especially not as the X program will use the x-www-browser alternative
per default...

So is there a consensus to mass-file bugs to let all Browsers Provide:
www-browser (even mozilla-firebird) and additionally x-www-browser (and
maybe text-www-browser)?

Grüße/Regards,

René
-- 
 .''`.  René Engelhard -- Debian GNU/Linux Developer
 : :' : http://www.debian.org | http://people.debian.org/~rene/
 `. `'  [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73
   `-   Fingerprint: 41FA F208 28D4 7CA5 19BB  7AD9 F859 90B0 248A EB73
  


signature.asc
Description: Digital signature

Re: Integrate Knoppix in Debian

[Bruno Rodrigues]

Keegan Quinn <[EMAIL PROTECTED]> wrote:
> 
> The Knoppix hard-disk
> installer creates a system that bears little resemblance to the base
> system we all know and love.

Can you please detail this? thx

Ask some advice

[vairam vairam]

Dear sir,
 
 
I studying Msc computer science in india.  My name is bairvan.  This semester i have a software project.  so please help me.  What platform is best and please tell some system side projects title.
 
Thank you
 
please mail me
 
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing

Re: Debian IS for the enterprise

[Bruno Rodrigues]

John Goerzen <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 26, 2003 at 01:07:23PM +0100, Ralf Hildebrandt wrote:
>> > Could you point me at the specific paragraph in either the constitution
>> > or the social contract, or in perhaps any other official document by the
>> > Debian project as a whole that supports this statement?
>> 
>> Especially since stable doesn't even install on recent server boxes...
> 
> Oh, I guess you must be talking about things like our new rack-mount
> PowerEdge 2650 with aacraid built in?  A machine that the stable CD
> installed with no trouble whatsoever?

Which doesn't support hyperthreading nor the network cards ?

I have a bunch of 1650 and 2650, where debian installer didn't work at all.
I had to install redhat in it, then debootstrap a debian inside and then
move debian to root and remove redhat. Nevertheless I had to leave
redhat's kernel because debian didn't support it (redhat 2.4.18-5? and
debian 2.4.18 something). This was last year.

Later, at around debian's kernel 2.4.20 or 22, when it got e1000 and tg3 
driver, I did install debian kernel in dell's 1650, but I still keep 
redhat's ones in 2650 due to lacking hyperthreading support in debian 
(see below).


example for two equal machines, dell1 with a debian kernel and dell2 with
a redhat kernel, both with the same debian system (dd'ed from one to the
other):

dell1:~# cat /proc/cpuinfo  | grep "model name" | head -1
model name  : Intel(R) XEON(TM) CPU 1.80GHz

dell1:~# uname -a
Linux dell1 2.4.22-1-686-smp #5 SMP Sat Oct 4 14:35:05 EST 2003 i686
GNU/Linux

dell1:~# cat /proc/cpuinfo  | grep processor
processor   : 0
processor   : 1



dell2:~# uname -a
Linux dell2 2.4.20-20.9smp #1 SMP Mon Aug 18 11:32:15 EDT 2003 i686
GNU/Linux

dell2:~# cat /proc/cpuinfo  | grep processor
processor   : 0
processor   : 1
processor   : 2
processor   : 3



I also got a Tecra M1 where nor old debian installer nor the new one did
work at all. I had to run knoppix in it, knx-hd-install and then upgrade
to debian's unstable.


In conclusion: I tend to suggest to my friends to just bootup knoppix,
see if everything works ok, and then update to debian. And I just say
"don't complain about debian installer being worst than redhat or suse.
use knoppix and just forget debian installer".

Can't we just make an installer like a mini-knoppix ?

Re: mounting tmpfs (and sysfs) defaultly in sarge?

[GOTO Masanori]

At Sat, 13 Dec 2003 11:42:45 +,
Roger Leigh wrote:
> > Tmpfs in Linux kernel 2.4, is formally known as shmfs (posix shared
> > memory filesystem).  It's useful for memory-based filesystem like
> > Solaris tmpfs.  However, if we support new Posix IPC like shm_open(3),
> > shm_unlink(3), to make debian posix compliant (and like other
> > distros), it should be mounted on /dev/shm.  In the past there were
> > some discussed, ex:
> >
> > 
> > http://lists.debian.org/debian-devel/2001/debian-devel-200111/msg00706.html
> >
> > So I propose:
> >
> >   - /dev/MAKEDEV should have /dev/shm in "std" entry.
> >   - /etc/fstab should mount /dev/shm (tmpfs) in default.
> 
> Please make sure that when this is added, you do default to a sensible
> size option.  For example:
> 
> none/dev/shmtmpfsdefaults,size=500M00

AFAIK, it's no problem.  If we mount tmpfs without size= option,
kernel automatically limits a half of real memory size.  In addition,
memory contents in tmpfs can swap out from memory to HDD.  This is one
of nice feature of tmpfs.  If we would like to avoid this size issue,
then we only specify size=1M (or 10M) for posix IPC.

If user specify size option in fstab explicitly, then it's user's
fault.  /dev/shm is used for posix IPC, not ram based temporary
filesystem.  If user wants to mount tmpfs for his temporary work, then
/dev/shm is not suitable place.

> If you don't specify a default limit, any user can kill the system by
> creating a huge file in there.  It's much nicer to get ENOSPC than a
> kernel panic.  The installer could pick a sensible limit based on, for
> example, 20% of the combined core+swap size.

If system memory is exhausted, then (1) swap (2) OOM Killer (3)
ENOSPC.  If we see kernel panic, then it's kernel bug.

Regards,
-- gotom

Re: mounting tmpfs (and sysfs) defaultly in sarge?

[Andreas Metzler]

GOTO Masanori <[EMAIL PROTECTED]> wrote:
> Tmpfs in Linux kernel 2.4, is formally known as shmfs (posix shared
> memory filesystem).  It's useful for memory-based filesystem like
> Solaris tmpfs.  However, if we support new Posix IPC like shm_open(3),
> shm_unlink(3), to make debian posix compliant (and like other
> distros), it should be mounted on /dev/shm.
[...]
>  - /dev/MAKEDEV should have /dev/shm in "std" entry.
>  - /etc/fstab should mount /dev/shm (tmpfs) in default.

> BTW, the coming Linux kernel 2.6 will support sysfs, replacement for
> procfs (/proc).  It's useful if we have /sys directory for kernel 2.6.
[...]

I would propose to handle this similarily to the devpts
filesystem i.e. by a init-script instead of cluttering fstab.
cu andreas

Re: Chrony rtc broken?

[Marcus Frings]

* John Hasler <[EMAIL PROTECTED]> wrote:

> Could someone who is running chrony 1.20 please test the rtc commands for
> me?  You'll need 'Enhanced Real-time Clock Support' in the kernel and will
> need to uncomment the rtcfile line in /etc/chrony/chrony.conf.  Posting the
> output of the rtcdata command in chronyc would suffice.

And here are my two outputs:

,[ A woody box with a backported chrony ]
| [17:[EMAIL PROTECTED]:~]$ uname -r
| 2.4.23
| 
| [17:[EMAIL PROTECTED]:~]$ grep CONFIG_RTC /usr/src/linux/.config
| CONFIG_RTC=m
| 
| [17:[EMAIL PROTECTED]:~]$ dpkg -l chrony | grep ^ii
| ii  chrony 1.20-1.mf1
| 
| [17:37]iridium:/home/marcus# grep rtc /etc/chrony/chrony.conf
| rtcfile /var/lib/chrony/chrony.rtc
| log tracking measurements statistics rtc
| rtconutc
| 
| [17:[EMAIL PROTECTED]:~]$ chronyc rtcdata
| RTC ref time (UTC) : Sat Dec 13 16:34:39 2003
| Number of samples  : 14
| Number of runs : 7
| Sample span period :  22m
| RTC is fast by : 0.090088 seconds
| RTC gains time at  : 5.033 ppm
`

,[ A sid box with chrony ]
| [17:[EMAIL PROTECTED]:~]$ uname -r
| 2.4.22
| 
| [17:[EMAIL PROTECTED]:~]$ grep CONFIG_RTC /usr/src/linux/.config
| CONFIG_RTC=m
| 
| [17:[EMAIL PROTECTED]:~]$ dpkg -l chrony | grep ^ii
| ii  chrony 1.20-1 
| 
| [17:39]xenon:/home/marcus# grep rtc /etc/chrony/chrony.conf
| rtcfile /var/lib/chrony/chrony.rtc
| 
| [17:[EMAIL PROTECTED]:~]$ chronyc rtcdata
| RTC ref time (UTC) : Thu Jan  1 00:00:00 1970
| Number of samples  : 0
| Number of runs : 0
| Sample span period :0
| RTC is fast by : 0.00 seconds
| RTC gains time at  : 0.000 ppm
`

Regards,
Marcus
-- 
"Tuba cum sonuerit dies erit extrema
et iudex advenerit vocabit sempiterna
electos in patria
prescitos ad inferna."

Re: mounting tmpfs (and sysfs) defaultly in sarge?

[GOTO Masanori]

At Sat, 13 Dec 2003 14:00:05 + (UTC),
Miquel van Smoorenburg wrote:
> 
> In article <[EMAIL PROTECTED]>,
> Martin Pitt  <[EMAIL PROTECTED]> wrote:
> >- I sometimes switch to my old 2.4 for testing purposes. Then of
> >  course mounting /sys will fail and the user will get an error
> >  message (it doesn't harm, though). This problem could only be
> >  circumvented by not mounting /sys in /etc/fstab, but doing that in
> >  an init script which checks which kernel version runs ATM. Do you
> >  think that it is worth the effort?
> 
> There is existing practice here; see /etc/init.d/devpts.sh

Ah, indeed.  Well, 2.6 has not reached stable release, but I think
it's worth while using /etc/init.d/sysfs or something for mounting
sysfs.

Regards,
-- gotom

Re: Mass bug filing potential: (x-)www-browser Provides

[Julien BLACHE]

Rene Engelhard <[EMAIL PROTECTED]> wrote:

Hi,

> So there at the moment is no way to Suggests: x-www-browser to just
> Suggest browsers for X.
>
> x-www-browser isn't listed in virtual-packages-list, though. Maybe it
> should be added. Would make sense IMHO. [ To be consequent,
> text-www-browser would then make sense, too ...]

I second the addition of x-www-browser to the list of virtual
packages.

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> 
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 

Re: mounting tmpfs (and sysfs) defaultly in sarge?

[Rob Weir]

On Sat, Dec 13, 2003 at 04:19:16PM +0900, GOTO Masanori said
> BTW, the coming Linux kernel 2.6 will support sysfs, replacement for
> procfs (/proc).  

A replacement? I'm pretty sure you need both; /sysfs doesn't include
*everything* that /proc does (and vice-versa).  I'm not sure what the
long-term plans are, but /sysfs can't replace /proc right now.

-- 
Rob Weir <[EMAIL PROTECTED]> | [EMAIL PROTECTED]  |  Do I look like I want a CC?
Words of the day:  revolution security Saddam Hussein Consul Ermes tempest CDMA


signature.asc
Description: Digital signature

Re: Bug#223772: general: no md5sums for many packages (e.g. bc)

[Bruno Rodrigues]

Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] writes:
> 
>> Subject: general: no md5sums for many packages (e.g. bc)
>> Package: general
>> Version: N/A; reported 2003-12-12
>> Severity: normal
>> Tags: security
> 
> Every package has a md5sum in the Package file.
> 
> Some packages have a useless and space wasting md5sums file inside the
> package. Due to its uselessness the existance is rather a bug than its
> omission.
> 
> Please close this bug, read the threads on debian-devel about this and
> if you still want md5sum files help making actually usefull ones.

I guess he means md5sum for files inside package, as in:

[EMAIL PROTECTED]:~$ debsums bc
debsums: no md5sums for bc

[EMAIL PROTECTED]:~$ debsums debsums
usr/bin/debsums OK
usr/sbin/debsums_gen OK
(...)


[EMAIL PROTECTED]:/var/lib/dpkg/info$ ls *.list | wc -l
1135

[EMAIL PROTECTED]:/var/lib/dpkg/info$ ls *.md5sums | wc -l
1042

Looking at the source:

CHROOT/[EMAIL PROTECTED]:~/code/bc/bc-1.06$ grep md5sums debian/rules
#   dh_md5sums -pbc
#   dh_md5sums -pdc


It would be nice to fix those packages to enable a simple system testing
without requiring installing something like tripwire.

Re: Debian IS for the enterprise

[sean finney]

hi john,

On Sat, Dec 13, 2003 at 03:07:00PM +, Bruno Rodrigues wrote:
> Which doesn't support hyperthreading nor the network cards ?

nor the aacraid/aic7xxx scsi raid controllers, which really sucks
if that's where your hard disks are.  but there are folks on the
net who've made netboot isos which work for that.  i haven't checked
the smp/hyperthreading support, i'll look into that next week.

> I also got a Tecra M1 where nor old debian installer nor the new one did
> work at all. I had to run knoppix in it, knx-hd-install and then upgrade
> to debian's unstable.

the knoppix hd install is great if you know nothing about how to install
a linux system, don't care about specifics, and just want to have linux
on your machine with minimal fuss.  push a couple buttons and blam, you
have linux. and knoppix itself is a great way to find out if your
machine will support debian gnu/linux.

however, it lacks a few things that a full-fledged debian installer
would need to have[1], such as giving the user a way to partition the
hard drive, what software to install, and how to configure the base system.

> Can't we just make an installer like a mini-knoppix ?

personally, i'd like to see knoppix come with the debian installer
as a menu option.  it's a little more difficult to go the other way
because knoppix is pretty much x86-centric, and debian supports much
more than just x86 pc's.


sean

[1] since the last time i checked, which was with an iso from about a
month ago


signature.asc
Description: Digital signature

Re: Release-critical Bugreport for December 12, 2003

[Steve Langasek]

On Sat, Dec 13, 2003 at 09:36:46AM +, Mark Howard wrote:

> On Sat, Dec 13, 2003 at 01:13:23AM -0500, Grzegorz B. Prokopski wrote:
> > The thing is that #215314 has tag: sid bacause it only applies to
> > unstable version (upstream release is on its way and will close it).

> > Version in testing is clean and robust and I wouldn't want it to be
> > at some point removed from testing because of a bug in unstable.

> I think the distinction between sid RC bugs and all RC bugs was removed
> at some point, without telling us. Take a look at the gjdoc package -
> there are two RC bugs tagged sarge and one tagged sid, but the testing
> scripts are not upgrading the version in testing, even though it would
> close two rc bugs and reduce the number of rc bugs for sarge.

No, this points to a problem with the bug list as seen by the testing
scripts.  update_excuses for gjdoc says 

  gjdoc (source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, 
s390, sparc) is buggy! (1 > 0)

which is clearly not true if the sarge version of the package has two RC
bugs, no matter how you count.  (It should be non-buggy, 1 < 3; and even
if the bug you describe existed, it would be 3 > 2, not 1 > 0.)

I think this is something aj will need to look at, since this output is
from scripts that run on auric.

-- 
Steve Langasek
postmodern programmer



signature.asc
Description: Digital signature

Re: APT-Fu 0.2.3

[Scott James Remnant]

On Sat, 2003-12-13 at 08:47, Herbert Xu wrote:

> Colin Walters <[EMAIL PROTECTED]> wrote:
> > 
> > But your message didn't include a Content-Type header specifying that,
> > so it's likely to come through as garbage for most MUAs...
> 
> Right, here it is again
> 
> \xEF\xBB\xBF\xE8\xBE\xAD\xE6\xB5\xB7
> 
Now that's just the hand-printed bytecodes of raw UTF-8 :-)

Now, if my by-hand Unicode isn't rusty, I make this out to be

U+FEFF  ZERO WIDTH NO_BREAK SPACE
U+8FAD  CJK: words, speech, expression, phrase
U+6D77  CJK: sea, ocean; maritime

That first character is fairly superfluous for this example, I think
what you were aiming for was:

èïæ

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?



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

Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries

[Bruce Sass]

On Fri, 12 Dec 2003, Chris Cheney wrote:
> On Fri, Dec 12, 2003 at 05:47:17PM -0700, Bruce Sass wrote:
> > On Fri, 12 Dec 2003, Chris Cheney wrote:
> > > On Wed, Dec 10, 2003 at 01:28:51PM -0700, Bruce Sass wrote:
> > <...>
> > > .desktop files are not bloated... period. They include i18n which for
> > > you is bloat since you obviously can communicate in English.
> >
> > "not bloated... period", yet you admit the translations are bloat for
> > someone who doesn't need them.  Can you also accept the X-KDE-* stuff
> > is bloat for every menu data consumer except KDE (ditto for Gnome
> > specials), and that in general freedesktop features are bloat for
> > everyone who doesn't support the freedesktop standard.
>
> Bloat is relative, since i18n is needed by a large amount of people,
> certainly more than need english it is not really bloat. Certainly it
> isn't bloat for the 5Bil+ people whose language isn't english. Something
> you might determine is a critical feature someone else might consider
> bloat.

Do the 5Bil+ people need all the translations, or just the few they
understand/use.  Should one or two someone's critical feature be
imposed on the entire population.

> Yes, X-KDE-* could be considered to be bloat by some people.
> However, the same people who have systems fast enough to actually run
> Gnome or KDE also have large enough hard drives that it shouldn't even
> be a consideration.

Unfortunately, the proposal as I understand it would have everyone
getting the X-KDE-* and other specials... even though they may not
have the space or processing power to run KDE.

> Across all desktop files in the archive that
> probably amounts to less than 100KB of additional space. Bitching about a
> loss of 100KB when the same packages overall take 500MB+ is very petty.
> And no I do not think that the freedesktop standard overall is bloat.

Your figures are inaccurate.  Based on your own numbers (and being
somewhat generous in your favour): Let's say the average i18n-ed
.desktop file is 2k, and a non-i18n file is 200 bytes, and there are
2625 of them in the archive... that is 5250k of i18n files and 513k of
single language files, a difference of way more than "less than
100KB".

The above is just the tip of the iceberg with respect to i18n, I had
roughly the same size savings when I was removing translations from
KDE2 files---KDE3 has more files, more translations per file, and I
haven't looked at Gnome.


> > > As I mentioned further down in this message Konqueror only uses 159
> > > bytes when all i18n is stripped from it. I see many debian menu
> > > files that are larger than this and they don't contain i18n either.
> >
> > I suspect those files contain more than one menu entry; KDE has a file
> > per entry, menu uses a file per package which contain multiple menu
> > entries.
>
> Yes that is true, so I went and got the konqueror menu file to compare.
> Just the one entry for the file browser which is equivalent to the
> .desktop file is bigger than the .desktop file without its i18n support.
> And add to that the fact that the .menu description is shorter which
> further disproves the point that .desktop files are larger.
>
> .desktop - 159 bytes
>
> [Desktop Entry]
> Encoding=UTF-8
> Type=Application
> Exec=kfmclient openProfile webbrowsing
> Icon=konqueror
> DocPath=konqueror/index.html
>
> Name=Konqueror Web Browser
>
>
> .menu - 168 bytes
>
> ?package(konqueror):\
> needs=X11\
> section=Apps/Net\
> hints="KDE,Web browsers"\
> kderemove="y"\
> title="Konqueror"\
> command="/usr/bin/konqueror --profile webbrowsing"


The 15 bytes used by the KDE specific "kderemove" line would not be
necessary if menues are built from a common data pool (.desktop-159,
.menu-153).  Also, where is the "Comment" in the .desktop example.


I don't see this comparison as meaningful, and even if I did, not
significant because the size difference between the two formats is
probably somewhere around the margin of error.

> > > If several KDE and Gnome developers got together and rewrote the
> > > menu-methods for the various WM's would that satisfy you?
> >
> > No, because it doesn't address the primary concern of (say) a Fluxbox
> > user needing to process the KDE, Gnome, and freedesktop stuff which
> > they don't have a use for.
>
> I contend that the processing the time difference would not be sufficient
> to tell the difference over extracting and installing packages on the
> system. And the only time menus get rebuilt normally is when you are
> installing new packages. Systems old enough to worry about this also
> typically don't have hundreds of menu files to deal with as well since
> their hd's are too small.

I've hung a 30G drive off the bus of a 50MHz box, but that is besides
the point... which is: the proposal gets everyone significantly larger
than necessary menu data files, and "everyone" includes those who
can't afford or don't want a freedesktop based box.

> As s

Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries

[Bruce Sass]

On Fri, 12 Dec 2003, Moritz Moeller-Herrmann wrote:
<...>
> Of course the system can and will be improved, once it is generally adopted.

Improving it at the outset will speed up its adoption.

Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries

[Billy Biggs]

Bruce Sass ([EMAIL PROTECTED]):

> The above is just the tip of the iceberg with respect to i18n, I had
> roughly the same size savings when I was removing translations from
> KDE2 files---KDE3 has more files, more translations per file, and I
> haven't looked at Gnome.

  Bruce,

  I can't figure out your position on i18n.  Do you think that:

  1. Debian should only provide english
  2. Menu entries should be english only
  3. Packages should individually only include one language
  4. Packages should include all languages, but only install files
 pertinent to the local language
  5. Something else

  I am just curious because I find your opinion puzzling.  None of this
has anything to do with .desktop vs menufile.  If i18n support were
added to menufile it would be the same.

  -Billy

Re: Changes in formal naming for NetBSD porting effort(s)

[Branden Robinson]

[I am not subscribed to debian-bsd.]

On Fri, Dec 12, 2003 at 10:29:05AM -0700, Joel Baker wrote:
> [ Adding -legal to the Cc; it may become inappropriate for -devel, at ]
> [ some point, in which case folks should remove the -devel Cc. The -bsd   ]
> [ Cc should probably remain no matter what, as this could potentially ]
> [ affect any of the BSD ports.]

I've still got some -devel-relevant stuff here, so I'm preserving that
list in the headers for the moment.

> On Fri, Dec 12, 2003 at 11:54:09AM -0500, Branden Robinson wrote:
> > I checked, and I don't see the *specific* grounds for the request
> > explicated anywhere.
> 
> I guess it depends on precisely what you mean by specific grounds, in this
> case. If you mean 'specific accusations of dilution of trademark', then I
> don't believe there have been any.

No, I mean a specific description of how "Debian GNU/NetBSD" dilutes, or
risks diluting, the trademark but "Debian GNU/KNetBSD" does not.

I can expect a phone call (or worse) from a certain very large company
if I go into soft drink business with a product called "Branden's
KCoca-Cola" just as easily as I can if I call it "Branden's Coca-Cola".

FYI, the serial number of the "NetBSD" mark according to the U.S. PTO
(Patent and Trademark Office) is 78025507.

> > What makes a suitable name?  Please be specific.  If you don't know, I
> > think you should request this information from the NetBSD Foundation.
> 
> As far as I can tell, anything which does not use the bare word 'NetBSD'
> as part of it's name, but I certainly can request clarification from Mr.
> Mewburn and The NetBSD Foundation about that.

As I understand it, TNF's view of what dilutes a trademark is
considerably narrower than that of U.S. courts.  It may be wise to
obtain a trademark license explicitly authorizing this usage.

> I think that is largely a reflection of "nobody had any disagreement on
> the principle, or a better suggestion for the formal port name", combined
> with the fact that it triggered reviewing some of the haphazard naming
> conventions with a critical eye, and making sure that they were reasonable
> and rational.
> 
> The thread is, indeed, split into two interleaved parts, and the
> non-technical part is almost empty.

I don't have a problem with the technical issues being grappled with.
In fact, I'm glad they are.  But the fact that the technical part got a
good amount of attention doesn't mean the non-technical aspect has been
adequately grappled with.  And it was on non-technical grounds that Mr.
Newburn made his request -- "trademark dilution" is not a technical
concept, but a legal one.

BSD is also still a trademark, but I was unable to find any information
about its licensing, or even whether it is still actively defended.

> > > 4) The Debian port name will become 'Debian GNU/KLNetBSD(i386)'[1].
> > 
> > Well, no offense, but that's ugly as hell, and is going to square the
> > amount of confusion people experience when trying to decode our OS
> > names.
> 
> Agreed, unfortunately - it is, and I suspect it may well. Suggestions for
> better naming welcome, of course (or even a direction to go in).

We might use names from Christian demonology (since the BSD mascot
is the cute and devilish "daemon"), with the first letter shared by the
demon's name and the corresponding BSD flavor.

Thus:

Debian FreeBSD  -> Debian Forneus (BSD)
Debian NetBSD   -> Debian Naberius (BSD)
Debian OpenBSD  -> Debian Orobos (BSD)

I got these names from the Wikipedia http://en2.wikipedia.org/wiki/List_of_specific_demons_and_types_of_demons>.

Moreover, none of these names are currently registered with the USPTO,
so we'd be set in that department.

> I believe (note: personal view) that the core is a perceived difference
> between the bare word 'NetBSD', which has, prior to this port, implied a
> kernel, libc, *and* userland of a specific form, and a variant of that
> name which is recognizeable, but distinctive enough to not cause confusion
> between their "product" and what we intend to produce.

My feeble understanding of U.S. trademark law leads me to believe that
the *more* similar our product is to theirs, the more grounds they have
for being able to argue that we're "diluting" the name, because we're
promoting marketplace confusion.

After all, if everybody *knows* that Debian NetBSD is quite different
from TNF's NetBSD, then it's more difficult to claim that there is
confusion.

> > Debian either needs a trademark license from the NetBSD Foundation for
> > use of the "NetBSD" mark, or it does not.  If we do, then our hands are
> > tied and we might as well ask them to tell us what they want it called,
> > and what the terms of use are.  Since the Debian Project doesn't legally
> > exist, this will probably have to go through SPI.  If we don't need a
> > trademark license, then I don't understand why they've grounded their
> > request for a name 

Re: APT-Fu 0.2.3

[Herbert Xu]

Scott James Remnant <[EMAIL PROTECTED]> wrote:
> 
> Now, if my by-hand Unicode isn't rusty, I make this out to be
> 
> U+FEFF  ZERO WIDTH NO_BREAK SPACE
> U+8FAD  CJK: words, speech, expression, phrase
> U+6D77  CJK: sea, ocean; maritime

That's correct.
-- 
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: cvs versioning

[Arnaud Vandyck]

Paul Brossier <[EMAIL PROTECTED]> writes:

> I am working on packages from cvs upstream sources.  How should I name
> their debian version ? I give a few examples below.
>
> Is there a spec for this somewhere ?

In the policy?

/usr/share/doc/debian-policy/policy.txt.gz

3.2.1. Version numbers based on dates
-

...
 However, in some cases where the upstream version number is based
 on a date (e.g., a development "snapshot" release) the package
 management system cannot handle these version numbers without
 epochs.  For example, dpkg will consider "96May01" to be greater
 than "96Dec24".

 To prevent having to use epochs for every new upstream version, the
 version number should be changed to the following format in such
 cases: "19960501", "19961224".  It is up to the maintainer whether
 he/she wants to bother the upstream maintainer to change the
 version numbers upstream, too.
...

Cheers,

-- 
  .''`. Arnaud Vandyck
 : :' : http://people.debian.org/~avdyk/
 `. `'  
   `-

Re: Changes in formal naming for NetBSD porting effort(s)

[Branden Robinson]

[I am not subscribed to debian-bsd.]

On Sat, Dec 13, 2003 at 09:28:12AM +0430, Stephane Bortzmeyer wrote:
> On Fri, Dec 12, 2003 at 11:54:09AM -0500,
>  Branden Robinson <[EMAIL PROTECTED]> wrote 
>  a message of 126 lines which said:
> 
> > Debian either needs a trademark license from the NetBSD Foundation
> > for use of the "NetBSD" mark, or it does not.
> 
> Legally speaking, you're right. Now, on more practical grounds, I do
> not think that the NetBSD Foundation threatened to sue us.

I didn't say they did.  They did identify a legal theory for doing so in
the future, though.  It's not like there is a common law of trademark
dilution, or a "natural right" of trademarks.

I think the polite thing to do, if one has no intention of suing
someone, is not to speculate to a person's face about what the thrust of
your court complaint might be.

The TNF has made it clear enough that they feel they have legal remedies
at their disposal if we don't handle their request in a manner to their
liking.

That's enough to get the legally-minded members of the Debian Project
involved, IMO.

> I believe that they feared confusion and asked politely, as an humble
> request from fellow free software developers, to consider a change in
> the name. 

Yes, they did that.  They also, if Joel Baker's representations as to
the content of the communication are accurate, included a statement
inviting us to make the inference that they have ways of compelling our
compliance if the courteous approach doesn't work.

As I said above, I think that's rude.  It may be a rudeness that they
feel they were forced to indulge due to the way U.S. trademark law
works, but that doesn't make it any less of a discourtesy.  As I noted
elsewhere in this thread, I don't feel they're acting *irrationally*.

We, the Debian Project, have made similar requests of people using the
word "Debian".  At least recently, our communications have included the
hint of the iron fist inside the velvet glove, just as the message Joel
Baker received did.

It's the way the trademark game is played.  Should we go into hysterics?
No.  Neither should we pretend that the threat of legal recourse is not
present.

> I do not think debian-legal is concerned: it is not an issue of being
> right with trademark law, it's an issue of not pissing off NetBSD
> people for no good reason.

Sounds like it's both to me.  I think you are fundamentally misreading
the situation.  Pretending a legal threat is absent when it is not is a
good way to get a very nasty surprise when someone decides to up the
ante.

I suggest that the Debian Project not allow ourselves to be taken by
surprise in this situation.

-- 
G. Branden Robinson|Religion is regarded by the common
Debian GNU/Linux   |people as true, by the wise as
[EMAIL PROTECTED] |false, and by the rulers as useful.
http://people.debian.org/~branden/ |-- Lucius Annaeus Seneca


signature.asc
Description: Digital signature

problem to unsubscribe

[Arnaud Vandyck]

Hi all,

I read debian-devel via the newsgroup now (linux.debian.devel) and I'd
like to unsubscribe to the list but I can't. I did receive the
confirmation string and answer it but it seems that I still receive
mails from the list (also for debian-mentors -
linux.debian.devel.mentors).

I'd like to do it for every list but I can't unsubscribe. Is there a
problem with the unsubscribe script?

Best regards,

-- 
  .''`. Arnaud Vandyck
 : :' : http://people.debian.org/~avdyk/
 `. `'  
   `-

Re: Proposed change to debian release system

[Arnaud Vandyck]

Scott Minns <[EMAIL PROTECTED]> writes:

[...]

> Stable - released when the software is rock sold and very mature
> 
> Current - This is software that has been in testing for six months and
>   experienced no critical bugs, floors or dependency
>   problems. A new version is released every six

This is nearly impossible. I don't know if other developers will agree
but IMHO, it's like having two `stable' releases!

> months - supported by a security team.  After 1 year the current
>  version becomes stable.

I don't think we have enough developers to follow security problems in
stable, current and months!

> Testing - Software in the queue to enter current â otherwise as it is
>   at present

Testing should be more stable and should have less RC bugs then it is at
the moment. But this discussion has already take place here and on
debian-release. Maybe search the archive and you'll see some other
proposals.

> Unstable - new software, no testing for those that like to live
>dangerously - as it is at present

Also, you must be aware that there is `experimental' and this is the
pool to promote. This pool is intended for packages to `tests' and
packages in this pool does not go automatically in unstable. This is an
important point. The bad thing with this pool is that packages in main
are not autobuild on different arches (IMHO).

I think promote experimental with buildd would really be benefic to the
project.

> My reason for suggesting this change is that I love using debian, but
> Iâm currently having to evaluate other distros and OS's such as slack
> and FreeBSD to get the features, stability and security that we need.

Slackware?! Well, of course FreeBSD is great (even if I've never use
it), I can tell you the Debian community and distribution is really
great ;)... and surely the best choice ;)

> I will be interested to hear you feedback and thought on the matter.

I'm not a senior network administrator but I'm really pleased with
Debian (even with mixed pools!.. yes, not a good idea!).

Best regards,

-- 
  .''`. Arnaud Vandyck
 : :' : http://people.debian.org/~avdyk/
 `. `'  
   `-

Re: cvs versioning

[Arnaud Vandyck]

Sorry, bad list :'(

Paul Brossier <[EMAIL PROTECTED]> writes:

> I am working on packages from cvs upstream sources.  How should I name
> their debian version ? I give a few examples below.
>
> Is there a spec for this somewhere ?

In the policy?

/usr/share/doc/debian-policy/policy.txt.gz

3.2.1. Version numbers based on dates
-

[...]

--
argh!

Re: Proposed change to debian release system

[Andrew Pollock]

On Sat, Dec 13, 2003 at 03:20:27PM +, Scott Minns wrote:
> Hiya all,
> First of all let me introduce myself, my name is Scott Minns, i'm a 
> debian user, not a developer.  That most likely makes you question why 
> i'm using thins mailing list at all, let alone having the gall to 
> propose altering a well established testing and release system.
> 
> Here is my proposal and I would like to hear your thoughts on it, In 
> addition to the present releases- stable, testing and unstable. We add a 
> release called current.

[snip]

What you propose is probably technically difficult to actually achieve, due
to dependencies, and would, as has already been pointed out, effectively
mean there are two "stable" distributions running around.

I've been musing over a proposal for a while, which your email makes me want
to raise now...

I'd like to propose some changes to the stable release policy (ps it would
be nice if the policy is linked from http://www.debian.org/releases/stable/).

I'd like for certain packages to be classed as "perishable", i.e. they
become more or less useless with age. How packages should be classsed as
such, I'm not 100% sure on yet (-devel+maintainer+SRM consenus, perhaps?),
but to provide some examples:

* spamassassin
* snort

could be considered perishable because their effectiveness is reduced over
time. Such classed packages should be allowed to be updated in stable, I
feel. Of course, it could be argued that any package is perishable, and thus
this whole thing becomes a moot point...

The exact policy on what and how they can be updated needs to be debated,
and of course the whole thing would need the Stable Release Manager's
blessing.

It also makes for more work for both the Stable Release Manager and the
Security Team though, as there would be multiple versions of a package that
could potentially require a security update. This makes the proposal
unattractive, but coming back to the Social Contract, our first priority
should be to our users, so if an 18 month old stable distribution is not
serving our users needs adequately, and we can't (in the short term) shorten
our release cycle, then perhaps this is a middle ground that can be
explored further...

This proposal is a tad premature in that I hadn't thought it through in as
much depth as I'd have liked to have before floating it, but I felt the
original email was a good catalyst for getting it out there...

Andrew

Bug#223903: ITP: libimage-exif-perl -- Perl module to extract EXIF information from JPEG image files

[Julien BLACHE]

Package: wnpp
Severity: wishlist

  Package name: libimage-exif-perl
  Version : 0.98.4
  Upstream Author : Sergey S Prozhogin <[EMAIL PROTECTED]>
  URL : 
http://www.cpan.org/authors/id/C/CC/CCPRO/Image-EXIF-0.98.4.tgz
  License : Perl + BSD

Description: Perl module to extract EXIF information from image files
 This Perl extension allows you to extract EXIF information from your
 image files, especially photographs taken with a digital camera.
 .
 It supports some of the vendor extensions to the EXIF format used by
 some cameras.

The perl module itself is licensed under the Perl license, but it uses part
of the exiftags package which is licensed under the BSD license. (and is
part of Debian already)

I have the package ready to go, I'll probably upload it before the end of
the week-end.

JB.

-- System Information:
Debian Release: testing/unstable
Architecture: powerpc
Kernel: Linux frigate 2.4.22-ben2-brk-of-xfs #1 Mon Dec 8 18:03:37 CET 2003 ppc
Locale: LANG=C, [EMAIL PROTECTED]

Re: Changes in formal naming for NetBSD porting effort(s)

[Henning Makholm]

Scripsit Branden Robinson <[EMAIL PROTECTED]>
> On Sat, Dec 13, 2003 at 09:28:12AM +0430, Stephane Bortzmeyer wrote:

> > Legally speaking, you're right. Now, on more practical grounds, I do
> > not think that the NetBSD Foundation threatened to sue us.

> I didn't say they did.  They did identify a legal theory for doing so in
> the future, though.  It's not like there is a common law of trademark
> dilution, or a "natural right" of trademarks.

Would you at least consider that possibility that they might have
meant exactly what they said: "We're somewhat worried that if someday
we have to defend our trademark against a real villain, then the
villain may be able to get off the hook by pointing to Debian/FreeBSD.
Could we work together on finding another name that will let us sleep
tighter?"

Just because the fear they related *could* be used as grounds for a
lawsuit doesn't mean that it's not real.

> I think the polite thing to do, if one has no intention of suing
> someone, is not to speculate to a person's face about what the
> thrust of your court complaint might be.

How would you expect them to that, if you insist of reading the mere
mention of why they are uneasy as a veiled lawsuit threat? Should they
just say: "We humbly suggest that you change your name, but we cannot
tell you why, because that would sound like a lawsuit threat?"

(BTW, to me it's immediately clear that it can't be a threat, because
they know that we know that a threat would be completely empty,
because we know that they know that they would earn an ocean of bad
karma if they actually attacked another majour open-source project
through the courts.)

> The TNF has made it clear enough that they feel they have legal remedies
> at their disposal if we don't handle their request in a manner to their
> liking.

I think you're seing spectres.

-- 
Henning Makholm "... and that Greek, Thucydides"

Generating ~/.ssh/known_hosts from LDAP

[Matt Zimmerman]

I couldn't find any way to authenticate db.debian.org when using direct LDAP
(TLS doesn't seem to be supported), but nonetheless this is damn convenient.

(requires python-ldap)

-- 
 - mdz
#!/usr/bin/python

#
# debian-known-hosts
#
#   Dump ssh host keys from db.debian.org in a format suitable for an
#   ssh known_hosts file
#
# BUGS: has no way to authenticate db.debian.org
#
# Matt Zimmerman <[EMAIL PROTECTED]>, 12/13/2003
#

import ldap

conn = ldap.ldapobject.SmartLDAPObject('ldap://db.debian.org')
msgid = conn.search('dc=debian,dc=org', ldap.SCOPE_SUBTREE,
filterstr='objectClass=debianServer',
attrlist=('hostname', 'sshRSAHostKey'))
restype, resdata = conn.result(msgid)

for dn, attrs in resdata:
if 'sshRSAHostKey' not in attrs:
continue
hostnames = ','.join(attrs['hostname'])
for hostkey in attrs['sshRSAHostKey']:
print hostnames, hostkey




signature.asc
Description: Digital signature

Re: Proposed change to debian release system

[Henning Makholm]

Scripsit Arnaud Vandyck <[EMAIL PROTECTED]>
> Scott Minns <[EMAIL PROTECTED]> writes:

> > Stable - released when the software is rock sold and very mature
> > 
> > Current - This is software that has been in testing for six months and
> >   experienced no critical bugs, floors or dependency
> >   problems. A new version is released every six

> This is nearly impossible. I don't know if other developers will agree
> but IMHO, it's like having two `stable' releases!

I concur. In particular, the process is already such that if we get
even near something that fits this description of "current", a big
party will be thrown and that something will be frozen to become the
next "stable" within a short timeframe.

Everybody seems to agree that new stable versions *should* be out
about every 6 months. The problem of getting testing into a freezeable
state is not going to go away simply by calling the goal "current"
instead of "stable".

-- 
Henning Makholm  "What has it got in its pocketses?"

Services I'd like from auric

[Kevin Rosenberg]

I certainly miss the varied and up-to-date information that I was able
to get from auric. Taking James Troup's advice from his announcement
of discussing information we'd like from auric, what's on my mind
today is the ability to check the NEW queue.

I frequently add new packages to Debian and, at the moment, I'm not
sure of what new packages I've uploaded before the recent breech and
what versions they were.

Thus, if the ftpmasters are planning on a long-term restriction on
auric, mirroring the data in the new queue [at least filenames and
upload dates] would be of significant help to me.

Thanks for considering the request,

Kevin


signature.asc
Description: Digital signature

Bug#223905: ITP: jamnntpd -- NNTP server that allows newsreaders to access a JAM messagebase

[Peter Karlsson]

Package: wnpp
Version: 0.5
Severity: wishlist

* Package name: jamnntpd
  Version : 0.5
  Upstream Author : Johan Billing <[EMAIL PROTECTED]>
* URL : http://www.some.org/
* License : DFSG compliant
  Description : NNTP server that allows newsreaders to access a JAM 
messagebase

"JamNNTPd is an attempt to merge dying fidonet technology with modern Usenet
newsreaders. Basically, JamNNTPd is NNTP server that allows newsreaders to
access a JAM messagebase. (If you didn't understand a word of this, you
probably don't want to use JamNNTPd anyway)."

License terms:

  The copyright of JamNNTPd belongs to Johan Billing. Permission to use,
  copy and distribute JamNNTPd is granted provided that this copyright
  notice is included. Permission to modify JamNNTPd is granted. Distributing
  modified versions of JamNNTPd is allowed provided that the documentation
  clearly states that it is a modified version. Parts of JamNNTPd may be
  freely used in other projects as long as credit is given.

  JamNNTPd uses JAMLIB for reading and modifying JAM messagebases. JAMLIB is
  copyright 1996 Björn Stenberg and is released under the GNU Lesser General
  Public License (see included file src/jamlib/LICENSE).

Re: Bits from the RM

[Brian May]

On Tue, Dec 02, 2003 at 02:47:12PM -0700, Joel Baker wrote:
> For those playing along at home, I suspect this would look a lot like:
> 
> clone XX
> severity -1 important
> retitle -1 Causes massive failures on package foo
> assign -1 bar

Would it be acceptable to add:

forwarded XX http://bugs.debian.org/YY

(where YY is the new BTS id for -1)?

OR (easier; can be done in the one message)

tag -1 upstream

Otherwise, there is no way to filter out this bug report in BTS
listings.

However, both of these are intended for upstream bugs, not
bugs in other related packages.

Any better ideas?
-- 
Brian May <[EMAIL PROTECTED]>

Re: Bits from the RM

[Brian May]

On Sun, Dec 14, 2003 at 10:58:53AM +1100, Brian May wrote:
> Otherwise, there is no way to filter out this bug report in BTS
> listings.

Not to mention the problem that if -1 is closed, XX needs to be
manually too, but the "owner" of XX is not informed that -1
has been closed (AFAIK).
-- 
Brian May <[EMAIL PROTECTED]>

pthread + malloc = segfault

[kai stammerjohann]

hi,
i have some threads and some mallocs. after a couple of malloc calls, i get a 
SIGSEGV from mallopt.
i compile the app (contains c and c++ files) with "gcc -g -O0 -lstdc++ -lpthread 
..."
(the code works under windows and multithreaded c++ libs, so there aren't any 
faults in the code)
the callstack looks like this:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 49156 (LWP 11020)]
0x40186efa in mallopt () from /lib/libc.so.6
(gdb) where
#0  0x40186efa in mallopt () from /lib/libc.so.6
#1  0x40186145 in malloc () from /lib/libc.so.6
#2  0x0804a3fd in Buffer::checkSpace(unsigned long) (this=0x8089458, 
writelen=4) at common/Buffer.cpp:143
#3  0x0804a507 in Buffer::addDWORD(unsigned long) (this=0x8089458, val=831) at 
common/Buffer.cpp:178
#4  0x0805bfc0 in SearchCommand::handle(NetBuffer*) (this=0x8069348, 
input=0x80893d0) at server/SearchCommand.cpp:79
#5  0x080591c7 in CommandThread::run() (this=0x8089408) at 
server/CommandThread.cpp:30
#6  0x0804ba37 in Thread::threadProc(void*) (param=0x8089408) at Thread.h:68
#7  0x400d3d53 in pthread_start_thread () from /lib/libpthread.so.0
#8  0x400d3d99 in pthread_start_thread_event () from /lib/libpthread.so.0
should i link to special threadsafe c++ libs (and if, how) ?
thanks

Re: mounting tmpfs (and sysfs) defaultly in sarge?

[Marco d'Itri]

On Dec 13, Andreas Metzler <[EMAIL PROTECTED]> wrote:

 >I would propose to handle this similarily to the devpts
 >filesystem i.e. by a init-script instead of cluttering fstab.
Agreed. This also solves the problem of ugly messages at boot when
booting a 2.4 kernel.
udev (and given time many other programs) needs sysfs mounted, so we
should decide if it will be handled by devpts.sh or by a similar script
in a different package.
Currently the udev init script[1] mounts it by itself, but I'd like to
remove this code and assume that something else already did it.


[1] http://www.bofh.it/~md/debian/

-- 
ciao, |
Marco | [3602 dej/G42U8D59c]

Client Development Specialist for Technology firms

[Scott M. Wiseman]

Title: Objective:








To: debian-devel@lists.debian.org

Subject:
RESUME - Client
Development Specialist for Technology firms

IF
this resume reaches you in Error. 

Please
forward to your Human Resources Department

 

 

Resume

 

Scott
Wiseman
13428 Maxella Ave Ste 207
Marina Del
  Rey, CA 90292
310-967-4593

Objective:

To produce successful client engagements for a high
technology firm looking to Increase market share 
and develop brand identity for their products and service offerings.

 Position
Seeking:

Senior Business
Technology Analyst / Client Development Executive

 · Knowledge of relevant technologies:

· Enterprise Solutions:

· Business Intelligence and Relational databases (SQL, Oracle);

· Queuing systems (MSMQ, Oracle AQ);

· EAI Enterprise
Application Integration (Web Services, BizTalk)

· Storage Area Networks, Network Attached Storage (EMC, 

· CRM products (Microsoft CRM);

· Middleware (MTS, DCOM, COM, XML, .NET Framework, Web Services); 

· Internet protocols and products (HTTP, TCP/IP, FTP, Microsoft IIS
Web Server);   

· Content Management Systems/ Knowledge Management (Share point
Portal Server)

· Disaster Recovery and Business Continuity Planning (Veritas,
Storage, Snapshots)
·
Enterprise Networking (VPN, Frame, Router, WAN, Terminal Server, Citrix)
·
Corporate Compliance support(HIPAA, Sarbanes-Oxley, Gramm Leach Bliley Act)

· SMB Solutions:

· MS
Office 97 through 2003, Front Page,etc
·
Exchange 5.5 through 2003, IIS 4.0 through 6.0, SQL 7.0 through SQL 2000
· Veritas
Backup, Ghost, Ultra-Bac, Retrospect, Adobe, Omnipro,
· Legal
Solution, Baji, Compu-Law Vision, etc

· Technical Skills:

· Programming (ASP, SQL
SP, XML, COM, VB Script, HTML, _javascript_, .NET, ADSI, C)

· Over 14 years of software development and IT infrastructure experience.
·
Experience with entire product development life cycle;

· Experience with Infrastructure
Planning and Implementation.  

· Hands-on management of implementation teams; 
· Hands-on
implementation of integration strategies (if needed);

· Experienced integration strategies;

· Proven business process
reengineering skills;

· Experience configuring Firewalls (Net screen, D-Link, Cisco Pix);

· Exchange 5.5 through 2003 Server Setup and Administration;

· NT/ 2000/ 2003 Server
Setup and Administration;

· Install and configured DSU, CSU for ISDN and T-1 Frame Circuits,
phone systems.

· Help Desk Support, Troubling and repairing workstations.

· Sales and Marketing Skills:

· Experience with product/services strategy development, and
customer interaction;
· Ability
to articulate a compelling case for various Company branded Technologies;
·
Outstanding speaking/presentation skills and good writing skills;

· Expertise closing tough customers;

· Experience in developing Lead Generation vehicles;

· Knowledge of Solution Selling (Michael T. Bosworth)

· Experience Managing Call
 Centers and Direct Mail
Campaigns;

· Experience tracking/staying with customer through the Sale
Buy-Cycle;

· Expertise at selling intangible and conceptual
products(Software/Services)

 

· Education:

· 1990 - California State University Northridge,
CA. 
· Completed
Bachelor's Degree in Computer Science.

· Job References:

Job References upon
request.

 

 

 

 

How to depend on Japanese fonts?

[Ben Burton]

Hi.  I have a question in relation to #216440 (kiten requires Japanese
fonts):

Is there a simple or recommended way of making a package depend on
Japanese fonts?

The only solutions I can see are to either:

1) pick a couple of decent fonts and include them in the depends list;
2) pick a couple of decent fonts and include them in the recommends or
suggests list;
3) make a list of all Japanese fonts (separated by | ).

Option (1) seems bad because it forces a choice of font that the user
might not want (bear in mind that Japanese font packages can be quite
large).  Option (3) seems bad because it's ugly and difficult to keep
up-to-date.  And of course option (2) seems bad because the hard
dependency is lost.

Any suggestions?

Ben.

Re: Services I'd like from auric

[Colin Watson]

On Sat, Dec 13, 2003 at 03:56:02PM -0700, Kevin Rosenberg wrote:
> I certainly miss the varied and up-to-date information that I was able
> to get from auric. Taking James Troup's advice from his announcement
> of discussing information we'd like from auric, what's on my mind
> today is the ability to check the NEW queue.

I frequently find myself running 'locate' over the morgue and poking
around in the results in an attempt to figure out when a package was
removed and what it looked like when it was, usually when working on
unknown-package bugs. snapshot.debian.net provides some of the same
functionality but is about an order of magnitude more effort to find
things in (through no fault of its own - what I want here is exactly a
Unix filesystem).

I'm not sure whether this is solvable without exporting the morgue,
which I'm aware would be a big slice of some machine's resources.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: How to depend on Japanese fonts?

[Brian M. Carlson]

On Sun, Dec 14, 2003 at 02:14:05PM +1100, Ben Burton wrote:
> 
> Hi.  I have a question in relation to #216440 (kiten requires Japanese
> fonts):
> 
> Is there a simple or recommended way of making a package depend on
> Japanese fonts?
> 
> The only solutions I can see are to either:
> 
> 1) pick a couple of decent fonts and include them in the depends list;
> 2) pick a couple of decent fonts and include them in the recommends or
> suggests list;
> 3) make a list of all Japanese fonts (separated by | ).

4) Create a meta-package x-fonts-jp (or something like that) which
depends on jp-font-pkg-0 | jp-font-pkg-1 | ... .

5) Create a virtual package x-font-jp which is provided by each Japanese
font package.

Of course, the package names might be better if they were
x-font{,s}-jis, I don't know; I haven't read the bug.

> Option (1) seems bad because it forces a choice of font that the user
> might not want (bear in mind that Japanese font packages can be quite
> large).  Option (3) seems bad because it's ugly and difficult to keep
> up-to-date.  And of course option (2) seems bad because the hard
> dependency is lost.

(4) puts the onus on one package maintainer, and (5) puts the onus on
many maintainers to coordinate (which isn't necessarily a problem, since
it happens all the time). It's only a problem if the maintainer of your
favorite Japanese font forgets to include the Provides: line. I'm really
not sure if there's a simple solution to this.

-- 
Brian M. Carlson <[EMAIL PROTECTED]> 0x560553e7


signature.asc
Description: Digital signature

Re: pthread + malloc = segfault

[Aaron M. Ucko]

kai stammerjohann <[EMAIL PROTECTED]> writes:

> i compile the app (contains c and c++ files) with "gcc -g -O0 -lstdc++ 
> -lpthread ..."
> (the code works under windows and multithreaded c++ libs, so there aren't any 
> faults in the code)

Either that or you got lucky; you might want to try enlisting a memory
checker such as valgrind or Electric Fence to verify that you don't
have a subtle bug.  

> should i link to special threadsafe c++ libs (and if, how) ?

Change "-lpthread" to "-pthread" to ensure that your code is compiled
for thread safety.

[Incidentally, this is somewhat off-topic unless you plan to package
the code in question...]

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.

Re: cvs versioning

[Peter S Galbraith]

Arnaud Vandyck <[EMAIL PROTECTED]> wrote:

> Paul Brossier <[EMAIL PROTECTED]> writes:
> 
> > I am working on packages from cvs upstream sources.  How should I name
> > their debian version ? I give a few examples below.
> >
> > Is there a spec for this somewhere ?
> 
> In the policy?
> 
> /usr/share/doc/debian-policy/policy.txt.gz
> 
> 3.2.1. Version numbers based on dates
> -
> 
> ...
>  However, in some cases where the upstream version number is based
>  on a date (e.g., a development "snapshot" release) the package
>  management system cannot handle these version numbers without
>  epochs.  For example, dpkg will consider "96May01" to be greater
>  than "96Dec24".
> 
>  To prevent having to use epochs for every new upstream version, the
>  version number should be changed to the following format in such
>  cases: "19960501", "19961224".  It is up to the maintainer whether
>  he/she wants to bother the upstream maintainer to change the
>  version numbers upstream, too.

I started a thread on -policy recently where I suggested this was bad
and should be something like 0.19960501 instead, to avoid epochs when
upstream finally declares a 1.0 release.

Peter

Re: Changes in formal naming for NetBSD porting effort(s)

[Joel Baker]

[ If you're being impatient about resolving this, please see the bottom   ]
[ of the email for an imporant bit of information...  ]

[ snip ]

On Sat, Dec 13, 2003 at 04:27:27PM -0500, Branden Robinson wrote:
> 
> On Fri, Dec 12, 2003 at 10:29:05AM -0700, Joel Baker wrote:
> 
> > On Fri, Dec 12, 2003 at 11:54:09AM -0500, Branden Robinson wrote:
> > > What makes a suitable name?  Please be specific.  If you don't know, I
> > > think you should request this information from the NetBSD Foundation.
> > 
> > As far as I can tell, anything which does not use the bare word 'NetBSD'
> > as part of it's name, but I certainly can request clarification from Mr.
> > Mewburn and The NetBSD Foundation about that.
> 
> As I understand it, TNF's view of what dilutes a trademark is
> considerably narrower than that of U.S. courts.  It may be wise to
> obtain a trademark license explicitly authorizing this usage.

I have sent Mr. Mewburn an email requesting both a clarification of what
The NetBSD Foundation would consider acceptable, in a name, and the
rationale behind it, and questioning the possibly of looking into some
form of trademark agreement, particularly one which would allow us to
use something that might otherwise violate the trademark, but still be a
sufficiently distinct name for TNF to be content.

However, see below.

> > I think that is largely a reflection of "nobody had any disagreement on
> > the principle, or a better suggestion for the formal port name", combined
> > with the fact that it triggered reviewing some of the haphazard naming
> > conventions with a critical eye, and making sure that they were reasonable
> > and rational.
> > 
> > The thread is, indeed, split into two interleaved parts, and the
> > non-technical part is almost empty.
> 
> I don't have a problem with the technical issues being grappled with.
> In fact, I'm glad they are.  But the fact that the technical part got a
> good amount of attention doesn't mean the non-technical aspect has been
> adequately grappled with.  And it was on non-technical grounds that Mr.
> Newburn made his request -- "trademark dilution" is not a technical
> concept, but a legal one.

Indeed; I did not mean to imply that it should have been sufficient, only
summarize what folks would find in the thread if they read it - which is to
say, no objections to renaming, and no real discussion of trademark issues
at all. (Notably, the fact that we had no real discussion is part of why I
posted it to -devel, rather than just sending it to the project officials
as a notification/request.)

> BSD is also still a trademark, but I was unable to find any information
> about its licensing, or even whether it is still actively defended.

Hmmm. A good point, though one might reasonable wonder if 'NetBSD' would
not, itself, infringe on this if it were being actively enforced. My
impression is that it is not being actively enforced, but I make no claim
to having done an exhaustive search, or spoken to the current trademark
holders.

> > > > 4) The Debian port name will become 'Debian GNU/KLNetBSD(i386)'[1].
> > > 
> > > Well, no offense, but that's ugly as hell, and is going to square the
> > > amount of confusion people experience when trying to decode our OS
> > > names.
> > 
> > Agreed, unfortunately - it is, and I suspect it may well. Suggestions for
> > better naming welcome, of course (or even a direction to go in).
> 
> We might use names from Christian demonology (since the BSD mascot
> is the cute and devilish "daemon"), with the first letter shared by the
> demon's name and the corresponding BSD flavor.
> 
> Thus:
> 
> Debian FreeBSD  -> Debian Forneus (BSD)
> Debian NetBSD   -> Debian Naberius (BSD)
> Debian OpenBSD  -> Debian Orobos (BSD)
> 
> I got these names from the Wikipedia  http://en2.wikipedia.org/wiki/List_of_specific_demons_and_types_of_demons>.
> 
> Moreover, none of these names are currently registered with the USPTO,
> so we'd be set in that department.

This may well be a solution to many problems in one go; it also happens
to be one I like, but then, I've used that same reference for picking
hostnames on the in-house consulting company's network. So I may be biased.

More on this below.

> > I believe (note: personal view) that the core is a perceived difference
> > between the bare word 'NetBSD', which has, prior to this port, implied a
> > kernel, libc, *and* userland of a specific form, and a variant of that
> > name which is recognizeable, but distinctive enough to not cause confusion
> > between their "product" and what we intend to produce.
> 
> My feeble understanding of U.S. trademark law leads me to believe that
> the *more* similar our product is to theirs, the more grounds they have
> for being able to argue that we're "diluting" the name, because we're
> promoting marketplace confusion.

As far as I understand it, that seems correct. Certainly we're close enough
that it doesn't seem like an un

Re: Any Progress?

[Clint Adams]

> Please cc [EMAIL PROTECTED] about bugs.debian.org problems in future.
> 
> Can you supply some message-ids or subject lines or something so that we
> can investigate? master's e-mail doesn't appear to be generally broken.
> I wonder, though, if all five (!) MXs are doing the right thing.

I've had at least 5 BTS mails bounced back to me, and master continues
to reject with '451 rejected: temporarily unable to verify sender
address'.

I suspect that this message will never reach [EMAIL PROTECTED]

Enhance localepurge? (was Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menuentries

[Nathanael Nerode]

So some people are complaining because they don't like the extra space 
in .desktop files taken up by internationalization.

This is a job for localepurge, or a similar program.  (Read the file -- 
purge locales -- write the file.) It should not preclude using the 
FreeDesktop standard.  So stop complaining about it.  :-)