Bug reports missing

[Andreas Tille]

Hi,

I just sendet

  mailx -s "Merge" [EMAIL PROTECTED] <<...
  merge 219863 223355
  close 223355
  thanks

and got the answer mentioned below.  In fact my research showed that #219863
does not exist in the BTS.  If this is a known issue (probably caused by the
current administration issues) forget it.  I just wanted to set a marker to
not forget this issue.

Kind regards

  Andreas.

-- Forwarded message --
Date: Wed, 10 Dec 2003 00:48:05 -0600
From: Debian Bug Tracking System <[EMAIL PROTECTED]>
To: Andreas Tille <[EMAIL PROTECTED]>
Cc: #223355 ,
 Andreas Tille <[EMAIL PROTECTED]>
Subject: Processed: Merge

Processing commands for [EMAIL PROTECTED]:

> merge 219863 223355
Bug number 219863 not found.

> close 223355
Bug#223355: tipptrainer: Seg fault after starting lesson
'close' is deprecated; see http://www.debian.org/Bugs/Developer#closing.
Bug closed, send any further explanations to [EMAIL PROTECTED] (B.Schreiber)

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)

Automatical loading 2.6 modules using module-init-tools

[Andreas Tille]

Hi,

/usr/share/doc/module-init-tools/FAQ tells something about the reason why
in RedHat modules are not loaded automatically.  I'm missing any statement
why this fails in Debian.  I'm I missing something or is this a bug (at least
a wishlist documentation one)?

Kind regards

   Andreas.

Re: Automatical loading 2.6 modules using module-init-tools

[Martin Pitt]

Hi Andreas!

On 2003-12-10  8:34 +0100, Andreas Tille wrote:
> /usr/share/doc/module-init-tools/FAQ tells something about the reason why
> in RedHat modules are not loaded automatically.  I'm missing any statement
> why this fails in Debian.  I'm I missing something or is this a bug (at least
> a wishlist documentation one)?

Please check that you don't have anything in /etc/modprobe.d/ that
sounds like devfs. I encountered the same problem a while ago and
solved it like this: Copy /etc/modprobe.devfs to
/etc/modprobe.d/1devfs and run update-modules. This should regenerate
/lib/modules/modprobe.conf.

I don't know whether this is a bug in module-init-tools or whether
this was my fault. I often tinker with the kernel and modules, maybe
you and I made the same error...

Please tell me whether it worked. If so, then maybe Marco can fix that
in module-init-tools?

Have a nice day!

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


signature.asc
Description: Digital signature

Re: Automatical loading 2.6 modules using module-init-tools

[Andreas Tille]

On Wed, 10 Dec 2003, Andreas Tille wrote:

> /usr/share/doc/module-init-tools/FAQ tells something about the reason why
> in RedHat modules are not loaded automatically.
Sorry for the noise.  I just had no module-init-tools installed when installing
my self-made kernel-2.6test11 package and thus "depmod -a" failed for several
modules.  Now "depmod -a" runs smoothly and automatic module loading works
fine (with exception of alsa sound, but this seems to be a *-user related
question - even if I would love to hear some experiences, perhaps in private).

Kind regards

 Andreas.

Re: Initrd and software raid [was: Initrd rocks!]

[Florent Rougon]

Brian May <[EMAIL PROTECTED]> wrote:

> I believe the kernel raid1 autodetection only works if raid1 is compiled
> into the kernel.

That is true as explained in:

  http://marc.theaimsgroup.com/?l=linux-raid&m=105232695713715&w=2

In short, to get autostart with md compiled as modules, you need to
apply an md patch from Paul Clements (I never tried this patch).

BTW, linux-raid seems not to be archived on mlist.linux.raid any more
since about August 2002 which, uhm, sucks.

> In anycase, initrd images generated from mkinitrd in Debian do not
> autodetect.

Also, perhaps it is interesting to note that the md maintainer, Neil
Brown, seems to prefer manual settings in boot params instead of
autodetection for md arrays. Autodetection was advocated in the SW Raid
howto, which is terribly outdated. I for myself switched from
autodetection to manual setting in my GRUB config files and am happy
with this setup (I hate black magic). Example:

  kernel /boot/vmlinuz-2.4.18 [your usual kernel cmdline params] root=/dev/md0 
ro raid=noautodetect md=0,/dev/hda5,/dev/hdc1

Note: this starts the root array only; the other arrays are started by a
  "mdadm -A -s" from /etc/init.d/mdadm-raid.

> IIRC, There is a parameter to mdadm (--scan?) that could be used for
> this, but when I asked the initrd maintainer I was given a good reason
> why it was not used (sorry; I can't remember what this was now; it might
> simply be that the mdadm code is unreliable, inefficient, or buggy).

I think this is unlikely, since (-s = --scan) is what is used in the
Debian aforementioned init script for mdadm (/etc/init.d/mdadm-raid).
Also, I use it without any problem since several months now, but my
setup is not very exotic.

-- 
Florent

Re: Automatical loading 2.6 modules using module-init-tools

[Martin Pitt]

Hi!

On 2003-12-10  9:20 +0100, Martin Pitt wrote:
>  Copy /etc/modprobe.devfs to /etc/modprobe.d/1devfs and run
>  update-modules. This should regenerate /lib/modules/modprobe.conf.

Err, I just see that you didn't tell whether you are using devfs or
the "old" ones. In the latter case, this solution certainly doesn't
help. But maybe it is the same problem. Please look at
/lib/modules/modprobe.conf whether it looks reasonable.

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


signature.asc
Description: Digital signature

Re: Bug reports missing

[Colin Watson]

On Wed, Dec 10, 2003 at 08:30:49AM +0100, Andreas Tille wrote:
> I just sendet
> 
>   mailx -s "Merge" [EMAIL PROTECTED] <<...
>   merge 219863 223355
>   close 223355
>   thanks
> 
> and got the answer mentioned below.  In fact my research showed that #219863
> does not exist in the BTS.

#219863 is archived, as http://bugs.debian.org/219863 says near the top
of the page. You can't make any changes to archived bugs.

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Bug reports missing

[Colin Watson]

On Wed, Dec 10, 2003 at 11:22:42AM +0100, Andreas Tille wrote:
> On Wed, 10 Dec 2003, Colin Watson wrote:
> > On Wed, Dec 10, 2003 at 08:30:49AM +0100, Andreas Tille wrote:
> > > I just sendet
> > >
> > >   mailx -s "Merge" [EMAIL PROTECTED] <<...
> > >   merge 219863 223355
> > >   close 223355
> > >   thanks
> > >
> > > and got the answer mentioned below.  In fact my research showed that 
> > > #219863
> > > does not exist in the BTS.
> >
> > #219863 is archived, as http://bugs.debian.org/219863 says near the top
> > of the page. You can't make any changes to archived bugs.
> 
> OK, perhaps I should have used
>merge 223355 219863
> to avoid this - which is not *really* important.

No, you can't make *any* changes to archived bugs. This includes merging
other bugs with them (merge is commutative).

> But the problme was that
>http://bugs.debian.org/219863
> showed some kind of "This bug report does not exist" when I tried this 
> morning.
> Seems to be fixed now ...

Don't know about that. All the relevant files are dated Nov 9 so I'm not
sure how that could have gone wrong ...

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Bug reports missing

[Andreas Tille]

On Wed, 10 Dec 2003, Colin Watson wrote:

> On Wed, Dec 10, 2003 at 08:30:49AM +0100, Andreas Tille wrote:
> > I just sendet
> >
> >   mailx -s "Merge" [EMAIL PROTECTED] <<...
> >   merge 219863 223355
> >   close 223355
> >   thanks
> >
> > and got the answer mentioned below.  In fact my research showed that #219863
> > does not exist in the BTS.
>
> #219863 is archived, as http://bugs.debian.org/219863 says near the top
> of the page. You can't make any changes to archived bugs.
OK, perhaps I should have used
   merge 223355 219863
to avoid this - which is not *really* important.  But the problme was that
   http://bugs.debian.org/219863
showed some kind of "This bug report does not exist" when I tried this morning.
Seems to be fixed now ...

