Re: Source package containing HTML-only form of texinfo doc

[fourmond]

  Hello,

On Thu, Jul 05, 2007 at 07:50:30PM +0200, Thomas Weber wrote
> I'm one of Octave's Debian maintainers. 
> 
> The problematic part is that qtoctave is primarly a Windows application. I 
> don't think they even have any sort of code for generating the HTML files 
> from the Texinfo sources, so even including the texinfo files would still be 
> a violation.
> 
> Maybe they should just update the documentation and use the HTML files from 
> [1]. I think the files there have a more liberal license.
> 
> [1] http://www.gnu.org/software/octave/doc/interpreter/

  As for a debian package of qtoctave, the solution we think is the best for 
now is to repackage the 
original tarball to remove the texinfo-generated stuff and Recommend 
octave2.9-htmldoc with 
appropriate paths rewrites.

  Regards,

Vincent


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

Bug#431952: ITP: python-plwm -- Pointless Window Manager - python library for creating Window Managers

[Mike O'Connor]

Package: wnpp
Severity: wishlist
Owner: "Mike O'Connor" <[EMAIL PROTECTED]>


* Package name: python-plwm
  Version : 2.6a
  Upstream Author : Peter Liljenberg <[EMAIL PROTECTED]>
* URL : http://plwm.sourceforge.net/
* License : GPL
  Programming Lang: Python
  Description : Pointless Window Manager - python library for creating 
Window Managers
 PLWM is a Python package, containing classes suitable for
 implementing a window manager. PLWM is also a window manager, using
 the PLWM package.
 package

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.21.1-thinkpad (SMP w/1 CPU core; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash


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

Re: upstart (Re: Bug#417118: ntpdate: Start sequence problem for some network setups)

[Oleg Verych]

* martin f krafft (Fri, 6 Jul 2007 07:57:57 +0200)
>
> also sprach Oleg Verych <[EMAIL PROTECTED]> [2007.07.05.1957 +0200]:
>> Unless i will see any kind of implemented proposal, i.e. tar or deb
>> that i can use/test on base installation, it's a *technical* problem.
>
> So why don't you use your time to help solve the problem

In fact i do use my time now to solve problems. One of those is an
alternative to "dpkg filters", after one or two days to be released to
you here. Another, as you night notice in this ML, is bug shooting in
`dash'.

> instead of harping= on mailing lists?

Oops, i thought message, i was replying to, is one of those. That's why
i did reply in such way actually.

Either way, i don't care.



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

QuickyPix - was Re: Bug#431803: ITP: pyctures -- Small and simple web gallery for pictures

[David Härdeman]

On Thu, July 5, 2007 02:40, Marti­n Ferrari wrote:
> Package: wnpp
> Severity: wishlist
> Owner: "Marti­n Ferrari" <[EMAIL PROTECTED]>
>
> * Package name: pyctures

That reminds me, is there any DD who'd be interested in packaging
QuickyPix (http://www.cubewano.org/quickypix/)? It's another web gallery
app written in python which seems to have some nice features (like not
having to wade through 25 pages of configuration settings to get it up and
running).

-- 
David Härdeman


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

Bug#431997: ITP: libjavajodatime-java -- The JodaTime-Libery for java

[Daniel 'DaB.' Baur]

Package: wnpp
Severity: wishlist
Owner: "Daniel 'DaB.' Baur" <[EMAIL PROTECTED]>


* Package name: libjavajodatime-java
  Version : 1.4
  Upstream Author : Stephen Colebourne <[EMAIL PROTECTED]>
* URL : http://joda-time.sourceforge.net/index.html
* License : Apache License Version 2.0.
  Programming Lang: Java
  Description : The JodaTime-Libery for java

(Include the long description here.)
The jodatime-libery will be part of the official sun-java-programm in the
future (see https://jsr-310.dev.java.net/). But this will take some time. So
a package which containes the java-libery would be nice and should make no
problems.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.18-4-686 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash


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

Re: Missing license info in source files - fixed in upstream svn

[Paul Cager]

On Tue, July 3, 2007 4:06 pm, Paul Cager wrote:
> On Tue, July 3, 2007 8:38 am, Andreas Barth wrote:
>> Explain it in debian/copyright, that's the proper place (the source
>> files don't actually need license statement, even though of course it
>> helps transparence and is therefore encouraged).
>
> I didn't realise that. I had assumed that each source file *had* to have a
> license declaration in it.
>
> So if the source files do not have license declarations, we are still OK
> if there is a "COPYING" (or similar) file in the tarball? What about if
> there is no such file but there is an explicit license declaration on
> upstream's web site?

May I ask for a bit of clarification?

Andreas Barth said:
>Explain it in debian/copyright, that's the proper place (the source
>files don't actually need license statement, even though of course it
>helps transparence and is therefore encouraged).

So it looks as though it is acceptable to have files without license
declarations (provided the license is stated elsewhere).

But Ben Finney said:
>No, there needs to be an explicit grant of license explaining what
>terms apply, and exactly which files comprise the work being licensed.

I'm not sure I understand; would a "COPYING" file stating "this project is
licensed under..." be acceptable?


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

Re: Missing license info in source files - fixed in upstream svn

[Russ Allbery]

Paul Cager <[EMAIL PROTECTED]> writes:
> But Ben Finney said:

>> No, there needs to be an explicit grant of license explaining what
>> terms apply, and exactly which files comprise the work being licensed.

> I'm not sure I understand; would a "COPYING" file stating "this project
> is licensed under..." be acceptable?

In practice, there's so much software out there that just provides a
license in the README file and no separate notices in each file that I
don't think you're going out on much of a limb by assuming that any files
that don't say otherwise are covered by the copyright and license in the
general README file.

If you want to try to convince upstream to use better discipline about
marking each file, that's certainly fine, but I doubt it makes any real
difference given past precedent.

You do need to be careful of packages that just drop the GPL COPYING file
into the distribution but don't mention a license anywhere else in the
distribution.  Some packages like that have, in the past, not actually
been under the GPL.  Upstream sometimes does dumb things, like put COPYING
in the distribution just to satisfy Automake.  Unless there's some
statement written by the author specifying what the package license is,
it's probably worth seeking clarification.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Targeting RPM and Debian from a Debian box?

[Luis Matos]

Sex, 2007-07-06 às 18:47 +0200, Bernd Zeimetz escreveu:
> Hi,
> 
> > My development workstation is running Debian, and I'd like to produce
> > both .deb and .rpm releases of my software.
you can easily use virtual machines like xen and qemu to build and test
them.

> -- 
> Bernd Zeimetz
> <[EMAIL PROTECTED]> 
> 
> 


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

Targeting RPM and Debian from a Debian box?

[Christian Convey]

My development workstation is running Debian, and I'd like to produce
both .deb and .rpm releases of my software.

Is this something people normally do from the same Debian workstation,
or do they typically fire up a RedHat system to do their .rpm
creation, and use a Debian workstation to do their .deb creation?

Thanks,
Christian


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

Re: Targeting RPM and Debian from a Debian box?

[Bernd Zeimetz]

Hi,

> My development workstation is running Debian, and I'd like to produce
> both .deb and .rpm releases of my software.

depending on your software producing packages for Redhat, SuSE or any
other rpm based distributions on a Debian box is not what you want to do
as you want to use their specific library versions to build your package
properly. If you're only packaging some architecture independent stuff,
it probably doesn't matter at all - you would want to test your package
on the target distribution, though.

Cheers,

Bernd

-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 


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

Re: Targeting RPM and Debian from a Debian box?

[Russ Allbery]

Christian Convey <[EMAIL PROTECTED]> writes:

> My development workstation is running Debian, and I'd like to produce
> both .deb and .rpm releases of my software.

> Is this something people normally do from the same Debian workstation,
> or do they typically fire up a RedHat system to do their .rpm creation,
> and use a Debian workstation to do their .deb creation?

You'll have to use the appropriate OS to build packages for that OS.
Debian requires this as well in order to get things like shared library
dependencies right, to satisfy Build-Depends, and so forth.  It makes
sense that RPM has the same issues.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Targeting RPM and Debian from a Debian box?

[Christian Convey]

\On 7/6/07, Russ Allbery <[EMAIL PROTECTED]> wrote:

Christian Convey <[EMAIL PROTECTED]> writes:

> My development workstation is running Debian, and I'd like to produce
> both .deb and .rpm releases of my software.

> Is this something people normally do from the same Debian workstation,
> or do they typically fire up a RedHat system to do their .rpm creation,
> and use a Debian workstation to do their .deb creation?

You'll have to use the appropriate OS to build packages for that OS.
Debian requires this as well in order to get things like shared library
dependencies right, to satisfy Build-Depends, and so forth.  It makes
sense that RPM has the same issues.

--
Russ Allbery ([EMAIL PROTECTED])   



Thanks everyone.


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

Re: QuickyPix - was Re: Bug#431803: ITP: pyctures -- Small and simple web gallery for pictures

[Margarita Manterola]

On 7/6/07, David Härdeman <[EMAIL PROTECTED]> wrote:


That reminds me, is there any DD who'd be interested in packaging
QuickyPix (http://www.cubewano.org/quickypix/)? It's another web gallery
app written in python which seems to have some nice features (like not
having to wade through 25 pages of configuration settings to get it up and
running).


Well, if you think you can manage it, you can package it yourself and
ask for the package to get sponsored.  If not, you should then file an
RFP:
http://www.debian.org/devel/wnpp/

--
Besos,
Marga

Re: Targeting RPM and Debian from a Debian box?

[Peter Makholm]

"Christian Convey" <[EMAIL PROTECTED]> writes:

> Is this something people normally do from the same Debian workstation,
> or do they typically fire up a RedHat system to do their .rpm
> creation, and use a Debian workstation to do their .deb creation?

Never done it myself but I would at least built the rpm in a chroot or
vserver with the target distribution installed.

//Makholm


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

Re: Targeting RPM and Debian from a Debian box?

[Ivan Jager]

On Fri, 6 Jul 2007, Russ Allbery wrote:


Christian Convey <[EMAIL PROTECTED]> writes:


My development workstation is running Debian, and I'd like to produce
both .deb and .rpm releases of my software.



Is this something people normally do from the same Debian workstation,
or do they typically fire up a RedHat system to do their .rpm creation,
and use a Debian workstation to do their .deb creation?


You'll have to use the appropriate OS to build packages for that OS.
Debian requires this as well in order to get things like shared library
dependencies right, to satisfy Build-Depends, and so forth.  It makes
sense that RPM has the same issues.


I don't build RPMs any more, but you should be able to build them just 
fine inside a chroot. Look at the schroot package if you want to do it as 
a normal user.


You will still want an install of each distro you want to build/test 
packages for, although some things built for one distro may work fine on 
another.


Ivan


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

Re: Targeting RPM and Debian from a Debian box?

[Bernd Zeimetz]

> Never done it myself but I would at least built the rpm in a chroot or
> vserver with the target distribution installed.

vserver is a good hint here, definitely my favourite way to install
diferent distributions/versions/... on one machine, and way less
ressource intensive than xen & co.

-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 


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

Bug#432023: ITP: ll-core -- Core modules used by all ll- and other modules

[Bernd Zeimetz]

Package: wnpp
Severity: wishlist
Owner: Bernd Zeimetz <[EMAIL PROTECTED]>

* Package name: ll-core
  Version : 1.9.1
  Upstream Author : Walter Doerwald <[EMAIL PROTECTED]>
* URL : http://www.livinglogic.de/Python/core/index.html
* License : Python lic.
  Programming Lang: Python
  Description : Core modules used by ll- and other packages

 ll-core is a collection of the following modules:
 .
   * 'ansistyle' can be used for colored terminal output (via
 ANSI escape sequences).
   * 'color' provides classes and functions for handling
 RGB color values.
   *  'make' is an object oriented make replacement.
   *  'misc' provides several small utility functions and
 classes.
   *  'sisyphus' provides classes for running Python scripts as
 cron jobs.
   *'daemon' can be used on UNIX to fork a daemon process.
   *   'url' contains an RFC2396 compliant implementation of
 URLs and classes for accessing resource metadata
 as well as file like classes for reading data
 from URLs and writing data to URLs.
   *  'xpit' is a module that makes it possible to embed Python
 expressions in text (as XML style processing
 instructions).


If anybody can come up with a better short description - please let me
know. I'm packaging this module collection as dep. of XIST (itp
#336685). The packages will be added to the python-module team's svn.


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

Re: apt-get -y upgrade for non-interactive sessions - and replacing conf files in /etc

[Florian Lohoff]

On Thu, Jul 05, 2007 at 11:57:31AM -0700, Alan Ezust wrote:
> Subject: apt-get -y upgrade for non-interactive sessions - and replacing conf 
> files in /etc
> 
> Hi -  i was wondering, I'm trying to run apt-get upgrade in a
> non-interactive shell.
> I passed -y as an option, and then during the postinst, I have a
> situation where the package has a configuration file which is newer
> than what it is about to replace. I would like it to just replace the
> configuration file without asking me, but it won't do that, even if I
> pass the -y option.
> 
> I realize that the default behavior of apt-get is probably valid, but
> is there a way to run apt-get such that clobbering of configuration
> files can happen without user intervention?

conffiles is a dpkg thing - not apt 

Try something like this ...

DEBIAN_FRONTEND=noninteractive \
apt-get \
-o Dpkg::Options::="--force-confnew" \
--force-yes \
-fuy \
dist-upgrade


I used something like this (a shell script with a couple hundret lines) to 
upgrade
a couple hundret machines from woody via sarge to etch ... (Can we make 6 Year
Release cycles please?).

Flo
-- 
Florian Lohoff  [EMAIL PROTECTED] +49-171-2280134
Those who would give up a little freedom to get a little 
  security shall soon have neither - Benjamin Franklin


signature.asc
Description: Digital signature

Please all dependency info into your init.d script

[Petter Reinholdtsen]

As you might be aware, there are several bugs in the Debian boot
sequence.  The bugs affect some combinations of packages, and are some
times hard to solve.  To solve them once and for all, I want us to
switch to a dependency based sequencing of the symlinks in
/etc/rc*.d/.  I gave a talk about this at Debconf, see
https://penta.debconf.org/~joerg/events/21.en.html> for the
slides and more info.

For this to work properly, all init.d scripts need to provide
dependency information.  There is a standard for specifying such
dependency information in the LSB, and already 56% of the Debian
packages in unstable include the header with dependency information.
This message is for the rest of you.

I've created
http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot> to
track the progress of this work.  See also
http://wiki.debian.org/LSBInitScripts> for clues on how to write
such header.

The following packages are according to lintian missing the LSB
headers.  Please add dependency information to these packages soon.
Without it, it is very hard to verify the correctness of the debian
boot sequence, and equally hard to switch to a dependency based boot
sequencing.  Some proposed headers are available in the insserv
package, directory /usr/share/insserv/override/, so if you are lucky
you can pick it from there.

Guenter Geiger (Debian/GNU) <[EMAIL PROTECTED]>
   realtime-lsm

Laszlo Boszormenyi (GCS) <[EMAIL PROTECTED]>
   metalog

Stefan Hornburg (Racke) <[EMAIL PROTECTED]>
   courier
   courier-authlib
   interchange
   pure-ftpd
   sympa

Cyril Lacoux (Yack) <[EMAIL PROTECTED]>
   digitools

Marco Presi (Zufus) <[EMAIL PROTECTED]>
   linesrv

Peter De Schrijver (p2) <[EMAIL PROTECTED]>
   linux-atm

Stefan Alfredsson <[EMAIL PROTECTED]>
   monit

Pierre Ancelot <[EMAIL PROTECTED]>
   hwtools

Osamu Aoki <[EMAIL PROTECTED]>
   tpconfig

Ben Armstrong <[EMAIL PROTECTED]>
   xpilot-ng

Don Armstrong <[EMAIL PROTECTED]>
   spamass-milter

SZALAY Attila <[EMAIL PROTECTED]>
   zorp

Julien BLACHE <[EMAIL PROTECTED]>
   smcroute

Joost van Baal <[EMAIL PROTECTED]>
   uruk

Alan Bain <[EMAIL PROTECTED]>
   rbootd

Andreas Barth <[EMAIL PROTECTED]>
   dhcp
   mgetty

Daniel Baumann <[EMAIL PROTECTED]>
   ipac-ng
   ipmasq
   nfs-user-server

Edelhard Becker <[EMAIL PROTECTED]>
   atop

Hilko Bengen <[EMAIL PROTECTED]>
   ulog-acctd

Grzegorz Bizon <[EMAIL PROTECTED]>
   specter

Bastian Blank <[EMAIL PROTECTED]>
   omniorb4
   redhat-cluster

Blars Blarson <[EMAIL PROTECTED]>
   cnews

Eduard Bloch <[EMAIL PROTECTED]>
   apt-cacher
   scsi-idle

Ed Boraas <[EMAIL PROTECTED]>
   aime
   tinyproxy

W. Borgert <[EMAIL PROTECTED]>
   blinkd

Cyril Bouthors <[EMAIL PROTECTED]>
   bld
   drbdlinks

Chris Boyle <[EMAIL PROTECTED]>
   reaim

Joachim Breitner <[EMAIL PROTECTED]>
   infon

Adrian Bridgett <[EMAIL PROTECTED]>
   dante

Eric Van Buggenhaut <[EMAIL PROTECTED]>
   udhcp

Chris Butler <[EMAIL PROTECTED]>
   wu-ftpd

Bruno Barrera C. <[EMAIL PROTECTED]>
   portsentry

Patrick Caulfield <[EMAIL PROTECTED]>
   mopd

Emmanuel le Chevoir <[EMAIL PROTECTED]>
   frox

Dennis L. Clark <[EMAIL PROTECTED]>
   bnetd

Isaac Clerencia <[EMAIL PROTECTED]>
   wesnoth

Jesus Climent <[EMAIL PROTECTED]>
   distmp3

Russell Coker <[EMAIL PROTECTED]>
   memlockd

Jamin W. Collins <[EMAIL PROTECTED]>
   jabber

Carlo Contavalli <[EMAIL PROTECTED]>
   wipl

Leo Costela <[EMAIL PROTECTED]>
   knockd

Paul Cupis <[EMAIL PROTECTED]>
   guarddog
   guidedog

Artur R. Czechowski <[EMAIL PROTECTED]>
   rrdcollect

Julien Danjou <[EMAIL PROTECTED]>
   ledstats
   sysrqd
   tetrinetx
   tleds

Debian ALSA Maintainers <[EMAIL PROTECTED]>
   alsa-tools

Debian CUPS Maintainers <[EMAIL PROTECTED]>
   cupsys

Debian GNUstep maintainers <[EMAIL PROTECTED]>
   gnustep-base

Debian Hamradio Maintainers <[EMAIL PROTECTED]>
   ssbd

Debian Icecast team <[EMAIL PROTECTED]>
   icecast2

Debian Java Maintainers <[EMAIL PROTECTED]>
   tomcat5

Debian LVM Team <[EMAIL PROTECTED]>
   devmapper
   lvm-common
   lvm2
   multipath-tools

Debian Nagios Maintainer Group <[EMAIL PROTECTED]>
   nsca

Debian Qt/KDE Maintainers <[EMAIL PROTECTED]>
   kdenetwork

Debian VoIP Team <[EMAIL PROTECTED]>
   bayonne
   rtpproxy
   ser
   siproxd
   stun
   yate

Debian/Ubuntu Zope Team <[EMAIL PROTECTED]>
   schooltool

Eric Delaunay <[EMAIL PROTECTED]>
   scsitools

Cédric Delfosse <[EMAIL PROTECTED]>
   darkstat

Jean-Francois Dive <[EMAIL PROTECTED]>
   l2tpd

Bernd Eckenfels <[EMAIL PROTECTED]>
   net-acct
   transproxy

Nick Estes <[EMAIL PROTECTED]>
   upsd

Martín Ferrari <[EMAIL PROTECTED]>
   vtun

Agney Lopes Roth Ferraz <[EMAIL PROTECTED]>
   fnfx

Duncan Findlay <[EMAIL PROTECTED]>
   spamassassin

Decklin Foster <[EMAIL PROTECTED]>
   lastfmsubmitd
   mpd

Turbo Fredriksson <[EMAIL PROTECTED]>
   roxen4

Jochen Friedrich <[EMAIL PROTECTED]>
   isakmpd
   snmptrapfmt

Peter S Galbraith <[EMAIL PROTECTED]>
   xtide

Radovan Garabik <[EMAIL PROTECTED]>
   serpento

Re: Bug#417118: ntpdate: Start sequence problem for some network setups

[Petter Reinholdtsen]

[Touko Korpela]
> Is there any ideas to fix this? I'm having same problem with ntp+dnsmasq

My idea for fixing this is to reorder the sysv boot sequence using
dependency information, and allow those with special needs to provide
extra/replacement dependency information in /etc/ to adjust the
sequence for local needs.  I would like to have it implemented for
Etch, and have proposed it as a release goal.

It is mostly independent of the ideas for switching to upstart, as
upstart is mostly useful for the early boot where the kernel events
need to be properly handled by the boot system.  It will only affect a
few packages.  The majority of the 843 packages with init.d scripts do
not need to interact with the kernel, so at least for Lenny we do not
need to rewrite all boot scripts to get better handling of kernel
events.

See http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot>
for the state of this effort.

Happy hacking,
-- 
Petter Reinholdtsen


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

Re: Missing license info in source files - fixed in upstream svn

[Bernhard R. Link]

* Russ Allbery <[EMAIL PROTECTED]> [070706 17:46]:
> > I'm not sure I understand; would a "COPYING" file stating "this project
> > is licensed under..." be acceptable?
>
> In practice, there's so much software out there that just provides a
> license in the README file and no separate notices in each file that I
> don't think you're going out on much of a limb by assuming that any files
> that don't say otherwise are covered by the copyright and license in the
> general README file.

One still should do the usual minimal coherency checks. If for example
files have a different author or copyright holder specified or look
totally out of style, its better to search the web for those files
and/or seek for clarification.

> You do need to be careful of packages that just drop the GPL COPYING file
> into the distribution but don't mention a license anywhere else in the
> distribution.  Some packages like that have, in the past, not actually
> been under the GPL.  Upstream sometimes does dumb things, like put COPYING
> in the distribution just to satisfy Automake.  Unless there's some
> statement written by the author specifying what the package license is,
> it's probably worth seeking clarification.

Another case often enough gotten wrong are things like icons, which are
often just copied around. Its better to ask upstream explicitly about
them[1]. Or if it is a package were upstream is no longer available, doing
a quick google check for those file's md5sums for an explicit hint
if they are from other sources.

Hochachtungsvoll,
Bernhard R. Link

[1] After all, you should contact upstream anyway, as an very important
part of maintaining a package should be communicating about bugs,
user supplied patches, your own patches, ...


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

Re: Bug#417118: ntpdate: Start sequence problem for some network setups

[Michael Biebl]

Petter Reinholdtsen wrote:
> [Touko Korpela]
>> Is there any ideas to fix this? I'm having same problem with ntp+dnsmasq
> 
> My idea for fixing this is to reorder the sysv boot sequence using
> dependency information, and allow those with special needs to provide
> extra/replacement dependency information in /etc/ to adjust the
> sequence for local needs.  I would like to have it implemented for
> Etch, and have proposed it as a release goal.
> 
> It is mostly independent of the ideas for switching to upstart, as
> upstart is mostly useful for the early boot where the kernel events
> need to be properly handled by the boot system.  It will only affect a

That's not quite correct. Upstart not only handles the relationship
between hardware events and services (start ntpdate when network
interface is available and configured) but also between services and
services (start hal when dbus is available etc). Upstart handles the
complete boot process and not only the early boot, as you suggest. More
info on that will follow.

Cheers,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Bug#417118: ntpdate: Start sequence problem for some network setups

[Michael Biebl]

Michael Biebl wrote:
> Petter Reinholdtsen wrote:
>> [Touko Korpela]
>>> Is there any ideas to fix this? I'm having same problem with ntp+dnsmasq
>> My idea for fixing this is to reorder the sysv boot sequence using
>> dependency information, and allow those with special needs to provide
>> extra/replacement dependency information in /etc/ to adjust the
>> sequence for local needs.  I would like to have it implemented for
>> Etch, and have proposed it as a release goal.
>>
>> It is mostly independent of the ideas for switching to upstart, as
>> upstart is mostly useful for the early boot where the kernel events
>> need to be properly handled by the boot system.  It will only affect a
> 
> That's not quite correct. Upstart not only handles the relationship
> between hardware events and services (start ntpdate when network
> interface is available and configured) but also between services and
> services (start hal when dbus is available etc). Upstart handles the
> complete boot process and not only the early boot, as you suggest. More
> info on that will follow.

Btw, static dependencies won't help you for the ntpdate case, as you
can't know in advance, when the network is up and ready.
That's the beauty and elegance of the upstart approach: Things only
happen (meaning services or tasks are started), when the corresponding
event occurs resp. the correct state is entered.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#431974: ITP: radiance -- Lighting Simulation and Rendering System

[Bernd Zeimetz]

(I've forgot to add X-Debbugs-CC when sending this ITP. Forwarding the
mail to d-devel as I think radiance could be interesting for more people
- if anybody wants to join the team - please let me know)



Package: wnpp
Owner: Bernd Zeimetz <[EMAIL PROTECTED]>
Severity: wishlist

* Package name: radiance
  Version : 3.8
  Upstream Author : Greg Ward <[EMAIL PROTECTED]>
* URL : http://radsite.lbl.gov/radiance/index.html
* License : The Radiance Software License, Version 1.0
BSD-style,
http://radsite.lbl.gov/radiance/misc/license.txt
  Programming Lang: C
  Description : Lighting Simulation and Rendering System

Radiance is intended to aid lighting designers and architects by
predicting the light levels and appearance of a space prior to
construction. The package includes programs for modeling and translating
scene geometry, luminaire data and material properties, all of which are
needed as input to the simulation. The lighting simulation itself uses
ray tracing techniques to compute radiance values (ie. the quantity of
light passing through a specific point in a specific direction), which
are typically arranged to form a photographic quality image. The
resulting image may be analyzed, displayed and manipulated within the
package, and converted to other popular image file formats for export to
other packages, facilitating the production of hard copy output.




The current plan is to maintain the package in a team which is located
at the Darmstadt University of Technology. We'll probably provide
optimized packages for the different sub-architectures, similar to the
packaging scheme used for ATLAS.



-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 




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

Re: Archive rebuild with improved dpkg-shlibdeps

[Steve Langasek]

Hi Raphael,

On Thu, Jun 21, 2007 at 09:59:53AM +0100, Raphael Hertzog wrote:
> ace-of-penguins_1.2-8_sid32.buildlog:dpkg-shlibdeps: warning: Symbol [EMAIL 
> PROTECTED] used by debian/ace-of-penguins/usr/lib/libcards.so.1.0.0 found in 
> none of the libraries.  
> -> here's you have the opposite problem, this library uses symbols from
> another library without being linked with it. You need to the appropriate
> "-l" flag (in this case -lX11).

> If you encounter any strangeness, please report it so that we can check.
> Those warnings could be the base of some mass-bug filings althought
> we might want to start with the second one (those are real bugs, while the
> other are not creating any technical problem (except useless
> dependencies)).

If you do decide to do mass bugfiling about this second issue, please take
care to exclude from your list those objects which are neither shared
libraries nor executables.  It's fairly common for plugin APIs to require
that plugins refer to symbols only defined by the module loader, so checking
for undefined symbols in these DSOs will create a huge number of false
positives.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


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

Re: Targeting RPM and Debian from a Debian box?

[Hamish Moffatt]

On Fri, Jul 06, 2007 at 05:06:56PM +, Peter Makholm wrote:
> "Christian Convey" <[EMAIL PROTECTED]> writes:
> 
> > Is this something people normally do from the same Debian workstation,
> > or do they typically fire up a RedHat system to do their .rpm
> > creation, and use a Debian workstation to do their .deb creation?
> 
> Never done it myself but I would at least built the rpm in a chroot or
> vserver with the target distribution installed.

It looks like rpmstrap could build you a suitable chroot (like
debootstap for Debian), but from the description it appears to be
somewhat outdated (eg Fedora Core 2).

Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


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