Re: S/390 buildd reconfiguration --> problem fix

[Henrique de Moraes Holschuh]

On Tue, 12 Oct 2004, Martin Schulze wrote:
> Unfortunately this changed the kernel architecture from s390 to s390x.
> This in turn has the potential to break older configure scripts.

According to GNU upstream CVS, s390x was added as a basic machine in
2001-03-09.   That is *HIDEOUSLY* out-of-date stuff.

Any package with such a config.sub should be breaking also on amd64, and
probably on any of the Debian/BSDs.  Since people will notice the FTBFS on
s390x, please take the time to get a fully updated config.sub and
config.guess into sid (or at least file a bug on the BTS) while you are
doing the minimal fix for sarge...

I urge people to read the autotools-dev package's README.Debian, and use one
of the automated config.sub/guess update procedures (the "link method"
described there won't even increase your diff.gz size by more than a few
bytes) to fix packages in sid.

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

Re: [OT:HUMOR] Re: software

[Josh Lauricha]

On Mon 10/11/04 14:37, Matthew Dempsky wrote:
> Kevin Mark <[EMAIL PROTECTED]> writes:
> 
> > On Sun, Oct 10, 2004 at 11:37:06PM -0500, Adam Heath wrote:
> > Price for Commercial Software:
> >> > Adobe Illustrator CS - 90.00
> >> > Adobe Acrobat 6.0 Professional - 100.00
> >> > McAfee Personal Firewall Plus 2004 v. 5.0 - 20.00
> >> > Adobe Photoshop Elements 2.0 - 40.00
> >> > Macromedia Studio MX 2004 - 180.00
> >> > Abode InDesign CS - 100.00
> >> > Microsoft Windows Server 2003 Enterprise Edition - 200.00
> >> > Adobe Photoshop 7.0 - 60.00
> >> > Adobe Premiere Pro 1.5 - 100.00
> >> > QuickBooks Premier Edition 2004 - 80.00
> >> > Microsoft Office XP Pro - 100.00
> >> > Symantec pcANYWHERE 11.0 - 80.00
> >> > Macromedia Studio MX 2004 - 180.00
> >> > 3D Home Architect Landscape Design Deluxe 6.0 - 29.99
> 
> Debian 3.0r2 8 CD set - 17.99 [1]
> 
> The reassurance of knowing your operating system is carefully
> maintained by over 800 developers with the strictest requirements on
> freedom - Priceless

Careful, mastercard might sue you [1].
 
> The GPL.  It's everywhere you want to be.

Since that's visa, I guess it'd have to be a different commercial. So,
with the 800 developers surely some can act and direct, maybe one or two
know someone in the media... an open source Debian commercial!

http://www.attrition.org/news/mc/

-- 

--
| Josh Lauricha| Ford, you're turning|
| [EMAIL PROTECTED] | into a penguin. Stop|
| Bioinformatics, UCR  | it  |
||
| OpenPG:|
|  4E7D 0FC0 DB6C E91D 4D7B C7F3 9BE9 8740 E4DC 6184 |
||

Re: S/390 buildd reconfiguration --> problem fix

[Florian Weimer]

* Martin Schulze:

> Unfortunately this changed the kernel architecture from s390 to
> s390x.

May I suggest to fix this in the kernel?

Need a debian packager for kftpgrabber

[Kevin Smith]

http://kftpgrabber.sourceforge.net

Anyone that can join the project as a packager?

#kftpgrabber on irc.freenode.net

Any generous help or time donated would be greatly apprecaited.

Regard [EMAIL PROTECTED]

Re: S/390 buildd reconfiguration --> problem fix

[Kurt Roeckx]

On Tue, Oct 12, 2004 at 06:25:33AM +0200, Martin Schulze wrote:
> 
> Unfortunately this changed the kernel architecture from s390 to s390x.
> This in turn has the potential to break older configure scripts.

May I suggest that you use the linux32 util?  It should change
the returned uname -r from s390x to s390.

There are various places where you could do it.  They go from
doing it in the initrd to just when building it (like the call to
sbuild).


Kurt

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

[Nikita V. Youshchenko]