Kind regards

Andreas.

/usr/bin/xpp with different functionalty in xpp and iraf

[Roland Stigge]

Hi,

since the respective maintainers don't seem to have acted upon this, I
will address this here.

Policy states:
=
10.1. Binaries
--
 Two different packages must not install programs with different
 functionality but with the same filenames.  (The case of two programs
 having the same functionality but different implementations is handled
 via "alternatives" or the "Conflicts" mechanism.  See Section 3.10,
 `Maintainer Scripts' and Section 7.3, `Conflicting binary packages -
 `Conflicts'' respectively.) If this case happens, one of the programs
 must be renamed.  The maintainers should report this to the
 `debian-devel' mailing list and try to find a consensus about which
 program will have to be renamed.  If a consensus cannot be reached,
 _both_ programs must be renamed.
=

Since xpp-xpp seems to be a more common user tool, I propose renaming
iraf-xpp to /usr/bin/iraf-xpp (if it's possible to consider all the
places where it's possibly called) or /usr/lib/iraf/xpp (if it's just an
iraf-internally used tool).

Note that it doesn't seem to be enough if the two packages conflict on
each other.

Please add further suggestions for the maintainers to consider.

Thanks.

bye,
  Roland


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

Re: Bug reports missing

[Anthony Towns]

On Wed, Dec 10, 2003 at 08:30:49AM +0100, Andreas Tille wrote:
> I just sendet
>   mailx -s "Merge" [EMAIL PROTECTED] <<...
>   merge 219863 223355

] Debian Bug report logs - #219863
] Bug is archived. No further changes may be made.

>   close 223355

You also can't merge an open bug and a closed bug even when it's not
archived.

> and got the answer mentioned below.  In fact my research showed that #219863
> does not exist in the BTS.  

What research? It certainly shows up in http://bugs.debian.org/219863 .

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

   Linux.conf.au 2004 -- Because we can.
   http://conf.linux.org.au/ -- Jan 12-17, 2004


pgpi6c4V8wJEI.pgp
Description: PGP signature

Re: Initrd rocks! (was Re: Backporting 2.4.23 kernel packages)

[Herbert Xu]

Brian May <[EMAIL PROTECTED]> wrote:
> 
> IIRC, There is a parameter to mdadm (--scan?) that could be used for
> this, but when I asked the initrd maintainer I was given a good reason
> why it was not used (sorry; I can't remember what this was now; it might
> simply be that the mdadm code is unreliable, inefficient, or buggy).

The reason is that we need hotplug support or something similar
before RAID autodetection will make sense.

If you don't have the underlying devices there RAID autodetection
will not work.
-- 
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

Bug#223536: ITP: xfce4-session -- XFce4 Session Manager

[Oliver M. Bolzer]

Package: wnpp
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


* Package name: xfce4-session
  Version : 0.1.3+20030922-1 
  Upstream Author : Benedikt Meurer <[EMAIL PROTECTED]> 
* Upstream: [EMAIL PROTECTED]:/cvsroot/xfce/xfce4/xfce4-session 
* License : BSD without (3) 
  Description : XFce4 Session Manager

  xfce4-session is a X11-compliant "session manager" designed for use
  with the XFce4 Desktop Environment. On log out, the session manager  
  saves  the state of all your running applications. When you log
  back in, the session manager restores the same applications with
  the same window positions.


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

iD8DBQE/1vIAh4aHre9Q0f8RAkYpAJ43sPgoex4Q11Z6m6MwNr+DEbF+cwCfeOGD
/dKgLejVSnNap04NQFudbeY=
=nRk+
-END PGP SIGNATURE-

Re: APT-Fu 0.2.3

[Herbert Xu]

Miles Bader <[EMAIL PROTECTED]> wrote:
> 
> FWIW, the `fu' in kung-fu means something like style or technique, so
> apt-fu sort of makes sense if you think of as a tool for doing cool
> things using the power of apt... :-)

I'm afraid that although the character `fu' has many meanings, but
style or technique isn't one of them.

Here are the rough translations of the various meanings of `fu' in my
dictionary:

a1) Opposite of a woman, that is, a man.
a2) An adult man.
a3) A farming method in the Zhou dynasty (1000BC-221BC).

b1) Pronoun in the second person.
b2) Demonstrative prnoun, as in `this' or `these'.
b3) Mortal man, as opposed to the supernatural.
b4) Denotes exclamation at the end of a sentence.
b5) Denotes interrogation at the end of a sentence.
b6) Used in the beginning of a sentence, has no meaning.
b7) Used in the middle of a sentence, has no meaning.

The word kung-fu originally refers to the time consumed by performing
tasks.  The present-day meaning comes from the fact that martial art
usually requires years/decades of training, which is a lot of kung-fu.

In this sense the character has no meaning.  Although kung-fu has
also been used to refer to man-hours where `fu' presumably refers to
man, but the only usage I know is from the Three Kingdoms period
(~200AD) and it is probably not related to the present-day meaning.

Therefore, `fu' has no meaning at all in kung-fu.  So it is entirely
appropriate to construct the word `apt-fu'.
-- 
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: [Firebird-devel] Orphaning Firebird RDBMS

[marius popa]

Grzegorz B. Prokopski wrote:
Hi!
I haven't (seriously) used Firebird since a year and there's no chance
I'll be using anytime soon. It's low maintenance software though as
upstream is focused on firebird 1.5/2.0
Therefore I am going to orhpan:
* firebird
* php4-interbase (depending on firebird)
Drop me note if you want to take them over. Else - I'll orphan them
formally soon.
Cheers,
Grzegorz B. Prokopski
Description: FireBird - RDBMS based on InterBase 6.0 code
 The "classic" flavour uses new process to handle every connection.
 This results in somewhat slower operation (but it is said it is faster
 on local connections than "super"), but also can operate on many
 processors on SMP machines. This is the "traditional" flavour.
 The "super" flavour uses separate thread to handle every connection.
 It is has it's adventages (for ex. is usually faster), but also some
 disadventages (is unable to use more than one CPU on SMP systems,
 under some circumstances clients can crash all server).
 Firebird is a relational database offering many ANSI SQL-92 features
 that runs on Linux, Windows, and a variety of Unix platforms. Firebird
 offers excellent concurrency, high performance, and powerful language
 support for stored procedures and triggers. It has been used in
 production systems, under a variety of names since 1981.
 Firebird is a commercially independent project of C and C++
 programmers, technical advisors and supporters developing and enhancing
 a multi-platform relational database management system based on the
 source code released by Inprise Corp (now known as Borland Software
 Corp) under the InterBase Public License v.1.0 on 25 July, 2000.
What involves the role of an debian package maintenance ? (more details)
Maybe this anouncement should be added on the firbird/ibphoenix web site 
too...

Re: APT-Fu 0.2.3

[George Danchev]

On Wednesday 10 December 2003 12:48, Herbert Xu wrote:
> Miles Bader <[EMAIL PROTECTED]> wrote:
> > FWIW, the `fu' in kung-fu means something like style or technique, so
> > apt-fu sort of makes sense if you think of as a tool for doing cool
> > things using the power of apt... :-)
>
> I'm afraid that although the character `fu' has many meanings, but
> style or technique isn't one of them.

OK, agreed. After reading the apt-fu(1) completely I found the explanation 
from the author. Under the "NOMENCLATURE" section it reads:
...
Initially, this project started out with the name 'apttoo', obviously 
influenced by the name of well-known source-distribution for Linux. Then it 
was renamed to 'aptor', but I didn't like that name, either.

Finally, I settled on 'apt-fu', giving naysayers a chance to call it, 
'apt-futility' or apt-<4letterword>.

APT-Fu is the name of this project, but command-line applications are usually 
written entirely in lowercase for easy of typing, so 'apt-fu' is the name of 
the executable script.

optFiles is short for ``options files''.
...

In fact I was pleased to find that performings of apt-fu and opt files are 
very well documented in man pages, README and examples/ ... Really doesn't 
look like a fast hack (which I was suspecting for a while)

-- 
pub  4096R/0E4BD0AB 2003-03-18 
1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 

