Re: Do not touch l10n files (was Re: DDTP issue)

[Fabio Massimo Di Nitto]

On Thu, 15 May 2003, Gustavo Noronha Silva wrote:

> Em Tue, 13 May 2003 06:57:45 +0200 (CEST), Fabio Massimo Di Nitto
> <[EMAIL PROTECTED]> escreveu:
>
> > > Now Apache maintainers are telling us that they chose another layout
> > > and we are bound to it.
> >
> > Yes because the official maintainer is responsable for the description of
> > a package. Including the layout and this was told already in the same
> > message above.
>
> This is the same as telling me I should translate 'yellow submarine' to
> 'amarelo submarino', when the right thing in pt_BR is 'submarino amarelo'.

Not at all. None of us did ask them to change sentences or words used for
the translation.

> Why do you bother with the layout of the translation? The translators are
> the authorities when it comes to their languages. I think we should not
> be put in a jail and be unable to decide how we think our users should
> see the message.
>
> Let's make it clear: we translate stuff to make it more readable to
> our fellow compatriots, making the translation look bad to our users
> does not help achieving the goal.

All this other stuff already found several answers in the thread. No need
to reanswer them again and restart from scratch.

Thanks
Fabio

-- 
Our mission: make IPv6 the default IP protocol
"We are on a mission from God" - Elwood Blues

http://www.itojun.org/paper/itojun-nanog-200210-ipv6isp/mgp4.html

Re: Where are translated man pages packaged?

[Fabio Massimo Di Nitto]

On Thu, 15 May 2003, Wouter Verhelst wrote:

> > When grabbing old mails, I found an answer from a developer who told me
> > that his package is part of base and thus he wants to keep it small.
> > Is this indeed an important issue?
>
> I'd say yes; but those packages will not usually be uninstalled, so I
> see it as no problem to put manpages for packages in base in a
> manpages-xx package.
>
>

I agree with Wouter. For me would be an issue having the base system
bigger than it is now. Specially preparing very small "black box" where i
need to save as much space as i can even during the installation phase.

Fabio

(Denis this is nothing against translation.. just a matter of space ;))

-- 
Our mission: make IPv6 the default IP protocol
"We are on a mission from God" - Elwood Blues

http://www.itojun.org/paper/itojun-nanog-200210-ipv6isp/mgp4.html

Re: security in testing

[Brian Nelson]

Matt Zimmerman <[EMAIL PROTECTED]> writes:

> On Fri, May 16, 2003 at 10:40:10AM +1000, Anthony Towns wrote:
>
>> On Thu, May 15, 2003 at 10:06:47AM -0400, Matt Zimmerman wrote:
>> >   release
>> >   (Or "released version", "baseline") A version of
>> >  a piece of software which has been made public (as opposed to
>> >  a version that is in development, or otherwise unreleased).
>> 
>> So, you're contending that "testing" hasn't been made public? Or you're
>> contending that people regularly upload development versions of packages
>> to testing? Or are you contending that there's a line somewhere between
>> annual updates and daily updates that makes security support unnecessary?
>
> No, I'm contending that testing is in development.  It's a daily snapshot.
> It doesn't make any sense to release patches and security advisories for a
> snapshot which will be overwritten in the near future.

Uh, if "near future" == a few days, I doubt anyone would be terribly
concerned with testing's lack of security updates.  The problem is when
the "in the near future" means "in a few months".

-- 
Looks like excitement by repetition!


pgpej06uUPqjE.pgp
Description: PGP signature

Re: security in testing

[Sven Luther]

On Thu, May 15, 2003 at 07:30:36PM -0400, Michael Stone wrote:
> On Thu, May 15, 2003 at 07:07:16AM +0200, Sven Luther wrote:
> >But we don't advertize this, so it is natural that people make the
> >mistake and use testing instead of unstable.
> 
> People say this all the time. Then other people go around telling
> everyone to run testing. I'm not sure how to fix misplaced advocacy.

Please, have a look at our announement when first testing was created.
Read well what _We_, as debian, said and then tell me that again.

The reality is that _We_ advocated testing as two things :

  1) a release helping tool, with all arches in sync and so on. This has
 served us well, altough there is often a big lag, and the loose
 release schedule is a strain on developers who have no good idea of
 how to best schedule their own packaging effort. But all in all, it
 works.

  2) a way for people for which stable is too outdated to run more
 advanced software, without suffering from the breakages of unstable.
 By saying this we clearly imply that it is better to run testing
 than unstable. Sure, this was before we had time to test testing,
 and before we became aware of the big stalls implied, and the fact
 that security wise testing is worse than unstable. But this, only
 the insiders, and even then, not everyone, is well informed about.

This second goal is today a total failure, it must not need be so,
but it is today, and we are putting many people at risk. And i think
even that this is against the "We wont hide problems" of our social
contract because there is a small step between not being loud enough
about a fact and hiding it.

I still think that the second goal can be achieved. Probably the fact to
use testing-proposed-update for security and RC bugs would be enough, i
don't know, only experience will tell. That said, again, almost nobody
(of the developers) is aware of the fact that we can (and should) use
testing-proposed-update for that.

All in all, this long thread is only a (mis)-communication problem, as
often is, and we would loose less time if we stopped hiding our head in
the sand and stop alos to use arguments like 'but you should know' or
'this is not a problem, just ...'.

Friendly,

Sven Luther

Re: Screwed up fonts in _ALL_ Qt applications :(

[Chris Cheney]

On Sun, May 11, 2003 at 09:00:02PM -0700, Brian Nelson wrote:
> Something related to #189750, perhaps?
> 
> -- 
> Looks like excitement by repetition!

It is very unlikely that it is related to 189750, but it could be
something related to how fontconfig chooses fonts. For example the
medium font selection in Konsole ends getting a CJK font instead of a
regular monospace one, which makes it look very wide.

Chris

Re: ABI change in libsensors1 (from lm-sensors)

[Chris Cheney]

Why not kick upstream into releasing 2.7.1 with proper soname bump to
libsensors2 (Make sure they are aware they screwed up...). Then upload
libsensors2, there are only 8 sources depending on libsensors1 now so
it wouldn't be a big deal to rebuild those few in any case.

Chris

sources depending on libsensors1

hardware-monitor
kdebase
ksensors
lm-sensors
mrtgutils
wmgtemp
wmsensors
xsensors

Re: conflicts-based solution (was Re: security in testing)

[Matthias Urlichs]

Hi, Anthony Towns wrote:

> If someone
> would like to volunteer whose not in with the security team, or a
> release assistant, please talk to herr DPL about doing so, rather than
> me.

[ patiently waiting for AM approval ]

Will do.

And, thanks for the info. Whether to further automate this (i.e. the "do
we need that 'tpu-approved' list at all?" question) I'll ask some other
time.  ;-)

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
-- 
share, n.:
To give in, endure humiliation.

Re: Where are translated man pages packaged?

[Colin Watson]

On Fri, May 16, 2003 at 07:09:00AM +0200, Fabio Massimo Di Nitto wrote:
> On Thu, 15 May 2003, Wouter Verhelst wrote:
[restored attribution you snipped ...]
> > On Thu, May 15, 2003 at 05:48:15PM +0200, Denis Barbier wrote:
> > > When grabbing old mails, I found an answer from a developer who told me
> > > that his package is part of base and thus he wants to keep it small.
> > > Is this indeed an important issue?
> >
> > I'd say yes; but those packages will not usually be uninstalled, so I
> > see it as no problem to put manpages for packages in base in a
> > manpages-xx package.
> 
> I agree with Wouter. For me would be an issue having the base system
> bigger than it is now. Specially preparing very small "black box" where i
> need to save as much space as i can even during the installation phase.

Can't you basically just 'rm -rf /usr/share/doc /usr/share/man' if
you're tight on space?

-- 
Colin Watson  [EMAIL PROTECTED]

Re: security in testing

[Matthias Urlichs]

Hi, Anthony Towns wrote:

> Yes, and funnily enough, uploads to -p-u have to be processed by the
> release manager, either Joey for stable, or me for testing.

This may be a stupid question, but why is there a "have to" here (we're
not in freeze mode!), and would you be OK with sharing this part of your
responsibility?

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
-- 
 hmm, lunch does sound like a good idea
 would taste like a good idea too

Re: security in testing

[Matthias Urlichs]

Hi, Manoj Srivastava wrote:

> Finding a cure is not a problem: we know what the cure is; do
>  the same thing the security team does for stable.

A few other cures have been advocated. I'll not repeat them here.

As in medicine, figuring out what the RIGHT cure is is the problem.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
-- 
Learned men are the cisterns of knowledge, not the fountainheads.

Re: Packages up for adoption: ap-utils, igal, tcpflow

[Steve Kemp]

On Thu, May 15, 2003 at 09:39:54PM +0100, Robert McQueen wrote:
> Just a brief note to draw people's attention to the following RFAs
> I filed a few days ago:
>  #193116 ap-utils -- Access Point SNMP Utils for Linux
>  #193117 igal -- online image gallery generator
>  #193118 tcpflow -- TCP flow recorder

  I'd take tcpflow if it's not already been claimed, it nicely
  comliments dsniff which I already have.

Steve
-- 


pgpym700RqGop.pgp
Description: PGP signature

Re: Where are translated man pages packaged?

[Martin Quinson]

On Thu, May 15, 2003 at 11:24:14AM +0200, Denis Barbier wrote:
> Hi,
> 
> There is currently no consensus whether translated man pages should
> be shipped along with original man pages or within manpages-xx packages.
> Unfortunately this leads to conflicts when a translation is first
> shipped by the latter, then incorporated into the former (e.g. when
> it becomes part of upstream tarball).
> 
> Some developers are reluctant to include French translated man pages and
> ask me to ship them in manpages-fr.  How can I make them change their
> mind?  Is there a consensus that translated man pages must go with
> original man pages?  Are exceptions needed for some packages?

I would say that the manpages-XX should disappear as source packages, and all
manpages-XX bin packages should be generated from the same source package.
That way, it would be really easier to check if the translations are
uptodate or not.
Alioth can be very useful to base a group in charge of maintaining this
package.

To answer your question, I would say that translated manpages have to be in
the same package than the original one when possible.
Concerning packages in base, where space is a concern, as far as dpkg cannot
handle properly translations (ie, until sarge+12 :) they can be placed in
the manpages-XXX packages. 

But that's only my opinion, Mt.

-- 
Tout dormeur a en lui un lève tard qui sommeil.

Re: Where are translated man pages packaged?

[Fabio Massimo Di Nitto]

On Fri, 16 May 2003, Colin Watson wrote:

> > I agree with Wouter. For me would be an issue having the base system
> > bigger than it is now. Specially preparing very small "black box" where i
> > need to save as much space as i can even during the installation phase.
>
> Can't you basically just 'rm -rf /usr/share/doc /usr/share/man' if
> you're tight on space?

Of course... but also during the installation?

I don't mind at all cleaning up after... but during is a bit of a pain..

more than once i had to install small dns servers on boxes with less than
100Mb flash and stuff like that... so basically also the minimal
installation has to be tight.. then rm doc and man and after install the
minimum sets of pkgs to provide the services.

Fabio

-- 
Our mission: make IPv6 the default IP protocol
"We are on a mission from God" - Elwood Blues

http://www.itojun.org/paper/itojun-nanog-200210-ipv6isp/mgp4.html

Re: Do not touch l10n files

[Martin Quinson]

On Thu, May 15, 2003 at 01:47:37PM -0500, Branden Robinson wrote:
> On Thu, May 15, 2003 at 03:40:57PM +0200, Denis Barbier wrote:
> > On Thu, May 15, 2003 at 01:25:56PM +0100, Thom May wrote:
> > > * Denis Barbier ([EMAIL PROTECTED]) wrote :
> > > > It has already been told more than once: in French, an itemized list is
> > > > preferred over a comma separated list when it gives a very long 
> > > > sentence.
> > >
> > > Now, preferred, in English, means "more desirable than another" not "we 
> > > must
> > > use this at all costs". So, again. We have said we don't like the layout 
> > > and
> > > would *prefer* that the translators change it. 
> > 
> > Following your definition of "prefer", you ask us to change it, but will
> > accomodate otherwise.  This is fine with me, let's see what the translator
> > will decide.
> 
> It's the package maintainer's preference that controls, unless he is
> overruled.  The procedures for overruling a maintainer's decision are
> described in the Constitution.

I guess that the translator (CCed) will prefer an ugly looking description
than getting in such war, which already took too much useful energy from
useful work. I mean, I still think that forcing the way stuff is translated
is not very wise from maintainers, but I naturally admit that when
translators and maintainers cannot find an agreement, the maintainer have to
be right.

Sigh, Mt.

-- 
If the facts don't fit the theory, change the facts.
  -- Albert Einstein

Re: security in testing

[Michael Stone]

On Thu, May 15, 2003 at 09:15:21PM -0500, Anthony Towns wrote:
Please don't bother listening to or arguing with Michael on this,
he's wrong, but likes to keep repeating his opinion as though it's
gospel whenever this comes up anyway.
aj likes to say I'm wrong, but hasn't fixed the problems to make it
true.
Mike Stone

Re: security in testing

[Gerfried Fuchs]

[Removed debian-private from Cc-List, there is *no* need to duplicate
 the thread there]

On Fri, May 16, 2003 at 07:58:44AM +0200, Sven Luther wrote:
>   2) a way for people for which stable is too outdated to run more
>  advanced software, without suffering from the breakages of unstable.
>  By saying this we clearly imply that it is better to run testing
>  than unstable.

 Sure, but we _still_ tell people that care for security *to run
