Re: debsums for maintainer scripts

[Manoj Srivastava]

On Fri, 05 Dec 2003 13:34:10 -0500, Anthony DeRobertis <[EMAIL PROTECTED]> 
said: 

> On Thu, 2003-12-04 at 11:11, Manoj Srivastava wrote:
>> That is but one optimization: we already are suffering from archive
>> bloat, what about the disk and bandwidth cost of carrying around
>> the sigs?  And since one rarely needs the md5sums anyway, what is
>> so wrong with checking against the .deb when needed?

> I just took an md5sum of every file on my system. Including things
> like /var and /home that aren't part of packages. It's 13M,
> uncompressed.  Compressed, it's 3.5M.

> If we were really worried about archive size, an md5sum is 16
> octets.  It's hard to see that mattering to overall archive size.

I am (probably) getting a Zaurus for christmas this year. I
 would like to run Debian on it.  You think that the PDA has gobs of
 disk space to throw around?

>> > Its also a warm feeling to run debsums to see the broken memory
>> > chip one just replaced with a working one has not caused any
>> > bit-changes in the installed files. If the checksums were created
>> > at the same system, one has to get them from somewhere else, so
>> > there is little sense in having them generated at all.
>>
>> A warm fuzzy feeling, however, is to be distrusted when dealing
>> with security and/or system integrity checking.

> Have you ever met any bit changes that defeat md5? Didn't think so.

Have you met any bit changes that defeated checksums
 generated and stored on the same system? Don't think so.

manoj
-- 
No one can feel as helpless as the owner of a sick goldfish.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

出血！做盒子、印刷的来吧！！

[shenghaogz]

ÉîÛÚ½ò¸êֽƷ°ü×°Ó¡Ë¢³§


רס´ÓÊÂÓÚÊýÂëIT²úÆ·µÄ°ü×°ÖÆ×÷£¬ÐÎÏóÉè¼Æ£¬Æ·ÅÆÍƹ㣬¹ÒÀú¡¢Ì¨Àú¡¢Çë¼í¡¢ºØ¿¨¡¢MP3¡¢UÅÌ¡¢Ö÷°å¡¢ÏÔ¿¨¡¢ÊýÂëÏà»ú¡¢ÊÖ»ú¡¢ÉãÏñ
Í·¡¢²»¸É½º¡¢º£±¨¡¢Ðû´«µ¥¡¢µÄÓ¡Ë¢¡¢ÖÆ×÷¡£
MP3¡¢UÅÌ¡¢ÉãÏñÍ·¡¢ÀñÆ·ºÐ¡¢ÖÆ×÷·Ñ2.2ÔªÆ𣡼۸ñ¾ø¶ÔÓŻݣ¬ÉîÛÚÔÙÒ²ÕÒ²»µ½µÚ¶þ¼Ò£¡£¡£¡£¡




»ªÇ¿±±ÎÞÈ˲»Öª£¡ÎÞÈ˲»Ïþ£¡£¡£¡£¡£¡£¡£¡£¡£¡£¡£¡£¡£¡£¡£¡£¡£¡£¡£¡



ÓÅÖÊ·þÎñ£¡ËÍ»õÉÏÃÅ£¡£¡»¶Ó­À´µç×Éѯ£¡£¡£¡£¡




³§Ö·£ºÁú»ªÕòÕÁ¿ÓµÚ¶þ¹¤ÒµÇø
°ì¹«ÊÒ£ºÂÞºþÇø÷Բ·Ëñ¸Ú´óÏÃ8Â¥817ºÅ
µç»°£º25840783  
´«Õ棺83259235  83259240
ÊÖ»ú£º1375101008513510616563
[EMAIL PROTECTED]

Re: Building a distribution from source?

[Russell Coker]

On Sat, 6 Dec 2003 18:12, Russell Coker <[EMAIL PROTECTED]> wrote:
> 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.

I meant to say "Adamantix is not"...

-- 
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: debsums for maintainer scripts

[Manoj Srivastava]

On Fri, 5 Dec 2003 16:50:19 +0100, Javier Fernández-Sanguino Peña <[EMAIL 
PROTECTED]> said: 

> Well, there are not really sides here. But again:

> - I want md5sums to be stored in the local filesystem, I don't
>   really care
> if they are inside the debs or not, as long as it's standard
> procedure and nobody has to hack apt.conf, dpkg or what else to have
> this. If we cannot provide a standard configuration for apt that
> regenerates this information then our only bet is md5sum files
> inside the debs.

And I do _NOT_ want to waste the space on my zaurus (I am
 trying to be a good boy, santa) with on disk md5sum files. So by all
 means craft a standard configuration for apt that regenerates this
 information on demand.

> - I want md5sums information provided in a off-site way by ftp sites
>   and
> mirrors so I can compare it against the local database and against
> the files in the disk. Again, this could be generated by extracting
> the whole archive and running md5sum over the archive or (easier) by
> extracting the md5sums files from the .debs and putting them
> together.

I am fine with the former.

manoj

-- 
Fast ship?  You mean you've never heard of the Millennium Falcon? Han
Solo
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: exim4-config and exim4-base installed on systems with non-exim-MTA

[Manoj Srivastava]

On Thu, 04 Dec 2003 22:22:07 +0100, Tore Anderson <[EMAIL PROTECTED]> said: 

> * Marc Haber
>> Splitting up the config file in small files was necessary to do
>> debconf support, which is a Debian requirement.

>   Debconf support is now required?  I'm flabbergasted.  Could you
>  please point me to this section of our policy?  I certainly cannot
>  find it.

Not using debconf to prompt users is now a bug, though not
 (yet) a serious one.
