Fwd: Regarding: packages.debian.org/testing/net/bcm5700-source

[martin f krafft]

Have people seen these? Is this a new way to phish email address
confirmations? The website exposes all the kinds of things that I do
not want on the WWW...

- Forwarded message from [EMAIL PROTECTED] -

Date: Tue, 12 Oct 2004 12:37:57 -0400
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Regarding: packages.debian.org/testing/net/bcm5700-source

This e-mail has been sent to inform you that your
web site URL has been submitted to our search engine
database. This is the URL that will be included.

  URL : packages.debian.org/testing/net/bcm5700-source
 DATE : 10/12/2004 12:37:56
  USER IP : Unknown IP. User had used an automated software for url submission

In order to complete this request we require that you
click on the web site link below. This will confirm
that you wish to be included in our search engine 
database at no fee to you.
http://www.mardox.com/confirm.cgi?T

- End forwarded message -

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


signature.asc
Description: Digital signature

Re: Is declaring correct deps/conflicts for versions not in stable really no longer needed?

[GOTO Masanori]

At Tue, 12 Oct 2004 14:03:00 +0400,
Nikita V. Youshchenko <[EMAIL PROTECTED]> wrote:
> > The bug _was_ in glibc, and not in php. It is not the job of php to
> > force you to have a non-buggy glibc installed.
> 
> This depends on point of view.
> If a library < X.Y does not provide a feature needed by a package, it's a 
> common practice to make package depend on library (>= X.Y). Other 
> packages, that don't need that library feature, don't need to depend on 
> library (>= X.Y).
> The case with libapache-mod-php4 / glibc looks similar: glibc less than 
> 2.3.2.ds1-17 does not provide neede functionality [due to a bug]. This 
> affects libapache-mod-php4, but does no affect most (all?) other packages.

Note that you guys seems not know what dlopen() is.  POSIX and SUS
says that dlclose() does not need to unmap libraries.  So, it's debian
specific wishlist.  I fixed this report because it's convenient for
the upgrade from woody to sarge, but it's not mandatory behavior.  So,
another word, it's also libapache-mod-php4 bug during upgrade.

Regards,
-- gotom

Re: ppp/ip-up vs. network/if-up

[Thomas Hood]

On Tue, 2004-10-12 at 23:28, Robert Collins wrote:
> Does it hook into ppp to handle persistent ppp connections? (i.e. adsl).


I am not sure what you mean.

The new ifupdown uses pppd's updetach option.  Run with this option,
pppd only exits after it has made a connection.  Since ifup runs "up"
commands only after pppd exits, "up" commands only get run after the
connection has been made.

-- 
Thomas

Re: Xsession doesn't use umask setting from /etc/login.defs

[Branden Robinson]

[Redirecting to debian-devel; followups set.]

On Mon, Sep 20, 2004 at 02:29:32PM +0200, Wouter Hanegraaff wrote:
> Hi,
> 
> After a fresh sarge install, I'm having problems with umask settings. In
> /etc/login.defs I set umask to 002, and that works for logging in on the
> console or remote via ssh. However, if I use {g,x,k}dm I keep getting an
> umask of 022, because Xsession is started by the display manager which
> has a default umask of 022.
> 
> It seems that Xsession doesn't change the UMASK at all. Should it do so?
> If not, which program should set the umask during a graphical login?

Good question.

debian-devel folks, what do you think?  I'm having difficulty deciding how
to think about this issue.

/etc/login.defs explicitly indicates that it is "Configuration control
definitions for the login package", and many of its parameters are
inapplicable to display managers, or already implemented in parallel (e.g.,
how long do wait after a failed login before displaying the prompt/greeter
again?).

By analogy, /etc/environment is a PAM thing and should only be dealt with
by PAM.  (We can't use it anyway since the umask is not an environment
variable.)

* What's the path of least resistance?
* What would violate user expectations the least?
* What would be a good ideal approach, if code changes weren't an issue?

-- 
G. Branden Robinson| You could wire up a dead rat to a
Debian GNU/Linux   | DIMM socket and the PC BIOS memory
[EMAIL PROTECTED] | test would pass it just fine.
http://people.debian.org/~branden/ | -- Ethan Benson


signature.asc
Description: Digital signature

Re: ..d-u support sponsorships, was: Problem with ppp keeping link up

[John Lines]

Another possibility would be distribution based lists - e.g. debian-woody, 
debian-sarge  - possibly debian-sid.

Users of a specific distribution can use that list, without having to be asked 
'which version are you running'. It will tend to automatically group the more 
advanced questions (or the 'Does this work at all?') generally asked by the 
people running sid or sarge from the ones asked by people who are running 
woody - which tend to be more of the nature of 'How do I use some specific 
feature'

-- 
John Lines 

Re: Fwd: Regarding: packages.debian.org/testing/net/bcm5700-source

[Colin Watson]

On Wed, Oct 13, 2004 at 08:22:14AM +0200, martin f krafft wrote:
> Have people seen these?

Thousands of times.

-- 
Colin Watson   [EMAIL PROTECTED]

Re: ppp/ip-up vs. network/if-up

[Adrian 'Dagurashibanipal' von Bidder]

On Wednesday 13 October 2004 08.30, Thomas Hood wrote:
> On Tue, 2004-10-12 at 23:28, Robert Collins wrote:
> > Does it hook into ppp to handle persistent ppp connections? (i.e.
> > adsl).
>
> I am not sure what you mean.
>
> The new ifupdown uses pppd's updetach option.  Run with this option,
> pppd only exits after it has made a connection.  Since ifup runs "up"
> commands only after pppd exits, "up" commands only get run after the
> connection has been made.

I think Robert thought about if the scripts are rerun if pppd loses 
connection and reconnects - typically with a different IP.

cheers
-- vbi

-- 
Oops


pgpQ8UqhtNIFI.pgp
Description: PGP signature

Re: Fwd: Regarding: packages.debian.org/testing/net/bcm5700-source

[martin f krafft]

also sprach Colin Watson <[EMAIL PROTECTED]> [2004.10.13.0929 +0200]:
> > Have people seen these?
> 
> Thousands of times.

Have people responded? What do people think?

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


signature.asc
Description: Digital signature

Re: possible mass bug filing: spamassassin 3

[Manoj Srivastava]

On Wed, 06 Oct 2004 15:56:25 -0500, Manoj Srivastava
<[EMAIL PROTECTED]> said:  

>   Under your scheme, Sarge would be bereft of all the packages
>  that build on SA that have not changed, at the cost of something
>  that has shown all evidence of being flakey and not ready for prime
>  time yet.


Well, dialing down  max children to 2 allows my machine to
 keep load averages within sane limits, and still not build up a
 significant backlog (-m 10 was doing that). I have not had any
 further problems with SA3, so far.

manoj
-- 
Real Users find the one combination of bizarre input values that shuts
down the system for days.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

discover or alsa?

[Thomas Hood]

