Re: security in testing

[Stephen Frost]

* Matthias Urlichs ([EMAIL PROTECTED]) wrote:
> Hi, Matt Zimmerman wrote:
> 
> > There is no shortage of opinions about what "we" should do, but there is
> > unlikely to be any action until an "I" arises who actually does the work.
> > This has been discussed over and over with the same result each time
> > (i.e., no action).
> 
> Two answers:
> (a) Before I do something like that, I'd need to be accepted as DD.

False statement.

> (b) Before I do something like that, I'd like to get some sort of rough
> consensus that this is in fact a good idea, i.e. nobody has serious
> problems with the approach.

Don't believe anyone has any serious problems with the approach and,
honestly, if you care enough about what other people think to not take
any action on your own chances are pretty good whatever you did wouldn't
get very far anyway.

Stephen


pgpCW19Wpo4z1.pgp
Description: PGP signature

Re: security in testing

[Anthony Towns]

On Wed, May 14, 2003 at 11:59:49PM -0400, Matt Zimmerman wrote:
> There are no mirrors of security.debian.org, and have not been for as long
> as I have been aware.  See the security team FAQ.

deb http://mirror.pacific.net.au/debian-security/ stable/updates main

> Do you honestly think would be a good idea to use testing-security this way
> on a continual basis?  

Yes, I do. I think we should release DSA's for security problems in
testing, too.

> Such an endeavor would not seem to require any of the
> facilities which make foo-security different from foo{,-proposed-updates}.

The same applies to stable: the key differences are immediacy,
announcements and control, all of which are equally valuable for testing
as stable. In any event, testing-proposed-updates exists and works at
present, the only thing missing is people reliably uploading to it, and
evaluating whether uploads work well enough to be included in testing
or not. All the technical issues have already been addressed.

> > > This is a related, more general issue, of how to minimize the blockage
> > > introduced by package dependencies.  I think this problem is much more
> > > worthwhile to address than security updates targeted at 'testing'.
> > You're wrong: blockages can never be cleared quickly enough to make for
> > timely security fixes. For security fixes, "timely" is "same day"; for
> > testing, "timely" is "a couple of weeks".
> Finding ways to minimize these blockages would benefit all packages'
> progress into testing, security fixes included, and thereby greatly benefit
> 'testing' users, whatever their motivation might be.

Except that there can be no testing users while we don't provide security
updates. Using testing on a multi-user machine, or one that provides any
network services on a machine connected to the network is not something
anyone can recommend in good conscience, and that rules out almost
everything Debian's actually good at.

> Sidestepping the process to provide this kind of "timely" security update
> for "unreleased" software, on the other hand, doesn't seem particularly
> valuable to me.

What, precisely, is unreleased about it?

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


pgp72RIkWpFap.pgp
Description: PGP signature

Re: security in testing

[LapTop006]

On Wed, May 14, 2003 at 11:59:49PM -0400, Matt Zimmerman arranged a set of bits 
into the following:
> There are no mirrors of security.debian.org, and have not been for as long
> as I have been aware.  See the security team FAQ.
FALSE.

There are at least several mirrors. I myself use them as for some reason
I can never keep a reliable connection to s.d.o.
I know of at least two in .au (Pacific Internet and PlanetMirror).
PlanetMirror is ftp.au.debian.org as well.
Whether or not these are official mirrors is besides the point, there
ARE mirrors and they ARE used and ARE required.


pgp073mG3CVkH.pgp
Description: PGP signature

Re: Do not touch l10n files

[Christian Couder]

Manoj Srivastava wrote :

> On Tue, 13 May 2003 09:12:25 +0200, Javier Fernández-Sanguino Peña
> <[EMAIL PROTECTED]> said:  
> 
> > Maintainers or developers do not have a say on how translations are
> > done except for gettext sintax errors. If you do not like how a
> > translation team works, but you do not understand the language,
> > tough luck.
> 
>If this is a turf war between translators and developers; then
>  the person with upload rights shall win. 
> 
> As a package developer I hold veto powers over anything
>  shipped in my package, since it is my signature that goes with it,
>  and I am responsible for all bugs. 

and

> > On Wed, 14 May 2003 19:25:20 +0200, Denis Barbier <[EMAIL PROTECTED]>
> > said: 
> 
> > > On Wed, May 14, 2003 at 02:22:36AM -0500, Manoj Srivastava wrote:
> > >> Silly? My, we must have a chip on our choulder. Equally silly as
> > >> non-maintainers having delusions of control over what gets shipped
> > >> with a package?
> 
> > > Where did I say that?  I am only requesting that developers who do
> > > not speak a given language do not edit their related l10n files, but
> > > ask first a trusted person fluent in this language if changes are
> > > needed.
> 
> This is no different from code: if I maintian software, and I
>  may not understand all the complexities of the package in question,
>  but when I think I discover a problem, I send a notice to the
>  upistream (coder, translator), and, if I am not fluenbt in the
>  language, I ask someone to help (who may not be the upstream
>  code/translator). 
> 
> I then add a local patch correcting the issue until the matter
>  is resolved upstream.
> 
> This is a far cry from ``Do not touch l10n files''. 
> 
> No one expects a maintainer to change code files either if
>  they result is incorrect; that is just a bug. But maintainers are not
>  admonished to never touch upstream files. 
> 
> If ever a translation is included in my packages, I certainly
>  am not going to respect such a restriction against modifying files in
>  my package.


The situation is very different from the situation maintainer face with 
upstream code because in fact apt should be able to install l10n packages 
related to a given program package when it installs the program package. 

So if l10n materials are currently integrated into program packages, instead 
of being in separate l10n packages, it's because of this lack in apt. It's 
not because the program package maintainer should also be responsible for 
l10n stuff related to the program, like he is responsible for the code in the 
program.

This lack in apt is very bad because :
- users get lot of l10n that is mostly useless for them,
- program packages are bloated with l10n stuff,
- maintainers' job is more difficult because they have to deal with stuff they 
don't understand,
- maintainer feel they are responsible for l10n material in _their_ package  
and feel the right to mess with the l10n material in _their_ package or to 
refuse l10n stuff,
- Translators do not maintain packages so are not considered Developers and 
have no vote,
- Translators have to deal with maintainers jealous of their rights on _their_ 
package.

Maintainers should realize that the current situation is (or should be) 
temporary and so that the power they currently have on l10n stuff is 
something temporary, something that they shouldn't have if things were done 
properly.

So Denis is very right to say "Do not touch l10n files".

Regards,
Christian.

Re: Returning from "vacation". (MIA?)

[Andreas Metzler]

Clay Crouch <[EMAIL PROTECTED]> wrote:
> My most humble apologies.

> It has become quite clear that the culture that the DD community
> shares has evolved in my absence. My absence disallowed me to
> evolve with it. The culture you now enjoy is not the one I left.

> I truly didn't expect to be attacked on my first post. I also
> truly didn't expect to be further lambasted from all quarters
> for responding to them.
[...]

I don't get it. I can't see an "attack" in
<[EMAIL PROTECTED]>. There was some critique, but
it was not hostile at all. OTOH <[EMAIL PROTECTED]>
_was_ evidently written to be offensive.

If people are telling you that you might be wrong they aren't attacking
you.
   cu andreas

Re: Returning from "vacation". (MIA?)

[Russell Coker]

On Thu, 15 May 2003 14:37, Matthias Urlichs wrote:
> Ahem. Your email wouls have to contain a few highly unlikely phrases to be
> classified as "uncertain" by me. FWIW, yours ends up as
>
> X-Spam-Status: No, hits=-42.6 required=5.0

Sorry, if you are only using that when spamassasin records it as a likely spam 
then that's OK.

Most people who use spamassasin just bounce or discard the message if it 
matches.  Using such a process instead is not so bad.

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

Re: Answers to "Why is package X not in testing yet?"

[Björn Stenberg]

Joe Buck wrote:
> However, the output is redundant in many cases.

Fixed now.

-- 
Björn

RE：回复：合作

[张]

对不起 打扰之处请见谅

本公司是一家专业致力于网络服务的专业性公司，提供高质空间，优质服务，为您建设网站提供必不可少的各类型空间及域名；

域名80元 送20个次级域名

标准主机空间 100M网站空间+100M邮局空间 
可支持asp/php/cgi/access 可运行论坛程序200元/年

不论您是单位企业还是个人，我们都将竭诚为您提供贴身个性化的网络支持服务

同时本公司还推出网站建设服务，最低999元就可让您拥有包含：空间+域名+邮局+网页 
的完整网站

同时为只需简单介绍各类信息的个人及企业提供网站简化模式――网络名片
最低只需100元/年

如果您在单位里不是负责这方面事情的人，在表达歉意的同时，也希望您顺手转发给贵单位负责这方面事情的负责人，您一个举手之劳，就会让单位觉得您在关心单位，为单位着想，何乐而不为呢！

非常感谢!

现广招天下有志网络创业的朋友 加入吧  轻松上网做代理  
一同为打造中国企业的网络品牌而努力有意与我联系 等候您的加入

联系人：张先生  QQ 9651016  [EMAIL PROTECTED]   

Re: "Bug marked as done" messages to-be-MIMEified?

[Adrian 'Dagurashibanipal' von Bidder]

On Wednesday 14 May 2003 16:05, Mark Brown wrote:
> On Wed, May 14, 2003 at 02:24:25PM +0100, Colin Watson wrote:
> > Usually this is controlled by the Content-Disposition: header.
> > "Content-Disposition: inline" should be displayed inline;
> > "Content-Disposition: attachment" will often be hidden until explicitly
> > opened.
>
> Assuming the mail client pays attention, of course.

I guess using MIME structures like that more would make more people complain 
to devlopers of MUAs that don't handle this properly...

I don't know many MUAs, but perhaps others do.

Q: is content-disposition handled properly, especially for messag/rfc822 type 
attachments? (Or if not, are message attachments displayed inline by 
default?)

KMail 1.5.1: yes
Evolution: yes (already in 1.0.x IIRC)
sylpheed?
mozilla mail? (whatever the name of that thing is right now...)

I guess quite critical would be
mutt
pine

as especially developers are known to use textmode mail readers quite a lot.

(Yes, I've stopped caring about users of a certain other widespread MUA, as 
you've probably guessed anyway when you notice me using PGP/MIME to sign 
messages...)

cheers
-- vbi

-- 
random link of the day: http://fortytwo.ch/sienapei/laegoong


pgp8HVqzpTEpK.pgp
Description: signature

Re: security in testing

[Sven Luther]

On Wed, May 14, 2003 at 03:57:58PM -0400, Michael Stone wrote:
> On Wed, May 14, 2003 at 10:14:53AM -0500, Gunnar Wolf wrote:
> >I'm sorry, I am on a public terminal, and can't quite remember where I
> >read it - But testing should always be close to a releasable state.
> 
> That assumption is both false and absurd. Testing has exactly two
> advantages over unstable--1) all dependencies are satisfied and 2) known
> rc bugs don't propagate to testing. In all other respects unstable is
> better. (Security problems, rc bugs not noticed during the first two
> weeks, etc.)

But we don't advertize this, so it is natural that people make the
mistake and use testing instead of unstable.

Friendly,

Sven Luther

Re: security in testing

[Björn Stenberg]

Manoj Srivastava wrote:
> > This is, after all, more than just a herd of cats.
> How on earth did you get that quaint idea?

>From looking at Debian. It is far more structured, organised and controlled
than the great majority of free software projects out there.

> If you want a universally held firm direction, go read the social
> contract. That is as close as you are going to get.

I disagree. There is obviously a consensus on a number of important issues,
such as that making all ports adhere to the lowest common denominator is more
important than letting a few ports catch up with time.

Direction need not come from on high, it more often evolves from long
discussions in developer mailing lists. That does not mean it does not exist.

-- 
Björn

Re: Do not touch l10n files [without notifying translators]

[Martin Quinson]

On Wed, May 14, 2003 at 01:03:07PM -0500, Manoj Srivastava wrote:
> On Wed, 14 May 2003 19:17:50 +0200, Javier Fernández-Sanguino Peña <[EMAIL 
> PROTECTED]> said: 
> 
> > On Wed, May 14, 2003 at 02:18:04AM -0500, Manoj Srivastava wrote:
> >> As a package developer I hold veto powers over anything shipped in
> >> my package, since it is my signature that goes with it, and I am
> >> responsible for all bugs.
> 
> > You do hold upstream responsible for the bugs in their software
> > right?
> 
>   I don't shrug off my responsibilities so lightly. I am
>  responsible for all my packages. I may need help to solve or diagnose
>  some bugs, but every single bug on my packages receives my attention,
>  and I work on trying to gather enough information to help upstream
>  debug those issues.
> 
>   In case the upstream does not respond, or does not think it is
>  a bug, I create local patches. 
> 
> 
> > From my point of view, same should go for translators.
> 
>   Sure. When (if?) translated descriptions are included in
>  packages, I'll contact the translators fiirst, perhaps including
>  local changes until the matter is resolved.  Just like I do with
>  upstream code. 

So, I would say that you are handling translations right, and there is no
need to get hurt by Denis's complain. It wasn't directed at all maintainers,
but to the ones feeling confident enough to corrupt l10n files *without
informing the translator of their changes*.

