Re: Ubuntu discussion at planet.debian.org

[Matt Zimmerman]

On Sun, Oct 24, 2004 at 05:42:23PM -0600, Marcelo E. Magallon wrote:

>  Testing is by design all-or-nothing.  As long as a single architecture
>  hasn't buildd support for t-p-u, the buildd support for t-p-u is as
>  good as missing.

This isn't "by design", it's simply the policy which is currently in use.

-- 
 - mdz

Re: NMU on sysklogd

[Javier Fernández-Sanguino Peña]

On Fri, Oct 29, 2004 at 03:50:31PM +0200, Jerome Warnier wrote:
> On Fri, 2004-10-29 at 13:28 +0200, Javier Fernández-Sanguino Peña wrote:
> > I haven't yet contacted Joey, however, since I'm still considering this
> > option and how to do it best. One option, for example, is to do a NMU to
> > experimental so other people can test the package (and verify that the bugs
> > are actuall fixed) before uploading to sid. I have done this for other base
> > packages (like ifupdown). I suggest you think about it (and the
> > consequences of a broken^Wuntested upload at this point) before talking
> > with him.
> We'll see that in due time. I have lots of other things to do.

I'm sure you do. I have been telling you (and you've ignored) some 
steps you can do to help. Since you previously said:

> Could someone go through the list and NMU this? I'm willing to help, if
> necessary.

If you have information, please send it to the BTS, that's the place 
maintainers look for information related to bugs. You shouldn't expect 
people to review the -devel archives everytime they want to find 
information related to a bug, do you?

If you can provide more help (besides adding information to the bugs in the 
BTS) you could prepare or test patches for those bugs you care for. 
Replying in a public mailing list is not the kind of help that would move 
forward a fix.

Regards

Javier

ObBug: 41801 54967 54999 69754 70557 76209 90486 110732 116162 118647 
132401 140776 146819 150423 150423 150423 159708 160454 165098 166531 
166713 166943 173746 173938 174181 194502 203578 206205 210516 215855 
219206 220382 225087 228031 228258 228688 230020 243681 253508 262941 
263224 267112 272581
[Modutils NMU to experimental, yes, I'm breaking the rule since those 
aren't RC and I'm not fixing them in sid, but you get the point]


signature.asc
Description: Digital signature

Bug#278868: ITP: aips -- Astronomical Image Processing System

[Justin Pryzby]

Package: wnpp
Severity: wishlist

* Package name: aips
  Version : 20041029
  Upstream Author : NRAO <[EMAIL PROTECTED]>
* URL : http://www.aoc.nrao.edu/aips/
* License : GPL
  Description : Astronomical Image Processing System from NRAO

 The Astronomical Image Processing System is a software package for
 calibration, data analysis, image display, plotting, and a variety of
 ancillary tasks on Astronomical Data. It comes from the National
 Radio Astronomy Observatory. It is primarily for Radio Astronomy.
 .
 Homepage: http://www.aoc.nrao.edu/aips/

Developers, this is a very large package.  I'm not even sure if its
appropriate for inclusion in Debian.  I will be keeping a copy in my
personal repository, along with all the other astronomy software.

At the moment I'm not even sure how large; it is meant to keep all the
source code along with the executables (and sync via cvs every night
via cron..).  The *source* targzball is 67M at 69% compression.  But
now I have to come up with a way to isolate the runtime files from the
install files (unfortunately not disjoint).