> > > > >  * Finally drop the bogus libapache-mod-ssl dependency from the
> > > > > apache1.3 php4 module, as glibc (>= 2.3.2.ds1-17) has fixed the
> > > > > dlopen refcount bug that we were hacking around (closes: #205553,
> > > > > #230956, #271000)
> > > >
> > > > However, libapache-mod-php4 cdoes not depend on libc6 (>=
> > > > 2.3.2.ds1-17), it just depends on libc6 (>= 2.3.2.ds1-4). Isn't
> > > > that a  bug?
> > >
> > > Perhaps, but this lack of precision will have no effect on upgrades
> > > from  woody (glibc -17 -- or rather, 18 -- is targetted for sarge);
> > > it will only have an effect for partial upgrades from earlier
> > > versions of testing/unstable.
> >
> > Quite a few people do use testing today, and may be affected by this.
>
> Perhaps so, but if we went out of our way to depend/conflict against
> every broken package that's been in testing/unstable, package
> relationships would be ridiculousy unwieldly.  The very reason
> testing/unstable exists is to weed out the bugs the best we can before a
> stable release.

I believe you are wrong.
If package requires a version of another package greater than X, it should 
declare so in it's dependences, even if you are sure that next stable 
release will satisfy this automatically.
Current situation is version of libapache-mod-php4 currently in testing 
does not work correctly with version of libc6 currently in testing.

I'm forwarding this to -devel.

Re: Need a debian packager for kftpgrabber

[Noèl Köthe]

Am Dienstag, den 12.10.2004, 01:54 -0400 schrieb Kevin Smith:
> http://kftpgrabber.sourceforge.net
> 
> Anyone that can join the project as a packager?
> 
> #kftpgrabber on irc.freenode.net

best would be to send a RFP like described on
http://www.de.debian.org/devel/wnpp/

-- 
NoÃl KÃthe 
Debian GNU/Linux, www.debian.org


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: Smooth Debian Installer Experience

[Adrian 'Dagurashibanipal' von Bidder]

On Saturday 09 October 2004 21.33, Adam Majer wrote:
> Colin Watson wrote:

> >Scroll up to the top of the country list and you'll see "enter
> >information manually".
>
> Not to nitpick here, but shouldn't options like "None of the above" be
> at the end of a list? Generally, the idea of picking something from a

IMHO, if the list is bigger than a screenfull, list items like 'not on this 
list/manually' should be displayed in a way to be visible when the screen 
first comes up: when I see part of a list of countries, I don't necessarily 
expect an item 'enter manually' at the top/bottom - I just go 'Oh, pick a 
country', scroll to Switzerland and hit enter.

cheers
-- vbi

-- 
Oops


pgpZfhglyR6dH.pgp
Description: PGP signature

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

[Jeroen van Wolffelaar]

On Tue, Oct 12, 2004 at 12:49:47PM +0400, Nikita V. Youshchenko wrote:
> [attibution missing, probably Adam Conrad]
> > Perhaps so, but if we went out of our way to depend/conflict against
> > every broken package that's been in testing/unstable, package
> > relationships would be ridiculousy unwieldly.  The very reason
> > testing/unstable exists is to weed out the bugs the best we can before a
> > stable release.
> 
> I believe you are wrong.
> If package requires a version of another package greater than X, it should 
> declare so in it's dependences, even if you are sure that next stable 
> release will satisfy this automatically.
> Current situation is version of libapache-mod-php4 currently in testing 
> does not work correctly with version of libc6 currently in testing.

If a certain range of versions of a package was buggy, that is annoying,
but not a reason for all packages affected by it to depend on non-buggy
versions. Suppose a certain version of ext2fstools trashes my filesystem
on filenames of length 42, and my application uses this filename length
extensively, do I need to conflict with this version of ext2fstools[1]?

The bug _was_ in glibc, and not in php. It is not the job of php to force
you to have a non-buggy glibc installed.

In this specific case, it must be prevented that in the end, a glibc and
a php that don't cooperate very well will be shipped with sarge. This
could be done by a suitable depends, or by making sure a newer non-buggy
glibc is really going to make testing.

As one of the Release Managers (Steve Langasek) told you that the latter
will be taken care of, and there is even a RC bug on libc to make sure
this will happen (#259211), there is no risk this will be forgotten, so
indeed, the dependency is unneeded.

--Jeroen

[1] This is just a random analogy, it's about the general idea, please
don't reply saying the analogy is not 100% correct

-- 
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl

Re: Re: Terminal - a good terminal?

[Jeff Teunissen]

[ I'm not subbed to -devel, this was pulled from the archive -- please Cc me
on replies ]

Thomas Dickey wrote:

> Jeff Teunissen <[EMAIL PROTECTED]> wrote:
> 
> > Primitive? heh. And as for the rest, I haven't had trouble -- it's
> > just an infocmp away. In any case, switching the emulation is trivial
> > -- it's not like terminal emulation is complicated.
> 
> Judging by the variety of poor implementations, I'd say that's
> incorrect. Even "linux" emulation - how many implement its savable
> colors?

Well, at least one does. :) A lot of our main emulation code was culled from
the kernel source, and abstracted some. So we got most of it for free, and
the rest is just doing a few things that aren't implemented by the kernel.

So yeah, "setterm -*ground foo -store" works.

-- 
| Jeff Teunissen  -=-  Pres., Dusk To Dawn Computing  -=-  deek @ d2dc.net
| GPG: 1024D/9840105A   7102 808A 7733 C2F3 097B  161B 9222 DAB8 9840 105A
| Core developer, The QuakeForge Projecthttp://www.quakeforge.net/
| Specializing in Debian GNU/Linux  http://www.d2dc.net/~deek/

Bug#276146: ITP: ttf-essays -- TrueType font based on the typeface used in a 1743 English translation of Montaigne's Essays

[Carlos Perellà MarÃn]

Package: wnpp
Severity: wishlist

* Package name: ttf-essays
  Version : 0.2
  Upstream Author : John Stracke <[EMAIL PROTECTED]>
* URL : http://www.thibault.org/fonts/essays/
* License : LGPL
  Description : TrueType font based on the typeface used in a 1743 English 
translation of Montaigne's Essays

John wrote a new TrueType font and asked me about package it for Debian
as I'm already doing with isabella and staypuft.

It contains 817 characters: all of ASCII, Latin-1, and Latin Extended A;
some of Latin Extended B (basically, the ones that are more or less based
on Roman letters); and a variety of other characters, such as oddball
punctuation, numerals, etc.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-1-686
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (ignored: LC_ALL set to 
es_ES.UTF-8)

Wanted BTS feature: subscription to individual bug reports

[Nikita V. Youshchenko]

Hello.

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

Currently I can subscribe to bugs on per-package-basis (using PTS), or to 
all bugs using [EMAIL PROTECTED]

Something thar could be really usable is subscribing to bugs that I've 
either submitted, or ever posted a comment to.

Is something like that available/planned?

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

[Nikita V. Youshchenko]

> > Current situation is version of libapache-mod-php4 currently in
> > testing does not work correctly with version of libc6 currently in
> > testing.
>
> If a certain range of versions of a package was buggy, that is annoying,
> but not a reason for all packages affected by it to depend on non-buggy
> versions. Suppose a certain version of ext2fstools trashes my filesystem
> on filenames of length 42, and my application uses this filename length
> extensively, do I need to conflict with this version of ext2fstools[1]?

Although I agree that it is not possible (and sometimes is an absurd) to 
declare complete package relationships that will work correclty in any 
case, I think such deps should be declared whn possible.

A good compromise is to declare relationship with any version of packages 
that have been in the archive since last stable release - at least in case 
when such relationships are either known by package maintainer a priori 
(as in this case - it was documented in changelog), or are found and 
reported by users.

This costs a little effort, and makes mixed stable/testing/unstable systems 
more consistent. [I believe ability to run such systems without major 
problems is an important feature of debian]

> The bug _was_ in glibc, and not in php. It is not the job of php to
> force you to have a non-buggy glibc installed.

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

> In this specific case, it must be prevented that in the end, a glibc and
> a php that don't cooperate very well will be shipped with sarge. This 
> could be done by a suitable depends, or by making sure a newer non-buggy
> glibc is really going to make testing.

If we go futher this way, we may end with statement that versioned 
dependencies are not needed at all, because sooner or later needed version 
will enter testing, and the only thing is no ensure that this will happen 
before next stable release.

> As one of the Release Managers (Steve Langasek) told you that the latter
> will be taken care of, and there is even a RC bug on libc to make sure
> this will happen (#259211), there is no risk this will be forgotten, so
> indeed, the dependency is unneeded.

IMHO this only means that this issue is not RC bug against 
libapache-mod-php4. But this does not mean that issue does not exist.


Probably the issue is minor, and doesn't really need any attension. But 
system quality will be higher if this and similar issues will be avoided, 
and adding a versioned dep is not a high cost to pay for that :).

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

[George Danchev]

On Tuesday 12 October 2004 12:33, Jeroen van Wolffelaar wrote:
> On Tue, Oct 12, 2004 at 12:49:47PM +0400, Nikita V. Youshchenko wrote:
> > [attibution missing, probably Adam Conrad]
> >
> > > Perhaps so, but if we went out of our way to depend/conflict against
> > > every broken package that's been in testing/unstable, package
> > > relationships would be ridiculousy unwieldly.  The very reason
> > > testing/unstable exists is to weed out the bugs the best we can before
> > > a stable release.
> >
> > I believe you are wrong.
> > If package requires a version of another package greater than X, it
> > should declare so in it's dependences, even if you are sure that next
> > stable release will satisfy this automatically.
> > Current situation is version of libapache-mod-php4 currently in testing
> > does not work correctly with version of libc6 currently in testing.
>
> If a certain range of versions of a package was buggy, that is annoying,
> but not a reason for all packages affected by it to depend on non-buggy
> versions. 

That is not always the way to go and depends on how long it will take to fix 
the buggy package, and if any reasonable dependency alternatives could be 
found. Good exaple is the recent dfsbuild, apt-move, gawk saga... Because of 
#263964, the #274377 was reasinged to apt-move, and #265117 #274377 got 
merged. That's because it is faster to complete #274377 and reduce the 
impact, till #263964 gets properly fixed.

-- 
pub 4096R/0E4BD0AB  2003-03-18  
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 

Re: Need a debian packager for kftpgrabber

[Alexander Schmehl]

* Noèl Köthe <[EMAIL PROTECTED]> [041012 11:18]:
> > http://kftpgrabber.sourceforge.net
> > Anyone that can join the project as a packager?
> > #kftpgrabber on irc.freenode.net
> best would be to send a RFP like described on
> http://www.de.debian.org/devel/wnpp/

Vince Tantardini <[EMAIL PROTECTED]> allready send an ITP #276068.

Yours sincerely,
  Alexander


signature.asc
Description: Digital signature

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

[Adrian 'Dagurashibanipal' von Bidder]

On Monday 11 October 2004 20.24, Marco d'Itri wrote:
> On Oct 11, Joerg Sommer <[EMAIL PROTECTED]> wrote:
> > why ppp provides its own mechanism of telling programs when the
> > interface is coming up or down? Many programs register for the ppp
> > mechanism, but not for the network mechanism. Where is the difference
> > and why both isn't
>
> Historical reasons? Also, many programs are interested only the ppp
> interface (it could be argued that they actually care about the
> interface associated to the default route, but at this point it would be
> a bit complex to do something about this).

I agree with JÃrg, though, that this should be unified for sarge+1.

JÃrg: file a wishlist bug with ppp and/or programs using ppp/if-*.d, 
perhaps? 

cheers
-- vbi

-- 
Oops


pgpszAs7jNZQ8.pgp
Description: PGP signature

Re: Updating scanners and filters in Debian stable (3.1)

[paddy]

On Mon, Oct 11, 2004 at 04:30:36PM -0400, Stephen Gran wrote:
> This one time, at band camp, paddy said:
> > On Mon, Sep 13, 2004 at 12:45:34PM -0400, Stephen Gran wrote:
> > > This one time, at band camp, Martin Schulze said:
> > > > A while ago there was a discussion in which it was said that such
> > > > tools are rather useless (or even dangerous) if they don't get their
> > > > database updated in accordance with new viruses/security problems.
> > > > 
> > > > Some of these systems are hence not suitable for a stable Debian
> > > > release where updates will only be made for security problems and
> > > > very important bugfixes.
> > > > 
> > > > Have you thought about keeping these packages out of sarge or did you
> > > > develop a solution so that users can get their databases updated
> > > > outside of the stable Debian release?
> > > 
> > > ClamAV uses freshclam for virus definitions, so the actual database
> > > updates are covered.  That being said, there are relatively frequent
> > > changes to the scanning engine as well, leaving me feeling like it may
> > > not be the best choice for a stable release.  I do plan to continue
> > > offering out of band up dates on p.d.o, but I am not sure this is the
> > > best way to proceed.  Feedback welcome,
> > 
> > Stephen,
> > 
> > Revisiting your original question.
> > 
> > Reading the Debian Policy Manual as I am right now:
> > 
> > 2.2.1 The main section
> > ...
> > packages in main ...
> > must not be so buggy that we refuse to support them
> > 
> > While you clearly do not refuse, it was argued that the net effect is 
> > likely to be just so.
> 
> People seem to comparing apples and oranges rather frequently in this
> discussion, so I will try to be very clear here.  I am not talking about
> regular bugs in clam that affect the security, stability, or packaging
> of the software itself.  Infrastructure is already in place for those
> sorts of problems.  

You're right of course, I have been confused by conversations about other
packages.  Given that a package lives up to what is expected of packages
in stable (or can reasonably be expected to do so), is it not 'supported'
by definition?  

It would seem a little presumptious to consider the converse: that packages
needing it should maintain a presence in volatile, as a condition of
fullfilling their obligations to stable.

Either way, this does underline the potential value of volatile, 
as you go on to point out.
 
> The problem is only that packages of this sort need to change to keep 
> up with the threats they are designed to combat.  The inability to pick 
> up a new virus is not a bug in the same category as 'segfaults at start'
> or 'never worked at all' - it is a 'this used to work, but times have 
> changed' bug, similar to a 'please package new upstream version because
> it has more features' kind of bug.  If clam releases in stable, and
> there is no volatile, then there is no in-band mechanism to deal with
> these sorts of bugs.  So there will likely be tons of 'does not catch
> virus X' bugs tagged wontfix and people will just be referred to out of
> band update sites.  This is not the end of the world, but I think we can
> do better.

Agreed.

> > Perhaps the question now should be:  does volatile modify this?
> > 
> > (for example, does volatile count as support for this purpose).

I realise now that this is perilously close to 'an excuse for not 
living up to the standards of stable', which I did not intend.

> I don;t think it relates to that part of the policy manual, as I said
> above, but perhaps some people feel so.

Just reading that paragraph in the policy manual, there seems an ambiguity 
in 'support', but I am not familiar with whole document and its interpretation, 
so I am likely just misquoting.  I really was reading that at the time and my 
post finger got itchy (again :)  And I thought that data point might assist
you in addressing one of your original questions.

I have no strong feeling either way, beyond that volatile seems a strong
positive move to do worthwhile work.

But if 'support' for stable is defined to ignore the 'useless' question,
then it seems volatile will define 'support' to a different standard.

Regards,
Paddy
--
Perl 6 will give you the big knob. -- Larry Wall

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

[Robert Collins]

On Tue, 2004-10-12 at 13:59 +0200, Adrian 'Dagurashibanipal' von Bidder
wrote:
> On Monday 11 October 2004 20.24, Marco d'Itri wrote:
> > On Oct 11, Joerg Sommer <[EMAIL PROTECTED]> wrote:
> > > why ppp provides its own mechanism of telling programs when the
> > > interface is coming up or down? Many programs register for the ppp
> > > mechanism, but not for the network mechanism. Where is the difference
> > > and why both isn't
> >
> > Historical reasons? Also, many programs are interested only the ppp
> > interface (it could be argued that they actually care about the
> > interface associated to the default route, but at this point it would be
> > a bit complex to do something about this).
> 
> I agree with Jörg, though, that this should be unified for sarge+1.
> 
> Jörg: file a wishlist bug with ppp and/or programs using ppp/if-*.d, 
> perhaps? 

First off the semantics of using ifupdown ifup.d scripts for ppp
interfaces need to be made the same as using ppp ifup.d scritps for ppp
interfaces.
ifupdown - normally interface is created before ifup.d scripts are run,
and does not go away again, except maybe after ifdown is run (modulo
users deliberately doing stuff like rmmod). for ppp interfaces, they do
not exist when the ifup.d scripts run, and may disappear and reappear
without warning (thing persist mode)- without the ifupdown ifup.d
scripts being run. In short, the scripts run once when the 'user' runs
ifup, and once on ifdown.

ppp's ifup.d scripts however are called for each and every time the
interface finishes connecting .. and disconnects. In short, the scripts
may run many times for on pon, and then once for poff.

Thats quite different - I'd love for this to be consolidated and
addressed though.

Rob



-- 
GPG key available at: .


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

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

[paddy]

John,

On Mon, Oct 11, 2004 at 06:48:00PM -0500, John Hasler wrote:
> Sven Mueller writes:
> > Say a new open source network security scanner enters the world, and it
> > works well when compiled against Debian stable, we might want to add it
> > to v.d.o even though it wasn't available when the last stable
> > distribution was released.  Or a new version of clamav is released, which
> > sadly breaks compatibility, so we rename it to clamav2 and it can still
> > be released through v.d.o, similarly to exim4 entering debian alongside
> > exim a while ago.
> 
> Those things belong in the non-existent backports.debian.org, not in
> volatile.debian.org.

I disagree.

define 'breaks compatibilty'.

As long as it _is_ still the same package, (For an example of the converse, 
I direct you to apt-proxy) then the change in name is just
an artifact of the upstream versioning and the packaging system.  Basing
policy on an implementation detail that should be used for 
technical reasons, simply for lack of doing the work to arrive at a 
proper description, would be a mistake. (not that I'm accusing you of
doing that, clearly).

Regards,
Paddy
-- 
Perl 6 will give you the big knob. -- Larry Wall

Re: TG3 firmware report...

[John Hasler]

Florian Weimer writes:
> Is U.S. law really *that* different?

No.  It is commonplace to introduce evidence about established industry
practice in lawsuits.
-- 
John Hasler

Re: Wanted BTS feature: subscription to individual bug reports

[Christoph Berg]

Re: Nikita V. Youshchenko in <[EMAIL PROTECTED]>
> I can't find a way to track more-or-less easilly all bugs in BTS that I am 
> somewhat involved into.
> 
> Is something like that available/planned?

Planned yes, available no:

http://people.debian.org/~terpstra/message/20030918.123817.598830d5.en.html

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


signature.asc
Description: Digital signature

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

[Marco d'Itri]

On Oct 12, Adrian 'Dagurashibanipal' von Bidder <[EMAIL PROTECTED]> wrote:

> I agree with Jörg, though, that this should be unified for sarge+1.
I doubt this is even possible, the semantics are very different for any
non-trivial scenario (and for many trivial ones too).

> Jörg: file a wishlist bug with ppp and/or programs using ppp/if-*.d, 
> perhaps? 
Don't bother filing bugs against ppp, I don't see anything to be changed
in the package.

-- 
ciao, |
Marco | [8514 trUIqsDAQNRrY]


signature.asc
Description: Digital signature

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

[John Hasler]

Sven Mueller writes:
> Say a new open source network security scanner enters the world...
^^^
I wrote:
> Those things belong in the non-existent backports.debian.org, not in
> volatile.debian.org.

paddy writes:
> define 'breaks compatibilty'.

> As long as it _is_ still the same package...

If a package changes enough to require a new name it is a new package.

> Basing policy on an implementation detail that should be used for
> technical reasons, simply for lack of doing the work to arrive at a
> proper description, would be a mistake.

I don't understand what you mean by this.  Descriptions have nothing to do
with it.
-- 
John Hasler

Re: about volatile.d.o/n

[Henning Makholm]

Scripsit Sven Mueller <[EMAIL PROTECTED]>
> Henning Makholm [u] wrote on 11/10/2004 20:22:

> [volatile.debian.org]

> > Security fixes should be handled by security.d.o.

> Perhaps yes, perhaps no.

Security fixes *to* packages already in volatile is a grey area, yes.

I thought I was talking about security fixes to stable packages
going in volatilie instead of security.d.o.

-- 
Henning Makholm "You want to know where my brain is,
spetsnaz girl? Do you? Look behind you."

Re: about volatile.d.o/n

[Henning Makholm]

Scripsit paddy <[EMAIL PROTECTED]>
> On Mon, Oct 11, 2004 at 07:22:15PM +0100, Henning Makholm wrote:
> > Scripsit paddy <[EMAIL PROTECTED]>

> > > To be fair, the issue is that if were just rules, there wouldn't
> > > be a need.

> > Why not? 

> Well, the argument goes:

>   that can be done out-of-band,

But isn't volatile.d.o supposed to *be* the out-of-band mechanism
(whatever out-of-band means here)?

>   but some updates involve changes
>   or additions to the engine.  There is a class of such software.

I don't see how that means that there "wouldn't be a need" for rule
updates.

> SA3 has been on the cards for some time now.  Is there a policy around 
> name changes at these times?  could you have pinned (<<3.0) ?

Not according to my understanding of apt pinning. And in any case the
point is that I want to run a *stable* box. I am not keeping
consciously track with upstream changes to "background" software like
spam filters, so I didn't *know* that a 3.0 version was about to
happen. A user of stable should be *able* to remain ignorant about
such chages. That's what "stable" means.

> At the end of the day, I'm not certain exactly what you wanted protecting
> from,

See the long thread about spamassassin3. The highlight is that the new
version has a non-backwards-compatible API which makes certain other
software stop working.

I did not personally have any local scripts that depended on the old
API, but I might have had.

> but it's hard to be certain that volatile would give it to you.
> After all the point is to get (at least some) changes.

The point is to get improved *classification* without changing the
*interfaces*.

> > Clearly, but the *format* in which the virus scanner reports its
> > findings should stay stable.

> You'll get no argument from me on the priciple of that.
> But what is stable?  What if a format needs extending to take account
> of some new circumstance?

Then a decision has to be made respecting the users' interest in
having whatever local scripts they are using keep working.

> For instance, suppose there are Packages A and B in volatile.
> (A) has an interface (1) that is only used by (B) in the whole of debian.

"In the whole of Debian" is not the only concern here; I would say it
is not even relevant. Admins of un*x systems are *supposed* to write
a truckload of local scripts to adapt their system to their wishes.
That's the way it works. And our commitment in calling stable "stable"
is that those local scripts will keep working across security updates,
unless breaking them is necessary to close a hole. Similarly, if
volatile is to be any value added over pinning unstable or testing,
it must respect the same commitment.

> but the case for eventually upgrading to (1+) is
> compelling: it is only a question of when and how.

If upgrading will break existing interfaces, then "when" means "after
the current testing freezes and is released as stable".

> You've said mozilla belongs in backports, which I'll take to mean:
> mozilla does not belong in volatile.

I'm saying that *new upstream versions* of mozilla with hundreds of
little interface changes, new preferences file formats, et cetera,
does not belong in volatile.

> So you're not advocating mozilla in volatile. It may be that someone
> will come along that will advocate it in a compelling fashion, but
> I'm not holding my breath.  Until then, if no one is building it,
> then what is there to knock down ?

I do not understand that question either.

> Concrete example: I care about virus detection in the first two weeks, 
> and even more so in the first few hours.  To me not detecting a virus,
> purely because someone is correcting spellings would be downtime.
> (of course, if it's because _I'm_ too busy or too lazy, that's a
> different matter ! ;)

I'm not sure what consequences this example has for what should and
what should not be accepted in volatile. If the volunteer who would be
preparing a rule update would rather use his time correcting
spellings, we cannot force him. But that is probably not what you're
getting at?

-- 
Henning Makholm  "I tried whacking myself repeatedly
 with the cluebat. Unfortunately, it was
 not as effective as whacking someone else."

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

[paddy]

On Tue, Oct 12, 2004 at 07:57:06AM -0500, John Hasler wrote:
> Sven Mueller writes:
> > Say a new open source network security scanner enters the world...
> ^^^

Yes, I neglected this half of the scenario, but see below.

> I wrote:
> > Those things belong in the non-existent backports.debian.org, not in
> > volatile.debian.org.
> 
> paddy writes:
> > define 'breaks compatibilty'.
> 
> > As long as it _is_ still the same package...
> 
> If a package changes enough to require a new name it is a new package.

Does the converse apply?  If not then you have a problem.

> > Basing policy on an implementation detail that should be used for
> > technical reasons, simply for lack of doing the work to arrive at a
> > proper description, would be a mistake.
> 
> I don't understand what you mean by this.  Descriptions have nothing to do
> with it.

Yes I wasn't happy with the word decription either but I had hoped it would 
suffice.

My point is this:  

I would oppose a policy that said 
'packages under new names must not enter volatile'

because I strongly suspect that 'packages under new names' is a poor proxy 
for whatever it is you want.  In particular it might create a pressure in
a marginal situation on the otherwise technical decision of naming a package.
I hope you will agree that this would be undesirable, even if you contend
that it does not invalidate the use of 'packages under new names' in this
way.

I've suffered the breakage that comes with such naming, and I gave you a
good example.  I wouldn't wish to see more pressure on this device.

I would like to know what you want.  Because we appear to disagree on the 
more fundamental issue of whether new packages *should* ever enter volatile.  
I'm hoping we can get to a 'proper description', at which point I would
hope that the whole 'packages under new names' would fall by the wayside, 
although I hope I am open-minded enough to be persuaded otherwise.

Let me articulate my opposition to closing down the possibility of new
packages in volatile.

We don't need just another backports.
Nor do we need just another stable.

Packages entering volatile should do so for a good reason.  
I would support your position modified to 'should not _automatically_ enter'
for new major versions of packages already in volatile.  There should be
a good reason.

Volatile must be free to package software that is not in stable, this is
its reason to exist.

Being too rigid about this could result in packages in stable have dependencies
across stable, volatile and backports, or not being able to fulfill the
purpose of being usefull.

If you want a clone of stable, you might as well say 'nothing can enter after
stable is released', which is mighty close to what you are saying, only
noone is saying that because it _so_ obviously ridiculous.

I hope that volatile will play very nicely with stable.  For me that is the
whole point. But I don't expect it to have a two to three year release cycle.
That is also the point.  But most of all it should exist for a purpose,
and I would not see that purpose hobbled by knee-jerk reactions, although
I _am_ keen to try to understand what your point is.

Regards,
Paddy
-- 
Perl 6 will give you the big knob. -- Larry Wall

Re: about volatile.d.o/n

[Sven Mueller]

Henning Makholm [u] wrote on 12/10/2004 16:05:
For instance, suppose there are Packages A and B in volatile.
(A) has an interface (1) that is only used by (B) in the whole of debian.
"In the whole of Debian" is not the only concern here; I would say it
is not even relevant. Admins of un*x systems are *supposed* to write
a truckload of local scripts to adapt their system to their wishes.
That's the way it works. And our commitment in calling stable "stable"
is that those local scripts will keep working across security updates,
unless breaking them is necessary to close a hole. Similarly, if
volatile is to be any value added over pinning unstable or testing,
it must respect the same commitment.
If you put it that way, I have to agree with you. However, I would make 
one restriction:
- packages in volatile have to keep their commandline (both input and
  output) interfaces compatible, but may change C/Python/Perl
  interfaces if no unresolved incompatibility in the whole of Debian is
  created that way. However, as far as possible, they _should_ also keep
  those compatible.
An exception can be made (like you said) if a change in interface is 
needed to close a security whole. Another reason for exception is an 
addition to the interface (as little interfering as possible) to allow 
scanning for and reporting of new security holes or viruses (for 
security/virus scanners).

If upgrading will break existing interfaces, then "when" means "after
the current testing freezes and is released as stable".
Like I said above, I generally agree. But I would only expect scripting 
interfaces in the meaning of commandline interfaces to remain 
compatible. If a sysadmin writes scripts which depend on an actual API, 
I think it is reasonable for him(/her) to track changes in the APIs 
(s)he is using and/or to mark the packages containing those APIs as hold.

You've said mozilla belongs in backports, which I'll take to mean:
mozilla does not belong in volatile.
I'm saying that *new upstream versions* of mozilla with hundreds of
little interface changes, new preferences file formats, et cetera,
does not belong in volatile.
OK, I would like to see it implemented approx. like this (names subject 
to change):
- volatile.d.o: security and virus scanners, anti-spam software and
similarly fast moving software needed mostly on servers
- backports.d.o: New (versions of) user interface software (new KDE, new
 Mozilla and the like)
Both might need security team support, which I would think is difficult 
for the later.

cu,
sven

Re: TG3 firmware report...

[Thomas Bushnell BSG]

Florian Weimer <[EMAIL PROTECTED]> writes:

> > You cannot infer person A's intent in doing something merely by
> > assuming that it must be the same as persons B, C, and D.
> 
> Well, of course you can.  A lot of contracts are made this way (for
> example, if you buy something in a shop).

Actually, no.  First, buying something in a shop doesn't necessarily
involve any contract at all; it's a sale, which can proceed other than
by contract.

Second, the Uniform Commercial Code explicitly says things about
following customary practices, and does say that commercial contracts
are presumed to be following normal customary practices, so that such
imputation of intent works there.

But no, the UCC does not apply to copyright licensing.

And finally, it might be evidence for A's intent that they were
probably wanting what B, C, and D, wanted.  I said that you can't get
there *merely* from that assumption, but there must be some additional
something to help it along.  Otherwise, the inference doesn't go.

Moreover, companies are allowed to have deceptive copyright
statements; in fact, they do it all the time.  Nearly every book or CD
you get has a deceptive copyright statement on it.

Thomas

Re: TG3 firmware report...

[Thomas Bushnell BSG]

John Hasler <[EMAIL PROTECTED]> writes:

> No.  It is commonplace to introduce evidence about established industry
> practice in lawsuits.

Right, but this is not imputation of intent, and it's generally done
under the UCC which worked a sea change in US commercial contracts law
for this purpose, but does not apply to non-contractual things like
copyright licenses.

Re: about volatile.d.o/n

[paddy]

On Tue, Oct 12, 2004 at 03:05:05PM +0100, Henning Makholm wrote:
> Scripsit paddy <[EMAIL PROTECTED]>
> > On Mon, Oct 11, 2004 at 07:22:15PM +0100, Henning Makholm wrote:
> > > Scripsit paddy <[EMAIL PROTECTED]>
> 
> > > > To be fair, the issue is that if were just rules, there wouldn't
> > > > be a need.
> 
> > > Why not? 
> 
> > Well, the argument goes:
> 
> > that can be done out-of-band,
> 
> But isn't volatile.d.o supposed to *be* the out-of-band mechanism
> (whatever out-of-band means here)?

No. clamav virus signatures, for example, can be maintained by a program,
freshclam, that downloads database updates from upstream.  These files
do not come through the usual package management: you don't apt-get them.
Similar situtations exist for other software with this kind of volatility.

> >   but some updates involve changes
> > or additions to the engine.  There is a class of such software.
> 
> I don't see how that means that there "wouldn't be a need" for rule
> updates.

See above.  The consensus seems to be that it would be undesirable to 
even try to push this data through the regular package-management channel.

> > SA3 has been on the cards for some time now.  Is there a policy around 
> > name changes at these times?  could you have pinned (<<3.0) ?
> 
> Not according to my understanding of apt pinning. 

Pity, that would be a nice feature.

> And in any case the
> point is that I want to run a *stable* box. I am not keeping
> consciously track with upstream changes to "background" software like
> spam filters, so I didn't *know* that a 3.0 version was about to
> happen. A user of stable should be *able* to remain ignorant about
> such chages. 

Ah, but you weren't just a user of stable were you?  
You'd drunk from the forbidden waters of unstable! :)

> That's what "stable" means.

I'd go along with that.

I don't know what "volatile" will eventually mean.
Clearly it can't mean exactly the same as "stable", but it would be
a shame if it couldn't provide a service in the "I don't how it works, 
it just works" class to users of stable.

That isn't however my personal interest.

> > At the end of the day, I'm not certain exactly what you wanted protecting
> > from,
> 
> See the long thread about spamassassin3. The highlight is that the new
> version has a non-backwards-compatible API which makes certain other
> software stop working.

I'll go and do that, I had been skipping it ...

> I did not personally have any local scripts that depended on the old
> API, but I might have had.
> 
> > but it's hard to be certain that volatile would give it to you.
> > After all the point is to get (at least some) changes.
> 
> The point is to get improved *classification* without changing the
> *interfaces*.

For me the point is to achieve function.  
Naturally one tries to avoid bugs and breakage.  

The standards of QA to which given software are important factors in
the selection of that software.  Volatile should have clear standards
of QA so that users know what to expect, and mainatiners know what they
are aiming for.  I don't know how much of that it will be possible to
write upfront, and how much will have to be learn along the way.

> > > Clearly, but the *format* in which the virus scanner reports its
> > > findings should stay stable.
> 
> > You'll get no argument from me on the priciple of that.
> > But what is stable?  What if a format needs extending to take account
> > of some new circumstance?
> 
> Then a decision has to be made respecting the users' interest in
> having whatever local scripts they are using keep working.

Sounds reasonable to me.

> > For instance, suppose there are Packages A and B in volatile.
> > (A) has an interface (1) that is only used by (B) in the whole of debian.
> 
> "In the whole of Debian" is not the only concern here; 

Agreed, and I did attend to the question of user scripts further down.

> I would say it is not even relevant. 

I think it could prove to be a consideration.

> Admins of un*x systems are *supposed* to write
> a truckload of local scripts to adapt their system to their wishes.

I only use a soldering iron.  scripts are for wimps. invoking trucks
doesn't make them any less wimpy.  ;)

> That's the way it works. And our commitment in calling stable "stable"
> is that those local scripts will keep working across security updates,
> unless breaking them is necessary to close a hole. Similarly, if
> volatile is to be any value added over pinning unstable or testing,
> it must respect the same commitment.

Okay.  The purpose of security is to close holes.  Given that volatile
identifies it's purpose, I say we apply a similar measure.  Without the
_possibility_ of trading breakage against purpose, we run the risk of
futility.  But I agree, breakage should not be introduced randomly.

I happen to believe that an excessive aversion to controlled breakage
can result in more consequential 'accidental' breakages.

There is almost always a trade-off.

Trying to fix tutos package

[Ernesto Hernandez-Novich]

For about a couple of months I've been working in order to fix 'tutos'
so that the latest upstream, plus additional plugins and handlers, is
included in Sarge. The version currently available in testing is very
old and misses lots of new features, plus has some annoying bugs.

I've been in contact with the current maintainers, and even though they
have been very helpful, I feel they don't have enough time for my
questions.

I've placed the package in

deb http://arepa.nuevomundo.com.ve/~emhn/debian binary/

and it does install properly (I've been able to test it in i386, alpha
and sparc) and seems to work fine. I'd like more testing from other
people, of course.

There's an issue with a couple of dependencies:

- The currently available version in Sarge depends on libphp-jpgraph
  (1.5.2). The latest TUTOS' version will _not_ work with that, and the
  changes needed to make it so are not trivial. Upstream libphp-jpgraph
  changed licences from 1.6 on, and it's no longer DFSG compliant.

  For _my_ internal use, I've packaged 1.16, and TUTOS works fine (is
  also in the APT source listed before)

- TUTOS has a very nice Palm Plugin that allows exporting things like
  contacts and calendars to PDB files. The library required for that
  is DFSG compliant, but it's not packaged in Debian; I've already
  packaged for my internal use, and it works, I've just not added it
  as a dependency yet.

I'd appreciate pointers on what to do now in order to get this package
into Sarge, and hopefully the libphp-pdb library as a new package.

My public GPG key is in

http://arepa.nuevomundo.com.ve/~emhn/debian

for those interested in verifying the packages (note that it is signed by
César Mendoza, already a Debian Developer).
-- 
Ernesto Hernández-Novich - On Linux 2.6.8.1 i686 - Unix: Live free or die!
Geek by nature, Linux by choice, Debian of course.
If you can't apt-get it, it isn't useful or doesn't exist.
GPG Key Fingerprint = 438C 49A2 A8C7 E7D7 1500 C507 96D6 A3D6 2F4C 85E3

Re: about volatile.d.o/n

[John Hasler]

sven writes:
> - volatile.d.o: security and virus scanners, anti-spam software and
> similarly fast moving software needed mostly on servers

- volatile.d.o: security and virus scanners, anti-spam software and
  similarly fast moving software

> - backports.d.o: New (versions of) user interface software (new KDE, new
> Mozilla and the like)

- backports.d.o: New (versions of) software (new KDE, new Mozilla and the
like)

> Both might need security team support, which I would think is difficult
> for the later.

I would say that both _require_ security team support, and are not worth
doing if it is not available.
-- 
John Hasler

Re: about volatile.d.o/n

[paddy]

On Tue, Oct 12, 2004 at 05:02:23PM +0200, Sven Mueller wrote:
> Henning Makholm [u] wrote on 12/10/2004 16:05:
> 
> >>For instance, suppose there are Packages A and B in volatile.
> >>(A) has an interface (1) that is only used by (B) in the whole of debian.
> >
> >"In the whole of Debian" is not the only concern here; I would say it
> >is not even relevant. Admins of un*x systems are *supposed* to write
> >a truckload of local scripts to adapt their system to their wishes.
> >That's the way it works. And our commitment in calling stable "stable"
> >is that those local scripts will keep working across security updates,
> >unless breaking them is necessary to close a hole. Similarly, if
> >volatile is to be any value added over pinning unstable or testing,
> >it must respect the same commitment.
> 
> If you put it that way, I have to agree with you. However, I would make 
> one restriction:
> - packages in volatile have to keep their commandline (both input and
>   output) interfaces compatible, 

would that be 'have to' as in 'MUST'?
define compatible.

>   but may change C/Python/Perl
>   interfaces if no unresolved incompatibility in the whole of Debian is
>   created that way. 

Yeah I've never liked those C/Python/Perl people either, 
not enough soldering irons! ;)