I admit that his tone was quite categorical, but he was only repporting a
problem which exists (we have some example of bad habits, but giving any
name would only lead to more people feeling insulted, and a bigger flamewar,
which would help nobody). If you don't do the stuff he is complaining about,
if, as Colin said, the collaboration between you and the tranlators
colaborating on your packages is based on mutual respect, everything is
perfect, and there is no need for yet another flamewar here.

Please don't get me wrong. I understand that the tone of the complain may
lead too easily to such flamewar (ie, I don't say that you or anybody else
wanted to get this flamewar), but I would like people to understand that
instead of flooding -devel yet another time, we should document somewhere
what the best current practices are concerning l10n (yours are good
candidate), and try to ease the collaboration needed to achieve the l10n
goals.

> > Translation-related bugs should be the responsibility of the
> > translation teams (and should be forwarded to them).
> 
>   While translations reside outside my package, the bugs shall
>  be reassigned (or closed), not forwarded. When the translation is in
>  my package, the bug shall be forwarded, and perhaps I'll use local
>  patches to correct the issue. 

That's an interesting point. I asked for a translation pseudo package, so
that developpers can reassign bug repports about translations to somewhere
where translators can be made aware of the issue and work on it to help the
maintainer, but this request never leaded to any concret decision. :)


In my opinion, one of the problems here is that we have no infrastructure at
all to ease the l10n work, neither do we have any infrastructure to handle
properly the l10n bugs. I dream of something like the dbuild and
packages.qa.debian.org or qa.debian.org/developer.php for translators, but
there is still a very long road until there.

First step being to create a DT (debian translator) status, or renaming
Debian Developers to Debian Contributor, since the former name clearly do
not capture all the ways to contribute to Debian. You may think that it's a
dummy name problem, but the problem more complicated. 

In the past, I applyed to become DD with stating that I do not want to
maintain any package, only become translator. And most of the questions I
was asked was how to deal with bug repports against my packages, and how to
use lintian and yada to increase the quality of my packages...

[in the meanwhile, I begun helping to fix RC bugs, and repackaged doc-rfc to
solve the issues repported against it, for example, so those questions where
not that useless to that extend, but that's another story]


So, to summarize myself, if we would live in a perfect world, we would:
 1. Document the BCP concerning l10n, and repport as bug any maintainer or
translator not sticking to it (and only them)
 2. Think about improving (creating?) the l10n infrastructure within Debian.
Much more thinkings (=flamewar? ;) are needed for that.

Bye, Mt.

-- 
Computers are not intelligent. They only think they are.

Re: security in testing

[Matthias Urlichs]

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.)?

If that's so, cool, I'll have free time in two weeks or so.
I assume debian-admin are the correct people to talk further.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
-- 
If you are shooting under 80 you are neglecting your business;
over 80 you are neglecting your golf.
-- Walter Hagen

Re: security in testing

[Björn Stenberg]

Keegan Quinn wrote:
> Funny how myself and every admin I know have only very minor issues with
> running unstable.  What, pray tell, makes it such an 'obvious' non-option
> for end users?

How about constantly repeated statements to the effect?

"So you did not even look at the release announcement, and yet
you run unstable. You are luck that all that happened was that you had extra
copies of mail. People had had much worse happen to them running unstable,"
  -- Manoj Srivastava, linux.debian.bugs.dist, 1999-07-02

"Newbies are constantly told "don't run unstable" by all clued users.  The
ones that persist are either very dumb, and fail. Or very intelligent, and
succeed after mastering the learning curve."
  -- Stephen R. Gore, debian-devel 2000-06-05

"Don't run unstable - it's normal that unstable sometimes breaks."
  -- Adrian Bunk, muc.lists.debian.user, 2001-02-16

"The real moral: if you don't have a good chance of figuring out what's
wrong on your own, and fixing, backing out of, or jury-rigging around it
without outside help... don't run unstable."
  -- Craig Dickson, muc.lists.debian.user, 2002-11-14

"there are risks associated with running unstable, if you're not willing
or not able to deal with those risks then DON'T RUN UNSTABLE."
  -- Craig Sanders, debian-devel 2002-12-13

The list can be made much longer, but I think you get the idea. End users are
discouraged from running unstable, and for good reasons.

> I do like the sound of this, but saying it has a place and actually making
> it happen are very different things.  There seems to be a lot of the former,
> and little of the latter

That tired old argument doesn't bite on me since I have already volunteered to
set up a testing-i386 release. :-)

-- 
Björn

Re: security in testing

[Matthias Urlichs]

Hi, Stephen Frost wrote:

> honestly, if you care enough about what other people think to not take
> any action on your own chances are pretty good whatever you did wouldn't
> get very far anyway.

My approach is somewhat different. I freely admit that I'm fairly new to
Debian and probably have some misconceptions about how Things Are Done.
(That wouldn't be the first time...)

So I'd rather ask first than to step on somebody's toes.

Besides, somebody might have a better idea how to do that. They should
have a chance to speak up _before_ I do all the work. ;-)

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
-- 
"The trouble with having an open mind, of course, is that people
 will insist on coming along and trying to put things in it."
 [Terry Pratchett, "Diggers"]

Re: security in testing

[Matthias Urlichs]

Hi, Chris Leishman wrote:

>> - If the build is successful, it's available for apt-getting from
>> testing-updates; otherwise the maintainer gets a helpful ;-) email.
> 
> I'm just curious why the updates couldn't just go straight into testing 
> itself.  It's not as if the testing distribution is frozen in any way - 
> and that would deal with the problem of people not getting updates for 
> s.d.o.
> 
The current unstable->testing process might work for testing-updates too --
I haven't thought that far. The main problem I see with this approach is
that testing might get out-of-sync with unstable.

Something to think about for the next step, anyway.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
-- 
I'm CONTROLLED by the CIA!!  EVERYONE is controlled by the CIA!!
-- Zippy the Pinhead

mailcap next step

[mcINEK]

Hello!

I was wondering how to improve mailcap system to become useful.
First step was to able mc use mailcap. Now, I want to make nautilus to
use mailcap. And I have a few questions.

1. Where nautilus (gnome2?) keeps info about mime types?
2. (more complicated) Does run-mailcap differs x and non x applications?
Could be posible run ie. links in mc and galeon in nautilus by the same
run-mailcap command?

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

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

[Sven Luther]

On Thu, May 15, 2003 at 01:13:19PM +1000, Anthony Towns wrote:
> On Wed, May 14, 2003 at 07:12:15PM -0400, Joey Hess wrote:
> > Take the harden package, or create something similar: a package that
> > conflicts with all versions of packages with known security holes.
> 
> Why not just /fix/ the holes? Is uploading a package with a well known
> patch _really_ that hard?

Because the resulting package will be built on unstable and may have
dependency problems that will stop it from entering testing for long
times (month ?). sure you can argue that we should then fix the
dependent packages, but this may take time, more time than what is
reasonable for a security update anyway.

The fact is, we don't have a security architecture, or even autobuilders
for testing, and thus fixing the bug is no problem, but getting it in
testing is, and even with an override from the RM this could cause
problem.

A propper solution would be to have an additional build structure, where
you could upload to testing-proposed-updates, or something such, and where
the autobuilder would build these packages in a testing environment, and
which will follow the exact same rules for migration as the
unstable->testing one, except that all dependencies should be always
fullfilled, leaving only architecture rebuild problems.

Sure this is not bullet proof, and maybe it should be monitored to make
sure someone doesn't misuse this to get things in testing, but it would
enable the package maintainers to do RC and security bug fixing in
testing without being held back by this or that library/build-tool
package that just got a new version which will stop anything built with
it to enter testing.

If this works well, it could be possible to extend this for the next
release to have a dual build system, one for library/build-tool stuff,
and the other for the rest of the packages. But then, this is a
discussion for another time.

Friendly,

Sven Luther

Re: Questions regarding utf-8

[Andreas Metzler]

Bob Hilliard <[EMAIL PROTECTED]> wrote:
> Thanks to all who replied to my recent question on this subject.
> Andreas Metzler <[EMAIL PROTECTED]> wrote:
>> With glibc I'd use
>> iconv --from=SRC-ENCODING --to=DST-ENCODING//TRANSLIT
>> if it is acceptable to change the length of strings. This will replace
>> e.g. the Euro-Symbol with "EUR".

> Without //TRANSLIT, iconv fails if DST-ENCODING is US or ASCII,
> but with //TRANSLIT, all characters that aren't included in ASCII are
> rendered as `?'.

I was not aware of that, but you are right.

> This useful, but not as useful as the conversions
> performed by recode.

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

> Where is `//TRANSLIT' documented?

In former times it was documented in the manpages but afaict it is not
documented anywhere anymore (I checked the respective manpages and the
contents of glibc-doc 2.2.5-11.2)

*prompt* zgrep -li translit `dlocate -L glibc-doc`
/usr/share/doc/glibc-doc/ChangeLog.11.gz
/usr/share/doc/glibc-doc/ChangeLog.12.gz
/usr/share/doc/glibc-doc/ChangeLog.10.gz
cu andreas
-- 
Hey, da ist ein Ballonautomat auf der Toilette!
Unofficial _Debian-packages_ of latest unstable _tin_
http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/

Re: A strawman proposal: "testing-x86"

[Sven Luther]

On Wed, May 14, 2003 at 10:51:42AM -0500, Manoj Srivastava wrote:
> On Wed, 14 May 2003 09:14:20 -0400, Theodore Ts'o <[EMAIL PROTECTED]> said: 
> 
> > If that's the case, then maybe the testing distribution has outlived
> > its usefulness.  But if people feel otherwise, then it would make
> > sense to think of ways in which testing might be able to be more
> > true to its original goals --- which is to expand the number of
> > people who can test out packages before a stable release.  If that's
> > the case, then for a giving platform:
> 
>   Hmm. I always thought that testing was a tool for release
>  management, and a replacement of the freeze mechanism. If so, it is
>  really only ready for extensive use and testing close to a stable
>  release -- when the RM calls uponm and lets lose the hrdes on testing
>  to sniff out undiscovered bugs. Untl then, it is a no mans land where
>  the ravening winds howl and moan.

That is what it really is, but not what we advertized when testing was
first introduced. We told back then that the aim of testing was dual,
and in addition to what you said, it would also be a place for people
who want to run things newer than stable to go without getting the
breakage of unstable they may not handle. By saying that, we encouraged
people to use testing instead of unstable, none of which have security
updates, and gave the impression that testing was more
stable/secure/preferable/whatever to unstable, which is contrary to what
you are saying.

I don't say that what you say is wrong, just that people are not aware
of it, because we did tell them differently back then.

Friendly,

Sven Luther

Re: security in testing

[Sven Luther]

On Thu, May 15, 2003 at 03:19:02PM +1000, Anthony Towns wrote:
> On Wed, May 14, 2003 at 11:59:49PM -0400, Matt Zimmerman wrote:
> > There are no mirrors of security.debian.org, and have not been for as long
> > as I have been aware.  See the security team FAQ.
> 
> deb http://mirror.pacific.net.au/debian-security/ stable/updates main
> 
> > Do you honestly think would be a good idea to use testing-security this way
> > on a continual basis?  
> 
> Yes, I do. I think we should release DSA's for security problems in
> testing, too.
> 
> > Such an endeavor would not seem to require any of the
> > facilities which make foo-security different from foo{,-proposed-updates}.
> 
> The same applies to stable: the key differences are immediacy,
> announcements and control, all of which are equally valuable for testing
> as stable. In any event, testing-proposed-updates exists and works at
> present, the only thing missing is people reliably uploading to it, and
> evaluating whether uploads work well enough to be included in testing
> or not. All the technical issues have already been addressed.

Are the testing-proposed-updates autobuilt on all arches ? I got the impression
that this was not the case, but i may be wrong.

Friendly,

Sven Luther

Re: security in testing

[Sven Luther]

On Wed, May 14, 2003 at 05:37:51PM -0700, Keegan Quinn wrote:
> On Wednesday 14 May 2003 04:53 pm, Björn Stenberg wrote:
> > What's worse, saying testing is not for public use means there is _no_
> > place to get updates, since unstable is obviously not an option for end
> > users. This makes Debian the only linux distribution I know of that
> > completely eschews software updates between frozen releases (except for
> > security fixes).
> 
> Hmm.  Funny how myself and every admin I know have only very minor issues 
> with 
> running unstable.  What, pray tell, makes it such an 'obvious' non-option for 
> end users?  Well-timed unstable snapshots are often more 'stable' than 
> commercial Linux releases, in my limited experience.

Because we give them the impression that testing is more adapted to them
than unstable.

Friendly,

Sven Luther

Re: Do not touch l10n files

[Denis Barbier]