Re: Bug reports missing

[Hamish Moffatt]

On Wed, Dec 10, 2003 at 08:30:49AM +0100, Andreas Tille wrote:
>   mailx -s "Merge" [EMAIL PROTECTED] <<...
>   merge 219863 223355
>   close 223355
>   thanks
> 
> and got the answer mentioned below.  

It's your punishment for using the close command. DON'T!
There is no need and no excuse.

thanks,
Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Revocation list for old packages with security holes (was: Re: Revival of the signed debs discussion)

[Julian Mehnle]

Joey Hess <[EMAIL PROTECTED]> wrote:
> Goswin von Brederlow wrote:
> > What can we do with deb signatures?
> >
> > For our current problem, the integrity of the debian archive being
> > questioned, the procedure would be easy and available to every user:
> >
> > 1. get any clean Debian keyring (or just the key signing the keyring)
> > 2. verify the latest Debian keyring
> > 3. verify that each deb was signed by a DD and the signature fits
>
> The canoical attack against signed debs in this situation is to find a
> signed deb on snapshot.debian.net that contains a known security hole.
> Now inject it into the compromised archive, with a changed filename, and
> edit the Packages file to have its md5sum. Now a user's checks will
> succeed -- the package is signed with a developer's key -- but they will
> install the old, insecure .deb. The only hint will be a warning from
> dpkg that it is downgrading the package, and a clever attacker might
> avoid even that.

We could use a revocation list where signatures of packages with known security 
holes are listed as being revoked.  Of course, you'd
need to be online to check it when installing/updating packages.  And the 
revocation list would best be served from a server that's
secure and separate from the archive servers to make attacks against it a bit 
more difficult.

> I would still like to be able to produce signed debs, it's another layer
> of security, but they are no panacea.

True.

Re: Bug reports missing

[Andreas Tille]

On Wed, 10 Dec 2003, Anthony Towns wrote:

> What research? It certainly shows up in http://bugs.debian.org/219863 .
Not when I tried it some hours ago.  I can't reproduce this, sorry.

Moreover I wonder why it is missing from

   
http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=pkg&data=tipptrainer&archive=yes

but this might be a different effect.

Kind regards

   Andreas.

Re: Revocation list for old packages with security holes (was: Re: Revival of the signed debs discussion)

[Goswin von Brederlow]

"Julian Mehnle" <[EMAIL PROTECTED]> writes:

> Joey Hess <[EMAIL PROTECTED]> wrote:
> > Goswin von Brederlow wrote:
> > > What can we do with deb signatures?
> > >
> > > For our current problem, the integrity of the debian archive being
> > > questioned, the procedure would be easy and available to every user:
> > >
> > > 1. get any clean Debian keyring (or just the key signing the keyring)
> > > 2. verify the latest Debian keyring
> > > 3. verify that each deb was signed by a DD and the signature fits
> >
> > The canoical attack against signed debs in this situation is to find a
> > signed deb on snapshot.debian.net that contains a known security hole.
> > Now inject it into the compromised archive, with a changed filename, and
> > edit the Packages file to have its md5sum. Now a user's checks will

Packages contain the control file which has all the informations about
the package. Also apt will not successfully install a deb package with
a changed name.

Signed debs prevent any tampering with the package post signing.
Changing the name or version of the file and in Packages leads to
confusion now and can be easily deteced, if one can trust the control
file within the deb (i.e. if its signed).


The only attack left is compromising a mirror and keeping a newer
(fixed) version out so people will still install an old buggy
version. Ensuring the Release.gpg file is resigned frequently would
allow users to detect when its held back by a compromise. But since
every done something is uploaded Release.gpg will be signed daily
already. Its not 100% reliable but a Release.gpg older then 3 days
would be very suspicious.

> > succeed -- the package is signed with a developer's key -- but they will
> > install the old, insecure .deb. The only hint will be a warning from
> > dpkg that it is downgrading the package, and a clever attacker might
> > avoid even that.

How do you avoid that? You can use a package with a higher version and
rename it but then apt won't work even without checking the control file.

> We could use a revocation list where signatures of packages with
> known security holes are listed as being revoked.  Of course, you'd
> need to be online to check it when installing/updating packages.
> And the revocation list would best be served from a server that's
> secure and separate from the archive servers to make attacks against
> it a bit more difficult.

And how do you make sure the revokation list isn't compromised (kept
in the state it was a few days ago)? Its the same problem as with the
Packages/Release.gpg files.

> > I would still like to be able to produce signed debs, it's another layer
> > of security, but they are no panacea.
> 
> True.

Signed debs basically add nothing except ease of use and
transparency.  All the security that would be contained in a signed
deb is already contained in the changes and Release.gpg. But checking
those changes files is complicated. A signature in the deb would be
equally secure (and equaly insecure) but just so much easier for the
user.

That the one (two) big argument for signed debs: ease of use and
transparency.

MfG
Goswin

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

[Andrew Suffield]

On Wed, Dec 10, 2003 at 11:47:28AM +0800, Cameron Patrick wrote:
> On Tue, Dec 09, 2003 at 09:49:25PM +, Andrew Suffield wrote:
> 
> | Alternate approaches (that involve significantly less work)
> 
> That's the bit that I (and presumably others) am not convinced about.
> You keep making this assertion, but with little to back it up.  Have
> you, e.g., looked at the Categories definitions for .desktop files?  I
> don't believe that mapping them onto the section field of our menu
> system (and vice versa) without losing any information would be trivial.

We don't have to map them onto anything. We just have to pass them
through to the menu methods in a fashion that allows them to generate
.desktop files.

We *may* be able to do more interesting things with them, but we don't
*need* to.

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


signature.asc
Description: Digital signature

Re: Revocation list for old packages with security holes (was: Re: Revival of the signed debs discussion)

[Andreas Barth]

* Julian Mehnle ([EMAIL PROTECTED]) [031210 13:40]:
> Joey Hess <[EMAIL PROTECTED]> wrote:
> > Goswin von Brederlow wrote:
> > > What can we do with deb signatures?
> > >
> > > For our current problem, the integrity of the debian archive being
> > > questioned, the procedure would be easy and available to every user:
> > >
> > > 1. get any clean Debian keyring (or just the key signing the keyring)
> > > 2. verify the latest Debian keyring
> > > 3. verify that each deb was signed by a DD and the signature fits
> >
> > The canoical attack against signed debs in this situation is to find a
> > signed deb on snapshot.debian.net that contains a known security hole.
> > Now inject it into the compromised archive, with a changed filename, and
> > edit the Packages file to have its md5sum. Now a user's checks will
> > succeed -- the package is signed with a developer's key -- but they will
> > install the old, insecure .deb. The only hint will be a warning from
> > dpkg that it is downgrading the package, and a clever attacker might
> > avoid even that.

> We could use a revocation list where signatures of packages with known 
> security holes are listed as being revoked.  Of course, you'd
> need to be online to check it when installing/updating packages.  And the 
> revocation list would best be served from a server that's
> secure and separate from the archive servers to make attacks against it a bit 
> more difficult.

Yes, that would also be a good enhancement.

However, verifying the actual control files of a package again the
information in Packages is also worth doing.


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: Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries

[Andrew Suffield]

On Tue, Dec 09, 2003 at 05:18:21PM -0600, Billy Biggs wrote:
> Andrew Suffield ([EMAIL PROTECTED]):
> 
> > On Tue, Dec 09, 2003 at 09:49:54AM -0600, Billy Biggs wrote:
> > > Andrew Suffield ([EMAIL PROTECTED]):
> > > 
> > > > It's "pass a few more text fields through to the menu methods, and
> > > > use them to generate .desktop files" versus "rewrite everything".
> > > 
> > > You sure it's "rewrite everything"?  A script to parse all .desktop
> > > files in /usr/share/applications and output the same as
> > > 'update-menus
> > 
> > Straw man, again. The proposal was to rewrite all menu entries as
> > .desktop files - yeah, I'm sure that means rewriting them all.
> 
>   Agreed on that, but it's not rewriting all of the menu package, which
> is what I felt your post implied.