>   However, as far as possible, 

what is the basis for the trade-off.

>  they _should_ also keep those compatible.

so that's just a bug then?

> An exception can be made (like you said) if a change in interface is 
> needed to close a security whole. 

Taken as read.

> Another reason for exception is an 
> addition to the interface (as little interfering as possible) to allow 
> scanning for and reporting of new security holes or viruses (for 
> security/virus scanners).

This is part of the definition of compatible?

> >If upgrading will break existing interfaces, then "when" means "after
> >the current testing freezes and is released as stable".
> 
> Like I said above, I generally agree. But I would only expect scripting 
> interfaces in the meaning of commandline interfaces to remain 
> compatible. If a sysadmin writes scripts which depend on an actual API, 
> I think it is reasonable for him(/her) to track changes in the APIs 
> (s)he is using and/or to mark the packages containing those APIs as hold.

more generally, and a point I was trying to make before:

If one wishes to make guarantees about APIs then it might be good to
identify the APIs.  It is surprising how much people's opinions can vary 
in the edge-cases, and too much hand-waving is bad for the circulation.
(okay, so I made the last part up).

Sven, you're clearly having a good crack at that here.

> >>You've said mozilla belongs in backports, which I'll take to mean:
> >>mozilla does not belong in volatile.
> >
> >I'm saying that *new upstream versions* of mozilla with hundreds of
> >little interface changes, new preferences file formats, et cetera,
> >does not belong in volatile.
> 
> OK, I would like to see it implemented approx. like this (names subject 
> to change):
> - volatile.d.o: security and virus scanners, anti-spam software and
> similarly fast moving software needed mostly on servers
> - backports.d.o: New (versions of) user interface software (new KDE, new
>  Mozilla and the like)
> Both might need security team support, which I would think is difficult 
> for the later.