stable*.  Noone was ever told that unstable is secure and should be used
for critical services

>  Sure, this was before we had time to test testing,
>  and before we became aware of the big stalls implied, and the fact
>  that security wise testing is worse than unstable.

 And still, unstable _is_ bad according to security. We do NOT encourage
people to run unstable for secure machines, so why do you think that
telling people to rather use testing than unstable for not-secure things
is a bad idea? Just take the long time that the kde2 package in unstable
were still vulnerable because their maintainers thought that kde3 will
make it soon into unstable (or whatever the real reason was -- the
reason doesn't really matter, so don't pin me down on that).

> This second goal is today a total failure,

 I don't think so.  Security was never part of that second goal.

> I still think that the second goal can be achieved. Probably the fact to
> use testing-proposed-update for security and RC bugs would be enough, i
> don't know, only experience will tell.

 Some people stepping forward to do actual work on that part would be
needed, than it might be enough. People repeating the same phrases and
accuses over and over again are not enough, though.

 So long,
Alfie

Re: mailcap next step

[mcINEK]

I'm attaching two scripts. One just converts 'old' 
/usr/lib/mime/packages/ directory to 'new' one. Why I'll explain later.
Next is replacement for update-mime script to use 'new' format. It
generates full compatible mailcap file, but inserts just one application
(x and non x) for each mime type. I think this solution isn't worse than
original. Although this script has one *big* disadvantage... It's shell
script and it's very slow. I'm sorry but I don't know perl. Nevertheless
it can't be improved, it's just a sample.

Now, why I think my structure of files in /usr/lib/mime/packages is
better. It's very simple to take control of it. System wide script (my
update-mime2) looks at .default files for each type and puts into
mailcap. If it doesn't find defaults (admin didn't choose one) it puts
first from directory (such as old one). In conclusion, we see that we
generally don't loose usability but we're getting new one. Of course,
this script propably doesn't use all of original update-mime features,
because I don't even know them, but I can be improved.

In contrast the 'power' of this special directory structure is appearing
for user, not administrator. It's very easy to write a frontend to
select apps from that tree. For each type it can show user all
posibilities and extra show administrator suggestion (.default). Then in
*simple* way it'd generate ~/.mailcap file.

As we see, we don't loose usability, even compatibility. I replaced just
one script, and provide converter for temporary. Please, look at it, and
thinks is it interesting. Say rather about 'idealogic' solution, not
technically scripts, because they can be improved by someone, who's good
at it.

PS. I'm now using this on my computer and I don't have any problems. I
work know on a kind of frontend.

PS2. For tests, you can change directiories in scripts vars.

Regards,
Marcin.
-- 
  .---, --:   mcINEK   :--
 /  ,. \   '   T h e   O w l s  a r e  n o t 
|  |  ; ;W h a t   T h e y   S e e m . . .   '
 \ `._ /wrote on Debian GNU/Linux SID

#! /bin/bash
#
# This sctipt is a replacment for update-mime.
# It uses new format of /usr/lib/mime/packages dir.
#
# Author: mcINEK <[EMAIL PROTECTED]>
#

if [ -x /usr/sbin/update-mimedir ]; then
  /usr/sbin/update-mimedir
fi

mime_dirs="/usr/lib/mime/packages"
mailcap="/etc/mailcap" 

dirs=`find $mime_dirs -type d | sort`

if [ "$mime_dirs" == "" ]; then
  echo "Is /usr/lib/mime/packages using new format?"
  exit
fi

echo "# File generated by update-mime2 script." > $mailcap
echo >> $mailcap

for dir in $dirs; do
  [ ! "$dir" == "$mime_dirs" ] || continue
  dir=`echo "$dir" | awk -F\/ '{ print $NF}'`
  cd "$mime_dirs/$dir"
  # check, if there's any program
  [ ! "`ls`" == "" ] || continue
  # looking for non x program, sed to make sure if chosen only one
  x_program=`ls x.*.default 2> /dev/null | sed q1`
  if [ ! "$x_program" ]; then
# choose first available
x_program=`ls x.* 2> /dev/null | sed q1`
  fi
  # if not will use terminal program

  # chech for a default term program
  term_program=`ls --ignore='x.*' 2> /dev/null | grep .*.default | sed q1`
  if [ ! "$term_program" ]; then
term_program=`ls --ignore='x.*' 2> /dev/null | sed q1`
  fi

  mime_type=`echo $dir | sed 's/\./\//'`
  
  #echo "X - $x_program T - $term_program"
  
  if [ "$x_program" ]; then
echo "$mime_type; `cat $mime_dirs/$dir/$x_program`" >> $mailcap
  fi
  if [ "$term_program" ]; then
echo "$mime_type; `cat $mime_dirs/$dir/$term_program`" >> $mailcap
  fi
  
  echo >> $mailcap
  
  echo -n .
done

echo 
#! /bin/bash
#
# This script converts old /usr/lib/mime/packages
# to new format.
#
# Author mcINEK <[EMAIL PROTECTED]>
#

mimedirs="/usr/lib/mime/packages"
new_mimedirs=$mimedirs

files=`find $mimedirs -type f -maxdepth 0 | awk -F\/ '{ print $NF  }'`

[ ! "$files" == "" ] || exit

for file in $files; do
  while read line; do
[ ! "$line" == "" ] || continue
mime_type=`echo $line | awk -F\; '{ print $1 }'`
mime_dir=`echo $mime_type | sed 's/\//./'`
#echo $mime_type # choose one of two: this
echo -n .   # or this
mkdir "$new_mimedirs/$mime_dir" 2> /dev/null
if [ "`echo $line | grep DISPLAY`" == "" ]; then
  echo $line | awk -F' ' '{ for(i=2;i<=NF;i++) {printf("%s ",$i)} }' \
> "$new_mimedirs/$mime_dir/$file"
else
  echo $line | awk -F' ' '{ for(i=2;i<=NF;i++) {printf("%s ",$i)} }' \
> "$new_mimedirs/$mime_dir/x.$file"
fi	
  done < "$mimedirs/$file"
  rm "$mimedirs/$file" 2> /dev/null
done

echo 


signature.asc
Description: PGP signature

Re: security in testing

[Colin Watson]

On Fri, May 16, 2003 at 05:45:21AM -0400, Michael Stone wrote:
> On Thu, May 15, 2003 at 09:15:21PM -0500, Anthony Towns wrote:
> >Please don't bother listening to or arguing with Michael on this,
> >he's wrong, but likes to keep repeating his opinion as though it's
> >gospel whenever this comes up anyway.
> 
> aj likes to say I'm wrong, but hasn't fixed the problems to make it
> true.

Why is this thread still being cc'ed pointlessly between -private and
-devel?

-- 
Colin Watson  [EMAIL PROTECTED]

Re: security in testing

[Gerfried Fuchs]

On Fri, May 16, 2003 at 12:15:48PM +0200, Sven Luther wrote:
> Yes, but before someone steps for and does this, a consensus need to be
> found on what to do, the RM at least has to green-light it, and it
> should be announced on debian-devel-announce so all the maintainer are
> aware of it and the rules that apply to doing it.

 No, you can't announce something on dda that doesn't exist. That's
nonsense. Pretty please announce things that already started working and
showed worth it, thanks.

 So long,
Alfie

Re: security in testing

[Anthony Towns]

On Fri, May 16, 2003 at 09:11:27AM +0200, Matthias Urlichs wrote:
> Hi, Anthony Towns wrote:
> > Yes, and funnily enough, uploads to -p-u have to be processed by the
> > release manager, either Joey for stable, or me for testing.
> This may be a stupid question, but why is there a "have to" here (we're
> not in freeze mode!), 

Because you can't tell if uploads to -p-u are buggy or not, since (a)
no one runs them, and (b) the BTS doesn't distinguish them from the
version in unstable. There are miscellaneous technical problems too.

> and would you be OK with sharing this part of your
> responsibility?

Sure. It just needs someone motivated and responsible.

Cheers,
aj

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

  ``Dear Anthony Towns: [...] Congratulations -- 
you are now certified as a Red Hat Certified Engineer!''


pgpinj5HGYnHi.pgp
Description: PGP signature

Re: ITP: latex209 -- macro files of LaTeX 2.09 25-mar-1992 version

[Agustin Martin Domingo]

TSUCHIYA Masatoshi wrote:
On Thu, 15 May 2003 10:08:37 -0800
[EMAIL PROTECTED] (Fielder George Dowding) said as follows:

I use LaTeX2e and friends (almost daily).

I know that LaTeX-2.09 is obsolete, however I need it to process
ancient TeX sources without modification.
If your documents starts with a '\documentstyle{your_style}' call 
instead of a '\documentclass' one the 209 compatibility mode should 
automatically be activated. What kind of problems are you experiencing?

Cheers,
--
=
Agustin Martin Domingo, Dpto. de Fisica, ETS Arquitectura Madrid,
(U. Politecnica de Madrid)  tel: +34 91-336-6536, Fax: +34 91-336-6554,
email:[EMAIL PROTECTED], http://corbu.aq.upm.es/~agmartin/welcome.html

Re: security in testing

[Sven Luther]

On Fri, May 16, 2003 at 12:01:54PM +0200, Gerfried Fuchs wrote:
> [Removed debian-private from Cc-List, there is *no* need to duplicate
>  the thread there]
> 
> On Fri, May 16, 2003 at 07:58:44AM +0200, Sven Luther wrote:
> >   2) a way for people for which stable is too outdated to run more
> >  advanced software, without suffering from the breakages of unstable.
> >  By saying this we clearly imply that it is better to run testing
> >  than unstable.
> 
>  Sure, but we _still_ tell people that care for security *to run
> stable*.  Noone was ever told that unstable is secure and should be used
> for critical services

Sure, but the main point is that unstable is better security wise than
testing, and very much so. If a security problem appears in unstable, it
is often because it was only discovered recently, and upstream at least
will care enough to fix it quickly, or maybe the maintainer will take
action, or even the security team can help some when it does the stable
security fix, be it only by informing the maintainer about the problem.

So a security hole in unstable offers potential attackers a much smaller
window of oportunity to exploit it, while such security holes in testing
remain there for weeks or month, and we even document them so potential
attackers have a easy time exploiting them.

> >  Sure, this was before we had time to test testing,
> >  and before we became aware of the big stalls implied, and the fact
> >  that security wise testing is worse than unstable.
> 
>  And still, unstable _is_ bad according to security. We do NOT encourage

Sure, but orders of magintude less so than testing.

> people to run unstable for secure machines, so why do you think that
> telling people to rather use testing than unstable for not-secure things
> is a bad idea? Just take the long time that the kde2 package in unstable
> were still vulnerable because their maintainers thought that kde3 will
> make it soon into unstable (or whatever the real reason was -- the
> reason doesn't really matter, so don't pin me down on that).

Yes, unstable has the same problem, but well, it is unstable, and again,
the windows of oportunity is less so. Also, if the maintainer wanted, he
could fix the problem easily enough, while for testing, altough it seem
to be possible, i bet most of the maintainers where not aware of it,
and it needs the intervention of the RM anyway.

> > This second goal is today a total failure,
> 
>  I don't think so.  Security was never part of that second goal.

Maybe, but then i tried running testing instead of unstable on my work
box some time back, and encountered more problems than with unstable.
Also, the lack of new packages makes running testing not worth the
trouble.

> > I still think that the second goal can be achieved. Probably the fact to
> > use testing-proposed-update for security and RC bugs would be enough, i
> > don't know, only experience will tell.
> 
>  Some people stepping forward to do actual work on that part would be
> needed, than it might be enough. People repeating the same phrases and
> accuses over and over again are not enough, though.

Yes, but before someone steps for and does this, a consensus need to be
found on what to do, the RM at least has to green-light it, and it
should be announced on debian-devel-announce so all the maintainer are
aware of it and the rules that apply to doing it.

All the rest is just maintaining the status quo, while making it more
difficult for people wanting to change things to do it or even attain
consensus on the best way to do it.

Friendly,

Sven Luther

Re: Packages up for adoption: ap-utils, igal, tcpflow

[Celso González]

On Thu, May 15, 2003 at 09:39:54PM +0100, Robert McQueen wrote:
> Just a brief note to draw people's attention to the following RFAs
> I filed a few days ago:
>  #193116 ap-utils -- Access Point SNMP Utils for Linux
>  #193117 igal -- online image gallery generator
>  #193118 tcpflow -- TCP flow recorder
> 
> Please see the bugs for more information about the status of each
> package, and please e-mail me if you are interested in adopting
> them (I am not on this list).
> 
I will like to adopt ap-utils, iÅm using the 1.1 package but i have 
a few problem that is resolved in the current 1.3 version

If you think I could to the job i will send the request to wnpp.

Best regards

-- 
Celso Gonzalez 
[EMAIL PROTECTED]


pgpyszsCsfXNh.pgp
Description: PGP signature

Re: mailcap next step

[Michał Politowski]

On Fri, 16 May 2003 12:05:17 +0200, mcINEK wrote:
> Next is replacement for update-mime script to use 'new' format. It
> generates full compatible mailcap file, but inserts just one application
> (x and non x) for each mime type.

You obviously haven't read man mailcap.order?

-- 
Michał Politowski -- [EMAIL PROTECTED]
Warning: this is a memetically modified message

Re: security in testing

[Sven Luther]

On Fri, May 16, 2003 at 12:36:38PM +0200, Gerfried Fuchs wrote:
> On Fri, May 16, 2003 at 12:15:48PM +0200, Sven Luther wrote:
> > Yes, but before someone steps for and does this, a consensus need to be
> > found on what to do, the RM at least has to green-light it, and it
> > should be announced on debian-devel-announce so all the maintainer are
> > aware of it and the rules that apply to doing it.
> 
>  No, you can't announce something on dda that doesn't exist. That's
> nonsense. Pretty please announce things that already started working and
> showed worth it, thanks.

What are you speaking about ? The plan is not to announce a testing
security team, but how it is possible for debian developers to fix
security and RC bugs in testing when the packages would otherwise have
been stalled in unstable due to perl or KDE brokeness or whatever.

The only thing really needed here is the RM's blessing, and an
announcement.

What you are trying to say, is nobody is doing it, so we cannot announce
it, and anyway, it is the users fault for running testing, so let's keep
everything as is, it as run fine upto now, and woe to who dares suggest
something different.

Friendly,

Sven Luther

Re: Michael-John Turner MIA? (was: Debian MIA check)

[Paul Slootman]

On Fri 16 May 2003, Martin Michlmayr wrote:
> 
> I didn't check yet whether he really made that upload.  But yeah, the
> mrtg bug is certainly a good reason to contact him again...  Feel

I wrote to him (again) on the 13th about his, still zero response.

> free to NMU in the meantime.

Done, mrtg 2.9.29-0.1 is accepted.
I also needed to upload libsnmp-session-perl 0.95-0.1 as the new mrtg
depends on this 0.93 or higher (only 0.90 was available), and MJ is also
the maintainer for this package.


Paul Slootman

Re: ITP: latex209 -- macro files of LaTeX 2.09 25-mar-1992 version

[TSUCHIYA Masatoshi]

>> On Fri, 16 May 2003 12:55:54 +0200
>> [EMAIL PROTECTED] (Agustin Martin Domingo) said as follows:

>If your documents starts with a '\documentstyle{your_style}' call
>instead of a '\documentclass' one the 209 compatibility mode should
>automatically be activated. What kind of problems are you
>experiencing?

It is true that the 2.09 compatibility mode works finely in almost
cases.  However, LaTeX-2.09 itself still be needed for style files
that use internal macros of LaTeX-2.09.  The style file of my
bachelor's thesis is an example of such style files, and there are a
fair number of sources that use it.  When one of them is processed in
the 2.09 compatibility mode, the following message is printed.

! Undefined control sequence.

-- 
TSUCHIYA Masatoshi

Re: Packages up for adoption: ap-utils, igal, tcpflow

[Robert McQueen]

On Fri, May 16, 2003 at 08:48:46AM +0100, Steve Kemp wrote:
>   I'd take tcpflow if it's not already been claimed, it nicely
>   comliments dsniff which I already have.
> 
> Steve

It's yours.

Regards,
Rob

Re: ITP: latex209 -- macro files of LaTeX 2.09 25-mar-1992 version

[Agustin Martin Domingo]

TSUCHIYA Masatoshi wrote:
It is true that the 2.09 compatibility mode works finely in almost
cases.  However, LaTeX-2.09 itself still be needed for style files
that use internal macros of LaTeX-2.09.  The style file of my
bachelor's thesis is an example of such style files, and there are a
fair number of sources that use it.  When one of them is processed in
the 2.09 compatibility mode, the following message is printed.
! Undefined control sequence.
I see.
I do not know how complex is that style file, but I guess that the 
amount of work you will need to make the 209 latex package properly 
install and work in a reasonable way without breaking latex2e behavior 
and without being broken by latex2e compatible style files (not only the 
base files, but other style files too that have replaced the old files 
having the same name but being now written for latex2e) is really high 
and might be broken by changes in tetex files that are being rewritten 
to be latex2e aware.

Unless that style file is a nightmare I would really consider its 
rewriting rather than preparing a package with the obsolete latex209 
stuff if the above possible problems cannot be clearly managed.

I am cc'ing this message to the debian-tetex-maint list. I think they 
would also like to know about this and will have a much better knowledge 
than I have about how possible it is and the incompatibilities that 
might arise.

Cheers,
--
Agustin

Re: Packages up for adoption: ap-utils, igal, tcpflow

[Robert McQueen]

On Fri, May 16, 2003 at 12:51:40PM +0200, Celso González wrote:
> I will like to adopt ap-utils, i??m using the 1.1 package but i have 
> a few problem that is resolved in the current 1.3 version
> 
> If you think I could to the job i will send the request to wnpp.
> 
> Best regards

Fine by me. As far as I can tell you're not a DD or in the NM queue, so
you will need to find a sponsor. I'd offer, put the purpose of putting
these packages up for adoption is removing the need for me to spend any
more time on them. :D

Regards,
Rob

Packages adopted (ap-utils, igal, tcpflow)

[Robert McQueen]

On Thu, 15 May 2003 21:39:54 +0100, Robert McQueen wrote:
> Just a brief note to draw people's attention to the following RFAs
> I filed a few days ago:
>  #193116 ap-utils -- Access Point SNMP Utils for Linux
>  #193117 igal -- online image gallery generator
>  #193118 tcpflow -- TCP flow recorder
> 
> Please see the bugs for more information about the status of each
> package, and please e-mail me if you are interested in adopting
> them (I am not on this list).
> 
> Regards,
> Rob

igal has been taken by [EMAIL PROTECTED], so they've all been taken now,
thanks for your rapid replies.

Regards,
Rob

Re: mailcap next step

[mcINEK]

W liście z pią, 16-05-2003, godz. 13:05, Michał Politowski pisze: 
> You obviously haven't read man mailcap.order?

I've read, when you first time told me.
It's just a step to provide that usability like my script.
Please, look at this two opions objectively. Forget, that one of them is
already implemented. 

First in administrator point of view. When you are administrator on
non-your computer, you propably don't care about mime types, and you
even don't change mailcap.order. If it's your machine, of course you can
modify mailcap.order. But when you install apps or remove you must edit
it manually. When you've got a lot of preferences mailcap.order is big
and it's hard to find sth. Nevertheless, you propably use user account
to work.

And here is 'magic'. If you are advanced user (and of course you are :)
you could copy /etc/mailcap to ~/.mailcap, sort it, and than just erase
dubbling lines to chose that apps you want. It's ok, and it wasn't as
much difficult (for you). However, imagine a user who doens't know a lot
about all sfuff conencted with mime types (They are people like them
too!!!). He propably won't know what to do.

Here comes help. A frontend. Certainly, you can write a frontend parsing
big file, and after hard work you propably will manage it to show info
in simple way to user. But what for??? Now, it's so much easier to write
a good, *fast* frontend in every language. Because, you've got clean
(and soft :) directory structure with types. Besides, there's still a
posibility to generate full mailcap like old one (if you want to).

You can ask: why change sth?
And I'd tell you: Because new solution is easier to improve, it's solid
base to make any kind of apps making sth with mime. And if is not right
now (I'm sure about it), we should improve it, or even find better.

Regards,
Marcin
-- 
  .---, --:   mcINEK   :--
 /  ,. \   '   T h e   O w l s  a r e  n o t 
|  |  ; ;W h a t   T h e y   S e e m . . .   '
 \ `._ /wrote on Debian GNU/Linux SID