(The Debian version will not do the nightly CVS thing, btw).

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (101, 'testing'), (99, 'unstable'), (9, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.9-rc1
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8

Re: Comparing FHS 2.3 and 2.1

[Manoj Srivastava]

On Fri, 29 Oct 2004 13:16:59 +0200, Nikolai Prokoschenko <[EMAIL PROTECTED]> 
said: 

> On Thu, Oct 28, 2004 at 09:46:47PM +0400, Nikita V. Youshchenko wrote:
>> > Speaking of which: there used to be some proposed addition to FHS
>> > about re-locating all dot-files into ~/etc or some directory like
>> > that. Does anybody know what happened to that? I'm aware of the
>> > problems (sharing $HOME over several different machines etc.),
>> > but but I'll be glad if the mess were out of $HOME.
>> I think there is little hope here.  There are too many apps out
>> that treat home directory as a wastebasket, and probably Linux/Unix
>> itself will be obsoleted faster than all those.

> Most applications can be patched to use another directory for their
> cruft.  It's just the "legal" sutff I'm currently interested in, as
> as soon as it is "recommended" by FHS, it can become a part of
> e.g. Debian Policy and get enforced by patches.

Actually, if it is not common practice, it would probably mean
 that Debian would not adopt FHS 2.3 fully, only bits of it, and
 policy would then enshrine the current practice, and it would be even
 harder to change things.

So, if you have patches ready, I suggest you get moving on
 having them implemented, and not wait for policy to have to outlaw
 your patch set.

manoj
-- 
Four thousand different MAGNATES, MOGULS & NABOBS are romping in my
gothic solarium!!
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: SourceForge.net PR-Web Upgrade Notice

[Blu]

On Tue, Oct 26, 2004 at 10:35:05AM +0100, Luke Kenneth Casson Leighton wrote:
> i'm forwarding this to debian devel for people's attention because
> it would appear that debian has lost a quite large opportunity -
> by not having selinux available.
> 
> l.
> 
> - Forwarded message from "SourceForge.net Team" <[EMAIL PROTECTED]> -
> 
> Old configuration:
> 
>   Debian Potato
[...]
>   ^^
> New configuration:
> 
>   Fedora Linux: Fedora Core 2
>   ^^
[...]

I bet that it is more a marketing than a technical move. They did
something similar moving away from postgresql to DB2 I think, a while ago.

Blu.

RE: agradou

[genice turetta]

Quem é você?
_
MSN Messenger: converse com os seus amigos online.  
http://messenger.msn.com.br

Re: Release-critical Bugreport for October 29, 2004

[Steinar H. Gunderson]

On Fri, Oct 29, 2004 at 04:13:48PM +0100, Jochen Voss wrote:
>>   269366 [] [U] screen: ftbfs [sparc] no tgetent - no screen
> Where does the [U] come from?  I do not see the upstream bug tag
> set on

It is for "sid" in this case.

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

Re: Release-critical Bugreport for October 29, 2004

[Frank Lichtenheld]

On Fri, Oct 29, 2004 at 04:13:48PM +0100, Jochen Voss wrote:
> Hello,
> 
> On Fri, Oct 29, 2004 at 06:30:02AM -0700, BugScan reporter wrote:
> > Package: screen (debian/main)
> > Maintainer: Adam Lazur <[EMAIL PROTECTED]>
> >   269366 [] [U] screen: ftbfs [sparc] no tgetent - no screen
> Where does the [U] come from?  I do not see the upstream bug tag
> set on

U has two meanings there. If it appears in the left [], it means the
upstream tag, if it appears in the right [], it means the sid tag.

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

Re: Release-critical Bugreport for October 29, 2004

[Jochen Voss]

Hello,

On Fri, Oct 29, 2004 at 06:30:02AM -0700, BugScan reporter wrote:
> Package: screen (debian/main)
> Maintainer: Adam Lazur <[EMAIL PROTECTED]>
>   269366 [] [U] screen: ftbfs [sparc] no tgetent - no screen
Where does the [U] come from?  I do not see the upstream bug tag
set on

http://bugs.debian.org/269366

The problem is in fact Debian specific: the Debian package patches
configure.in but uses the old (non-regenerated) configure.  This
makes detection of libncursesw fail.

I hope this helps,
Jochen
-- 
http://seehuhn.de/


signature.asc
Description: Digital signature

$HOME/.dotfiles and FHS 2.3 (was: Comparing FHS 2.3 and 2.1)

[Frank Küster]

"Marcelo E. Magallon" <[EMAIL PROTECTED]> wrote:

> On Tue, Oct 26, 2004 at 03:02:02PM -0500, Manoj Srivastava wrote:
>
>  >  5)==
>  > 
>  > User specific configuration files for applications are stored in the
>  > user's home directory in a file that starts with the '.' character (a
>  > "dot file"). 
[...]
>  Holy...  and that's the area of FHS... how?
>
>  First, does every single package have to comply with this?
>
>  Off the top of my head:
>
> * aspell stores user's dictionaries in ~/, and it store several
>   files per languaje.

These I wouldn't name "configuration files". They are data files
containing my personal input for later reuse. Although, indeed, it would
be nice to have them in a subdirectory.

> * bash reads and writes a number of files in ~/ (.bash_profile,
>   .bashrc, .bash_history)
> * there are several directories related to GNOME (at least ~/.gnome2
>   and ~/.gnome2_private)
> * vim has ~/.vimrc, ~/.viminfo (configure IIRC), ~/.vim/

They should probably use their own directory in the future. I think this
would really be a good idea.