Depending on how big it is I imagine.  Certainly, when staying close to
upstream versions, one hopes to have a relatively easy time applying 
security fixes (or even just upgrading to the next version).

I'm inclined to think that packages like mozilla belong in stable or
backports, because I can't see why they _have_ to be volatile.  I don't
think being immature software would make a good criterion for entry.

Regards,
Paddy
-- 
Perl 6 will give you the big knob. -- Larry Wall

Re: TG3 firmware report...

[Nathanael Nerode]

Marco d'Itri wrote:

> On Oct 10, Nathanael Nerode <[EMAIL PROTECTED]> wrote:
> 
>> Until they do one of these two things, the firmware is not safe to
>> distribute.  I don't know why upstream is distributing it; I believe they
>> are simply being sloppy about licensing.
> You know well that upstream is not "being sloppy", but disagrees with
> your interpretation of licensing.

On the contrary.  The upstream maintainer stated that "nobody" from Broadcom
"complained", and apparently felt that that was sufficient, and that it was
unimportant to get a valid explicit license.  Or indeed to include
Broadcom's copyright statement at all, until I complained about its
absence.  That, to me, seems sloppy.

Copyright infrignment is strict liability, IIRC.  This is not safe to mess
around with.

-- 
This space intentionally left blank.

Re: TG3 firmware report...

