Re: Sun Java available from non-free

[Wouter Verhelst]

On Mon, May 22, 2006 at 08:47:52AM -0700, Mike Bird wrote:
> On Monday 22 May 2006 06:56, Wouter Verhelst wrote:
> > On Mon, May 22, 2006 at 01:47:01PM +0200, Romain Beauxis wrote:
> > > On Monday 22 May 2006 13:35, you wrote:
> > > > Try as I might, and considering how lawyers and judges are human beings
> > > > and not automatons, I can't see any realistic scenario in which we
> > > > could be sued and lose a case in relation to this license. Do you?
> > >
> > > While I understand your argument about Sun asking for this, and even
> > > found it serious, please do not argue the judges are human being after
> > > all... Judges aply law, and that what they are meant for.
> >
> > Sure. They are, however, supposed to apply some common sense in doing
> > so, rather than acting like an automaton.
> 
> Sun says Java distributors indemnify Sun.  Debian does not have to
> distribute Java.  Let us suppose - hypothetically - that Debian rashly
> decides to distribute Java.
> 
> A supertanker runs aground, discharges a million gallons of crude oil,
[crazy scenario involving Debian laptop with Java applet]

The risk you're describing is crazy, and very unlikely of actually
occurring.

Ignoring that, even if it were to occur, who's to say the people who
would want to sue Sun in your scenario wouldn't want to sue Debian, too,
while the're at it? After all, the laptop _is_ running Debian. I suspect
the fact that there is a java weather applet running isn't even remotely
relevant to such nutcases.

I don't think the chance of "nutcase sueing Sun for Bad Applet" is any
more relevant or likely than the chance of "nutcase sueing Debian for
bad browser". I really don't see how it makes the license problematic.

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


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

Re: Unidentified subject!

[Hex Star]