==
3.10.1. Prompting in maintainer scripts
---

 Package maintainer scripts may prompt the user if necessary.
 Prompting should be done by communicating through a program, such as
 `debconf', which conforms to the Debian Configuration management
 specification, version 2 or higher.  Prompting the user by other
 means, such as by hand[1], is now deprecated.
==

So if the package maintainer scripts interact with the user,
 not using debconf is a SHOULD violation.

manoj

-- 
An ounce of clear truth is worth a pound of obfuscation.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: debsums for maintainer scripts

[Manoj Srivastava]

On Thu, 04 Dec 2003 17:36:16 +0100, Thomas Viehmann <[EMAIL PROTECTED]> said: 

> Manoj Srivastava wrote:
>> Before we make such a push, we should at least ensure that it is
>> something we really want to do. I think locally generated checksums
>> are a better solution.
> To me, the main use of md5sums seems to be verifying nothing bad (as
> in accident, not malicious manipulation) happened to the extracted
> files.  md5sums included in the packages do that even earlier than
> those generated.

Earlier than what?  You already can check the integrity of the
 .deb you are installing; don't install corrupted .debs. Now
 admittedly there is a window where files can be corrupted between
 unpacking and creating the checksums, in which case just run the ar
 .. tar -d incantation posted earlier to check the on disk file
 _after_ generating the checksum to make sure that that little window
 is also closed.

manoj
-- 
"All my life I wanted to be someone; I guess I should have been more
specific." Jane Wagner
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

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

[Mathieu Roy]

Marc Wilson <[EMAIL PROTECTED]> said:

> On Fri, Dec 05, 2003 at 12:57:53PM +0100, Mathieu Roy wrote:
>> > Some or all of: twm, pdmenu, blackbox, afterstep, fluxbox, gtk-menu,
>> > wmaker, fvwm2, enlightenment, etc, consult /etc/menu-methods for more.
>> > There are dozens of programs that use the debian menus that would have
>> > no reason to use the .desktop stuff.
>> 
>> Can you name the ones that are still developed in that list?
>
> I couldn't pass this up:
>
> twm - admittedly, bug-fixes only
> pdmenu  - this is a window manager?
> blackbox- alive and under current development
> afterstep   - alive and under current development
> fluxbox - alive and under current development
> gtk-menu- this is a window manager?
> wmaker  - alive and under current development
> fvwm2   - alive and under current development
> e   - well, there are CVS commits, call it what you will
>
> I only see *one* window manager in that list that isn't alive (twm).
> Enlightenment is, of course, debatable, and always has been. ^_^
>
> Not that whether or not a package has a release every ten minutes or every
> ten months has jack to do with whether or not it's useful software.
>
> There are any number of other window managers that couldn't care less about
> .desktop files, yet (a) provide menus, (b) are packaged in Debian.

Sure. However, I use WindowMaker since several years now, and apart
from bug fixes, I did not notice real changes over years (the
changelog does not speak otherwise, it's almost only about bugs and
i18n updates).

About blackbox, , there no news
since September the 2nd... 2002. 

It's maybe a mistake to say that these projects are no longer active
at all, however their activity by comparison to GNOME and KDE is
pretty small.

I'm not criticizing inactivity, there are understandable reasons
behind it.
For instance, on WindowMaker website, it's told that the development
is not going on because the main authors are busy in real life: in
GNOME and KDE case, I think that numerous author works for these
projects in their real professionnal life (am I wrong?), so it is
easier to keep moving.



>> Why do you say that this programs would have no reason to use the
>> .desktop stuff? What reasons would they have to use the Debian Menu
>> instead?
>
> They don't.  That simple data point seems to be missing from the entire
> discussion.  They use their own internal menu formats.
>
> Thus, we have the menu package, which takes *Debian's*
> window-manager-independent menu entries, and creates for each of these
> window managers something that they can digest in their own format.
>
> Saying "Debian should provide .desktop files" is all well and good.
> Perhaps it should even be encouraged.  But there is still a great need for
> what the menu package does.

Ok, it would be indeed interesting that this Debian tool that make
the conversion get compatible with .desktop files. This tool would be
interesting for any distributions that ships these wm also.

For instance, if I correctly understood the story, RedHat stopped
shipping WindowMaker because they do not want to support a window
manager that do not follow the agreements between KDE and GNOME
people, freedesktop.org in fact.


Regards,

-- 
Mathieu Roy

  +-+
  | General Homepage:   http://yeupou.coleumes.org/ |
  | Computing Homepage: http://alberich.coleumes.org/   |
  | Not a native english speaker:   |
  | http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english  |
  +-+

Re: debsums for maintainer scripts

[Manoj Srivastava]

On Thu, 4 Dec 2003 19:30:12 +0100, Javier Fernández-Sanguino Peña <[EMAIL 
PROTECTED]> said: 

> Why do we have to make each of our users find a solution to generate
> this from a _local_ mirror (or the system's .deb archive which
> shoulnd't be trusted in the event of an intrusion) when we could do
> this ourselves and provide the results?

I have no objections to Debian providing md5sums, as  long as
 we do not ignore our users running Debian in low disk space
 environments -- like zaurii. As long as these files are not in a deb,
 and are not mandated to live in /var/lib/dpkg/info; feel free.

> Notice that I'm not necessarily depending on the local md5sums, I'm
> taking a file provided by a vendor, in this case, Debian. Let's call
> it Contents-xxx.md5sum.gz.  This file is available for download from
> all Debian mirrors, signed with the Release key and provides these
> three fields for every file in a single Release:

OK. 

manoj

-- 
panic: kernel trap (ignored)
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: OT: Smartcards and Physical Security

[Manoj Srivastava]

On Fri, 5 Dec 2003 02:45:41 -0800, Tom  <[EMAIL PROTECTED]> said: 

> Let me start by saying I basically understand your last point: it's
> not worth it because it won't work.

> On Fri, Dec 05, 2003 at 04:01:42AM -0600, Manoj Srivastava wrote:
>> who follow secire processes. Blowing 40k collectively is unlikely
>> to buy us much security.

> Like I said, it may be that it would be wasted money.  But you are
> switcing arguments here.  Originally you were bristling at the
> suggestion that you spend your own money.  Now you seem to be okay
> with that, but saying it would be wasteful because you basically
> don't trust smartcards.

I am bristling at the idea of users demanding that volunteers
 are not doing enough, and need to spend money to provide better
 service. I was amused at the idea that you seemed to think that this
 was even remotely workable. I was flabbergasted that someone thought
 that mere gadetry actually brought security. I was heartened to think
 there there are still people on -devel misguided enough to believe
 that the Debian project has such a common hive mind that such a
 proposal would get past the belly laugh stage.

> I don't trust them either, but they are a layer.  Of course, they
> may be an absolutely useless layer, but they may not.  I think this
> is your true objection (to smartcards at all) and not to the
> suggestion of having your spend your own money to improve the
> project.  And that's an acceptable belief (although it *may* not be
> correct).  But if you want to explore other, free ways to improve
> Debian's security process (such as auditing one another's machines
> or some other way I can't think of), that's a good thing.  The point
> is: a failure occured.  Don't let it happen again.

Drop the imperatives, and we shall get along a lot better.
 Better still, roll up your sleeves and make it happen, and
 you'll earn my respect, and my support.

>>
>> >> Let me see if I can point out the logical flaws in words with
>> >> few syllables.
>>
>> Take a bath? take a _bath_? What are we, back in grade school now?

> You're not seriously talking about taking pot shots are you?  Tit
> for tat.  But I withdraw the remark, I was thinking of the
> traditional image of the long-stringy-haired Unix hacker such as
> RMS.  I was picturing RMS
> -- I didn't mean anything else. :-)

I was merely dumbfounded at the _quality_ of pot shots you
 were taking.  I am used to, umm, well, more, uggh. /mature/ pot shots
 being taken at people on this list. I have not heard that expression
 since the playing fields of my primary school.

manoj
-- 
People who take cold baths never have rheumatism, but they have cold
baths.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Building Debian Completely From Source

[cobaco]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2003-12-05 21:02, Matt Zimmerman wrote:
> On Fri, Dec 05, 2003 at 01:53:11PM -0600, John Goerzen wrote:
> > The nearest I have seen is fink, but I know little about it.
> >
> > Am I missing something?
>
> apt-src, apparently.

take a look at apt-build
- -- 
Cheers, cobaco
  
1. Encrypted mail preferred (GPG KeyID: 0x86624ABB)
2. Plain-text mail recommended since I move html and double
format mails to a low priority folder (they're mainly spam)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/0TX35ihPJ4ZiSrsRAvWyAKCLELx3sDEfz5PE9h/Hwi5gmKLeLgCfQe8w
QcWHWn5RdtuggmcAr8abk2w=
=5ZJg
-END PGP SIGNATURE-

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

[Manoj Srivastava]

On Fri, 5 Dec 2003 11:09:56 -0600, Chad Walstrom <[EMAIL PROTECTED]> said: 

> On Fri, Dec 05, 2003 at 04:08:41AM -0600, Manoj Srivastava wrote:
>> > ... It only stands to reason that if both the KDE and Gnome
>> > desktop camps wish to formalize on the format that we should
>> > adopt it as well, if only as an extension of our menu system.  We
>> > would have to generate .desktop files anyway, when Gnome and KDE
>> > move form their own native menu formats.
>>
>> You talk as if the whole universe of window managers is merely
>> gnome and kde.

> I understand how you might get that, but you have to admit that they
> are the most visible of the desktop environments.  I didn't mention
> window managers specifically because I don't see the need to make
> the distinction in this case.  The .desktop files has the same goal
> and focus as a .menu file -- providing a convenient interface to
> finding and launching applications, so let's keep that the focus of
> the discussion.

Part of the focus of this discussion is about the obstacles we
 have facing a transition to .desktop entries. And this is one of them
 -- until there exists a mechanism to convert .desktop entries into
 things that the back-end WM's can grok, we are stymied (since we have
 a system that works, however imperfectly, and dropping support for
 these window mangers would be a regression).

The other part is, of course, teaching developers how to write
 the .desktop menu item, and I for one, have never seen one.

manoj
-- 
I hope the ``Eurythmics'' practice birth control ...
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: The term "Custom Debian Distribution" (Was Re: [custom] The term "flavor" and encouraging work on Debian)

[cobaco]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2003-12-05 16:36, Ben Armstrong wrote:
> On Fri, Dec 05, 2003 at 03:20:45AM -0600, cobaco <[EMAIL PROTECTED]> wrote:
> > _ideally_ there are no changes. In practice there will be.
>
> Why?

because it takes time to change things in Debian, example:
  as far as I'm aware everyone involved with CDD's agrees that low priority
  debconf questions combined with debconf-preseeding are the way to go
  regarding CDD-specific configuration of packages on installation. However 
  at the moment this is simply not completely possible

  -> while we're working to change it so that this is possible a temporary
  solution is necessary (otherwise we can't provide an out-of-the-box
  solution that works for our target group). As this should be a
 temporary workaround there's nobody trying to get it into Debian
 (instead we're trying to change things so debconf-preseeding can take
  care of all our needs)

  -> if you don't allow temporary solutions while low priority debconf
  question get included, than there currently are no CDD's as
  custom configuration is necessary to support a CDD's target group
  out-of-the-box.

> I'm sorry, but I really have a hard time with this.  A Custom Debian
> Distribution is nothing more than what is provided within Debian proper,
> as Andreas said.  While a Debian subproject may consider and make use of
> stuff in development that is outside of Debian while transitioning it to
> be "pure Debian", the formal definition of CDD cannot include materials
> outside of Debian main, otherwise it is not Debian, and cannot contain the
> name "Debian" in its title.  

IMHO as long as both a and b below apply it can be called a CDD.

 a) doesn't cause problems when mixed with standard Debian packages (i.e. 
pointing your sources.list to the Debian mirrors should just work without 
problems)
 b) "its use"/"its being outside of Debian" is temporary awaiting changes or 
additions to Debian (which can take quite awhile to filter through if, like 
Skolelinux, the CDD uses stable as a base)

>Skolelinux, as you say, is a perfect example
> of this.  Skolelinux is not a CDD.  It is a project in transition to
> becoming a CDD.  
(obviously) I disagree here IMHO Skolelinux is a CDD in transition to 
becoming a debian-subset.

>As I understand it, Skolelinux is not entirely there yet,
> for the reasons you have already mentioned.  It 's has its own history and
> its own needs which are for the moment unresolvable within Debian. 

with the exception of ltsp which isn't _yet_ in Debian, all non-debian 
software in Skolelinux has to do with configuration. these packages either
- will be included into Debian at some point (e.g the ltsp packages)
- will be/are superseeded by newer Debian packages (e.g. user-sme wich
  provides the sami keyboard for Xfree86, this is already present in
  the newer Xfree86 packages)
- should become unnecessary because of improvents to Debian (e.g
  debian-edu-config which uses cfengine to do custom configuration
 while this can't be done by debconf-preseeding, and which changes
 other packages' configuration files, and thus wouldn't be accepted
 into Debian)
 
> Furthermore, it does not contain 'Debian' in its title, so there is no
> confusion.  This is clearly a Debian-derivative, not a CDD.

it doesn't have Debian in the name -> it's a Debian-derivative

i.e having Debian in the name is a prerequisite for a CDD!?! 
Surely you're joking?

> Now, I'm not saying that Debian derivatives shouldn't exist.  It is
> important to acknowledge that they do, but at the same time work towards
> eliminating, as much as possible, the need for their existence outside of
> Debian main.  

agreed

>Not all reasons for being a derivative (or "Debian-based
> distribution") can be eliminated (such as the inclusion of non-free or
> contrib software).  However, I believe the reasons for Skolelinux not
> being a CDD can and will eventually be resolved.

IMHO there are 2 main differences between a CDD and a Debian-derivative:
1. a CDD aims to improve Debian so that Debian will at some point include 
everything needed to support the target-group and needs of the CDD (at which 
point it will become a Debian-subset). A Debian-derivative on the other hand 
doesn't have this inclusion into Debian as an objective.
2. the software provided by a CDD can be mixed freely with standard Debian 
package without causing problems. Whereas a Debian-derivative doesn't 
(necessarily) ensure this.

Skolelinux conforms to both 1. and 2. above -> is a CDD (in my opinion)
Lindows (for instance) does not comply to 1. and 2. above -> is a 
Debian-derivative.

- -- 
Cheers, cobaco
  
1. Encrypted mail preferred (GPG KeyID: 0x86624ABB)
2. Plain-text mail recommended since I move html and double
format mails to a low priority folder (they're mainly spam)
-BEGIN PGP SIGNATURE-

Re: Backporting 2.4.23 kernel packages

[Russell Coker]

On Sat, 6 Dec 2003 08:35, Andrew Pollock <[EMAIL PROTECTED]> wrote:
> On Fri, Dec 05, 2003 at 11:08:53PM +1100, Russell Coker wrote:
> > > I presume I can lower the dependencies on things like modutils and
> > > whatnot down to the versions that are in stable with no ill-effects?
> >
> > It only depends on coreutils|fileutils, so there's no problems in that
> > regard.
>
> What about modutils and initrd-tools?

What is needed for initrd-tools?  I've given up on using initrd's for kernels 
I compile.

As for modutils, that's probably a bug in kernel-package that it doesn't list 
dependencies.

Add the following to your /etc/apt/sources.list file to get Brian's back-ports 
of modutils and all other things:
deb http://www.microcomaustralia.com.au/debian/ stable main

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

[Manoj Srivastava]

On Fri, 5 Dec 2003 16:48:28 -0500, Joey Hess <[EMAIL PROTECTED]> said: 
 [I whole heartedly agree with Joey here. I am just adding a few
 remarks] 

> No, you're going about this backwards. Get the code written. Get the
> policy for Debian menu layout using .desktop files written. Make
> sure that there's a plan for how the transition will work. Only then
> does it make sense to begin asking maintainers to switch to .desktop
> files.

You do not need the policy to be a formal policy either -- get
 a few like minded people to participate, and the policy can evolve
 with the code as you work out the bugs.  A working set of packages
 using the code and policies, even if in a test environment, goes a
 long way convince people of the feasibility.

> Because until you have code and a policy, you cannot test the menu
> items you are adding, and you do not know they will fit within the
> policies we will eventually devise for layout, wording, icons,
> whatever, for .desktop menu entries. And because in the meantime it
> leads to bloat, and to poor UI.

> By going about this backwards, you only double the amount of work
> that maintainers who add .desktop files will eventually have to do,
> and you do nothing to advance your goal of widespread use of
> .desktop files in Debian. If you would write some code, come up with
> a clear and workable transition plan, and go through regular
> channels to get it into policy, you would find that most developers
> would move to the new system with only a little nudging. As it is,
> you're setting yourself up for a fight every step of the way, and
> it's painful to watch.

In the past, policies have been developed and matured  outside
 the staid old debian technical policy, and thus unfettered by the
 procedural constraints of the policy process until they had been
 field tested, and had critical mass to get formally approved rapidly. 

manoj
-- 
There are more things in heaven and earth than any place else.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: exim4-config and exim4-base installed on systems with non-exim-MTA

[Andreas Barth]

* Anthony Towns (aj@azure.humbug.org.au) [031206 08:10]:
> On Fri, Dec 05, 2003 at 05:46:30PM +0100, Marc Haber wrote:
> > On Thu, 4 Dec 2003 13:43:39 +1000, Anthony Towns
> >  wrote:
> > >The one that gets installed later, Pre-Deps the one that gets installed
> > >earlier. exim4-daemon Pre-Depends: exim4-config; exim4-config Depends:
> > >exim4-base, probably.
> > Unfortunately, that doesn't work. 

> Err, of course it doesn't. What a stupid idea.
> 
> Seriously, I think you need to reconsider having the configuration in
> a separate package.
> 
> What're you trying to achieve exactly?

Allowing for different configuration mechanismn. And I (as a user of
exim4) like that very much.


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: Backporting 2.4.23 kernel packages

[Andrew Pollock]

On Sat, Dec 06, 2003 at 05:11:50PM +1100, Russell Coker wrote:
> On Sat, 6 Dec 2003 08:35, Andrew Pollock <[EMAIL PROTECTED]> wrote:
> > On Fri, Dec 05, 2003 at 11:08:53PM +1100, Russell Coker wrote:
> > > > I presume I can lower the dependencies on things like modutils and
> > > > whatnot down to the versions that are in stable with no ill-effects?
> > >
> > > It only depends on coreutils|fileutils, so there's no problems in that
> > > regard.
> >
> > What about modutils and initrd-tools?
> 
> What is needed for initrd-tools?  I've given up on using initrd's for kernels 
> I compile.

Ah, there's the catch. I don't (usually). I'd like to take the source of a
kernel-image-2.4.23 package and do whatever's necessary to get it to install
on a woody system without having to drag in half of sarge/sid to satisfy
dependencies. This is where I was going with my initial posting. Sorry if
this wasn't clear. 

At present, for say 2.4.22, I've taken the kernel-image-2.4.22-3-686 package
from sarge, along with whatever dependencies required, and installed on it
woody. Problem is, more often than not, modutils or initrd-tools has a libc6
dependency, and well, everything goes downhill from there...
 
> As for modutils, that's probably a bug in kernel-package that it doesn't list 
> dependencies.
> 
> Add the following to your /etc/apt/sources.list file to get Brian's 
> back-ports 
> of modutils and all other things:
> deb http://www.microcomaustralia.com.au/debian/ stable main

Thanks.

Andrew

Re: Building a distribution from source?

[Russell Coker]

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.

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

That URL is obsolete.  They can not use the "trusted Debian" name any more.  
In fact the domain should probably be de-registered to avoid confusion.

-- 
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: exim4-config and exim4-base installed on systems with non-exim-MTA

[Anthony Towns]

On Fri, Dec 05, 2003 at 05:46:30PM +0100, Marc Haber wrote:
> On Thu, 4 Dec 2003 13:43:39 +1000, Anthony Towns
>  wrote:
> >The one that gets installed later, Pre-Deps the one that gets installed
> >earlier. exim4-daemon Pre-Depends: exim4-config; exim4-config Depends:
> >exim4-base, probably.
> Unfortunately, that doesn't work. 

Err, of course it doesn't. What a stupid idea.

Seriously, I think you need to reconsider having the configuration in
a separate package.

What're you trying to achieve exactly?

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


pgpjYiLWA9cu0.pgp
Description: PGP signature

Re: The term "Custom Debian Distribution" (Was Re: [custom] The term "flavor" and encouraging work on Debian)

[cobaco]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2003-12-05 13:01, Andreas Tille wrote:
> On Fri, 5 Dec 2003, cobaco wrote:
> > On 2003-12-05 11:16, Andreas Tille wrote:
> > > their fine work.  I really love what they do and SkoleLinux is one of
> > > the most impressive derivatives of Debian, but it just does not (yet)
> > > fall under our definition.]
> >
> > huh ?! How do you figure that?
>
> Please read again my last two mails and assume that I know what SkoleLinux
> is.

I wasn't making that assumption (sorry if it seemed I was), I was pointing 
out some of the details of Skolelinux (which I did assume you aren't 
completely familiar with), in the hope of pinpointing the exact point on 
which we disagree (as I obviously do think of Skolelinux as a CDD).

So given those details what makes you say Skolelinux isn't a CDD? 
(I'm guessing "not everything used in Skolelinux is in Debian"  _yet_)
- -- 
Cheers, cobaco
  
1. Encrypted mail preferred (GPG KeyID: 0x86624ABB)
2. Plain-text mail recommended since I move html and double
format mails to a low priority folder (they're mainly spam)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/0O6U5ihPJ4ZiSrsRAuZOAJ92sLAWZoPUXzONb+xylPhryi8pSgCgjC/G
akaUiZZr+przqw08Eqrjeo0=
=lWSe
-END PGP SIGNATURE-

Re: uploading problems and massive email floods

[Ryan Murray]

On Fri, Dec 05, 2003 at 10:52:19AM -0800, Ben Pfaff wrote:

> autoconf_2.58-9_i386.changes has bad PGP/GnuPG signature!
> Removing autoconf_2.58-9_i386.changes, but keeping its associated files for 
> now.
> 
> Greetings,
> 
>   Your Debian queue daemon

This problem should be fixed.

> After that, I've received over 134 copies of the following
> message:

And in future, you should only get 1 copy of this message.

-- 
Ryan Murray, Debian Developer ([EMAIL PROTECTED], [EMAIL PROTECTED])
The opinions expressed here are my own.


pgpThnBbD61v2.pgp
Description: PGP signature

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

[Cameron Patrick]

On Sat, Dec 06, 2003 at 10:05:57AM +0100, Mathieu Roy wrote:

| Sure. However, I use WindowMaker since several years now, and apart
| from bug fixes, I did not notice real changes over years (the
| changelog does not speak otherwise, it's almost only about bugs and
| i18n updates).
| 
| About blackbox, , there no news
| since September the 2nd... 2002. 
| 
| It's maybe a mistake to say that these projects are no longer active
| at all, however their activity by comparison to GNOME and KDE is
| pretty small.

What's your point?  The window managers don't /need/ to be changed - or
at least they shouldn't.  They don't natively support Debian's menu
system, they don't natively support .desktop files, and are unlikely to
ever do either.  The current Debian menu system, despite its faults,
supports writing menus for weird formats that an arbitrary window
manager (or other menuing system) might be able to read.  If .desktops
are ever to achieve prominence in Debian, we need to be able to do the
same with those.

(Personally, I feel that extending the current menu system such that it
is both backwards-compatible with what we have not and supports
everything in the freedesktop.org standard is not as trivial as Andrew
has suggested it is in another thread - but if it was accomplished, we
wouldn't have to worry about window managers not supporting .desktop
files as their configuration would be generated just as they are now
using existing menu-methods.)

| For instance, if I correctly understood the story, RedHat stopped
| shipping WindowMaker because they do not want to support a window
| manager that do not follow the agreements between KDE and GNOME
| people, freedesktop.org in fact.

There is no reason for Debian to do something merely because Red Hat
does.  Trying to make Debian compliant with freedesktop's standards by
dropping everything that doesn't support them is a sub-optimal approach,
and is unlikely to be taken seriously by many people.

Cameron.

Re: The term "Custom Debian Distribution" (Was Re: [custom] The term "flavor" and encouraging work on Debian)

[cobaco]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2003-12-05 17:10, Tom wrote:
> On Fri, Dec 05, 2003 at 11:36:20AM -0400, Ben Armstrong wrote:
> > Then that discussion needs to be resolved so that a solution can be made
> > that is in Debian main.
>
> It's useful to try to clarify the terms so people can speak the same
> language, but as soon as you categorize anything somebody's going to
> come out with something which fits in multiple categories.
>
> Anything which isn't just a subset of Debian will ultimately just be a
> distraction,

anything which doesn't _aim_  to be a subset of Debian ...

- -- 
Cheers, cobaco
  
1. Encrypted mail preferred (GPG KeyID: 0x86624ABB)
2. Plain-text mail recommended since I move html and double
format mails to a low priority folder (they're mainly spam)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/0OQo5ihPJ4ZiSrsRAtdMAJ9+pixH8tplwe41HbDLxeWTE1EIeQCeMFTM
w5JRUW5jLQLV75OHWLs8/oI=
=W9jF
-END PGP SIGNATURE-

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

[Mathieu Roy]

Cameron Patrick <[EMAIL PROTECTED]> said:

> On Sat, Dec 06, 2003 at 10:05:57AM +0100, Mathieu Roy wrote:
>
> | Sure. However, I use WindowMaker since several years now, and apart
> | from bug fixes, I did not notice real changes over years (the
> | changelog does not speak otherwise, it's almost only about bugs and
> | i18n updates).
> | 
> | About blackbox, , there no news
> | since September the 2nd... 2002. 
> | 
> | It's maybe a mistake to say that these projects are no longer active
> | at all, however their activity by comparison to GNOME and KDE is
> | pretty small.
>
> What's your point?  The window managers don't /need/ to be changed - or
> at least they shouldn't.  They don't natively support Debian's menu
> system, they don't natively support .desktop files, and are unlikely to
> ever do either.  The current Debian menu system, despite its faults,
> supports writing menus for weird formats that an arbitrary window
> manager (or other menuing system) might be able to read.

I do not understand how can you, in one hand, say there no need for a
standard like .desktop for these window managers (well, this term is 
questionnable - wmaker is, for instance, more than a windowmanager),
and, in another hand, talk about "weird formats" of different window 
manager.

The point of .desktop is to avoid having "weird formats" to handle,
but only one.

If these environment needs the data, or part of the data, that can be
contained in .desktop (currently provided by the debian menu system),
why would it be stupid for them to be able to deal directly with
.desktop?


> If .desktops are ever to achieve prominence in Debian, we need to be
> able to do the same with those.

Sure, as long as some environment will not support .desktop while
needing the data contained in .desktop, Debian will have to use
converters. 


> | For instance, if I correctly understood the story, RedHat stopped
> | shipping WindowMaker because they do not want to support a window
> | manager that do not follow the agreements between KDE and GNOME
> | people, freedesktop.org in fact.
>
> There is no reason for Debian to do something merely because Red Hat
> does.

Why do you assume that I want Debian to follow RedHat choice?


> Trying to make Debian compliant with freedesktop's standards by
> dropping everything that doesn't support them is a sub-optimal
> approach, and is unlikely to be taken seriously by many people.

Nobody proposed that. I do not see the point in arguing about a
non-existant proposal.



-- 
Mathieu Roy

  +-+
  | General Homepage:   http://yeupou.coleumes.org/ |
  | Computing Homepage: http://alberich.coleumes.org/   |
  | Not a native english speaker:   |
  | http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english  |
  +-+

Re: OT: Smartcards and Physical Security

[Tom]

On Sat, Dec 06, 2003 at 01:51:23AM -0600, Manoj Srivastava wrote:
> 
>   Drop the imperatives, and we shall get along a lot better.
>  Better still, roll up your sleeves and make it happen, and
>  you'll earn my respect, and my support.

How about "fuck up again and watch your good thing go away"
(hint I ain't it)

>   I was merely dumbfounded at the _quality_ of pot shots you
>  were taking.

Heh.  I've had to tell people at work to go home and take a fucking 
bath: you stink.  Manoj, your words are powerless.

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

[Cameron Patrick]

On Sat, Dec 06, 2003 at 11:25:31AM +0100, Mathieu Roy wrote:

| > What's your point?  The window managers don't /need/ to be changed - or
| > at least they shouldn't.  They don't natively support Debian's menu
| > system, they don't natively support .desktop files, and are unlikely to
| > ever do either.  The current Debian menu system, despite its faults,
| > supports writing menus for weird formats that an arbitrary window
| > manager (or other menuing system) might be able to read.
| 
| I do not understand how can you, in one hand, say there no need for a
| standard like .desktop for these window managers (well, this term is 
| questionnable - wmaker is, for instance, more than a windowmanager),
| and, in another hand, talk about "weird formats" of different window 
| manager.

The situation /now/ is that /most/ window managers use their own unique
format to handle their menus.  Even the versions of KDE and Gnome
currently in Debian, while both using .desktop files, store them in a
different place and place them into menu hierarchies differently.

A standard like .desktop or the Debian menu system we have now /is/ a
good thing; we also need a way to make those menu hierarchies available
to applications which cannot and will not read them directly (hence the
"weird formats" that I mentioned).  Currently, freedesktop provides the
former but not the latter, so in order for freedesktop's scheme to be
considered as a replacement for what we use now, there must also be a
way to convert them into the format used by some arbitrary menu system.
In practice, a way to convert existing menu entries into the new system,
and ideally also a way to make use of existing menu-methods, would also
be required.

(I'm sorry, I was imprecise earlier: when I said "window managers" I was
actually referring to any piece of software which displays a menu of
applications available on the system.)

| The point of .desktop is to avoid having "weird formats" to handle,
| but only one.

The point is that applications which provide menu entries don't need to
care about about the format that a particular window manager may want
that menu item in.  Currently the Debian menu system provides one such
standard format; another candidate is .desktop files.

| If these environment needs the data, or part of the data, that can be
| contained in .desktop (currently provided by the debian menu system),
| why would it be stupid for them to be able to deal directly with
| .desktop?

Of course not.  But a lot - in fact, the overwhelming majority - of
these environments predate .desktop files, and are unlikely to change.
They don't integrate directly with any menu system but their own.  For
new window managers (or or menu systems), I agree, it makes sense to use
.desktop files for the appropriate menu, as they are more widely
supported outside of Debian.

| > If .desktops are ever to achieve prominence in Debian, we need to be
| > able to do the same with those.
| 
| Sure, as long as some environment will not support .desktop while
| needing the data contained in .desktop, Debian will have to use
| converters. 

I claim once again that this will always - at least for the forseeable
future - be the case.  Converters for the .desktop format don't yet
exist; converters for the current system are in place and working right
now for /every/ menu system in Debian ... with the exception of KDE and
GNOME, where the Debian menu appears to be treated as a second-class
citizen compared to the {GNOME,KDE}-specific menu.  *sigh*

| > There is no reason for Debian to do something merely because Red Hat
| > does.
| 
| Why do you assume that I want Debian to follow RedHat choice?
[...]
| Nobody proposed that. I do not see the point in arguing about a
| non-existant proposal.

In that case, why did you mention what Red Hat were doing?

Cheers,

Cameron.

Re: [custom] Debian Enterprise - a Custom Debian Distribution

[Enrico Zini]

On Wed, Dec 03, 2003 at 10:07:14AM -0500, Fraser Campbell wrote:

> > I've just learnt of Cubit from South Africa: http://www.cubit.co.za/
> Is it free software?  They don't seem to provide a link to the full text of 
> their license, it sounds free according to their license summary but I also 
> see the statement "Cubit has only a very small yearly license fee and no 
> purchase cost".

You're right.  I had another look and it doesn't seem to be free
software.  I don't know them, so I don't know if they can be talked into
freeing it.

Well, there's always Gnu Enterprise, although it's not from Africa:

apt-cache search gnu enterprise


Ciao,

Enrico

--
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: Revival of the signed debs discussion

[Henning Makholm]

Scripsit Goswin von Brederlow <[EMAIL PROTECTED]>

> If a package is compromised we can proof that the DD of the package
> either is malicious or incompetent.

Say, we just had a major compromise on certain Debian machines. Pray
tell, who do you think this proves is malicious or incompetent? We'd
certainly want to toss out the culprit ASAP.

-- 
Henning Makholm "Jeg forstår mig på at anvende sådanne midler på
   folks legemer, at jeg kan varme eller afkøle dem,
som jeg vil, og få dem til at kaste op, hvis det er det,
  jeg vil, eller give afføring og meget andet af den slags."

Re: exim4-config and exim4-base installed on systems with non-exim-MTA

[Tollef Fog Heen]

* Tore Anderson 

| * Marc Haber
| 
|  > The way -config does the configuration is something that is questioned
|  > by a lot of people. Most conservative eximists hate the configuration
|  > being split out in several files,
| 
|   Absolutely, this is a slight convenience for the packagers which causes
|  a major inconvenience to the users.  Well, in my opinion anyway.

It also makes it possible for packages such as clamav, spamassassin
and mailman to seamlessly drop in support in a fairly clean way.

|   The Apache 2 packages does much of the same, sadly.

For the same reason, mostly.  If you want to get a headache some day,
please take a look at apacheconfig (it's part of the apache package)
in woody.  It tries to maintain the httpd.conf file.

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

Re: debsums for maintainer scripts

[Bernhard R. Link]

* Goswin von Brederlow <[EMAIL PROTECTED]> [031206 05:12]:
> > But false negatives cause work. Why do you want to cause false
> > negatives?
> 
> Its not causing it. Its not preventing them anymore than the current
> list.

Huh? I gave multiple examples where the current solution works
correctly, but your suggested solution will give false negatives
unless major work is put into it.

> > I'm still hoping to see you giving a single reason, why the current
> > robust solution, implemented by a vast majority packages, should be
> 
> Because its neither robust, not elegant, nor tamper resistant.

So please give me a simple reson or example why it is not robust.
I cannot think of anything more robust than a static file generated
at build time.

In what respect is it not elegant?

And what tamper is it accessible for, that generating at install time 
is not?

> > replaced by something else. Where this something else needs substantial
> > computing power, will need much work to be usable in all cases and 
> 
> As I explained it only need the extra computing power to calculate a
> signature of the md5sums list of a package. The time taken to compute
> a signature of a few K is neglible compared to the time spend
> computing the md5sums of installed files in the first place.

No, it needs the time to calculate all the md5sums before it can
calculate the signature. And it will need this time with any
installation of a package. (As there is currently to way to do it
later, and making sure there is will not be easy).

> Also this is only required when actually verifying and only for people
> who want to do that. People with proper intrusion detection systems
> don't have to.

This simply does not work. 
dpkg -i a ; dpkg -i a-replacement ; dpkg -P a-replacement
is simply not equivalent to
dpkg -i a

> > is complex enought that it will eventually fail.
> 
> Its just as robust as the current md5sum lists and then failsave on
> top of it. Its not removing any features you can have with the current
> setup but adds security, saves bandwith and space.

How should it add security? If you generate the md5sums at build time
or at install time, it keeps the same.

> > The only thing having any similarity to a reason was the size of those
> > files. But seeing how small they are, I don't think this can be the
> > reason. So what did I miss?
> 
> It is a reason. First you have the smaller and embeded systems that
> can realy do with the files, seeing that they are useless for a
> security audit anyway. Second you have all the mirrors wasting
> precious space and bandwith.

Embeded systems is will need some space reductions with other files 
anyway. (Or such small files will not cause anything).

The space-save for the mirrors by removing the md5sums files should
be equivalent to dropping a single avarage-sized non-free package.
(If it has a longer description, the bandwidth needed to fetch this
 packages Description within Packages.gz each time someone does an
 update should also easily compensate the bandwith of the md5sums
 of all the other files.)

> As an example: The md5sum list of a package is usually bigger or same
> size as its changes file and there is concern about mirror space and
> bandwith if they should be added to the archive.

Almost all packages have already a md5sums file. So there if few
additionally space needed. For the comparison of the size:

# find /var/lib/dpkg/info/ -name "*.md5sums" -exec ./count.sh {} \; 
|./avarage.awk 
3200.3

# find /usr/share/doc -name "changelog.Debian.gz" -exec wc -c {} \; 
|./avarage.awk
5310.36
# find /usr/share/doc -name "changelog.Debian.gz" -exec ./count.sh {} \; | 
./avarage.awk
5333.54

Where count.sh is gzip < $1 | wc -c and having the md5sums file packaged
in a larger .tar.gz might even cause less space.
(All numbers from my woody system, where 989 out of 1158 packages have
 md5sums files).

Hochachtungsvoll,
  Bernhard R. Link

-- 
Sendmail is like emacs: A nice operating system, but missing
an editor and a MTA.

apt-utils compatible debsigs

[Andreas Barth]

Hi,

we had a discussion about signed deb-files. One major drawback was the
incompatibility between apt-utils and debsigs. I updated debsigs to
create a compatible version; this is apt-able at
deb http://debsign.turmzimmer.net/ ./
deb-src http://debsign.turmzimmer.net/ ./
(and of course also sent to the BTS). I also put some more ideas to
that website.


I would like some feedback on this change (and it is admited that the
major drawback of this change is that it is ugly, and should be backed
out one we have a "debian ar"), and on the other contents of this
website.


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: Revival of the signed debs discussion

[Andreas Barth]

* Henning Makholm ([EMAIL PROTECTED]) [031206 13:25]:
> Scripsit Goswin von Brederlow <[EMAIL PROTECTED]>
> > If a package is compromised we can proof that the DD of the package
> > either is malicious or incompetent.
 
> Say, we just had a major compromise on certain Debian machines. Pray
> tell, who do you think this proves is malicious or incompetent? We'd
> certainly want to toss out the culprit ASAP.

IMHO there can also be a third explanation: "Bad luck". But this also
nullifies the trust in any keys on any compromised machine - and the
administrators did replace the keys.

(And, to be honest: Perhaps one should discuss whether the kernel-team
would need some security team, like we have here at Debian. But
speaking what other should do is always very easy, and leads mostly to
nothing than hot air. For this cause, I didn't start and don't want to
say anything more to this topic. If someone with profound security
knowledge would want to help out there, this would be a much better
starting point for any discussion.)


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: The term "Custom Debian Distribution" (Was Re: [custom] The term "flavor" and encouraging work on Debian)

[Benj. Mako Hill]

On Fri, Dec 05, 2003 at 09:00:05PM +0100, cobaco wrote:
>   -> if you don't allow temporary solutions while low priority debconf
>   question get included, than there currently are no CDD's as
>   custom configuration is necessary to support a CDD's target group
>   out-of-the-box.

This isn't totally true. Some CDDs are happy just working on a group
of packages that weren't around before and allowing for a task,
metapackage, or something similar. Low priority debconf questions are
way of solving a "we want something other than the default
*configuration* for a given set of packages" problem. This seems like
a thing that many, but not necessary all, CDDs will want to do.

Regards,
Mako

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



pgpdZoawPJc7V.pgp
Description: PGP signature

Re: Bits from the RM

[Martin Pitt]

Hi aj, hi all others,

On 2003-12-01 14:45 +1000, Anthony Towns wrote:
> Another possibility is to just drop packages that aren't maintained well
> enough. While this is somewhat attractive, it doesn't really serve our
> users any better than saying "Why don't we just lower our standards?"

Basically I agree that instantly dropping 'bad' packages (or, worse,
doing it automatically) is not the best option for users. But OTOH it
cannot be the best solution neither to keep them forever, begging 
people to fix them without any success. 

Currently there are other issues that hold up the release (d-i and
others), but when these things have settled, I have the impression
that many users would prefer a release with some dropped packages over
a never-ending testing period. At least I do :-) Because compiling one
or two upstream packaes is much easier that always trying to keep in
sync with testing or fiddling with backports.org.

Just my EUR 0.02,

have a nice weekend everybody!

Martin

Bug#223067: ITP: fnfx -- daemon to use the special keys of Toshiba laptop keyboard

[Cédric Delfosse]

Package: wnpp
Severity: wishlist

* Package name: fnfx
  Version : 0.2
  Upstream Author : Timo Hoenig <[EMAIL PROTECTED]>
* URL : http://fnfx.sf.net
* License : GPL
  Description : daemon to use the special keys of Toshiba laptop keyboard

 It enables owners of Toshiba laptops to map the Fn keys and the multimedia
 keys to trigger laptop internal functions (change the LCD brightness, volume
 up and down, ...), power management related functions (suspend modes), or
 user written scripts.
 .
 You need a 2.4 or 2.6 Linux kernel with ACPI support and the "Toshiba Laptop
 Extras" option.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux localhost 2.6.0-test9-1-386 #1 Sun Oct 26 22:32:52 EST 2003 i686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]

Re: Building Debian Completely From Source

[John Goerzen]

On Fri, Dec 05, 2003 at 05:48:21PM -0800, Eric Wong wrote:
> apt-fu src-dist-upgrade

Excellent work!  *This* is what I have been searching for.  Plus, it
seems to actually work! :-)

I have one feature request: I'd like to have an option so that I can ask
it to rebuild arch-indep packages just like it rebuilds other packages.
In other words, a "never download any .deb, ever" option :-)

Oh, and a second feature request: how about uploading it to sid?  (If
you're not a Debian developer, I'd gladly sponsor the upload.  You
obviously know your way around the packaging system )

> Though it takes some configuring.

I'd like to be able to set that one, too...  just do the upgrade for all
packages.  But that effect can be simulated now with dpkg
--get-selections.

> apt-fu installs binary packages of build-depends first to avoid circular
> build-dependencies, and then builds and installs the build-depends from
> source if -R is specified.  It's a nasty problem but you can't have the
> chicken without the egg, nor the egg without the chicken.

Yeah, I have found some of those circular build-deps.  I believe they
should be considered serious bugs if they aren't already.  That's just
wrong.  But in my case, I'd rather deal with the breakage manually than
download the .deb.

-- John

Re: Bits from the RM

[Anthony Towns]

On Sat, Dec 06, 2003 at 03:01:20PM +0100, Martin Pitt wrote:
> On 2003-12-01 14:45 +1000, Anthony Towns wrote:
> > Another possibility is to just drop packages that aren't maintained well
> > enough. While this is somewhat attractive, it doesn't really serve our
> > users any better than saying "Why don't we just lower our standards?"
> Basically I agree that instantly dropping 'bad' packages (or, worse,
> doing it automatically) is not the best option for users. But OTOH it
> cannot be the best solution neither to keep them forever, begging 
> people to fix them without any success. 

Sure. The best solution is to beg people to fix them _with_ success.

Please focus your attentions in that direction.

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


pgpk7TnFq5RrA.pgp
Description: PGP signature

Re: exim4-config and exim4-base installed on systems with non-exim-MTA

[Anthony Towns]

On Sat, Dec 06, 2003 at 10:34:45AM +0100, Andreas Barth wrote:
> > Seriously, I think you need to reconsider having the configuration in
> > a separate package.
> > What're you trying to achieve exactly?
> Allowing for different configuration mechanismn. And I (as a user of
> exim4) like that very much.

There are plenty of things that could be described that way that don't
involve having separate packages. There's a reason the word "exactly"
appeared in the question above.

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


pgpR3Fn0Toy5B.pgp
Description: PGP signature

Problems verifying release.gpg

[Jarno Elonen]

Hi,

I'm having trouble verifying release.gpg for Unstable. Has the release key 
been changed to 30B34DD5, am I doing something wrong or what's up?

After apt-secure failed to "apt-get update" today...

  Err http://ftp.fi.debian.org unstable Release
The following signatures couldn't be verified because the public key is
not available: NO_PUBKEY 2DB1C72530B34DD5

...I tried to verify the signature myself. However, it failed as well:

supertiger:~/test$ wget http://ftp.fi.debian.org/debian/dists/unstable/Release
--17:48:00--  http://ftp.fi.debian.org/debian/dists/unstable/Release
   => `Release'