signature.asc
Description: PGP signature

confidential matter

[timothykembela]

Confidential matter***
> 
> Sir/madam,
> 
> 
> 
> I need your help,I amTimothy Kembela
l the son of a 
> Late minister during the reign of mobutu seseko,
> I came to know you in the course of my search for 
> a reliable and God fearing partner and I decide 
> to contact you because I believe you are a reputable
> 
> person and I felt you can help us over this
> confidential 
> matter. I count on your intergrity and honesty to be
> able 
> to handle this business.
> 
> 
> My father was a minister in Democratic Republic of 
> Congo during the reign of Late President Mobutu. 
> Our father was killed during the rebel attack and 
> our house was burnt. We  manage to escape to Ghana
> with  my mother and two of my sisters 
> where we are now taking refuge.Before the death of 
> my father he deposited US$50 MILLION, with a
> security 
> company in Europe.The money is kept in a trunk boxes
> 
> and was registered as precious substance. Thus there
> is 
> nobody that knows that it is money that is in the
> box.
> 
> All the document with which the money was deposited
> is
> 
> with us. I am lookinf for somebody to that is
> capable 
> and willing to travel to  MADRID SPAIN
> 
> receive the two trunk boxes of money on behalf of my
> family from the security company.
> 
> 
> We need a trust worthy and experience person that
> will
> 
> help us to invest this money in your country  and
> take
> 
> us as one family  and will also buy a house for us
> over 
> there where we can live safely.
> 
> 
> We are expecting to hear from you.Please contact me
> on
> 
> this Email Address: [EMAIL PROTECTED]
>   
> Thanks for your  anticipated cooperation.please 
> include your telephone number and fax number in 
> your reply
> 
> Best Regards,
> 
TIMOTHY KEMBELA
> 

Re: security in testing

[Michael Banck]

On Thu, May 15, 2003 at 11:06:25PM -0500, Manoj Srivastava wrote:
>   The problem is finding competent volunteers to do the work.

I must have missed that post to debian-devel-announce where the security
guys call for responsible people to get on the team then.

I mean, nothing wrong with trying to step up to prospective DDs and
privately, behind the curtain, asking them: "Hey, we need help and you
know your stuff. Wouldn't you like to work for the sec-team?" I know
NM-Front-Desk does this trying to get future AMs. But I haven't even
noticed the slightest action by the sec-team in this regard. 

If a member of the sec-team says "Yes, we are actively trying to find
new members, but finding competent and responsive people who have the
time and will to help is very difficult", then I'm happy and shut up.

But otherwise, I consider the current stance of the security-team on
this issue as "We don't care about testing and we've got more important
things to do with our time anyway. Go away."


Michael

-- 
 whenever i come in here, it feels like #d-d is frozen in time
forever
 the version numbers of the software mentioned in the topic
change, though

Re: security in testing

[Michael Banck]

On Fri, May 16, 2003 at 01:13:05PM +0200, Sven Luther wrote:
> The only thing really needed here is the RM's blessing, and an
> announcement.

I have no idea how you might think this announcement should look like.
Could you perhaps at least give a rough outline of it?

Thanks.

Michael

-- 
 DaniFilth: Welcher ist dein Username?
 Alfie: DarkSorcerer
 Ist nicht gebaned.

Re: security in testing

[Michael Banck]

So, what have we got here?

Three theses:

On Wed, May 14, 2003 at 07:13:39PM +0200, Sven Luther wrote:

1.
> Well, the documentation says that there is no security for testing, 

2.
> but it does not say that the security of unstable is higher than the
> one of testing. 

OK, so testing has "no security" and you wonder why "the security of
unstable is higher than the one of testing"? Reality check?

The only conclusion I can draw from these two theses is that you think
Debian Developers actively upload *backdoors* to unstable, in order to
get its security below even testing.

3.
> Anyway, intuitively testing is supposed to be more stable/secure/
> better/whatever than unstable, 

Your intuition seems to be way off. Could you please write down your
theses #1 five times and think about your theses #3 again?

> and that is what the people expect. 

s/people/morons/


Michael

-- 
"No bastard ever won a war by dying for his country. He won it by making
the other poor dumb bastard die for his country."
-- General George Patton Jr

Re: security in testing

[Michael Banck]

On Thu, May 15, 2003 at 08:52:26AM -0400, Stephen Frost wrote:
> * Matthias Urlichs ([EMAIL PROTECTED]) wrote:
> > Hi, Stephen Frost wrote:
> > 
> > >> (a) Before I do something like that, I'd need to be accepted as DD.
> > > 
> > > False statement.
> > 
> > So non-DDs can get accounts on Debian machines to setup something like
> > this (install FTP directories, setup autobuilders, etc.)?
> 
> You can set up your own, you don't need access to Debian machiens to
> build security updates and make them available for testing.