On Thu, May 15, 2003 at 01:10:35AM +0100, Colin Watson wrote:
> On Thu, May 15, 2003 at 12:22:27AM +0200, Denis Barbier wrote:
> > On Wed, May 14, 2003 at 02:02:27PM -0500, Manoj Srivastava wrote:
> > >   This is a far cry from ``Do not touch l10n files''. 
> > 
> > Hey, this was the subject, I had to get it short.  My original post
> > contained the following paragraph:
> >   So I would like to ask developers not to edit l10n files (templates,
> >   PO files, etc) themselves; if you believe that something goes wrong,
> >   notify the translator or his translation team (or any other trusted
> >   person).  If you disagree, think twice before applying your changes,  
> >   you are certainly wrong.
> 
> Oh, rubbish. I won't claim to be able to deal with l10n files in every
> language under the sun, but I'm familiar enough with several European
> languages to be able to correct minor errors, make cautious small
> updates when something has changed globally, and so on.

And you could also have mentioned that you pointed out an error I made
when merging two translations.  Of course I am grateful to developers
who take care of l10n, but from my experience I was corrected once and
my files were corrupted many times.

Again my complaint goes against people who do not fully understand
foreign languages and believe that they know what they should look
like, see e.g.
  
http://lists.debian.org/debian-l10n-french/2003/debian-l10n-french-200305/msg00161.html

> As long as I'm careful, I believe that this improves the state of
> l10n. Sure, I'll usually remember to tell the translator about it too,
> but I have many things to do, and translations are often the last
> thing I do before making a release in order to make sure that they're
> as up to date as possible so I'm often in a hurry.
>
> Perhaps this is just a translation problem itself, but "you are
> certainly wrong" has an incredibly arrogant tone.

As said above this assumption is based on my own statistics, others
may differ.

Denis

partimage on powerpc

[Sergio Rua]

Hello,

> # partimage 
> 
> Error: volume hedaer size != 512 (520)
>   This version has been compiled with an uncompatible version of
>   gcc.

I received this bug report (#193391) today and I cannot reproduce it on
i386. Looks like a problem on powerpc. I'm not very familiar with
powerpc. Could somebody help me?

Thanks.

Note: I'm not subscribed to the list at this moment. Please Cc me.

--
Kind regards,

Sergio Rua

Re: Do not touch l10n files

[Denis Barbier]

On Wed, May 14, 2003 at 07:17:50PM +0200, Javier Fernández-Sanguino Peña wrote:
[...]
> > As a package developer I hold veto powers over anything
> >  shipped in my package, since it is my signature that goes with it,
> >  and I am responsible for all bugs. 
> 
> You do hold upstream responsible for the bugs in their software right? From
> my point of view, same should go for translators. Translation-related bugs
> should be the responsibility of the translation teams (and should be
> forwarded to them). Some other projects (like GNOME [1] or KDE [2])
> understand this and the translation (l10n work) translators get access to
> the source code CVS and whatever they do gets merged with the programs if
> it "works" (syntactically correct, compiles, etc..)

This is fully right.  Some Debian projects work this way (I know debian-www,
debian-installer and debian-doc, are there others?) and it eases everyone's
life.

Denis

possible problem for debian was [NTP considered basic] misc@openbsd.org

[Uwe A. P. Wuerdinger]

Hi,
I just catched this conversation on the misc OpenBSD mailinglist.
Does this in any way afflict debian?
greets Uwe
--
X-Tec GmbH
Institute for Computer and Network Security
WWW : http://www.x-tec.de/
IPv6: http://www.ipv6.x-tec.de/
--- Begin Message ---
> I'd like to encourage the OpenBSD developers to move
> NTP support into the "base" package.

We cannot.  The code is not free enough.



--- End Message ---
--- Begin Message ---
>  Theo de Raadt Wednesday, May 14, 2003 10:14 AM
>  > I'd like to encourage the OpenBSD developers to move
>  > NTP support into the "base" package.
>
>  We cannot.  The code is not free enough.

I'm curious if you could be more specific here, because at first glance
it seems the NTP copyright is at even less restrictive than the berkeley
copyright (i.e. it does not require mention in advertising as bsd's
does).  I copy the entirety below.
Rick
***
* *
* Copyright (c) David L. Mills 1992-2003  *
* *
* Permission to use, copy, modify, and distribute this software and   *
* its documentation for any purpose and without fee is hereby *
* granted, provided that the above copyright notice appears in all*
* copies and that both the copyright notice and this permission   *
* notice appear in supporting documentation, and that the name*
* University of Delaware not be used in advertising or publicity  *
* pertaining to distribution of the software without specific,*
* written prior permission. The University of Delaware makes no   *
* representations about the suitability this software for any *
* purpose. It is provided "as is" without express or implied  *
* warranty.   *
* *
***



--- End Message ---
--- Begin Message ---
* Permission to use, copy, modify, and distribute this software and   *
* its documentation for any purpose and without fee is hereby *
* granted, provided that the above copyright notice appears in all*

this is a misplaced modifier that has a 2nd meaning -- that it cannot
be sold.  i've talked to lawyers.  it's a real problem, and they say
they won't fix it.

sorry.



--- End Message ---

Bug#193399: ITP: latex209 -- macro files of LaTeX 2.09 25-mar-1992 version

[TSUCHIYA Masatoshi]

Package: wnpp
Severity: wishlist

* Package name: latex209
  Version : 25.mar.1992
  Upstream Author : Leslie Lamport
* URL or Web page : 
ftp://ctan.tug.org/tex-archive/obsolete/macros/latex209/distribs/latex209.tar.gz
* License : Public Domain
  Description : Commands and macro files of LaTeX 2.09 25-mar-1992 version

Where are translated man pages packaged?

[Denis Barbier]

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?

Denis

Re: Debian MIA check

[Amaya]

There must be some mistake :-m

Joey Hess dijo:
> Tor Slettnes
>   mindi
>   mondo
>   smail
>   xcdroast
>   yard
>   zmailer
>   zmailer-ssl

These are Héctor García's and he is not MIA at all. 
What happened?


-- 
  I would rather starve than lose your acceptance
 .''`.My eyes will always show my empty soul
: :' :- Boy Sets Fire
`. `' Proudly running Debian GNU/Linux (Sid 2.4.20 Ext3)
  `-   www.amayita.com  www.malapecora.com  www.chicasduras.com

RE：回复： 合作

[张]

对不起 打扰之处请见谅

本公司是一家专业致力于网络服务的专业性公司，提供高质空间，优质服务，为您建设网站提供必不可少的各类型空间及域名；

域名80元 送20个次级域名

标准主机空间 100M网站空间+100M邮局空间 
可支持asp/php/cgi/access 可运行论坛程序200元/年

不论您是单位企业还是个人，我们都将竭诚为您提供贴身个性化的网络支持服务

同时本公司还推出网站建设服务，最低999元就可让您拥有包含：空间+域名+邮局+网页 
的完整网站

同时为只需简单介绍各类信息的个人及企业提供网站简化模式――网络名片
最低只需100元/年

如果您在单位里不是负责这方面事情的人，在表达歉意的同时，也希望您顺手转发给贵单位负责这方面事情的负责人，您一个举手之劳，就会让单位觉得您在关心单位，为单位着想，何乐而不为呢！

非常感谢!

现广招天下有志网络创业的朋友 加入吧  轻松上网做代理  
一同为打造中国企业的网络品牌而努力有意与我联系 等候您的加入

联系人：张先生  QQ 9651016  [EMAIL PROTECTED]

Re: mailcap next step

[Wouter Verhelst]

On Thu, May 15, 2003 at 10:04:39AM +0200, mcINEK wrote:
> Hello!
> 
> I was wondering how to improve mailcap system to become useful.
> First step was to able mc use mailcap. Now, I want to make nautilus to
> use mailcap. And I have a few questions.
> 
> 1. Where nautilus (gnome2?) keeps info about mime types?
> 2. (more complicated) Does run-mailcap differs x and non x applications?

If you already parsed mailcap into mc's configuration, you should've
seen this (picking out a random one):

application/vnd.sun.xml.draw; openoffice '%s'; edit=openoffice '%s'; test=test 
"$DISPLAY" != "" ; description="OpenOffice.org 1.0 Drawing"; nametemplate=%.sxd

Take extra care to the 'test' parameter.

> Could be posible run ie. links in mc and galeon in nautilus by the same
> run-mailcap command?

If you can create a test to accomplish that, sure.

-- 
Debian GNU/Linux -- http://www.debian.org
Nederlandstalige Linux-documentatie -- http://nl.linux.org

"An expert can usually spot the difference between a fake charge and a
full one, but there are plenty of dead experts." 
  -- National Geographic Channel, in a documentary about large African beasts.

Re: Where are translated man pages packaged?

[Wouter Verhelst]

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?

As the new maintainer of manpages-nl...

I'd say, and so did Joost Van Baal, the previous maintainer, that
translated manpages belong with the original. This way, it's easier to
keep track of changes, manpages don't take up space documenting
programs or -dev library packages that aren't installed, and, most
importantly: people that don't know about the manpages-xx package will
get the translated manpages if they set their $LANG, since it's with the
'normal' package. People that set their $LANG will probably prefer that
anyway.

With regard to those conflicting pages: that's just temporary; once
manpages have been incorporated in the right package, one can easily
remove the manpage from the manpages-xx package, and upload a new
package.

-- 
Debian GNU/Linux -- http://www.debian.org
Nederlandstalige Linux-documentatie -- http://nl.linux.org

"An expert can usually spot the difference between a fake charge and a
full one, but there are plenty of dead experts." 
  -- National Geographic Channel, in a documentary about large African beasts.


pgpEdp39Uc05y.pgp
Description: PGP signature

Re: Where are translated man pages packaged?

[Colin Watson]

On Thu, May 15, 2003 at 11:24:14AM +0200, Denis Barbier wrote:
> 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 think it is proper to include translated man pages with original man
pages, and to use apt-localepurge (now) or dpkg exclusions (when they're
implemented) if people are worried about space. My gut feeling is that
the manpages-LL packages should cover roughly the same topics as the
English manpages package.

My experience has been that refusing to include translated man pages
makes it much harder to tell when the man pages have got out of date.
However, I'm not sure how to go about persuading reluctant developers of
this.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: mailcap next step

[mcINEK]

W liście z czw, 15-05-2003, godz. 11:54, Wouter Verhelst pisze: 
> If you already parsed mailcap into mc's configuration, you should've
> seen this (picking out a random one):
> 
> application/vnd.sun.xml.draw; openoffice '%s'; edit=openoffice '%s'; 
> test=test "$DISPLAY" != "" ; description="OpenOffice.org 1.0 Drawing"; 
> nametemplate=%.sxd
> 
> Take extra care to the 'test' parameter.
> 
> > Could be posible run ie. links in mc and galeon in nautilus by the same
> > run-mailcap command?
> 
> If you can create a test to accomplish that, sure.

Yes, I've seen it. BUT...

This is galeon entry in /etc/mailcap:

text/html; /usr/bin/galeon '%s'; description=HTML Text; test=test -n
"$DISPLAY"; nametemplate=%s.html

Even if I change it, to run links if not $DISPLAY it would be bad
solution. User can't choose which browser use. In addition, it's another
record from the same file.

text/html; /usr/bin/mozilla '%s'; description=HTML Text; test=test -n
"$DISPLAY";  nametemplate=%s.html

We see a conflict. It doesn't matter how many browser user installed,
always will be run galeon (it's above so it's first - am I right?).

The best solution, I think, is that galeon (mozilla, etc) shouldn't
provide a /etc/mailcap record, but just alternatives. And then in
/etc/mailcap should be (just ONE) record, like (sorry, I don't know
syntax)

text/html; if DISPLAY run x-www-browser else run www-browser

that's all. When user want to change one of browsers just use
update-alternatives --config.

This mechanism may be applied not only for browser, but image-viewers
etc.

What do you think about that? (I hope you understanded me ;)

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

Re: Debian MIA check

[Amaya]

Sorry, my terminal was too small to check all the replies in the thread,
including Hector's himself 0:-)

Glad to see this clarified.

-- 
  I would rather starve than lose your acceptance
 .''`.My eyes will always show my empty soul
: :' :- Boy Sets Fire
`. `' Proudly running Debian GNU/Linux (Sid 2.4.20 Ext3)
  `-   www.amayita.com  www.malapecora.com  www.chicasduras.com

Re: DebConf 3 for New Maintainers

[Andreas Schuldei]

* Colin Watson ([EMAIL PROTECTED]) [030514 15:42]:
> organization, though. Tollef, do you know if there'll be wireless base
> stations around or, will we be doing ad-hoc mode?)

yes, there will be wlan. not user about the mode of operation.

and there will also be some stationary pcs there.

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

[Anthony Towns]

On Thu, May 15, 2003 at 08:09:48AM +0200, Sven Luther wrote:
> On Thu, May 15, 2003 at 01:13:19PM +1000, Anthony Towns wrote:
> > On Wed, May 14, 2003 at 07:12:15PM -0400, Joey Hess wrote:
> > > Take the harden package, or create something similar: a package that
> > > conflicts with all versions of packages with known security holes.
> > Why not just /fix/ the holes? Is uploading a package with a well known
> > patch _really_ that hard?
> The fact is, we don't have a security architecture, or even autobuilders
> for testing, 

Uh, actually, we have both these things. We've had them for almost a year
now, although they haven't been used.

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


pgpiCQsHLXZ2A.pgp
Description: PGP signature