Resolving ftp.fi.debian.org... 130.230.54.99
Connecting to ftp.fi.debian.org[130.230.54.99]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 34,068 [text/plain]

100%[>] 34,068--.--K/s

17:48:00 (303.83 KB/s) - `Release' saved [34068/34068]

supertiger:~/test$ wget http://ftp.fi.debian.org/debian/dists/unstable/
Release.gpg
--17:48:06--  http://ftp.fi.debian.org/debian/dists/unstable/Release.gpg
   => `Release.gpg'
Resolving ftp.fi.debian.org... 130.230.54.99
Connecting to ftp.fi.debian.org[130.230.54.99]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 197 [text/plain]

100%[>] 197   --.--K/s

17:48:06 (1.88 MB/s) - `Release.gpg' saved [197/197]

supertiger:~/test$ mv Release.gpg Release.asc
supertiger:~/test$ gpg --no-default-keyring --keyring=./test-ring.gpg 
--keyserver the.earth.li --recv-keys 38C6029A
gpg: keyring `./test-ring.gpg' created
gpg: key 38C6029A: public key "Debian Archive Automatic Signing Key (2003) 
<[EMAIL PROTECTED]>" imported
gpg: Total number processed: 1
gpg:   imported: 1
supertiger:~/test$ gpg --keyring=./test-ring.gpg --verify Release.asc
gpg: Signature made Fri Dec  5 22:42:16 2003 EET using DSA key ID 30B34DD5
gpg: Can't check signature: public key not found

