Re: Dependencies on kernel-image-x.y [was: NPTL support in kernel 2.4 series]

[Antti-Juhani Kaijanaho]

On 20050122T161110+0100, Martin Kittel wrote:
> I would like to have some clarification on whether it is sensible to 
> declare a package dependency on kernel-image-x.y (e.g. kernel-image-2.6, 
> _not_ a full kernel version kernel-image-x.y.z)

No, it's not.  The job of a depends relation is to make sure that
another package is installed so that your package can link to the
library it contains, can refer to the files it contains or can execute
binaries it contains.  To make a depends on a kernel worth the while,
you'd need to be able to either link to the kernel, cause the kernel to
run or refer in some other way to the files a kernel package contains.
You can't link to a kernel and you can't cause it to run (except in an
emulator, and I doubt that'd be of any use to you).  And in this
particular case, you are not trying to access files in the kernel
package.  Therefore, a depends relation is not warranted.

> 1) it explicitely and visibly states the dependency that is inherent in 
> the package

The situation here is analoguous to the question whether an X
installation should depend on fonts: such a dependency would document
the dependency on inherent in X, yet we don't do that, because there are
reasonable setups of X where the fonts are provided outside the
packaging system's knowledge.

A Suggests or Recommends brings the same documentation value as a
Depends, and it will not force people to work around a packaging system
artefact.

> 2) the information the dependency provides is visible _before_ the 
> package is even downloaded

A package description is equally visible.

-- 
Antti-Juhani Kaijanaho, Debian developer 

http://kaijanaho.info/antti-juhani/blog/en/debian


signature.asc
Description: Digital signature

Bug#291796: ITP: planetpenguin-racer -- another 3D racing game featuring Tux, the Linux penguin

[Alexander Schmehl]

Package: wnpp
Severity: wishlist


* Package name: planetpenguin-racer
  Version : 0.2.3
  Upstream Author : planetpenguin.de Crew / Volker Stroebel <[EMAIL PROTECTED]>
* URL : http://projects.planetpenguin.de/racer/
* License : GPL
  Description : another 3D racing game featuring Tux, the Linux penguin

 PlanetPenguin Racer is a simple OpenGL racing game featuring Tux, the Linux
 mascot. The goal of the game is to slide down a snow- and ice-covered
 mountain as quickly as possible, avoiding the trees and rocks that will
 slow you down.
 .
 It is based on the GPL version of TuxRacer.


Oliver, as the current maintainer of tuxracer.  Would you like to
comment an my intentions?  Any hints or usefull suggestions?


Yours sincerely,
  Alexander


-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-1-686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Reboot in postinst

[Marc Haber]

On Fri, 21 Jan 2005 13:06:55 +0100, Andreas Barth
<[EMAIL PROTECTED]> wrote:
>I disagree. You should warn the administrator that he has to do that.
>Especially just restarting ssh is _very_ wrong IMHO, because it can
>easily kill the only access to a remote computer. Take a look how glibc
>does it, that's fine IMHO.

I haven't been asked to re-start any services by glibc updates for
quite some time, and back in the days when glibc asked to restart
services, it always failed.

So, rebooting seems to be the only way to be sure after a library
update.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Reboot in postinst

[Marc Haber]

On Fri, 21 Jan 2005 13:34:51 -0500, Joey Hess <[EMAIL PROTECTED]>
wrote:
>Roberto Sanchez wrote:
>> If the system is that important to the admin, he will pay attention to such
>> things.  Imagine that you are upgrading ssh for some security update over the
>> weekend.  If your system is in some colo or other remote location where you
>> are unable to access it until Monday morning, then you have a problem if ssh
>> dies on you.
>
>If your system is in a colo, it would be wise to have a backup login
>method besides ssh.

At least in Germany, cheap colocated servers for about $40 a month
(including hardware rent, colo space, power and net) are
state-of-the-art at the moment. Having a serial console is pretty
exotic with these servers. Usually the most you get is a remote power
cycle facility and some rescue system which can be bootet over the
network.

Greetins
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: not starting packages at boot

[Marc Haber]

On Sat, 22 Jan 2005 18:44:16 -0800, Steve Langasek <[EMAIL PROTECTED]>
wrote:
>I hope that at least the cupsys maintainer will close this bug without
>mangling the package in this fashion; there's no reason to have the cupsys
>server package installed if you're not going to use it as a server.

I disagree. I have a number of server packages installed on my
personal laptop for the sake of having the docs with me. I am,
however, fine with using update-rc.d or $EDITOR /etc/runlevel.conf[1]
to accomplish this.

My beef is that I want to be able to prevent a newly installed
package's postinst from starting the service (for example, because I
know that the service needs configuration before it can be started for
the first time, or because I know that this service is probably never
going to run on this installation).

Greetings
Marc

[1] Thanks, Roland, for file-rc, which is really great

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: not starting packages at boot

[Michal Politowski]

On Sun, 23 Jan 2005 10:38:20 +0100, Marc Haber wrote:
[...]
> My beef is that I want to be able to prevent a newly installed
> package's postinst from starting the service

Looks like something invoke-rc.d calls policy-rc.d for.

> (for example, because I
> know that the service needs configuration before it can be started for
> the first time, or because I know that this service is probably never
> going to run on this installation).

-- 
Michał Politowski
Talking has been known to lead to communication if practised carelessly.


signature.asc
Description: Digital signature

Re: not starting packages at boot

[Goswin von Brederlow]

Marc Haber <[EMAIL PROTECTED]> writes:

> On Sat, 22 Jan 2005 18:44:16 -0800, Steve Langasek <[EMAIL PROTECTED]>
> wrote:
>>I hope that at least the cupsys maintainer will close this bug without
>>mangling the package in this fashion; there's no reason to have the cupsys
>>server package installed if you're not going to use it as a server.
>
> I disagree. I have a number of server packages installed on my
> personal laptop for the sake of having the docs with me. I am,
> however, fine with using update-rc.d or $EDITOR /etc/runlevel.conf[1]
> to accomplish this.
>
> My beef is that I want to be able to prevent a newly installed
> package's postinst from starting the service (for example, because I
> know that the service needs configuration before it can be started for
> the first time, or because I know that this service is probably never
> going to run on this installation).
>
> Greetings
> Marc
>
> [1] Thanks, Roland, for file-rc, which is really great

Chroots also nearly never want to start services and it would be nice
fi there were a consistent way to stop daemons from getting started
(stoped on upgrade) on install there.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: not starting packages at boot