Re: fwctl and ipchains-perl - any takers?

[Martin Michlmayr]

* Bernd Eckenfels <[EMAIL PROTECTED]> [2003-04-27 18:12]:
> Martin, while maintaining the archive,  contacted me, because he wanted to
> remove the orpahaned ipchains-perl module. He noticed, that my fwctl is
> depending on it.
> 
> So here is my question, is anybody willing to take over fwctl/ipchains-perl
> and add iptables support, or has anybody some ideas what to do?

No one seems to have responded, or?

-- 
Martin Michlmayr
[EMAIL PROTECTED]

Re: Do not touch l10n files

[Thom May]

Ok, I've been trying to stay out of this as much as possible, since I think
Denis' original post:
> >   So I would like to ask developers not to edit l10n files (templates,
> >   PO files, etc) themselves; if you believe that something goes wrong,
> >   notify the translator or his translation team (or any other trusted
> >   person).  If you disagree, think twice before applying your changes,  
> >   you are certainly wrong.

is exactly what we did. 
I'm sorry that an aparently simple request has descended into mud-slinging
and general hostility, but it certainly wasn't our intention.
I'm also quite upset to see off hand insults - I've never claimed to "know
what a foreign language should look like", what we've asked is for a
rational explanation as to why when we removed a single character, (a "3" as
it happens) the layout of the french translation changed dramatically and to
a form that the maintainers do not view as ideal.
I hesitate to comment on the "ownership" of the translation, but would like
to point out that the package maintainer is the one whose name is "on" the
package; thus I think in the final analysis it's the maintainers call. If
the maintainer has concerns about the translation, then the *least* the
translation team could do is respond in a civil manner with the reasons
behind the decision and work *with* the maintainer to resolve the problem. 
Cheers
-Thom

(sorry if the threading is broken - i'm replying based on the web archive.
Please cc me on responses, too)

Re: mailcap next step

[Wouter Verhelst]

On Thu, May 15, 2003 at 12:11:03PM +0200, mcINEK wrote:
> W li?cie z czw, 15-05-2003, godz. 11:54, Wouter Verhelst pisze: 
> > If you already parsed mailcap into mc's configuration, you should've
> > seen this (picking out a random one):
> > 
> > application/vnd.sun.xml.draw; openoffice '%s'; edit=openoffice '%s'; 
> > test=test "$DISPLAY" != "" ; description="OpenOffice.org 1.0 Drawing"; 
> > nametemplate=%.sxd
> > 
> > Take extra care to the 'test' parameter.
> > 
> > > Could be posible run ie. links in mc and galeon in nautilus by the same
> > > run-mailcap command?
> > 
> > If you can create a test to accomplish that, sure.
> 
> Yes, I've seen it. BUT...
> 
> This is galeon entry in /etc/mailcap:
> 
> text/html; /usr/bin/galeon '%s'; description=HTML Text; test=test -n
> "$DISPLAY"; nametemplate=%s.html
> 
> Even if I change it, to run links if not $DISPLAY it would be bad
> solution. User can't choose which browser use. In addition, it's another
> record from the same file.
> 
> text/html; /usr/bin/mozilla '%s'; description=HTML Text; test=test -n
> "$DISPLAY";  nametemplate=%s.html
> 
> We see a conflict. It doesn't matter how many browser user installed,
> always will be run galeon (it's above so it's first - am I right?).

Yes.

> The best solution, I think, is that galeon (mozilla, etc) shouldn't
> provide a /etc/mailcap record, but just alternatives. And then in
> /etc/mailcap should be (just ONE) record, like (sorry, I don't know
> syntax)
> 
> text/html; if DISPLAY run x-www-browser else run www-browser
> 
> that's all. When user want to change one of browsers just use
> update-alternatives --config.

Here's your error: if you do that, it's not the user who can change his
browser, but the system administrator. Those two are not always the
same.

However, there's a better way. From mailcap(5):

FILES
   $HOME/.mailcap:/etc/mailcap:/usr/share/etc/mailcap:/usr/local/etc/mail-
  cap -- default path for mailcap files.

In other words: you can create a ~/.mailcap, with the same syntax as
/etc/mailcap, and copy your preferred entries from /etc/mailcap there --
or create new ones.

-- 
Debian GNU/Linux -- http://www.debian.org
Nederlandstalige Linux-documentatie -- http://nl.linux.org

"An expert can usually spot the difference between a fake charge and a
full one, but there are plenty of dead experts." 
  -- National Geographic Channel, in a documentary about large African beasts.


pgpSpNlEjOEBj.pgp
Description: PGP signature

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

[Sven Luther]

On Thu, May 15, 2003 at 09:03:06PM +1000, Anthony Towns wrote:
> On Thu, May 15, 2003 at 08:09:48AM +0200, Sven Luther wrote:
> > On Thu, May 15, 2003 at 01:13:19PM +1000, Anthony Towns wrote:
> > > On Wed, May 14, 2003 at 07:12:15PM -0400, Joey Hess wrote:
> > > > Take the harden package, or create something similar: a package that
> > > > conflicts with all versions of packages with known security holes.
> > > Why not just /fix/ the holes? Is uploading a package with a well known
> > > patch _really_ that hard?
> > The fact is, we don't have a security architecture, or even autobuilders
> > for testing, 
> 
> Uh, actually, we have both these things. We've had them for almost a year
> now, although they haven't been used.

So, the infrastructure is there, but not turned on ?

What about woody-proposed-updates ? Are the autobuilders available for
it ? I rememeber having to hand build some of the packages for it
sometime ago.

Friendly,

Sven Luther

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

[David Nusinow]

On Thu, May 15, 2003 at 09:03:06PM +1000, Anthony Towns wrote:
> On Thu, May 15, 2003 at 08:09:48AM +0200, Sven Luther wrote:
> > On Thu, May 15, 2003 at 01:13:19PM +1000, Anthony Towns wrote:
> > > On Wed, May 14, 2003 at 07:12:15PM -0400, Joey Hess wrote:
> > > > Take the harden package, or create something similar: a package that
> > > > conflicts with all versions of packages with known security holes.
> > > Why not just /fix/ the holes? Is uploading a package with a well known
> > > patch _really_ that hard?
> > The fact is, we don't have a security architecture, or even autobuilders
> > for testing, 
> 
> Uh, actually, we have both these things. We've had them for almost a year
> now, although they haven't been used.

They're testing-proposed-updates is documented in Section 5.5.2 of the
Developer's Reference, but it says that they should only be used in
case of a freeze.

"You should not upload to testing-proposed-updates when you can update
your packages through unstable." is also a prominent quote from that
section. Nothing specifying security updates, although it does discuss
that these updates require manual intervention. Maybe a specific
reference to managing security updates to testing in this section would
be helpful? It'd finally put it down somewhere where people can point
to, and maybe cut a few of these debates a little shorter.

 - David Nusinow (going to file a wishlist bug for this)

Re: mailcap next step

[mcINEK]

W liście z czw, 15-05-2003, godz. 13:00, Wouter Verhelst pisze: 
> Here's your error: if you do that, it's not the user who can change his
> browser, but the system administrator. Those two are not always the
> same.

But, does it eliminate my soluton? As you wrote later, user always can
change /etc/mailcap. I didn't wonder how it would be on multi-users
machines but I don't think it could be 'worse'.

On the contrary, for one-user machines it will be very good and fast
solution to make their programs runing apps like they want. The don't
need to wonder what app will be starded, just that what they choose by
update-alternatives. And also, this apps may be different for xwindows
or console. 

What is more, everything will be doing automatically.
I think it can be interesting.

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

Re: mailcap next step

[Wouter Verhelst]

On Thu, May 15, 2003 at 01:24:42PM +0200, mcINEK wrote:
> W li?cie z czw, 15-05-2003, godz. 13:00, Wouter Verhelst pisze: 
> > Here's your error: if you do that, it's not the user who can change his
> > browser, but the system administrator. Those two are not always the
> > same.
> 
> But, does it eliminate my soluton? As you wrote later, user always can
> change /etc/mailcap. I didn't wonder how it would be on multi-users
> machines but I don't think it could be 'worse'.
> 
> On the contrary, for one-user machines it will be very good and fast
> solution to make their programs runing apps like they want. The don't
> need to wonder what app will be starded, just that what they choose by
> update-alternatives. And also, this apps may be different for xwindows
> or console. 

I really think it would be a bad idea to go the alternatives road here.
If you must, you could write a front-end that parses /etc/mailcap, and
for a given MIME type, allows a user to pick the application of his/her
choice; the front-end could then write that to ~/.mailcap.

> What is more, everything will be doing automatically.
> I think it can be interesting.

We disagree, then.

-- 
Debian GNU/Linux -- http://www.debian.org
Nederlandstalige Linux-documentatie -- http://nl.linux.org

"An expert can usually spot the difference between a fake charge and a
full one, but there are plenty of dead experts." 
  -- National Geographic Channel, in a documentary about large African beasts.


pgpFd1QMfATGB.pgp
Description: PGP signature

Re: mailcap next step

[mcINEK]

W liście z czw, 15-05-2003, godz. 13:30, Wouter Verhelst pisze: 
> I really think it would be a bad idea to go the alternatives road here.

But why? Could you give me any reasons? I've said why yes, so you tell
why not ;]

> If you must, you could write a front-end that parses /etc/mailcap, and
> for a given MIME type, allows a user to pick the application of his/her
> choice; the front-end could then write that to ~/.mailcap.

It won't work, because the aren't any 'standards'. I don't have idea how
make x/non-x choice from mailcap. I REALLY think alternatives could be
good.

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

Re: mailcap next step

[Michał Politowski]

On Thu, 15 May 2003 12:11:03 +0200, mcINEK wrote:
[...]
> We see a conflict. It doesn't matter how many browser user installed,
> always will be run galeon (it's above so it's first - am I right?).
> 
> The best solution, I think, is that galeon (mozilla, etc) shouldn't
> provide a /etc/mailcap record, but just alternatives. And then in
> /etc/mailcap should be (just ONE) record, like (sorry, I don't know
> syntax)

Assuming you think one setting for all users is enough,
you already have a solution: man mailcap.order

Otherwise ~/.mailcap is the way to go, as has been already suggested.

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

Re: mailcap next step

[Wouter Verhelst]

On Thu, May 15, 2003 at 01:35:22PM +0200, mcINEK wrote:
> W li?cie z czw, 15-05-2003, godz. 13:30, Wouter Verhelst pisze: 
> > I really think it would be a bad idea to go the alternatives road here.
> 
> But why? Could you give me any reasons? I've said why yes, so you tell
> why not ;]

Alternatives are meant for something else. I could want to run a small
HTML viewer when I get a HTML-encoded mail, but could want to run
mozilla or konqueror as my 'default' webbrowser, when an other
application tries to run one. Yes, you could create /another/
alternative for /every/ MIME type in your mailcap, but that would bloat
the alternatives system.

Also, going the alternatives way would result in a *lot* of work (you'd
have to remove all other mailcap entries, since they'd conflict with
your work), and would not really be an improvement, since only the
sysadmin could change preferences, and users would still be where they
are today: having to copy lines from /etc/mailcap to ~/.mailcap.

Worse; now they can copy lines; then, they'd have to edit them to be
useful, else they'd /still/ run the sysadmin's preferences.

Alternatives and mailcap are two different worlds. Please keep them
separated.

> > If you must, you could write a front-end that parses /etc/mailcap, and
> > for a given MIME type, allows a user to pick the application of his/her
> > choice; the front-end could then write that to ~/.mailcap.
> 
> It won't work, because the aren't any 'standards'. I don't have idea how
> make x/non-x choice from mailcap. I REALLY think alternatives could be
> good.

It's done in there, all over the place! There's a 'test' option, which
is meant to use a line conditionally; it's commonly used to test whether
$DISPLAY is set, which is *exactly* what you need.

-- 
Debian GNU/Linux -- http://www.debian.org
Nederlandstalige Linux-documentatie -- http://nl.linux.org

"An expert can usually spot the difference between a fake charge and a
full one, but there are plenty of dead experts." 
  -- National Geographic Channel, in a documentary about large African beasts.


pgpEjFHyNsreI.pgp
Description: PGP signature

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

[Anthony Towns]

On Thu, May 15, 2003 at 11:13:59AM +0200, Sven Luther wrote:
> On Thu, May 15, 2003 at 09:03:06PM +1000, Anthony Towns wrote:
> > On Thu, May 15, 2003 at 08:09:48AM +0200, Sven Luther wrote:
> > > On Thu, May 15, 2003 at 01:13:19PM +1000, Anthony Towns wrote:
> > > > On Wed, May 14, 2003 at 07:12:15PM -0400, Joey Hess wrote:
> > > > > Take the harden package, or create something similar: a package that
> > > > > conflicts with all versions of packages with known security holes.
> > > > Why not just /fix/ the holes? Is uploading a package with a well known
> > > > patch _really_ that hard?
> > > The fact is, we don't have a security architecture, or even autobuilders
> > > for testing, 
> > Uh, actually, we have both these things. We've had them for almost a year
> > now, although they haven't been used.
> So, the infrastructure is there, but not turned on ?