Look. People already complained about mentors.debian.net being run by
non-DDs. Do you think 'security.debian.net', being run by non-DDs, would
get any support at all?

Playing that 'you can do everything possibly imagineable without being a
DD' card has its limits, IMHO.

Michael

Re: security in testing

[Matt Zimmerman]

On Fri, May 16, 2003 at 01:59:48PM +1000, Anthony Towns wrote:

> On Thu, May 15, 2003 at 10:28:48PM -0400, Matt Zimmerman wrote:
> > Outstanding DSA's are not the matter at hand; 
> 
> Sure they are: if you're complaining that the security team already has
> too much work to do, then it's outstanding DSAs that are exactly the
> problem.  If there aren't any outstanding DSAs, then it'd seem like now
> would be the right time to see about doing a *better* job, rather than
> just the same old one.

No, I'm complaining that you want to funnel additional, unrelated work
through the security team when there is no good reason to do so.

> [...more of the same...]
> > Why don't they upload them to testing-proposed-updates instead?  You
> > have said that it works and all known technical issues have been
> > addressed.  Just give maintainers the power they want.
> 
> Yes, and funnily enough, uploads to -p-u have to be processed by the
> release manager, either Joey for stable, or me for testing. How's the
> phrase go? "You suggest distributing the workload, and your concrete
> suggestions are exactly the opposite of that."

"So add people."  See where this is going?

With t-p-u, any maintainer can upload their package, review the build logs,
fix any problems, re-upload, etc.  Why would you want the security team to
do this instead?

> > No, I'm contending that testing is in development.  
> 
> Are you contending that the stable Debian release *isn't* in development?
> I'm pretty sure that the OpenOffice.org guys are working on some stuff to
> be included in the next stable release.

The stable Debian release is *not* in development.  It is not changing.  The
only way it will change significantly will be when it is *completely replaced*
with a new release.

  development
   n 1: act of improving by expanding or enlarging or refining; "he
congratulated them on their development of a plan to
meet the emergency"; "they funded research and
development"
   2: a process in which something passes by degrees to a
  different stage (especially a more advanced or mature
  stage); "the development of his ideas took many years";
  "the evolution of Greek civilization"; "the slow
  development of her skill as a writer" [syn: {evolution}]

> > It's a daily snapshot.
> 
> That's certainly true. Do you contend that it's impossible to have a daily
> release schedule? How about hourly? Weekly? Monthly? Every two months?
> Six?

There's obviously no hard and fast rule.  It's a tradeoff whether it's more
expedient to patch what's there or let it go into the next release.  If the
next "release" is less than 24 hours away, it doesn't make much sense to
patch the existing release.

-- 
 - mdz

Re: security in testing

[Sven Luther]

On Fri, May 16, 2003 at 02:44:28PM +0200, Michael Banck wrote:
> On Fri, May 16, 2003 at 01:13:05PM +0200, Sven Luther wrote:
> > The only thing really needed here is the RM's blessing, and an
> > announcement.
> 
> I have no idea how you might think this announcement should look like.
> Could you perhaps at least give a rough outline of it?

What about :

  We currently don't support secutiry updates (by the security team) for
  testing or unstable. Security updates for unstable are the
  responsability of the individual maintainers, which can and should
  upload fixed packages to close the security holes. Normally such
  packages would move into testing after they are built for each
  architectures and the testing-delay is expired (priority of security
  fix upload should be set to high when uploading to unstable), but
  sometime dependency problems can stop such fixed packages to be moved
  into testing in a timely manner (this may even take weeks or month).

  Since it is unacceptable for debian to distribute packages with known
  security holes, maintainers should, in case a package cannot enter
  testing trough the normal means, do a testing-proposed-update.

  To upload a package to testing proposed update, a package needs to be
  built in a testing box/chroot/pbuilder, and uploaded to
  testing-proposed-update, with urgency high. The version number of said
  package should be the same as the one currently in testing, with a
  minor bump of the debian version number (1.2.3-4 becomes 1.2.3-4.1).

Note : maybe something like 1.2.3-4.0.tpu.1 would be better, -4.1 is
already a NMU or something such.

  Such a package should be as close to possible to the version actually
  in testing, and not depend on packages and/or versions that are not
  yet in testing.

Note : maybe it is acceptable to use also packages in
testing-proposed-updates, but this could cause dependency problems, and
is best to be avoided. Also, it is not sure if the buildd will fetch
packages out of testing-proposed-updates or not.

  Notice that the packages can only move from testing-proposed-updates
  into testing if they fullfill the same criteria as for moving from
  unstable to testing, and either the RM or one of his assistants gives
  the green light. So, each time such an upload is made, a email should
  be sent to the [EMAIL PROTECTED] giving the reasons for the upload.

  Please notice that this is not a way of circumventing the unstable to
  testing migration, and uther care should be taken not to break testing
  more with the fix than it was before. Also, maintainer doing such
  uploads should follow the buildd logs and check that their packages
  builds and enters testing correctly, and remedy to any problems that
  would arise in a timely fashion.

Or something of the kind, naturally written by someone who writes better
english than me.

Also, we could add 2 things, first the RM assitants, which are debian
developers who have voluntereed to help the RM in this, and have the
right to give the green light to uploads.

Second, what could be done about NMUs. Maybe a small group of apprentice
security team members could scan the security announcements, and prepare
NMU of such security holed packages, in close contact with the
maintainer and the RM or his assistants, or maybe even the security
team, especially if the problems are also present in stable packages.
Additionnaly, they would be the ideal candidate to be promoted to work
on the real security team, once they have proven their worth.

So, with such an announcement, everyone wins, our user will get a more
secure testing, the maintainer will be able to fix things in testing
more easily, and the security team would get group of people to draw
future team members if needed. The only one who stands to loose is the
RM, since he has to green light every upload, but then, with the
addition of one or two RM assistants, this may not be such a load after
all.

Friendly,

Sven Luther

Re: security in testing

[Sven Luther]

On Fri, May 16, 2003 at 02:52:15PM +0200, Michael Banck wrote:
> So, what have we got here?
> 
> Three theses:
> 
> On Wed, May 14, 2003 at 07:13:39PM +0200, Sven Luther wrote:
> 
> 1.
> > Well, the documentation says that there is no security for testing, 
> 
> 2.
> > but it does not say that the security of unstable is higher than the
> > one of testing. 
> 
> OK, so testing has "no security" and you wonder why "the security of
> unstable is higher than the one of testing"? Reality check?
> 
> The only conclusion I can draw from these two theses is that you think
> Debian Developers actively upload *backdoors* to unstable, in order to
> get its security below even testing.

???

The problem is that holes in testing and unstable appear at the same
time, but often only can get fixed in unstable.

> 3.
> > Anyway, intuitively testing is supposed to be more stable/secure/
> > better/whatever than unstable, 
> 
> Your intuition seems to be way off. Could you please write down your
> theses #1 five times and think about your theses #3 again?

Make a survey, that is what the vast majority of our user think. What i
am saying is that, sure, we say that testing has no security team
working on it, but this is also the case for unstable. People who are
not intimely familiar with the way the testing script work and such will
think that ok, testing has no security and may be broke, but it should
be worst in unstable, since after all testing has had some testing
already. Nobody is telling them that testing has any number of known and
documented security holes, which were there for a long time, and that we
have no intention of fixing in a timely fashion.

> > and that is what the people expect. 
> 
> s/people/morons/

Please, stay polite. It is not because you disagree that it gives you
the right to be rude (to me or to our users).

Friendly,

Sven Luther