[Nathanael Nerode]

John Hasler wrote:

> Nathanael Nerode writes:
>> To me, this means that Broadcom didn't know what the hell it was doing.
>> I cannot divine Broadcom's actual intentions from that, and Broadcom can
>> easily and convincingly claim that it intended something different from
>> what you assume.
> 
> The intent implied by publically releasing a work under the GPL is well
> understood and widely known.

The intent implied by publically releasing a work "under the GPL" but
without source code, however, is not well understood or widely known.  If
indeed anyone understands it.

> I don't believe that they would stand any 
> chance of getting an injunction, let alone damages.

Have you got a legal opinion to back that up?  :-P

> The fact that they have already permitted redistribution would count
> heavily against them.

Well, if you feel safe distributing the tg3 microcode files in non-free, you
may.  I don't, which is why I have not submitted such a package to Debian.

I will be happy to tell you how to take the files from Broadcom's driver and
convert them to the form which is loaded by the driver currently in Debian,
and to give you my tools for doing so.  (Or anyone else who is interested
in this.)

Perhaps I should construct a package for non-free which instructs users to
download Broadcom's driver; then unpacks it, and converts and installs the
firmware files appropriately?  (I *am* sure that Broadcom permits
distribution from their own website directly to end-users, since they
pretty much advertise that.)  That I would feel safe doing.