[Steve Langasek]

On Sun, Jan 23, 2005 at 11:10:37AM +0100, Goswin von Brederlow wrote:
> Marc Haber <[EMAIL PROTECTED]> writes:

> > On Sat, 22 Jan 2005 18:44:16 -0800, Steve Langasek <[EMAIL PROTECTED]>
> > wrote:
> >>I hope that at least the cupsys maintainer will close this bug without
> >>mangling the package in this fashion; there's no reason to have the cupsys
> >>server package installed if you're not going to use it as a server.
> >
> > I disagree. I have a number of server packages installed on my
> > personal laptop for the sake of having the docs with me. I am,
> > however, fine with using update-rc.d or $EDITOR /etc/runlevel.conf[1]
> > to accomplish this.
> >
> > My beef is that I want to be able to prevent a newly installed
> > package's postinst from starting the service (for example, because I
> > know that the service needs configuration before it can be started for
> > the first time, or because I know that this service is probably never
> > going to run on this installation).
> >
> > Greetings
> > Marc

> > [1] Thanks, Roland, for file-rc, which is really great

> Chroots also nearly never want to start services and it would be nice
> fi there were a consistent way to stop daemons from getting started
> (stoped on upgrade) on install there.

echo -e '#!/bin/sh\n\nexit 101' > /chroot/usr/sbin/policy-rc.d \
&& chmod a+x /chroot/usr/sbin/policy-rc.d

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Do all frontends use the dpkg binary?

[Kevin Mark]

Hi DD folken,
I simple question.

In my quest to log package installation, I wrote a wrapper script for
dpkg. I 'mv dpkg dpkg.real' and 'vi dpkg' with a wrapper[0]. When I use
aptitude and apt-get, these commands seem to call dpkg for all of there
package installation and query needs. Do others (wajig,feta,...)
use '/usr/bin/dpkg' for installing packages or do they use a library?
obviously if they do, then my script will not log everything.

Also, is there a way to avoid a dpkg upgrade overwriting /usr/bin/dpkg
and (IIRC) divert /usr/bin/dpkg -> /usr/bin/dpkg.real, so that I dont
have to remember to redo this step?

with red swirly regards,
-Kev

[0] script
--
#!/bin/sh
if [ -w /var/log/dpkg.log ]; then
echo "$(date) dpkg $@" >> /var/log/dpkg.log
fi
dpkg.real $@
--
-- 
counter.li.org #238656 -- goto counter.li.org and be counted!

(__)
(oo)
  /--\/
 / |||
*  /\---/\
   ~~   ~~
"Have you mooed today?"...


signature.asc
Description: Digital signature

Re: Do all frontends use the dpkg binary?

[Matthew Palmer]

On Sun, Jan 23, 2005 at 05:21:02AM -0500, Kevin Mark wrote:
> Also, is there a way to avoid a dpkg upgrade overwriting /usr/bin/dpkg
> and (IIRC) divert /usr/bin/dpkg -> /usr/bin/dpkg.real, so that I dont
> have to remember to redo this step?

man dpkg-divert

It rocks.  Hard.

- Matt


signature.asc
Description: Digital signature

Re: Reboot in postinst

[Wouter Verhelst]

Op zo, 23-01-2005 te 10:30 +0100, schreef Marc Haber:
> I haven't been asked to re-start any services by glibc updates for
> quite some time, and back in the days when glibc asked to restart
> services, it always failed.
> 
> So, rebooting seems to be the only way to be sure after a library
> update.

lsof +L 1

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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: not starting packages at boot

[Thomas Hood]

On Sun, 23 Jan 2005 03:00:27 +0100, Dan Jacobson wrote:
> Now that maintainers realized that one might like a package installed,
> but perhaps only plans to use it unoften, it only makes sense for not
> starting at boot to be offered as a friendly configuration option,
> instead of needing some devious guerilla techniques to thwart the
> packages starting.


apt-get install sysv-rc-conf.

-- 
Thomas Hood


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: not starting packages at boot

[Thomas Hood]

On Sun, 23 Jan 2005 10:40:08 +0100, Marc Haber wrote in part:
> Ihave a number of server packages installed on my
> personal laptop for the sake of having the docs with me. I am,
> however, fine with using update-rc.d or $EDITOR /etc/runlevel.conf[1]
> to accomplish this.


In some cases this might be grounds for wishing that the docs
be split off into a separate package.  Another solution is to
"dpkg -x" the package into the directory of your choice and
to peruse the docs in there.  Of course, neither of these is
completely convenient.  If one really wants the package to be
installed but deactivated then he can install it and disable
it using sysv-rc-conf.

I agree that sysv-rc-conf leaves something to be desired.  It
would really be much better if there were a reliable way of
restoring a service's runlevel settings to their "factory
defaults" -- i.e. to what the package postinst set them to.

This could be implemented by changing update-rc.d so that it
recorded these settings somewhere; the information could later
be used to restore the service's runlevel settings to their
factory defaults.  I have written about this in #183460 and
#237379.  This feature is also needed so that maintainer
scripts can change runlevel configuration iff they haven't
been changed by the user.

-- 
Thomas Hood


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: initrd, lvm, and devfs

[Russell Coker]

On Tuesday 18 January 2005 09:03, Brian May <[EMAIL PROTECTED]> wrote:
> I guess this means sarge won't work "out-of-the-box" with 2.6.11 and
> LVM unless you compile your own kernel (one that doesn't require an
> initrd image), or fix this initrd image.

LVM root can not work without using an initrd to scan for volumes.

LVM for non-root when the root file system is on a regular partition is not 
relevant to this discussion.  It is totally independent of the initrd.

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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Do all frontends use the dpkg binary?

[Kevin Mark]

On Sun, Jan 23, 2005 at 09:22:36PM +1100, Matthew Palmer wrote:
> On Sun, Jan 23, 2005 at 05:21:02AM -0500, Kevin Mark wrote:
> > Also, is there a way to avoid a dpkg upgrade overwriting /usr/bin/dpkg
> > and (IIRC) divert /usr/bin/dpkg -> /usr/bin/dpkg.real, so that I dont
> > have to remember to redo this step?
> 
> man dpkg-divert
> 
> It rocks.  Hard.
> 
> - Matt
Hi Matt,
I thought it was the way but wasnt sure. The man page is a little
skimpy. I did not help. But google found IIRC a debian-*-manual entry.
So: dpkg-divert --package dpkg --add --rename --divert \
/usr/bin/dpkg.real /usr/bin/dpkg did the trick!
Cheers!
-Kev
-- 
counter.li.org #238656 -- goto counter.li.org and be counted!