Re: Screwed up fonts in _ALL_ Qt applications :(

[Adam Majer]

On Fri, May 16, 2003 at 01:33:12AM -0500, Chris Cheney wrote:
> On Sun, May 11, 2003 at 09:00:02PM -0700, Brian Nelson wrote:
> > Something related to #189750, perhaps?
> > 
> > -- 
> > Looks like excitement by repetition!
> 
> It is very unlikely that it is related to 189750, but it could be
> something related to how fontconfig chooses fonts. For example the
> medium font selection in Konsole ends getting a CJK font instead of a
> regular monospace one, which makes it look very wide.

It's not related - when the bug was fixed the bad font remained.
I really think that there should be _a_lot_ more weight placed on
the the type of font (ie. latin1/korean difference should have more 
weight than scalable/bitmap or bold/normal.

Re: security in testing

[Stephen Frost]

* Michael Banck ([EMAIL PROTECTED]) wrote:
> Look. People already complained about mentors.debian.net being run by
> non-DDs. Do you think 'security.debian.net', being run by non-DDs, would
> get any support at all?

It shouldn't and wouldn't need to be security.debian.net.  It can be
'mytestingupdates.net' and just be sure to label it as an unofficial
non-Debian site which contains security updates for testing.  If it's
good people will use it and then some of them will be willing to help,
etc.  People are only going to bitch if you make it look like an
official part of Debian when it isn't, and rightly so.

> Playing that 'you can do everything possibly imagineable without being a
> DD' card has its limits, IMHO.

There are things you can't do if you're not a DD- you can't upload
packages to Debian.  There's nothing to stop you from setting up your
own site people can add to their sources.list; *lots* of people have
done it.  Debian provides you with all the tools you need.  In the time
you've spent on this thread you could have done it, easily.

Claiming on mailing lists of all the great things you'd do if only you
were a DD is a bunch of wasted breath.  If you've got the time and skill
to do it then do it and show us how great it is.  If you don't then
you're going to have to wait till someone who does steps up.  Being a DD
would maybe save you 30 seconds of time spent setting up the repository
itself.

Stephen


pgpteVIcWJ2F1.pgp
Description: PGP signature

[no subject]

[*]

 ÇëÎÊÄãÓÐûÓÐSony s85 ÊýÂëÕÕÏà»úµÄÔö¾à¼°¹ã½Ç¾µÍ·£¿Èç¹ûÓУ¬¼Û¸ñ¶àÉÙ£¿
--
ÎÒ´æÔÚ£¬ÒòΪÎÒÊÇÖйúÈË£¡¾´Çë¹Ø×¢ÖлªÍøÐÅÌìÓÊ
ÐÅÌìÓÊÖ®ÊÕ·ÑÓÊ£ºhttp://paymail.china.com
ÐÅÌìÓÊÖ®Ãâ·ÑÓÊ£ºhttp://mail.china.com

Re: Do not touch l10n files (was Re: DDTP issue)

[Adam Majer]

On Tue, May 13, 2003 at 01:31:59AM +0200, Denis Barbier wrote:
> 
> Unfortunately 0xa0 is the no-break space which is very common in
> French typography.  One could argue that Tollef was not aware of this
> fact, but the question is: why does he believe that he can change this
> localized file when he obviously does not master this language?

[snip]

> In short, do not modify PO files unless gettext reports some warnings.
> Only apply your changes to English text, and translators will take
> care of propagating these changes.

I completely agree with you. And frankly, we need more "english" -> English
translators. ;)

- Adam

Re: security in testing

[Michael Banck]

On Fri, May 16, 2003 at 10:06:57AM -0400, Stephen Frost wrote:
> * Michael Banck ([EMAIL PROTECTED]) wrote:

> People are only going to bitch if you make it look like an
> official part of Debian when it isn't, and rightly so.

Why the hell do you think this should not be an official part of debian?

> Debian provides you with all the tools you need. 

Debian does not provide you with credibility, though. I doubt a lot
people would say: "Oh, that Michael Banck dude is doing sec-updates for
testing now. Although he's german, working on the hurd port, busy with
university and not actually running testing, I'm going to put his
APT-line in all of the 200 desktop machines running testing at our
company without thinking twice whether he can really live up to
expectations. Oh, it's not an official debian site. Well, I'm not
getting suspicious of *that* tiny bit"

> In the time you've spent on this thread you could have done it,
> easily.

If providing reliable testing security could be provided in the time
I've spend on this thread, it have would already be done by the current
security-team, I'm sure.

Michael

Re: Questions regarding utf-8

[Matthias Urlichs]

Hi, John Darrington wrote:

> Given a text file, it will attempt to guess the natural language in
> which it was written. I'm sure it would be fairly simple to modify it to
> guess the charset.  If you point me to a reasonably large set of example
> files, I'll see what I can do.

You could use your existing samples, which hopefully include a number of
non-ASCII characters, recode them to UTF-8, and then try a few encodings
-- the German text would typically be in latin-1, latin-15, or one of the
Windows or Mac specific charsets for West or Central Europe.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
-- 
Dimensions will always be expressed in the least usable term.
EXAMPLE: Velocity will be expressed in furlongs per fortnight.

Re: ABI change in libsensors1 (from lm-sensors)

[David Z Maze]

Chris Cheney <[EMAIL PROTECTED]> writes:

> Why not kick upstream into releasing 2.7.1 with proper soname bump to
> libsensors2 (Make sure they are aware they screwed up...). Then upload
> libsensors2, there are only 8 sources depending on libsensors1 now so
> it wouldn't be a big deal to rebuild those few in any case.

I did send upstream mail pointing out the issue and asking for an
soname change, but I haven't heard anything back.  I'll upload a new
package with a Debian-specific soname as soon as I can get to a
development machine with the relevant hardware, probably tomorrow...

> sources depending on libsensors1
> 
> hardware-monitor
> kdebase
> ksensors
> lm-sensors
> mrtgutils
> wmgtemp
> wmsensors
> xsensors

(The other motivation for uploading a new libsensors1 is to Conflict:
with the subset of these packages that have linked against the
libsensors1 that doesn't work; if I'm not going to do that, then I
should probably ask that libsensors1 be removed.)

-- 
David Maze [EMAIL PROTECTED]  http://people.debian.org/~dmaze/
"Theoretical politics is interesting.  Politicking should be illegal."
-- Abra Mitchell

Re: security in testing

[Stephen Frost]

* Michael Banck ([EMAIL PROTECTED]) wrote:
> On Fri, May 16, 2003 at 10:06:57AM -0400, Stephen Frost wrote:
> > People are only going to bitch if you make it look like an
> > official part of Debian when it isn't, and rightly so.
> 
> Why the hell do you think this should not be an official part of debian?

It may be eventually if it works out.  It doesn't need to be to begin
with.  The work certainly does not require the result being an official
part of Debian.  You seem to fail to understand that.

> > Debian provides you with all the tools you need. 
> 
> Debian does not provide you with credibility, though. I doubt a lot

You don't need to be part of Debian to do the work and to make it
available.

> > In the time you've spent on this thread you could have done it,
> > easily.
> 
> If providing reliable testing security could be provided in the time
> I've spend on this thread, it have would already be done by the current
> security-team, I'm sure.

You took the comment out of context and then replied to it as that.  The
comment was that you could have created the repository, which is all
that being a DD would do for you (the Debian repository is already
created).  The work of providing reliable security updates for testing 
would not have been done just because you were made a DD.

Stephen


pgpH6Cd3y5HpQ.pgp
Description: PGP signature

Re: Bug#190038: libgtkdatabox_1:0.2.3.0-1(m68k/unstable/thing2): FTBFS on m68k

[Junichi Uekawa]

> > It's strange, because on my i386 system
> > objdump -T /usr/lib/libgdk-X11-2.0.so gives
> > 
> > 0002e71c gDF .text  0049  Base_gdk_display_x11_get_type
> > 00045ebc gDF .text  014c  Base_gdk_windowing_window_init
> > 0005017c gDF .text  0106  BaseXineramaIsActive
> > 00010a20 gDF .init    Base_init
> > 0002b8b0 gDF .text  0041  Basegdk_image_type_get_type
> > 00050284 gDF .text  01ba  BaseXineramaQueryScreens
> >   DF *UND*  00c3  g_get_charset
> > 00026e3c gDF .text  0097  Base_gdk_screen_close
> > 
> > and that probably means the symbol should be defined within that library.
> 
> On crest (m68k) this results in:
> 
>   D  *UND*    XineramaIsActive
> 00016970 gDF .init    Base_init
> 0002ffd4 gDF .text  004c  Basegdk_image_type_get_type
>   D  *UND*    XineramaQueryScreens
>   DF *UND*  00c6  g_get_charset
> 0002b8fa gDF .text  009a  Base_gdk_screen_close
>   DF *UND*  0148  XkbSetDetectableAutoRepeat
> 
> Any idea why it seems to be undefined (*UND*) on m68k?

Noone seems to have replied to this mail yet, but 
for this kind of thing to happen, a possible cause would be 
a XineramaQueryScreens function that is expected to be 
defined in a static library (and linked into the 
shared library) was once provided as a shared library.

libXinerama.a is only provided as a static library, 
but apparently, on m68k, I suspect some symbols were provided
through some shared library, at some time.



regards,
junichi

Re: Where are translated man pages packaged?

[Keegan Quinn]

On Friday 16 May 2003 01:07 am, Fabio Massimo Di Nitto wrote:
> On Fri, 16 May 2003, Colin Watson wrote:
> > > I agree with Wouter. For me would be an issue having the base system
> > > bigger than it is now. Specially preparing very small "black box" where
> > > i need to save as much space as i can even during the installation
> > > phase.
> >
> > Can't you basically just 'rm -rf /usr/share/doc /usr/share/man' if
> > you're tight on space?
>
> Of course... but also during the installation?
>
> I don't mind at all cleaning up after... but during is a bit of a pain..
>
> more than once i had to install small dns servers on boxes with less than
> 100Mb flash and stuff like that... so basically also the minimal
> installation has to be tight.. then rm doc and man and after install the
> minimum sets of pkgs to provide the services.

Please do not try to force this methodology upon the standard Debian base 
system.  Administrators of embedded systems have many tools to deal with 
these problems already, that do not require ever unpacking the full base onto 
the target.

 - Keegan

Re: security in testing

[Matt Zimmerman]

On Fri, May 16, 2003 at 02:41:47PM +0200, Michael Banck wrote:

> On Thu, May 15, 2003 at 11:06:25PM -0500, Manoj Srivastava wrote:
> > The problem is finding competent volunteers to do the work.
> 
> I must have missed that post to debian-devel-announce where the security
> guys call for responsible people to get on the team then.

Are you subscribed to that list?

http://lists.debian.org/debian-devel-announce/2003/debian-devel-announce-200305/msg5.html

(it's the DPL who actually makes the call for responsible people in this
case)

> If a member of the sec-team says "Yes, we are actively trying to find
> new members, but finding competent and responsive people who have the
> time and will to help is very difficult", then I'm happy and shut up.

Well, then. :-)

-- 
 - mdz

Re: security in testing

[Michael Banck]

On Fri, May 16, 2003 at 12:38:39PM -0400, Stephen Frost wrote:
> * Michael Banck ([EMAIL PROTECTED]) wrote:
> > On Fri, May 16, 2003 at 10:06:57AM -0400, Stephen Frost wrote:
> > > People are only going to bitch if you make it look like an
> > > official part of Debian when it isn't, and rightly so.
> > 
> > Why the hell do you think this should not be an official part of debian?
> 
> It may be eventually if it works out.  It doesn't need to be to begin
> with.  The work certainly does not require the result being an official
> part of Debian.  You seem to fail to understand that.

You seem to fail to understand that people don't pull security updates
from Joe-Random-NM-or-not's server. Of course, one can setup a
repository with testing-security-updates. Whether it would (or should)
actually be used is another matter.

I'm all for starting, implementing and testing *new* projects outside of
the current infrastructue before they get transferred to .debian.org.
But the infrastructure and the procedures *are* there, we just need to
do it.

> > > Debian provides you with all the tools you need. 
> > 
> > Debian does not provide you with credibility, though. I doubt a lot
> 
> You don't need to be part of Debian to do the work and to make it
> available.

See above.

> > > In the time you've spent on this thread you could have done it,
> > > easily.
> > 
> > If providing reliable testing security could be provided in the time
> > I've spend on this thread, it have would already be done by the
> > current security-team, I'm sure.
> 
> The comment was that you could have created the repository, which is
> all that being a DD would do for you (the Debian repository is already
> created).  The work of providing reliable security updates for testing
> would not have been done just because you were made a DD.

Huh? How could a DD create a repository somebody else cannot? The only
place that would be is people.debian.org/~, right? That'll be
quite a bad place for security updates because I think one still cannot
pin different repositories at p.d.o to different priorities. Correct me
if I'm wrong.

> You took the comment out of context and then replied to it as that.
 
I was not aware that you might actually argue about such a minor
implementation detail. Sure, I could have setup a repository while I was
writing those lines, but what does an empty repository serve to the
problem? You seem to say yourself that it actually takes time to provide
security updates. 

Time, and the trust of the other debian developers, the users and
ideally of the security-team. There are a couple of DDs whose
security-for-testing-repository would be put instantly into my
sources.list (if I'd actually ran testing). There are a couple of others
I'd rather install Windows98 at home like my parents urge me to do than
do that.

Michael

-- 
 asuffield: screw m68k :)
 j/k
 joshk: screw your application :)
 j/k
 hoho, see how funny those kind of jokes are?

贴纸相机，股票机软件，批发电脑显示器

[智通科技]

1。目前日韩，香港及中国大陆流行的贴纸相机，全套整机7680元，单购软件（包括图库，加密狗）980元。（可议价）

2。全国通用股票接收机，功能强大，不需交月费，全套1280元，单购软件180元。

3。特价批发全新彩色电脑显示器，14寸每台330元，15寸每台380元，17寸每台580元。

4。新型广告，装修，装饰材料，可使光线变色转弯过墙---光纤丝，规格：0.3--1.2mm，批发价：35元/千克。


另外还有多种新奇科技产品，详情请参考我们的网站：www.gdztkj.com ; E-mail:[EMAIL 
PROTECTED]
联系电话：020-88303923

Bug#193574: ITP: albatross -- a Toolkit for Stateful Web Applications

[Fabian Fagerholm]

Package: wnpp
Version: N/A; reported 2003-05-16
Severity: wishlist

* Package name: albatross
  Version : 1.01
  Upstream Author : Object Craft <[EMAIL PROTECTED]>
* URL : http://www.object-craft.com.au/projects/albatross/
* License : BSD
  Description : a Toolkit for Stateful Web Applications

Albatross is a small and flexible Python toolkit for developing highly
stateful web applications. It includes, among other things:
 * An extensible HTML templating system similar to DTML that promotes
   separation of presentation and implementation.
 * The ability to place Python code for each page in a dynamically loaded
   module, or to place each page in its own class.
 * Optional sessions.
 * Deployment as CGI programs or mod_python modules.

Homepage: http://www.object-craft.com.au/projects/albatross/


A first version of the package is available at
http://people.paniq.net/~fabbe/debian/albatross/

Re: security in testing

[Steve Kemp]

On Fri, May 16, 2003 at 01:39:20PM -0400, Matt Zimmerman wrote:

> > If a member of the sec-team says "Yes, we are actively trying to
> > find
> > new members, but finding competent and responsive people who have
> > the
> > time and will to help is very difficult", then I'm happy and shut
> > up.
>
> Well, then. :-)

  Every time I get a few spare hours I glance over list of packages
 needing work, and tagged security:

http://qa.debian.org/bts-security.html

  Of the packages listed there 23 out of the 147 entries contain
 patches, (some of these patches may well be bogus).

  So it seems like a simple matter to apply and rebuild them, short
 of performing an NMU it seems that there's little a random developer
 could do.

  Adding more patches is something I could manage, and others too, but
 I'd worry that they'd just get left there growing old along with the
 others..

Steve
---


pgp9KFnoGQHOb.pgp
Description: PGP signature

Re: Where are translated man pages packaged?

[Fabio Massimo Di Nitto]

On Fri, 16 May 2003, Keegan Quinn wrote:

> > more than once i had to install small dns servers on boxes with less than
> > 100Mb flash and stuff like that... so basically also the minimal
> > installation has to be tight.. then rm doc and man and after install the
> > minimum sets of pkgs to provide the services.
>
> Please do not try to force this methodology upon the standard Debian base
> system.  Administrators of embedded systems have many tools to deal with
> these problems already, that do not require ever unpacking the full base onto
> the target.

sorry but i can hardly read from the previous post that i am trying to
force something to someone. I guess this is just a misunderstanding.

Fabio

-- 
Our mission: make IPv6 the default IP protocol
"We are on a mission from God" - Elwood Blues

http://www.itojun.org/paper/itojun-nanog-200210-ipv6isp/mgp4.html

Re: security in testing

[Stephen Frost]

* Michael Banck ([EMAIL PROTECTED]) wrote:
> You seem to fail to understand that people don't pull security updates
> from Joe-Random-NM-or-not's server. Of course, one can setup a
> repository with testing-security-updates. Whether it would (or should)
> actually be used is another matter.

People pull all kinds of stuff from all kinds of people's servers.  What
you fail to understand is that not being a DD doesn't mean you can't do
the work.

> I'm all for starting, implementing and testing *new* projects outside of
> the current infrastructue before they get transferred to .debian.org.
> But the infrastructure and the procedures *are* there, we just need to
> do it.

So do it.  You don't need it to be part of the current infrastructure,
it doesn't save you much time, as I was trying to point out.

> Huh? How could a DD create a repository somebody else cannot? The only
> place that would be is people.debian.org/~, right? That'll be
> quite a bad place for security updates because I think one still cannot
> pin different repositories at p.d.o to different priorities. Correct me
> if I'm wrong.

You're misunderstanding the comment.  Were you made a DD the only work
you wouldn't have to do to create testing security updates would be to
create the repository.  You'd have to do all the rest, which is where
the real effort is.