Re: Problems verifying release.gpg

[Jarno Elonen]

> I'm having trouble verifying release.gpg for Unstable. Has the release key
> been changed to 30B34DD5

Ah, so it has. I just found the announcement which had been filtered to a 
wrong mail folder by accident. Sorry.

- Jarno

15天减去20斤的减肥方法

[中国纤体网]

  您好
  如果您为了肥胖而烦恼，请进入中国纤体网 http://www.cnqt.net
  我们能让您在短时间内，变的苗条、美丽。
  您还可以在中国纤体网免费计算您的肥胖状况。
  祝身体健康  
中国纤体网 http://www.cnqt.net

Requirements on signatures on debs (was: Revival of the signed debs discussion)

[Andreas Barth]

First: There is now a version of debsigs that creats debs that the
apt-utils could cope with, see http://debsigs.turmzimmer.net/ (I tried
it with the unmodified apt-utils of woody).

* Goswin von Brederlow ([EMAIL PROTECTED]) [031202 04:55]:
> I agree with you that every instance along the way to the archive
> should sign the package:
> 
> 1. maintainer
> 2. sponsor
> 3. buildd
> 4. buildd admin
> 5. dinstall

I've tried to write down a list of requirements for the signature
names (and what should be signed). I'll update the web version of this
on http://debsigs.turmzimmer.net/policy.html


  policy for debsigs