(__)
(oo)
  /--\/
 / |||
*  /\---/\
   ~~   ~~
"Have you mooed today?"...


signature.asc
Description: Digital signature

Re: Dependencies on kernel-image-x.y [was: NPTL support in kernel 2.4 series]

[Martin Kittel]

Antti-Juhani Kaijanaho  debian.org> writes:
> 
> The situation here is analoguous to the question whether an X
> installation should depend on fonts: such a dependency would document
> the dependency on inherent in X, yet we don't do that, because there are
> reasonable setups of X where the fonts are provided outside the
> packaging system's knowledge.

Ok, it seems I had a much stricter idea of what should be under the
control of the package management system than is accepted practice in
debian. I am now realizing that kernel packages are not the only
thing that need not register with dpkg.

Thanks for the clarification.

Martin.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ITP: backgrounds-debian-shell -- Photography of shells aligned to form the Debian logo

[Gürkan Sengün]

> > * Package name: backgrounds-debian-shell
> >   Version : 1.0
> >   Upstream Author : Jakub Budziszewski <[EMAIL PROTECTED]>
> > * URL : http://linuks.mine.nu/jakub/
> > * License : Artistic License
> >   Description : Photography of shells aligned to form the Debian logo
> >  A photography that consists of shells aligned to form the
> >  Debian logo.
> 
> A package for a single background is a remarkably stupid idea. This
> should go in desktop-base.

Hello Colin,

Can you put only the one large image into desktop-base please?

I have backgrounds-debian-shell packaged already including all info,
tell me if you need it, it installs into /usr/share/backgrounds/debian-shell/

Yours,
Gürkan

Re: Dependencies on kernel-image-x.y [was: NPTL support in kernel 2.4 series]

[Andreas Metzler]

On 2005-01-22 Martin Kittel <[EMAIL PROTECTED]> wrote:
[...]
> B) most people compile their own kernels and don't bother registering 
> those with dpkg, e.g. via kernel-package, and therefore their systems, 
> -while actually running a suitable kernel- do not provide the required 
> virtual package.

> With A) I absolutely agree, but I think B) is not a valid objection to 
> having a dependency on kernel-image-x.y, especially since it is very 
> easy to create a custom kernel package with kernel-package. Also the 
> reasoning of B) could be applied to any package, starting with 
> java2-runtime and then going all the way to libc.
[...]

Hello,
Which is exactly why I did not tell you "most people compile their
own kernels with make install", but "installing their own kernels with
make install is traditionally accepted practice." Other people told you
the same thing.
http://lists.debian.org/debian-devel/2005/01/msg01261.html

 cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"
   http://downhill.aus.cc/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Please test exim4 4.44-1 (linked against db4.2) in experimental

[Marc Haber]

Hi,

exim4 4.44-1 has been uploaded to experimental. This is the first
package version of exim4 to be linked against db4.2, which is a good
thing for d-i.

The exim4 maintainers consider to upload this package for sid and
sarge. For this to happen, we need testing.

I would like to invite all readers to test exim4 4.44, which can be
downloaded from the experimental distribution. We would like to have
broader testing before uploading to sid and asking the release team to
hint 4.44-1 into sarge.

If the experimental phase does not uncover any bad bugs, a nearly
identical version is scheduled to be uploaded to unstable on Thursday,
2005-01-27.

Thanks for your consideration.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: hwcap supporting architectures?

[Junichi Uekawa]

Hi,

>  Before asking here I went thru several mailing list archives.  What I
>  found was a general argument along the lines of "don't add _that_ hwcap
>  because that will increase the size of the list of paths that you have
>  to stat(2) in order to find the library and that's slow".  In
>  particular upstream doesn't seem to like the idea much.  I just can't
>  find the reason why they think the stat(2) call is _so_ expensive that
>  it will hurt system performance.  There was some mention of a glib
>  issue with plugins.  I couldn't find further data points on that...

The main problem with adding hwcap is that the number of directory 
to be traversed doubles with every addition, which is an 
exponential thing; rather than something linear.

Looking at the rate of hardware changes, we will ideally be wanting
to add a new hwcap entry just about every year;
which results roughly in x10 time penalty every 3 years.

> What that means is that you need to make about 2000 stat(2) calls to
> get _anywhere_ near what's measurable by a human and about 2 to
> start getting said human annoyed.

Which will be reachable within 10 or 20 years of time.

Thus, to be realistic, a linear or O(1) scheme, or some kind of 
library path caching scheme is required; time to do some coding?




Ref:

Having a hwcap of 'a' and 'b' and 'c' requires lookup of 

a/
a/b/
a/b/c
a/c/
b/
b/c
c/


Having a hwcap of 'a' and 'b' and 'c' and 'd' requires lookup of 

a/
a/b/
a/b/c
a/c/
b/
b/c
c/
a/d
a/b/d
a/b/c/d
a/c/d
b/d
b/c/d
c/d
d

regards,
junichi


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Do all frontends use the dpkg binary?

[Adeodato Simó]

* Kevin Mark [Sun, 23 Jan 2005 07:37:57 -0500]:

> So: dpkg-divert --package dpkg --add --rename --divert \
> /usr/bin/dpkg.real /usr/bin/dpkg did the trick!

  Uhm, I think you want to carefully read the --package option
  description in the man page. And then, check --local.

-- 
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
Listening to: Tamara - Será la última vez
 
There is no man so good who, were he to submit all his thoughts to the
laws, would not deserve hanging ten times in his life
-- Michel de Montaigne


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ${lib}-dev, .pc and pkg-config

[Artur R. Czechowski]

On Sun, Jan 23, 2005 at 05:49:22AM +0900, Junichi Uekawa wrote:
> I've checked the libpkg guide, and I found a chapter called 
> 'Annotated list of files that usually reside in -dev package'
> which contains reference to pkgconfig.
Hell, right. I was looking for string "pkg-config" and I didn't find it.
Could you correct it, please?