No, it's sitting there, waiting for someone to use it. After a year's
neglect it might need some metaphorical oil on its hinges and some
dusting, but it really is there. I'm not just saying this for rhetorical
value.

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


pgpRc4xTImQn5.pgp
Description: PGP signature

Re: mailcap next step

[mcINEK]

W liście z czw, 15-05-2003, godz. 13:49, Wouter Verhelst pisze: 
> Alternatives and mailcap are two different worlds. Please keep them
> separated.

OK, so leave alternatives.

> > It won't work, because the aren't any 'standards'. I don't have idea how
> > make x/non-x choice from mailcap. I REALLY think alternatives could be
> > good.
> 
> It's done in there, all over the place! There's a 'test' option, which
> is meant to use a line conditionally; it's commonly used to test whether
> $DISPLAY is set, which is *exactly* what you need.

No, it doesn't. There can be more tjan one line describing the same mime
type. And what then? Solving this problem will be sorting content of
/usr/lib/mime/packages by appropiate types, such as:

/usr/lib/mime/packages/text-html/mozilla,
 content (example): x,/usr/bin/mozilla
/usr/lib/mime/packages/text-html/links
 content: text,/usr/bin/mozilla

And on that base update-mime can generate /etc/mailcap. Of course if
they'd be more browsers it only can choose one, but in the present time
it's the same.

If there'd be a types tree like that making front-end will make sense,
otherwise no. User'd choose a program from that directory structure.

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

Re: Do not touch l10n files

[Denis Barbier]

On Thu, May 15, 2003 at 12:04:14PM +0100, Thom May wrote:
> Ok, I've been trying to stay out of this as much as possible, since I think
> Denis' original post:
> > >   So I would like to ask developers not to edit l10n files (templates,
> > >   PO files, etc) themselves; if you believe that something goes wrong,
> > >   notify the translator or his translation team (or any other trusted
> > >   person).  If you disagree, think twice before applying your changes,  
> > >   you are certainly wrong.
> 
> is exactly what we did. 
> I'm sorry that an aparently simple request has descended into mud-slinging
> and general hostility, but it certainly wasn't our intention.
> I'm also quite upset to see off hand insults - I've never claimed to "know
> what a foreign language should look like", what we've asked is for a
> rational explanation as to why when we removed a single character, (a "3" as
> it happens) the layout of the french translation changed dramatically and to
> a form that the maintainers do not view as ideal.

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.

Denis

Re: Do not touch l10n files

[Thom May]

* Denis Barbier ([EMAIL PROTECTED]) wrote :
> On Thu, May 15, 2003 at 12:04:14PM +0100, Thom May wrote:
> > I'm also quite upset to see off hand insults - I've never claimed to "know
> > what a foreign language should look like", what we've asked is for a
> > rational explanation as to why when we removed a single character, (a "3" as
> > it happens) the layout of the french translation changed dramatically and to
> > a form that the maintainers do not view as ideal.
> 
> 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. 
-Thom

Re: mailcap next step

[Wouter Verhelst]

On Thu, May 15, 2003 at 02:13:32PM +0200, mcINEK wrote:
> > > It won't work, because the aren't any 'standards'. I don't have idea how
> > > make x/non-x choice from mailcap. I REALLY think alternatives could be
> > > good.
> > 
> > It's done in there, all over the place! There's a 'test' option, which
> > is meant to use a line conditionally; it's commonly used to test whether
> > $DISPLAY is set, which is *exactly* what you need.
> 
> No, it doesn't. There can be more tjan one line describing the same mime
> type. And what then?

The first one will be used.

> Solving this problem will be sorting content of
> /usr/lib/mime/packages by appropiate types, such as:
> 
> /usr/lib/mime/packages/text-html/mozilla,
>  content (example): x,/usr/bin/mozilla
> /usr/lib/mime/packages/text-html/links
>  content: text,/usr/bin/mozilla
> 
> And on that base update-mime can generate /etc/mailcap. Of course if
> they'd be more browsers it only can choose one, but in the present time
> it's the same.

You don't need to do that. Leave /etc/mailcap the way it is; system-wide
preferences wrt default applications suck anyway :-)

> If there'd be a types tree like that making front-end will make sense,
> otherwise no. User'd choose a program from that directory structure.

Uh. You can create such a tree in-memory, no? Parsing the file is not
*that* hard.

-- 
Debian GNU/Linux -- http://www.debian.org
Nederlandstalige Linux-documentatie -- http://nl.linux.org

"An expert can usually spot the difference between a fake charge and a
full one, but there are plenty of dead experts." 
  -- National Geographic Channel, in a documentary about large African beasts.


pgpcIpVqYnnIK.pgp
Description: PGP signature

Re: DebConf 3 for New Maintainers

[Tollef Fog Heen]

* Colin Watson 

| (I'm not involved with the organization, though. Tollef, do you know
| if there'll be wireless base stations around or, will we be doing
| ad-hoc mode?)

The area is covered with WLANs already, but we'll have a few switches
for people who don't have wireless.

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

Re: mailcap next step

[mcINEK]

W liście z czw, 15-05-2003, godz. 14:30, Wouter Verhelst pisze: 
> Uh. You can create such a tree in-memory, no? Parsing the file is not
> *that* hard.

Of course, I can. But I don't understand why don't improve BAD
mechanism. If sth is bad and doesn't pass our requests we should change
it. Is update-mime a 'holy cow'? 

Nevertheless if it's just my opinion I won't argue and don't touch
anything.

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

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

[Sven Luther]

On Thu, May 15, 2003 at 10:26:35PM +1000, Anthony Towns wrote:
> On Thu, May 15, 2003 at 11:13:59AM +0200, Sven Luther wrote:
> > On Thu, May 15, 2003 at 09:03:06PM +1000, Anthony Towns wrote:
> > > On Thu, May 15, 2003 at 08:09:48AM +0200, Sven Luther wrote:
> > > > On Thu, May 15, 2003 at 01:13:19PM +1000, Anthony Towns wrote:
> > > > > On Wed, May 14, 2003 at 07:12:15PM -0400, Joey Hess wrote:
> > > > > > Take the harden package, or create something similar: a package that
> > > > > > conflicts with all versions of packages with known security holes.
> > > > > Why not just /fix/ the holes? Is uploading a package with a well known
> > > > > patch _really_ that hard?
> > > > The fact is, we don't have a security architecture, or even autobuilders
> > > > for testing, 
> > > Uh, actually, we have both these things. We've had them for almost a year
> > > now, although they haven't been used.
> > So, the infrastructure is there, but not turned on ?
> 
> No, it's sitting there, waiting for someone to use it. After a year's
> neglect it might need some metaphorical oil on its hinges and some
> dusting, but it really is there. I'm not just saying this for rhetorical
> value.

Ok, i had the impression this was not the case, but then, maybe i
misremembered or something such.

So, the right and easy solution for the samba security bug is to upload
the source package to testing-proposed-update, and it will get rebuild
on all testing supported architectures in time.

What happens then, will it stay apart, or get transitioned into testing
when all arches have rebuilt ?

I suppose a testing pbuilder or something such would be needed for the
initial upload and not pure source, since we don't have a arch: all
autobuilder.

What about version numbers ? Should the same version number as the
unstable package be used, or only the minor debian version number be
bumped, with maybe an additional testing or security part ?

Also, should we use this only for security fixes, or also for other RC
bugs or even non RC bugs ? Where is the limit and if there is one, who
will enforce it ?

Friendly,

Sven Luther

Re: possible problem for debian was [NTP considered basic] misc@openbsd.org

[Sam Hocevar]

On Thu, May 15, 2003, Uwe A. P. Wuerdinger wrote:

> I just catched this conversation on the misc OpenBSD mailinglist.
> Does this in any way afflict debian?

   This subject has already been discussed forever on debian-legal. The
general consensus is that "without fee" does not mean "you may redistri-
bute as long as it is without a fee" but rather "the rights are granted
to you without having to pay a fee to the author".

   See for instance:

> http://lists.debian.org/debian-legal/1999/debian-legal-199908/msg00049.html

   Or search the -legal archives for "without a fee".

Regards,
-- 
Sam.

Re: security in testing

[Stephen Frost]

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

> If that's so, cool, I'll have free time in two weeks or so.

Great, glad to hear it.

> I assume debian-admin are the correct people to talk further.

If you need space to host the site I may be willing to help you out once
you've shown that you're producing something.

Stephen


pgpSwH7ACxNQ3.pgp
Description: PGP signature

Re: security in testing

[Mark Brown]

On Wed, May 14, 2003 at 05:37:51PM -0700, Keegan Quinn wrote:

> Hmm.  Funny how myself and every admin I know have only very minor issues 
> with 
> running unstable.  What, pray tell, makes it such an 'obvious' non-option for 
> end users?  Well-timed unstable snapshots are often more 'stable' than 
> commercial Linux releases, in my limited experience.

As you say, mostly unstable is just fine but...

> Sure, every now and then a badly-broken package makes it in for a day or two. 
>  
> This seems to be far less harmful than the massive headache that treating 
> 'testing' as a usable release seems to be causing.

...when things go wrong they can *really* go wrong.  I've had my system
rendered unbootable by unstable packages before and while I've not had a
problem coping with things yet I'd not J. Random User to cope.  

You'll also find that applications can be completely broken for extended
periods of time in unstable which is a tad inconvenient if you're trying
to use them (for example, gnucash has been segfaulting on startup on
PowerPC for a while now).  Again, I can cope but I don't think it's a
good idea to suggest people run it without giving the matter some
thought.

One of the things that people were hoping for with testing when it was
first introduced was that the crippling bugs where thing just don't work
would get caught before things hit testing.  If testing were actually
getting prompt updates most of the time that'd make it a slightly less
current alternative to unstable with much reduced risk of something
overly nasty happening.

Most of the problems that have come up (like the big holdups) weren't as
widely discussed.

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

Re: Where are translated man pages packaged?

[Mark Brown]

On Thu, May 15, 2003 at 11:09:08AM +0100, Colin Watson wrote:

> I think it is proper to include translated man pages with original man
> pages, and to use apt-localepurge (now) or dpkg exclusions (when they're
> implemented) if people are worried about space. My gut feeling is that

I believe this was the consensus in the last big translation discussion
- where possible translations should be integrated with the package
being translated.  This has been happening again with Debconf templates,
for example.

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

Re: DebConf 3 for New Maintainers

[Josselin Mouette]

Le jeu 15/05/2003 à 14:49, Tollef Fog Heen a écrit :
> The area is covered with WLANs already, but we'll have a few switches
> for people who don't have wireless.

Side question: will there be a few machines for people who can't bring a
laptop ?
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: PGP signature

Re: mailcap next step

[Wouter Verhelst]

On Thu, May 15, 2003 at 02:46:34PM +0200, mcINEK wrote:
> W li?cie z czw, 15-05-2003, godz. 14:30, Wouter Verhelst pisze: 
> > Uh. You can create such a tree in-memory, no? Parsing the file is not
> > *that* hard.
> 
> Of course, I can. But I don't understand why don't improve BAD
> mechanism.

I fail to see why it would be bad. It's not perfect, but that's far from
the same thing. Moreover, I think your ideas would make things worse,
rather than better.

> If sth is bad and doesn't pass our requests we should change
> it. Is update-mime a 'holy cow'? 

Certainly not.

-- 
Debian GNU/Linux -- http://www.debian.org
Nederlandstalige Linux-documentatie -- http://nl.linux.org

"An expert can usually spot the difference between a fake charge and a
full one, but there are plenty of dead experts." 
  -- National Geographic Channel, in a documentary about large African beasts.


pgpM5KEp94Ay2.pgp
Description: PGP signature

Re: security in testing

[Sven Luther]

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.

You again forget that debian is not x86 only, or do you expect Matthias
to have access to machines of all the supported arches ?

Friendly,

Sven Luther

Re: security in testing

[Matt Zimmerman]

On Thu, May 15, 2003, someone calling themselves "LapTop006" wrote:

> On Wed, May 14, 2003 at 11:59:49PM -0400, Matt Zimmerman arranged a set of 
> bits into the following:
> > There are no mirrors of security.debian.org, and have not been for as long
> > as I have been aware.  See the security team FAQ.
> FALSE.

Official mirrors.  I should have known someone would jump on this.

-- 
 - mdz

Re: mailcap next step

[mcINEK]

W liście z czw, 15-05-2003, godz. 15:23, Wouter Verhelst pisze: 
> I fail to see why it would be bad. It's not perfect, but that's far from
> the same thing. Moreover, I think your ideas would make things worse,
> rather than better.

It's not perfect. Importand bugs are for me:

* doesn't allow to choose what program use
* it skip more than one application for one type

Our task is to think, when it would be good, and what we're gonna do.

Of course, we can leave it as it is now, but then we won't go further in
making Debian better and more and more useful.

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

Re: Do not touch l10n files

[Steve Langasek]

On Thu, May 15, 2003 at 07:32:55AM +0200, Christian Couder wrote:

> The situation is very different from the situation maintainer face with 
> upstream code because in fact apt should be able to install l10n packages 
> related to a given program package when it installs the program package. 