Lots of users are reporting that ALSA sound doesn't "just" work when
they install it.  The cause of the problem is the fact that discover
loads OSS modules even when ALSA modules are available.  This bug cannot
be worked around consistently with policy because discover offers no
mechanism for blacklisting modules other than editing a conffile.  The
bug report against discover1 (#220616) has been tagged "wontfix" so I am
not expecting the discover maintainers to solve the problem.

Given these facts, what should the ALSA packaging team do?  It seems
that the alsa packages should Conflict with discover and discover1.
-- 
Thomas Hood

Re: discover or alsa?

[Petter Reinholdtsen]

[Thomas Hood]
> Given these facts, what should the ALSA packaging team do?  It seems
> that the alsa packages should Conflict with discover and discover1.

Isn't this only a problem with discover1?  I thought discover (v2) had
a mechanism to detect if OSS or ALSA was used.

It is probably better to discuss this with the discover1 and discover
(v2) maintainers and authors over at debian-boot and discover-workers.

Bug#221988 (makeinfo --xml outputs non-well-formed XML) and my patch

[Vincent Lefevre]

I submitted a patch for the bug #221988. Does anyone know when it
will be considered? If this bug could be fixed in the Sarge release
(I don't know if this is possible), this would really be fine.

Thanks,

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: Bug#276229: RFH: ion2, ion3 -- Keyboard-friendly window manager with tiled windows

[Norbert Tretkowski]

* Per Olofsson wrote:
> I currently don't have the time and energy to maintain ion2 and ion3
> as well as I should, so I hereby request a co-maintainer for them.
> There are no big problems with the packages as they are, but they
> need to be updated to the latest upstream versions.

Since I'm using ion2 and ion3, I'd like to help you with the packages.

Norbert

Re: discover or alsa?

[Thomas Hood]

On Wed, 2004-10-13 at 10:57, Petter Reinholdtsen wrote:
> [Thomas Hood]
> Isn't this only a problem with discover1?  I thought discover (v2) had
> a mechanism to detect if OSS or ALSA was used.


If there is such a mechanism then it isn't working.


> It is probably better to discuss this with the discover1 and discover
> (v2) maintainers and authors over at debian-boot and discover-workers.


The discover maintainers ended that discussion with a decision not to
fix the bug in discover1.  The bug _may_ be fixed in discover at some
time in the future, presumably post-sarge.  The remaining question is
how alsa should deal with this situation.  Conflict with discover[1]? 
Add a paragraph to the alsa-base README telling how to fix the problem
by hand?  Add code to the alsa initscript which rmmods OSS modules?
-- 
Thomas Hood

Re: Package idea, Debian-Firewall.

[Javier Fernández-Sanguino Peña]

On Wed, Oct 13, 2004 at 06:13:36AM +0200, nicklas (smurfd) wrote:
> Hey Debian-devels!
> 
> I have had  a package idea, for a long time now. The idea, was a
> package, containing a "Flush-all" firewall script. Adding this script to
> be ran at bootup. Just for the simplicity. I tend to keep forgetting to
> add it myself.

You could actually try to convince the iptables maintainer to allow users 
to set this kind of "deny all" setup in postinst through debconf. It should 
be rather easy to do actually, since you just have to execute an iptables 
script (similar to what you provided) and run '/etc/init.d/iptables save'.
I tried to do this a while back without any success (see #212692).

There are a lot of ways to setup a firewall in Debian [1] I rather not have 
yet another package to do this.

Regards

Javier


[1] 
http://www.debian.org/doc/manuals/securing-debian-howto/ch-sec-services.en.html#s-firewall-setup


signature.asc
Description: Digital signature

Re: Common set of debconf templates

[Brian Sutherland]

On Tue, Oct 12, 2004 at 10:05:40PM +0200, Agustin Martin wrote:
> On Mon, Oct 11, 2004 at 12:59:01PM +0200, Brian Sutherland wrote:
> > On Mon, Oct 11, 2004 at 07:36:40AM +0200, Christian Perrier wrote:
> > > SHARED TEMPLATES
> > >It's actually possible to have a template and a question that
> > >are shared among a set of packages. All the packages have to
> > >provide an identical copy of the template in their templates
> > ^
> > >files. This can be useful if a bunch of packages need to ask
> > >the same question, and you only want to bother the user with it
> > >once. Shared templates are generally put in the shared/
> > >pseudo-directory in the debconf tem- plate namespace.
> > 
> > What happens when the template changes in the template package but is
> > out of sync in the other packages?
> > 
> 
> IIRC, last installed package wins and puts its version of the template into
> the debconf database, even if it is not the most up-to-date. If there is a
> package that has no translations at all for the shared question and is
> installed after packages having plenty of translations, there will be no
> translations at all for that shared question in the debconf database. 

What about a rule that says:

- If the package name is the same as the directory in the debconf database
  then use that package's templates take priority.
- Else, as before.

The package includes the template-package's templates at build
(debhelper style as suggested before).

Then up to date translations can be ensured by installing a
debconf-translation-templates meta package or templates package before 
the package.

(Pre-depends / Recommends / Installer business??)

-- 
Brian Sutherland

Re: Is declaring correct deps/conflicts for versions not in stable really no longer needed?

[Steve Langasek]

On Wed, Oct 13, 2004 at 03:23:51PM +0900, GOTO Masanori wrote:
> At Tue, 12 Oct 2004 14:03:00 +0400,
> Nikita V. Youshchenko <[EMAIL PROTECTED]> wrote:
> > > The bug _was_ in glibc, and not in php. It is not the job of php to
> > > force you to have a non-buggy glibc installed.

> > This depends on point of view.
> > If a library < X.Y does not provide a feature needed by a package, it's a 
> > common practice to make package depend on library (>= X.Y). Other 
> > packages, that don't need that library feature, don't need to depend on 
> > library (>= X.Y).
> > The case with libapache-mod-php4 / glibc looks similar: glibc less than 
> > 2.3.2.ds1-17 does not provide neede functionality [due to a bug]. This 
> > affects libapache-mod-php4, but does no affect most (all?) other packages.

> Note that you guys seems not know what dlopen() is.  POSIX and SUS
> says that dlclose() does not need to unmap libraries.  So, it's debian
> specific wishlist.  I fixed this report because it's convenient for
> the upgrade from woody to sarge, but it's not mandatory behavior.  So,
> another word, it's also libapache-mod-php4 bug during upgrade.

Actually, the segfault was not caused by a bug in libapache-mod-php4;
the bug is either a bug in openssl or in glibc, depending on your POV.
Perhaps both ;), although the triggering event was certainly the
introduction of a new upstream version of glibc -- in spite of the fact
that there don't seem to have been any changes in the dlopen() code in
that particular upstream version.

-- 
Steve Langasek
postmodern programmer

Re: Package idea, Debian-Firewall.

[Francesco P. Lovergine]

On Wed, Oct 13, 2004 at 11:39:29AM +0200, Javier Fernández-Sanguino Peña wrote:
> On Wed, Oct 13, 2004 at 06:13:36AM +0200, nicklas (smurfd) wrote:
> > Hey Debian-devels!
> > 
> > I have had  a package idea, for a long time now. The idea, was a
> > package, containing a "Flush-all" firewall script. Adding this script to
> > be ran at bootup. Just for the simplicity. I tend to keep forgetting to
> > add it myself.
> 
> You could actually try to convince the iptables maintainer to allow users 
> to set this kind of "deny all" setup in postinst through debconf. It should 
> be rather easy to do actually, since you just have to execute an iptables 
> script (similar to what you provided) and run '/etc/init.d/iptables save'.
> I tried to do this a while back without any success (see #212692).
> 

Indeed currently iptables rules need to be loaded with pre-up scripting
in /etc/network/interfaces. Old init.d scripts are deprecated and not
installed at all. 

> There are a lot of ways to setup a firewall in Debian [1] I rather not have 
> yet another package to do this.
> 

Agree.


-- 
Francesco P. Lovergine

Re: discover or alsa?

[Marco d'Itri]

On Oct 13, Thomas Hood <[EMAIL PROTECTED]> wrote:

> Lots of users are reporting that ALSA sound doesn't "just" work when
> they install it.  The cause of the problem is the fact that discover
> loads OSS modules even when ALSA modules are available.  This bug cannot
> be worked around consistently with policy because discover offers no
> mechanism for blacklisting modules other than editing a conffile.  The
> bug report against discover1 (#220616) has been tagged "wontfix" so I am
> not expecting the discover maintainers to solve the problem.
Discover should not try to load drivers for PCI devices AT ALL, we have
hotplug for this.

-- 
ciao, |
Marco | [8529 riJkWPDrTv6mA]


signature.asc
Description: Digital signature

Re: Fwd: Regarding: packages.debian.org/testing/net/bcm5700-source

[Colin Watson]

On Wed, Oct 13, 2004 at 09:43:52AM +0200, martin f krafft wrote:
> also sprach Colin Watson <[EMAIL PROTECTED]> [2004.10.13.0929 +0200]:
> > martin f krafft wrote:
> > > Have people seen these?
> > 
> > Thousands of times.
> 
> Have people responded? What do people think?

It's yet more spam. Why would we respond or care?

-- 
Colin Watson   [EMAIL PROTECTED]

Re: RFD: Draft for a volatile.d.o policy

[Thaddeus H. Black]

John Hasler mentions,

> ... the non-existent backports.debian.org ...

An existent backports.debian.org would seem a
worthy aspiration.  Were plans thereto afoot, I
would encourage.

(It has been surmised once or twice in this
thread that few people here actually use stable.
This may be so, but just to add my own datum, I
would admit that I use stable for everything
except Debian development.  Signed by stable
GnuPG, this very mail issues from stable Mutt.
Even stable Mozilla still has a home on my PC.)

-- 
Thaddeus H. Black
508 Nellie's Cave Road
Blacksburg, Virginia 24060, USA
+1 540 961 0920, [EMAIL PROTECTED]


pgp5OYKYKZvuJ.pgp
Description: PGP signature

Re: discover or alsa?

[Wouter Verhelst]

On Wed, Oct 13, 2004 at 10:51:46AM +0200, Marco d'Itri wrote:
> On Oct 13, Thomas Hood <[EMAIL PROTECTED]> wrote:
> > Lots of users are reporting that ALSA sound doesn't "just" work when
> > they install it.  The cause of the problem is the fact that discover
> > loads OSS modules even when ALSA modules are available.  This bug cannot
> > be worked around consistently with policy because discover offers no
> > mechanism for blacklisting modules other than editing a conffile.  The
> > bug report against discover1 (#220616) has been tagged "wontfix" so I am
> > not expecting the discover maintainers to solve the problem.
> Discover should not try to load drivers for PCI devices AT ALL, we have
> hotplug for this.

The reverse could be (and has been, on multiple occasions) said about
hotplug.

The issue is that there are multiple auto-detection schemes in the
archive, currently, all of which will check what hardware is available
in the system, what driver can support that hardware, and which will
load the appropriate driver.

In this thread discover, discover1, and hotplug have been named; but
there are more -- at least at one point, we have (had) kudzu packaged
for Debian as well.

Apart from that, there's also the 'canon' way of managing modules
(/etc/modules), and a number of other packages which will load modules
to be able to do what they're installed for (hardware driver support
packages such as the ALSA ones, but also stuff such as binfmt-support
and nbd-client).

This multitude of packages doing stuff with modules is bound to break
eachother. Perhaps it's time to create a scheme which will allow
packages to load modules without stepping on eachother's toes? Such a
scheme would

* Require init scripts to ask the central module handling system
  permission to load a module, with a description of what purpose the
  module serves.
* Not do anything if the central handling system forbids it.
* Optionally keep track of what modules are loaded by what package, for
  debugging purposes.
* Allow packages to register themselves as the 'preferred' handler of
  the module at postinst time (similar to the alternatives system; this
  would solve the current issue ALSA has).
* Give the local admin the ability to override such decisions, or to
  disable the loading of certain modules.

Comments?

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


signature.asc
Description: Digital signature

Re: Package idea, Debian-Firewall.

[Steve Kemp]

On Wed, Oct 13, 2004 at 06:13:36AM +0200, nicklas (smurfd) wrote:

> I have had  a package idea, for a long time now. The idea, was a
> package, containing a "Flush-all" firewall script. Adding this script to
> be ran at bootup. Just for the simplicity. I tend to keep forgetting to
> add it myself.

  I think anybody who knows enough to create a firewall will not
 omit the flushing.

> the postinst file looks like : 
> 
> #!/bin/sh
> set -e
> if [ "$1" = "configure" ]; then
> ln -s /etc/init.d/debian-firewall /etc/rc0.d/S20debian-firewall
> ln -s /etc/init.d/debian-firewall /etc/rc1.d/S20debian-firewall
> ln -s /etc/init.d/debian-firewall /etc/rc2.d/S20debian-firewall

  N!

  Use update-rc.d, please.

  http://www.debian-administration.org/?article=28

> and the prerm file looks like : 
> 
> #!/bin/sh
> set -e
> if [ "$1" = "remove" ]; then
> rm /etc/rc0.d/S20debian-firewall
> rm /etc/rc1.d/S20debian-firewall

  Again update-rc.d should be used here.

Steve
--
# The Debian Security Audit Project.
http://www.debian.org/security/audit

Re: discover or alsa?

[Free Ekanayaka]

|--==> Wouter Verhelst writes:

  WV> [1  ]
  WV> On Wed, Oct 13, 2004 at 10:51:46AM +0200, Marco d'Itri wrote:
  >>On Oct 13, Thomas Hood <[EMAIL PROTECTED]> wrote:
  >>> Lots of users are reporting that ALSA sound doesn't "just" work when
  >>> they install it.  The cause of the problem is the fact that discover
  >>> loads OSS modules even when ALSA modules are available.  This bug cannot
  >>> be worked around consistently with policy because discover offers no
  >>> mechanism for blacklisting modules other than editing a conffile.  The
  >>> bug report against discover1 (#220616) has been tagged "wontfix" so I am
  >>> not expecting the discover maintainers to solve the problem.
  >>Discover should not try to load drivers for PCI devices AT ALL, we have
  >>hotplug for this.

  WV> The reverse could be (and has been, on multiple occasions) said about
  WV> hotplug.

I thought hotplug was dealing  with hot plugging devices (pcmcia, usb,
etc.)

  WV> The issue is that there are multiple auto-detection schemes in the
  WV> archive, currently, all of which will check what hardware is available
  WV> in the system, what driver can support that hardware, and which will
  WV> load the appropriate driver.

  WV> In this thread discover, discover1, and hotplug have been named; but
  WV> there are more -- at least at one point, we have (had) kudzu packaged
  WV> for Debian as well.

  WV> Apart from that, there's also the 'canon' way of managing modules
  WV> (/etc/modules), and a number of other packages which will load modules
  WV> to be able to do what they're installed for (hardware driver support
  WV> packages such as the ALSA ones, but also stuff such as binfmt-support
  WV> and nbd-client).

  WV> This multitude of packages doing stuff with modules is bound to break
  WV> eachother. Perhaps it's time to create a scheme which will allow
  WV> packages to load modules without stepping on eachother's toes?

I definitely agree, some rational is needed here.

  WV> Such a scheme would

  WV> * Require init scripts to ask the central module handling system
  WV>   permission to load a module, with a description of what purpose the
  WV>   module serves.
  WV> * Not do anything if the central handling system forbids it.
  WV> * Optionally keep track of what modules are loaded by what package, for
  WV>   debugging purposes.
  WV> * Allow packages to register themselves as the 'preferred' handler of
  WV>   the module at postinst time (similar to the alternatives system; this
  WV>   would solve the current issue ALSA has).
  WV> * Give the local admin the ability to override such decisions, or to
  WV>   disable the loading of certain modules.

Seems a good scheme to me.

For the  record I've made a custom  discover1-data package  which uses
ALSA in place of OSS:

http://apt.agnula.org/demudi/pool/local/d/discover1-data/

Cheers,

Free

Re: Fwd: Regarding: packages.debian.org/testing/net/bcm5700-source

[martin f krafft]

also sprach Colin Watson <[EMAIL PROTECTED]> [2004.10.13.1334 +0200]:
> It's yet more spam. Why would we respond or care?

Well, I realise. I was just curious.

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


signature.asc
Description: Digital signature

Re: Common set of debconf templates

[sean finney]

On Wed, Oct 13, 2004 at 11:51:00AM +0200, Brian Sutherland wrote:
> The package includes the template-package's templates at build
> (debhelper style as suggested before).
> 
> Then up to date translations can be ensured by installing a
> debconf-translation-templates meta package or templates package before 
> the package.

if the templates are included at build-time by a debhelper-style script,
there's no need for a runtime dependency for these templates.

> (Pre-depends / Recommends / Installer business??)

i think Pre-depends should be avoided at any possible cost.  this
unfortunately means that the REGISTER suggestion won't reliably work,
which is really too bad because that would have been the most graceful
solution.

over the past week i've been in contact with joeyh about the
feasability of doing this with a debhelper-style script, and think
i have the workings of a primitive version hashed out with him.


sean

-- 


signature.asc
Description: Digital signature

Re: RFD: Draft for a volatile.d.o policy

[John Hasler]

Thaddeus H. Black writes:
> An existent backports.debian.org would seem a worthy aspiration.  Were
> plans thereto afoot, I would encourage.

I agree, but I try to avoid writing anything that could be construed as
"somebody ought to do X" on debian lists.

> It has been surmised once or twice in this thread that few people here
> actually use stable.

I run Stable on one machine and Unstable on the other.
-- 
John Hasler

Re: discover or alsa?

[Rob Weir]

On Wed, Oct 13, 2004 at 02:14:24PM +0200, Free Ekanayaka said
> |--==> Wouter Verhelst writes:
> 
>   WV> [1  ]
>   WV> On Wed, Oct 13, 2004 at 10:51:46AM +0200, Marco d'Itri wrote:
>   >>On Oct 13, Thomas Hood <[EMAIL PROTECTED]> wrote:
>   >>> Lots of users are reporting that ALSA sound doesn't "just" work when
>   >>> they install it.  The cause of the problem is the fact that discover
>   >>> loads OSS modules even when ALSA modules are available.  This bug cannot
>   >>> be worked around consistently with policy because discover offers no
>   >>> mechanism for blacklisting modules other than editing a conffile.  The
>   >>> bug report against discover1 (#220616) has been tagged "wontfix" so I am
>   >>> not expecting the discover maintainers to solve the problem.
>   >>Discover should not try to load drivers for PCI devices AT ALL, we have
>   >>hotplug for this.
> 
>   WV> The reverse could be (and has been, on multiple occasions) said about
>   WV> hotplug.
> 
> I thought hotplug was dealing  with hot plugging devices (pcmcia, usb,
> etc.)

PCI (on special motherboards) is hotpluggable :-)

-rob

-- 
Words of the day: CBNRC Glock SCUD missile Janet Reno clandestine NASA ASIO

Re: Bug#276057: ITP: mediawiki -- Wikipedia wiki engine

[Andreas Tille]

On Mon, 11 Oct 2004, Evan Prodromou wrote:
* Package name: mediawiki
 Version : 1.3.5
 Upstream Author : Mediawiki developers <[EMAIL PROTECTED]>
* URL : http://wikipedia.sourceforge.net/
* License : GPL
 Description : Wikipedia wiki engine
MediaWiki is the wiki engine that runs Wikipedia, Wiktionary,
Wikibooks, and all the other Wikimedia wiki web sites. (A wiki engine
is a web-based tool for collaborative editing). It uses PHP and MySQL.
Does this include an easy way to update the WikiPedia database from the
original servers to get a nice possibility to read WikiPedia offline?
Kind regards
 Andreas.

Re: Fwd: Regarding: packages.debian.org/testing/net/bcm5700-source

[Thomas Bushnell BSG]

martin f krafft <[EMAIL PROTECTED]> writes:

> also sprach Colin Watson <[EMAIL PROTECTED]> [2004.10.13.0929 +0200]:
> > > Have people seen these?
> > 
> > Thousands of times.
> 
> Have people responded? What do people think?

I have assumed that they are live-address harvesting spam.  It's so
easy to make an automated search engine, that why would they need to
you "submit", after they've already found your page?!

Re: Wanted BTS feature: subscription to individual bug reports

[Anand Kumria]

On Tue, 12 Oct 2004 13:37:37 +0400, Nikita V. Youshchenko wrote:

> Hello.
> 
> I can't find a way to track more-or-less easilly all bugs in BTS that I am 
> somewhat involved into.
> 

If by 'involved' you mean submitted, then this might be useful:

http://bugs.debian.org/cgi-bin/[EMAIL PROTECTED]>

Cheers,
Anand

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

Re: Wanted BTS feature: subscription to individual bug reports

[Wouter Verhelst]

On Thu, Oct 14, 2004 at 01:59:36AM +1000, Anand Kumria wrote:
> On Tue, 12 Oct 2004 13:37:37 +0400, Nikita V. Youshchenko wrote:
> 
> > Hello.
> > 
> > I can't find a way to track more-or-less easilly all bugs in BTS that I am 
> > somewhat involved into.
> > 
> 
> If by 'involved' you mean submitted, then this might be useful:
> 
> http://bugs.debian.org/cgi-bin/[EMAIL PROTECTED]>

Or, if you want the short version:



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


signature.asc
Description: Digital signature

Re: discover or alsa?

[Marco d'Itri]

On Oct 13, Wouter Verhelst <[EMAIL PROTECTED]> wrote:

> > Discover should not try to load drivers for PCI devices AT ALL, we have
> > hotplug for this.
> The reverse could be (and has been, on multiple occasions) said about
> hotplug.
Sure, many people say silly things.
hotplug is needed on most systems (think about USB devices), will
probably become mandatory very soon (hint: udev) and needs anyway to
support PCI hotplugging for systems with an hotplug PCI bus.
Since it's here, is going to stay and does almost everything we need,
automatically (it uses information provided by the kernel and does not
need a database to be updated), I'd say we can as well use it for
coldplugging.

> Apart from that, there's also the 'canon' way of managing modules
> (/etc/modules), and a number of other packages which will load modules
> to be able to do what they're installed for (hardware driver support
> packages such as the ALSA ones, but also stuff such as binfmt-support
> and nbd-client).
ALSA does not loads modules anymore, the other packages you mentioned do
not load device drivers and are not relevant in this discussion.

> Comments?
Your proposals are (other than very vague) way too much complex and
probably not even possible to implement.

-- 
ciao, |
Marco | [8536 arLPqUeErJ8NQ]


signature.asc
Description: Digital signature

Re: discover or alsa?

[Anand Kumria]

On Wed, 13 Oct 2004 13:43:01 +0200, Wouter Verhelst wrote:

> On Wed, Oct 13, 2004 at 10:51:46AM +0200, Marco d'Itri wrote:
>> On Oct 13, Thomas Hood <[EMAIL PROTECTED]> wrote:
>> > Lots of users are reporting that ALSA sound doesn't "just" work when
>> > they install it.  The cause of the problem is the fact that discover
>> > loads OSS modules even when ALSA modules are available.  This bug cannot
>> > be worked around consistently with policy because discover offers no
>> > mechanism for blacklisting modules other than editing a conffile.  The
>> > bug report against discover1 (#220616) has been tagged "wontfix" so I am
>> > not expecting the discover maintainers to solve the problem.
>> Discover should not try to load drivers for PCI devices AT ALL, we have
>> hotplug for this.
> 
> The reverse could be (and has been, on multiple occasions) said about
> hotplug.

[snip]
 
> The issue is that there are multiple auto-detection schemes in the
> This multitude of packages doing stuff with modules is bound to break
> eachother. Perhaps it's time to create a scheme which will allow
> packages to load modules without stepping on eachother's toes? Such a
> scheme would
> 
> * Require init scripts to ask the central module handling system
>   permission to load a module, with a description of what purpose the
>   module serves.
> * Not do anything if the central handling system forbids it.
> * Optionally keep track of what modules are loaded by what package, for
>   debugging purposes.
> * Allow packages to register themselves as the 'preferred' handler of
>   the module at postinst time (similar to the alternatives system; this
>   would solve the current issue ALSA has).
> * Give the local admin the ability to override such decisions, or to
>   disable the loading of certain modules.
> 
> Comments?

I think this is a situation where should push a particular implementation
to standard. Just as we promote 'sysvinit' and have interoperability
scripts for things like file-rc; if people want to use it.

Once we've picked a standard one, I'm partial to hotplug myself since it
seems to work well on both 2.4 and 2.6 kernels and I've found discover
doesn't. The optional detection mechanism(s) can then come up with a
programmatic interface similar to sysv-rc.

Cheers,
Anand

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

packages.debian.org version discrepency

[Shaun Jackman]

The unstable link at http://packages.debian.org/freeguide shows
version 0.8, but http://packages.debian.org/unstable/misc/freeguide
shows version 0.7.2. Why is this?

Cheers,
Shaun

Bug#276376: ITP: gpsd -- a GPS service daemon

[Tilman Koschnick]

Package: wnpp
Severity: wishlist

* Package name: gpsd
  Version : 2.1
  Upstream Author : Derrick Brashear 
Eric S. Raymond 
Russ Nelson 
Remco Treffkorn 
* URL : http://developer.berlios.de/projects/gpsd/
* License : GPL
  Description : a GPS service daemon

gpsd is a userland daemon acting as a liason between a GPS or
Loran-C receiver and clients. The receiver is expected to generate
position information as NMEA-0183 sentences, or Rockwell binary format,
although that can be changed.

Re: Wanted BTS feature: subscription to individual bug reports

[Erik Schanze]

Anand Kumria <[EMAIL PROTECTED]>:
> On Tue, 12 Oct 2004 13:37:37 +0400, Nikita V. Youshchenko wrote:
> > I can't find a way to track more-or-less easilly all bugs in BTS that I am 
> > somewhat involved into.
> > 
> 
> If by 'involved' you mean submitted, then this might be useful:
> 
> http://bugs.debian.org/cgi-bin/[EMAIL PROTECTED]>
> 
I assume he mean also bugs on wich he had supplied additional information.
This feature would be very nice.

Regards,

Erik


-- 
 www.ErikSchanze.de *
 Bitte keine HTML-E-Mails! No HTML mails, please! Limit: 100 kB *
  * Linux-Info-Tag in Dresden, am 30. Oktober 2004  *
 Info: http://www.linux-info-tag.de *

Re: discover or alsa?

[Wouter Verhelst]

On Wed, Oct 13, 2004 at 06:07:49PM +0200, Marco d'Itri wrote:
> On Oct 13, Wouter Verhelst <[EMAIL PROTECTED]> wrote:
> > > Discover should not try to load drivers for PCI devices AT ALL, we have
> > > hotplug for this.
> > The reverse could be (and has been, on multiple occasions) said about
> > hotplug.
> Sure, many people say silly things.
> hotplug is needed on most systems (think about USB devices),

That's no argument for blatantly ignoring different implementations
which perform similar things.

> will probably become mandatory very soon (hint: udev) and needs anyway
> to support PCI hotplugging for systems with an hotplug PCI bus.

That doesn't have anything to do with coldplugging. Also, AFAIK, udev is
far from the only /dev implementation in the kernel. I don't think it'll
suddenly be mandatory.

> Since it's here, is going to stay and does almost everything we need,
> automatically (it uses information provided by the kernel and does not
> need a database to be updated), I'd say we can as well use it for
> coldplugging.

Sure, I'm not contesting that. But there are other coldplugging
implementations around. It's generally considered polite to respect
different implementations.

> > Apart from that, there's also the 'canon' way of managing modules
> > (/etc/modules), and a number of other packages which will load modules
> > to be able to do what they're installed for (hardware driver support
> > packages such as the ALSA ones, but also stuff such as binfmt-support
> > and nbd-client).
> ALSA does not loads modules anymore,

ACPI.

> the other packages you mentioned do not load device drivers and are
> not relevant in this discussion.

They load modules. This is a suggestion about managing how modules are
loaded.

> > Comments?
> Your proposals are (other than very vague) way too much complex and
> probably not even possible to implement.

Of course they're vague. They're an initial idea.

if want-module-load --package hotplug snd-ens1371
then
  modprobe es1371
fi

want-module-load would check configuration files and 'exit 0' or 'exit 1'
depending on whether it will allow hotplug to load the es1371 module. It
would know that es1371 is an ALSA module for a PCI sound board, and
would check whether hotplug would be allowed to load this module.

The admin could say stuff such as

discover oss forbid
hotplug alsa allow

Which would tell the system that discover is not to load any OSS
modules, while it's okay for hotplug to load ALSA stuff.

What's impossible about that?

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


signature.asc
Description: Digital signature

Re: discover or alsa?

[Wouter Verhelst]

On Wed, Oct 13, 2004 at 07:26:32PM +0200, Wouter Verhelst wrote:
[brown paper bag]
> if want-module-load --package hotplug snd-ens1371
> then
>   modprobe es1371
> fi
> 
> want-module-load would check configuration files and 'exit 0' or 'exit 1'
> depending on whether it will allow hotplug to load the es1371 module. It
> would know that es1371 is an ALSA module for a PCI sound board, and
> would check whether hotplug would be allowed to load this module.

consistency is nice. s/es1371/snd-ens1371/g
> 
> -- 
>  EARTH
>  smog  |   bricks
>  AIR  --  mud  -- FIRE
> soda water |   tequila
>  WATER
>  -- with thanks to fortune



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

Re: packages.debian.org version discrepency

[Gustavo Franco]

On Wed, 13 Oct 2004 09:06:03 -0700, Shaun Jackman <[EMAIL PROTECTED]> wrote:
> The unstable link at http://packages.debian.org/freeguide shows
> version 0.8, but http://packages.debian.org/unstable/misc/freeguide
> shows version 0.7.2. Why is this?

I see the same with the moodle package[0], it shows 1.4.1-1 (unstable)
but looking into [1] it points to 1.4-1.

[0] = http://packages.debian.org/moodle/
[1] = http://packages.debian.org/unstable/web/moodle

--
Gustavo Franco

Re: discover or alsa? Solution proposal.

[Greg Folkert]

On Wed, 2004-10-13 at 10:30 +0200, Thomas Hood wrote:
> Lots of users are reporting that ALSA sound doesn't "just" work when
> they install it.  The cause of the problem is the fact that discover
> loads OSS modules even when ALSA modules are available.  This bug cannot
> be worked around consistently with policy because discover offers no
> mechanism for blacklisting modules other than editing a conffile.  The
> bug report against discover1 (#220616) has been tagged "wontfix" so I am
> not expecting the discover maintainers to solve the problem.
> 
> Given these facts, what should the ALSA packaging team do?  It seems
> that the alsa packages should Conflict with discover and discover1.

I have a solution.

Hotplug has many many great features. One such feature
== /etc/hotplug/blacklist.d

If ALSA is the preferred sound solution, then the alsa-base maintainer
should present a list in hotplug with all of the traditional "oss"
drivers names in a file called alsa-base. hotplug will indeed not load
these files.

Now, I propose, that since Discover v2 DOES indeed use modprobe to load
its modules... alsa-base should have a similar list in something
like /etc/discover/blacklist.d called alsa-base with the skip="" done
for all of the OSS modules.

Now, this COULD be all addresses, in one way. Force discover and hotplug
to honor a file in /etc/modprobe.d/alsa-base, which is currently there
already but only has a few entries. Or just make sure they call modprobe
vs anything else.

If the entries where there for every OSS module, not just the ones there
now (three redirections only) then it could be done with more ease. Sure
I know it'd make the job of Jordi Mallach, Steve Kowalik, David B.
Harris and Thomas Hood more painful...

But, I'd even be willing to do the grunt work for the file if need be.
It would seem to be a file with a bunch of CNP then edit. Of course, I
am no programmer but understand programming from an Network and Systems
Hardware Analyst POV.

It is an idea, but will anyone think it a good one?
-- 
greg, [EMAIL PROTECTED]

The technology that is
Stronger, better, faster:  Linux


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

Re: discover or alsa? Solution proposal.

[Marco d'Itri]

On Oct 13, Greg Folkert <[EMAIL PROTECTED]> wrote:

> If ALSA is the preferred sound solution, then the alsa-base maintainer
> should present a list in hotplug with all of the traditional "oss"
> drivers names in a file called alsa-base. hotplug will indeed not load
> these files.
Guess what? This is how it works...

-- 
ciao, |
Marco | [8542 dakmyZwg7lGh2]


signature.asc
Description: Digital signature

Re: discover or alsa?

[Marco d'Itri]

On Oct 13, Wouter Verhelst <[EMAIL PROTECTED]> wrote:

> > will probably become mandatory very soon (hint: udev) and needs anyway
> > to support PCI hotplugging for systems with an hotplug PCI bus.
> That doesn't have anything to do with coldplugging. Also, AFAIK, udev is
Sure it does. Why waste time duplicating the infrastructure? Also,
programs like kudzu and discover need a database, while hotplug is
automatically up to date to the installed kernel. This alone should be a
major argument in its favour.

> far from the only /dev implementation in the kernel. I don't think it'll
> suddenly be mandatory.
devfs is dead, deal with this. It has no future, and I expect it will be
removed in the next two years. To learn why udev will probably become
mandatory, read the threads about this in the debian-devel@ archive.

> > > Apart from that, there's also the 'canon' way of managing modules
> > > (/etc/modules), and a number of other packages which will load modules
> > > to be able to do what they're installed for (hardware driver support
> > > packages such as the ALSA ones, but also stuff such as binfmt-support
> > > and nbd-client).
> > ALSA does not loads modules anymore,
> ACPI.
The ACPI modules are not related to hotplug, at least currently.

> > the other packages you mentioned do not load device drivers and are
> > not relevant in this discussion.
> They load modules. This is a suggestion about managing how modules are
> loaded.
non-device modules are not related to hotplug either.

> What's impossible about that?
Impossible, not. Not needed and hard to deploy, yes.

-- 
ciao, |
Marco | [8541 conkbA9aSVJGU]


signature.asc
Description: Digital signature

Re: discover or alsa? Solution proposal.

[Greg Folkert]

On Wed, 2004-10-13 at 20:19 +0200, Marco d'Itri wrote:
> On Oct 13, Greg Folkert <[EMAIL PROTECTED]> wrote:
> 
> > If ALSA is the preferred sound solution, then the alsa-base maintainer
> > should present a list in hotplug with all of the traditional "oss"
> > drivers names in a file called alsa-base. hotplug will indeed not load
> > these files.
> Guess what? This is how it works...

Or at least SUPPOSED to work, when things aren't going the way it
should, tells me not everyone is playing ball in the same park.

I believe that kudzu and all them other hwdetect schemes out there
should also use this method then. You need to have a choke point that
everything else uses. All the stuff should be that way then.

If it is, it doesn't feel that way yet.
-- 
greg, [EMAIL PROTECTED]

The technology that is
Stronger, better, faster:  Linux


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

Re: discover or alsa?

[Wouter Verhelst]

On Wed, Oct 13, 2004 at 08:18:45PM +0200, Marco d'Itri wrote:
> On Oct 13, Wouter Verhelst <[EMAIL PROTECTED]> wrote:
> > > will probably become mandatory very soon (hint: udev) and needs anyway
> > > to support PCI hotplugging for systems with an hotplug PCI bus.
> > That doesn't have anything to do with coldplugging. Also, AFAIK, udev is
> Sure it does. Why waste time duplicating the infrastructure? Also,
> programs like kudzu and discover need a database, while hotplug is
> automatically up to date to the installed kernel. This alone should be a
> major argument in its favour.
> 
> > far from the only /dev implementation in the kernel. I don't think it'll
> > suddenly be mandatory.
> devfs is dead, deal with this.

I wasn't talking about DevFS specifically. Note that, when DevFS was
accepted into mainline kernels, it was expected to be great and
wonderful. Allow me to be a bit sceptical regarding udev -- especially
given the .dev mess and related race conditions you mailed about a while
ago.

For the time being, I'm sticking to static /dev directories. It has
kernel-side issues, but it's well-established, and it works. I expect
many people will think the same way. Frankly, I'm not convinced udev is
going to be as popular as you seem to suggest.

> It has no future, and I expect it will be removed in the next two
> years.

So do I.

> To learn why udev will probably become mandatory, read the threads
> about this in the debian-devel@ archive.

Care to provide me with a reference?

> > > > Apart from that, there's also the 'canon' way of managing modules
> > > > (/etc/modules), and a number of other packages which will load modules
> > > > to be able to do what they're installed for (hardware driver support
> > > > packages such as the ALSA ones, but also stuff such as binfmt-support
> > > > and nbd-client).
> > > ALSA does not loads modules anymore,
> > ACPI.
> The ACPI modules are not related to hotplug, at least currently.

That can all change, at which point it'd suddenly have issues similar to
the issues ALSA had in the past. Your point?

> > > the other packages you mentioned do not load device drivers and are
> > > not relevant in this discussion.
> > They load modules. This is a suggestion about managing how modules are
> > loaded.
> non-device modules are not related to hotplug either.

Again, I was talking about more than just hotplug.

Automagically configuring stuff is nice for desktop systems where those
that are allowed physical access to the system do not necessary have
root privileges. It isn't necessarily a good idea in, e.g., data
centers.

My point is that the proposed system would give a local admin the
ability to manage modules over packages. Even if you think udev is the
future and all the rest is crap, that doesn't have to mean everyone else
agrees with you, or that it's even true.

> > What's impossible about that?
> 
> Impossible, not. Not needed and hard to deploy, yes.

Frankly, that sorta summarizes my opinion about udev. It probably solves
some issues at the kernel side of things, but from what I've seen, it
sure looks ugly.

Does that mean I should completely ignore it?

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


signature.asc
Description: Digital signature

Brazil Summer Time

[Rosilene Oliveira]

Hi,
I'd like to know if there is a version to convert the time of 
application Debian 3.0 to Brazil summer time.
We use the version 3.0, its time has changed to summer time, but here, 
in Brazil, we haven't changed the time yet. It wil change at November 2nd

Bug#276391: O: vgabios -- VGA BIOS software for the Bochs and Qemu emulated VGA card

[Robert Millan]

Package: wnpp
Severity: normal

I intend to orphan the vgabios package.

The package description is:

 The goal of this project is to provide a Video BIOS for Bochs and Qemu.
 This VGA BIOS is very specific to the bochs/qemu emulated VGA card.
 It is NOT meant to drive a physical vga card.
 You will probably fry it if you try. You have been warned.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: kfreebsd-i386 (i386)
Kernel: GNU/kFreeBSD 5.2.1-7
Locale: LANG=C, LC_CTYPE=C (ignored: LC_ALL set to C)

Bug#276392: O: bochs -- IA-32 PC emulator

[Robert Millan]

Package: wnpp
Severity: normal

I intend to orphan the bochs package.

The package description is:

 Bochs is a highly portable free IA-32 (x86) PC emulator written in C++, that
 runs on most popular platforms. It includes emulation of the Intel x86 CPU,
 common I/O devices, and a custom BIOS.
 .
 Bochs is capable of running most operating systems inside the emulation
 including GNU, GNU/Linux, *BSD, FreeDOS, MSDOS and Windows 95/NT.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: kfreebsd-i386 (i386)
Kernel: GNU/kFreeBSD 5.2.1-7
Locale: LANG=C, LC_CTYPE=C (ignored: LC_ALL set to C)

Re: Brazil Summer Time

[Gustavo Franco]

Hi,

I guess that you need tz-brasil package[0], but as you can see it
wasn't packaged in time to woody. You can use "apt pinning" to install
only tz-brasil from "testing" or install wget (its depends) and
tz-brasil manually.

You can ask me or debian-user-portuguese ML for further information.

[0] = http://packages.debian.org/tz-brasil/

Hope that helps,
Gustavo Franco -- <[EMAIL PROTECTED]>

On Wed, 13 Oct 2004 15:50:44 -0300, Rosilene Oliveira
<[EMAIL PROTECTED]> wrote:
> Hi,
> I'd like to know if there is a version to convert the time of
> application Debian 3.0 to Brazil summer time.
> We use the version 3.0, its time has changed to summer time, but here,
> in Brazil, we haven't changed the time yet. It wil change at November 2nd.
> I wait for help.
> Thank's
> Rose

Re: Brazil Summer Time

[Andre Luis Lopes]

Hi,

On Wed, Oct 13, 2004 at 03:50:44PM -0300, Rosilene Oliveira wrote:
> Hi,
> I'd like to know if there is a version to convert the time of 
> application Debian 3.0 to Brazil summer time.
> We use the version 3.0, its time has changed to summer time, but here, 
> in Brazil, we haven't changed the time yet. It wil change at November 2nd.
> I wait for help.

You should probably be asking on debian-user-portuguese@lists.debian.org
or [EMAIL PROTECTED] This list is for Debian development
only.

Anyway, check http://br-linux.org/noticias/003568.html out. It will help
you regarding your problems (sorry, Brazilian Portuguese only).

-- 
++--++
||  André Luís Lopes [EMAIL PROTECTED]||
||   http://people.debian.org/~andrelop ||
||  Debian-BR Projecthttp://www.debian-br.org   ||
||  Public GPG KeyID 9D1B82F6   ||


signature.asc
Description: Digital signature

Re: Brazil Summer Time

[Gustavo Franco]

> [...]
> 
> [0] = http://packages.debian.org/tz-brasil/

I'm sorry, the right url is "http://packages.debian.org/tz-brasil";
that slash in the end doesn't exists.

--
Gustavo Franco -- <[EMAIL PROTECTED]>

Re: discover or alsa?

[Joshua Kwan]

On Wed, 13 Oct 2004 10:30:47 +0200, Thomas Hood wrote:
> Lots of users are reporting that ALSA sound doesn't "just" work when
> they install it.  The cause of the problem is the fact that discover
> loads OSS modules even when ALSA modules are available.  This bug cannot
> be worked around consistently with policy because discover offers no
> mechanism for blacklisting modules other than editing a conffile.  The
> bug report against discover1 (#220616) has been tagged "wontfix" so I am
> not expecting the discover maintainers to solve the problem.

Well, no. Now discover1 (as yet unreleased) has support for an
/etc/discover.d dir where you can have something akin to
/etc/hotplug/blacklist.d/alsa-base. Of course, once that discover1 upload
is made, the bug goes to the ALSA maintainers.

I've removed the wontfix tag - I hope this conclusion is satisfactory to
you.

-- 
Joshua Kwan

Re: discover or alsa?

[Ian Murdock]

On Wed, 2004-10-13 at 11:12 +0200, Thomas Hood wrote:
> On Wed, 2004-10-13 at 10:57, Petter Reinholdtsen wrote:
> > [Thomas Hood]
> > Isn't this only a problem with discover1?  I thought discover (v2) had
> > a mechanism to detect if OSS or ALSA was used.
> 
> 
> If there is such a mechanism then it isn't working.

It should. The current version of discover (v2) loads OSS drivers if the
version of the kernel is <= 2.4 and ALSA drivers if the version is
>= 2.6. There's currently no mechanism for telling the system to
load ALSA drivers when running 2.4, but we intend to
tackle that (and related configuration issues) in discover 2.1.x.

> The discover maintainers ended that discussion with a decision not to
> fix the bug in discover1.  The bug _may_ be fixed in discover at some
> time in the future, presumably post-sarge.  The remaining question is
> how alsa should deal with this situation.  Conflict with discover[1]? 
> Add a paragraph to the alsa-base README telling how to fix the problem
> by hand?  Add code to the alsa initscript which rmmods OSS modules?

I can't speak for discover1, as that is maintained by a different group
now, but I suspect the reason this was marked "wontfix" was because
discover1 has no built in mechanism for multiple versions of things, so
there's no easy way for it to support both ALSA and OSS at the
same time. discover2, on the other hand, has built in support for this.

-- 
Ian Murdock
317-578-8882 (office)
http://www.progeny.com/
http://ianmurdock.com/

"A door is what a dog is perpetually on the wrong side of." --Ogden Nash

Re: discover or alsa?

[Ian Murdock]

On Wed, 2004-10-13 at 10:51 +0200, Marco d'Itri wrote:
> On Oct 13, Thomas Hood <[EMAIL PROTECTED]> wrote:
> 
> > Lots of users are reporting that ALSA sound doesn't "just" work when
> > they install it.  The cause of the problem is the fact that discover
> > loads OSS modules even when ALSA modules are available.  This bug cannot
> > be worked around consistently with policy because discover offers no
> > mechanism for blacklisting modules other than editing a conffile.  The
> > bug report against discover1 (#220616) has been tagged "wontfix" so I am
> > not expecting the discover maintainers to solve the problem.
> 
> Discover should not try to load drivers for PCI devices AT ALL, we have
> hotplug for this.

That's funny, I've been saying the same thing about hotplug ever since
the PCI stuff was turned on and boot time increased by 25%..
-- 
Ian Murdock
317-578-8882 (office)
http://www.progeny.com/
http://ianmurdock.com/

"A door is what a dog is perpetually on the wrong side of." --Ogden Nash

Re: discover or alsa?

[Daniel Burrows]

On Wednesday 13 October 2004 02:18 pm, Marco d'Itri wrote:
> udev will probably become mandatory

  At the moment, if your block devices aren't listed in /sys/block, udev seems 
to ignore them and to forbid you from creating them manually, at least 
in /dev.  This made a CD writer inaccessible on a computer I was trying to 
fix recently until I accessed the CD drive via /proc.

  udev has some nice features, but until it works more reliably, I'd like it 
kept as far away from the standard install as possible.

  Daniel

-- 
/--- Daniel Burrows <[EMAIL PROTECTED]> --\
|"Is it too late to extricate myself|
| from this plot line?" |
|"Yes." -- Fluble   |
\- A duck! -- http://www.python.org /


pgpJFls66LDpW.pgp
Description: PGP signature

Re: discover or alsa?

[Ian Murdock]

On Wed, 2004-10-13 at 12:53 -0700, Joshua Kwan wrote:
> On Wed, 13 Oct 2004 10:30:47 +0200, Thomas Hood wrote:
> > Lots of users are reporting that ALSA sound doesn't "just" work when
> > they install it.  The cause of the problem is the fact that discover
> > loads OSS modules even when ALSA modules are available.  This bug cannot
> > be worked around consistently with policy because discover offers no
> > mechanism for blacklisting modules other than editing a conffile.  The
> > bug report against discover1 (#220616) has been tagged "wontfix" so I am
> > not expecting the discover maintainers to solve the problem.
> 
> Well, no. Now discover1 (as yet unreleased) has support for an
> /etc/discover.d dir where you can have something akin to
> /etc/hotplug/blacklist.d/alsa-base. Of course, once that discover1 upload
> is made, the bug goes to the ALSA maintainers.

I will add this support to discover2 as well, since it currently suffers
from the same problem as discover1 with respect to blacklisting modules.

-- 
Ian Murdock
317-578-8882 (office)
http://www.progeny.com/
http://ianmurdock.com/

"A door is what a dog is perpetually on the wrong side of." --Ogden Nash

Re: ppp/ip-up vs. network/if-up

[Thomas Hood]

On Wed, 13 Oct 2004 09:50:04 +0200, Adrian 'Dagurashibanipal' von Bidder
wrote:
> I think Robert thought about if the scripts are rerun if pppd loses 
> connection and reconnects - typically with a different IP.


FYI: The experimental ifupdown does not currently rerun "up" scripts if
pppd reconnects.

I can see why, in the case of PPP interfaces, that might be desired.  I am
not sure that we should implement it, though.  It would depart from the
way ifupdown "up" and "down" scripts have worked in the past for other
interfaces.

-- 
Thomas Hood

Re: discover or alsa?

[Thomas Hood]

On Wed, 2004-10-13 at 21:53, Joshua Kwan wrote:
> Well, no. Now discover1 (as yet unreleased) has support for an
> /etc/discover.d dir where you can have something akin to
> /etc/hotplug/blacklist.d/alsa-base. Of course, once that discover1 upload
> is made, the bug goes to the ALSA maintainers.
>
> I've removed the wontfix tag - I hope this conclusion is satisfactory to
> you.


Very satisfactory, thanks.  Will this feature be added to both discover1
and discover?

BTW the "wontfix" tags is still there (#220616).

-- 
Thomas

Re: about volatile.d.o/n

[Jesus Climent]

On Mon, Oct 11, 2004 at 02:32:01PM +0100, paddy wrote:
> 
> Hmm, deja vu ;)
> 
> What happens to packages that become orphaned?

What happens with a package orphaned from stable?

-- 
Jesus Climent  info:www.pumuki.org
Unix SysAdm|Linux User #66350|Debian Developer|2.4.27|Helsinki Finland
GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429  7E18 66FC 1D7F 8694 6D69

There's nothing that can't be done.
--McManus (The usual suspects)

Re: ppp/ip-up vs. network/if-up

[Richard A Nelson]

On Wed, 13 Oct 2004, Thomas Hood wrote:

> FYI: The experimental ifupdown does not currently rerun "up" scripts if
> pppd reconnects.

Is not the same true for DHCP ?

> I can see why, in the case of PPP interfaces, that might be desired.  I am
> not sure that we should implement it, though.  It would depart from the
> way ifupdown "up" and "down" scripts have worked in the past for other
> interfaces.

I don't see how we can get this kind of support without ppp and dhcp
support... The two would be very similiar (the potential to get the
same address, or a new one).

It would take some thought to handle all the possibilities properly
but the end result would be *very* nice.  I've tried a few times,
and wound up with scripts in ppp, dhcp, and network - all modelled
similiar to the DHCP state management.
-- 
Rick Nelson
Linux poses a real challenge for those with a taste for late-night
hacking (and/or conversations with God).
-- Matt Welsh

Re: about volatile.d.o/n

[Jesus Climent]

On Mon, Oct 11, 2004 at 12:34:02PM -0500, John Hasler wrote:
> 
> I see no reason for new packages to ever go into volatile.  Such things
> belong in backports.

You seem to have missed a very important ground of volatile: add new packages
in a controled way when backporting code to the version in stable is far more
difficult than guarantee a new version being stable enough to be updated. With
all the policy added to it.

-- 
Jesus Climent  info:www.pumuki.org
Unix SysAdm|Linux User #66350|Debian Developer|2.4.27|Helsinki Finland
GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429  7E18 66FC 1D7F 8694 6D69

I'm a mog: half man, half dog. I'm my own best friend!
--Barf (Spaceballs)

fishing hooks-samples

[Distribuidora del Nordeste]

Dear Sirs:
 
 
We are here in Argentina wholesalers with a long chain of retailers that
purchase our "Mystix" products. We are looking for a China factory that can
provide us quality products. We buy habitually, 92611, 92641, 277E, 277F, 2320,
2330 and 3191 series (referred to Mustad nomination) and Chinu hooks w/ rings.
Our level of demand is around 2.000.000 hooks a year. If you can make this
products, please contact to our International Department and make us know your
best prices for a mentioned series and if possible, send us samples to
test.
  
Best regards,
 
Luis Belmonte
Distribuidora del Nordeste S.C.
Constitución 964
2000-Rosario
Argentina
Tel.54-341-4351800
Fax:54-341-4388551
E-mail: [EMAIL PROTECTED]
Web-site: www.dnpesca.com.ar
Distribuidora del Nordeste
S.C.
Distribuidora del Nordeste
S.C.
BEGIN:VCARD
VERSION:2.1
N:Nordeste;Distribuidora del
FN:Distribuidora del Nordeste S.C.-
EMAIL;PREF;INTERNET:[EMAIL PROTECTED]
REV:20041013T201408Z
END:VCARD

Re: about volatile.d.o/n

[Jesus Climent]

On Mon, Oct 11, 2004 at 07:22:15PM +0100, Henning Makholm wrote:
> 
> > To be fair, the issue is that if were just rules, there wouldn't
> > be a need.
> 
> Why not? I pretty much want to have the spamfilter rules on my mail
> box updated from time to time. Currently that has lead me to put
> a low-pinned unstable in sources.list and get spamassassin from there.
> But it was not meant to suddenly pull in spamassassin3. If volatile
> had existed, I could have avoided that.

Read the thread. There are plenty of points you seems to be missing with your
statement.

J

-- 
Jesus Climent  info:www.pumuki.org
Unix SysAdm|Linux User #66350|Debian Developer|2.4.27|Helsinki Finland
GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429  7E18 66FC 1D7F 8694 6D69

London. You know... fish, chips, cup o' tea, bad food, worse weather,
Mary-fucking-Poppins... London!
--Avi (Snatch)

Re: about volatile.d.o/n

[John Hasler]

I wrote:
> I see no reason for new packages to ever go into volatile.  Such things
> belong in backports.

Jesus Climent writes:
> You seem to have missed a very important ground of volatile: add new
> packages in a controled way when backporting code to the version in
> stable is far more difficult than guarantee a new version being stable
> enough to be updated.

New versions of packages already in Stable are not new packages.  Clamav
1.0 would be a new version.  BetterVirusGetter would be a new package.
-- 
John Hasler

Re: Common set of debconf templates

[Brian Sutherland]

On Wed, Oct 13, 2004 at 08:38:58AM -0400, sean finney wrote:
> On Wed, Oct 13, 2004 at 11:51:00AM +0200, Brian Sutherland wrote:
> > The package includes the template-package's templates at build
> > (debhelper style as suggested before).
> > 
> > Then up to date translations can be ensured by installing a
> > debconf-translation-templates meta package or templates package before 
> > the package.
> 
> if the templates are included at build-time by a debhelper-style script,
> there's no need for a runtime dependency for these templates.

How do you then solve the problem of the translations and such becoming
out of date?

(Maybe it is not such a problem if the package is rebuilt frequently,
but the translation changes infrequently)

> 
> > (Pre-depends / Recommends / Installer business??)
> 
> i think Pre-depends should be avoided at any possible cost.  this
> unfortunately means that the REGISTER suggestion won't reliably work,
> which is really too bad because that would have been the most graceful
> solution.

What do you do instead of REGISTER if each package wants to have it's
own question? Change the directories of the questions when copying?

> over the past week i've been in contact with joeyh about the
> feasability of doing this with a debhelper-style script, and think
> i have the workings of a primitive version hashed out with him.

Thanks, Great!! let me know if you need somebody to test it. (or even
help)

-- 
Brian Sutherland

Re: Common set of debconf templates

[Agustin Martin]

On Wed, Oct 13, 2004 at 08:38:58AM -0400, sean finney wrote:

> if the templates are included at build-time by a debhelper-style script,
> there's no need for a runtime dependency for these templates.
> 

But for shared/* debconf templates this means that all packages using that
template need to be rebuilt against the new template-providing package
after every change in its template contents. I think that is better to
split the roles, one template contains the real template and is not shared,
something like:

Template: dictionaries-common/default-ispell
Type: select
Choices: ${choices}
Description: The full and internationalized template description
Choices-es: ${choices}
Description-es: The template spanish translation

and shared templates with a dummy description (a single whitespace is
enough) for the packages that share the question (here all ispell dicts),
something like

Template: shared/packages-ispell
Type: text
Description: Dummy template, DO NOT TRANSLATE!!!

So things like the one below (in some sort of pseudo language, so untested)
in all of the owners .config files

sharedq = shared/packages-ispell
globalq = dictionaries-common/default-ispell

newchoices = metaget_owners($sharedq)
oldchoices = get_choices($globalq)

if ( $newchoices != $oldchoices ) {
  set_choices for $globalq to $newchoices
  unset_seen_flag ($globalq)
}

ask ($globalq)

and the appropriate stuff in the maintainer scripts should do the job.
This way upgrading po files only in package containing $globalq
completely upgrades the templates for this question, without the need of
rebuilding the packages sharing the related question. We are using
something of this kind in dictionaries-common for ispell dicts and
wordlists, although things are more complicated for us, because each
ispell dict can provide more than one possibility to the global owners
field, but doing things with just the package names should be much
easier.

> > (Pre-depends / Recommends / Installer business??)
> 
> i think Pre-depends should be avoided at any possible cost.  this
> unfortunately means that the REGISTER suggestion won't reliably work,
> which is really too bad because that would have been the most graceful
> solution.
> 

AFAIK templates are all read and registered to debconf database before
the .config files are run. Pre-Dependencies stage (configuring packages on
which other pre-depend) takes place later. Why register would not work if
called from .config and the package containing the global question is also
being installed? I think a plain dependency is all what is needed to
make sure the global template is present and read at the .templates stage. 

By the way, REGISTER looks a really nice approach for questions having
an essentially similar debconf template (not to be messed with shared/*
debconf templates). It might even be useful for shared/* questions instead
of the above schema.

Cheers,

-- 
Agustin

Re: Xsession doesn't use umask setting from /etc/login.defs

[Tomas Fasth]

Branden Robinson wrote:
[Redirecting to debian-devel; followups set.]
On Mon, Sep 20, 2004 at 02:29:32PM +0200, Wouter Hanegraaff
wrote:
Hi,
After a fresh sarge install, I'm having problems with umask
settings. In /etc/login.defs I set umask to 002, and that works
for logging in on the console or remote via ssh. However, if I
use {g,x,k}dm I keep getting an umask of 022, because Xsession
is started by the display manager which has a default umask of
022.
It seems that Xsession doesn't change the UMASK at all. Should
it do so? If not, which program should set the umask during a
graphical login?
Searching Google for "xsession umask" will give you some hints.
/etc/login.defs explicitly indicates that it is "Configuration
control definitions for the login package", and many of its
parameters are inapplicable to display managers, or already
implemented in parallel (e.g., how long do wait after a failed
login before displaying the prompt/greeter again?).
I believe that /etc/login.defs _is_ the right place to define the
default umask property.
// Tomas
--
Tomas Fasth <[EMAIL PROTECTED]>
GnuPG 0x9FE8D504

Re: ppp/ip-up vs. network/if-up

[Robert Collins]

On Wed, 2004-10-13 at 22:10 +0200, Thomas Hood wrote:
> On Wed, 13 Oct 2004 09:50:04 +0200, Adrian 'Dagurashibanipal' von Bidder
> wrote:
> > I think Robert thought about if the scripts are rerun if pppd loses 
> > connection and reconnects - typically with a different IP.
> 
> 
> FYI: The experimental ifupdown does not currently rerun "up" scripts if
> pppd reconnects.
> 
> I can see why, in the case of PPP interfaces, that might be desired.  I am
> not sure that we should implement it, though.  It would depart from the
> way ifupdown "up" and "down" scripts have worked in the past for other
> interfaces.

If the goal is something like:
bring my adsl link up when the box starts.
run an iptables script when the link ataches, every time
if ppp gives up completely on the link, sms my phone
AND only use ifupdown scripts, not the ppp specific ones

then something has to be implemented. Note that ethernet interfaces with
dhcp would also benefit - there are dhcp customisation
(/etc/dhclient-{enter,exit}-hooks scripts that folk customise to run
iptables or whatever after the link comes up, because the ip address may
change. Wireless too is another one.

I think there is basically a general class of network event to represent
these, and if ifupdown is taught it, and then dhcp, ppp,  are
hooked into it, the result would be fanastic. That class is link events,
as opposed to interface ones. I.e. add link-pre-up.d, link-up.d,
link-post-down.d directories.

where link-pre-up.d might be invoked by dhclient when a wireless
interface gets link, before the dhcp requests are sent, link-up.d after
the ip address is allocated, link-post-down.d after the link is found to
be dead for whatever reason. (link-down.d is unlikely to be needed IMO,
but perhaps we should add it for completeness..)

So for my goal above, I'd:
set ppp0 to auto in /etc/interfaces
add an iptables paranoid rule for the interface in the link-pre-up.d
scripts dir.
add an iptables customisation-for-the-up in the link-up.d dir
add the sms script to the if-post-down.d

-Rob


-- 
GPG key available at: .


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

Bug#276410: ITP: png2ico -- converts .PNG files to Windows .ICO icon resources

[Manfred Brandl]

Package: wnpp
Severity: wishlist


* Package name: png2ico
  Version : 0.0.20241208
  Upstream Author : Matthias Benkmann <[EMAIL PROTECTED]>
* URL : http://www.winterdrache.de/freeware/png2ico/index.html
* License : GPL
  Description : converts .PNG files to Windows .ICO icon resources

Converts PNG files to Windows icon resource files.
This reopens Bus #173050. I do know that icoutils also can do that task,
but I already have debianzed png2ico. I am not a debian Developer.
Maybe someone can download the file from ftp://home.brandl.net/put/png2ico/ and 
dupload them.

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

(no subject)

[Nsl602]

CAN YOU TELL ME HOW TO MAKE MY ICONS SMALLER ON THE START MENU 
PLEASE   THANK YOU NANCY

Internet Egypt Server Notification

[mx.backup.ie-eg.com]

An e-mail you sent with message-id NOQUEUE
was modified by our mail scanning software.

The recipients were: <[EMAIL PROTECTED]>

Here are the details of the modification:

An attachment named [EMAIL PROTECTED] was removed from this document as it
constituted a security hazard. If you require to send this document , please 
contact
the recipients .

Re: Common set of debconf templates

[Joey Hess]

Brian Sutherland wrote:
> What about a rule that says:
> 
> - If the package name is the same as the directory in the debconf database
>   then use that package's templates take priority.
> - Else, as before.

Suppose that:

1. package A is preconfigured, and has an A/template
2. package B is preconfigured (separate debconf run), also has A/template.

Debconf has no way to know if package B has a newer or an older version
of A/template than the one it already has from package A.

-- 
see shy jo

Re: Package idea, Debian-Firewall.

[nicklas (smurfd)]

ons 2004-10-13 klockan 14.04 skrev Steve Kemp:
> On Wed, Oct 13, 2004 at 06:13:36AM +0200, nicklas (smurfd) wrote:
> 
> > I have had  a package idea, for a long time now. The idea, was a
> > package, containing a "Flush-all" firewall script. Adding this script to
> > be ran at bootup. Just for the simplicity. I tend to keep forgetting to
> > add it myself.
> 
>   I think anybody who knows enough to create a firewall will not
>  omit the flushing.

True true!

> 
>   Use update-rc.d, please.
> 
>   http://www.debian-administration.org/?article=28

Ah, okey. Thanks for pointing that out! Looks way nicer. I will give
that a shot. 

Great site btw, lots of good reading.

> Steve
> --
> # The Debian Security Audit Project.
> http://www.debian.org/security/audit

Re: Package idea, Debian-Firewall.

[nicklas (smurfd)]

ons 2004-10-13 klockan 11.39 skrev Javier Fernández-Sanguino Peña:
> On Wed, Oct 13, 2004 at 06:13:36AM +0200, nicklas (smurfd) wrote:
> > Hey Debian-devels!
> > 
> > I have had  a package idea, for a long time now. The idea, was a
> > package, containing a "Flush-all" firewall script. Adding this script to
> > be ran at bootup. Just for the simplicity. I tend to keep forgetting to
> > add it myself.
> 
> You could actually try to convince the iptables maintainer to allow users 
> to set this kind of "deny all" setup in postinst through debconf. It should 
> be rather easy to do actually, since you just have to execute an iptables 
> script (similar to what you provided) and run '/etc/init.d/iptables save'.
> I tried to do this a while back without any success (see #212692).
> 
> There are a lot of ways to setup a firewall in Debian [1] I rather not have 
> yet another package to do this.
> 
> Regards
> 
> Javier
> 
> 
> [1] 
> http://www.debian.org/doc/manuals/securing-debian-howto/ch-sec-services.en.html#s-firewall-setup

That Do make abit more sense, i must admit. 
Ill drop him a mail, see what he says :)
Yeah, either a "drop all" rule, or load a firewall script, you got
already on your disk or on a floppy/cd.

regards 

nicklas

Re: Xsession doesn't use umask setting from /etc/login.defs

[GOTO Masanori]

At Thu, 14 Oct 2004 00:14:58 +0200,
Tomas Fasth wrote:
> > /etc/login.defs explicitly indicates that it is "Configuration
> > control definitions for the login package", and many of its
> > parameters are inapplicable to display managers, or already
> > implemented in parallel (e.g., how long do wait after a failed
> > login before displaying the prompt/greeter again?).
> 
> I believe that /etc/login.defs _is_ the right place to define the
> default umask property.

It's just my wishlist, but I think it's good idea to provide a summary
that describes what file affects the bootstrap configuration in
debian, by a professional of this kind of area...

Regards,
-- gotom

Re: Brazil Summer Time

[GOTO Masanori]

At Wed, 13 Oct 2004 15:50:44 -0300,
Rosilene Oliveira wrote:
> I'd like to know if there is a version to convert the time of 
> application Debian 3.0 to Brazil summer time.
> We use the version 3.0, its time has changed to summer time, but here, 
> in Brazil, we haven't changed the time yet. It wil change at November 2nd.
> I wait for help.

Timezone is defined in libc6 package: look at /usr/share/zoneinfo/ and
glibc source timezone/sourthamerica.  However, it's hard to update
woody's glibc - at least I have no plan to update it for woody.

BTW, I've duploaded the glibc 2.3.2.ds1-18 which includes the latest
timezone data with Brazilian summer time changes.  That version should
go to sarge, so this problem will be fixed in sarge/sid.

Brazilian goverment does not announce summer time changes early
in every year.

Regards,
-- gotom