On 5/22/06, Matthew R. Dempsky <[EMAIL PROTECTED]> wrote:
On Sun, May 21, 2006 at 10:00:43PM -0700, Hex Star wrote:> Hmmm...interesting...the other time someone posted something explicit and> someone replied to it and pointed it out, everyone joined in and> investigated it...this time the person who points it out gets
> criticized...go figure...I always get the short end of the stick...Perhaps because your past mailing list behavior is not well regarded.What? What did I do to deserve that? :-( ...btw the past incident I
have referred to is:
http://lists.debian.org/debian-user/2006/04/msg04040.html

Re: Sun Java available from non-free

[Mike Bird]

On Monday 22 May 2006 16:52, Wouter Verhelst wrote:
> I don't think the chance of "nutcase sueing Sun for Bad Applet" is any
> more relevant or likely than the chance of "nutcase sueing Debian for
> bad browser". I really don't see how it makes the license problematic.

And that is why, in legal matters, Debian needs the combined expertise of
the volunteer lawyers on debian-legal, rather than the "legal opinion" of
a programmer.  Fair's fair.  I wouldn't trust most attorneys to fix a device
driver.

--Mike Bird


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

Re: Making init scripts use dash

[Felipe Sateler]

gregor herrmann wrote:
> IIRC lintian does this already.
And devscripts contains a 'checkbashishms' tool
-- 

Felipe Sateler


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

Bug#368551: ITP: xml-security-c -- C++ library for XML Digital Signatures

[Russ Allbery]

Package: wnpp
Severity: wishlist
Owner: Russ Allbery <[EMAIL PROTECTED]>


* Package name: xml-security-c
  Version : 1.2.1
  Upstream Author : The Apache Software Foundation
* URL : http://xml.apache.org/security/
* License : Apache 2.0
  Programming Lang: C++
  Description : C++ library for XML Digital Signatures

 XML-Security-C is a library for the XML Digital Security specification.
 It provides processing and handling of XML Key Management Specifications
 (XKMS) messages together with a command line client for performing XKMS
 requests and reading/dumping XKMS messages.

This library is a prerequisite for Shibboleth, which we're currently
working on packaging.

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-1-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


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

Re: alternatives and priorities

[Maximiliano Curia]

On Sunday 21 May 2006 16:31, Wouter Verhelst wrote:
> > You would end up with nvi or nano as editors, since they are installed by
> > default. Probably more as viewer and so on.

> Which is bad why?

What I meant was that you would have a high number of installations for the 
packages that are installed by default in a normal installation, and that is 
not an objective way of getting information.




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

Bug#368553: ITP: libparallel-forkmanager-perl -- A simple parallel processing fork manager for Perl

[John Lightsey]

Package: wnpp
Severity: wishlist
Owner: John Lightsey <[EMAIL PROTECTED]>

* Package name: libparallel-forkmanager-perl
  Version : 0.7.5
  Upstream Author : Szabó, Balázs <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/~dlux/Parallel-ForkManager-0.7.5/
* License : Perl (GPL/Artistic)
  Description : A simple parallel processing fork manager for Perl

 This Perl module is intended for use in operations that can be done in
 parallel where the number of processes to be forked off should be limited.
 Typical use is a downloader which will be retrieving hundreds/thousands
 of files.
 .
 Homepage: http://search.cpan.org/~dlux/Parallel-ForkManager-0.7.5/

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.12-1-686
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Re: Sun Java available from non-free

[Russ Allbery]

Martijn van Oosterhout <[EMAIL PROTECTED]> writes:

> Well, IANAL, but as far as I can see, as long as Sun has a valid reason
> to change their mind and is willing to compensate any losses caused by
> them changing their mind, they can do whatever they like.

Well, but *that* I don't think is a worry.  Sun changes their mind, we
take the software out of non-free again, oh well.  Just like if they
change the license down the road.

The worry is over whether we get sued.  If they might just make us take
the software out of the archive again, oh well.  Like Steve says, I think
that's a risk for quite a lot of stuff in non-free, and is one of the
(many) reasons why the amount of support Debian offers for non-free is
extremely limited.

*Because* this is non-free, I think the situation is very, very different
than it would be for main, and in more ways than just what criteria are
applied to judging the license.  For example, I personally don't think
that Debian makes as strong of an ongoing committment to support something
by including it in non-free; simply removing it in the case of problems is
more of a viable option.  (This may be an opinion that's idiosyncratic to
me, though.)

> A few possible problems are:

> - The promise was made without consideration (no symbolic one cent payment)
> - The promise was not formally notarised. A press notice may not count.
> - It wouldn't damage Debian or anybody much to revoke the statement.

> They may not be able to recover damges for the period you relied on
> their statement, but nothing prevents them from stating the contrary.
> that's assume the promise is considered valid ofcourse.

One of the reasons why I'm curious about analoguous laws in other legal
systems is that, as I understand it, the "no consideration" bits aren't as
relevant to estoppel.  That's a factor in validity of contracts, but
estoppel is a separate principle.  Estoppel basically says that you can't
trap people by lying about your intentions and then suing them when they
rely on your promises.

> A comparison of estoppel between English, American and German. It
> refers to contracts however, we we don't have in this case:
> http://tldb.uni-koeln.de/php/pub_show_document.php?pubdocid=114700

Yeah, that page is about promissory estoppel, and what I'm talking about
is equitable estoppel.



equitable estoppel n. where a court will not grant a judgment or other
legal relief to a party who has not acted fairly; for example, by
having made false representations or concealing material facts from
the other party.  This illustrates the legal maxim: "he who seeks
equity, must do equity."  Example: Larry Landlord rents space to Dora
Dressmaker in his shopping center but falsely tells her a Sears store
will be a tenant and will draw customers to the project.  He does not
tell her a new freeway is going to divert traffic from the center.
When she failed to pay her rent due to lack of business, Landlord sues
her for breach of lease.  Dressmaker may claim he is equitably
estopped.

> Thie simplest solution in this case would be if Sun simply attached
> the FAQ as an addendum to the licence rather than stating it's not
> legally binding.

Yeah.  Not disagreeing there.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: alternatives and priorities

[Nick Phillips]

On Fri, May 19, 2006 at 03:46:28PM +0200, Wouter Verhelst wrote:

> That's not an issue. First, ed doesn't install an alternatives for
> "editor". Second, there's also 'by_vote', which puts vim on top.

Which is an excellent demonstration of "why we should not use popcon to
decide alternatives priorities".

nano is a more sensible default because it is usable by newbies and by
people who do not understand the concept of a modal editor.

Being popular is overrated...


Cheers,


Nick


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

Re: libdb transition policy?

[Florian Weimer]

* Nikita V. Youshchenko:

>> * Nikita V. Youshchenko:
>> > However, if I will build library against libdb4.4 instead of
>> > libdb4.2, this will probably break any binaries built against the
>> > library - both packaged and local.
>>
>> What kind of interface does libetpan expose?  Based on the package
>> description, I wouldn't expect the library to export any Berkeley DB
>> objects at all.
>
> Library internally uses libdb (to maintain mail cache, and probably
> for other things also), and is currently linked against libdb4.2. So
> the issue exists.

Berkeley DB uses symbol versioning, so I don't think changing the DB
version will affect the library ABI.

You need to devise a procedure for upgrading the database
environments, of course.  But this is completely separate from soname
issues.


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

Re: libdb transition policy?

[Nikita V. Youshchenko]

> * Nikita V. Youshchenko:
> > However, if I will build library against libdb4.4 instead of
> > libdb4.2, this will probably break any binaries built against the
> > library - both packaged and local.
>
> What kind of interface does libetpan expose?  Based on the package
> description, I wouldn't expect the library to export any Berkeley DB
> objects at all.

Library internally uses libdb (to maintain mail cache, and probably for 
other things also), and is currently linked against libdb4.2. So the issue 
exists.


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

Re: Making init scripts use dash

[Gabor Gombas]

On Mon, May 22, 2006 at 01:55:54PM +, Jörg Sommer wrote:

> But what counts more in the comparison dash vs. bash is the shell
> startup. And the shell is started for every script not name foo.sh.

Also, if init scripts will be really parallel (meaning lots of
concurrent scripts, not just 2-3), then the smaller memory footprint of
dash may turn out to be even a bigger win than the sequential speed
difference. Some very basic tests using callgrind show that bash uses
20-30 times more CPU cache than dash. And when things are running
parallell, CPU cache is a very expensive thing to waste...

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


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

Re: Making init scripts use dash

[Gabor Gombas]

On Tue, May 23, 2006 at 01:19:44PM +0200, Gabor Gombas wrote:

> difference. Some very basic tests using callgrind show that bash uses
> 20-30 times more CPU cache than dash. And when things are running

Er, fat fingers. The difference is just 2-3 times.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


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

Re: alternatives and priorities

[Wouter Verhelst]

On Mon, May 22, 2006 at 10:42:26PM -0300, Maximiliano Curia wrote:
> On Sunday 21 May 2006 16:31, Wouter Verhelst wrote:
> > > You would end up with nvi or nano as editors, since they are installed by
> > > default. Probably more as viewer and so on.
> 
> > Which is bad why?
> 
> What I meant was that you would have a high number of installations for the 
> packages that are installed by default in a normal installation, and that is 
> not an objective way of getting information.

Again, this is why I didn't suggest to use the by_inst numbers, but
rather the by_vote numbers. The former count the number of
installations; the latter count the actual _use_ of a binary.

If you have nano installed on your system but never actually use it,
that won't move it up in the vote.

If you have a look at the order of the by_vote numbers for editors,
you'll see that vim, not nvi or nano, is at the top.

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


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

Re: use of "invoke-rc.d $PACKAGE stop || exit $?" in prerm scripts

[Frank Küster]

Florian Weimer <[EMAIL PROTECTED]> wrote:

> * Michael Prokop:
>
>> Using:
>>
>>   invoke-rc.d $PACKAGE stop || true
>>   /etc/init.d/$PACKAGE stop || true
>>
>> would be a replacement already used in some packages like for
>> example at, binfmt-support, dnsmasq, drbd0.7-utils, freeradius, hal,
>> scanlogd, sl-modem-daemon, snort.
>
> I suppose it would be preferable to fix the "stop" target of the init
> script top cope with the situation that the daemon has already been
> terminated.  The current situation (stopping a daemon manually before
> deinstallation makes it fail) is hardly acceptable.

I agree:  The only valid reason for a "stop" call to fail should be if
it is actually impossible to stop a running daemon.  In this case, I
think the package removal should indeed fail, because even if it just
hangs completely, it might recover and then just continue to accept
connections until the machine is rebooted.

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)