What are the technical conditions

   Current, signatures are created with debsigs and each is stored in an
   extra file in the deb. One (due to policy unchangeable) condition is
   that non-standard filesnames in the deb start with _ and that all
   filenames are not longer than 14 characters. debsigs uses as prefix
   the characters "_gpg", which is quite usefull. So, there are (at
   maximum) 10 characters left for usage of signature names.

What should signature reflect?

   There are quite different people and roles who handle a package during
   it's lifetime. These are (among others):
 * Maintainer as part of the build process
 * non-Maintainer as part of the build process (NMUs)
 * sponsor
 * buildd
 * buildd-Admin (or is this aequivalent to the non-Maintainer?)
 * dinstall for installing

   There are a few key differences: Some roles are bound to scripts that
   do their action independing on any human action, some are bound more
   or more less to human interaction.

   One other key question is: Should each signature stand for it's own
   (means: one could delete one signature from inbetween a deb), or
   should they depend on each other)? The former has the advantage that
   this is the current approach, and technically easier. The later has
   the advantage that this enforces identification in which order which
   persons and roles did handle the deb.


I'm open for additions, suggestions, comments or (due I hope not) errors.
Please tell me.


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

[Mathieu Roy]

Cameron Patrick <[EMAIL PROTECTED]> said:

[...]


> A standard like .desktop or the Debian menu system we have now /is/ a
> good thing; we also need a way to make those menu hierarchies available
> to applications which cannot and will not read them directly (hence the
> "weird formats" that I mentioned).  Currently, freedesktop provides the
> former but not the latter, so in order for freedesktop's scheme to be
> considered as a replacement for what we use now, there must also be a
> way to convert them into the format used by some arbitrary menu system.
> In practice, a way to convert existing menu entries into the new system,
> and ideally also a way to make use of existing menu-methods, would also
> be required.

Ok.

[...]


> Of course not.  But a lot - in fact, the overwhelming majority - of
> these environments predate .desktop files, and are unlikely to change.
> They don't integrate directly with any menu system but their own.  For
> new window managers (or or menu systems), I agree, it makes sense to use
> .desktop files for the appropriate menu, as they are more widely
> supported outside of Debian.

Ok.

[...]


> | > There is no reason for Debian to do something merely because Red Hat
> | > does.
> | 
> | Why do you assume that I want Debian to follow RedHat choice?
> [...]
> | Nobody proposed that. I do not see the point in arguing about a
> | non-existant proposal.
>
> In that case, why did you mention what Red Hat were doing?

Since the paragraph where I mentioned RedHat is no longer quoted, it
is less obvious why I mentioned it.

I mentioned RedHat choice has an example of major GNU/Linux
contributor that apparently decided that current development activity
on the project WindowMaker is too low to continue to support
commercially WindowMaker.

I have to admit that all the information I can found about that is
very laconic, for instance, in 

is says that wmaker has been removed due to "Developer resource
constraints". 

I remember about a message from a guy from RedHat saying more or less
that he see no point in supporting an environment/wm that do not
follow the new standards decided at freedesktop.org (is open to
anybody if I understood right), that makes hard for RedHat to avoid
some specific troubles, to provide support easily. But I'm not able to 
remember where I seen that message, so maybe it was a mistake from me.  

This example was not meant to be a plan for Debian but an example of
persons thinking that it could make sense for wmaker to consider
following freedesktop.org standards in some cases.

The point was only: apparently it does not look so dumb to everybody
to consider using .desktop even for some of the environment/wm listed
by someone previously in this discussion.

(A bad example, I have to admit, considering the size of my
explanation of its usage)






-- 
Mathieu Roy

  +-+
  | General Homepage:   http://yeupou.coleumes.org/ |
  | Computing Homepage: http://alberich.coleumes.org/   |
  | Not a native english speaker:   |
  | http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english  |
  +-+

Re: Building Debian Completely From Source

[Roger Leigh]

John Goerzen <[EMAIL PROTECTED]> writes:

>> apt-fu installs binary packages of build-depends first to avoid circular
>> build-dependencies, and then builds and installs the build-depends from
>> source if -R is specified.  It's a nasty problem but you can't have the
>> chicken without the egg, nor the egg without the chicken.
>
> Yeah, I have found some of those circular build-deps.  I believe they
> should be considered serious bugs if they aren't already.  That's just
> wrong.  But in my case, I'd rather deal with the breakage manually than
> download the .deb.

In late 2001, I spent several weekends hand-building quite a large
chunk of woody (over 200 source packages).  I found quite a number of
serious bug in several packages, including missing Build-Deps, and, in
the case of (IIRC) Tcl 8.x, it wouldn't build unless the same version
was also installed (due to a shlibs problem requiring the just-built
library to be installed for shlibdeps to be computed).

This sort of automated source building is a very good idea--it will
root out a lot of build bugs, and will improve the quality of Debian.


-- 
Roger Leigh

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

Re: OT: Smartcards and Physical Security

[Manoj Srivastava]

On Sat, 6 Dec 2003 02:35:16 -0800, Tom  <[EMAIL PROTECTED]> said: 

> On Sat, Dec 06, 2003 at 01:51:23AM -0600, Manoj Srivastava wrote:
>>
>> Drop the imperatives, and we shall get along a lot better.  Better
>> still, roll up your sleeves and make it happen, and you'll earn my
>> respect, and my support.