Did you miss the context I quoted? You've since deleted it; let's
bring it back:

>...> You do realize that the desktop standard has more features than the
>...> debian menu system? Like i18n, icon theming, dynamic construction of a
>...> menu hierarchy based on user /Desktop system preferences and so on? And
>...> that this information would be lost? Why not run it the other way around,
>...> convert the existing debian menu entries to .desktop files and work from
>...> there? I think that this way would help debian on the desktops.

[Ignoring most of the drivel, the second to last sentence is the
relevant one; the rest of the mail I was replying to followed on from
that]

> Rewriting all menu files is fairly
> trivial and does not have to be done all at once.

"Fairly trivial"? I have over a hundred affected packages installed on
this box alone.

And... you do have to rewrite the menu package as well, obviously:

> > > A script to parse all .desktop
> > > files in /usr/share/applications and output the same as
> > > 'update-menus

That's most of the interesting content of the menu package (plus
documentation etc). It's not really a very complicated package.

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


signature.asc
Description: Digital signature

re: debian pxe dhcp netinstall (debconf enterprise fai etc.)

[Thomas Lange]

on ... <[EMAIL PROTECTED]> wrote:

> First i tried "fai", but while i liked the concept of
> classes it was to much of a hassle and the number of scripts and
> dependencies was to much to understand in 4 hours (after which i gave up). 
Did you try the simple example DEMO in FAI? Did you read chapter 4.8 "For the 
impatient user"?
I think one should get FAI work in 4 hours. But even if this time was
not enough, you could  additionaly have spend the time you needed for
writing your installation scripts.

> name. It seemed to me that its development had cheased. But the death knell 
> to fai was that it is currently not supporting "debconf". With the fallback 
> or override
But you can extend fai (using hooks) to use debconf and debwrap
(debwrap was new to me - looks pretty nice) as you do in your
scripts. This should take only a few minutes to write such a hook.

> The whole process is "nearly working". Some things are missing such as
> that nis does not add +::: to the corresponding files and such packages
AFAIK, NIS does not need this line any more. Use the file nsswitch.conf instead.


> ... or debconf asking for manual input. Especially debconf with its
> initial dialog when first installed was annoying
Never seen this with FAI.

 
> I would like to have some feedback, especially on the topic of
> doing automatic updates with an cron job. I would also like to hear of
> some hints if there is an other tool which does the job (debix,
Some guys are using FAI not only for the initial installation, but
also for updates and daily maintenance. They are using FAI's new command fcopy
for this.

> script files. I think the whole automatic management thing (which is
> also the reason behind the whole "enterprise" discussion) has a lot of
> potential. Having the ability to reconfigure large clusters or
You're right. Automating system administration and configuration
management is a hot topic these days. Do you know these references?

Automating Unix and Linux Administration by Kirk Bauer 

Bootstrapping an Infrastructure (1998)  Steve Traugott, Joel Huddleston
Proceedings of the Twelth Systems Administration Conference (LISA XII) (USENIX 
Association: Berkeley, CA)


I think you should spend some more time to look a FAI. Most of the
things you need for an automatied installation are already implemented
and working for a lot of users for their clusters, labs and
desktops. Also two of the top500 cluster where build using FAI.
If you need debconf or debwrap support, it's eaesy to extend FAI to
support it. But then you have also the nice class system.

I also have problems, when people are trying to write some code from
scratch. Often they only spend a few weeks or month in coding, then
this project will fall asleep and all their good work is lost. Second,
do not underestimate the time you will need to get a lot of users that
will test your software. Without other users, your software will not
become better, because you can't find all the bugs yourself. To
summarize, I invite you to join the FAI mailling list and help improve
FAI, so it will also meet your needs.

-- 
best regards Thomas Lange (author of FAI)
http://www.informatik.uni-koeln.de/fai/

RE: Revocation list for old packages with security holes

[Julian Mehnle]

Goswin von Brederlow wrote:
> "Julian Mehnle" <[EMAIL PROTECTED]> writes:
> > We could use a revocation list where signatures of packages with
> > known security holes are listed as being revoked.  Of course, you'd
> > need to be online to check it when installing/updating packages.
> > And the revocation list would best be served from a server that's
> > secure and separate from the archive servers to make attacks against
> > it a bit more difficult.
> 
> And how do you make sure the revokation list isn't compromised (kept
> in the state it was a few days ago)? Its the same problem as with the
> Packages/Release.gpg files. 

The revocation list would need to be signed with a special private key that is 
stored on a non-networked machine.  It's not too often that signatures of old 
packages need to be revoked.  Probably mostly just whenever the security team 
releases a security-fixed package (of course also on some other occasions).

Of course, such a package revocation list brings all the problems that other 
types of revocation lists, e.g. SSL certificate revocation lists, have.  But as 
proven by VeriSign & Co., these problems can be successfully mastered.

> That the one (two) big argument for signed debs: ease of use and
> transparency. 

Not exactly.  Also, individual signed debs could be downloaded[1] and verified 
*individually*.  No need for Packages/Release.gpg files.

[1] E.g. from http://wiki.debian.net/?DebianKDE or 
http://people.debian.org/~$developer/

Re: Revocation list for old packages with security holes

[Goswin von Brederlow]

"Julian Mehnle" <[EMAIL PROTECTED]> writes:

> Goswin von Brederlow wrote:
> > "Julian Mehnle" <[EMAIL PROTECTED]> writes:
> > > We could use a revocation list where signatures of packages with
> > > known security holes are listed as being revoked.  Of course, you'd
> > > need to be online to check it when installing/updating packages.
> > > And the revocation list would best be served from a server that's
> > > secure and separate from the archive servers to make attacks against
> > > it a bit more difficult.
> > 
> > And how do you make sure the revokation list isn't compromised (kept
> > in the state it was a few days ago)? Its the same problem as with the
> > Packages/Release.gpg files. 
> 
> The revocation list would need to be signed with a special private
> key that is stored on a non-networked machine.  It's not too often
> that signatures of old packages need to be revoked.  Probably mostly
> just whenever the security team releases a security-fixed package
> (of course also on some other occasions).

You completly missed the point.

Say something gets revoced, added to the list and the list is signed
and all. But still this stupid transparent proxy of my stupid ISP will
give last month list and I will never know something got revoked.
The same could happen intentionally by an attacker.

> Of course, such a package revocation list brings all the problems
> that other types of revocation lists, e.g. SSL certificate
> revocation lists, have.  But as proven by VeriSign & Co., these
> problems can be successfully mastered.
> 
> > That the one (two) big argument for signed debs: ease of use and
> > transparency. 
> 
> Not exactly.  Also, individual signed debs could be downloaded[1]
> and verified *individually*.  No need for Packages/Release.gpg
> files.

Yes, you don't need archive the Release.gpg or changes files from the
time the package was released: "ease of use". You can even verify
debian.snapshot.net.

MfG
Goswin

Re: Bug reports missing

[Colin Watson]

On Wed, Dec 10, 2003 at 01:19:57PM +0100, Andreas Tille wrote:
> On Wed, 10 Dec 2003, Anthony Towns wrote:
> > What research? It certainly shows up in http://bugs.debian.org/219863 .
> 
> Not when I tried it some hours ago.  I can't reproduce this, sorry.
> 
> Moreover I wonder why it is missing from
> 
>
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=pkg&data=tipptrainer&archive=yes
> 
> but this might be a different effect.

Hmm, how odd. (Yes, it's a different effect - index.archive was
truncated for some reason, ENOSPC at a guess.) Fixed, thanks.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Building a distribution from source?

[Peter Busser]

Hello!

> On Sat, 6 Dec 2003 04:37, Jakob Lell <[EMAIL PROTECTED]> wrote:
> > maybe Adamantix is what you are wanting to do. It is based on Debian woody
> Adamantix in now what we want to do, what we want to do is to improve Debian.

``We''? Who is ``we''? It is unlikely that you are one of them royal people, so
I take it you meant to say:

Adamantix is not what I want to do, what I want to do is to improve Debian.