-- 
This space intentionally left blank.

Re: TG3 firmware report...

[Nathanael Nerode]

Thomas Bushnell BSG wrote:

> John Hasler <[EMAIL PROTECTED]> writes:
> 
>> Thomas writes:
>> > In cases like this one, what has happened is that the copyright holder
>> > has simply failed to make legal distribution possible, by saying "you
>> > must distribute complete source" and then failing to provide it.
>> 
>> He has provided what he claims is source.

If there was an explicit statement saying "Broadcom claims that this is
source code for the purposes of the GPL," that would be the case.  I have
not been able to get such a statement from Broadcom, either.

If someone has better lines of communication with Broadcom, they can clear
this up really easily: making the statement above; releasing the source
code; licensing under 2-clause BSD or MIT/X11; or stating "We intend to
allow anyone to redistribute these hex files in any form": *any one* of
these options would make the firmware safe to distribute in non-free.

However, since I have not yet been able to talk to anyone at Broadcom who
appears to know anything about this, I do not feel safe making any
assumptions about their intent.

>> If he sues me for 
>> redistributing all of what I got from him after he told me it included
>> source he will be laughed out of court.
> 
> In this case, one would be well advised to obtain an explicit waiver
> on the point, rather than to rely on such.

Which is exactly what I hoped to get.  Unfortunately, I have had a hard time
getting feedback from Broadcom.

If you fancy your luck, please try!

-- 
This space intentionally left blank.

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

[Per Olofsson]

Package: wnpp
Severity: normal

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

The package description is:
 Ion, based on PWM, is an unusual window manager with no overlapping
 windows. Windows are placed in tabbed frames which may be arbitrarily
 split to create additional frames, making keyboard navigation much
 easier. Flexible configuration is possible thanks to Lua, which is
 used as the configuration language.
 .
 There is also support for so-called "floating workspaces" where
 windows are managed the conventional way, so that you can still run
 applications which do not fit very well into Ion's window management
 approach. A pwm2 binary is included which starts Ion with floating
 workspaces as the default, thus replacing the now obsolete PWM window
 manager.

-- 
Pelle

Bug#276228: RFH: pcmcia-cs -- PCMCIA Card Services for Linux

[Per Olofsson]

Package: wnpp
Severity: normal

I currently don't have the time and energy to maintain this package
properly, so I hereby request co-maintainer(s) for it. There are
currently no RC bugs in it and I will probably fix them if they arise,
but there are other things to do like updating to the latest upstream
version (although not for sarge). The package has an Alioth project
with a Subversion repository so it should be fairly easy to cooperate,
and I will also be available to discuss things by email.

The PCMCIA support in debian-installer could also use some
improvement.

-- 
Pelle

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

[Thomas Hood]

On Tue, 12 Oct 2004 14:30:14 +0200, Robert Collins wrote:
> Thats quite different - I'd love for this to be consolidated and
> addressed though.


The experimental version of ifupdown addresses this to some extent.  The
if-up.d scripts are run only after the PPP interface is created.

-- 
Thomas Hood

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

[Thomas Hood]

On Oct 11, Joerg Sommer <[EMAIL PROTECTED]> wrote:
> why ppp provides its own mechanism of telling programs when the
> interface is coming up or down? Many programs register for the ppp
> mechanism, but not for the network mechanism. Where is the difference


The reason there continues to be a need for /etc/ppp/ip-(up|down).d/ is
that ifupdown has never handled ppp interfaces properly.  ifup runs
/etc/network/if-up.d/ scripts immediately after starting pppd; what it
should do is wait for the PPP link to be established before running
hook scripts.  This shortcoming is addressed in the experimental
version of ifupdown.

-- 
Thomas Hood

Re: about volatile.d.o/n

[Sven Mueller]

paddy [u] wrote on 12/10/2004 18:14:
If you put it that way, I have to agree with you. However, I would make 
one restriction:
- packages in volatile have to keep their commandline (both input and
 output) interfaces compatible, 
would that be 'have to' as in 'MUST'?
Yes.
define compatible.
Not really a good definition, but explains what I have in mind:
If package A is updated, for it to still keep compatibility, the 
following needs to be fulfilled:

Any pre-existing piece of software (let's call it X) which interfaces 
with A must stay fully functional. New features may be added to A and 
might not be available via the original interface, but any feature 
previously available must still work in the same way (less bugs being 
fixed). This also means that spelling mistakes in the C locale must be 
preserved (they may get fixed in other locales though, including en_US) 
as well as any (possibly even weird) output formatting.

That last sentence also implies that any script using the commandline 
interface of A must reset LC_ALL and LANG to "C" or unset it. Otherwise 
the output format and wording might change from one revision to the 
other. This is good practise anyway, since you couldn't rely on a 
specific output formatting or wording without specifically setting a 
well-known locale.

 but may change C/Python/Perl
 interfaces if no unresolved incompatibility in the whole of Debian is
 created that way. 
Yeah I've never liked those C/Python/Perl people either, 
not enough soldering irons! ;)
 It wasn't meant that way. But I think that locally written 
scripts shouldn't directly use the Perl module API (as in 
Mail::SpamAssassin for example) but use the commandline interface instead.

 However, as far as possible, 
what is the basis for the trade-off.
You mean where I would draw the line for that? I would want to decide 
that case-by-case. If the change to the API is minimal and the work for 
avoiding it is tremendous (or other reasons make it important to 
incorporate that change), it seems wise to allow it in.

they _should_ also keep those compatible.
so that's just a bug then?
??? You mean the incompatibility? Suppose so.
Another reason for exception is an 
addition to the interface (as little interfering as possible) to allow 
scanning for and reporting of new security holes or viruses (for 
security/virus scanners).
This is part of the definition of compatible?
In a way, yes. see explanation above. The addition should interfere with 
existing interfaces as little as possible.

If one wishes to make guarantees about APIs then it might be good to
identify the APIs.  It is surprising how much people's opinions can vary 
in the edge-cases, and too much hand-waving is bad for the circulation.
(okay, so I made the last part up).
;-)
API is an application programming interface. So it is not interfering 
with scripting interfaces (aka commandline interfaces) ;-)
Actually I think that any machine readable input/output of a program (at 
least when called with the C locale selected) is regarded by many people 
as an API. I don't think so, but I think it should be handled in a 
similar way, but with rules a (very) little less strict.

Sven, you're clearly having a good crack at that here.
Sounds like a compliment to me. thanks. :-)
OK, I would like to see it implemented approx. like this (names subject 
to change):
- volatile.d.o: security and virus scanners, anti-spam software and
   similarly fast moving software needed mostly on servers
- backports.d.o: New (versions of) user interface software (new KDE, new
Mozilla and the like)
Both might need security team support, which I would think is difficult 
for the later.
Depending on how big it is I imagine.  Certainly, when staying close to
upstream versions, one hopes to have a relatively easy time applying 
security fixes (or even just upgrading to the next version).
Yes, staying close to upstream makes it easier to backport their 
security fixes for certain. But depending on the release practise of 
upstream, it might not be advisable to always simply update to their 
newest version.