> How about "fuck up again and watch your good thing go away" (hint I
> ain't it)

And then again I question your judgement. What, pray, is this
 good thing that is going to go away? (BTW, this is not the first time
 we have fucked up, and it won't be the last time).

>> I was merely dumbfounded at the _quality_ of pot shots you were
>> taking.

> Heh.  I've had to tell people at work to go home and take a fucking
> bath: you stink.  Manoj, your words are powerless.

You have my condolences for the work environment you find
 yourself in.

manoj
-- 
One picture is worth 128K words.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: OT: Smartcards and Physical Security

[Tom]

On Sat, Dec 06, 2003 at 11:13:05AM -0600, Manoj Srivastava wrote:

>   And then again I question your judgement. What, pray, is this
>  good thing that is going to go away?

"Hey hey I saved the world today
Everybody*s happy now
The bad things gone away
And everybody*s happy now
The good thing*s here to stay
Please let it, please let it"

I'm not being evasive, this is the answer to your question:
You'll know it when it's gone.

Re: song

[Scott James Remnant]

ObPrivate

On Sat, 2003-12-06 at 17:22, Andreas Schuldei wrote:

> * Matt Flax ([EMAIL PROTECTED]) [031206 17:30]:
> > I have now completed a rough song outline for Debain 2003.
> 
> is there a reason for this to be *private*?
> 
It's probably very rude or something, I'm all for it :-)

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



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

Re: Building Debian Completely From Source

[Antti-Juhani Kaijanaho]

On 20031206T085705-0600, John Goerzen wrote:
> Yeah, I have found some of those circular build-deps.  I believe they
> should be considered serious bugs if they aren't already.  That's just
> wrong.

There are several good reasons for circular build-time dependencies.
For example, every self-hosting compiler build-depends on itself
(many of them can be bootstrapped, but I'm not sure we want to require
bootstrapping on every build - and some require manual bootstrapping
work).

-- 
Antti-Juhani Kaijanaho, Debian developer   http://www.iki.fi/gaia/


signature.asc
Description: Digital signature

Re: debsums for maintainer scripts

[Goswin von Brederlow]

"Bernhard R. Link" <[EMAIL PROTECTED]> writes:

> * Goswin von Brederlow <[EMAIL PROTECTED]> [031206 05:12]:
> > > But false negatives cause work. Why do you want to cause false
> > > negatives?
> > 
> > Its not causing it. Its not preventing them anymore than the current
> > list.
> 
> Huh? I gave multiple examples where the current solution works
> correctly, but your suggested solution will give false negatives
> unless major work is put into it.
> 
> > > I'm still hoping to see you giving a single reason, why the current
> > > robust solution, implemented by a vast majority packages, should be
> > 
> > Because its neither robust, not elegant, nor tamper resistant.
> 
> So please give me a simple reson or example why it is not robust.
> I cannot think of anything more robust than a static file generated
> at build time.

Files get corrupted on your system, files disapear, file get edited
legally, postinst/debconf change files, files get replaced, 

Using/Providing signatures of the md5sum files prevents tampering
(including accidental). The rest remains but I consider them dpkg bugs
mostly.

> In what respect is it not elegant?
> 
> And what tamper is it accessible for, that generating at install time 
> is not?

To the evil attacker or filesystem corruption.

> > > replaced by something else. Where this something else needs substantial
> > > computing power, will need much work to be usable in all cases and 
> > 
> > As I explained it only need the extra computing power to calculate a
> > signature of the md5sums list of a package. The time taken to compute
> > a signature of a few K is neglible compared to the time spend
> > computing the md5sums of installed files in the first place.
> 
> No, it needs the time to calculate all the md5sums before it can
> calculate the signature. And it will need this time with any

No, you need to compute the md5sum of all files to do an actual
audit. You already have the list of md5sum file then and just have to
check the signature instead of checking again
var/lib/dpkg/info/*.md5sum.

> installation of a package. (As there is currently to way to do it
> later, and making sure there is will not be easy).

The way to create them later is just as well working as comparing the
current md5sum files. You don't loose anything. And if thats not well
enough you have the _option_ to spend a miniscule amount of extra time
to generate the md5sum lists on install.

> > Also this is only required when actually verifying and only for people
> > who want to do that. People with proper intrusion detection systems
> > don't have to.
> 
> This simply does not work. 
> dpkg -i a ; dpkg -i a-replacement ; dpkg -P a-replacement
> is simply not equivalent to
> dpkg -i a

dpkg bug as said before. And the current md5sum lists approach fails
just as well.

> > > is complex enought that it will eventually fail.
> > 
> > Its just as robust as the current md5sum lists and then failsave on
> > top of it. Its not removing any features you can have with the current
> > setup but adds security, saves bandwith and space.
> 
> How should it add security? If you generate the md5sums at build time
> or at install time, it keeps the same.

You generate the signature at build time. You can verify if the md5sum
list you generate at any time or the list a friend gives you (or you
download from snapshot.debian.net) matches the one the maintainer had.

Imagine that, you could trsut snapshot.debian.net not to be
compromised.

> > > The only thing having any similarity to a reason was the size of those
> > > files. But seeing how small they are, I don't think this can be the
> > > reason. So what did I miss?
> > 
> > It is a reason. First you have the smaller and embeded systems that
> > can realy do with the files, seeing that they are useless for a
> > security audit anyway. Second you have all the mirrors wasting
> > precious space and bandwith.
> 
> Embeded systems is will need some space reductions with other files 
> anyway. (Or such small files will not cause anything).
> 
> The space-save for the mirrors by removing the md5sums files should
> be equivalent to dropping a single avarage-sized non-free package.
> (If it has a longer description, the bandwidth needed to fetch this
>  packages Description within Packages.gz each time someone does an
>  update should also easily compensate the bandwith of the md5sums
>  of all the other files.)
>
>
> > As an example: The md5sum list of a package is usually bigger or same
> > size as its changes file and there is concern about mirror space and
> > bandwith if they should be added to the archive.
> 
> Almost all packages have already a md5sums file. So there if few
> additionally space needed. For the comparison of the size:
> 
> # find /var/lib/dpkg/info/ -name "*.md5sums" -exec ./count.sh {} \; 
> |./avarage.awk 
> 3200.3
> 
> # find /usr/share/doc -name "changelog.Debian.gz" -exec wc -c {} \; 
> |./avarage.awk
> 5310.36
> # find /usr/share/doc -name "c

Re: Building Debian Completely From Source

[Goswin von Brederlow]

Roger Leigh <[EMAIL PROTECTED]> writes:

> John Goerzen <[EMAIL PROTECTED]> writes:
> 
> >> apt-fu installs binary packages of build-depends first to avoid circular
> >> build-dependencies, and then builds and installs the build-depends from
> >> source if -R is specified.  It's a nasty problem but you can't have the
> >> chicken without the egg, nor the egg without the chicken.
> >
> > Yeah, I have found some of those circular build-deps.  I believe they
> > should be considered serious bugs if they aren't already.  That's just
> > wrong.  But in my case, I'd rather deal with the breakage manually than
> > download the .deb.
> 
> In late 2001, I spent several weekends hand-building quite a large
> chunk of woody (over 200 source packages).  I found quite a number of
> serious bug in several packages, including missing Build-Deps, and, in

Did you consult the buildd build-dependency override files? Back then
Build-depends were less than complete.

> the case of (IIRC) Tcl 8.x, it wouldn't build unless the same version
> was also installed (due to a shlibs problem requiring the just-built
> library to be installed for shlibdeps to be computed).
> 
> This sort of automated source building is a very good idea--it will
> root out a lot of build bugs, and will improve the quality of Debian.

Thats whats autobuilders already do.

MfG
Goswin

Re: Requirements on signatures on debs (was: Revival of the signed debs discussion)

[Goswin von Brederlow]

Andreas Barth <[EMAIL PROTECTED]> writes:

> First: There is now a version of debsigs that creats debs that the
> apt-utils could cope with, see http://debsigs.turmzimmer.net/ (I tried
> it with the unmodified apt-utils of woody).
> 
> * Goswin von Brederlow ([EMAIL PROTECTED]) [031202 04:55]:
> > I agree with you that every instance along the way to the archive
> > should sign the package:
> > 
> > 1. maintainer
> > 2. sponsor
> > 3. buildd
> > 4. buildd admin
> > 5. dinstall
> 
> I've tried to write down a list of requirements for the signature
> names (and what should be signed). I'll update the web version of this
> on http://debsigs.turmzimmer.net/policy.html

Please update my bug for policy about this if you have some spare time.

>   policy for debsigs
> 
> What are the technical conditions
> 
>Current, signatures are created with debsigs and each is stored in an
>extra file in the deb. One (due to policy unchangeable) condition is
>that non-standard filesnames in the deb start with _ and that all
>filenames are not longer than 14 characters. debsigs uses as prefix
>the characters "_gpg", which is quite usefull. So, there are (at
>maximum) 10 characters left for usage of signature names.
> 
> What should signature reflect?
> 
>There are quite different people and roles who handle a package during
>it's lifetime. These are (among others):
>  * Maintainer as part of the build process
>  * non-Maintainer as part of the build process (NMUs)
>  * sponsor
>  * buildd
>  * buildd-Admin (or is this aequivalent to the non-Maintainer?)
>  * dinstall for installing
> 
>There are a few key differences: Some roles are bound to scripts that
>do their action independing on any human action, some are bound more
>or more less to human interaction.
> 
>One other key question is: Should each signature stand for it's own
>(means: one could delete one signature from inbetween a deb), or
>should they depend on each other)? The former has the advantage that
>this is the current approach, and technically easier. The later has
>the advantage that this enforces identification in which order which
>persons and roles did handle the deb.
> 
> 
> I'm open for additions, suggestions, comments or (due I hope not) errors.
> Please tell me.
> 
> 
> Cheers,
> Andi

Sounds good.

MfG
Goswin

Re: Revival of the signed debs discussion

[Goswin von Brederlow]

Henning Makholm <[EMAIL PROTECTED]> writes:

> Scripsit Goswin von Brederlow <[EMAIL PROTECTED]>
> 
> > If a package is compromised we can proof that the DD of the package
> > either is malicious or incompetent.
> 
> Say, we just had a major compromise on certain Debian machines. Pray
> tell, who do you think this proves is malicious or incompetent? We'd
> certainly want to toss out the culprit ASAP.

Say master gets compromised. I don't realy care, the deb signature of
the maintainer and buildds is still preventing any tampering. Each
signature adds another gpg key that has to be compromised to tamper
with exiting debs.

MfG
Goswin

Re: uploading problems and massive email floods

[Ben Pfaff]

Ryan Murray <[EMAIL PROTECTED]> writes:

> On Fri, Dec 05, 2003 at 10:52:19AM -0800, Ben Pfaff wrote:
> 
> > autoconf_2.58-9_i386.changes has bad PGP/GnuPG signature!
> > Removing autoconf_2.58-9_i386.changes, but keeping its associated files for 
> > now.
> > 
> > Greetings,
> > 
> > Your Debian queue daemon
> 
> This problem should be fixed.
> 
> > After that, I've received over 134 copies of the following
> > message:
> 
> And in future, you should only get 1 copy of this message.

Thanks for taking care of everything.
-- 
"To prepare for the writing of Software,
 the writer must first become one with it,
 sometimes two."
--W. C. Carlson

Re: Revival of the signed debs discussion

[Goswin von Brederlow]

Andreas Barth <[EMAIL PROTECTED]> writes:

> * Henning Makholm ([EMAIL PROTECTED]) [031206 13:25]:
> > Scripsit Goswin von Brederlow <[EMAIL PROTECTED]>
> > > If a package is compromised we can proof that the DD of the package
> > > either is malicious or incompetent.
>  
> > Say, we just had a major compromise on certain Debian machines. Pray
> > tell, who do you think this proves is malicious or incompetent? We'd
> > certainly want to toss out the culprit ASAP.

If a mail goes around saying the key of xyz got compromised I would
block any package with that key from getting installed (given signed
debs), in a heartbeet.

How or what is to blame can be sorted out later.

> IMHO there can also be a third explanation: "Bad luck". But this also
> nullifies the trust in any keys on any compromised machine - and the
> administrators did replace the keys.

And currently its very hard to remove packages build by a compromised
maintainer from a local system or even check if one has any.

MfG
Goswin

Re: Building Debian Completely From Source

[Adam Heath]

On Sat, 6 Dec 2003, Roger Leigh wrote:

> In late 2001, I spent several weekends hand-building quite a large
> chunk of woody (over 200 source packages).  I found quite a number of
> serious bug in several packages, including missing Build-Deps, and, in
> the case of (IIRC) Tcl 8.x, it wouldn't build unless the same version
> was also installed (due to a shlibs problem requiring the just-built
> library to be installed for shlibdeps to be computed).

That's a bug in tcl.  It should use shlibs.local.

Re: Building Debian Completely From Source

[John Goerzen]

On Sat, Dec 06, 2003 at 09:31:54PM +0200, Antti-Juhani Kaijanaho wrote:
> For example, every self-hosting compiler build-depends on itself
> (many of them can be bootstrapped, but I'm not sure we want to require
> bootstrapping on every build - and some require manual bootstrapping
> work).

Obviously gcc is the #1 example of this.  However, gcc packages should
not need to depend on themselves; in our distribution, we tend to have
many different versions of gcc available, and any of them should be able
to build a newer gcc.

Nothing else in main comes to mind right now, though I'm sure there is
something else...

But for everything but the C compiler, I think that the build probably
should do the bootstrapping work itself wherever possible.

apell

[Henning Glawe]

Moin,
what are the "license problems" causing the removal of aspell in the
update to 3.0r2 ?
do these problems exist in debian unstable ?
if not: why was aspell _removed_ from stable and not replaced by a
backport of the version in unstable ?

-- 
c u
henning

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

[Marc Wilson]

On Sat, Dec 06, 2003 at 06:02:16PM +0100, Mathieu Roy wrote:
> I remember about a message from a guy from RedHat saying more or less
> that he see no point in supporting an environment/wm that do not
> follow the new standards decided at freedesktop.org...

Just as a data point, you do realize that freedesktop.org is a wholly owned
and operated subsidiary of RedHat, right?

Oh, you don't think so?  Take a look at who their god-king is.  Take a look
at where their mailing lists are hosted.  Karsten has detailed in another
thread his interactions with that group.

Then think about whether RedHat has a vested interest in *not* supporting
anything that doesn't view the world the same way their annointed "God of
the Desktop" does.

-- 
 Marc Wilson |  Stupid nick highlighting  Whenever someone
 [EMAIL PROTECTED] | starts with "stupid" it highlights the nick.  Hmm.
 | -- #Debian

Re: recovery status update

[Steve Langasek]

On Fri, Dec 05, 2003 at 01:17:25PM +0100, Roland Bauerschmidt wrote:
> James Troup wrote:
> > As part of the recovery process, db.debian.org has migrated, both to a
> > new host (because the old box was on it's last legs and HP kindly
> > donated a shiny new one to replace it), and to a newer version of LDAP
> > (because it was still using potato's OpenLDAP).
> 
> Which exact version of OpenLDAP and which database backend are you
> using? The BDB backend has severe problems if incorrectly configured
> (i.e. a DB_CONFIG file is missing or the cachesize specified there is
> too small). We're working on that at the moment; libdb4.2 4.2.51 is
> supposed to fix the problem, though a correctly cachesize is still
> important for performance.

Hmm, I'm pretty sure the box is running stable, so this should be a
non-issue (for now).

Cheers,
-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

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

[Zenaan Harkness]

On Sun, 2003-12-07 at 08:41, Marc Wilson wrote:
> On Sat, Dec 06, 2003 at 06:02:16PM +0100, Mathieu Roy wrote:
> > I remember about a message from a guy from RedHat saying more or less
> > that he see no point in supporting an environment/wm that do not
> > follow the new standards decided at freedesktop.org...
> 
> Just as a data point, you do realize that freedesktop.org is a wholly owned
> and operated subsidiary of RedHat, right?
> 
> Oh, you don't think so?  Take a look at who their god-king is.  Take a look
> at where their mailing lists are hosted.  Karsten has detailed in another
> thread his interactions with that group.
> 
> Then think about whether RedHat has a vested interest in *not* supporting
> anything that doesn't view the world the same way their annointed "God of
> the Desktop" does.

Ahh ... thanks for pointing this out. I knew there was a conspiracy to
pre-empt and subvert all competing desktop standardization efforts. By
no less than those evil Microsoft wannabes themselves, Red Hat! We
should take it even more personally - no point dealing on superfluous
technical level.

Cynicism aside, can anyone point to Carsten's thread for some other
individual's POV?

ta
zen

-- 
Debian Enterprise GNU/Linux: http://debian-enterprise.org/
* Homepage: http://soulsound.net/
* PGP Key: http://soulsound.net/zen.asc
* Please respect the confidentiality of this email as sensibly warranted.

Re: apell

[Brian Nelson]

Henning Glawe <[EMAIL PROTECTED]> writes:

> Moin,
> what are the "license problems" causing the removal of aspell in the
> update to 3.0r2 ?

IMO, there are no license problems.  See:

  http://lists.debian.org/debian-user/2003/debian-user-200312/msg00870.html

> do these problems exist in debian unstable ?

No.

> if not: why was aspell _removed_ from stable and not replaced by a
> backport of the version in unstable ?

The upgrade to Aspell 0.50 is too big of a change for stable and would
break a ton of stuff.

-- 
Don't worry, it's *in*-flammable.


pgpFNCPhCksgL.pgp
Description: PGP signature

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

[Colin Walters]

On Sat, 2003-12-06 at 16:41, Marc Wilson wrote:
> On Sat, Dec 06, 2003 at 06:02:16PM +0100, Mathieu Roy wrote:
> > I remember about a message from a guy from RedHat saying more or less
> > that he see no point in supporting an environment/wm that do not
> > follow the new standards decided at freedesktop.org...
> 
> Just as a data point, you do realize that freedesktop.org is a wholly owned
> and operated subsidiary of RedHat, right?

That's simply not true.  Plenty of people contribute to freedesktop.org
outside of Red Hat.  I know a number of Debian developers who do, for
example.

> Oh, you don't think so?  Take a look at who their god-king is.  Take a look
> at where their mailing lists are hosted. 

You might notice that Red Hat hosts a lot of *other* mailing lists too:
http://www.redhat.com/mailman/listinfo

And I suppose hosting say the BLinux list is all part of another
conspiracy?

> Then think about whether RedHat has a vested interest in *not* supporting
> anything that doesn't view the world the same way their annointed "God of
> the Desktop" does.

It's hard to try to take this seriously, but: what is this supposed
"vested interest"?



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

Re: Building Debian Completely From Source

[Roger Leigh]

Adam Heath <[EMAIL PROTECTED]> writes:

> On Sat, 6 Dec 2003, Roger Leigh wrote:
>
>> In late 2001, I spent several weekends hand-building quite a large
>> chunk of woody (over 200 source packages).  I found quite a number of
>> serious bug in several packages, including missing Build-Deps, and, in
>> the case of (IIRC) Tcl 8.x, it wouldn't build unless the same version
>> was also installed (due to a shlibs problem requiring the just-built
>> library to be installed for shlibdeps to be computed).
>
> That's a bug in tcl.  It should use shlibs.local.

Yup.  I filed a bug and fix for it at the time, IIRC (it /was/ two
years ago!).


-- 
Roger Leigh

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

Re: Building Debian Completely From Source

[Roger Leigh]

Goswin von Brederlow <[EMAIL PROTECTED]> writes:

> Roger Leigh <[EMAIL PROTECTED]> writes:
>
>> John Goerzen <[EMAIL PROTECTED]> writes:
>> 
>> >> apt-fu installs binary packages of build-depends first to avoid circular
>> >> build-dependencies, and then builds and installs the build-depends from
>> >> source if -R is specified.  It's a nasty problem but you can't have the
>> >> chicken without the egg, nor the egg without the chicken.
>> >
>> > Yeah, I have found some of those circular build-deps.  I believe they
>> > should be considered serious bugs if they aren't already.  That's just
>> > wrong.  But in my case, I'd rather deal with the breakage manually than
>> > download the .deb.
>> 
>> In late 2001, I spent several weekends hand-building quite a large
>> chunk of woody (over 200 source packages).  I found quite a number of
>> serious bug in several packages, including missing Build-Deps, and, in
>
> Did you consult the buildd build-dependency override files? Back then
> Build-depends were less than complete.
>
>> the case of (IIRC) Tcl 8.x, it wouldn't build unless the same version
>> was also installed (due to a shlibs problem requiring the just-built
>> library to be installed for shlibdeps to be computed).
>> 
>> This sort of automated source building is a very good idea--it will
>> root out a lot of build bugs, and will improve the quality of Debian.
>
> Thats whats autobuilders already do.

Do they ensure that you can *rebuild* from source, after the initial
autobuild?  They can't ensure that woody or sarge can be built from
the source.  If you took a woody distribution disc, and tried to build
just using the binaries and source packages on the disc, you'd find
many packages have become unbuildable.


-- 
Roger Leigh

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

Re: apell

[Brian Nelson]

Brian Nelson <[EMAIL PROTECTED]> writes:

> Henning Glawe <[EMAIL PROTECTED]> writes:
>
>> Moin,
>> what are the "license problems" causing the removal of aspell in the
>> update to 3.0r2 ?
>
> IMO, there are no license problems.  See:

Actually, I take that back.  There was a serious bug in that
/usr/share/doc/aspell-en/copyright claimed it was LGPL, but the
wordlists in fact are under a conglomerate of licenses (none of which
are copyrightable anyway in the US, but hey...).

-- 
Don't worry, it's *in*-flammable.


pgpSjSM1dfveQ.pgp
Description: PGP signature

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

[Chad Walstrom]

On Sat, Dec 06, 2003 at 01:40:58AM -0600, Manoj Srivastava wrote:
>  -- until there exists a mechanism to convert .desktop entries into
>  things that the back-end WM's can grok, we are stymied

Agreed.

> (since we have a system that works, however imperfectly, and dropping
> support for these window mangers would be a regression).

Never suggested it.  Personally, I like menu files.  They're simple,
direct, and provide a great service to Debian.

> The other part is, of course, teaching developers how to write the
> .desktop menu item, and I for one, have never seen one.

That hasn't stopped us before. ;-p  I agree though, it's a learning
process.  I haven't looked at the menu code, so I don't know how
difficult it'ld be to "throw in" a .desktop file parser/converter.

Don't get me wrong, I didn't ever suggest abandoning Debian menu.  I
only suggested that participating in something that may turn out to be a
"standard" amongst desktop environments will only benefit us.

-- 
Chad Walstrom <[EMAIL PROTECTED]>   http://www.wookimus.net/
   assert(expired(knowledge)); /* core dump */


pgpnDHrLTlFif.pgp
Description: PGP signature

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

[Chad Walstrom]

On Sat, Dec 06, 2003 at 05:11:50PM +1100, Russell Coker wrote:
> What is needed for initrd-tools?  I've given up on using initrd's for
> kernels I compile.

That's sad.  initrd saved my bacon more than once. ;-)  If you like to
compile vanilla kernels, either find the Debian cramfs-initrd patch or
use romfs.  Then change mkinitrd.conf(5) to look like this:

  MKIMAGE="genromfs -d %s -f %s"

I've had problems with "BUSYBOX=yes", so I don't include it.  (I should
have debugged it -- had to do w/mount and /etc/fstab, but I didn't have
the time.)

mkinitrd is pretty good about finding your required modules, but it
sometimes doesn't get it right.  Always mount the romfs file and make
sure the modules are there and will be loaded (/etc/modules).

Good luck!

-- 
Chad Walstrom <[EMAIL PROTECTED]>   http://www.wookimus.net/
   assert(expired(knowledge)); /* core dump */


pgpCWQVvYCpps.pgp
Description: PGP signature

Re: debsums for maintainer scripts

[David Weinehall]

On Sat, Dec 06, 2003 at 01:24:58AM -0600, Manoj Srivastava wrote:
> On Fri, 05 Dec 2003 13:34:10 -0500, Anthony DeRobertis <[EMAIL PROTECTED]> 
> said: 
> 
> > On Thu, 2003-12-04 at 11:11, Manoj Srivastava wrote:
> >> That is but one optimization: we already are suffering from archive
> >> bloat, what about the disk and bandwidth cost of carrying around
> >> the sigs?  And since one rarely needs the md5sums anyway, what is
> >> so wrong with checking against the .deb when needed?
> 
> > I just took an md5sum of every file on my system. Including things
> > like /var and /home that aren't part of packages. It's 13M,
> > uncompressed.  Compressed, it's 3.5M.
> 
> > If we were really worried about archive size, an md5sum is 16
> > octets.  It's hard to see that mattering to overall archive size.
> 
>   I am (probably) getting a Zaurus for christmas this year. I
>  would like to run Debian on it.  You think that the PDA has gobs of
>  disk space to throw around?

udeb's would probably be better here anyway; the checksums is
not the heaviest load on your Zaurus; dpkg itself, perl, glibc, etc will
be.

[snip]


Regards: David Weinehall
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/

Re: Intel f90 compiler for Debian.

[Lukas Geyer]

alberto <[EMAIL PROTECTED]> writes:

> Intel has a powerful f90 compiler, the only one freely available on
> the market, as far as I know, which runs under Linux. It is an
> extremely important tool for those who run numerical simulations for
> scientific purposes.
> http://www.intel.com/software/products/compilers/downloads/forlin.htm
> 
> Unfortunately for Debian users, Intel distribute the compiler as an
> rpm archive, and the install script is accordingly written.
> 
> I have succesfully and easily installed the compiler on my Debian
> Woody in a kind of a dirty way and I've put a brief HOWTO on my web
> site:
> http://www.nordita.dk/~bigazzi/varie/Intel_F90_on_a_Debian_GNU_system
> .html
> 
> I'm sure, though, that the install script, wich you find on the same
> page of mine, can be just adapted to Debian and made available to
> Intel for them to include Debian as a supported platform for their
> compiler.
> 
> Notice that, in the scientific community, the availability of such a
> compiler for Debian,  will greatly benefit our favorite distro.
> 
> Does anyone want to take the task of rewriting the script for Debian?

There are more problems to this than the rpm format. As I understand
their website, Intel provides a binary-only version of this compiler,
and the license agreement prohibits disassembly and reverse
engineering. Furthermore, it is available only for the i386
architecture. The non-freeness prevents it from becoming part of
Debian. The free software community would profit much more from making
gcc's Fortran compiler compatible with the Fortran 95 standard. For
those interested, the TODO list is at

http://gcc.gnu.org/fortran/todo.html

Of course, if somebody (maybe you?) sends Intel some patches to make
their compiler work on Debian systems, that can not be bad. As an
aside, I don't quite understand why Fortran is still so popular in the
numerical mathematics community... :)