> * Window Maker stores its configuration across several files and
>   directories under ~/GNUstep (configurable) (and no, I won't change
>   the default because it's configurable via an environment variable)

I was always annoyed by this, and it's not easy to find the solution in
the documentation (I only learned of the environment variable in this
thread). Why not change the default, when everybody can get back the
original buggy behavior by setting an environment variable?

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: NMU on sysklogd

[Jerome Warnier]

On Fri, 2004-10-29 at 13:28 +0200, Javier Fernández-Sanguino Peña wrote:
> On Fri, Oct 29, 2004 at 11:56:46AM +0200, Jerome Warnier wrote:
> > In fact, I dug into the problem, and found that the initscript
> > (/etc/cron.daily/sysklogd) had a 'reload-or-restart' argument, which is
> > used by the cronjob and does not always work (in my case, on several
> > machines, never) nor do the restart one (I'm not sure anymore I tried
> > it, though). So, I replaced the last line:
> 
> (...)
> 
> I think it would be best if you sent this information to the BTS, as a 
> patch for the current package. That way others (including the maintainer, 
> which needs not be following this thread) can test it too. 
Well, the problem is that I'm not happy with that solution. In fact, the
initscript should be fixed, which maybe involves bug #211858 (relates to
--pidfile), which has already a non-applied patch.
The fact is that both 'reload-or-restart' and 'restart' do not work as
expected.

> Please provide as much information in order to reproduce this issue as 
> possible too.
It is very simple: install a Sarge, let it run and you'll see at some
point that /var/log/syslog (this is not the only file affected of
course) is empty and keeps empty and syslog.0 continues to be filled by
the new messages.
All my Sarge systems show the same behaviour.

> Those are the very first steps you should take before even considering a 
> NMU. Also, in this particulary case, read the README.NMU file in the 
> sources.
I cannot do a NMU myself, so don't worry, I won't ;-)