Fair enough. But if I were to improve Debian, I would put PaX in the default
kernel source.

> > create installation CDs yourselve. For more information about Adamantix,
> > see http://trusteddebian.org/
> That URL is obsolete.

Right, it is obsolete. Please use http://www.adamantix.org/ instead. Not that
it makes any difference, because you end up with the same web page in front
of you.

> They can not use the "trusted Debian" name any more.  

``They''? Who is ``they''? Does ``they'' include Debian developers who actively
contribute to Adamantix or not? You don't make any sense here Russell, let me
rephrase it again:

Peter can not use the "trusted Debian" name any more.  

Oh yes I can. Martin Michlmayr and I have an agreement that I (you may read
``we'' here if you want) can use the trusteddebian.org domain for the web site
and for e-mail (although not for advertising it). That is why you see a big
Adamantix logo when you select www.trusteddebian.org.

IMHO it was a big win for the project to be renamed from Trusted Debian to
Adamantix.

> In fact the domain should probably be de-registered to avoid confusion.

If anyone appears to be confused here, it seems to be you (again).

Groetjes,
Peter Busser

Re: APT-Fu 0.2.3

[Eric Wong]

Herbert Xu <[EMAIL PROTECTED]> wrote:
> Miles Bader <[EMAIL PROTECTED]> wrote:
> > 
> > FWIW, the `fu' in kung-fu means something like style or technique, so
> > apt-fu sort of makes sense if you think of as a tool for doing cool
> > things using the power of apt... :-)
> 
> I'm afraid that although the character `fu' has many meanings, but
> style or technique isn't one of them.
> 
> Here are the rough translations of the various meanings of `fu' in my
> dictionary:
> 
> a1) Opposite of a woman, that is, a man.
> a2) An adult man.
> a3) A farming method in the Zhou dynasty (1000BC-221BC).
> 
> b1) Pronoun in the second person.
> b2) Demonstrative prnoun, as in `this' or `these'.
> b3) Mortal man, as opposed to the supernatural.
> b4) Denotes exclamation at the end of a sentence.
> b5) Denotes interrogation at the end of a sentence.
> b6) Used in the beginning of a sentence, has no meaning.
> b7) Used in the middle of a sentence, has no meaning.
> 
> The word kung-fu originally refers to the time consumed by performing
> tasks.  The present-day meaning comes from the fact that martial art
> usually requires years/decades of training, which is a lot of kung-fu.
> 
> In this sense the character has no meaning.  Although kung-fu has
> also been used to refer to man-hours where `fu' presumably refers to
> man, but the only usage I know is from the Three Kingdoms period
> (~200AD) and it is probably not related to the present-day meaning.
> 
> Therefore, `fu' has no meaning at all in kung-fu.  So it is entirely
> appropriate to construct the word `apt-fu'.

Very cool explanation.  I've always used 'kung-fu' and 'kung'
(pronounced 'gung' in Cantonese)  to refer to both the time consumed to
do work and various martial art forms; yet I never realized that I've
never used or heard the word 'fu' used alone.  With that, apt-fu did
take a lot of kung-fu to produce :)

-- 
Eric Wong[EMAIL PROTECTED]
Petta Technology, Inc  [EMAIL PROTECTED]

ITA: animals -- Traditional AI animal guessing engine using a binary tree DB

[Jim Lynch]

Subject says it all.

-Jim

-- 
Jam sessions community web site: http://jam.sessionsnet.org

Infinite http redirect loop from people.d.o

[Jamin W. Collins]

Not sure if this is still part of the ongoing recovery or something
else, but people.d.o is producing an infinite redirect loop for any
personal page request.

$ telnet people.debian.org 80
Trying 192.25.206.10...
Connected to gluck.debian.org.
Escape character is '^]'.
GET http://people.debian.org/~jcollins/


302 Found

Found
The document has moved http://people.debian.org/~jcollins/";>here.

Apache/1.3.26 Server at gluck.debian.org Port 80


-- 
Jamin W. Collins

Remember, root always has a loaded gun.  Don't run around with it unless
you absolutely need it. -- Vineet Kumar

Use opie on Debian central servers to prevent password sniffing?

[Tim Freeman]

At
http://lists.debian.org/debian-announce/debian-announce-2003/msg3.html
it says the Debian machines were compromised by password sniffing from
other compromised machines.  If you use one time passwords instead,
then password sniffing doesn't yield useful information.

As you probably know, the packages for that are opie-server and
libpam-opie on the server, and opie-client on the client.  You'd also
have to edit /etc/pam.d/{login,ssh} to mention libpam-opie, at least.
Finding and installing a skey calculator on a personal organizer is
probably better than using opie-client on a machine that's connected
to the internet and therefore conceivably compromised.

I just started using opie on fungible.com, and it seems to work well
so far.

Is there some issue with opie that would cause problems when using it
on the Debian servers?

-- 
Tim Freeman  [EMAIL PROTECTED]
I xeroxed a mirror. Now I have an extra xerox machine.   -- Steven Wright

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

[Bruce Sass]

On Tue, 9 Dec 2003, Henning Makholm wrote:
> Scripsit Bruce Sass <[EMAIL PROTECTED]>
> > On Tue, 9 Dec 2003, Moritz Moeller-Herrmann wrote:
>
> > > In which format shall application packages store
> > > their menu information.
>
> > It doesn't matter,
>
> If you don't think the problem being discussed matters, why are you
> participating in the discussion?

The "problem" is real, the format used to convey the data is
immaterial.

> > the question should be, "what requires more work: adding features to
> > the existing menu system, or changing the entire menu system."
>
> Is there a difference? The changes being contemplated consist in
> adding features, and any addition of features constitute a change.

Yes. relatively small change vs. rewriting almost from scratch


> > > Users and developers propose following the
> > > freedesktop standard and using this.
>
> > Users and developers are also resisting the proposal.
>
> With few or no actual arguments about what would go bad.

The pain is not worth the gain... why should all the menu consumers
need to redo their menu handling so two of them can have a slightly
easier time of it.


> > > How is this logical? How does the freedesktop standard not "gain" us
> > > features?
>
> > Because nobody but KDE and Gnome use those features and they
> > already support .desktop files.
>
> Yes, but that does not buy KDE and Gnome users anything unless the
> .desktop files are in the .debs for the applications they use. We're
> discussions how to allow the .debs to contain them without duplication
> of information and needless redundancy.

Ok.  How about doing it so the vast majority of menu consumers are not
stuck with a needless rewrite.


> > > freedesktop entry features > debian menu file features
>
> > True, but everyone except KDE and Gnome will toss out the freedesktop
> > features.  Processing bloated .desktop files just to toss the
> > results is a waste of resources.
>
> The fraction of Debian users who use KDE and Gnome is probably less
> than 90%, but I don't believe that it is small enough that it makes
> sense to oppose on principle their getting the information they want.

All users should be able to get what they want, including those who
don't want KDE or Gnome... saddling them with bloated .desktop files
does not achieve that.


> > Nobody benefits from the transition... not even KDE or Gnome, since
> > they already support the features the freedesktop standard brings to
> > the table.
>
> Having a .desktop infrastructure is worth nothing if you dont have the
> data it works with. KDE and Gnome users would certainly benefit from
> having .desktop files in the .debs of the packages they use.

Yes, but they would benefit in the same way if the KDE and Gnome
specific bits were an addendum to the main menu data entries.

Only KDE and Gnome users stand to benefit, so they should be the ones
with the added burden.

> > I regularily use KDE, UWM, pdmenu, and Fluxbox, I also have twm, xfce
> > and mwm installed... processing the menues takes too much time and
> > resources as it is, and you want to use up more, for what gain?
>
> Just how much more time and resources would it take to convert
> .desktop files to Debian menu definitions? How often does it have to
> be done?

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 would like to see:
/usr/lib/menu/desktop
/usr/lib/menu/desktop/gnome
/usr/lib/menu/desktop/kde
etc.

desktop/ can contain the generic .desktop data (translations and
features common to all .desktop aware menu consumers), the gnome and
kde dirs would contain the bits specific to them (X-KDE-*, etc.)


- Bruce

Use opie on Debian central servers to prevent password sniffing?

[Tim Freeman]

At
http://lists.debian.org/debian-announce/debian-announce-2003/msg3.html
it says the Debian machines were compromised by password sniffing from
other compromised machines.  If you use one time passwords instead,
then password sniffing doesn't yield useful information and the damage
from this sort of failure would be more limited.

As you probably know, the packages for that are opie-server and
libpam-opie on the server, and opie-client on the client.  You'd also
have to edit /etc/pam.d/{login,ssh} to mention libpam-opie, at least.
Finding and installing a skey calculator on a personal organizer is
probably better than using opie-client on a machine that's connected
to the internet and therefore conceivably compromised.  To discourage
people from typing into a potentially compromised machine, you certainly
don't want to have opie-client installed on any central server.

I just started using opie on fungible.com, and it seems to work well
so far.

Is there some issue with opie that would cause problems when using it
on the Debian servers?

-- 
Tim Freeman  [EMAIL PROTECTED]
I xeroxed a mirror. Now I have an extra xerox machine.   -- Steven Wright

Re: Use opie on Debian central servers to prevent password sniffing?

[Philippe Troin]

Tim Freeman <[EMAIL PROTECTED]> writes:

> At
> http://lists.debian.org/debian-announce/debian-announce-2003/msg3.html
> it says the Debian machines were compromised by password sniffing from
> other compromised machines.  If you use one time passwords instead,
> then password sniffing doesn't yield useful information and the damage
> from this sort of failure would be more limited.
> 
> As you probably know, the packages for that are opie-server and
> libpam-opie on the server, and opie-client on the client.  You'd also
> have to edit /etc/pam.d/{login,ssh} to mention libpam-opie, at least.
> Finding and installing a skey calculator on a personal organizer is
> probably better than using opie-client on a machine that's connected
> to the internet and therefore conceivably compromised.  To discourage
> people from typing into a potentially compromised machine, you certainly
> don't want to have opie-client installed on any central server.
> 
> I just started using opie on fungible.com, and it seems to work well
> so far.
> 
> Is there some issue with opie that would cause problems when using it
> on the Debian servers?

I haven't look at OPIE for ages, but when using it with ssh, doesn't
it force you to turn privilege separation off in /etc/ssh/sshd_config?

Maybe the ssh people fixed this issue since.

Phil.

Re: Building a distribution from source?

[Steve Kemp]

On Wed, Dec 10, 2003 at 07:44:55PM +0100, Peter Busser wrote:

> ``We''? Who is ``we''? It is unlikely that you are one of them royal people, 
> so
> I take it you meant to say:
> 
> Adamantix is not what I want to do, what I want to do is to improve Debian.

  That is correct, I agree with Russell.  What _I_ want to do is improve
 Debian.  if for a while I have to go it alone and demonstrate mycode
 and pacakges work then so be it, but the ultimate aim is to improve
 Debian.

> Fair enough. But if I were to improve Debian, I would put PaX in the default
> kernel source.

  PaX is interesting, ProPolice is more interesting.

> > > create installation CDs yourselve. For more information about Adamantix,
> > > see http://trusteddebian.org/
> > That URL is obsolete.

  Yes.

> Right, it is obsolete. Please use http://www.adamantix.org/ instead. Not that
> it makes any difference, because you end up with the same web page in front
> of you.

  But you loose the association with Debian "proper".

> > In fact the domain should probably be de-registered to avoid confusion.
> 
> If anyone appears to be confused here, it seems to be you (again).

  Fight amongst yourself if you wish.  Adamantix are clear that they
 are seprate from Debian as I believe they are.   Anything else is
 pointless bickering and semantics.

Steve
--

Re: Initrd and software raid [was: Initrd rocks!]

[Eduard Bloch]

#include 
* Florent Rougon [Wed, Dec 10 2003, 09:48:55AM]:

> Note: this starts the root array only; the other arrays are started by a
>   "mdadm -A -s" from /etc/init.d/mdadm-raid.
> 
> > IIRC, There is a parameter to mdadm (--scan?) that could be used for
> > this, but when I asked the initrd maintainer I was given a good reason
> > why it was not used (sorry; I can't remember what this was now; it might
> > simply be that the mdadm code is unreliable, inefficient, or buggy).
> 
> I think this is unlikely, since (-s = --scan) is what is used in the
> Debian aforementioned init script for mdadm (/etc/init.d/mdadm-raid).

That is simply wrong. The mdadm-raid init script uses the mdrun script
which was written IIRC because of following reasons:

 --scan was not reliable under certain circumstance (don't remember the
   details)
 --scan output needed to be stored somewhere which did not work if / got
   corrupted and cannot be mounted readonly or on initrd before tmpfs or
   such are available

So something was needed to emulate the exact behaviour of the kernel
autodetection using a userspace tool, mdrun was born.

Herbert did not accept mdrun for initrd-tools but choosed a "manual"
mode where all used device files are detected and noted in initrd
scripts, then recreated in tmpfs at boot time, using mdadm on them.

MfG,
Eduard.
-- 
Freude beruht auf dem frohen Glauben, daß das Gute überwiegt.

Re: Use opie on Debian central servers to prevent password sniffing?

[Jeremy T. Bouse]

As I recall you are correct on this, atleast with Stable and
testing... I have had OPIE setup for awhile on machines that only have
admin accounts and no general user accounts and I recall having to turn
off privilege separation on them to get it to work with the
challenge-response system. If this has changed I haven't seen anything
on it myself and would appreciate a pointer.

Regards,
Jeremy

On Wed, Dec 10, 2003 at 01:02:39PM -0800, Philippe Troin wrote:
> I haven't look at OPIE for ages, but when using it with ssh, doesn't
> it force you to turn privilege separation off in /etc/ssh/sshd_config?
> 
> Maybe the ssh people fixed this issue since.
> 
> Phil.
> 


signature.asc
Description: Digital signature

Re: Use opie on Debian central servers to prevent password sniffing?

[Tim Freeman]

From: Philippe Troin <[EMAIL PROTECTED]>
>I haven't look at OPIE for ages, but when using it with ssh, doesn't
>it force you to turn privilege separation off in /etc/ssh/sshd_config?

Yes, using opie and pam and sshd all at once requires turning off
privilege separation for sshd.

Opie protects against a local root exploit anywhere on the machine
causing a bunch of cascading compromises.

Sshd privilege separation protects against an exploit in openssh
allowing remote compromise of a bunch of machines.

I don't know which risk is bigger.

Hey, maybe using exec-shield would decrease the chances of the openssh
bugs being exploitable?  That would also make other local root
exploits harder.  But maybe that has already been done.

-- 
Tim Freeman  [EMAIL PROTECTED]
I xeroxed a mirror. Now I have an extra xerox machine.   -- Steven Wright

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

[Henning Makholm]

Scripsit Bruce Sass <[EMAIL PROTECTED]>
> On Tue, 9 Dec 2003, Henning Makholm wrote:
> > Scripsit Bruce Sass <[EMAIL PROTECTED]>
> > > On Tue, 9 Dec 2003, Moritz Moeller-Herrmann wrote:

> > If you don't think the problem being discussed matters, why are you
> > participating in the discussion?

> The "problem" is real, the format used to convey the data is
> immaterial.

The format that should be used is what this thread is about
discussing. If you want to discuss something different, that is fine,
but it will be most practical if you do it in a different thread.

> > > the question should be, "what requires more work: adding features to
> > > the existing menu system, or changing the entire menu system."

> > Is there a difference? The changes being contemplated consist in
> > adding features, and any addition of features constitute a change.

> Yes. relatively small change vs. rewriting almost from scratch

Nobody has proposed "rewriting almost from scratch". Please avoid
strawman arguments; they convince nobody of anything and does nothing
to forward a resultion of the question.

> > > Users and developers are also resisting the proposal.

> > With few or no actual arguments about what would go bad.

> The pain is not worth the gain...

Nobody has put forward any description of which "pain" it is that you
speak.

> why should all the menu consumers need to redo their menu handling

It is not being proposed that they should.

> > Yes, but that does not buy KDE and Gnome users anything unless the
> > .desktop files are in the .debs for the applications they use. We're
> > discussions how to allow the .debs to contain them without duplication
> > of information and needless redundancy.

> Ok.  How about doing it so the vast majority of menu consumers are not
> stuck with a needless rewrite.

They aren't.

> > The fraction of Debian users who use KDE and Gnome is probably less
> > than 90%, but I don't believe that it is small enough that it makes
> > sense to oppose on principle their getting the information they want.

> All users should be able to get what they want, including those who
> don't want KDE or Gnome... saddling them with bloated .desktop files
> does not achieve that.

Have you quantified the "bloat" you are speaking about? Can the same
argument not apply to any i18n effort?

> > Having a .desktop infrastructure is worth nothing if you dont have the
> > data it works with. KDE and Gnome users would certainly benefit from
> > having .desktop files in the .debs of the packages they use.

> Yes, but they would benefit in the same way if the KDE and Gnome
> specific bits were an addendum to the main menu data entries.

At the cost of a more complicated system, which would by nobody anything.

> Only KDE and Gnome users stand to benefit, so they should be the ones
> with the added burden.

Which burden?

> > Just how much more time and resources would it take to convert
> > .desktop files to Debian menu definitions? How often does it have to
> > be done?

> 1 or 2 hundred bytes vs. a couple to few thousand bytes _per_entry_;

I think we can spare that much memory while generating the menus.

> I would like to see:
> /usr/lib/menu/desktop
> /usr/lib/menu/desktop/gnome
> /usr/lib/menu/desktop/kde

But for some reason you're wildly opposed to the idea that .debs can
contain files that populate these directories. Why?

-- 
Henning Makholm   "Larry wants to replicate all the time ... ah, no,
   all I meant was that he likes to have a bang everywhere."

Re: recovery status update

[Thomas Viehmann]

Aaron M. Ucko wrote:
> Clint Adams <[EMAIL PROTECTED]> writes:
> 
> 
>>- how to run madison and wanna-build
> 
> 
> I thought the idea was for the unrestricted mirror to include a
> read-only copy of the database madison consults.
> 
> wanna-build presumably needs more real-time access, though.

Maybe those tools could trigger updating of the mirror before they are
actually executed.
(Just a random thought, probably completely useless, but I might just be
lucky.)

Cheers

T.



pgpWbipYxsrHj.pgp
Description: PGP signature

Re: recovery status update

[Wouter Verhelst]

On Tue, Dec 09, 2003 at 10:14:08PM -0500, Aaron M. Ucko wrote:
> Clint Adams <[EMAIL PROTECTED]> writes:
> 
> > - how to run madison and wanna-build
> 
> I thought the idea was for the unrestricted mirror to include a
> read-only copy of the database madison consults.
> 
> wanna-build presumably needs more real-time access, though.

Not really. Wanna-build keeps its own bdb database, based on the output
of quinn-diff. Provided the wanna-build box has (semi-)realtime access
to the Packages- and Sources-files on auric (a requirement because of
the way security updates are handled), it could technically run
anywhere.

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


signature.asc
Description: Digital signature

Re: Building a distribution from source?

[Thomas Viehmann]

Peter Busser wrote:
> Fair enough. But if I were to improve Debian, I would put PaX in the default
> kernel source.

If you were to improve Debian, you'd have spent the five minutes it
takes to realize that the only two very ways of getting PaX in the
default debian kernel source is to get PaX included upstream or to prove
it's value by creating a popular and well tested patch.

If you're not prepared to do things the Debian way, then you're not
about to do things in or for Debian.

I'd be interested to buy Microsoft, but I don't have the change today,
the same way you're displaying interest in Debian.

You're doing your own project because there you can do as you please,
but you won't do anything for Debian by reiterating that Debian should
do as you please as well.
Others prefer to see what they can do to improve Debian by choosing ways
to change stuff that actually work.
Is understanding the difference really that hard?

Regards

T.


pgpEkONpncA1B.pgp
Description: PGP signature

奇猫牌 KR-A&B 型电子驱鼠器

[广州庆瑞]

广州庆瑞电子科技有限公司

敬启者：

本电子邮件是商务宣传资料，如对您产生任何不良的影响，我表示深深的歉意，请即返回告知

并将此邮件删除，我将不再打扰。

　

如果您或您的朋友对驱鼠有任何需求，我们将竭诚为您服务，所列产品完全是本公司开发生产的，

具有自主知识产权。产品在广州各大供电局的电房得到广泛的使用，对电房内的电器设备起到很好

的保护作用,同时广泛用于制药，皮革和仓库等行业。

如有垂询，不胜感激。

颂致商祺！

　

　

广州庆瑞电子科技有限公司

市场部经理

俞先生

电话：020-85562199   33010208 传真：020-85560935

欢迎访问公司网站：  http://kingray.nease.net

　

奇猫牌 KR-A&B 型电子驱鼠器

  

奇猫牌 KR-A&B 
型电子驱鼠器是广州庆瑞电子科技有限公司自行开发的高科技产品，该产品采用当今最新的超声波技术，通过先进的电子电路产生周期性的超声波，攻击老鼠的听觉和神经系统，迫使老鼠逃离现场。

  

原理：应用超声波技术驱鼠由来已久，但对老鼠逐渐习惯其固定超声波而失效的缺陷，本公司深入研究老鼠的生态和习性，开发设计出多重扫描变频超声波（Multiplex
 Modulated Sweeping Ultrasonic 
Sounds）,直接密集地强烈刺激和攻击老鼠的知觉神经和脑中枢神经系统，使其十分痛苦，恐惧和不舒服，食欲不振，全身痉孪，繁殖能力降低，无法在此环境下生存而逃离该超声波放射区域。

  

特点：

1．  使用特殊IC回路震荡和高分贝转换器，寿命长，耗电量低，适合长时间使用。

2．  老鼠最怕的是变频扫描（Sweeping Modulation）复合超声波。

3．  
不含化学原料及危险装置，仅干扰老鼠的神经系统而不会对人体和宠物产生不良影响，无公害，无副作用，安全可靠。

4．  体积小，易安装，免维修，操作简单。

5．  
立体空间的驱鼠效果能达到纵，横面任何方向，与一般捕鼠器，药物杀鼠等定点驱鼠法完全不同。

6．  
此产品超声波20~65KHz不在人类，狗，猫，鸟的听觉范围内，也不会干扰电视，收音机，电脑和其他电子仪器，如助听器，车库房遥控器等。

7．  可变换放射器的角度。

  

   

  

型号：KR-A&B   频率：10~65KHz音压：140db 在40KHz  耗电：<2W

有效范围：50~100平方米

尺寸：KR-A:  130x180x120KR-B:  125x129x80 (mm)

  

　

地址：广州中山大道89号   电话：020-85562199  
33010208 联系人：俞先生

欢迎访问公司网站：  http://kingray.nease.net

　


　

　

Re: Building a distribution from source?

[Russell Coker]

On Thu, 11 Dec 2003 09:05, Steve Kemp <[EMAIL PROTECTED]> wrote:
>   That is correct, I agree with Russell.  What _I_ want to do is improve
>  Debian.  if for a while I have to go it alone and demonstrate mycode
>  and pacakges work then so be it, but the ultimate aim is to improve
>  Debian.

This is why I am very interested in what you are doing.

Let me know when you have an apt repository that's in a usable state and I'll 
recommend it on my SE Linux web pages.  I expect that anyone who is 
interested in SE Linux will be interested in your work as well.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

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

[Bruce Sass]

On Wed, 10 Dec 2003, Henning Makholm wrote:
> Have you quantified the "bloat" you are speaking about? Can the same
> argument not apply to any i18n effort?

Yes, using KDE2.  The script removed any lines with "[""]" in
them from KDE files (was possible at the time without incurring
breakage) and would typically result in about 5M of disk usage being
reduced to a couple hundred K.  KDE was also faster processing and
accessing its menues, although I did not quantify that aspect (not as
easy to do and the difference was obvious enough that I didn't feel
the need to hack KDE to put a number to it).

Yes, the same argument applies to all i18n efforts.

I18n is great, until disk usage and processing times start to climb
with no real benefit to individual users.


> > Yes, but they would benefit in the same way if the KDE and Gnome
> > specific bits were an addendum to the main menu data entries.
>
> At the cost of a more complicated system, which would by nobody anything.

I would hardly call avoiding forcing everyone except KDE and Gnome the
need to deal with menu data files which are 10x to 20x the size they
need to be `not buying nobody anything'.