Re: alternatives and priorities

[Miles Bader]

Wouter Verhelst <[EMAIL PROTECTED]> writes:
> If you have a look at the order of the by_vote numbers for editors,
> you'll see that vim, not nvi or nano, is at the top.

A list like this only seems meaningful if the entries are fairly
consistent with each other.

For instance, if you have packages like:

PACKAGE NAMEUSE COUNT
  -
EDITOR-1123
EDITOR-2-VERSION-3  55
EDITOR-2-VERSION-3.149
EDITOR-2-VERSION-4  73

The package "EDITOR-1" is "more popular" than any other _package_, but
one could also fairly say that EDITOR-2 is actually more popular than
EDITOR-1 in general.  Which should be higher priority?

-Miles
-- 
Come now, if we were really planning to harm you, would we be waiting here,
 beside the path, in the very darkest part of the forest?


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

Re: Bug#368551: ITP: xml-security-c -- C++ library for XML Digital Signatures

[Guus Sliepen]

On Mon, May 22, 2006 at 05:28:07PM -0700, Russ Allbery wrote:

> * Package name: xml-security-c
>   Programming Lang: C++
>   Description : C++ library for XML Digital Signatures

If it is a C++ library, please name the package xml-security-c++. If
upstream names their tarballs xml-security-c, tell them to change that
as well.

-- 
Met vriendelijke groet / with kind regards,
Guus Sliepen <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: alternatives and priorities

[Wouter Verhelst]

On Tue, May 23, 2006 at 04:55:52PM +0900, Miles Bader wrote:
> Wouter Verhelst <[EMAIL PROTECTED]> writes:
> > If you have a look at the order of the by_vote numbers for editors,
> > you'll see that vim, not nvi or nano, is at the top.
> 
> A list like this only seems meaningful if the entries are fairly
> consistent with each other.
> 
> For instance, if you have packages like:
> 
> PACKAGE NAMEUSE COUNT
>   -
> EDITOR-1123
> EDITOR-2-VERSION-3  55
> EDITOR-2-VERSION-3.149
> EDITOR-2-VERSION-4  73
> 
> The package "EDITOR-1" is "more popular" than any other _package_, but
> one could also fairly say that EDITOR-2 is actually more popular than
> EDITOR-1 in general.  Which should be higher priority?

Good point.

I would say that all three should receive approximately the priority of
all three editors combined, but with version 4 slightly more than
version 3, and version 3 in turn slightly more than version 3.1

How's that sound?

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


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

libdb transition policy? (Was: Re: Bug#367853: libetpan: Please consider transitioning to libdb4.4)

[Nikita V. Youshchenko]

[CCing to -devel and to people who maintain packages that depend on 
libetpan]

> Package: libetpan
> Severity: wishlist
>
>
> Hi,
> currently several versions of the berkeley db libraries are used in the
> archive: libdb[4.2,4.3,4.4].
> Please consider upgrading to libdb4.4 in order to ship etch with fewer
> versions of this library.

Thank you for pointing this.

However, if I will build library against libdb4.4 instead of libdb4.2, this 
will probably break any binaries built against the library - both packaged 
and local.

Asking upstream to change soname is IMO not an option in this case because 
libdb transition is debian internal activity, and upstream has nothing to 
do with it.

So how to handle this? Change soname (making it different from upstream)?

Reading Library Packaging guide [1] could not point me to any particular 
solution.

Btw, I guess the same situation is with other packages also - maybe there 
is some policy around this particular transition?

Nikita

[1] http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html


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

libetpan 0.45-2 was built on m68k but not went to archive?

[Nikita V. Youshchenko]

Hello.

I just found that my package, libetpan, was not updated for m68k.
[1] states that it is out of date on m68k.
But [2] states that latest version was successfully built on m68k long ago 
- on Apr17.

What's going on? Whom to contact on this issue?

Nikita

[1] http://bjorn.haxx.se/debian/testing.pl?package=libetpan
[2] http://buildd.debian.org/build.php?arch=m68k&pkg=libetpan


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

Bug#368581: ITP: libdatetime-format-strptime-perl -- Parse and format strp and strf time patterns

[Krzysztof Krzyzaniak (eloy)]

Package: wnpp
Severity: wishlist
Owner: "Krzysztof Krzyzaniak (eloy)" <[EMAIL PROTECTED]>

* Package name: libdatetime-format-strptime-perl
  Version : 1.0601
  Upstream Author : Rick Measham <[EMAIL PROTECTED]>
* URL : 
http://search.cpan.org/CPAN/authors/id/R/RI/RICKM/DateTime-Format-Strptime-1.0700.tar.gz
* License : Perl: Artistic/GPL
  Programming Lang: Perl
  Description : Parse and format strp and strf time patterns

 DateTime::Format::Strptime implements most of strptime(3), the POSIX
 function that is the reverse of strftime(3), for DateTime. While strftime
 takes a DateTime and a pattern and returns a string, strptime takes
 a string and a pattern and returns the DateTime object
 associated.
 

 NOTE: this package is needed to upload new upstream version of
 libformvalidator-simple-perl

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-1-686
Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2)


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

Re: libdb transition policy?

[Florian Weimer]

* Nikita V. Youshchenko:

> However, if I will build library against libdb4.4 instead of
> libdb4.2, this will probably break any binaries built against the
> library - both packaged and local.

What kind of interface does libetpan expose?  Based on the package
description, I wouldn't expect the library to export any Berkeley DB
objects at all.


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

Re: use of "invoke-rc.d $PACKAGE stop || exit $?" in prerm scripts

[Michael Prokop]

* Bernd Schubert <[EMAIL PROTECTED]> wrote:

>> inside their prerm maintainer scripts. If stopping $PACKAGE through
>> invoke-rc.d/init-script fails, removing the package fails as well.

>> Using:

>>   invoke-rc.d $PACKAGE stop || true
>>   /etc/init.d/$PACKAGE stop || true

> We are using chroot environments (e.g. with sid) where no daemon is running
> and invoke-rc.d will only do an "exit 0" in those chroots.

How do you achieve that? For example symlinking invoke-rc.d to
/bin/true is a workaround, but I'm searching for a general solution
to avoid that daemons are started when upgrading even though they
did not run before the upgrade (or don't start any service at all,
e.g. in chroots - as you mentioned).

> Using the method above, wouldn't there be any chance that a bad
> init script could kill daemons started outside the chroot?

The init script would be broken then.
Anyway, I don't see the difference between "stop || exit $?" and
"stop || true" in this case.

-mika-


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

Re: Making init scripts use dash

[Gabor Gombas]

On Sat, May 20, 2006 at 01:58:14AM +0200, Adam Borowski wrote:

> The interesting fact is that, contrary to what I expected, running
> "configure" was improved by only about 1% on average.

That may come from the fact that "configure" uses only the most basic
shell constructs (it does not even use functions). Also, depending on
the actual tests, 1/4-1/3 of "configure"'s run time is spent in the
waitpid() system call, independent of the shell.

> Thus, it's bash's start-up which is the slow part, in the terms of
> actual speed, bash is not that far behind.

It would be interesting to compare something more complex than "configure"
scripts. "configure" scripts are huge but primitive.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


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

Re: use of "invoke-rc.d $PACKAGE stop || exit $?" in prerm scripts

[Bernd Schubert]

Michael Prokop wrote:

> * Bernd Schubert <[EMAIL PROTECTED]> wrote:
> 
>>> inside their prerm maintainer scripts. If stopping $PACKAGE through
>>> invoke-rc.d/init-script fails, removing the package fails as well.
> 
>>> Using:
> 
>>>   invoke-rc.d $PACKAGE stop || true
>>>   /etc/init.d/$PACKAGE stop || true
> 
>> We are using chroot environments (e.g. with sid) where no daemon is
>> running and invoke-rc.d will only do an "exit 0" in those chroots.
> 
> How do you achieve that? For example symlinking invoke-rc.d to
> /bin/true is a workaround, but I'm searching for a general solution
> to avoid that daemons are started when upgrading even though they
> did not run before the upgrade (or don't start any service at all,
> e.g. in chroots - as you mentioned).

Via /usr/sbin/policy-rc.d, e.g.:

#!/bin/sh

# are we on hamilton?
WHERE=$(hostname -s|cut -b 1-8) # cut to remove {1,2} from hamilton{1,2}
if [ "$WHERE" = "hamilton" ]; then
# notify invoke-rc.d that nothing should be done -- we are in a chroot
exit 101
else
# allow it
exit 0
fi

(This chroot is used on the clients as their root environment)

> 
>> Using the method above, wouldn't there be any chance that a bad
>> init script could kill daemons started outside the chroot?
> 
> The init script would be broken then.
> Anyway, I don't see the difference between "stop || exit $?" and
> "stop || true" in this case.

What I mean is that the call of 

invoke-rc.d $PACKAGE stop || true

is fine, but the second call

/etc/init.d/$PACKAGE stop || true

will not using policy-rc.d and therefore might be a possible problem. Given
the fact that we have a sid chroot on a high availibilty system and a sid
package always might cause some trouble, I don't like the idea that a
malformed script is able to stop programs outside its chroot. 


Cheers,
Bernd


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

Re: Changing the default syslogd (again...)

[Petter Reinholdtsen]

[Nathanael Nerode]
> Conclusion
> --
> We should change the default syslogd.

There is only one feature I miss in the current sysklogd package, and
that is the ability to store the facility and severity in the log
file.  If we are to switch, please select one where this is possible
to enable.

Friendly,
-- 
Petter Reinholdtsen


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

Re: alternatives and priorities

[Petter Reinholdtsen]

[George Danchev]
> or some hosts have popularity-contest installed from pure upstream sources 
> instead from a popularity-contest debian package, thus don't have it 
> registered with the dpkg db.

That would seriously surprise me, as popularity-contest only is
distributed as a Debian package, and the Debian maintainers are also
upstream. :)


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

Re: use of "invoke-rc.d $PACKAGE stop || exit $?" in prerm scripts

[Henrique de Moraes Holschuh]

On Tue, 23 May 2006, Florian Weimer wrote:
> I suppose it would be preferable to fix the "stop" target of the init

There is nothing preferable about it.  Stop targets *are* to exit with
status 0 if the service is already stopped.

The fact that Debian policy still has this as a "should" clause is just
cruft that needs to be addressed.  There are absolutely no acceptable
exceptions to either this rule (stopping a stopped service is okay) nor to
its counterpart (starting an already started service is okay), as far as I
know.

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


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

Re: Bug#368551: ITP: xml-security-c -- C++ library for XML Digital Signatures

[Russ Allbery]

Guus Sliepen <[EMAIL PROTECTED]> writes:
> On Mon, May 22, 2006 at 05:28:07PM -0700, Russ Allbery wrote:

>> * Package name: xml-security-c
>>   Programming Lang: C++
>>   Description : C++ library for XML Digital Signatures

> If it is a C++ library, please name the package xml-security-c++. If
> upstream names their tarballs xml-security-c, tell them to change that
> as well.