Lukas

Bug#223114: marked as done ([INTL:de] german po-debconf translation)

[Debian Bug Tracking System]

Your message dated Sun, 7 Dec 2003 01:20:20 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Bug#223114: fixed in ksensors 0.7.2-12
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

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

--
Received: (at submit) by bugs.debian.org; 6 Dec 2003 22:13:38 +
>From [EMAIL PROTECTED] Sat Dec 06 16:13:37 2003
Return-path: <[EMAIL PROTECTED]>
Received: from smtp-send.myrealbox.com [192.108.102.143] 
by master.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1ASjlA-0003EF-00; Sat, 06 Dec 2003 15:14:40 -0600
Received: from . [EMAIL PROTECTED] [213.177.147.33]
by smtp-send.myrealbox.com with NetMail SMTP Agent $Revision:   3.45  $ 
on Novell NetWare
via secured & encrypted transport (TLS);
Sat, 06 Dec 2003 14:14:40 -0700
From: cobaco <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [INTL:de] german po-debconf translation
Date: Sat, 6 Dec 2003 23:13:33 +0200
User-Agent: KMail/1.5.3
MIME-Version: 1.0
Content-Disposition: inline
Message-Id: <[EMAIL PROTECTED]>
Content-Description: clearsigned data
Cc: [EMAIL PROTECTED]
Content-Type: Multipart/Mixed;
  boundary="Boundary-00=_9Zk0/VIVNeN38VH"
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 
2.60-master.debian.org_2003_11_25-bugs.debian.org_2003_11_20 
(1.212-2003-09-23-exp) on master.debian.org
X-Spam-Status: No, hits=-3.0 required=4.0 tests=BAYES_99,DATING,HAS_PACKAGE 
autolearn=no 
version=2.60-master.debian.org_2003_11_25-bugs.debian.org_2003_11_20
X-Spam-Level: 