> So if l10n materials are currently integrated into program packages, instead 
> of being in separate l10n packages, it's because of this lack in apt. It's 
> not because the program package maintainer should also be responsible for 
> l10n stuff related to the program, like he is responsible for the code in the 
> program.

I'm sure the apt maintainers will be happy to know you think the
inclusion of debconf template translations in packages indicates a
deficiency in their code.

-- 
Steve Langasek
postmodern programmer


pgpBkZdv65Y5I.pgp
Description: PGP signature

Re: "Bug marked as done" messages to-be-MIMEified?

[Josip Rodin]

On Wed, May 14, 2003 at 11:27:07PM +0100, Darren Salt wrote:
> >> so maybe it was actually only filed in my brain (which has no web
> >> interface) ...
> 
> > We need a bug system for developer's brains.
> 
> Agreed...
> 
>   $ mail [EMAIL PROTECTED] -s "Misplacement of apostrophes"
>   Package: doogie
>   
>   "developers' brains", surely.
>   Cc:
>   $
> 
> ;-)

But... maybe the developer in question really has >1 brain.
(Incidentally, that might explain a few other things as well :)

-- 
 2. That which causes joy or happiness.

Re: Do not touch l10n files

[Denis Barbier]

On Thu, May 15, 2003 at 01:25:56PM +0100, Thom May wrote:
> * Denis Barbier ([EMAIL PROTECTED]) wrote :
> > On Thu, May 15, 2003 at 12:04:14PM +0100, Thom May wrote:
> > > I'm also quite upset to see off hand insults - I've never claimed to "know
> > > what a foreign language should look like", what we've asked is for a
> > > rational explanation as to why when we removed a single character, (a "3" 
> > > as
> > > it happens) the layout of the french translation changed dramatically and 
> > > to
> > > a form that the maintainers do not view as ideal.
> > 
> > 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.

Denis

Re: mailcap next step

[Wouter Verhelst]

On Thu, May 15, 2003 at 03:35:33PM +0200, mcINEK wrote:
> W li?cie z czw, 15-05-2003, godz. 15:23, Wouter Verhelst pisze: 
> > I fail to see why it would be bad. It's not perfect, but that's far from
> > the same thing. Moreover, I think your ideas would make things worse,
> > rather than better.
> 
> It's not perfect. Importand bugs are for me:
> 
> * doesn't allow to choose what program use

Yes it does. Create a ~/.mailcap with the application of your choice for
a given MIME-type at the top.

My suggestion of a front-end was to create some application that would
help $USER to manage ~/.mailcap.

> * it skip more than one application for one type

That's actually the same thing as above, unless I don't understand what
you mean.

> Our task is to think, when it would be good, and what we're gonna do.
> 
> Of course, we can leave it as it is now, but then we won't go further in
> making Debian better and more and more useful.

Please point me to where I said we should leave things as they are.

-- 
Debian GNU/Linux -- http://www.debian.org
Nederlandstalige Linux-documentatie -- http://nl.linux.org

"An expert can usually spot the difference between a fake charge and a
full one, but there are plenty of dead experts." 
  -- National Geographic Channel, in a documentary about large African beasts.


pgpLZhMBTb0Bp.pgp
Description: PGP signature

Re: security in testing

[Matt Zimmerman]

On Thu, May 15, 2003 at 03:19:02PM +1000, Anthony Towns wrote:

> On Wed, May 14, 2003 at 11:59:49PM -0400, Matt Zimmerman wrote:
> > Do you honestly think would be a good idea to use testing-security this way
> > on a continual basis?  
> 
> Yes, I do. I think we should release DSA's for security problems in
> testing, too.

There's that "we" again.  Why not unstable, too?  Round it out to a nice,
even four distributions to simultaneously support, and 40 or so
distribution*architectures.  As if it doesn't take enough time already.

> > Such an endeavor would not seem to require any of the facilities which
> > make foo-security different from foo{,-proposed-updates}.
> 
> The same applies to stable: the key differences are immediacy,
> announcements and control, all of which are equally valuable for testing
> as stable.

No, it is not at all the same as stable.  The problem that is being
discussed in this thread is the presence of known, publicized security holes
in testing.

> In any event, testing-proposed-updates exists and works at
> present, the only thing missing is people reliably uploading to it, and
> evaluating whether uploads work well enough to be included in testing
> or not. All the technical issues have already been addressed.

In that case, I invite any maintainer with a security fix for their package
in 'testing' to upload it to testing for testing-proposed-updates.  Problem
solved.  Are you the one who will be responsible for reviewing the packages?

> Except that there can be no testing users while we don't provide security
> updates. Using testing on a multi-user machine, or one that provides any
> network services on a machine connected to the network is not something
> anyone can recommend in good conscience, and that rules out almost
> everything Debian's actually good at.

This does not trouble me in the least.

> > Sidestepping the process to provide this kind of "timely" security update
> > for "unreleased" software, on the other hand, doesn't seem particularly
> > valuable to me.
> 
> What, precisely, is unreleased about it?

  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).
  
 A release is either a {major release}, a {revision}, or a
 {bugfix}.
  
 Pre-release versions may be called {alpha test}, or {beta
 test} versions.
  
 See {change management}.

"released", as in "no longer under development", as in "not changing on a
DAILY BASIS" (as testing does), and so actually supportable.  testing is a
moving target.

-- 
 - mdz

Re: security in testing

[Theodore Ts'o]

On Wed, May 14, 2003 at 05:53:50PM -0400, Don Armstrong wrote:
> Manoj's answer, while witty, is closer to the mark than you may
> realize.
> 
> Debian will always be for whoever the people contributing to Debian
> are willing/want it to be for. No more, no less.

Um, when we all agreed to be Debian Developers, we agreed to the
following from the social contract:

* Our Priorities are Our Users and Free Software

We will be guided by the needs of our users and the free-software
community. We will place their interests first in our priorities. We
will support the needs of our users for operation in many different
kinds of computing environment.


So what does that mean?  If the we define "our users" as ourselves,
then the social contract reduces to "we will place our interests first
in our priorities", and that doesn't sound so good, does it?  :-)

If our users include those who want something that is less stale than
"stable", but where they don't want to deal with having to stich
together their system after an update to perl or lilo leaves their
system completely unusable, how do we meet their needs?  There are
certainly disagreements at the tactical level (we could solve this
problem by applying pressure to people to not upload broken packages
to unstable; we could solve the problem by fixing enough RC bugs that
packages flow into testing much more reliably and quickly; we could
solve the problem by recruiting people to upload into
"testing-security").  

But the first question before we discuss tactics is whether or not we
"should" do it.  Does the fact that we've accept the Social Contract
put any kind of moral claim on what we as an organization do?  If the
question to that question is yes, then individual developers will need
to search their souls and decide whether or not this means they are
feeling called to put in the time to fix an RC bug, or work to NMU or
otherwise clear a blocked, critical package, or contribute to security
or testing-security, or do something else to further the goal.

> I'd argue that the converse is more important. [Unless most developers
> do everything they do for purely altruistic reasons. I know I do what
> I do for selfish reasons first.]

That may be true, but the ideals articulated in the Social Contract
aspire to something a higher more than that.

- Ted

Re: mailcap next step

[mcINEK]

W liście z czw, 15-05-2003, godz. 15:42, Wouter Verhelst pisze: 
> Yes it does. Create a ~/.mailcap with the application of your choice for
> a given MIME-type at the top.
> 
> My suggestion of a front-end was to create some application that would
> help $USER to manage ~/.mailcap.

I think it's good idea too. It could be done even now. 
But that what I'm trying to say, is we shouldn't use long ways. Solution
you suggested is a 'little bubble' which you wan't stick to exist
mechanism. I will work, however, it's just a bypass. It's a fine
frontend to ulgy mechanism, which indeed doesn't work (if you have to
parse generated file, it doesn't work).

The clue is to think about efficient mechanism, which works globally and
can be adapted by user in *simple* ways (not by a giant/slow script
which parse conf file).

> Please point me to where I said we should leave things as they are.
You didn't say that, but you want use *minimal* solution, which aren't
always good.

PS1. Windows are done this way. MS created took w2k and sticked
more,more and more programmic 'bubbles' and created one big shit :)

PS2. Maybe I wrote my definition of 'bubble':
'Bubble' is a short code, which you can put(stick) to original code
without changing anything.

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

Re: security in testing

[Theodore Ts'o]

On Wed, May 14, 2003 at 05:37:51PM -0700, Keegan Quinn wrote:
> 
> Sure, every now and then a badly-broken package makes it in for a
> day or two.  This seems to be far less harmful than the massive
> headache that treating 'testing' as a usable release seems to be
> causing.

Something that would make unstable much more useful is if dpkg had a
reliable "undo" capability.  It's unpleasant when you update a
broken package, and large number of packages break, and you can't
necessarily find a copy of the older, non-broken version of the
package to re-install.  If you're not a developer, you don't have
access to archives, so your choice is to either go back to the stable
or testing version of the package, or try to find a mirror that still
has the n-1 release of the unstable package.

So simply making it easier for people to get a previous version of a
package when the current version in unstable is borked would probably
take away many of the reasons why people might want to use "testing"
instead of "unstable".

The harder disaster scenario to deal with is when after an update,
your system is so totally borked that recovering requires use of a
rescue disk, or other manual interventions.  As I mentioned, there was
a time some years ago, when I was first getting involved with Debian,
where broken perl uploads (which broke dpkg so it was painful to back
out of such a situation), and broken lilo uploads.  Both were screwing
up my system to such an extent that I was spending far more time than
I liked doing manual wizardry just to get my system back to a
recoverable state.

At the time, when I whined and complained, the response I was given
from my Debian mentors at time was to use the testing distribution
instead.  (I was also told, jokingly, that the all of the LILO
breakages was because the lilo maintainer was really a secret GRUB
supporter, and was breaking LILO just to get people to convert over to
GRUB, and that I should just get with the program and switch over to
GRUB.  :-)  

But now people are saying that using testing is a bad thing.  Part of
the problem is that different people have very different ideas about
exactly what testing is useful for.

>Hmm.  Funny how myself and every admin I know have only very minor issues with
>running unstable.  What, pray tell, makes it such an 'obvious' non-option for
>end users?  Well-timed unstable snapshots are often more 'stable' than
>commercial Linux releases, in my limited experience.

Clearly you didn't use unstable when I did several years ago, or
you're just remembering those days through rose-colored glasses.  :-)

But seriously, if the right answer is that people just shouldn't be
using testing, we should say that, in big letters.  And then perhaps
there ought to be tools that make it easier for someone to get their
system functioning again after an unstable package update leaves them
screwed over.  Ideally, that should never happen, but hey, people make
mistakes.  We just need a way to make sure that such mistakes are
recoverable.

- Ted

Proposal of removing MOSIX stuff

[Francesco P. Lovergine]

Hi all

Currently we have both OpenMosix and Mosix in our main archive.

See http://openmosix.sourceforge.net/ and http://www.mosix.com/ 
for background information. Both software provide the same
features for clustering (but IMHO OpenMosix is more actively developed
and has more prospectives, e.g. ia64 support).

Historically, OpenMosix has been a fork of Mosix, when Prof. Barak
changed license into a proprietary one :-/
The OM project leader Moshe Bar was the co-author of Mosix.

Currently, Mosix should be removed from main, because 
http://www.mosix.com/LICENSE denies redistribution of modifications 
without author's permission. OpenMosix is fully GPL, instead.

I'm simply proposing the complete removing of mosix from archive, if none
could adopt it and manage properly its moving in non-free.

Ciao

-- 
Francesco P. Lovergine


pgpi5sg3X0F01.pgp
Description: PGP signature

Re: DebConf 3 for New Maintainers

[Andreas Tille]

On 14 May 2003, Joachim Breitner wrote:

> > I would recommend this.  When I was in Bordeaux in 2000 without my own 
> > Laptop
> > it was much less fun. :-(  The educational effect decreases drastically!
> Well, that sould definatly interesting. I just hope I manage to get a
> laptop 'till then. Or would you think a zaurus with debian is sufficient
> :-) (Actually, why not: One might allow me to ssh on his machine so I
> can actually compile stuff *g*)
Honestly:  I do not know Zaurus except that I had my hands on it for a
minute (which was quite impressive).  But I think it could be a very
intersting test to install and use Debian on it.

> I think the problem is that for most bugs you need either very deep
> knowledge of the program or of some language or (mostly) both.
Definitely not.  Just have a deeper look and you will find that many bugs
are easy to fix.  (If you would know my limited skills and compare it
with the bugs I fixed in Bordeaux you would believe me. ;-)) )

> So if you
> can't do "much" C, a lot of bug fixing is out of your reach. Well, maybe
> I can find some bugs I can fix with perl or shell etc until then.
You will find those und probably others which are easy to fix.

Kind regards

   Andreas.

Re: security in testing

[Matthias Urlichs]

Hi,

Sven Luther wrote:
> You again forget that debian is not x86 only, or do you expect Matthias
> to have access to machines of all the supported arches ?
>
Right.