> I've been reviewing these packages' bugs. Even if some patches could be
> introduced to fix some of the issues I'm not sure all of them are
> appropiate. Even so, this package is of base priority, so it's frozen in
> sarge, only RC bugs should be fixed there. Maybe a cleanup of the package
I'm aware of that too.
> could be considered (following the NMU procedures above) and I'm open to
> doing it myself (as I've been doing it for other base packages).
Well, thanks but it is not quite ready for that.

> I haven't yet contacted Joey, however, since I'm still considering this
> option and how to do it best. One option, for example, is to do a NMU to
> experimental so other people can test the package (and verify that the bugs
> are actuall fixed) before uploading to sid. I have done this for other base
> packages (like ifupdown). I suggest you think about it (and the
> consequences of a broken^Wuntested upload at this point) before talking
> with him.
We'll see that in due time. I have lots of other things to do.

> Regards
> 
> Javier
-- 
Jerome Warnier <[EMAIL PROTECTED]>
BeezNest s.a r.l.

Re: Very BIG Problem with debian packages versioning...

[Oded Shimon]

On Friday 29 October 2004 12:23, Davor Ocelic wrote:
> On Fri, 29 Oct 2004 12:17:31 +0200
>
> Oded Shimon <[EMAIL PROTECTED]> wrote:
> > Just an idea, try
>
> 'which clamd' on both machines.

BTW, the site:

http://www.catb.org/~esr/faqs/smart-questions.html

Might be an interesting read for you... I very much reccommend you check it.

- ods15

Re: NMU on sysklogd

[Andreas Barth]

* Jerome Warnier ([EMAIL PROTECTED]) [041028 15:25]:
> It is really annoying since every log analysis tool is failing on this
> every week at least? By "log analysis tool" I mean anything relying on
> files in /var/log to do something.

> [..]

> Could someone go through the list and NMU this? I'm willing to help, if
> necessary.

For Bug 275111 - I think this bug needs a proper explanaition / patch,
because that's the only way to fix it.

In general: sysklogd is already frozen for release of sarge. So, please
don't upload _anything_ which won't make it for sarge, i.e. only RC-bug
fixes. Changes like using /etc/defaults might be nice, but are not
possible any more for sarge. (And, I guess that the maintainer might do
a cleanup round after release of sarge.)


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

Re: Drop testing

[Christoffer Sawicki]

> > The Debian Desktop Distribution will be something like this. I believe
> > more details will be available soon. Until then,
> > http://debiandesktop.org/ has a concept paper.
>
> Is this a fork from the main debian distribution?

No. Packages will migrate from `unstable' into the desktop tree by using a 
script similar to the one used for `testing'. The main difference is the 
conditions thas has to be fulfilled for a package to migrate.

*/ Christoffer Sawicki <[EMAIL PROTECTED]>

Re: NMU on sysklogd

[Javier Fernández-Sanguino Peña]

On Fri, Oct 29, 2004 at 11:56:46AM +0200, Jerome Warnier wrote:
> In fact, I dug into the problem, and found that the initscript
> (/etc/cron.daily/sysklogd) had a 'reload-or-restart' argument, which is
> used by the cronjob and does not always work (in my case, on several
> machines, never) nor do the restart one (I'm not sure anymore I tried
> it, though). So, I replaced the last line:

(...)

I think it would be best if you sent this information to the BTS, as a 
patch for the current package. That way others (including the maintainer, 
which needs not be following this thread) can test it too. 

Please provide as much information in order to reproduce this issue as 
possible too.

Those are the very first steps you should take before even considering a 
NMU. Also, in this particulary case, read the README.NMU file in the 
sources.

I've been reviewing these packages' bugs. Even if some patches could be
introduced to fix some of the issues I'm not sure all of them are
appropiate. Even so, this package is of base priority, so it's frozen in
sarge, only RC bugs should be fixed there. Maybe a cleanup of the package
could be considered (following the NMU procedures above) and I'm open to
doing it myself (as I've been doing it for other base packages).

I haven't yet contacted Joey, however, since I'm still considering this
option and how to do it best. One option, for example, is to do a NMU to
experimental so other people can test the package (and verify that the bugs
are actuall fixed) before uploading to sid. I have done this for other base
packages (like ifupdown). I suggest you think about it (and the
consequences of a broken^Wuntested upload at this point) before talking
with him.

Regards

Javier


signature.asc
Description: Digital signature

Re: Comparing FHS 2.3 and 2.1

[Nikolai Prokoschenko]

On Thu, Oct 28, 2004 at 09:46:47PM +0400, Nikita V. Youshchenko wrote:
> > Speaking of which: there used to be some proposed addition to FHS about
> > re-locating all dot-files into ~/etc or some directory like that. Does
> > anybody know what happened to that? I'm aware of the problems (sharing
> > $HOME over several different machines etc.), but but I'll be glad if the
> > mess were out of $HOME.
> I think there is little hope here.
> There are too many apps out that treat home directory as a wastebasket, and
> probably Linux/Unix itself will be obsoleted faster than all those.

Most applications can be patched to use another directory for their cruft.
It's just the "legal" sutff I'm currently interested in, as as soon as it
is "recommended" by FHS, it can become a part of e.g. Debian Policy and
get enforced by patches. 

-- 
Nikolai Prokoschenko 
[EMAIL PROTECTED] / Jabber: [EMAIL PROTECTED]

Re: Very BIG Problem with debian packages versioning...

[Davor Ocelic]

On Fri, 29 Oct 2004 12:17:31 +0200
Oded Shimon <[EMAIL PROTECTED]> wrote:

> Just an idea, try

'which clamd' on both machines.

Re: Very BIG Problem with debian packages versioning...

[Oded Shimon]

Just an idea, try
apt-get clean
apt-get --reinstall install 

hand embroidery badges

[longfly]

Dear Sirs,
It is immense pleasure to introduce you ourselves as we are one of the leading
manufacturers and exporters all kinds of hands embroidery badges,sashes,
pennants,flags,flagstaff,banners,family crest,emblems,and also other sorts of
products in the markets.
Therefore,we do cordially request you to please give us a chance and see 
our abilities
in the workmanship.and assure you with guarantee that we shall supply you 
our very
finest qualities of products with the cost of very low.

After having your reply and advise then we shall send you a sample for your 
inspection

and approval.and fulfill your whole requirements in time. please be sure.
Thank you very much in advance,we remain.
With best regards.
Truly yours
M.Jahangir
> 

Very BIG Problem with debian packages versioning...

[Vincenzo Belloli]

Package: clamav-daemon
Version: 0.80-2
The problem is related to clamav debian packages maintained by ... and 
hosted here:

deb http://people.debian.org/~sgran/debian woody main
I've 2 identical machines. These are versions installed in the 2 machines:
server1# dpkg -l | grep clam
ii  clamav 0.80-2 Antivirus scanner for Unix
ii  clamav-base0.80-2 Base package for clamav, an anti-virus 
utili
ii  clamav-daemon  0.80-2 Powerful Antivirus scanner daemon
ii  clamav-freshcl 0.80-2 Downloads clamav virus databases from 
the In
ii  clamav-testfil 0.80-2 Use these files to test that your 
Antivirus
ii  libclamav1 0.80-2 Virus scanner library
ii  libclamav1-dev 0.80-2 Clam Antivirus library development files

server2# dpkg -l | grep clam
ii  clamav 0.80-2 Antivirus scanner for Unix
ii  clamav-base0.80-2 Base package for clamav, an anti-virus 
utili
ii  clamav-daemon  0.80-2 Powerful Antivirus scanner daemon
ii  clamav-freshcl 0.80-2 Downloads clamav virus databases from 
the In
ii  clamav-testfil 0.80-2 Use these files to test that your 
Antivirus
ii  libclamav1 0.80-2 Virus scanner library
ii  libclamav1-dev 0.80-2 Clam Antivirus library development files

BUT THIS IS THE MATTER: on the 2 machines there are different versions 
of clamd anche clamdscan. Why che debian packages have not been updated 
 Is it normal that the same debian package version contains 
different program versions 

server1# clamd -V
ClamAV 0.80/559/Thu Oct 28 15:08:33 2004
server1# clamdscan -V
ClamAV 0.80/559/Thu Oct 28 15:08:33 2004
server2# clamd -V
ClamAV 0.80/560/Fri Oct 29 09:32:46 2004
server2# clamdscan -V
ClamAV 0.80/560/Fri Oct 29 09:32:46 2004
Now, if i want v.560 on all machines must uninstall the packages and 
reinstall them, because from the dpkg point of view the packages has not 
changed !!

Thanks a lot.
Vincenzo Belloli

Re: AMD64 Archive Key compromised!

[Francesco P. Lovergine]

On Fri, Oct 29, 2004 at 08:52:07AM +0200, Jens Schmalzing wrote:
> 
> I guess this is the modern version of "real men just upload their
> important stuff on ftp, and let the rest of the world mirror it."
> 

RMS used to have no password at MIT times, indeed :) 
How times changed!