I'd really rather stick with the upstream name, particularly since this is
a library package and the library is also called libxml-security-c.  Other
applications depend on this library and, when they do, their documentation
says to install XML-Security-C; I think calling it C++ instead would
confuse people.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: use of "invoke-rc.d $PACKAGE stop || exit $?" in prerm scripts

[Francesco P. Lovergine]

On Tue, May 23, 2006 at 09:46:10AM +0200, Frank Küster wrote:
> Florian Weimer <[EMAIL PROTECTED]> wrote:
> 
> > * Michael Prokop:
> >
> >> Using:
> >>
> >>   invoke-rc.d $PACKAGE stop || true
> >>   /etc/init.d/$PACKAGE stop || true
> >>
> >> would be a replacement already used in some packages like for
> >> example at, binfmt-support, dnsmasq, drbd0.7-utils, freeradius, hal,
> >> scanlogd, sl-modem-daemon, snort.
> >
> > I suppose it would be preferable to fix the "stop" target of the init
> > script top cope with the situation that the daemon has already been
> > terminated.  The current situation (stopping a daemon manually before
> > deinstallation makes it fail) is hardly acceptable.
> 
> I agree:  The only valid reason for a "stop" call to fail should be if
> it is actually impossible to stop a running daemon.  In this case, I
> think the package removal should indeed fail, because even if it just
> hangs completely, it might recover and then just continue to accept
> connections until the machine is rebooted.
> 

Unfortunately sometimes the daemon does not stop for an error in the
maintainer script and that prevents upgrading for ever, even when
the package has been corrected. BTW, it seems a lack in the policy
to specify how the maintainers scripts should work on stop (i.e. what
returning as exit code when stop does not work for secondary reasons)

-- 
Francesco P. Lovergine


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

Re: Packages violating policy 8.2

[Goswin von Brederlow]

Manoj Srivastava <[EMAIL PROTECTED]> writes:

> On 22 May 2006, Goswin von Brederlow stated:
>
>> Manoj Srivastava <[EMAIL PROTECTED]> writes:
>>
>>> On 22 May 2006, Goswin von Brederlow outgrape:
 I think that Policy 8.2 is fully applicable to your package
 then. It is a MUST directive so your unwillingness to allow
 multiple versions of your library to coexist does not affect the
 violation.
>>>
>>> I beg to differ. There is a rationale for the policy section:
>>
>> And if it where optional then it would read SHOULD. Or what is the
>> difference between MUST and SHOULD if you can jsut choose to ignore
>> both?
>
> The section in question is about shared library packages, but
>  I am not actually creating a shared library package. Perhaps this
>  needs clarification in policy.

To me it sounds like you are. You provide a shared object file in a public
place so other people can link their binaries against it. What else is
a shared library? Does it matter if no package in Debian uses it but
only other people? I think not. If you intention is to let others link
against it then it is a shared library by all means.

On a version upgrade the people that have their binaries linked
against your lib will be unable to upgarde without removing those
binaries first. The will have to work without them or with a chroot to
even recompile for the new lib. Think about that.

 Following 8.2 you only have 2 choices: Split the package or
 provide only static libaries and live with the wasted
 space. Otherwise the packages is RC buggy.
>>>
>>> May I ask what is the underlying rationale for this judgement?
>>
>> My motivation is that not following 8.2 will make it impossible to
>> convert the package to multiarch. For the rational of 8.2 itself you
>> have to read policy and ask the people who wrote it. But I think it
>> is pretty clear from the text: to be able to install multiple
>> versions of the library for smooth upgrades.
>
> That person could well have been me, though I can't say I
>  recall writing that.  But the intent of the section is for shared
>  library packages, and  as such setools is not a shared library
>  package.

If you say those libraries are not public then policy 10.2 would seem
to apply:

Policy 10.2:

| Shared object files (often .so files) that are not public libraries,
| that is, they are not meant to be linked to by third party executables
| (binaries of other packages), should be installed in subdirectories of
| the /usr/lib directory. Such files are exempt from the rules that
| govern ordinary shared libraries, except that they must not be
| installed executable and should be stripped.

Since you want to support linking by third party executables you don't
quite fit the description of not public library. But well, lets keep
one eye closed. Reading on you are violating a SHOULD directive.

I agree that binary packages with *.so.* files can well fall under
10.2. Do you think your package fully does?

> I'll be happy to discuss what I need to do about multi-arch.
>
>>> In what way do you think splitting the package would work? Why is
>
>> The same way it works for each and every other library package that
>> is split in Debian.
>
> But I have no intention of supporting multiple versions of the
>  libraries for setools, like I do for my other shared library packages
>  which are indeed split up.
>
>>> facilitating private packages for people who are working with
>>> SELinux a bad thing, when people who actually build and use these
>>> packages are aware of the current state of flux of SELinux?
>>
>> It isn't a bad thing but you aren't doing it "right" (right as laid
>> out in policy).
>
> Policy is not all infallible, not does it always apply. I
>  think packages shipping libraries with relocatable code which
>  explicitly do not support backwards compatibility nor multiple
>  versions for the library in question, and do not split out library or
>  -dev packages, are not covered by the rules designed for shared
>  library packages.
>
> manoj

It might be that that distinction is just missing from policy. So far
it only has the two options: public shared library and not public
library. Imho any third party linking against the library would mean
it has to be (made) public.

Feel free to draft a clarification to policy but I think 8.2 and 10.2
do cover all cases well enough.

MfG
Goswin


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

Re: use of "invoke-rc.d $PACKAGE stop || exit $?" in prerm scripts

[Henrique de Moraes Holschuh]

On Tue, 23 May 2006, Francesco P. Lovergine wrote:
> Unfortunately sometimes the daemon does not stop for an error in the
> maintainer script and that prevents upgrading for ever, even when
> the package has been corrected. BTW, it seems a lack in the policy
> to specify how the maintainers scripts should work on stop (i.e. what
> returning as exit code when stop does not work for secondary reasons)