Besides, I don't want to do this on my own, I want to do this as part of 
Debian. I don't yet know enough about the setup of testing-proposed-updates 
and the whole build structure in general to see clearly what needs to be done 
to automate the process, or indeed whether the people responsible for it 
would be OK with enhancing that along the lines of my proposal; my impression 
is that t-p-o is mostly processed manually at the moment, like 
stable-proposed-updates is, and it's under-used (t-p-o/main has a whopping 
TWO source packages). That may be a chicken-and-egg problem.

In other words, I don't want to reinvent any wheels -- I want to help make the 
existing wheels run more smoothly.

Anyway, I plan to start learning how to do this by setting up an autobuilder 
for m68k (the machine which replaces my broken IIfx (you have no idea how 
corrosive a run-down-and-leaking battery is -- I'll put some pics on my 
homepage later today :-/ ) should arrive tomorrow.) and proceed from there.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
-- 
I've been WRITING to SOPHIA LOREN every 45 MINUTES since JANUARY 1ST!!
-- Zippy the Pinhead

Re: mailcap next step

[Wouter Verhelst]

On Thu, May 15, 2003 at 04:05:28PM +0200, mcINEK wrote:
> > Please point me to where I said we should leave things as they are.
> You didn't say that, but you want use *minimal* solution, which aren't
> always good.
> 
> PS1. Windows are done this way. MS created took w2k and sticked
> more,more and more programmic 'bubbles' and created one big shit :)

What's that supposed to mean? Doing that does have its advantages, too
(such as "you don't have to re-integrate everything with the new
system").

Granted, pushing that to extremes will end you up with an unworkable
system with hundreds of incompatible API's. That's not what this does.

-- 
Debian GNU/Linux -- http://www.debian.org
Nederlandstalige Linux-documentatie -- http://nl.linux.org

"An expert can usually spot the difference between a fake charge and a
full one, but there are plenty of dead experts." 
  -- National Geographic Channel, in a documentary about large African beasts.


pgpMuVzjax1Di.pgp
Description: PGP signature

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

[Paul Slootman]

On Tue 13 May 2003, James Troup wrote:

> Of the 191 pings were sent out:
>  o 34 people's ping bounced[1].
>  o 28 people replied asking to be retired.
>  o 29 people replied with various different responses.
>  o 10 people replied who were active.
>  o 90 people didn't reply within the 2 month deadline[2].

I've not had any response to a message I sent Michael-John Turner
<[EMAIL PROTECTED]> a couple of months ago, asking him about his status.
However, I don't see him on James' list.  According to echelon he's not
been seen since 10 Feb 2002.

It's about bugs in mrtg that caused me to look for him.
It may be necessary to hijack his packages if he is in fact MIA.
A search on Google doesn't show any recent activity either.


Paul Slootman


pgpBUYYSNPpCQ.pgp
Description: PGP signature

Re: "Bug marked as done" messages to-be-MIMEified?

[David Z Maze]

"Adrian 'Dagurashibanipal' von Bidder" <[EMAIL PROTECTED]> writes:

> Q: is content-disposition handled properly, especially for
> messag/rfc822 type attachments? (Or if not, are message attachments
> displayed inline by default?)

Gnus: yes (since 5.8.0, the first MIME-aware version)

> (Yes, I've stopped caring about users of a certain other widespread MUA, as 
> you've probably guessed anyway when you notice me using PGP/MIME to sign 
> messages...)

I'm not actually clear how much this is a good thing; at some level,
we do want people reporting bugs.  (Though at the same level, we also
want them reading and using debian-user, and "get a real MUA" is a
common sentiment there.)  But yeah, its unnamed inbound MIME handling
is pretty terrible; content-disposition is completely ignored, so if I
attach a file to mail, the recipient sees my .signature as a separate
attachment...

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

Re: mailcap next step

[mcINEK]

W liście z czw, 15-05-2003, godz. 16:38, Wouter Verhelst pisze: 
> What's that supposed to mean? Doing that does have its advantages, too
> (such as "you don't have to re-integrate everything with the new
> system").
> 
> Granted, pushing that to extremes will end you up with an unworkable
> system with hundreds of incompatible API's. That's not what this does.

But only if this API is good. If API is wrong and don't have support for
new useful options, should be changed or improved. API is a solid,
stable base for building additions, however, it must be simple and
thought over. Besides, it's not such a basic feature, which requires
change system core.

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

Re: security in testing

[Steve Langasek]

On Wed, May 14, 2003 at 10:19:08AM -0400, Matt Zimmerman wrote:

> > >If unstable has a fix for the bug, then it is a waste of time to work on
> > >testing because users can just upgrade.  If unstable does not have a fix
> > >for the bug, then it is still a waste of time because unstable needs to
> > >be fixed anyway, and that package will replace the one in testing once it
> > >has survived in unstable.

> > I don't disagree.  Thats why I didn't suggest a policy of creating 
> > patched versions for testing.  Instead, simply remove and inform the 
> > user that it's a problem.

> What value does this provide for the users?  It may incite them to complain
> to the maintainer, who might (if they are active) try to get a fixed version
> into testing, and disrupt their work, but this is not a good way to motivate
> maintainers.  As for the user's security, this is like amputating a limb as
> treatment for a fracture.

*My* primary goals are to protect Debian's (and the maintainer's)
reputation, and to fulfill my civic duty to not increase the number of
compromised machines in the world being used to clog the Internet.  The
needs of people trying to use testing for production use contrary to
all admonitions are secondary, IMHO; and by the sound of things, making
testing less suitable for the casual user in the process might be a
benefit, not a detriment.

 > - I believe that people who are willing to run the testing distribution 
> > are happy to assume the risk of problematic packages and broken 
> > packaging - and are in usually happy to contribute bug reports where 
> > appropriate.
> > - I also believe that the majority of these people are NOT willing to 
> > accept this risk when it comes to known security issues.  They're happy 
> > to deal with packages not working right, or the inability to install 
> > something for various reasons, but they're not willing to have their 
> > box compromised.

> The people I know who run testing do it on single-user or trusted-users-only
> machines, on rather tightly controlled local networks.  They do not notice
> or care about security problems for the most part.

> We can both hypothesize about testing users in general, but our guesses
> don't carry much weight unless they are backed up by real data from a
> significant number of real users.

I am not hypothesizing.  I am getting reports from and about people who
are running the version of Samba from testing, whose machines have been
compromized because they were exposed to the Internet.  Given that the
only users of testing I know are those I hear about through such
reports, if I *were* to extrapolate, my conclusions about testing's
userbase would be quite different from yours; but the real point is that
there is a non-zero number of users who have been compromised by the
Samba vulnerability, that I cannot turn around to and say "you should
have known better" in good conscience because we as a community are
sending mixed signals to our users about testing's suitability.  It
makes no difference to me personally *which* way we clarify the matter,
but I think the lack of consensus is a serious problem.

> There are already very clear statements about this.

> http://www.debian.org/releases/

> testing
> The ``testing'' distribution contains packages that haven't been
> accepted into a ``stable'' release yet, but they are in the queue for that.
> The main advantage of using this distribution is that it has more recent
> versions of software, and the main disadvantage is that it's not completely
> tested and <<>>.

Out of curiosity, what *un*official support does testing receive from
the Debian security team?  This statement on the website does a rather
weak job of capturing the true state of affairs, IMHO, if maintainers
offering to prepare testing security uploads for their packages are
being turned away.

-- 
Steve Langasek
postmodern programmer


pgpQn9hzlDoJx.pgp
Description: PGP signature

Re: partimage on powerpc

[Matthias Urlichs]

Hi, Sergio Rua wrote:

>> # partimage 
>> 
>> Error: volume hedaer size != 512 (520)
>>  This version has been compiled with an uncompatible version of
>>  gcc.
> 
I'll check. Sergio: Which source package from where, please?

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
-- 
Why won't sharks eat lawyers?   Professional courtesy.

Re: security in testing

[Steve Langasek]

On Thu, May 15, 2003 at 10:08:03AM -0400, Theodore Ts'o wrote:
> On Wed, May 14, 2003 at 05:37:51PM -0700, Keegan Quinn wrote:
> > 
> > Sure, every now and then a badly-broken package makes it in for a
> > day or two.  This seems to be far less harmful than the massive
> > headache that treating 'testing' as a usable release seems to be
> > causing.

> Something that would make unstable much more useful is if dpkg had a
> reliable "undo" capability.  It's unpleasant when you update a
> broken package, and large number of packages break, and you can't
> necessarily find a copy of the older, non-broken version of the
> package to re-install.  If you're not a developer, you don't have
> access to archives, so your choice is to either go back to the stable
> or testing version of the package, or try to find a mirror that still
> has the n-1 release of the unstable package.

It seems to me that this is one of the reasons for the existence of
snapshot.debian.net.

Cheers,
-- 
Steve Langasek
postmodern programmer


pgpuRA6QkNQKc.pgp
Description: PGP signature

Re: security in testing

[Wouter Verhelst]

On Thu, May 15, 2003 at 10:08:03AM -0400, Theodore Ts'o wrote:
> On Wed, May 14, 2003 at 05:37:51PM -0700, Keegan Quinn wrote:
> > 
> > Sure, every now and then a badly-broken package makes it in for a
> > day or two.  This seems to be far less harmful than the massive
> > headache that treating 'testing' as a usable release seems to be
> > causing.
> 
> Something that would make unstable much more useful is if dpkg had a
> reliable "undo" capability.  It's unpleasant when you update a
> broken package, and large number of packages break, and you can't
> necessarily find a copy of the older, non-broken version of the
> package to re-install.  If you're not a developer, you don't have
> access to archives,

sure you do.

snapshot.debian.net

-- 
Debian GNU/Linux -- http://www.debian.org
Nederlandstalige Linux-documentatie -- http://nl.linux.org

"An expert can usually spot the difference between a fake charge and a
full one, but there are plenty of dead experts." 
  -- National Geographic Channel, in a documentary about large African beasts.


pgpLP3Up2zlQR.pgp
Description: PGP signature

Re: security in testing

[Mark Brown]

On Thu, May 15, 2003 at 10:08:03AM -0400, Theodore Ts'o wrote:

> package to re-install.  If you're not a developer, you don't have
> access to archives, so your choice is to either go back to the stable
> or testing version of the package, or try to find a mirror that still

With the pool system the old package will kick around on the mirrors for
a while.  Knowing that they're there is a bit of a trick, mind you.

> But now people are saying that using testing is a bad thing.  Part of
> the problem is that different people have very different ideas about
> exactly what testing is useful for.

I think some of this is that ideas have changed over time - when testing
was new there were high hopes for what it could achieve that haven't
been delivered on.

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

Re: mailcap next step

[Wouter Verhelst]

On Thu, May 15, 2003 at 04:53:32PM +0200, mcINEK wrote:
> W li?cie z czw, 15-05-2003, godz. 16:38, Wouter Verhelst pisze: 
> > What's that supposed to mean? Doing that does have its advantages, too
> > (such as "you don't have to re-integrate everything with the new
> > system").
> > 
> > Granted, pushing that to extremes will end you up with an unworkable
> > system with hundreds of incompatible API's. That's not what this does.
> 
> But only if this API is good.

It is, IMHO.

> If API is wrong and don't have support for
> new useful options,

Who says it doesn't?

> should be changed or improved. API is a solid,
> stable base for building additions, however, it must be simple and
> thought over. Besides, it's not such a basic feature, which requires
> change system core.

No, but lots of applications use it.

-- 
Debian GNU/Linux -- http://www.debian.org
Nederlandstalige Linux-documentatie -- http://nl.linux.org

"An expert can usually spot the difference between a fake charge and a
full one, but there are plenty of dead experts." 
  -- National Geographic Channel, in a documentary about large African beasts.


pgph9f3pasBML.pgp
Description: PGP signature

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

[Graham Wilson]

On Thu, May 15, 2003 at 06:15:07PM +0900, TSUCHIYA Masatoshi wrote:
> Package: wnpp
> Severity: wishlist
> 
> * Package name: latex209
>   Version : 25.mar.1992
>   Upstream Author : Leslie Lamport
> * URL or Web page : 
> ftp://ctan.tug.org/tex-archive/obsolete/macros/latex209/distribs/latex209.tar.gz
> * License : Public Domain
>   Description : Commands and macro files of LaTeX 2.09 25-mar-1992 version

what is the purpose of package the old latex macros?

-- 
gram


pgpLoVL2HYXdo.pgp
Description: PGP signature

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

[Matthias Urlichs]

Hi, Sven Luther wrote:

> On Thu, May 15, 2003 at 10:26:35PM +1000, Anthony Towns wrote:
>> No, it's sitting there, waiting for someone to use it. After a year's
>> neglect it might need some metaphorical oil on its hinges and some
>> dusting, but it really is there. I'm not just saying this for
>> rhetorical value.
> 
That's great, However...

> [ list of questions / possible problems ]

My impression is that t-p-o is intended to be used like woody-p-o, i.e.
security fixes only, with a MNUish version number.

> So, the right and easy solution for the samba security bug is to upload
> the source package to testing-proposed-update, and it will get rebuild
> on all testing supported architectures in time.
> 
Is that automatic, or does somebody have to push a few buttons?

> What happens then, will it stay apart, or get transitioned into testing
> when all arches have rebuilt ?
> 
IMHO: The latter.

> Also, should we use this only for security fixes, or also for other RC
> bugs or even non RC bugs ? Where is the limit and if there is one, who
> will enforce it ?
> 
IMHO the automatic system should make sure that the version number of the
t-p-o package is between that of the current testing version and that of
the current unstable, to ensure that the package will eventually be
replaced with the one in unstable.

Also IMHO, a good rule-of-thumb is "security fix, OR it fixes an important
bug AND the regular update into testing is stalled".

The automatic system should make sure that testing itself doesn't get
hosed; it already does that job for unstable. I would like to propose one
modification, in that the resulting binary packages need to be able to get
from t-p-o to testing on their own, otherwise they're deleted.

Developers' laziness should make sure that the system isn't abused for
spurious pseudo-updates. ;-)

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
-- 
[End of diatribe.  We now return you to your regularly scheduled
programming...]
 -- Larry Wall in Configure from the perl distribution

Re: security in testing

[Matthias Urlichs]

Hi, Matt Zimmerman wrote:

> In that case, I invite any maintainer with a security fix for their package
> in 'testing' to upload it to testing for testing-proposed-updates.  Problem
> solved.  Are you the one who will be responsible for reviewing the
> packages?

testing, in the absence of a freeze, is a moving target and continuously
updated from unstable, without any kind of review. I fail to see why a t-p-o 
=> testing path, or even a separate-testing-updates solution as I've
originally proposed, would need a review, but I'm willing to be
enlightened.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
-- 
People never change, they only become more who they are.

Re: security in testing

[Stephen Frost]

* Sven Luther ([EMAIL PROTECTED]) wrote:
> 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.
> 
> You again forget that debian is not x86 only, or do you expect Matthias
> to have access to machines of all the supported arches ?

No, I don't, but I do expect that if he wants to do something then he'll
at least make an attempt at it and start with whatever he has the
resources for.  If that's x86 then that will cover most of our users
anyway.

Stephen


pgp1NGj4ML9qK.pgp
Description: PGP signature

Re: A strawman proposal: "testing-x86"

[Matthias Urlichs]

Hi, Sven Luther wrote:

> [...] and gave the impression that testing was more
> stable/secure/preferable/whatever to unstable [...]

That was my first impression too.

> I don't say that what you say is wrong, just that people are not aware
> of it, because we did tell them differently back then.

IMHO it's a bug and it should be fixed. Note: I'm not saying that
security.d.o should do the same job for testing they're already doing for
stable and stable-old -- that wouldn't make much sense, IMHO.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
-- 
 Windoze CEMeNT: Now with CrackGuard(TM)!  Never worry about
   unsightly cracks in Windoze CEMeNT again!  CrackGuard(TM) is
   so powerful that the entire thing will crumble before it will
   crack.  Order your $200 upgrade version today!

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

[Steve Langasek]

On Thu, May 15, 2003 at 04:22:30AM -0700, David Nusinow wrote:
> On Thu, May 15, 2003 at 09:03:06PM +1000, Anthony Towns wrote:
> > On Thu, May 15, 2003 at 08:09:48AM +0200, Sven Luther wrote:
> > > On Thu, May 15, 2003 at 01:13:19PM +1000, Anthony Towns wrote:
> > > > On Wed, May 14, 2003 at 07:12:15PM -0400, Joey Hess wrote:
> > > > > Take the harden package, or create something similar: a package that
> > > > > conflicts with all versions of packages with known security holes.
> > > > Why not just /fix/ the holes? Is uploading a package with a well known
> > > > patch _really_ that hard?
> > > The fact is, we don't have a security architecture, or even autobuilders
> > > for testing, 

> > Uh, actually, we have both these things. We've had them for almost a year
> > now, although they haven't been used.

> They're testing-proposed-updates is documented in Section 5.5.2 of the
> Developer's Reference, but it says that they should only be used in
> case of a freeze.

> "You should not upload to testing-proposed-updates when you can update
> your packages through unstable." is also a prominent quote from that
> section. Nothing specifying security updates, although it does discuss
> that these updates require manual intervention. Maybe a specific
> reference to managing security updates to testing in this section would
> be helpful? It'd finally put it down somewhere where people can point
> to, and maybe cut a few of these debates a little shorter.

An upload to testing-proposed-updates is not the same as an upload to
testing-security, AFAIK (different upload queue, different machinery).
But it was my understanding that both were in working order, they just
aren't used -- and no one in a position to do so seems enthusiastic
about taking on the work of vetting uploads to either queue.

-- 
Steve Langasek
postmodern programmer


pgphC5q5Nin27.pgp
Description: PGP signature

Re: security in testing

[Stephen Frost]

* Matthias Urlichs ([EMAIL PROTECTED]) wrote:
> Sven Luther wrote:
> > You again forget that debian is not x86 only, or do you expect Matthias
> > to have access to machines of all the supported arches ?
> >
> Right.

Wrong, as I pointed out in my other message.

> Besides, I don't want to do this on my own, I want to do this as part of 
> Debian. I don't yet know enough about the setup of testing-proposed-updates 

You were asking about 'the way things are done'; well, in general what
I see as 'the way things are done' are if you want it, do something
about it, whatever you can.  If it's a good idea other people will help
and eventually people will realize what a great thing it is and that it
should be part of Debian.  Asking Debian to give you everything you ask
for in hopes that you might do something just isn't the way it works.

> and the whole build structure in general to see clearly what needs to be done 
> to automate the process, or indeed whether the people responsible for it 
> would be OK with enhancing that along the lines of my proposal; my impression 
> is that t-p-o is mostly processed manually at the moment, like 
> stable-proposed-updates is, and it's under-used (t-p-o/main has a whopping 
> TWO source packages). That may be a chicken-and-egg problem.
> 
> In other words, I don't want to reinvent any wheels -- I want to help make 
> the 
> existing wheels run more smoothly.
> 
> Anyway, I plan to start learning how to do this by setting up an autobuilder 
> for m68k (the machine which replaces my broken IIfx (you have no idea how 
> corrosive a run-down-and-leaking battery is -- I'll put some pics on my 
> homepage later today :-/ ) should arrive tomorrow.) and proceed from there.