> > You took the comment out of context and then replied to it as that.
>  
> I was not aware that you might actually argue about such a minor
> implementation detail. Sure, I could have setup a repository while I was
> writing those lines, but what does an empty repository serve to the
> problem? You seem to say yourself that it actually takes time to provide
> security updates. 

An empty repository is what you'd get if you were a DD.

> Time, and the trust of the other debian developers, the users and
> ideally of the security-team. There are a couple of DDs whose
> security-for-testing-repository would be put instantly into my
> sources.list (if I'd actually ran testing). There are a couple of others
> I'd rather install Windows98 at home like my parents urge me to do than
> do that.

Time is certainly needed.  Trust is needed if you want it to be an
official part of Debian.  If you spend the time you'll likely get the
trust after a while if things go well.

Stephen


pgp0ldbUTqdEm.pgp
Description: PGP signature

Re: Constitutional amendment: Condorcet/Clone Proof SSD vote tallying

[Ben Collins]

> ==
> 
> PROPOSAL
> __
> 
>  Constitutional amendment: Condorcet/Clone Proof SSD  vote tallying:
> __

I second this resolution.

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo   - http://www.deqo.com/


pgpB7NFmay7mo.pgp
Description: PGP signature

Re: security in testing

[Michael Banck]

On Fri, May 16, 2003 at 01:39:20PM -0400, Matt Zimmerman wrote:
> On Fri, May 16, 2003 at 02:41:47PM +0200, Michael Banck wrote:
> http://lists.debian.org/debian-devel-announce/2003/debian-devel-announce-200305/msg5.html

I stand corrected.

> > If a member of the sec-team says "Yes, we are actively trying to find
> > new members, but finding competent and responsive people who have the
> > time and will to help is very difficult", then I'm happy and shut up.
> 
> Well, then. :-)

Great. Thanks for letting me know, Matt.

Michael

-- 
 gibs vielleicht eine debain mailing list zu dhcp?
 debian-c-netzprobleme-in-wohnheimen-bei-ethernet-mit-
[EMAIL PROTECTED]

Re: Where are translated man pages packaged?

[Keegan Quinn]

On Friday 16 May 2003 11:45 am, Fabio Massimo Di Nitto wrote:
> On Fri, 16 May 2003, Keegan Quinn wrote:
> > > more than once i had to install small dns servers on boxes with less
> > > than 100Mb flash and stuff like that... so basically also the minimal
> > > installation has to be tight.. then rm doc and man and after install
> > > the minimum sets of pkgs to provide the services.
> >
> > Please do not try to force this methodology upon the standard Debian base
> > system.  Administrators of embedded systems have many tools to deal with
> > these problems already, that do not require ever unpacking the full base
> > onto the target.
>
> sorry but i can hardly read from the previous post that i am trying to
> force something to someone. I guess this is just a misunderstanding.

Perhaps the word 'force' was a bit harsh, but it's essentially how it works 
for an end-user.  It seemed to me that you were suggesting that the standard 
installer should be optimized for embedded systems, which does not sound like 
a very good idea.  These systems have many specialized needs which cannot be 
easily accounted for.

 - Keegan

Comments and proposals for security bugs

[Drew Scott Daniels]

There are many questions and comments about how the security team, RM and
others handle security bugs. Some change is desired by at least several
people. I've already started trying to help clean up security bugs. I
won't even bother volunteering for the security team until I've had my
identity verified (...no key and ~6h to a Dd... it'll happen though).

I'd propose that:
Package maintainers:
- should be in charge of fixing RC bugs in their packages in Testing and
Unstable. NMU's should of course be allowed in the usual fashion, with RC
bugs being allowed to get NMU'd faster.
- track their RC bugs in stable, testing and unstable publicly and not
forget about oldstable while it's supported.

The RM and those with authority (mini RM's?):
- allow and encourage RC bugs patched packages to go into
testing-proposed-updates (in the same way it's done with stable)
- decide if they want to bother moving packages from
testing-proposed-updates to testing (this could be problematic in tracking
bugs or upgrading from packages in testing to later ones in unstable).

The security team:
- Adopt a policy such as the one discussed [2], but preferably a modified
version to reflect current practices
- Include any available information about testing in their DSA's (the same
as they currently do for unstable)
- Pass any information about potential security bugs to maintainers, and
when they're public, file a bug in the BTS (they already do this for the
most part)
- Not have to check if testing packages are vulnerable
- Not have to release DSA's for packages not vulnerable in stable and
oldstable
- Not allow packages

Some volunteers could help:
- Colin Watson write the version tracking BTS
- track security bugs [4] that are in advisories, alerts, reports... and
put public information into the BTS (see [3] for details)
- make sure bugs (particularly security and RC bugs) are tagged properly
(including checking what distributions are affected)
- verify information that's in the BTS (especially see
http://qa.debian.org/bts-security.html ), maybe using the confirmed tag I
haven't looked at it's use yet.
- write patches for RC bugs in stable, oldstable, testing and sometimes
even unstable, put them in the BTS and tag them +patch
- do or at least prepare NMU's for packages when appropriate (see [3] for
some details)
- maintain a conflicts based solution to RC bugs (if there's a bug in only
one program in a package, how should that be handled? Especially a minor
program in a package with many reverse dependencies)



I am personally of the belief that security updates for testing should go
to testing-proposed-updates or alike and not security.debian.org  Archives
in security.debian.org would then have to track later versions of packages
in testing so as not to be out of date. I feel that this could only be
reasonable/acceptable after a nearly solid freeze.


Security in testing and unstable almost requires BTS version tracking or
at least version tracking of RC bugs. mdz told me, and debian-devel
recently, that he's tracking what versions close security bugs. In a
private email he also told me that he's working on an interface and that
he can't release the information publicly right now as it sometimes
contains private information (probably for things like CERT co-ordination
of advisories). If you check the archives of debian-mentors and then
debian-debugs you'll see that Colin Watson is planning to work on version
tracking for the BTS (don't bug him, but if you're interested in
contributing, talk in debian-debbugs).

A conflicts based package solution could work a great deal nicer with a
version tracking BTS. A conflicts based solution might not have to care
about the minor program in a major package issue, nor have to track to see
when a testing fix makes it into testing, but it certainly would be
helpful. It'd also be nice if a conflicts based solution could have
version conflicts to allow fixes from unstable, stable or oldstable.


I can say for certain that there are outstanding DSA worthy issues (e.g.
ptrace in the Linux Kernel, see [1] for details), but I can't say as to
when or if they will be released. I've been hoping that a security policy
could be adopted such as earlier ones discussed in an old debian-devel
thread [2]. It was suggested (implied by two statements in [2]) that
advisories should be issued within one week even if a patch is not
available, while I don't totally agree with that, I would like there to be
a canonical place to track *public* security bugs. A public security bug
is one that has been reported elsewhere (see [3] for some places). There
is a problem with this in that it takes a great deal of time and effort to
verify that the bug actually exists in even the two versions of packages
that the Security team supports.

Temporary advisories seem to happen infrequently if at all (see the open
security bugs), and imho for good reasons like the exploit has low
hazard/low risk/mitigating factors. I'd still li

新软通用进销存-----满足用户全面管理

[新软]

debian-devel:您好!
《新软通用进销存》 
针对中小型企业的管理特点，满足用户全面管理、进货、销售、代销、前台收款、资金
往来、库存、发票、报表打印输出、毛利统计、销售统计、采购价格比较、产商资料、客户资料、货品销售排
行榜、客户消费排行榜、权限管理、安全备份等各项工作

新适用范围：中小型企业、个体销售商 

详细介绍请进入本站查看
本软件免费试用一个月
 
新软　http://mail88.5188.org/ http://soft88.5188.org/ 

Re: security in testing

[Andreas Metzler]

Michael Banck <[EMAIL PROTECTED]> wrote:
[...]
> Huh? How could a DD create a repository somebody else cannot? The only
> place that would be is people.debian.org/~, right? That'll be
> quite a bad place for security updates because I think one still cannot
> pin different repositories at p.d.o to different priorities. Correct me
> if I'm wrong.
[...]

It is possible if $developer puts a meaningful Release-file in his
repository.
   cu andreas

Re: security in testing

[Michael Banck]

On Fri, May 16, 2003 at 02:49:28PM -0400, Stephen Frost wrote:
> * Michael Banck ([EMAIL PROTECTED]) wrote:
> > You seem to fail to understand that people don't pull security updates
> > from Joe-Random-NM-or-not's server. Of course, one can setup a
> > repository with testing-security-updates. Whether it would (or should)
> > actually be used is another matter.
> 
> People pull all kinds of stuff from all kinds of people's servers.  What
> you fail to understand is that not being a DD doesn't mean you can't do
> the work.

I wouldn't feel like setting up a repository for testing that only
clueless people-who-put-every-apt-line-they-see-in-their-sources-list[0]
would use.

> > I'm all for starting, implementing and testing *new* projects outside of
> > the current infrastructue before they get transferred to .debian.org.
> > But the infrastructure and the procedures *are* there, we just need to
> > do it.
> 
> So do it.  You don't need it to be part of the current infrastructure,
> it doesn't save you much time, as I was trying to point out.

1. See above
2. I don't have the time
3. I'm not running testing

oh, and:

4. I would have to get a s/390
 
> > Huh? How could a DD create a repository somebody else cannot? The only
> > place that would be is people.debian.org/~, right? That'll be
> > quite a bad place for security updates because I think one still cannot
> > pin different repositories at p.d.o to different priorities. Correct me
> > if I'm wrong.
 
> You're misunderstanding the comment.  Were you made a DD the only work
> you wouldn't have to do to create testing security updates would be to
> create the repository.  You'd have to do all the rest, which is where
> the real effort is.

> An empty repository is what you'd get if you were a DD.

I must be totally missing something. Is one getting the s3kr1t
"create-a-repository-key" when you are becoming a DD? Where would these
repositories be located? Nobody told me so!

Sorry that I'm not getting this.

Michael

-- 
[0] What's the official abbreviation/jargon term for those people?

Re: Questions regarding utf-8

[Bob Hilliard]

Andreas Metzler <[EMAIL PROTECTED]> writes:

> *prompt* echo ö§ | recode latin1..ascii
> "oSS
> *prompt* echo ö§ | iconv -f latin1 -t
> ascii//TRANSLIT ; echo $?
> oe?
> --
> »oe« is much better than »"o« and »SS« is no usable replacement for
> »§«  (I do not think there is one), it would be nice if iconv's
> exit-status reflected whether questionmarks were used, but changing
> this would probably break existing software.

 I agree oe is much better than "o, but I can't get that:

bob:vc-p2:bob>echo ö§ | iconv -f latin1 -t ascii//TRANSLIT
??

 I have iconv 2.3.1.  Is it possible that my locale affects the
glyphs iconv returns?  My locale is C.  What locale are you using?

 Following are the values recode gives for the most common
non-ASCII characters: 

ä   à   ç  ñ   ê   ô   ö   ß   £ 
"a  `a  c  ~n  ^e  ^o  "o  ss  lb

 For all of these, iconv returns '?' on my system.

 I have not been able to find recode's transliteration of é. In
all cases I have tried, recode truncates the balance of the word
containing é, and the beginning of the next word, as in the following
examples:

Pierre Bézier
Pierre B

Conseil Européen pour la Normalisation.
Conseil Europour la Normalisation.

Comité Européen de Normalisation
Comitrope Normalisation

André Fischer
Andrcher

Réseaux Associés pour la Recherche Européenne
Rx Associur la Recherche Europ

Répondez s'il vous plait
Rez s'il vous plait

 I am not happy with the values recode gives, but, in most cases,
they are better than the ?.  I would like to learn how to make iconv
give results similar to those you get.

Regards,

Bob
-- 
   _
  |_)  _  |_Robert D. Hilliard<[EMAIL PROTECTED]>
  |_) (_) |_)   1294 S.W. Seagull Way <[EMAIL PROTECTED]>
Palm City, FL 34990 USA   GPG Key ID: 390D6559 

Re: Where are translated man pages packaged?

[Keegan Quinn]

On Friday 16 May 2003 12:13 pm, Keegan Quinn wrote:
> On Friday 16 May 2003 11:45 am, Fabio Massimo Di Nitto wrote:
> > On Fri, 16 May 2003, Keegan Quinn wrote:
> > > > more than once i had to install small dns servers on boxes with less
> > > > than 100Mb flash and stuff like that... so basically also the minimal
> > > > installation has to be tight.. then rm doc and man and after install
> > > > the minimum sets of pkgs to provide the services.
> > >
> > > Please do not try to force this methodology upon the standard Debian
> > > base system.  Administrators of embedded systems have many tools to
> > > deal with these problems already, that do not require ever unpacking
> > > the full base onto the target.
> >
> > sorry but i can hardly read from the previous post that i am trying to
> > force something to someone. I guess this is just a misunderstanding.
>
> Perhaps the word 'force' was a bit harsh, but it's essentially how it works
> for an end-user.  It seemed to me that you were suggesting that the
> standard installer should be optimized for embedded systems, which does not
> sound like a very good idea.  These systems have many specialized needs
> which cannot be easily accounted for.