It is a case-by-case thing, I suppose.  If the service cannot be completely
stopped, the initscript *must* return a failure status.  If, for your
particular package, that is not critical at all, then yes, you should be
ignoring it.

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


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

Bug#368625: ITP: alleggl -- OpenGL extension for the Allegro gaming library

[Sam Hocevar (Debian packages)]

Package: wnpp
Severity: wishlist
Owner: "Sam Hocevar (Debian packages)" <[EMAIL PROTECTED]>


* Package name: alleggl
  Version : 0.4-RC4
  Upstream Author : Bertrand Coconnier, Elias Pschernig, George Foot,
Robert J Ohannessian
* URL : http://allegrogl.sourceforge.net/
* License : Unclear (no license in source code, SF page says "GPL,
zlib/libpng License"). Authors contacted for
clarification.
  Programming Lang: C
  Description : OpenGL extension for the Allegro gaming library

 This library adds accelerated 3D support to the Allegro library using
 OpenGL.
 .
 Allegro is a cross-platform library intended for use in computer
 games and other types of multimedia programming. It is used by many
 DOS games and can be used to port them easily to Linux.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (50, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


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

Processed: fix manual page name sections

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> clone 368383 -1
Bug#368383: dumb "manual page for..." NAME section on many man pages
Bug 368383 cloned as bug 368628.

> reassign -1 mailutils
Bug#368628: dumb "manual page for..." NAME section on many man pages
Bug reassigned from package `general' to `mailutils'.

> retitle -1 fix manual page name sections
Bug#368628: dumb "manual page for..." NAME section on many man pages
Changed Bug title.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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

Re: use of "invoke-rc.d $PACKAGE stop || exit $?" in prerm scripts

[Bernd Schubert]

> 
> inside their prerm maintainer scripts. If stopping $PACKAGE through
> invoke-rc.d/init-script fails, removing the package fails as well.
> 
> Using:
> 
>   invoke-rc.d $PACKAGE stop || true
>   /etc/init.d/$PACKAGE stop || true
> 

We are using chroot environments (e.g. with sid) where no daemon is running
and invoke-rc.d will only do an "exit 0" in those chroots. Using the method
above, wouldn't there be any chance that a bad init script could kill
daemons started outside the chroot?

Thanks,
Bernd


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

Processed: fix manual page name section: fribidi(1)

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> clone 368383 -1
Bug#368383: dumb "manual page for..." NAME section on many man pages
Bug 368383 cloned as bug 368632.

> reassign -1 libfribidi0
Bug#368632: dumb "manual page for..." NAME section on many man pages
Bug reassigned from package `general' to `libfribidi0'.

> retitle -1 fix manual page name section: fribidi(1)
Bug#368632: dumb "manual page for..." NAME section on many man pages
Changed Bug title.

> found -1 0.10.7-3
Bug#368632: fix manual page name section: fribidi(1)
Bug marked as found in version 0.10.7-3.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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

Re: Bug#368383: dumb "manual page for..." NAME section on many man pages

[Brendan O'Dea]

On Mon, May 22, 2006 at 10:29:16PM -0700, [EMAIL PROTECTED] wrote:
>Glad that you guys will take care of this, as it is way over my head.

It's not complex.  The problem manual pages have been generated with a
program [help2man] which interprets a program's --help output.

Unfortunately, it's not possible to reliably extract a short description
of the program from that output to use as the NAME section (this appears
in the whatis/apropos output)

The maintainer needs to add that data when generating the page either
with the --name option to help2man, or via a [name] section in an
include file.

I've cloned the bug for mailutils (dotlock), libfribidi0 (fribidi) and
recode.

Feel free to raise new bugs on other packages.

--bod


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

Processed: fix manual page name section: recode(1)

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> clone 368383 -1
Bug#368383: dumb "manual page for..." NAME section on many man pages
Bug 368383 cloned as bug 368634.

> reassign -1 recode
Bug#368634: dumb "manual page for..." NAME section on many man pages
Bug reassigned from package `general' to `recode'.

> retitle -1 fix manual page name section: recode(1)
Bug#368634: dumb "manual page for..." NAME section on many man pages
Changed Bug title.

> found -1 3.6-12
Bug#368634: fix manual page name section: recode(1)
Bug marked as found in version 3.6-12.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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

Re: libdb transition policy? (Was: Re: Bug#367853: libetpan: Please consider transitioning to libdb4.4)

[Andreas Barth]

* Nikita V. Youshchenko ([EMAIL PROTECTED]) [060523 17:22]:
> However, if I will build library against libdb4.4 instead of libdb4.2, this 
> will probably break any binaries built against the library - both packaged 
> and local.

Why that? It would only affect packages that (correctly or wrongly) also
depend on libdb4.2. (And libdb4.2 unfortunatly doesn't have versioning,
otherwise, it wouldn't be any issue; lidb4.3 and libdb4.4 are better in
that regard.)

AFAICS, this is only the case with etpan-ng. So, perhaps a conflict
between your new version and the current version of etpan-ng and an
upload of a changed version of etpan-ng (with a conflict to the current
version of libetpan) could help? Gerfried, what do you think?


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


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

Re: Packages violating policy 8.2

[Manoj Srivastava]

On 23 May 2006, Goswin von Brederlow stated:

> Manoj Srivastava <[EMAIL PROTECTED]> writes:
>
>> On 22 May 2006, Goswin von Brederlow stated:
>>
>>> Manoj Srivastava <[EMAIL PROTECTED]> writes:
>>>
 On 22 May 2006, Goswin von Brederlow outgrape:
> I think that Policy 8.2 is fully applicable to your package
> then. It is a MUST directive so your unwillingness to allow
> multiple versions of your library to coexist does not affect the
> violation.

 I beg to differ. There is a rationale for the policy section:
>>>
>>> And if it where optional then it would read SHOULD. Or what is the
>>> difference between MUST and SHOULD if you can jsut choose to
>>> ignore both?
>>
>> The section in question is about shared library packages, but
>> I am not actually creating a shared library package. Perhaps this
>> needs clarification in policy.
>
> To me it sounds like you are. You provide a shared object file in a
> public place so other people can link their binaries against
> it. What else is a shared library? Does it matter if no package in
> Debian uses it but only other people? I think not. If you intention
> is to let others link against it then it is a shared library by all
> means.

It is a shared library, and you are free to link with it --
 but as a developer you must realize that your package may break on
 upgrade, since there is no shared library package, just a single
 combined setools package.

With that caveat, this is a convenience for people who are
 working on setools.

> On a version upgrade the people that have their binaries linked
> against your lib will be unable to upgarde without removing those
> binaries first. The will have to work without them or with a chroot
> to even recompile for the new lib. Think about that.

I am. So if I build custom packages against these libraries,
 upgrades fail to install -- and then I force install and
 rebuild at a time of my chosing.

Works quite well for me.

> Following 8.2 you only have 2 choices: Split the package or
> provide only static libaries and live with the wasted
> space. Otherwise the packages is RC buggy.

 May I ask what is the underlying rationale for this judgement?
>>>
>>> My motivation is that not following 8.2 will make it impossible to
>>> convert the package to multiarch. For the rational of 8.2 itself
>>> you have to read policy and ask the people who wrote it. But I
>>> think it is pretty clear from the text: to be able to install
>>> multiple versions of the library for smooth upgrades.
>>
>> That person could well have been me, though I can't say I
>> recall writing that.  But the intent of the section is for shared
>> library packages, and  as such setools is not a shared library
>> package.
>
> If you say those libraries are not public then policy 10.2 would
> seem to apply:

> Policy 10.2:
>
> | Shared object files (often .so files) that are not public
> libraries, | that is, they are not meant to be linked to by third
> party executables | (binaries of other packages), should be
> installed in subdirectories of | the /usr/lib directory. Such files
> are exempt from the rules that | govern ordinary shared libraries,
> except that they must not be | installed executable and should be
> stripped.

Err, those a plugins, and one generally dlopens them, or
 otherwise manipulates the loader.  It certainly does not apply.

> Since you want to support linking by third party executables you
> don't quite fit the description of not public library. But well,
> lets keep one eye closed. Reading on you are violating a SHOULD
> directive.

I am not supporting  linking by "third party executables". I
 am, however, allowing people who recognize the lack to backward
 compatibility to help out with the development of SELinux.

> I agree that binary packages with *.so.* files can well fall under
> 10.2. Do you think your package fully does?

Nope.

>> I'll be happy to discuss what I need to do about multi-arch.
>>
 In what way do you think splitting the package would work? Why is
>>
>>> The same way it works for each and every other library package
>>> that is split in Debian.
>>
>> But I have no intention of supporting multiple versions of the
>> libraries for setools, like I do for my other shared library
>> packages which are indeed split up.
>>
 facilitating private packages for people who are working with
 SELinux a bad thing, when people who actually build and use these
 packages are aware of the current state of flux of SELinux?
>>>
>>> It isn't a bad thing but you aren't doing it "right" (right as
>>> laid out in policy).
>>
>> Policy is not all infallible, not does it always apply. I think
>> packages shipping libraries with relocatable code which explicitly
>> do not support backwards compatibility nor multiple versions for
>> the library in question, and do not split out library or -dev
>> packages, are not covered by th

Re: Sun Java available from non-free

[Stephen Gran]

This one time, at band camp, Mike Bird said:
> On Monday 22 May 2006 16:52, Wouter Verhelst wrote:
> > I don't think the chance of "nutcase sueing Sun for Bad Applet" is any
> > more relevant or likely than the chance of "nutcase sueing Debian for
> > bad browser". I really don't see how it makes the license problematic.
> 
> And that is why, in legal matters, Debian needs the combined expertise of
> the volunteer lawyers on debian-legal, rather than the "legal opinion" of
> a programmer.  Fair's fair.  I wouldn't trust most attorneys to fix a device
> driver.

Er, actually, they mostly are programmers with "legal opinions".  I
would prefer the opinions of actual lawyers when we feel we have
something potentially harmful, rather than the usual 'are my fonts free
enough' kind of question.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: Changing the default syslogd (again...)

[Manoj Srivastava]

On 23 May 2006, Javier Fernández-Sanguino Peña said:

> On Sun, May 21, 2006 at 07:38:10AM -0400, Nathanael Nerode wrote:
> (...)
>> Issues: (1) Quality.  sysklogd has 105 open bugs: 3 important (1
>> with patch), 43 normal (11 with patches), 11 minor (4 with
>> patches), and 19 wishlist (some of which are really quite
>> important, such as 44523)
>
> Please, when was open bugs a measure of quality? We have crappy code
> in Debian with 0 bugs because nobody uses it and cares to file a
> bug. Don't confuse popularity (more popular == more users == more
> *reported* bugs) to quality (worst code == more bugs). Reported bugs
> is in no way a measure to compare package's quality.

While a raw count of open bugsmay speak more to a packages
 size and history than quality of maintenance, important and normal
 bugs open for any length of time with patches do raise some flags.

Either the patch should have been applied, or the tag removed
 if the patch is unacceptable.

>> The source code is a hairy mess, in my opinion, and I can see why
>> these bugs aren't being fixed.  It's been prone to repeated RC
>> bugs, IMO due to the hairiness of the codebase.  (I would also
>> really not like to try a licensing audit of this package.)
>
> Actually, from personal experience, bugs are not fixed because the
> maintainer is against all NMUs, even those that follow the steps
> described in the sysklogd's source 'debian/NMU-Disclaimer'. The
> current maintainer's handling of bugs and suggestions to NMU for
> this package discourages people to either NMU or help him integrate
> patches included by other distributions (like Red Hat / Fedora) into
> the version in Debian.

Since we periodically have bug squash parties, and NMU's for
 long standing bugs ought to be permissible (use N-day delayed uploads
 if one wants to be extra careful), this should not be an issue.

manoj
-- 
I hear what you're saying but I just don't care.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

free flash stuff WAS: Re: Sun Java available from non-free

[Paul Wise]

On Mon, 2006-05-22 at 18:58 -0500, Anthony Towns wrote:

> Java is one of the most important packages for which we don't have an
> effective non-free replacement at present. The only one that I can think
> of that would be more important would be flash.

There is a gnash package destined for experimental in NEW, which will
greatly increase debian's flash viewing capabilities (swfdec/gplflash1
don't have huge amounts of support). Other things in NEW are: ming,
flasm and haxe. mtasc (ActionScript -> swf compiler) is already in, and
several more development tools are coming, see here:

http://osflash.org/debian_packaging

Anyone interested in free flash stuff should join the debian-flash list
(once it is created) and or send support to the list creation request:

http://bugs.debian.org/365479

There is also a pkg-flash project on alioth, waiting on the list to be
created (or rejected) before we move forward with putting stuff in svn.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: libetpan 0.45-2 was built on m68k but not went to archive?

[Wouter Verhelst]

On Tue, May 23, 2006 at 01:23:49PM +0400, Nikita V. Youshchenko wrote:
> Hello.
> 
> I just found that my package, libetpan, was not updated for m68k.
> [1] states that it is out of date on m68k.
> But [2] states that latest version was successfully built on m68k long ago 
> - on Apr17.
> 
> What's going on?

Something happened with the log mail from the buildd to me (its
maintainer), or with the reply that I sent back to the buildd, or so. As
such, it slipped through the cracks. This happens occasionally, and I
usually fix those when I get around to do maintenance on the buildd
host (which is a bit overdue by now, on that particular box).

Or when people like yourself come by, find out that something is wrong,
and ask us about it ;-)

> Whom to contact on this issue?

For buildd issues, you should always contact [EMAIL PROTECTED] --
in this case, [EMAIL PROTECTED]

Though that's not necessary anymore now for this particular one, I've
just fixed it.

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


signature.asc
Description: Digital signature

Re: use of "invoke-rc.d $PACKAGE stop || exit $?" in prerm scripts

[Michael Prokop]

* Bernd Schubert <[EMAIL PROTECTED]> wrote:
> Michael Prokop wrote:

>> How do you achieve that? For example symlinking invoke-rc.d to
>> /bin/true is a workaround, but I'm searching for a general solution
>> to avoid that daemons are started when upgrading even though they
>> did not run before the upgrade (or don't start any service at all,
>> e.g. in chroots - as you mentioned).

> Via /usr/sbin/policy-rc.d, e.g.:

> #!/bin/sh

> # are we on hamilton?
> WHERE=$(hostname -s|cut -b 1-8) # cut to remove {1,2} from hamilton{1,2}
> if [ "$WHERE" = "hamilton" ]; then
> # notify invoke-rc.d that nothing should be done -- we are in a chroot
> exit 101
> else
> # allow it
> exit 0
> fi

> (This chroot is used on the clients as their root environment)

Thanks.

>> The init script would be broken then.
>> Anyway, I don't see the difference between "stop || exit $?" and
>> "stop || true" in this case.

> What I mean is that the call of 

> invoke-rc.d $PACKAGE stop || true

> is fine, but the second call

> /etc/init.d/$PACKAGE stop || true

> will not using policy-rc.d and therefore might be a possible problem. Given
> the fact that we have a sid chroot on a high availibilty system and a sid
> package always might cause some trouble, I don't like the idea that a
> malformed script is able to stop programs outside its chroot. 

But /etc/init.d/$PACKAGE is executed only, if "[ -x "`which
invoke-rc.d 2>/dev/null`" ]" fails. And I still don't see what's the
relation to "stop || true". ;) I don't insist on the "stop || true"
way of life, I'd just like to make sure that removing packages
always works.

-mika-


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

Re: libetpan 0.45-2 was built on m68k but not went to archive?

[Ingo Juergensmann]

On Tue, May 23, 2006 at 01:23:49PM +0400, Nikita V. Youshchenko wrote:

> I just found that my package, libetpan, was not updated for m68k.
> [1] states that it is out of date on m68k.
> But [2] states that latest version was successfully built on m68k long ago 
> - on Apr17.
> What's going on? 

After a successful build human action is need to upload the package.
Sometimes it happens that a package slips through... 

Anyway, Wouter uploaded it now:
May 23 19:52:30 buildd-mail: libetpan has been installed; removing from
upload dir:
May 23 19:52:30 buildd-mail: libetpan-dev_0.45-2_m68k.deb
libetpan6_0.45-2_m68k.deb libetpan_0.45-2_m68k.changes
libetpan_0.45-2_m68k.upload

> Whom to contact on this issue?

There's an alias set for each arch ([EMAIL PROTECTED]) and of course
you could contact the porters list ([EMAIL PROTECTED]) or the buildd
admin itself (http://www.buildd.net/ lists them best to my knowledge). 

-- 
Ciao...//Fon: 0381-2744150 
  Ingo   \X/ SIP: [EMAIL PROTECTED]

gpg pubkey: http://www.juergensmann.de/ij/public_key.asc


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

not running depmod at boot time

[Marco d'Itri]

So, does anybody mind if I remove depmod from the module-init-tools init
script?

-- 
ciao,
Marco


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

Re: NEW queue backlog

[Thomas Viehmann]

[apologies for the blank reply]

Michael Banck wrote:
> Both Jörg and Jeroen (who are usually doing the NEW processing AFAIK)
> are travelling in Mexico for another two weeks I believe.  Maybe one of
> the regular ftp-masters steps in and does some processing for the more
> important stuff in the meanwhile, though.
Are you sure that this isn't done? I had the impression that fixes for
RC bugs that only are soname changes or something were processed a
couple of days ago...

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


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