I'm inclined to think that packages like mozilla belong in stable or
backports, because I can't see why they _have_ to be volatile.  I don't
think being immature software would make a good criterion for entry.
Right.

Re: about volatile.d.o/n

[Sven Mueller]

Henning Makholm [u] wrote on 12/10/2004 15:46:
Scripsit Sven Mueller <[EMAIL PROTECTED]>
Henning Makholm [u] wrote on 11/10/2004 20:22:

[volatile.debian.org]

Security fixes should be handled by security.d.o.

Perhaps yes, perhaps no.
Security fixes *to* packages already in volatile is a grey area, yes.
No argument there
I thought I was talking about security fixes to stable packages
going in volatilie instead of security.d.o.
Certainly.
volatile should _not_ be just another security archive.
Security fixes to packages in stable should go to security.d.o as they 
used to.
Volatile might get updated due to the same security problem, but if so, 
then that would most likely be by an upgrade to a fixed upstream version 
instead of a backport of that specific security fix. _If_ the new 
upstream version is stable and doesn't break compatibility (in a way 
contradicted by volatile policy).

cu,
sven

Re: Common set of debconf templates

[Agustin Martin]

On Mon, Oct 11, 2004 at 12:59:01PM +0200, Brian Sutherland wrote:
> On Mon, Oct 11, 2004 at 07:36:40AM +0200, Christian Perrier wrote:
> > SHARED TEMPLATES
> >It's actually possible to have a template and a question that
> >are shared among a set of packages. All the packages have to
> >provide an identical copy of the template in their templates
> ^
> >files. This can be useful if a bunch of packages need to ask
> >the same question, and you only want to bother the user with it
> >once. Shared templates are generally put in the shared/
> >pseudo-directory in the debconf tem- plate namespace.
> 
> What happens when the template changes in the template package but is
> out of sync in the other packages?
> 

IIRC, last installed package wins and puts its version of the template into
the debconf database, even if it is not the most up-to-date. If there is a
package that has no translations at all for the shared question and is
installed after packages having plenty of translations, there will be no
translations at all for that shared question in the debconf database. 

Cheers,

-- 
Agustin

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

[Robert Collins]

On Tue, 2004-10-12 at 20:48 +0200, Thomas Hood wrote:
> On Tue, 12 Oct 2004 14:30:14 +0200, Robert Collins wrote:
> > Thats quite different - I'd love for this to be consolidated and
> > addressed though.
> 
> 
> The experimental version of ifupdown addresses this to some extent.  The
> if-up.d scripts are run only after the PPP interface is created.

Does it hook into ppp to handle persistent ppp connections? (i.e. adsl).

One way that occurs to me would be a script in the ppp ip-*.d dirs that
calls the ifupdown's ip-*.d matching dir.

Rob

-- 
GPG key available at: .


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

Re: about volatile.d.o/n

[Henning Makholm]

Scripsit paddy <[EMAIL PROTECTED]>
> On Tue, Oct 12, 2004 at 03:05:05PM +0100, Henning Makholm wrote:

> > But isn't volatile.d.o supposed to *be* the out-of-band mechanism
> > (whatever out-of-band means here)?

> No. clamav virus signatures, for example, can be maintained by a program,
> freshclam, that downloads database updates from upstream.

I know that, but as far as I under stande, the whole point of volatile
is to replace exactly that with a situation where each maintainer does
not have do program his own freshfoo system (and worry about finding a
location to download from that is known in advance to stay availbale
throughout the entire lifetime of the next stable release).

> > I don't see how that means that there "wouldn't be a need" for rule
> > updates.

> See above.  The consensus seems to be that it would be undesirable to 
> even try to push this data through the regular package-management channel.

Whose consensus is this? The debian-devel feed that reaches me shows
quite enthusiastic support for pushing rule updates through an aptable
repository.

> > And in any case the point is that I want to run a *stable* box. I
> > am not keeping consciously track with upstream changes to
> > "background" software like spam filters, so I didn't *know* that a
> > 3.0 version was about to happen. A user of stable should be *able*
> > to remain ignorant about such chages.

> Ah, but you weren't just a user of stable were you?  
> You'd drunk from the forbidden waters of unstable! :)

Because volatile does not currently exist.

> > The point is to get improved *classification* without changing the
> > *interfaces*.

> For me the point is to achieve function.

Function may disappear totally if the update makes things break.

> > If upgrading will break existing interfaces, then "when" means "after
> > the current testing freezes and is released as stable".

> Yes, for stable.  Do we want 'just another stable' ?

No, we want a way to push non-breaking data updates to stable users in
a controlled way. They'll still be stable users, so they still want
freedom from gratuitous breaking.

> If you s/mozilla/spamassassin/ I might want to argue the point.

Well, I don't want to se an update to spamassassin in volatile if it
breaks APIs that my scripts use. Raising spam detection rates from 97%
to 98% is useless if the update makes my mail system go catatonic and
deliver all incoming mail, spam or not, to /dev/null. I run stable on
my mail server because I *don't* want random breakage, and if not
having any random breakage means that I'll have do delete a bit more
of my spam by hand, then so be it.

If I wanted random breakage, I'd run testing on the server. But I don't.

> Why are we talking about mozilla?

I don't know. You seem to have some kind of point about it, but I
still cannot fathom what it is.

-- 
Henning Makholm "Occam was a medieval old fart. The simplest
 explanation that fits the facts is always, God did it."

Re: Next reboot script execution framework

[Jérôme Warnier]

Le dim 03/10/2004 à 19:26, David Goodenough a écrit :
> On Sunday 03 October 2004 16:54, Jérôme Warnier wrote:
> > Is there a framework for executing once a script at next reboot in
> > Debian (Sarge|Sid)? Any idea of a "clean" way to do it?
> >
> > Thanks
> 
> One comment, it is rather "Not the Linux Way(TM)" to expect
> reboots.  Only things like changing the kernel should need a
> reboot.
Well, let me explain then:
I'm working on a customized Debian distro, and on a replication engine
(Replicator) for machines. I would like some things to happen next time
the machine is powered on, because the people who install it would like
to have to wait the less possible.
I imagined that we would finish the installation (probably unattended)
and the system would reboot at the end (because 1/ there *is* probably a
newer kernel, and for whatever reason, 2/ GDM does not start
automatically after being installed).
I would like the system to do things in the background at next reboot,
like running prelink, scrollkeeper-rebuilddb, updatedb, ...
You get the idea...

> David
-- 
Jérôme Warnier
Consultant
BeezNest
http://beeznest.net

Re: about volatile.d.o/n

[Matthias Urlichs]

Hi, Christoph Berg wrote:

> Re: Henning Makholm in <[EMAIL PROTECTED]>
>> > Some things are not so obvious:
>> 
>> Should volatile include updates of packages such as debian-keyring?
>> debian-policy and developers-reference?
> 
> Those who need these packages will run Sid anyway.

I hope I'll be able not to do that, for a while at least.

... well, except for the fact that I'm already a happy user of
spamassassin 3 ...

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]

Re: Next reboot script execution framework

[Erik Steffl]

Jérôme Warnier wrote:
Le dim 03/10/2004 à 19:26, David Goodenough a écrit :
On Sunday 03 October 2004 16:54, Jérôme Warnier wrote:
Is there a framework for executing once a script at next reboot in
Debian (Sarge|Sid)? Any idea of a "clean" way to do it?
Thanks
One comment, it is rather "Not the Linux Way(TM)" to expect
reboots.  Only things like changing the kernel should need a
reboot.
Well, let me explain then:
I'm working on a customized Debian distro, and on a replication engine
(Replicator) for machines. I would like some things to happen next time
the machine is powered on, because the people who install it would like
to have to wait the less possible.
I imagined that we would finish the installation (probably unattended)
and the system would reboot at the end (because 1/ there *is* probably a
newer kernel, and for whatever reason, 2/ GDM does not start
automatically after being installed).
I would like the system to do things in the background at next reboot,
like running prelink, scrollkeeper-rebuilddb, updatedb, ...
You get the idea...
  no.
  if there is a new kernel then reboot is neccessary.
  the services can be simply started. Rebooting machine because you 
need to start gdm is weird to the extreme. I mean do you reboot your 
machine to start vi? grep? ls?

erik

Re: about volatile.d.o/n

[Thomas Bushnell BSG]

Sven Mueller <[EMAIL PROTECTED]> writes:

> Any pre-existing piece of software (let's call it X) which interfaces
> with A must stay fully functional. New features may be added to A and
> might not be available via the original interface, but any feature
> previously available must still work in the same way (less bugs being
> fixed). This also means that spelling mistakes in the C locale must be
> preserved (they may get fixed in other locales though, including
> en_US) as well as any (possibly even weird) output formatting.
> 
> That last sentence also implies that any script using the commandline
> interface of A must reset LC_ALL and LANG to "C" or unset
> it. Otherwise the output format and wording might change from one
> revision to the other. This is good practise anyway, since you
> couldn't rely on a specific output formatting or wording without
> specifically setting a well-known locale.

No.  It must behave identically, regardless of locale.  Spelling fixes
in the interface *cannot* be part of what the new version needs in
order to remain useful.  This is just the kind of dogde that has been
worrying me about these proposals.

Thomas

Bug#276253: ITP: pmount -- mount removable devices as normal user

[Martin Pitt]

Package: wnpp
Severity: wishlist

  Package name: pmount
  Version : 0.2
  Upstream Author : Martin Pitt <[EMAIL PROTECTED]>
  URL : (currently in Ubuntu, will put it on
http://www.piware.de/projects.shtml soon)
  License : GPL
  Description : mount removable devices as normal user

 pmount ("policy mount") is a wrapper around the standard mount program which
 permits normal users to mount removable devices without a matching /etc/fstab
 entry. This provides a robust basis for automounting frameworks like GNOME's
 Utopia project and confines the amount of code that runs as root to a minimum.

-

Ubuntu currently uses pmount to mount removable devices instead of using the
fstab-update.sh approach of hal. This has three major advantages:

- It allows to run hal as a normal user instead of root and confines the amount
  of code that runs with root privileges to a minimum. pmount is very small,
  was programmed very carefully, and has been proofread by several people
  (including Matt Zimmerman).

- It avoids changing a central system configuration file and thus is more
  robust.

- It keeps hal policy free, the policy under which users can mount devices is
  determined and enforced by pmount.

Since Debian's utopia stack does not use pmount, I will not let pmount go into
Sarge. But I was asked to put it into sid soon for people to play with and for
other Custom distributions. Sjoerd Simons seems to be open to integrate pmount
into sarge+1's Utopia stack, too.

Have a nice day!

Martin

Bug#276255: ITP: python-libfuse -- Python bindings for FUSE (Filesystems in USErland)

[Sebastien Delafond]

Package: wnpp
Severity: wishlist


* Package name: python-libfuse
  Version : 1.3
  Upstream Author : Miklos Szeredi <[EMAIL PROTECTED]>
* URL : http://sourceforge.net/projects/avf
* License : GPL
  Description : Python bindings for FUSE (Filesystems in USErland)

This is a Python interface to FUSE.

FUSE (Filesystem in USErspace) is a simple interface for userspace
programs to export a virtual filesystem to the linux kernel.  FUSE
also aims to provide a secure method for non privileged users to
create and mount their own filesystem implementations.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.4.27-1-686-smp
Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15

Package idea, Debian-Firewall.

[nicklas (smurfd)]

Hey Debian-devels!

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

So tonight i took the time to create such a package.

What the package does, it creates a firewall script in
/etc/init.d/debian-firewall
looking like : 

#!/bin/bash

FW_VER=0.1

echo -e "\nLoading Debian Firewall[ $FW_VER ] ...\n"

IPTABLES=/sbin/iptables
DEPMOD=/sbin/depmod
INSMOD=/sbin/insmod

# Flush old rules, and set ACCEPT as default policy
$IPTABLES -P INPUT ACCEPT
$IPTABLES -F INPUT
$IPTABLES -P OUTPUT ACCEPT
$IPTABLES -F OUTPUT
$IPTABLES -P FORWARD DROP
$IPTABLES -F FORWARD

$IPTABLES -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT

(now it contains a ACCEPT ssh rule, just to show that its run, yes it does 
flush your old firewall, sorry about that)

the postinst file looks like : 

#!/bin/sh
set -e
if [ "$1" = "configure" ]; then
ln -s /etc/init.d/debian-firewall /etc/rc0.d/S20debian-firewall
ln -s /etc/init.d/debian-firewall /etc/rc1.d/S20debian-firewall
ln -s /etc/init.d/debian-firewall /etc/rc2.d/S20debian-firewall
ln -s /etc/init.d/debian-firewall /etc/rc3.d/S20debian-firewall
ln -s /etc/init.d/debian-firewall /etc/rc4.d/S20debian-firewall
ln -s /etc/init.d/debian-firewall /etc/rc5.d/S20debian-firewall
ln -s /etc/init.d/debian-firewall /etc/rc6.d/S20debian-firewall
fi


and the prerm file looks like : 

#!/bin/sh
set -e
if [ "$1" = "remove" ]; then
rm /etc/rc0.d/S20debian-firewall
rm /etc/rc1.d/S20debian-firewall
rm /etc/rc2.d/S20debian-firewall
rm /etc/rc3.d/S20debian-firewall
rm /etc/rc4.d/S20debian-firewall
rm /etc/rc5.d/S20debian-firewall
rm /etc/rc6.d/S20debian-firewall

echo "Leaving firewall script in /etc/init.d/debian-firewall.backup."
cp /etc/init.d/debian-firewall /etc/init.d/debian-firewall.backup
fi
(it saves a backup of it before removing it)


looks good? Only problem though, is that im not a debiandeveloper. Have had 
thoughts about it, but never got around
to drag myself to a keysigning party, basicly because they are somewhat far 
away from me.

Anyway, feel like you want to try it : 
http://smurfnet.homelinux.net/files/debian-firewall_0.1-1_all.deb

btw im not a subscriber to debian-devel AT lists dot debian dot org, so if you 
have anything to add/ask mail me at this mailaddress:
smurfd AT smurfnet dot homelinux dot org

best regards
/Nicklas

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

[Mike Mestnik]

--- Arnt Karlsen <[EMAIL PROTECTED]> wrote:

> On Tue, 12 Oct 2004 11:41:25 -0700 (PDT), Mike wrote in message 
> <[EMAIL PROTECTED]>:
> > 
> > --- [EMAIL PROTECTED] wrote:
> > 
> > > I note that back in Jan 2003, someone had the same problem but got
> > > no response on the debian-user mailing list. 
> > > 
> > It's good too see that this list is functioning and there are ppl
> > around to answer questions.  As for the debian-user list I don't have
> > enuff time to listen in for network related questions and direct them
> > to here.  I hope that some/any one would be kind enuff todo so and
> > encourage other to take the time todo so, when time is avalible.
> > 
> > Dito for debian-devel and any other list.
>  
> ..how about sponsorships?  You can easily spend a 16 hour working day
> at d-u to keep up with it, and face it, _somebody_ has to pay for all
> that time.  As I write this, I have 30470 unread of 67172 since joining
> d-u in August last year until wisening up the same way Lawrence Lessig
> did in January this year, bills to pay and Groklaw.net, FlightGear.org
> and IPCop.org.
> 
How about breaking up the list in to several smaller lists, like
debian-fierwall.  For today the names like debian-user1 and debian-user2
could be used to provide at least some level of maintanable/readable
material.  I don't know how many mails a day the d-u lists gets, but I'm
guessing more then 16 a day is too many.

> -- 
> ..med vennlig hilsen = with Kind Regards from Arnt... ;-)
> ...with a number of polar bear hunters in his ancestry...
>   Scenarios always come in sets of three: 
>   best case, worst case, and just in case.
> 
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact
> [EMAIL PROTECTED]
> 
> 




__
Do you Yahoo!?
Y! Messenger - Communicate in real time. Download now. 
http://messenger.yahoo.com

Re: about volatile.d.o/n

[Joey Hess]

Daniel Burrows wrote:
>   I generally have to resort to backports or unstable when installing Debian 
> on recent hardware, because we don't update hardware drivers in stable.  
> Would the kernel and X be candidates for volatile?

Let me throw something else into the discussion here. With the new installer
I expect we'll be able to produce significantly improves versions of the
installer after sarge is released, that include things like kernel
updates and other new features, and still support installing sarge (in
addition to etch). The problem is that although they may install using a
newer kernel, they have to get kernel packages to install from some apt
repository. If that turns out to be volatile, so be it, if not we'll
probably at least set up a backports style repository for such kernel
images.

-- 
see shy jo


signature.asc
Description: Digital signature

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

[David Palmer]

Mike Mestnik wrote:
 --- Arnt Karlsen <[EMAIL PROTECTED]> wrote:
 How about breaking up the list in to several smaller lists, like
 debian-fierwall.
Already exists, but is under used.
I think that many post 'wall questions to d-u because of the higher 
population, and therefore the greater potential for an applicable answer.
I think that if all firewall questions were to be transferred to 
debian-firewall that would not remain the case though, and the potential 
for this specialised list would grow to potential.

 For today the names like debian-user1 and debian-user2 could be used
 to provide at least some level of maintanable/readable material. I
 don't know how many mails a day the d-u lists gets, but I'm guessing
 more then 16 a day is too many.
I would suggest the creation of only one other list, and this would be 
for system/network admin.
This would create a list to cater for the more professional end of the 
market, while still maintaining d-u as an end user list, that a lot of 
admins would still employ.
With these two lists realised I think that the high volume of d-u would 
be brought back to manageable levels, increasing list user satisfaction 
as they would cater more efficiently to requirement.
I don't belive that any more disc space would be taken up, as the admin 
crowd are already active on d-u.
it would simply make d-u more manageable and specific itself.
Regards,

David.