-- 
Francesco P. Lovergine

Re: NMU on sysklogd

[Jerome Warnier]

On Fri, 2004-10-29 at 09:02 +0200, Petter Reinholdtsen wrote:
> [Jerome Warnier]
> > So what? Am I stuck with my problem like so many people are already? And
> > a "friendly" takeover of the package?
> 
> I suspect you will discover and get stuck in the power games in Debian.
I always found that funny, but I know the game. ;-)

> > I already have to problem on at least 4 machines, with things as
> > POP-before-SMTP and log analysers, packaged in Debian.
> 
> I would recommend changing to another syslogd.  There are several, and
> you could switch to one with a closer match to your needs.
Well, I already tried others, but they have more dependencies or are
more difficult to configure to do what I want. And sysklogd is in
section "base", so in my point of view, it should just _work_ out of the
box. Moreover it is the default syslogd installed for now.

In fact, I dug into the problem, and found that the initscript
(/etc/cron.daily/sysklogd) had a 'reload-or-restart' argument, which is
used by the cronjob and does not always work (in my case, on several
machines, never) nor do the restart one (I'm not sure anymore I tried
it, though). So, I replaced the last line:
/etc/init.d/sysklogd reload-or-restart > /dev/null
with:
kill -HUP `cat /var/run/syslogd.pid` > /dev/null