--Boundary-00=_9Zk0/VIVNeN38VH
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Description: clearsigned data
Content-Disposition: inline

=2DBEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Package: ksensors
Version: 0.7.2-7
Severity: wishlist
Tags: patch

Attached is the german po-debconf translation. This translation was done by=
=20
Pattrick William (patrick @ patrick-willam de), Tomas and Friedemann from=20
the german Skolelinux team.

Please add it to your next package revision, it should be inserted in your=
=20
package build-tree as debian/po/de.po, TIA.

=46eel free to mail me if this file needs updating at some future date (and=
=20
I'll pass it on to german team).
=2D --
Cheers, cobaco

/"\  ASCII Ribbon Campaign
\ /  No proprietary formats in attachments without request
 X   i.e. *NO* WORD, POWERPOINT or EXCEL documents
/ \  Respect Open Standards
  http://www.fsf.org/philosophy/no-word-attachments.html
  http://www.goldmark.org/netrants/no-word/attach.html






=2DBEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/0kZ95ihPJ4ZiSrsRAjMOAJ9vAL+gtEFqrVXqLughEJTqWYNKIACfTDLN
m18Hk9H+c91hLIeFCiBiypw=3D
=3DOfzS
=2DEND PGP SIGNATURE-

--Boundary-00=_9Zk0/VIVNeN38VH
Content-Type: application/x-gettext;
  name="de.po"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="de.po"

#
#Translators, if you are not familiar with the PO format, gettext
#documentation is worth reading, especially sections dedicated to
#this format, e.g. by running:
# info -n '(gettext)PO Files'
# info -n '(gettext)Header Entry'
#
#Some information specific to po-debconf are available at
#/usr/share/doc/po-debconf/README-trans
# or http://www.debian.org/intl/l10n/po-debconf/README-trans
#
#Developers do not need to manually edit POT or PO files.
#
msgid ""
msgstr ""
"Project-Id-Version: ksensors\n"
"POT-Creation-Date: 2003-03-04 22:06+0100\n"
"PO-Revision-Date: 2003-12-06 19:21+0100\n"
"Last-Translator: Patrick Willam <[EMAIL PROTECTED]>\n"
"Language-Team: skolelinux-germany <[EMAIL PROTECTED]>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=3Diso-8859-1\n"
"Content-Transfer-Encoding: 8bit\n"

#. Description
#: ../templates:3
msgid "Upgrading from a version prior to version 6.0"
msgstr "Upgraden von einer vorherigen Version zu Version 6.0"

#. Description
#: ../templates:3
msgid "Starting with version 6.0, KSensors support multiple lm-sensors chip=
s. Consequently, the format of KSensors configuration file (located in your=
 ~/.kde directory), has a little bit changed, thus you'll have to reconfigu=
re the sensors (name, min and max values, ...) in the configuration menu."
msgstr "Seit Version 6.0 unterst=FCtzt KSensors mehrere \"lm-sensors\"-Chip=
s. Infolgedessen hat sich das Format der KSensors-Konfigurationsdatei (lieg=
t

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

[Russell Coker]

On Sun, 7 Dec 2003 12:02, Chad Walstrom <[EMAIL PROTECTED]> wrote:
> That's sad.  initrd saved my bacon more than once. ;-)  If you like to

Initrd broke my systems more than once.

The recent versions of the package have significant problems if you want to 
convert to or from devfs.  The Debian mkinitrd has become too complex to 
manage so I have chosen not to bother.

> compile vanilla kernels, either find the Debian cramfs-initrd patch or
> use romfs.  Then change mkinitrd.conf(5) to look like this:
>
>   MKIMAGE="genromfs -d %s -f %s"

MKIMAGE='genromfs -f /dev/fd/1 -d %s | gzip -9 > %s'
The above is a better option.

> mkinitrd is pretty good about finding your required modules, but it
> sometimes doesn't get it right.  Always mount the romfs file and make
> sure the modules are there and will be loaded (/etc/modules).

I know, that's why I wrote a Perl script to get the right modules and also 
create a modules.dep file which has only the necessary data (attached).  This 
saves ~40k for modules.dep alone and much more by avoiding unneeded modules.

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


copy-needed-modules
Description: Perl program

Re: Building Debian Completely From Source

[Eric Wong]

John Goerzen <[EMAIL PROTECTED]> wrote:
> On Fri, Dec 05, 2003 at 05:48:21PM -0800, Eric Wong wrote:
> > apt-fu src-dist-upgrade
> 
> Excellent work!  *This* is what I have been searching for.  Plus, it
> seems to actually work! :-)

Cool, probably the best compliment I've received so far :)

> I have one feature request: I'd like to have an option so that I can ask
> it to rebuild arch-indep packages just like it rebuilds other packages.
> In other words, a "never download any .deb, ever" option :-)

Rebuilding arch-indep packages is no problem, and I'll gladly add an
option for that.  An option for 100% source packages will also be added,
but I'll also put a fat warning in there about circular dependencies.

> Oh, and a second feature request: how about uploading it to sid?  (If
> you're not a Debian developer, I'd gladly sponsor the upload.  You
> obviously know your way around the packaging system )

Awesome!  I've been wanting to start my road towards becoming a DD for
some time now.

> > Though it takes some configuring.
> 
> I'd like to be able to set that one, too...  just do the upgrade for all
> packages.  But that effect can be simulated now with dpkg
> --get-selections.

OK, I'll add an option for that.

> > apt-fu installs binary packages of build-depends first to avoid circular
> > build-dependencies, and then builds and installs the build-depends from
> > source if -R is specified.  It's a nasty problem but you can't have the
> > chicken without the egg, nor the egg without the chicken.
> 
> Yeah, I have found some of those circular build-deps.  I believe they
> should be considered serious bugs if they aren't already.  That's just
> wrong.  But in my case, I'd rather deal with the breakage manually than
> download the .deb.

OK, I'll do my best to have all the changes you requested done and
tested by tomorrow.  Let me know if you have any other feature requests
and/or bug reports.

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

Re: Intel f90 compiler for Debian.

[Matthias Urlichs]

Hi, Lukas Geyer wrote:

> As an
> aside, I don't quite understand why Fortran is still so popular in the
> numerical mathematics community... :)

There still are a lot of Fortran libraries which people are used to,
and they have been heavily optimized over the years.

The sad trutz is also that historically, since C is a language where any
pointer can point anywhere, some optimizations which are rather obvious in
Fortran compilers are difficult if not impossible in C. This has changed
somewhat (C99), but ...

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
Q.  What do Chtorrans call a Hollywood lawyer?
A.  Tough

Re: song

[Scott James Remnant]

On Sat, 2003-12-06 at 18:36, Scott James Remnant wrote:

> ObPrivate
> 
Total apologies here, especially to Matt Flax and Andreas Schuldei who
I've written to in separate mails.

I had no intention of mailing this to -devel (as you could probably
guess from the ObPrivate at the top).

I routinely remove all the To: and Cc: headers from mails and rewrite
them to ensure I don't Cc people and the mail goes to the right list,
and my brain utterly failed me and I must've written "debian-devel"
instead of "debian-private" in the To: line.

Entirely accidental, and I didn't even notice :-(

Sorry,

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



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

Re: debsums for maintainer scripts

[Goswin von Brederlow]

David Weinehall <[EMAIL PROTECTED]> writes:

> On Sat, Dec 06, 2003 at 01:24:58AM -0600, Manoj Srivastava wrote:
> > On Fri, 05 Dec 2003 13:34:10 -0500, Anthony DeRobertis <[EMAIL PROTECTED]> 
> > said: 
> > 
> > > On Thu, 2003-12-04 at 11:11, Manoj Srivastava wrote:
> > >> That is but one optimization: we already are suffering from archive
> > >> bloat, what about the disk and bandwidth cost of carrying around
> > >> the sigs?  And since one rarely needs the md5sums anyway, what is
> > >> so wrong with checking against the .deb when needed?
> > 
> > > I just took an md5sum of every file on my system. Including things
> > > like /var and /home that aren't part of packages. It's 13M,
> > > uncompressed.  Compressed, it's 3.5M.
> > 
> > > If we were really worried about archive size, an md5sum is 16
> > > octets.  It's hard to see that mattering to overall archive size.
> > 
> > I am (probably) getting a Zaurus for christmas this year. I
> >  would like to run Debian on it.  You think that the PDA has gobs of
> >  disk space to throw around?
> 
> udeb's would probably be better here anyway; the checksums is
> not the heaviest load on your Zaurus; dpkg itself, perl, glibc, etc will
> be.

udebs are neither updateable nor purgeable. They realy are not ment
for being installed on a real system.

A partial exclude for dpkg as wished for by many would be better. One
would tell dpkg to skip extracting /usr/share/doc on a Zaurus
probably.

MfG
Goswin

Re: Building Debian Completely From Source

[Goswin von Brederlow]

Roger Leigh <[EMAIL PROTECTED]> writes:

> Goswin von Brederlow <[EMAIL PROTECTED]> writes:
> 
> > Roger Leigh <[EMAIL PROTECTED]> writes:
> >> This sort of automated source building is a very good idea--it will
> >> root out a lot of build bugs, and will improve the quality of Debian.
> >
> > Thats whats autobuilders already do.
> 
> Do they ensure that you can *rebuild* from source, after the initial
> autobuild?  They can't ensure that woody or sarge can be built from
> the source.  If you took a woody distribution disc, and tried to build
> just using the binaries and source packages on the disc, you'd find
> many packages have become unbuildable.

Thought you ment just rebuilding of packages on a day to day basis. If
you follow sid by source you won#t have much difference to the
autobuilders. Upgrading by source from stable to the next stable or
rebuilding stable from source would be nice but due to lack of
resources I think thats never been done on any larger scale. It would
be nice if the faster archs would do a build of testing from scratch
of at least the base source package (skip OO, kde, gnome, just base +
build-essential + build-depends) say once a week on a rotating
schedule, i.e. 1. week i386, 2. week ia64, 3. week alpha, ...

MfG
Goswin

Re: Intel f90 compiler for Debian.

[Lukas Geyer]

Matthias Urlichs <[EMAIL PROTECTED]> writes:

> Hi, Lukas Geyer wrote:
> 
> > As an
> > aside, I don't quite understand why Fortran is still so popular in the
> > numerical mathematics community... :)
> 
> There still are a lot of Fortran libraries which people are used to,
> and they have been heavily optimized over the years.
> 
> The sad trutz is also that historically, since C is a language where any
> pointer can point anywhere, some optimizations which are rather obvious in
> Fortran compilers are difficult if not impossible in C. This has changed
> somewhat (C99), but ...

I thought that all or most of these libraries had C bindings in the
meantime. And for optimization purposes, it might not be as easy to do
in C, but there have always been options like -fstrict-aliasing and
such. However, that is probably not so much an issue if the C
functions are just wrappers for the Fortran library. People who want
the last percent in optimization would probably not use gcc anyway,
but some sort of vendor-optimized compiler for the respective
architecture they are using.

Lukas