> > > Just how much more time and resources would it take to convert
> > > .desktop files to Debian menu definitions? How often does it have to
> > > be done?
>
> > 1 or 2 hundred bytes vs. a couple to few thousand bytes _per_entry_;
>
> I think we can spare that much memory while generating the menus.

memory, disk space, and processing time

Maybe you can spare it, I can't, and I suspect those trying to run a
light weight system either can't or don't want to.


> > I would like to see:
> > /usr/lib/menu/desktop
> > /usr/lib/menu/desktop/gnome
> > /usr/lib/menu/desktop/kde
>
> But for some reason you're wildly opposed to the idea that .debs can
> contain files that populate these directories. Why?

Huh, I think you need to do some re-reading.


- Bruce

Re: Minneapolis, MN USA BSP + Keysigning

[Scott Dier]

Just reminding everyone of the BSP.

Remember to RSVP if your coming, thanks!  If you have RSVP'ed, thanks!

And, for the record, you post your phone number online and *within days*
some friggin creditor is looking for you to pay some bill for some other
"Scott Dier".  Actually, it was some guy's Mom looking for him to pay
rent on something she cosigned, but wow!  I need to do this more often!
:)

* Scott Dier <[EMAIL PROTECTED]> [031119 00:03]:
> Important directions correction below:
> 
> * Scott Dier <[EMAIL PROTECTED]> [031119 00:01]:
> >   One way to get here from there:
> >   Take Hwy 10 to Foley Blvd., go south.
> >   Take a right at 99th Ave NW
> >   Take a right at Woodcrest
> >   At Foley continue straight, the road becomes Quince at this
>^  Should read Egret, not Foley
> >   point.  Be careful of the transformer box to the left at this
> >   two-way stop, it can sometimes hide cars.
> >   Take a right at the 2nd street (its an access road)
> >   Find a parking spot in guest parking, if none are avaliable,
> >   park in the driveway to unload and then we will find some
> >   parking for you.
> -- 
> Scott Dier <[EMAIL PROTECTED]> KC0OBS http://www.ringworld.org/
> Free USA from energy dependence, http://www.apolloalliance.org/