One more thing to say: because of this bug (#275111), the logs do not
get rotated right, which can cause big trouble on heavily-loaded servers
(or using Quagga, which generates a lot of messages because of failed
communication with SNMP, but that's another story).

-- 
Jerome Warnier <[EMAIL PROTECTED]>
BeezNest s.a r.l.

Re: An important lesson

[Scott James Remnant]

On Thu, 2004-10-28 at 16:57 -0700, Don Armstrong wrote:

> On Thu, 28 Oct 2004, Scott James Remnant wrote:
> > On Thu, 2004-10-28 at 18:08 +0200, Adrian 'Dagurashibanipal' von Bidder
> > wrote:
> > > On Thursday 28 October 2004 16.40, Matthew Garrett wrote:
> > > > Warning: The signature is bad.
> > > 
> > > I guess this was unavoidable in a posting about a security related issue 
> > > with GnuPG...
> > > 
> > Verifies fine here.
> 
> If you ignore the:
> 
> gpg: WARNING: This key has been revoked by its owner!
> gpg:  This could mean that the signature is forgery.
> gpg: reason for revocation: Key has been compromised
> gpg: revocation comment: Compromised on the uid/gid remapping on alioth
> 
> perhaps.
> 
Heh, had to refresh the key to get *that* :D  I already had that key in
my keyring unrevoked.

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

Bug#278767: ITP: cpufrequtils -- Shared library and utilities to deal with the CPUFreq Linux kernel feature

[Mattia Dongili]

Package: wnpp
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: cpufrequtils
  Version : 0.0+0.1pre1
  Upstream Author : Dominik Brodowski <[EMAIL PROTECTED]>
* URL : http://www.brodo.de/cpufreq/
* License : GPL v2
  Description : Shared library and utilities to deal with the cpufreq linux 
kernel feature

This package will generate 3 packages:

* Package name: cpufrequtils
 This package contains two utilities for inspecting and setting the
 cpu frequency through both the sysfs and procfs CPUFreq kernel
 interfaces.

* Package name: libcpufreq0
 This library provide an unified method to access the CPUFreq kernel
 interface.

* Package name: libcpufreq-dev
 Thi package provides everything that is needed for developing own
  programs using libcpufreq.


- -- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (990, 'testing'), (300, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.9-1
Locale: LANG=en_GB, LC_CTYPE=en_GB

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

iD8DBQFBgghegpRPaOotLEERAnMPAKC8lopSiU72+m+ocz+2wd55Dt4xAQCfQuFs
HDJoXV/arZMTxWjjIKBmtHM=
=Evli
-END PGP SIGNATURE-

Re: software updates file in /usr -- policy bug?

[martin f krafft]

also sprach Wouter Verhelst <[EMAIL PROTECTED]> [2004.10.29.1002 +0200]:
> > > dpkg should not put files in /usr when it extracts programs either if
> > > /usr MUST NOT BE WRITTEN TO... ;)
>^^
> > Come on! The FHS regulates what normal software can/should do,
> > partially so that package managers can work reliably. dpkg is the
> > package manager, thus it is exempt from the FHS.

I noted the smiley. I still wanted to make it explicit.

In fact, I should have been even clearer. The FHS applies to the
filesystem structure are run-time, not at installation time. It
guides the installation, but only such that when the installation
phase is complete, the system can switch to run-time and be
FHS-compliant from the start onwards.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, admin, user, and author
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!


signature.asc
Description: Digital signature

Re: software updates file in /usr -- policy bug?

[Wouter Verhelst]

On Fri, Oct 29, 2004 at 08:49:54AM +0200, martin f krafft wrote:
> also sprach Chris Cheney <[EMAIL PROTECTED]> [2004.10.29.0823 +0200]:
> > dpkg should not put files in /usr when it extracts programs either if
> > /usr MUST NOT BE WRITTEN TO... ;)
   ^^
> Come on! The FHS regulates what normal software can/should do,
> partially so that package managers can work reliably. dpkg is the
> package manager, thus it is exempt from the FHS.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: Drop testing

[Manoj Srivastava]

On 25 Oct 2004 13:05:51 -0700, Thomas Bushnell BSG <[EMAIL PROTECTED]> said: 

> Anthony Towns  writes:
>> * One of Testing's goals was to be 95% releasable at all times.
>> * It hasn't been.
>> * Why not?
>> (a) RC bugs
>> (b) Can't install it
>> (c) Security vulnerabilities

> This is the crux of the problem, I think, but I'm a little confused.

> How does (a) contribute to this?  The assumption behind an RC bug is
> "we can't release with this bug unfixed".  But the problem is that,
> of course, we *do*, and we *have*, because many RC bugs are in
> things we have already released.  In other words, woody has RC bugs
> in it Right Now.  But that doesn't stop us from continuing to call
> it stable.

Did we know it was a RC bug when we released it? I think
 not. We do not live in a environment where we have perfect
 information,  so we do the best we can. However, if we let known RC
 bugs slide, the resulting release would be far worse -- since now ew
 have bugs we do not know about at the point of release, and bugs that
 we did, and let slide.

> So the RC bugs should not be blocking release unless they are *new*

No. If they are release critical, they are critical -- and
 they block the release. Anything else impacts the quality of
 distribution and starts a slippery slope towards mediocrity.

We have already blown it as a distribution with cutting edge
 releases -- our reputation rests on quality, and r0ock solid
 stability.

> RC bugs which don't already exist.  In other words, a new stable
> release shouldn't be worse, but it doesn't have to be maximally
> better.  It shouldn't have new RC bugs, but it's tolerable if it
> continues to have the same old ones.

I vehemently disagree. We are not people who have found common
 cause to only slowly deteriorate towards mediocrity; we are folks who
 are trying to put together the best possible distribution of Linux.

If people want a good enough distribution, they can try
 mandrake or red hat.

manoj
-- 
Mount St. Helens should have used earth control.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Several X applications refuse to start

[Andreas Tille]

On Thu, 28 Oct 2004, Sean Perry wrote:
1) what locale? try C.
[EMAIL PROTECTED]:~$ locale
LANG=C
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_PAPER="C"
LC_NAME="C"
LC_ADDRESS="C"
LC_TELEPHONE="C"
LC_MEASUREMENT="C"
LC_IDENTIFICATION="C"
LC_ALL=C
[EMAIL PROTECTED]:~$ emacs
X protocol error: BadValue (integer parameter out of range for operation) on 
protocol request 45
Fatal error (6).Aborted
2) this looks like a font issue (as you mentioned) try forcing the app to 
load 'fixed' as its font.
I also tend to see the problem in finding the right fonts.  When looking at
the strace output all applications I mentioned (emacs, xdvi, gv) have certain
problems with fonts, but I have neigther an idea how to force fixed fonts
nor how to fix the problem.  Regarding to the things I changed with the fonts
I was following some hints from
   http://www.paulandlesley.org/linux/xfree4_tt.html#FONTS-FILES