> What is it that you would request in addition?
What would you say about note like this one (base on Rene's email).

Should I add *.pc files in -dev package?

If upstream provides such files the answer is: yes, you should.
Otherwise, if there's no -I and -L needed, it isn't necessary, but when
either of them is needed, you are recommended to create one, unless there is
an old-style foo-config.

Cheers
Artur
-- 
meine trabant ist fantastik, zwei cylinder und nur plastik


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: not starting packages at boot

[Steve Greenland]

On 20-Jan-05, 22:09 (CST), Dan Jacobson <[EMAIL PROTECTED]> wrote: 
> Sure, one can go behind the backs of maintainers with
> > http://www.debian.org/doc/manuals/securing-debian-howto/ch3.en.html#s3.6
> > ("Disabling daemon services")
> and hope you remember what you did. But it's not as friendly as
> the approaches more and more packages are taking, as seen in my /var/log/boot:

There is nothing more unfriendly than having 

   '/etc/init.d/foo start' 

fail because because of some non-standard bit of crap in
/etc/default/foo. I could tolerate it if packaged defaulted *on*, but it
seems the habit is to default off. And more importangly, as others have
said (every single time this comes up), there is an *existing* mechanism
to accomplish this that doesn't require modifying every daemon package:
invoke-rc.d and policy-rc.d.


Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Do all frontends use the dpkg binary?

[Christoph Berg]

Re: Kevin Mark in <[EMAIL PROTECTED]>
> In my quest to log package installation, I wrote a wrapper script for
> dpkg.

$ tail -1 /etc/apt/apt.conf
DPkg::Pre-Install-Pkgs {"logger -t DPkg::Pre-Install-Pkgs";};

Christoph
-- 
[EMAIL PROTECTED] | http://www.df7cb.de/


signature.asc
Description: Digital signature

Re: Do all frontends use the dpkg binary?

[Bartosz Fenski aka fEnIo]

On Sun, Jan 23, 2005 at 06:11:42PM +0100, Christoph Berg wrote:
> > In my quest to log package installation, I wrote a wrapper script for
> > dpkg.
> 
> $ tail -1 /etc/apt/apt.conf
> DPkg::Pre-Install-Pkgs {"logger -t DPkg::Pre-Install-Pkgs";};

I wonder if it would be possible to set is as default behaviour along with
some logrotate scripts. Users quite often ask where are dpkg's actions
logged so I think this would be good idea.

Or at least we could ask using debconf if they want to log its tasks.

regards
fEnIo

-- 
  _  Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | IRC:fEnIo
_|_|_ 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Polska
(0 0)phone:+48602383548 | proud Debian maintainer and user
ooO--(_)--Ooo  http://skawina.eu.org | JID:[EMAIL PROTECTED] | RLU:172001


signature.asc
Description: Digital signature

Re: hwcap supporting architectures?

[Bernd Eckenfels]

On Mon, Jan 24, 2005 at 01:16:12AM +0900, Junichi Uekawa wrote:
> Looking at the rate of hardware changes, we will ideally be wanting
> to add a new hwcap entry just about every year;
> which results roughly in x10 time penalty every 3 years.

BTW: I wonder why hwcap decisions are not cached in the ld.so.cache?

Greetings
Bernd
-- 
  (OO)  -- [EMAIL PROTECTED] --
 ( .. )  [EMAIL PROTECTED],linux.de,debian.org}  http://www.eckes.org/
  o--o 1024D/E383CD7E  [EMAIL PROTECTED]  v:+497211603874  f:+497211606754
(OO)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Trying to come back...

[Nicolás Lichtmaier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi. I was once a Debian developer. Perhaps some of you remember my
name =) . I'd like to go back maintaining just one or two packages.
How should I do?
I've checked debian-keyring's changelog and I seem to have been marked
as "emeritus":
~  Emeritus \E*mer"i*tus\, n.; pl. {Emeriti}. [L.]
~ A veteran who has honorably completed his service.
I certainly appreciate such an honorable title (!), but is there any
way of coming back from there? (I've already tried emailing
[EMAIL PROTECTED])
I have a new GPG key, the old one was an old pgp2 style one (yes, it
was that long). I've signed the new one with the new one, but I needed
to manually compile an "IDEA" plugin for gpg. I don't know if such
plugin would also be needed for checking the key (IIRC the IDEA
algorithm was used just for message encrypting).
Many thanks!
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB8+Gb8cB4mNZ3qFwRAhCrAJ0f/4nz96U9Unli9HZknCOJSFQemACggTQS
zkNyQ8EJnR7YfWxzjiqKG5Y=
=guqs
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Do all frontends use the dpkg binary?

[Tollef Fog Heen]

* Kevin Mark 

| In my quest to log package installation, I wrote a wrapper script for
| dpkg. I 'mv dpkg dpkg.real' and 'vi dpkg' with a wrapper[0]. When I use
| aptitude and apt-get, these commands seem to call dpkg for all of there
| package installation and query needs. Do others (wajig,feta,...)
| use '/usr/bin/dpkg' for installing packages or do they use a library?

There is no libdpkg yet, so they all use the dpkg binary.  If not,
they are messing around with dpkg's internal data, something which
they shouldn't.

| Also, is there a way to avoid a dpkg upgrade overwriting /usr/bin/dpkg
| and (IIRC) divert /usr/bin/dpkg -> /usr/bin/dpkg.real, so that I dont
| have to remember to redo this step?

dpkg-divert, as others have said.

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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Trying to come back...

[Tollef Fog Heen]

* Nicolás Lichtmaier 

| Hi. I was once a Debian developer. Perhaps some of you remember my
| name =) . I'd like to go back maintaining just one or two packages.
| How should I do?

http://lists.debian.org/debian-devel-announce/2003/05/msg6.html

Welcome back!

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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

More on icons for packages

[Dale C. Scheetz]

Well, I finally found some documentation on icons in menu
specifications. What it says is pretty specific and goes against what I
found when I looked at actual packages.

1. the documentation says all icons go into /usr/share/pixmaps and

2. all menu icons should be 32x32 pixels and be in xpm format.

But, when I looked at several packages, many put their icons in
/usr/share/package-name/icons/ and very few actually use 32x32 for their
size even when they are placed in /usr/share/pixmaps/.

This document is only indirectly referenced in the policy manual, so it
isn't clear how much force it has. (it could be taken as the mearest
suggestion by the menu package maintainer)

/usr/share/pixmaps has lots of png files and many images are larger than
32x32.

Are these issues that should be resolved with bug reports?

With regards to GNOME panel icons. The "add to panel" option now no
longer offers "launcher from menu" so now with the "custom launcer" you
have to hunt for your icon. The default place to look is
/usr/share/pixmaps, so it would be user helpful to have all icons in
that location instead of requiring a hunt through all the other
possibilities when you don't find the icon you are looking for.