-- 
Scott Dier <[EMAIL PROTECTED]> KC0OBS http://www.ringworld.org/
Free USA from energy dependence, http://www.apolloalliance.org/

Re: APT-Fu 0.2.3

[Miles Bader]

Herbert Xu <[EMAIL PROTECTED]> writes:
> I'm afraid that although the character `fu' has many meanings, but
> style or technique isn't one of them.

Hmmm, you seem to be right, I was confused. :-(

I don't have a chinese dictionary, but my Japanese dictionary lists a
japanese version of kung-fu `kanfu-', which uses a kanji meaning `merit'
(kou) and the [common] `fu' meaning `husband':

  功夫

I guess that makes sense, if you interpret it as meaning something like
`Hard work is the partner of success' -- which sort of works with `apt'
too (partner of apt?).

[Having looked this stuff up, now I can see why I was confused, BTW --
_another_ japanese version of kung-fu is `kenpou'[1], in which the
second kanji can mean `method', and I was muddling this in my head with
the japanese `fuu'[2] which can mean `method' as well as `style', etc.]

Abashedly,

-Miles

[1] 拳法
[2] 風
-- 
Yo mama's so fat when she gets on an elevator it HAS to go down.

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

[Cameron Patrick]

On Wed, Dec 10, 2003 at 07:36:15PM -0700, Bruce Sass wrote:

| > Have you quantified the "bloat" you are speaking about? Can the same
| > argument not apply to any i18n effort?
| 
| Yes, using KDE2.
[...]
| Yes, the same argument applies to all i18n efforts.
| 
| I18n is great, until disk usage and processing times start to climb
| with no real benefit to individual users.

I seem to recall reading a number of complaints /from users/ in the BTS,
requesting .desktop files precisely because they are i18nalised.  Others
have suggested expanding the current Debian menu definition to handle
i18n.  That, to me, sounds like there must be some kind of benefit to
individual users to have translated menu items.

| I would hardly call avoiding forcing everyone except KDE and Gnome the
| need to deal with menu data files which are 10x to 20x the size they
| need to be `not buying nobody anything'.

I suspect that those who would rather see menu entries in their native
language - and whose native language is not English - would consider the
larger menu data files necessary to handle i18n to be a real advantage.

Cameron.

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

[Miles Bader]

Cameron Patrick <[EMAIL PROTECTED]> writes:
> I seem to recall reading a number of complaints /from users/ in the BTS,
> requesting .desktop files precisely because they are i18nalised.  Others
> have suggested expanding the current Debian menu definition to handle
> i18n.  That, to me, sounds like there must be some kind of benefit to
> individual users to have translated menu items.

Of course, but it's also clear that for many, _many_ people, having
hebrew translations for everything is simply bloat.

I'd think that ideally, there could be some system-wide setting that
specified which languages to support (e.g. `english, french, korean'),
and upon installation, i18nalised files would be filtered to strip out
any `unsupported' languages.  I suppose the default should probably be
to keep all languages.

-Miles
-- 
97% of everything is grunge

Re: Backporting 2.4.23 kernel packages

[Matthew Grant]

Simple.

Just take the kernel-source-2.4.34.tar.bz2 tar ball out of the sid
system and recompile using make-kpkg under woody, using the apporiate
config file



On Fri, 2003-12-05 at 18:41, Andrew Pollock wrote:
> Where I'm working, we have Debian stable deployed on a number of boxes. For
> hardware support reasons, we've had to grab newer kernels from testing, and
> have been reasonably successful at not dragging in half of testing with
> them.
> 
> We're going to want to upgrade everything to 2.4.23 ASAP, but I'd prefer not
> to drag in half of unstable with this upgrade.
> 
> So, I was wondering how to go about taking the source package for 2.4.23-686
> (and the SMP version) and backport them to stable?
> 
> Is it as simple as taking the source package and building it in a stable
> pbuilder chroot, or is there more black magic involved with kernel packages?
> 
> Thanks
> 
> Andrew
-- 
===
Matthew Grant/\  ^/\^   [EMAIL PROTECTED]  /\
A Linux Network Guy /~~\^/~~\_/~\___/~~\/**\
===GPG KeyID: 2EE20270  FingerPrint: 8C2535E1A11DF3EA5EA19125BA4E790E2EE20270==




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

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

[Dagfinn Ilmari MannsÃker]

Miles Bader <[EMAIL PROTECTED]> writes:

> I'd think that ideally, there could be some system-wide setting that
> specified which languages to support (e.g. `english, french, korean'),
> and upon installation, i18nalised files would be filtered to strip out
> any `unsupported' languages.  I suppose the default should probably be
> to keep all languages.

localepurge - Automagically removing unnecessary locale data

-- 
ilmari

Re: APT-Fu 0.2.3

[David Palmer.]

On Thu, 2003-12-11 at 10:54, Miles Bader wrote:
> Herbert Xu <[EMAIL PROTECTED]> writes:
> > I'm afraid that although the character `fu' has many meanings, but
> > style or technique isn't one of them.
> 
> Hmmm, you seem to be right, I was confused. :-(
> 
> I don't have a chinese dictionary, but my Japanese dictionary lists a
> japanese version of kung-fu `kanfu-', which uses a kanji meaning `merit'
> (kou) and the [common] `fu' meaning `husband':
> 
My old sifu told me that kung-fu meant 'work done', and/or 'goals
achieved.'

On another note, with reference to an earlier post, it was my
understanding that the alternative 'gung' was from the northern
mandarin, and not the southern cantonese.
Regards,

David.