I encourage you to learn about the build structure and set up your own
autobuilder, etc, etc.  I'm sure if you're patient and persistant enough
people will answer questions you have about the system, or point you to
where you can go read about it yourself.  Asking for Debian to supply
you with accounts and access to whatever without having done anything
isn't the way to go though- show us you can do it and that you can
handle it and you've got the time, etc.  As I said, if it's good, and
people like it then a) users will use it, b) others will help, and
following that Debian folks will be much more willing to have you do it
in a official capacity instead of on the side.

Stephen


pgpji4oWmyiog.pgp
Description: PGP signature

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

[Martin Michlmayr]

* Paul Slootman <[EMAIL PROTECTED]> [2003-05-15 16:44]:
> It's about bugs in mrtg that caused me to look for him.
> It may be necessary to hijack his packages if he is in fact MIA.

mj:
2003-03-21: Contact
2003-03-22: NMU by schepler: wmmatrix
2003-03-23: willfix

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
free to NMU in the meantime.

-- 
Martin Michlmayr
[EMAIL PROTECTED]

Re: Where are translated man pages packaged?

[Denis Barbier]

On Thu, May 15, 2003 at 11:09:08AM +0100, Colin Watson wrote:
> On Thu, May 15, 2003 at 11:24:14AM +0200, Denis Barbier wrote:
> > 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 think it is proper to include translated man pages with original man
> pages, and to use apt-localepurge (now) or dpkg exclusions (when they're
> implemented) if people are worried about space. My gut feeling is that
> the manpages-LL packages should cover roughly the same topics as the
> English manpages package.

I fully agree.

> My experience has been that refusing to include translated man pages
> makes it much harder to tell when the man pages have got out of date.
> However, I'm not sure how to go about persuading reluctant developers of
> this.

I know what to do then: flame them here ;)

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?

Denis

Re: "Bug marked as done" messages to-be-MIMEified?

[Colin Watson]

On Thu, May 15, 2003 at 10:47:34AM -0400, David Z Maze wrote:
> "Adrian 'Dagurashibanipal' von Bidder" <[EMAIL PROTECTED]> writes:
> > (Yes, I've stopped caring about users of a certain other widespread MUA, as 
> > you've probably guessed anyway when you notice me using PGP/MIME to sign 
> > messages...)
> 
> I'm not actually clear how much this is a good thing; at some level,
> we do want people reporting bugs.

Let's not overstate the impact here. Changing the -done acks to include
messages using MIME won't make any difference to people reporting bugs;
it may at most involve one extra step for people who use poor MUAs, but
it's probably no different from the one extra step they need to take
when receiving PGP/MIME-signed mail. On the flip side, it will probably
be much easier to read some acks in reasonably MIME-capable MUAs,
particularly those which contained MIME attachments in the original
report and those which were written in a different character set from
the closing message.

I think on balance it would be worth it.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: security in testing

[Sven Luther]

On Thu, May 15, 2003 at 10:08:03AM -0400, Theodore Ts'o wrote:
> On Wed, May 14, 2003 at 05:37:51PM -0700, Keegan Quinn wrote:
> > 
> > Sure, every now and then a badly-broken package makes it in for a
> > day or two.  This seems to be far less harmful than the massive
> > headache that treating 'testing' as a usable release seems to be
> > causing.
> 
> Something that would make unstable much more useful is if dpkg had a
> reliable "undo" capability.  It's unpleasant when you update a
> broken package, and large number of packages break, and you can't
> necessarily find a copy of the older, non-broken version of the
> package to re-install.  If you're not a developer, you don't have
> access to archives, so your choice is to either go back to the stable
> or testing version of the package, or try to find a mirror that still
> has the n-1 release of the unstable package.

There is always snapshot.debian.org, or whatever the link of it is.
Anybody can access that, but again, it is not widely publicized.

Friendly,

Sven Luther

Re: security in testing

[Sven Luther]

On Thu, May 15, 2003 at 04:16:39PM +0200, Matthias Urlichs wrote:
> Hi,
> 
> Sven Luther wrote:
> > You again forget that debian is not x86 only, or do you expect Matthias
> > to have access to machines of all the supported arches ?
> >
> Right.
> 
> Besides, I don't want to do this on my own, I want to do this as part of 
> Debian. I don't yet know enough about the setup of testing-proposed-updates 
> and the whole build structure in general to see clearly what needs to be done 
> to automate the process, or indeed whether the people responsible for it 
> would be OK with enhancing that along the lines of my proposal; my impression 
> is that t-p-o is mostly processed manually at the moment, like 
> stable-proposed-updates is, and it's under-used (t-p-o/main has a whopping 
> TWO source packages). That may be a chicken-and-egg problem.

If testing-proposed-updates is really functional as Anthony claims, then
it is just a question of uploading to testing-proposed-updates instead
of unstable, which is a simple change in the changelog file. The rest
should happen automatically.

There are still some issues that need discussed, but i spoke about them
in a separate mail, and will not repeat them here.

Friendly,

Sven Luther

Kernel 2.5.69 problem

[Victor Torrico]

I compiled and ran the debian kernel-source-2.5.69 package.  It boots OK, 
however, none of he modutil functions work.  I keep getting the following 
error message:  "QM_MODULES: Function not implemented" whenever I try things 
such as insmod, lsmod, or depmod.  I suspect the source for this was omitted 
from the source package.  Used latest kernel-package for the compile.

Help appreciated.

Victor

Running all latest SID packages on i386 machine.

Re: "Bug marked as done" messages to-be-MIMEified?

[Steve Langasek]

On Thu, May 15, 2003 at 10:47:34AM -0400, David Z Maze wrote:
> "Adrian 'Dagurashibanipal' von Bidder" <[EMAIL PROTECTED]> writes:
> 
> > Q: is content-disposition handled properly, especially for
> > messag/rfc822 type attachments? (Or if not, are message attachments
> > displayed inline by default?)

> Gnus: yes (since 5.8.0, the first MIME-aware version)

> > (Yes, I've stopped caring about users of a certain other widespread MUA, as 
> > you've probably guessed anyway when you notice me using PGP/MIME to sign 
> > messages...)

> I'm not actually clear how much this is a good thing; at some level,
> we do want people reporting bugs.  (Though at the same level, we also
> want them reading and using debian-user, and "get a real MUA" is a
> common sentiment there.)

I dunno, I've always found use of Outlook to be a fairly good predictor
of bug-reporting cluelessness (use of reportbug being another :).
Looking at the bug graphs, I have a hard time believing that lack of bug
reporting is a bottleneck for Debian. ;)

-- 
Steve Langasek
postmodern programmer


pgpUjf8EOcINu.pgp
Description: PGP signature

Re: security in testing

[Matthias Urlichs]

Hi, Steve Langasek wrote:

> If none of the people who are in a
> position to approve packages for inclusion in testing or
> testing-security are willing to commit resources to doing so

... or if the process is (or can be) sufficiently automated that the
general case doesn't need any human intervention other than a
debian/changelog edit.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
-- 
Never tell people how to do things.  Tell them WHAT to do and they will
surprise you with their ingenuity.
-- Gen. George S. Patton, Jr.