Personally I like larger than 32x32 icons for the panel because icons
are scaled to fit the panel so fairly large ones give much cleaner
detail when scaled to fit.

In any case I would like to see this floating document become an actual
part of the policy manual. It contains the implimentation details that
someone with questions really needs to see up front, not tucked away in
a specific package document outside the Policy Manual.

Any ideas?

Waiting is,

Dwarf


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: not starting packages at boot

[Mark Brown]

On Sun, Jan 23, 2005 at 10:53:48AM -0600, Steve Greenland wrote:

> /etc/default/foo. I could tolerate it if packaged defaulted *on*, but it
> seems the habit is to default off. And more importangly, as others have
> said (every single time this comes up), there is an *existing* mechanism
> to accomplish this that doesn't require modifying every daemon package:
> invoke-rc.d and policy-rc.d.

The main case where this sort of thing is useful is the case where the
package can't be shipped with a sane default configuration for some
reason and the init script can't detect this situation.

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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: More on icons for packages

[Bill Allombert]

On Sun, Jan 23, 2005 at 07:35:42PM -0500, Dale C. Scheetz wrote:
> Well, I finally found some documentation on icons in menu
> specifications. What it says is pretty specific and goes against what I
> found when I looked at actual packages.
> 
> 1. the documentation says all icons go into /usr/share/pixmaps and
> 
> 2. all menu icons should be 32x32 pixels and be in xpm format.

3 points:

Your quote is an extract from the Debian menu manual

or 


1) this is only for icons used in menu file for the Debian menu
systems. Icons used by window managers and files managers are a completly 
different business.

2) It says _at most_ 32x32 pixels. 

> But, when I looked at several packages, many put their icons in
> /usr/share/package-name/icons/ and very few actually use 32x32 for their
> size even when they are placed in /usr/share/pixmaps/.
> 
> This document is only indirectly referenced in the policy manual, so it
> isn't clear how much force it has. (it could be taken as the mearest
> suggestion by the menu package maintainer)
> 
> /usr/share/pixmaps has lots of png files and many images are larger than
> 32x32.
> 
> Are these issues that should be resolved with bug reports?

At least, they are flagged as bugs by lintian:



I try to get as much menu related bugs as I can, but I don't get much
support.

> With regards to GNOME panel icons. The "add to panel" option now no
> longer offers "launcher from menu" so now with the "custom launcer" you
> have to hunt for your icon. The default place to look is
> /usr/share/pixmaps, so it would be user helpful to have all icons in
> that location instead of requiring a hunt through all the other
> possibilities when you don't find the icon you are looking for.
> 
> Personally I like larger than 32x32 icons for the panel because icons
> are scaled to fit the panel so fairly large ones give much cleaner
> detail when scaled to fit.

The menu manual is only relevant for icons part of the window-managers
menu, not GNOME panel icons.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Unofficial php5 5.0.3

[Danyi Dávid]

Hi.
I've checked out the packages, and was about to play around with php5 a little, when I got into a little problem.
Fatal error: Call to undefined function ldap_start_tls() in test_ldap_tls.php on line 14
I have the php5-ldap module loaded and running, as well as php5-openssl, both 
the latest versions (5.0.3-0.5) as of now.
I just don't know if the problem is with my settings, all I found in php5 
source is that the ldap module
won't have this function unless the LDAP api version is greater than 2000.
Please check it out if you have the time.
Thanks a lot.

Hi.
I've uploaded fresh php5 5.0.3 packages:
deb http://people.debian.org/~dexter  php5 
sid
deb-src http://people.debian.org/~dexter  
php5 sid
This version introduces php5-modconf tool which is based on apache-modconf. 
The tool handles "extensions=" lines in php.ini file and restarts the web 
server if it is necessary.

Have a good fun.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: not starting packages at boot

[Andrew Pollock]

On Sun, Jan 23, 2005 at 10:53:48AM -0600, Steve Greenland wrote:
> On 20-Jan-05, 22:09 (CST), Dan Jacobson <[EMAIL PROTECTED]> wrote: 
> > Sure, one can go behind the backs of maintainers with
> > > http://www.debian.org/doc/manuals/securing-debian-howto/ch3.en.html#s3.6
> > > ("Disabling daemon services")
> > and hope you remember what you did. But it's not as friendly as
> > the approaches more and more packages are taking, as seen in my 
> > /var/log/boot:
> 
> There is nothing more unfriendly than having 
> 
>'/etc/init.d/foo start' 
> 
> fail because because of some non-standard bit of crap in
> /etc/default/foo. I could tolerate it if packaged defaulted *on*, but it
> seems the habit is to default off. And more importangly, as others have
> said (every single time this comes up), there is an *existing* mechanism
> to accomplish this that doesn't require modifying every daemon package:
> invoke-rc.d and policy-rc.d.
> 

Amen. I found this with distcc the other day. I had to dpkg-reconfigure it
and answer yes to starting it on boot to be able to start it manually via
/etc/init.d

It almost needs to be a question as to whether you want the start link in
/etc/rc?.d/

regards

Andrew

-- 
linux.conf.au 2005   -  http://linux.conf.au/  -  Birthplace of Tux
April 18th to 23rd   -  http://linux.conf.au/  -   LINUX
Canberra, Australia  -  http://linux.conf.au/  -Get bitten!


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Fwd: Re: status of the DDTP project?]

[Daniel Macêdo Batista]

Thanks for the informatino Tobias! The braziliam team is already using
the new email address, but unhappily there are problems yet:

- The DDTP server is with a long delay to send out the replies. Sometimes
the reply come in a lot of hours.

- The coordination of the brazilian team changed since october/2004. The
last coordinator was Fred Maranhao, and I'm the new coordinator. This
change demands modifications in the DDTP server to allow that I run
exclusive commands to coordinators. Theses modifications are pending and
this is harming the coordination.

Can, the person that created the [EMAIL PROTECTED], resolve the two problems
listed above?

[]'s

Em 20/1/2005, "Tobias Toedter" <[EMAIL PROTECTED]> escreveu:

...
>
>Hi,
>
>it seems that the problems with [EMAIL PROTECTED] aren't resolved just yet. 
>However, if you use [EMAIL PROTECTED] instead, the server sends out 
>replies. You'll get the normal feedback, and it looks like the processing 
>of incoming mails succeeds.
>
>Cheers,
>
>-- 
>
>Tobias
>
>Early to bed and early to rise and you'll
>be groggy when everyone else is wide awake.