which might be summed up in this script:
   MSTTFONTDIR=/usr/share/fonts/truetype/msttcorefonts
   cd ${MSTTFONTDIR}
   ttmkfdir -o fonts.scale
   head -1 fonts.scale > fonts.dir
   tail +2 fonts.scale | tac >> fonts.dir
   cp fonts.dir fonts.scale
   cd /etc/X11/fonts/TrueType
   cp -a ${MSTTFONTDIR}/fonts.dir .
   # the following script was downloaded via the link I mentioned above
   #   because the site has moved it is attached to this mail
   /tmp/download/mkfontalias.py
   grep 'iso8859-1"' fonts.alias > msttcorefonts.alias
   rm -f fonts.dir fonts.alias
   update-fonts-alias TrueType
I had to do this to get MagicPoint working with TrueType fonts.  I hope that
this did not break other important things.
Any font expert here who might see the problem?
Kind regards
Andreas.#!/usr/bin/python
#
# This is a short python utility to assist people in de-uglification of 
# their true type fonts. Basically, creates a fonts.alias file from the 
# fonts.dir file found in the directory.
#
# Consider this software to be under GPL.
#
# Roman Sulzhyk, Starmedia Networks, 2000. [EMAIL PROTECTED]
# --
# 20.05.2000: Added common MS webfonts as fontnames to map:
# Verdana, Tahoma, Impact, Arial Black, Comic Sans MS, Georgia, Trebuchet MS.
# R.K.Aa. [EMAIL PROTECTED] 
# --
# 21.05.2000: Added 'cheating' - sizes 6,7 and 8 now map to 9 point fonts.
# --
import sys, string, os

_font_sizes = range(6, 16) + [ 18, 24 ]
_infile = 'fonts.dir'
_outfile = 'fonts.alias'

# Resolution
_res = [ '75', '75' ]

# Do 'cheating' to make sizes 6,7,8 as 9 bit fonts
_cheat_map = { 6 : 9,
   7 : 9,
   8 : 9 }

# The fonts to map. Format name : alias
_font_map = { 'Arial' : 'Arial',
 'Times New Roman' : 'Times New Roman',
 'Verdana' : 'Verdana',
 'Tahoma' : 'Tahoma',
 'Impact' : 'Impact',
 'Arial Black' : 'Arial Black',
 'Comic Sans MS' : 'Comic Sans MS',
 'Georgia' : 'Georgia',
 'Trebuchet MS' : 'Trebuchet MS',
 'Courier New' : 'Courier New' }

# Read in the fonts.
try:
# Strip the first line
fonts = open ( _infile ).readlines()[1:]
except IOError, val:
sys.stderr.write ( 'Cannot read %s (%s) - are you sure you are in the '
   'fonts directory?\n' % (_infile, val) )
sys.exit(1)

# Now, create the output
_aliases = []
for line in fonts:
try:
# Get rid of the first entry, but mind that other may have 
# spaces in them
font = string.strip(string.join ( string.split ( line, ' ' )[1:], ' '))
except IndexError:
sys.stderr.write ( 'Cannot parse %s line: %s\n' % (_infile, line ) )
sys.exit(1)

entries = string.split ( font, '-' )

if len(entries) != 15:
# Seems to be invalid
sys.stdrr.write ( 'Invalid font: %s\n' % (font) )
sys.exit(1)