Although, in retrospect, I wouldn't object at all to a different installer 
which is actually designed for embedded systems.  :)  I'm not sure if work is 
being done along these lines or not.

 - Keegan

Re: Where are translated man pages packaged?

[Fabio Massimo Di Nitto]

On Fri, 16 May 2003, Keegan Quinn wrote:

> On Friday 16 May 2003 11:45 am, Fabio Massimo Di Nitto wrote:
> > On Fri, 16 May 2003, Keegan Quinn wrote:
> > > > more than once i had to install small dns servers on boxes with less
> > > > than 100Mb flash and stuff like that... so basically also the minimal
> > > > installation has to be tight.. then rm doc and man and after install
> > > > the minimum sets of pkgs to provide the services.
> > >
> > > Please do not try to force this methodology upon the standard Debian base
> > > system.  Administrators of embedded systems have many tools to deal with
> > > these problems already, that do not require ever unpacking the full base
> > > onto the target.
> >
> > sorry but i can hardly read from the previous post that i am trying to
> > force something to someone. I guess this is just a misunderstanding.
>
> Perhaps the word 'force' was a bit harsh, but it's essentially how it works
> for an end-user.  It seemed to me that you were suggesting that the standard
> installer should be optimized for embedded systems, which does not sound like
> a very good idea.  These systems have many specialized needs which cannot be
> easily accounted for.

No i was not suggesting either. I was just explaining why i would like to
avoid to get a bigger base system and giving out one of the reason. it was
an example, no more no less. anyway no big deal ;)

Fabio

-- 
Our mission: make IPv6 the default IP protocol
"We are on a mission from God" - Elwood Blues

http://www.itojun.org/paper/itojun-nanog-200210-ipv6isp/mgp4.html

Re: Constitutional amendment: Condorcet/Clone Proof SSD vote tallying

[Matthias Urlichs]

Hi,
>>  Constitutional amendment: Condorcet/Clone Proof SSD  vote tallying:
>> __
> 
> I second this resolution.

The accepted procedure seems to be to
- quote the full resolution
- sign your response (!)
- send the reply to debian-vote.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
-- 
Afternoon, n.:
That part of the day we spend worrying about how we wasted the morning.

Re: security in testing

[Stephen Frost]

* Michael Banck ([EMAIL PROTECTED]) wrote:
> I wouldn't feel like setting up a repository for testing that only
> clueless people-who-put-every-apt-line-they-see-in-their-sources-list[0]
> would use.

Others would see what you had done and you could post patches to the BTS
with the fixes in them, etc.

> 1. See above
> 2. I don't have the time
> 3. I'm not running testing

Ah, so, you don't have the time.  That would be the reason testing
hasn't got security updates- not enough skilled people with the time to
actually *do* it.  People with the time and skills, DD or not, could
provide updates and eventually I think these people and updates would be
incorporated into Debian in a move where Debian would then start
officially supporting testing.  I don't believe Debian should ever do it
piecemeal or partially.  If it's going to be done then it needs to be
done completely and we must have enough people to do it before we
announce that we will.

> 4. I would have to get a s/390

While having one would be fun if you'd actually been reading what I've
been saying you'd have noticed that you wouldn't have needed one.  You
wouldn't need to be running testing as your main system either.

> I must be totally missing something. Is one getting the s3kr1t
> "create-a-repository-key" when you are becoming a DD? Where would these
> repositories be located? Nobody told me so!
> 
> Sorry that I'm not getting this.

That's pretty clear.  

To create a respository you just need a couple debs and website and the
tools to create the Packages files, ie: dpkg-scanpackages.

Stephen


pgpuxi6JqiVJ5.pgp
Description: PGP signature

新软通用进销存-----满足用户全面管理

[新软]

debian-devel:您好!
《新软通用进销存》 
针对中小型企业的管理特点，满足用户全面管理、进货、销售、代销、前台收款、资金
往来、库存、发票、报表打印输出、毛利统计、销售统计、采购价格比较、产商资料、客户资料、货品销售排
行榜、客户消费排行榜、权限管理、安全备份等各项工作

新适用范围：中小型企业、个体销售商 

详细介绍请进入本站查看
本软件免费试用一个月
 
新软　http://mail88.5188.org/ http://soft88.5188.org/ 

Re: Constitutional amendment: Condorcet/Clone Proof SSD vote tallying

[Michael Banck]

On Fri, May 16, 2003 at 10:06:23PM +0200, Matthias Urlichs wrote:
> The accepted procedure seems to be to
> - sign your response (!)

He did.

Michael

-- 
 Well, if we can't talk about the Hurd here, we may as well
talk about sex.
 They are often equivalent. functionally speaking.
 neal: They last a short time under load?

Re: Questions regarding utf-8

[Andreas Metzler]

Bob Hilliard <[EMAIL PROTECTED]> wrote:
> Andreas Metzler <[EMAIL PROTECTED]> writes:
>> *prompt* echo ö§ | recode latin1..ascii
>> "oSS
>> *prompt* echo ö§ | iconv -f latin1 -t
>> ascii//TRANSLIT ; echo $?
>> oe?
>> --
>> »oe« is much better than »"o« and »SS« is no usable replacement for
>> »§«  (I do not think there is one), it would be nice if iconv's
>> exit-status reflected whether questionmarks were used, but changing
>> this would probably break existing software.

> I agree oe is much better than "o, but I can't get that:

> bob:vc-p2:bob>echo ö§ | iconv -f latin1 -t ascii//TRANSLIT
> ??

> I have iconv 2.3.1.  Is it possible that my locale affects the
> glyphs iconv returns?  My locale is C.  What locale are you using?
[...]

de_AT (uses ISO-8859-1 as charset).

LANG=de_AT, everything else is unset:
*prompt* echo ö§ | env -u LANG iconv -f latin1 -t ascii//TRANSLIT
??
*prompt* echo ö§ | env LANG=en_US iconv -f latin1 -t ascii//TRANSLIT
??
*prompt* echo ö§ | env LANG=de_AT iconv -f latin1 -t ascii//TRANSLIT
oe?
*prompt* echo ö§ | env LANG=fr_FR iconv -f latin1 -t ascii//TRANSLIT
o?
   cu andreas

Re: Constitutional amendment: Condorcet/Clone Proof SSD vote tallying

[Jose Carlos Garcia Sogo]

El día 16 may 2003, Matthias Urlichs escribía:
> Hi,
> >>  Constitutional amendment: Condorcet/Clone Proof SSD  vote tallying:
> >> __
> > 
> > I second this resolution.
> 
> The accepted procedure seems to be to
> - quote the full resolution
> - sign your response (!)

  The response is signed, and he doesn't need to quote the whole
  proposal if he doesn't want to.

> - send the reply to debian-vote.

  Yes, that's better for clearness, but I guess he hit reply on the mail
  sent to d-d-a, which is sent here by default.

-- 
  Jose Carlos Garcia Sogo
 [EMAIL PROTECTED]


pgp1F4EMICcNc.pgp
Description: PGP signature

Re: security in testing

[Michael Banck]

On Fri, May 16, 2003 at 04:09:28PM -0400, Stephen Frost wrote:
> * Michael Banck ([EMAIL PROTECTED]) wrote:
> > I wouldn't feel like setting up a repository for testing that only
> > clueless people-who-put-every-apt-line-they-see-in-their-sources-list[0]
> > would use.
> 
> Others would see what you had done and you could post patches to the BTS
> with the fixes in them, etc.

You seem to be missing something:

I'm not the least bit interested in running a testing-security
repository outside of Debian. Furthermore, I've neither the skill, nor the
time to contribute to something like this integrated to Debian. I've
merely pointed out that such a repository, maintained by a NM outside of
Debian, would not be *anywhere* near an acceptable solution, because of
the reasons I put forth in this thread.

You're saying: "You want security for testing? Do it yourself!"
I'm saying: "Sure, people could do it for themselves, but how would that
benefit Debian as a whole?"

> > 1. See above
> > 2. I don't have the time
> > 3. I'm not running testing
> 
> Ah, so, you don't have the time.  That would be the reason testing
> hasn't got security updates- not enough skilled people with the time to
> actually *do* it.  

Exactly.

> People with the time and skills, DD or not, could provide updates and
> eventually I think these people and updates would be incorporated into
> Debian in a move where Debian would then start officially supporting
> testing.  

Like I said, if people like dark, Kamion, vorlon, etc would go forth and
started a testing-security initiative, I'd be thrilled by this. If
 or somebody unknown to the project would come along,
people would say: "So what?" and go away.

> I don't believe Debian should ever do it piecemeal or partially.  If
> it's going to be done then it needs to be done completely and we must
> have enough people to do it before we announce that we will.
 
Exactly.

> > I must be totally missing something. Is one getting the s3kr1t
> > "create-a-repository-key" when you are becoming a DD? Where would these
> > repositories be located? Nobody told me so!
> > 
> To create a respository you just need a couple debs and website and the
> tools to create the Packages files, ie: dpkg-scanpackages.

Aha. And what exactly buys you being a DD in this regard? That's the
implementation detail I was talking about earlier. You said
repositories would be easier setup if one was a DD, if I'm not
completely mistaken?

Michael

-- 
 why can't alyssa milano live next door to me, be lonely and
need the satisfaction and fullfillment that only a 20 year old
computer programmer can provide...  
 
* azathoth shakes his fist at god and goes back to his debugging

Re: security in testing

[Stephen Frost]

* Michael Banck ([EMAIL PROTECTED]) wrote:
> You seem to be missing something:
> 
> I'm not the least bit interested in running a testing-security
> repository outside of Debian. Furthermore, I've neither the skill, nor the
> time to contribute to something like this integrated to Debian. I've
> merely pointed out that such a repository, maintained by a NM outside of
> Debian, would not be *anywhere* near an acceptable solution, because of
> the reasons I put forth in this thread.

It would be a start and I think that's what is needed.  It needs to be
started by someone, and I contend *anyone* can start it, before it will 
be possible to do it in full.

> You're saying: "You want security for testing? Do it yourself!"
> I'm saying: "Sure, people could do it for themselves, but how would that
> benefit Debian as a whole?"

Initially it would help only a few brave souls but were it kept up it
would slowly become trusted, along with those who ran it.  Eventually I
see it becoming a part of Debian and being of benefit to those who
choose to run testing.  Complaining without doing anything benefits no
one.

> > Ah, so, you don't have the time.  That would be the reason testing
> > hasn't got security updates- not enough skilled people with the time to
> > actually *do* it.  
> 
> Exactly.

So people need to be found who have the time and skills and are
interested.  I had thought that you met such criteria based on your
verbosity on this list but I suppose that was a poor assumption on my
part.

> Like I said, if people like dark, Kamion, vorlon, etc would go forth and
> started a testing-security initiative, I'd be thrilled by this. If
>  or somebody unknown to the project would come along,
> people would say: "So what?" and go away.

I contend that they don't need to start it, anyone can start it if they
have the time, interest and skills.  If the above had the time and 
inclination I expect they would have started it already.

What I hate hearing are claims that something can't be done because
someone isn't a DD.  It shows, in my view, a lack of true motivation to
do the work and becomes just an excuse to use to avoid doing the work
while retaining the feeling of rightousness to bitch about it.

> > I don't believe Debian should ever do it piecemeal or partially.  If
> > it's going to be done then it needs to be done completely and we must
> > have enough people to do it before we announce that we will.
>  
> Exactly.

Outside of Debian it could be started piecemeal until it's attracted
enough people to be able to do it for all of testing.

> Aha. And what exactly buys you being a DD in this regard? That's the
> implementation detail I was talking about earlier. You said
> repositories would be easier setup if one was a DD, if I'm not
> completely mistaken?

They're already set up if you're a DD, you just upload to the official
Debian repository.

Stephen


pgpVzICszBraZ.pgp
Description: PGP signature

Re: security in testing

[Michael Banck]

On Fri, May 16, 2003 at 05:35:01PM -0400, Stephen Frost wrote:
> It would be a start and I think that's what is needed.  It needs to be
> started by someone, and I contend *anyone* can start it, before it will 
> be possible to do it in full.

The thing is: The autobuilders for testing-security are already setup.
Handling security-advisories is already semi-automatic. The
security-team already has access to vender-sec.

I'd consider it a waste of resources to duplicate this infrastructure
outside of Debian, just so that somebody we can't really trust does it.

> > Aha. And what exactly buys you being a DD in this regard? That's the
> > implementation detail I was talking about earlier. You said
> > repositories would be easier setup if one was a DD, if I'm not
> > completely mistaken?
> 
> They're already set up if you're a DD, you just upload to the official
> Debian repository.

Ah, ok. But please consider that one cannot upload security-fixes to
testing via the official debian repository right now. testing-security
is (not) handled by the sec-team and t-p-u needs explicit approval by
the testing-RM. That's why I did not understand your point.