--
Daniel Macêdo Batista
[EMAIL PROTECTED], http://www.ic.unicamp.br/~ra030022
Mestrando em Ciência da Computação pela Unicamp
   .-.
  .''`./v\G N U / L I N U X
 : :'  :  // \\  >Não tenha medo do pinguim<
 `. `'`  /(   )\
   `- ^^-^^

Re: Trying to come back...

[Matthew Palmer]

On Sun, Jan 23, 2005 at 02:40:43PM -0300, Nicol?s Lichtmaier wrote:
> I've checked debian-keyring's changelog and I seem to have been marked
> as "emeritus":
> 
> ~  Emeritus \E*mer"i*tus\, n.; pl. {Emeriti}. [L.]
> ~ A veteran who has honorably completed his service.
> 
> I certainly appreciate such an honorable title (!), but is there any
> way of coming back from there? (I've already tried emailing
> [EMAIL PROTECTED])

Have a look at the post from James Troup on the subject of different
developer states,
http://lists.debian.org/debian-devel-announce/2003/05/msg6.html.  Should
explain most of your questions.

- Matt


signature.asc
Description: Digital signature

Re: Release update: kde3.3, upload targets, kernels, infrastructure

[Henning Makholm]

Scripsit Geoff Bagley <[EMAIL PROTECTED]>

> Is it possible to transfer some of the packages, a few at a time,
> over into Woody, so that when we all change to Sarge, the servers
> will not suffer from too heavy an overload ?

That would be a recipe for disaster. In no particular order:

* It would make it impossible to keep runing woody. Believe it or not,
  some sysadmins who run stable because they want stability will not
  have the time to drop everything and start babysitting their local
  scripts and configuration for upgrade pains at the random moment
  that the release team declares sarge to be stable. For the same
  reason, security support for woody is expected to last for at least
  several months after the release.

* When sarge becomes stable, its packages will have proved themselves
  to be (relatively) bug-free and well-integrated *as an ensemble*.
  There has been no widespread testing of systems with particular
  combinations of packages from woody and ones from sarge. It is
  likely that if the release team just picks a series of random
  untested package combinations, something *will* break
  catastrophically. Not anything we want to happen to stable systems.

Yes, some people will start upgrading immediately after sarge
releases, but I think most of the people who have a clue (the really
clueless ones just run sarge already because Old Software Is Bad )
will either defer upgrading until they have the time to do so at their
own leisure, or decide to migrate early at some time after security
support for sarge is announced.

The few who think that the precise release date signifies an instant
shift in the relative attractiveness of running woody vs. sarge will
just have to put up with loaded mirrors for a couple of days.

-- 
Henning Makholm"*Vi vil ha wienerbrød!*"

Re: not starting packages at boot

[Steve Greenland]

On 23-Jan-05, 14:05 (CST), Mark Brown <[EMAIL PROTECTED]> wrote: 
> On Sun, Jan 23, 2005 at 10:53:48AM -0600, Steve Greenland wrote:
> 
> > /etc/default/foo. I could tolerate it if packaged defaulted *on*, but it
> > seems the habit is to default off. And more importangly, as others have
> > said (every single time this comes up), there is an *existing* mechanism
> > to accomplish this that doesn't require modifying every daemon package:
> > invoke-rc.d and policy-rc.d.
> 
> The main case where this sort of thing is useful is the case where the
> package can't be shipped with a sane default configuration for some
> reason and the init script can't detect this situation.

But it seems to be used far more often than in that case.

Besides, IMO, '/etc/init.d/foo start' should *always* attempt 
to start the daemon if foo isn't running.

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Do all frontends use the dpkg binary?

[Scott James Remnant]

On Sun, 2005-01-23 at 18:19 +0100, Bartosz Fenski aka fEnIo wrote:

> On Sun, Jan 23, 2005 at 06:11:42PM +0100, Christoph Berg wrote:
> > > In my quest to log package installation, I wrote a wrapper script for
> > > dpkg.
> > 
> > $ tail -1 /etc/apt/apt.conf
> > DPkg::Pre-Install-Pkgs {"logger -t DPkg::Pre-Install-Pkgs";};
> 
> I wonder if it would be possible to set is as default behaviour along with
> some logrotate scripts. Users quite often ask where are dpkg's actions
> logged so I think this would be good idea.
> 
This would mean the disk would gradually fill up with logs, unless you
rotated them; which seems to defeat the use case everybody has given for
dpkg's actions being logged in the first place.

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: Trying to come back...

[Nicolás Lichtmaier]

I've checked debian-keyring's changelog and I seem to have been marked
as "emeritus":

Have a look at the post from James Troup on the subject of different
developer states,
http://lists.debian.org/debian-devel-announce/2003/05/msg6.html.  Should
explain most of your questions.

Yes, thanks. I've been already pointed at that message. =)


signature.asc
Description: OpenPGP digital signature

Re: More on icons for packages

[Dale C. Scheetz]

I understand your point about this document only applying to menus. My point 
was that this is the only documentation I can find on icons, and gnome has 
changed how it mounts programs on panels so I'm still running on empty as far 
as directions on proper behavior. Many of the icons that gnome has used in the 
past seem to reside in /usr/share/pixmaps so there seems to be some consensus 
on this location as a proper storage location.

I've been with Debian for a long time and it seems that consistancy is our most 
difficult product to impliment. Lintian is a great help in this maintenance 
but...

Thanks for the feedback. Any pointers to other docs would be useful...

Luck,

Dwarf

On Sun, 23 Jan 2005 21:20:44 +0100
Bill Allombert <[EMAIL PROTECTED]> wrote:

> On Sun, Jan 23, 2005 at 07:35:42PM -0500, Dale C. Scheetz wrote:
> > Well, I finally found some documentation on icons in menu
> > specifications. What it says is pretty specific and goes against what I
> > found when I looked at actual packages.
> > 
> > 1. the documentation says all icons go into /usr/share/pixmaps and
> > 
> > 2. all menu icons should be 32x32 pixels and be in xpm format.
> 
> 3 points:
> 
> Your quote is an extract from the Debian menu manual
> 
> or 
> 
> 
> 1) this is only for icons used in menu file for the Debian menu
> systems. Icons used by window managers and files managers are a completly 
> different business.
> 
> 2) It says _at most_ 32x32 pixels. 
> 
> > But, when I looked at several packages, many put their icons in
> > /usr/share/package-name/icons/ and very few actually use 32x32 for their
> > size even when they are placed in /usr/share/pixmaps/.
> > 
> > This document is only indirectly referenced in the policy manual, so it
> > isn't clear how much force it has. (it could be taken as the mearest
> > suggestion by the menu package maintainer)
> > 
> > /usr/share/pixmaps has lots of png files and many images are larger than
> > 32x32.
> > 
> > Are these issues that should be resolved with bug reports?
> 
> At least, they are flagged as bugs by lintian:
> 
> 
> 
> I try to get as much menu related bugs as I can, but I don't get much
> support.
> 
> > With regards to GNOME panel icons. The "add to panel" option now no
> > longer offers "launcher from menu" so now with the "custom launcer" you
> > have to hunt for your icon. The default place to look is
> > /usr/share/pixmaps, so it would be user helpful to have all icons in
> > that location instead of requiring a hunt through all the other
> > possibilities when you don't find the icon you are looking for.
> > 
> > Personally I like larger than 32x32 icons for the panel because icons
> > are scaled to fit the panel so fairly large ones give much cleaner
> > detail when scaled to fit.
> 
> The menu manual is only relevant for icons part of the window-managers
> menu, not GNOME panel icons.
> 
> Cheers,
> -- 
> Bill. <[EMAIL PROTECTED]>
> 
> Imagine a large red swirl here. 
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 
> 



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#53121: Save your money today when buying software - only reasonable prices here.. antherozooidal

[Sue]

Information's pretty thin stuff unless mixed with experience.
Top of the morning to you! :)

New software every week -more new low price every day for our products. What 
are you waiting for ??available. 

http://www.geocities.com/connie_montes_19/
It is not easy to find happiness in ourselves, and it is not possible 
to find it elsewhere.

excelent soft products for very reasonable money italian  - guaranteed. 

I have often thought that if a rational Fascist dictatorship were to 
exist, then it would choose the American system.

Great prices.out Quick confirmation response via email, shipped on time - it;s 
all our software magazin  

Who had deceived thee so often as thyself?My center is giving way, my right is 
in retreat situation excellent. I shall attack.






-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Release update: kde3.3, upload targets, kernels, infrastructure

[Horms]

On Fri, Jan 21, 2005 at 08:11:03PM -0800, Steve Langasek wrote:

[snip]

> Kernel updates
> --
> 
> One noteworthy source of open release-critical bugs are the kernel
> packages.  There have been a number of security vulnerabilities
> identified in the kernel over the past few weeks, including one that has
> required a change to core kernel interfaces and has therefore caused
> some delays in getting fixed kernels into testing for all architectures.
> At this point, fixed kernels are available on select architectures for
> the first round of security vulnerabilities, but another set of
> kernel-source packages are on their way.

In Friday kernel-source-2.4.27 2.4.27-8 was released which
should address the major outstanding issues with 2.4 and provide
a base for us to work on. 2.4.27-8 kernel images for i386 
were also made available on Friday. 

[snip]

-- 
Horms


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Release update: kde3.3, upload targets, kernels, infrastructure

[SR, ESC]

Le dim 2005-01-23 a 17:48:47 -0500, Henning Makholm <[EMAIL PROTECTED]> a dit:
> Scripsit Geoff Bagley <[EMAIL PROTECTED]>
> 
> > Is it possible to transfer some of the packages, a few at a time,
> > over into Woody, so that when we all change to Sarge, the servers
> > will not suffer from too heavy an overload ?
> 
> The few who think that the precise release date signifies an instant
> shift in the relative attractiveness of running woody vs. sarge will
> just have to put up with loaded mirrors for a couple of days.

also the plain simple reason that woody's and sarge's libc6 are
incompatible. we even coined a term for people installing sarge/sid
s/w onto woody machines stupidly, unknowingly, or otherwise:
bobbitting. comes from that story about that woman doing something to
her abusive husband, with a certain cutting implement, and the old
woody jokes. 

ec/

> -- 
> Henning Makholm"*Vi vil ha wienerbrÃd!*"
> 

-- 
"We're not talking about the same thing," he said. "For you the world is
weird because if you're not bored with it you're at odds with it. For me
the world is weird because it is stupendous, awesome, mysterious,
unfathomable; my interest has been to convince you that you must accept
responsibility for being here, in this marvelous world, in this marvelous
desert, in this marvelous time.  I wanted to convince you that you must
learn to make every act count, since you are going to be here for only a
short while, in fact, too short for witnessing all the marvels of it."
-- Don Juan


signature.asc
Description: Digital signature

Re: [Fwd: Re: status of the DDTP project?]

[Henrique de Moraes Holschuh]

On Sun, 23 Jan 2005, Daniel Macêdo Batista wrote:
> - The DDTP server is with a long delay to send out the replies. Sometimes
> the reply come in a lot of hours.

Live with it...  Our Debian email suffers these hassles sometimes.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Release update: kde3.3, upload targets, kernels, infrastructure

[Henning Makholm]

Scripsit "SR, ESC" <[EMAIL PROTECTED]>
>> Scripsit Geoff Bagley <[EMAIL PROTECTED]>

>> > Is it possible to transfer some of the packages, a few at a time,
>> > over into Woody, so that when we all change to Sarge, the servers
>> > will not suffer from too heavy an overload ?

> also the plain simple reason that woody's and sarge's libc6 are
> incompatible. we even coined a term for people installing sarge/sid
> s/w onto woody machines stupidly, unknowingly, or otherwise:

Huh? I run one machine that is mostly woody but with sarge's libc6 and
a few selected other sarge packages. This seems to work impeccably in
general (I do know where to point my anger at when it doesn't, but in
those casses libc has never been involved).  If sarge's libc6 were
*not* backwards compatible, it would have been called libc7.

-- 
Henning Makholm"There is a danger that curious users may
  occasionally unplug their fiber connector and look
  directly into it to watch the bits go by at 100 Mbps."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Do all frontends use the dpkg binary?

[Kevin Mark]

On Sun, Jan 23, 2005 at 08:13:08PM +0100, Tollef Fog Heen wrote:
> * Kevin Mark 
> 
> | In my quest to log package installation, I wrote a wrapper script for
> | dpkg. I 'mv dpkg dpkg.real' and 'vi dpkg' with a wrapper[0]. When I use
> | aptitude and apt-get, these commands seem to call dpkg for all of there
> | package installation and query needs. Do others (wajig,feta,...)
> | use '/usr/bin/dpkg' for installing packages or do they use a library?
> 
> There is no libdpkg yet, so they all use the dpkg binary.  If not,
> they are messing around with dpkg's internal data, something which
> they shouldn't.

ACK.

> 
> | Also, is there a way to avoid a dpkg upgrade overwriting /usr/bin/dpkg
> | and (IIRC) divert /usr/bin/dpkg -> /usr/bin/dpkg.real, so that I dont
> | have to remember to redo this step?
> 
> dpkg-divert, as others have said.

Cheers,
Kev
-- 
counter.li.org #238656 -- goto counter.li.org and be counted!

(__)
(oo)
  /--\/
 / |||
*  /\---/\
   ~~   ~~
"Have you mooed today?"...


signature.asc
Description: Digital signature

Re: Do all frontends use the dpkg binary?

[Kevin Mark]

On Sun, Jan 23, 2005 at 11:01:11PM +, Scott James Remnant wrote:
> On Sun, 2005-01-23 at 18:19 +0100, Bartosz Fenski aka fEnIo wrote:
> 
> > On Sun, Jan 23, 2005 at 06:11:42PM +0100, Christoph Berg wrote:
> > > > In my quest to log package installation, I wrote a wrapper script for
> > > > dpkg.
> > > 
> > > $ tail -1 /etc/apt/apt.conf
> > > DPkg::Pre-Install-Pkgs {"logger -t DPkg::Pre-Install-Pkgs";};
> > 
> > I wonder if it would be possible to set is as default behaviour along with
> > some logrotate scripts. Users quite often ask where are dpkg's actions
> > logged so I think this would be good idea.
> > 
> This would mean the disk would gradually fill up with logs,
  
As it would for any log file?

> unless you
> rotated them; 
  ^^^
With logrotate as most do?

> which seems to defeat the use case everybody has given for

> dpkg's actions being logged in the first place.

To log ever package installation?

Would such a log be very large as compared to say a mail log or an http
log? 

dpkg log < mail log << http log

making the logrotate use compression should help as it does with
any text file.
But I guess the file size would differ based upon your stream. 
ie. a stable system would have a smaller log file than a testing system, etc.
As a data point, my unstable dialup system is averging 30k / month for a
dpkg log as I update about 3 times a month.

just my .01 euros
Kev

-- 
counter.li.org #238656 -- goto counter.li.org and be counted!

(__)
(oo)
  /--\/
 / |||
*  /\---/\
   ~~   ~~
"Have you mooed today?"...


signature.asc
Description: Digital signature

Re: Do all frontends use the dpkg binary?

[Chris Walker]

Scott James Remnant <[EMAIL PROTECTED]> writes:

> This would mean the disk would gradually fill up with logs, unless you
> rotated them; which seems to defeat the use case everybody has given for
> dpkg's actions being logged in the first place.

Logs kept for a week would still be useful. 

A bug I filed[1] was closed with "The real error was
printed by dpkg much earlier in the process; it probably scrolled off
your screen."

If I had had a dpkg log, it would have been possible to find the real
error.

[1] #285414. It wasn't clear where to file it - so I chose apt. Next
time I'll file it against dpkg.

Chris


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: NPTL support in 2.4 kernel series?

[Brian May]

> "Lars" == Lars Wirzenius <[EMAIL PROTECTED]> writes:

Lars> (because people might want to install the package anyway,
Lars> and only use it when they are running the proper kernel)

This is IMHO an important point.

Consider udev. I believe you can still install it on a 2.4 kernel, but
IIRC you get a message saying it will only work if you boot a kernel
at or later then 2.6.8.

This is the correct approach IMHO.

Maybe some packages may need a way to back out of the installation of
the administrators decides they still need the application working
before doing a kernel upgrade.

Also note that just because a kernel is installed doesn't mean it is
working (I have 2.6.8-2-k7 Debian kernel installed on this computer
but it does not boot and I still have to investigate why - I suspect
some sort of initrd/RAID issue).

Even if the running kernel version is the right one doesn't mean the
system administrator isn't going to diagnose some serious problem with
the new version that requires a downgrade (hopefully this isn't too
frequent).
-- 
Brian May <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Reboot in postinst

[Brian May]

> "Wouter" == Wouter Verhelst <[EMAIL PROTECTED]> writes:

Wouter> lsof +L 1

rebooting is the only way to make sure rebooting will work if a reboot
is required for some reason during peak usage, e.g. power failure,
etc...

In some situations it might be better to test rebooting first at
low-demand times. Or if you plan on being off-site for an extended
period of time.
-- 
Brian May <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Fwd: Re: status of the DDTP project?]

[Christian Perrier]

> It seems there are enough people who want to help, but, which are debian
> developers? Could you, or anybody else, maybe try to find out who are
> interested?


Speaking on behalf of the French l10n team...

We have completely abandoned the DDTP effort now, as far as I am
aware. Nicolas Bertolissio made several contributions to the code in
the past, up to end 2003. I'm not sure whether he still contributes to
it.

The main reason was the fact that the DDTP deals with binary packages
descriptions which is far unlogical. It should rather deal with source
packages, especially when it comes at handling debconf translations. 

The DDTP is absolutely not adapted to the work on debconf
translations, that was our conclusion.

For packages descriptions, this is less important, but it seems that
the translators interest just switched to more important stuff.

During the last two years, we focused on debconf translations,
programs translations and web site translations rather than packages
descriptions translations. This was mostly because of the jerky
behaviour of the DDTP server, especially after the November 2003
compromise which left it unmaintained up to July 2004.

The review process also did not really fit with the way we have
established for working where all reviews are made in public in the
-l10n mailing list.

I personnally contributed a lot of packages description translations
back in 2002-2003 but, now, I just ignore the DDTP mails about them.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

apply to NM? ha!

[SR, ESC]

what's the fucking point in applying to NM when you get blasted for
asking a simple question about release. and what's the fucking point
when you get called luser for asking about it. 

really getting fucking sick of this crap. you fucking bored, so you go
and insult people? fuck off, and grow the fuck up, you're not in high
school anymore. 

you know who you are.

-- 
We can use symlinks of course... syslogd would be a symlink to syslogp and
ftpd and ircd would be linked to ftpp and ircp... and of course the
point-to-point protocol paenguin.
-- Kevin M. Bealer, commenting on the penguin Linux logo


signature.asc
Description: Digital signature