name = entries[2]

map = _font_map.get ( name, None )

if map:
# Create a bunch of aliases, for each size
for size in _font_sizes:
# Do the 'cheating' - fallback to size if not in the cheat map
real_size = _cheat_map.get ( size, size )

name = string.join ( entries[:7] + [ str(real_size), 
 str(real_size * 10) ] + 
 entries[9:], '-' )

alias = string.join ( entries[:2] + [map] + entries[3:7] + 
 [ str(size), str(size * 10) ] + 
  _res + entries[11:], '-' )

# Add the entry to the aliases
_aliases.append ( '"%s" "%s"' % (alias, name) )

# Boast
print 'Created %s aliases' % len(_aliases)

# Backup the existing file
_bak = _outfile + '.bak' 
if os.path.exists ( _outfile ) and not os.path.exists ( _bak ):
try:
os.rename ( _outfile, _bak )
except OSError, val:
sys.stderr.write ( 'Cannot backup %s to %s: %s\n' % (_outfile, _bak, 
   val) )
sys.exit(1)
else:
print 'Backed up ex

Re: An important lesson

[Adrian 'Dagurashibanipal' von Bidder]

On Friday 29 October 2004 01.57, Don Armstrong wrote:
> On Thu, 28 Oct 2004, Scott James Remnant wrote:
> > On Thu, 2004-10-28 at 18:08 +0200, Adrian 'Dagurashibanipal' von Bidder
> >
> > wrote:
> > > On Thursday 28 October 2004 16.40, Matthew Garrett wrote:
> > > > Warning: The signature is bad.
> > >
> > > I guess this was unavoidable in a posting about a security related
> > > issue with GnuPG...
> >
> > Verifies fine here.
>
> If you ignore the:
>
> gpg: WARNING: This key has been revoked by its owner!
> gpg:  This could mean that the signature is forgery.
> gpg: reason for revocation: Key has been compromised
> gpg: revocation comment: Compromised on the uid/gid remapping on alioth
>
> perhaps.

Ah, now I see. I didn't really notice what key was used to sign the original 
message...

greets
-- vbi

-- 
Oops


pgpzKsbmdm6iK.pgp
Description: PGP signature

Re: AMD64 Archive Key compromised!

[Jens Schmalzing]

Hi,

Adam Majer writes:

> But to have a secring.gpg on Google?

I guess this is the modern version of "real men just upload their
important stuff on ftp, and let the rest of the world mirror it."

Regards, Jens.

-- 
J'qbpbe, le m'en fquz pe j'qbpbe!
Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!

Re: NMU on sysklogd

[Petter Reinholdtsen]

[Jerome Warnier]
> So what? Am I stuck with my problem like so many people are already? And
> a "friendly" takeover of the package?

I suspect you will discover and get stuck in the power games in Debian.

> I already have to problem on at least 4 machines, with things as
> POP-before-SMTP and log analysers, packaged in Debian.

I would recommend changing to another syslogd.  There are several, and
you could switch to one with a closer match to your needs.

Re: software updates file in /usr -- policy bug?

[martin f krafft]

also sprach Chris Cheney <[EMAIL PROTECTED]> [2004.10.29.0823 +0200]:
> dpkg should not put files in /usr when it extracts programs either if
> /usr MUST NOT BE WRITTEN TO... ;)

Come on! The FHS regulates what normal software can/should do,
partially so that package managers can work reliably. dpkg is the
package manager, thus it is exempt from the FHS.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, admin, user, and author
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!


signature.asc
Description: Digital signature

Re: software updates file in /usr -- policy bug?

[Chris Cheney]

On Mon, Oct 25, 2004 at 07:11:45PM +0200, martin f krafft wrote:
> Hi all,
> 
> apt-spy and pciutils (and possibly others) contain methods to update
> a database integral to their operation.
> 
>   - `apt-spy update` downloads the list of available Debian mirrors
> to /usr/share/apt-spy (see #277816).
> 
>   - `update-pciids` downloads a new /usr/share/misc/pci.ids
> 
> I think these are both in violation with the FHS, which states
> (Chapter 4, emphasis mine, using caps instead of asterisks for
> readability):
> 
>   "/usr is shareable, READ-ONLY DATA. That means that /usr should be
>   shareable between various FHS-compliant hosts and MUST NOT BE
>   WRITTEN TO."

dpkg should not put files in /usr when it extracts programs either if
/usr MUST NOT BE WRITTEN TO... ;)

Chris