Michael

-- 
 welche grafische oberfläche verwendest du  unter Linux ?  gnome 
kde  oder eher fluxbox -> blackbox ..
 eh, gar keine. ich verwendet GNU Emacs 21 auf einem terminal
 mhh wat sind überhaupt emacs ?

Discussion period starts for the Constitutional amendment: Condorcet/Clone Proof SSD vote tallying

[Manoj Srivastava]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi folks,

We have six seconds (well, five people on public mailing
 lists) for the GR labelled: "Constitutional amendment:
 Condorcet/Clone Proof SSD vote tallying". It would not hurt to get a
 few more sponsors for this GR.

=
 4.2. Procedure
   
  1. The Developers follow the Standard Resolution Procedure, below. A
 resolution or amendment is introduced if proposed by any Developer
 and sponsored by at least K other Developers, or if proposed by
 the Project Leader or the Technical Committee.
  4. The minimum discussion period is 2 weeks, but may be varied by up
 to 1 week by the Project Leader. The Project Leader has a casting
 vote. There is a quorum of 3Q.
  7. Q is half of the square root of the number of current Developers.
 K is Q or 5, whichever is the smaller. Q and K need not be
 integers and are not rounded.
==

So, we only need 5 sponsors, apart from the proposer. I now
 state that the formal discussion period starts at Fri May 16 23:59:59 UTC 2003,
 and ends at Fri May 30 23:59:59 UTC 2003. 

The sponsors to date are:
  Joel Baker<[EMAIL PROTECTED]>
  Colin Walters <[EMAIL PROTECTED]>
  Ben Collins <[EMAIL PROTECTED]>
  Simon Law <[EMAIL PROTECTED]>
  Fabio Massimo Di Nitto  <[EMAIL PROTECTED]>
  Bas Zoetekouw <[EMAIL PROTECTED]>

manoj
- -- 
A day without sunshine is like night.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Processed by: Debian GNU/Linux -> Emacs -> Gnus -> Mailcrypt

iD8DBQE+xWBTIbrau78kQkwRAt3UAJ4uWG3K+JhGPmpOoDyK0IuoF+A1nQCdHpwr
5jy3cFToC8Y8wNlqqtJN5RM=
=7Iwg
-END PGP SIGNATURE-

Bug#193606: ITP: swftools -- utilities for handling flash .swf files

[Juan Manuel García Molina]

Package: wnpp
Version: unavailable; reported 2003-05-17
Severity: wishlist

* Package name: swftools
  Version : 0.4.4-1
  Upstream Author : Matthias Kramm <[EMAIL PROTECTED]>, Rainer Böhme <[EMAIL 
PROTECTED]>
* URL : http://www.quiss.org/swftools/
* License : GPL
  Description : utilities for handling flash .swf files

  SWF Tools is a collection of SWF manipulation and generation utilities
  written by Rainer Böhme and Matthias Kramm. It is released under the
  GPL.
  .
  This includes a merging tool (swfcombine), an extracting tool
  (swfextract), PDF/JPEG/PNG/AVI/WAV to SWF converters (pdf2swf,
  jpeg2swf, png2swf, avi2swf, and wav2swf), a text parsing tool
  (swfstrings), an SWF parser (swfdump), and a library for writing
  and reading SWFs (rfxswflib).

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux azuaga 2.4.20-ck6 #2 mié may 14 12:53:10 CEST 2003 i686
Locale: LANG=spanish, LC_CTYPE=spanish (ignored: LC_ALL set)

Bug#193606: ITP: swftools -- utilities for handling flash .swf files

[Chris Butler]

On Sat, May 17, 2003 at 12:10:38AM +0200, Juan Manuel García Molina wrote:
> Package: wnpp
> Version: unavailable; reported 2003-05-17
> Severity: wishlist
> 
> * Package name: swftools

Last time I checked this package, it contained MP3 encoding code from
LAME - which cannot be included in Debian due to patent issues.

-- 
Chris


pgpf3XOkNXsdN.pgp
Description: PGP signature

Testing the voting scripts

[Manoj Srivastava]

Hi folks,

I would like to test the new voting scripts, complete with
 signed acks. I'll be running this vote over on my home machine,
 pending the resolution of the fact that devotee does not run on
 potato (vote.d.o runs potato).  This vote would also be a good test
 of the super majority calculations, since two of the options require
 super majority.

Just replying to this message should be OK. Please do not
 encrypt the ballot, since the vote scripts can't deal with that yet.

May the best color win.

manoj

--
 Votes must be received by 23:59:59 UTC on May 29th, 2003.

This vote is being conducted to test the voting mechanism for Debian.
The object of this vote is to determine which color of the rainbow is
most favoured by Debian developers. Since Ultra Violet and Infra Red
are not traditionally seen as part of the rainbow colors, they need a
2:1 super majority to win this vote.  For voting questions contact
[EMAIL PROTECTED]

HOW TO VOTE

Do not erase anything between the lines below and do not change the
choice names.

In the brackets next to your preferred choice, place a 1. Place a 2 in
the brackets next to your next choice. Continue till you reach your
last choice. Do not enter a number smaller than 1 or larger than 5.
You may skip numbers.  You may rank options equally (as long as all
choices X you make fall in the range 1<= X <= 5).

To vote "no, no matter what" rank "None Of The Above" as more
desirable than the unacceptable choices, or You may rank the "None Of
The Above" choice, and leave choices you consider unacceptable
blank. Unranked choices are considered equally the least desired
choices, and ranked below all ranked choices. (Note: if the None Of
The Above choice is unranked, then it is equal to all other unranked
choices, if any -- no special consideration is given to the None Of
The Above choice by the voting software).

Then mail the ballot to: [EMAIL PROTECTED] Don't worry about
spacing of the columns or any quote characters (">") that your reply
inserts. NOTE: The vote must be GPG signed (or PGP signed) with your
key that is in the Debian keyring. Do _NOT_ encrypt your ballot; the
voting mechanism may not be able to decrypt your message.

- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
[   ] Choice 1: Ultra Violet
[   ] Choice 2: Violet
[   ] Choice 3: Indigo
[   ] Choice 4: Blue
[   ] Choice 5: Green
[   ] Choice 6: Yellow
[   ] Choice 7: Orange
[   ] Choice 8: Red
[   ] Choice 9: Infra Red
[   ] Choice 10: None Of The Above

- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-

As an experimental measure, the responses to a valid vote shall be
signed by the vote key created for the rainbow vote. The public ket
for the vote, signed by the Project secretary, is appended below.

pub  1024D/DDB871CC 2003-05-14 The Debian Rainbow vote key (This is an 
insecure, temporary vote mechanism key) <[EMAIL PROTECTED]>
sigDDB871CC 2003-05-14   [selfsig]
sigBF24424C 2003-05-15   Manoj Srivastava <[EMAIL PROTECTED]>
sub  1024g/01ED1673 2003-05-14  [expires: 2003-07-13]
sigDDB871CC 2003-05-14   [keybind]

-BEGIN PGP PUBLIC KEY BLOCK-
Version: GnuPG v1.2.2 (GNU/Linux)

mQGiBD7CcE4RBACcn0BOn65VY7SFPU4nPmem1nqcgQfYTbGFOJmXVX+k0UzbZCMg
22bKCakXEqEy7pDWCgjVmSeFeBLhUMKjPkCgQhOdzCWJpWgAV8Yzo/mbqQx6nndl
gjaRQCIh2uiTB6degPdSjcuCQVBnS+y2ns0R4vw7igaVndFCD5gjjc0LqwCg23ne
+HuK2pQqIjRM7y9qIDv76VUD+gPuSaxxD028aM+Jnb46+mngBYNiCGxnk7ZYXML6
s3BLvGLKHM3ikZ/7buYz3X85iCSVUWl5kwDLIYY7fVVH8uUL9c0DipoBginW3sr/
/wLGaSLZbsUvmmrrOf/FdW2F6N7eiqOcLNPXxXELJoAjSsReFiUb+mtoNcXKS0F0
qSJeA/9Rb9u1tH9MZz6alfRPnnzPJNGfndKM5WtH87u5Y4znxa1M+YrlxHPP7UFR
ZNfC766OEP+aQQMGxrB66eqoVEc1rysyDx93HOEtumJJJVGGH/SfSAyNWWNXnf/i
tu6PpmreCZowcQCUyXAwsSqT5kcLlqx1QyOFhS8kgBvWaUpCxrRpVGhlIERlYmlh
biBSYWluYm93IHZvdGUga2V5IChUaGlzIGlzIGFuIGluc2VjdXJlLCB0ZW1wb3Jh
cnkgdm90ZSBtZWNoYW5pc20ga2V5KSA8cmFpbmJvd0B2b3RlLmRlYmlhbi5vcmc+
iF0EExECAB0FAj7CcE4FCQBPGgAFCwcKAwQDFQMCAxYCAQIXgAAKCRCjZzrC3bhx
zAWmAJ9Ky5WUyrgA+r1C7kZm8MHqGLuWBQCguMiVcJQjpNE6G6kdj2ik7g9Pow+I
TAQQEQIADAUCPsQH3gWDAE2CcAAKCRAhutq7vyRCTFBaAKDNW3jsOkHY+9nm+9VA
3SOX20jmtwCfbSBOs7FCa9l3WS1ZKgp9zT4ps++5AQ0EPsJwUBAEAJWhmMu9t4ZN
bXHeF0SvCuXonsVd6E6/m9aLVicTsjx6yK3DWW4AsGM/oX5UF8SXC0rxoX2ytGET
WBH3OLyfevnO9VRSzHyOM/YBH8TE4jOoEr2Of4JBPM74liNV4kqeRyakColy2ki8
TFRl9YoIhwOgc7uQd/S4fX5bhC5qHpVfAAQNA/9pVTaDkopALSiZx8b3HdEs9pjR
FqoYS70/VRhWg8zDifEcNglR8BUqCuw1Qt6CbAVWNVjXm3a0V/l2AoIVEEYoMg2t
gTtj3HLiN1X3daF2lcyWwfDHzjrxmX/KHZxr8mdZBZkQfJbiW2th13HPydybu+Mh
RRM0klqDOUFq5ou274hMBBgRAgAMBQI+wnBQBQkATxoAAAoJEKNnOsLduHHMtZkA
nRvEPbtEoXyjIidlrZsiK2lpruW2AKC8pxgb4Hw/Jaj34tntE20Chy1Zmg==
=ZEeY
-END PGP PUBLIC KEY BLOCK-

-- 
Aren't you glad you're not getting all the government you pay for now?
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 

Re: security in testing

[Anthony Towns]

On Fri, May 16, 2003 at 09:30:46AM -0400, Matt Zimmerman wrote:
> > Yes, and funnily enough, uploads to -p-u have to be processed by the
> > release manager, either Joey for stable, or me for testing. How's the
> > phrase go? "You suggest distributing the workload, and your concrete
> > suggestions are exactly the opposite of that."
> "So add people."  See where this is going?
> With t-p-u, any maintainer can upload their package, review the build logs,
> fix any problems, re-upload, etc.  Why would you want the security team to
> do this instead?

One of the paragraphs you didn't quote answered that question:

> > Again, the security architecture is there for a reason: it's so
> > we have a quick, effective way to get security updates out and
> > so we can prepare security updates before they've been publically
> > announced. testing-proposed-updates simply does not manage either of
> > those things, just as stable-proposed-updates doesn't.

security.debian.org is setup for security updates -- it's specifically
designed to get them out as quickly as possible, to announce them,
and to keep the secret if they've not been widely announced.

I don't care if *you* are the person that's doing it, or if it's some
complete newbie to the security team; what I do care about is not wasting
or unnecessarily duplicating the infrastructure we've specifically
designed for this job.

Cheers,
aj

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

  ``Dear Anthony Towns: [...] Congratulations -- 
you are now certified as a Red Hat Certified Engineer!''


pgpp0tosKrTGp.pgp
Description: PGP signature

Bug#193612: ITP: fbpanel -- A lightwight X11 desktop panel

[Matthew Palmer]

Package: wnpp
Version: N/A; reported 2003-05-17
Severity: wishlist

* Package name: fbpanel
  Version : 1.0
  Upstream Author : Anatoly Asviyan <[EMAIL PROTECTED]>
* URL : http://fbpanel.sf.net/
* License : BSD
  Description : A lightweight X11 desktop panel
 FBPanel is a spinoff of the fspanel (f***ing small
 panel) with more eye candy.  It provides a taskbar
 (list of all opened windows), desktop switcher,
 launchbar, clock, is EWMH/NETWM compliant, and has
 modest resource usage.

Re: Constitutional amendment: Condorcet/Clone Proof SSD vote tallying

[Matthias Urlichs]

Hi, Michael Banck wrote:

>> - sign your response (!)
> 
> He did.

Oops, sorry, my mistake.  :-(

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
-- 
Relax, Julie. Everyone will understand.
-- Romeo