Re: postfix as default-mta? [Re: Bug#508644: new release goal default-mta?]

[Christian Perrier]

Quoting Steve Langasek (vor...@debian.org):

> If this were put to the TC, I can't see any way that this would be anything
> more than a poll of the personal preferences of the members of the TC.  If
> someone who's in a position to make this decision decides they'd like to
> delegate the decision to the TC, then ok, I suppose we can decide it that
> way; but otherwise I don't see any reason that a vote of the TC is a better
> way to decide this than any other arbitrary method...


Well, I grant the TC members for being wiser than just giving their
personal preferences and ponder the consequences of various options
when it comes to a technically related problem.

That's probably my personal opinion but I would personnally push for
the TC to be more involved in such "strategical" decisions. You guys
are not just a random collection of old timers, after all..:-)




signature.asc
Description: Digital signature

Re: postfix as default-mta? [Re: Bug#508644: new release goal default-mta?]

[Steve Langasek]

On Sat, May 09, 2009 at 08:04:07AM +0200, Christian Perrier wrote:
> Quoting Micah Anderson (mi...@debian.org):

> > I think our problem is, how do we go about making this decision? 

> If the problem is well summarized (the wiki page you pointed), why not
> make use of our Technical Committee for this?

> It certainly needs someone committing self to track down the issue
> once the decision is made (if the decision is made to
> change). Apparently, Martin Krafft kind of volunteered, at least if
> the change is meant to be postfix.

> I personnally think that we have a TC *also* for such kind of though
> decisions, not only to solve out disputes between package maintainers.

If this were put to the TC, I can't see any way that this would be anything
more than a poll of the personal preferences of the members of the TC.  If
someone who's in a position to make this decision decides they'd like to
delegate the decision to the TC, then ok, I suppose we can decide it that
way; but otherwise I don't see any reason that a vote of the TC is a better
way to decide this than any other arbitrary method...

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Possible mass bug filing: non-doc packages recommending doc packages

[Steve Langasek]

On Sat, May 09, 2009 at 11:31:05AM +1000, Ben Finney wrote:
> Wouldn't this MBF shake out which packages actually have good reason for
> a strong (i.e. pulled-in-by-default-package-tool-behaviour) dependency
> relationship to their docs from those that do not?

At the expense of the time of maintainers who have to close these garbage
bugs.

> That seems like a good reason to go through this exercise.

No.  Figure out which packages actually should be changed, *then* file bugs.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: postfix as default-mta? [Re: Bug#508644: new release goal default-mta?]

[Christian Perrier]

Quoting Micah Anderson (mi...@debian.org):

> I think our problem is, how do we go about making this decision? 


If the problem is well summarized (the wiki page you pointed), why not
make use of our Technical Committee for this?

It certainly needs someone committing self to track down the issue
once the decision is made (if the decision is made to
change). Apparently, Martin Krafft kind of volunteered, at least if
the change is meant to be postfix.

I personnally think that we have a TC *also* for such kind of though
decisions, not only to solve out disputes between package maintainers.




signature.asc
Description: Digital signature

Re: Using uscan with VCS hosting sites

[Ben Finney]

Raphael Geissert  writes:

> Ben Finney wrote:
> > So, how do I go from “the URL for the project source is
> > http://bitbucket.org/ned/coveragepy/>”, to a ‘debian/watch’
> > file that will enable ‘uscan’ to discover the current version is
> > ‘coverage-3.0b2’, and its original source tarball is downloadable
> > from http://bitbucket.org/ned/coveragepy/get/79dd373074de.gz>?
> 
> I can't think of any way to do what you want with version 2/3 watch
> files.

Thank you for considering it and saving me time on futile work.

> What you want is basically #395439 plus a feature that could be used
> to build links out of freshmeat's xml data.

Sounds good, feel free to take this example as a use case for the design
work :-)

-- 
 \ “The Things to do are: the things that need doing, that you see |
  `\ need to be done, and that no one else seems to see need to be |
_o__)   done.” —Richard Buckminster Fuller, 1970-02-16 |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Possible mass bug filing: non-doc packages recommending doc packages

[Ben Finney]

Steve Langasek  writes:

> Yes, and the MBF proposal *doesn't* take into account packages that
> previously *did* have a hard dep on their doc packages and only
> demoted it to a Recommends: once the default behavior changed.
> 
> Cf.  swat, samba-doc.

Wouldn't this MBF shake out which packages actually have good reason for
a strong (i.e. pulled-in-by-default-package-tool-behaviour) dependency
relationship to their docs from those that do not? That seems like a
good reason to go through this exercise.

-- 
 \ “There is something wonderful in seeing a wrong-headed majority |
  `\   assailed by truth.” —John Kenneth Galbraith, 1989-07-28 |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: postfix as default-mta? [Re: Bug#508644: new release goal default-mta?]

[Micah Anderson]

This discussion has happened before, many times. Some folks spent some
time on a wiki page describing the different MTAs, would be worth
reviewing for some background and comparison:

http://wiki.debian.org/DefaultMTA

Some people clearly want postfix as the default MTA in Debian (I do),
and some people dont want the default to change from Exim. There are
some people who want something else, but so far that something else has
not be technically satisfactory. 

I think our problem is, how do we go about making this decision? 

Micah

--
#debian-devel:
09:35 < Zugschlus> the exim maintainers  absolutely demand that postfix be 
default MTA for lenny
09:35 < Zugschlus> have the postfixites feel the pain they deserve
09:36 < Zugschlus> let the LOUD people have the work they want  
09:44 < Zugschlus> realist: I fully admit that postfix is vastly superior over 
exim
09:45 < Zugschlus> end of discussion
  


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: deprecating /usr as a standalone filesystem?

[Goswin von Brederlow]

Stefano Zacchiroli  writes:

> On Wed, May 06, 2009 at 12:10:54AM +0200, Joerg Jaspert wrote:
>> > So, does anybody still see reasons to continue supporting a standalone
>> > /usr?
>> There had been lots of responses to that.
>
> Yes, the most repeated argument has been mount /usr via NFS.
> Unfortunately, nobody yet explained how do they update the resulting
> cluster of machines.

On the NFS server you install a full system in a chroot (or run it as
xen/kvm/... instace for maintainance).

On clients during boot you run

rsync -avPSHx --exclude-from=host-files server:chroot/ /

The host-files lists some files in /etc/ and /var and also /usr and
/home and other directories you NFS mount.

> Of course the problem is that if you update on the NFS server, then
> related /etc and /var files [1] will not get updated on the NFS client
> machines and you need to propagate changes there. I see as quite
> pointless to use "let's export /usr via NFS" as an argument, if Debian
> does not provide a way to make that setup tenable.

ACK. There is really not much point in having / local. It is easy
enough to use nfs-root and overlay a host specific /etc and
/var. People might just not be used to it.

Networking is not a good argument why /usr must be kept
seperate. Stick to the other reasons mentioned.

> ACK on your second clarification request, though.
>
> Cheers.
>
> [1] Or anything else actually, given that maintainer scripts can
> affect basically all the filesystem.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: deprecating /usr as a standalone filesystem? [386 support]

[Goswin von Brederlow]

Josselin Mouette  writes:

> Le mardi 05 mai 2009 à 23:38 +0200, Frank Lin PIAT a écrit :
>> Interesting. I thought 386 wasn't supported anymore (?)
>
> AFAIK the kernel is able to emulate a 486 when running on a 386.

Afaik only when properly patched to do so and including glibc patches.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: deprecating /usr as a standalone filesystem?

[Goswin von Brederlow]

Giacomo Catenazzi  writes:

> Roger Leigh wrote:
>> On Tue, May 05, 2009 at 05:41:06PM +0200, Stéphane Glondu wrote:
>>> Marco d'Itri a écrit :
 I know that Debian supports this, but I also know that maintaning
 forever large changes to packages for no real gain sucks.
 A partial list of invalid reasons is: [...]
>>> How about: "my /usr is shared by many machines over NFS"?
>> 
>> That might have been a "traditional" reason for a shared /usr.
>> However, the package manager can't cope with this setup since
>> you have some components of a package installed locally and
>> some remotely for all systems using the "shared" part.  It's
>> an impossible situation to actually cater for in real life.
>> Has anyone ever actually *done* this?
>
> So why we created /usr/share (and moved documentation) ?

.oO(preparing for Multiarch support :)

> I see a lot of parallel installed system, so in this case
> I see no problem on sharing /usr.
> [BTW one of the most important conference is not LISA, about
> such configurations?]
>
> But also I don't think it is a problem sharing usr
> on multiple system with multiple configurations.
>
> On non public working stations, one doesn't run randomly
> programs. If I installed mysql-server on a system,
> it will work on such system, but if I install on
> an other system, it work also on the other system,
> occupying only one instance.
>
> I don't see problem from package management
> (also because we have a nullpotent dpkg), so
> we can upgrade from multiple system without problems.

apt-get install libmysqlclient16
apt-get remove --purge libmysqlclient16

and suddenly your other system has a broken mysql-server.

With your setup you can only install packages savely but not remove
them. Which one can decide to live with.

>> Looking at GNU/Hurd, /usr is a symlink to /.  If we were to make
>> /usr non-separable, maybe this would be the way to go.
>
> or plan9, which bind mount all /*/bin into the main /bin.
> I can live with such solution, but please allow us to use /usr
> in a different (maybe shared) partition.
>
> ciao
>   cate

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: deprecating /usr as a standalone filesystem?

[Goswin von Brederlow]

Roger Leigh  writes:

> On Tue, May 05, 2009 at 06:49:47PM +0200, Josselin Mouette wrote:
>> Le mardi 05 mai 2009 à 17:24 +0100, Roger Leigh a écrit :
>> > That might have been a "traditional" reason for a shared /usr.
>> > However, the package manager can't cope with this setup since
>> > you have some components of a package installed locally and
>> > some remotely for all systems using the "shared" part.  It's
>> > an impossible situation to actually cater for in real life.
>> > Has anyone ever actually *done* this?
>> 
>> Of course, you just need to think the image you actually update as a
>> master image, after which it is replicated by any means necessary (be it
>> systemimager or NFS).
>
> Sure, but you effectively only have "one" master image.  You don't
> have multiple users of /usr with differing /etc or /var.  They are
> all kept in sync.  This kind of makes /usr redundant since it is
> "sharable" but only among identical systems or else you will run
> into problems.

The important part would be that a small / is replicated across all
hosts. Possibly automatically on boot whenever it changed. The large
/usr on the other hand is exported via NFS. This keeps the amount of
data being replicated small.

>> As for NFS, I’d use root NFS instead of complicating my life with two
>> different methods for / and /usr, but I guess some are doing it this
>> way.
>
> On the compute cluster I helped set up for biological modelling, we
> opted to use Debian Live images on the cluster.  It IIRC NFS mounts
> a read-only cramfs filesystem and uses aufs on top of that.  There's
> just the one big filesystem (plus some site-specific mounts for
> shared data and a big scratch area all the nodes can access).  We
> certainly saw no point in making just /usr mountable since you need
> a matching rootfs to accompany it.

I have a setup with unionfs-fuse for xen/kvm instances here. I have
one master tree that every instance mounts read-only and unionfs-fuse
overlays a read-write branch from server:/srv/rw//.

But just like you I don't need a seperate /usr for that.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: ignoring the CoC in regards to cc:s (Re: Can we ship sources of a PDF file in the Debian diff?

[Miles Bader]

Ben Finney  writes:
>> You're arguing that a Reply-To header is "harmful" (not that I am
>> convinced)
>
> That field is very useful. What's harmful is mailing-list software
> munging that field, which is for the author to set and for nothing else
> to fiddle with.

Yup.   Reply-To is for the _original sender's_ use!

If mailing list software were to start setting Reply-To, what is it
supposed to do if it gets a message with Reply-To already set (by the
original sender)?  It could (1) overwrite the original Reply-To header,
breaking personal replies to the sender, or it could (2) refrain from
setting Reply-To for such messages, completely confusing the readers who
have become accustomed to depending on the mailing-list's setting.

I think there's no perfect solution to the general problem, because
there's too wide a variety of MUAs in use, which support different
feature sets.  But it's much better to get "duplicate" messages in some
cases than to break things in a way that leads to _lost_ messages.

My experience is that in practice, it's not such a huge problem anyway;
a combination of MUA list-followup commands + Mail-Followup-To: headers
+ MUA duplicate suppression seems to keep duplicates in check reasonably
well...

-Miles

-- 
If you can't beat them, arrange to have them beaten.  [George Carlin]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: deprecating /usr as a standalone filesystem?

[Goswin von Brederlow]

m...@linux.it (Marco d'Itri) writes:

> I have been told by upstream maintainers of one of my packages and by
> prominent developers of other distributions that supporting a standalone
> /usr is too much work and no other distribution worth mentioning does it
> (not Ubuntu, not Fedora, not SuSE).
>
> I know that Debian supports this, but I also know that maintaning
> forever large changes to packages for no real gain sucks.
>
> So, does anybody still see reasons to continue supporting a standalone
> /usr?
> If you do, please provide a detailed real-world use case.
> A partial list of invalid reasons is:
> - "I heard that this was popular in 1998"
> - "it's a longstanding tradition to support this"
> - "it's really useful on my 386 SX with a 40 MB hard disk"
>
> -- 
> ciao,
> Marco

Home case:

/ is a small raid1 that is directly booted into without initramfs
/usr is on lvm on raid5

Without a seperate /usr this would require the use of an initramfs and
seperate /boot partition or much more space.


Work case:

/ is an initramfs
/usr is shared over network for many hosts


Useability reasons:

- If fsck repairs anything while checking / the system has to
  reboot. All other filesystems can just continue. By splitting / and
  /usr there is less of a chance of / needing repair saving the reboot.

- Fsck for / is run first and then other filesystems can run in parallel.

- Less chance of filesystem corruption on / if /usr is another
  filesystem. That also means I can still boot even when /usr is
  damaged and then try to repair it.

- / is small and relatively constant while /usr grows all the
  time. With / outside LVM it can be booted directly and /usr inside
  LVM allows easy resize when more space is needed.

- / contains data that might need to be encrypted (/etc) while /usr
  can be left plain for more speed/less cpu usage.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Possible mass bug filing: non-doc packages recommending doc packages

[Russ Allbery]

Neil Williams  writes:

> In which case, the MBF could concentrate more on libraries and other
> packages that have -doc packages rather than on
> applications. Libraries that Recommend: libfoo-doc (as mine did and
> which I'll fix in the next upload) could conceivably be bringing in
> the docs not when someone is debugging the library itself (when the
> docs are useful) but when someone is debugging a reverse dependency -
> quite possibly for a bug that doesn't relate to the functionality
> provided by the library.

Hm, that's a good point.  libfoo-dev recommending libfoo-doc makes a lot
of sense to me, but libfoo1 shouldn't be recommending a *-doc package.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Possible mass bug filing: non-doc packages recommending doc packages

[Russ Allbery]

Giacomo Catenazzi  writes:
> Y Giridhar Appaji Nag wrote:

>> Would there be any objections to filing minor/wishlist bugs against
>> these packages?  I am including a tentative dd-list corresponding to
>> the packages [1] that I found after manually removing some packages
>> [2].  I will modify it based on suggestions.

> I think that lintian warning is the right way to do it.

I don't -- I think there are too many false positives for a lintian
warning given the thread.  I also think this is fundamentally going in
the wrong direction.  Wouldn't our users expect to get the documentation
with many of these packages by default?  Normally you do get some
documentation with things, and I've always been surprised by, say, ntp
not including any documentation without installing a separate package.

> As we see, there are a lot of "false positives", so an eventual mass
> bug filling will require a lot of manual check before filling the bug
> (yes, I think the main task in this case should be on the reporter,
> not on the maintainer).

If there are too many false positives for a mass bug filing, there are
probably too many false positives for a Lintian check.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Breaking /emul/ia32-linux for squeeze

[Goswin von Brederlow]

Clint Adams  writes:

> On Wed, Mar 11, 2009 at 10:10:13PM -0700, Steve Langasek wrote:
>> But moving the 32-bit libs to /usr/lib32 does not make us
>> standards-conformant on amd64, because the FHS (yuckily) standardized on
>> storing the *32-bit* libs in /usr/lib on this architecture, with 64-bit libs
>> in /usr/lib64.
>
> That is true, which means that someone will undoubtedly file FHS-violation 
> bugs
> on anything using /usr/lib32 after such a transition.

Exactly. You go from the wrong place to another wrong place. Nothing
gained but bug reports.

> On Thu, Mar 12, 2009 at 10:53:21AM +0100, Goswin von Brederlow wrote:
>> NO NO NO NO NO NO NO NO.
>> 
>> It is high time to change to the multiarch dir. For that gcc needs to
>> be fixed first so compiling 32bit code does not break. Transitioning
>> to /usr/lib32 will just needlessly break systems.
>
> The rest of this thread gives me the impression that
> 1) there is precious little chance that multiarch will happen anytime 
> reasonably soon

gcc-4.4 has a new multiarch patch included. It is still buggy but it
makes me hopes the gcc maintainers care about it.

> 2) there is no point in using multiarch directories instead of /usr/lib32 
> prematurely
>
> Aurélien and I are talking about switching to /usr/lib32 somewhere around the 
> time
> that (E)GLIBC hits sid.

You do realize what that entails, right? /usr/lib32 is currently a
link so you need a predepends on libc6 in every 32bit package.

> Are we going to have multiarch soon so that project can be abandoned?

Imho once the default gcc can link against libraries in
/usr/lib/i486-linux-gnu with "gcc -m32" that directory can be
populated. The libfoo i386 multiarch package will have to Conflicts:
lib32foo in any case as far as I'm concerned to avoid two versions of
the same lib to be available no matter where they are located. Having
them both in /usr/lib/i486-linux-gnu just adds the need for "Replaces:
lib32foo" which I don't consider a bad thing.


On the road to true multiarch there is another step though that you
(glibc maintainers) can work on. The split of libc6 into libc6 and
libc6-bin. Policy requires that already but the last ftp-master did
shut it down of fear of breaking things. Maybe time would be better
spend implementing and extensively testing the split rather than a
unneccessary transition to /usr/lib32.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: postfix as default-mta? [Re: Bug#508644: new release goal default-mta?]

[Jens Peter Secher]

2009/5/6 Josselin Mouette :
> Le mercredi 06 mai 2009 à 23:29 +0200, Luk Claes a écrit :
>> Maybe we should also consider changing the default MTA to postfix?
>
> Given that the default configuration is extremely simplistic and doesn’t
> use a percent of either exim or postfix features, I still wonder why it
> is not something like nullmailer or ssmtp.
>

+1 for ssmtp
-- 
Jens Peter Secher.
_DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_.
A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: texlive restrictive licence in main prevents derived works?

[Neil Williams]

On Fri, 08 May 2009 22:27:52 +0200
Frank Küster  wrote:

> >> Long discussion, please see debian-legal quite some time ago. The
> >> point is that modifications are allowed but the modifyied work
> >> needs to be renamed (like with tex the program) as long as the
> >> status of the packages is "Maintained" plus prominent notices etc.
> >> http://lists.debian.org/debian-legal/2004/07/msg00079.html
> >> and many other links.
> >
> > OK, it's just a naming thing. Not sure how we can handle that in
> > Emdebian - renaming isn't automated, at least not currently.
> 
> Renaming won't work, because it's not about filenames, it's about
> "identification to the interpreter". In other words, if the license of
> foo.sty requires it be distributed together with foo.pdf, you are
> allowed to rename the whole thing to bar, but then bar.sty (or still
> call it foo.sty if you prefer) must identify itself as "Package bar
> [$date]", and you'll get "foo was requested, bar was loaded" fatal
> errors. 

It looks like packages that build-depend on tex* will simply not build
on Emdebian Grip - for (of all things) legal reasons - without pulling
the unchanged Debian packages. It means bringing in the massive
Packages.gz file from Debian but then, the texlive dependencies aren't
exactly small.

Probably the easiest way to do that is simply remove tex* packages from
Emdebian Grip unconditionally. (Grip is filtered, we can easily prevent
Debian packages being included into Grip.)

Are there other packages anyone knows about that prevent the removal
of /usr/share/doc/foo by some automated process for legal reasons?

> > Hence why I'd like to understand the problem and work out how
> > Emdebian can have useful packages like docbook-utils without
> > getting into problems with tex.
> 
> I hope there's a different way to go: Identify which TeX/LaTeX styles
> are really needed by docbook-utils, and then let's create a package
> just for that. If it's still not small enough, including the docs,
> then let's start thinking again. What about
> 
> if $this_is_embedian rm $docfiles
> 
> in postinst?

That means downloading the docfiles in the first place which is what we
avoid by using Emdebian Grip. If the unchanged package needs to be
downloaded, it's not that much of a gain over having the package from
Debian unchanged, which is what it sounds like we would have to do.
 
> > It wouldn't be so bad if texlive-base didn't depend (not recommend)
> > texlive-doc-base.
> 
> What's the problem with that package?

Emdebian Grip drops Recommends so the problem goes away entirely - at
least it would if the resulting package was legal and would work as a
build dependency.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/



pgpnS6EyEbaRf.pgp
Description: PGP signature

ITP: mbrola-{af1,br3,cr1,cz2,de7,gr2,hu1,id1,it3,it4,la1,nl2,pl1,pt1,ro1,sw1,sw2} -- various voices for Mbrola

[Samuel Thibault]

Hello,

Here is a list of ITPs for various mbrola voices.  This completes the set
up to what espeak is able to use, except a few duplicates (there are a
lot of german voices, I only kept a good male and a good female voice).

Samuel

#527758 ITP: mbrola-af1 -- Afrikaans male voice for Mbrola
* Package name: mbrola-af1
  Version : 0.0.20040426-1
  Upstream Author : Faculte Polytechnique de  Mons  -  mbrola team 

* URL : http://tcts.fpms.ac.be/synthesis
* License : see the file readme.txt in the source zip: non-free as in
without source code, and for non-commercial, non-military
purposes, with and only with the mbrola package made
available by the author.
  Description : Afrikaans male voice for Mbrola
 This package contains an Afrikaans diphone database provided in the context
 of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
 .
 It provides an Afrikaans male voice to be used with the MBROLA
 program.

#527760 ITP: mbrola-br3 -- Brazilian Portuguese male voice for Mbrola
* Package name: mbrola-br3
  Version : 2.021-1
  Upstream Author : Faculte Polytechnique de  Mons  -  mbrola team 

* URL : http://tcts.fpms.ac.be/synthesis
* License : see the file readme.txt in the source zip: non-free as in
without source code, and for non-commercial, non-military
purposes, with and only with the mbrola package made
available by the author.
  Description : Brazilian Portuguese male voice for Mbrola
 This package contains a Brazilian Portuguese diphone database provided in the 
context
 of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
 .
 It provides a Brazilian Portuguese male voice to be used with the MBROLA
 program.

#527763 ITP: mbrola-cr1 -- Croatian male voice for Mbrola
* Package name: mbrola-cr1
  Version : 0.0.19981028-1
  Upstream Author : Faculte Polytechnique de  Mons  -  mbrola team 

* URL : http://tcts.fpms.ac.be/synthesis
* License : see the file readme.txt in the source zip: non-free as in
without source code, and for non-commercial, non-military
purposes, with and only with the mbrola package made
available by the author.
  Description : Croatian male voice for Mbrola
 This package contains a Croatian diphone database provided in the context
 of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
 .
 It provides a Croatian male voice to be used with the MBROLA
 program.

#527764 ITP: mbrola-cz2 -- Czech male voice for Mbrola
* Package name: mbrola-cz2
  Version : 0.2-1
  Upstream Author : Faculte Polytechnique de  Mons  -  mbrola team 

* URL : http://tcts.fpms.ac.be/synthesis
* License : see the file readme.txt in the source zip: non-free as in
without source code, and for non-commercial, non-military
purposes, with and only with the mbrola package made
available by the author.
  Description : Czech male voice for Mbrola
 This package contains a Czech diphone database provided in the context
 of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
 .
 It provides a Czech male voice to be used with the MBROLA
 program.

#527766 ITP: mbrola-de7 -- German female voice for Mbrola
* Package name: mbrola-de7
  Version : 0.0.20030404-1
  Upstream Author : Faculte Polytechnique de  Mons  -  mbrola team 

* URL : http://tcts.fpms.ac.be/synthesis
* License : see the file readme.txt in the source zip: non-free as in
without source code, and for non-commercial, non-military
purposes, with and only with the mbrola package made
available by the author.
  Description : German female voice for Mbrola
 This package contains a German diphone database provided in the context
 of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
 .
 It provides a German female voice to be used with the MBROLA
 program.

#527767 ITP: mbrola-gr2 -- Greek male voice for Mbrola
* Package name: mbrola-gr2
  Version : 0.0.20010521-1
  Upstream Author : Faculte Polytechnique de  Mons  -  mbrola team 

* URL : http://tcts.fpms.ac.be/synthesis
* License : see the file readme.txt in the source zip: non-free as in
without source code, and for non-commercial, non-military
purposes, with and only with the mbrola package made
available by the author.
  Description : Greek male voice for Mbrola
 This package contains a Greek diphone database provided in the context
 of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
 .
 It provides a Greek male voice to be used with the MBROLA
 program.

#527769 ITP: mbrola-hu1 -- Hungarian female voic

Re: texlive restrictive licence in main prevents derived works?

[Frank Küster]

Neil Williams  wrote:

> On Fri, 8 May 2009 13:10:02 +0200
> Norbert Preining  wrote:
>
>> > How did that get into main?
>> 
>> Long discussion, please see debian-legal quite some time ago. The point
>> is that modifications are allowed but the modifyied work needs to be
>> renamed (like with tex the program) as long as the status of the
>> packages is "Maintained" plus prominent notices etc.
>> http://lists.debian.org/debian-legal/2004/07/msg00079.html
>> and many other links.
>
> OK, it's just a naming thing. Not sure how we can handle that in
> Emdebian - renaming isn't automated, at least not currently.

Renaming won't work, because it's not about filenames, it's about
"identification to the interpreter". In other words, if the license of
foo.sty requires it be distributed together with foo.pdf, you are
allowed to rename the whole thing to bar, but then bar.sty (or still
call it foo.sty if you prefer) must identify itself as "Package bar
[$date]", and you'll get "foo was requested, bar was loaded" fatal
errors. 

> Hence why I'd like to understand the problem and work out how Emdebian
> can have useful packages like docbook-utils without getting into
> problems with tex.

I hope there's a different way to go: Identify which TeX/LaTeX styles
are really needed by docbook-utils, and then let's create a package just
for that. If it's still not small enough, including the docs, then let's
start thinking again. What about

if $this_is_embedian rm $docfiles

in postinst?

> It wouldn't be so bad if texlive-base didn't depend (not recommend)
> texlive-doc-base.

What's the problem with that package?

Package: texlive-doc-base
Priority: optional
Section: tex
Installed-Size: 1216

I don't think the dependency's needed - I think it was just because we
found it easier to have texlive-base Depend on it, instead of every doc
package (which Depend's on texlive-base anyway) Depend'ing on it.

Regards, Frank



-- 
Dr. Frank Küster
Debian Developer (TeXLive)
VCD Aschaffenburg-Miltenberg, ADFC Miltenberg
B90/Grüne KV Miltenberg


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#527748: ITP: libdigest-whirlpool-perl -- Digest::Whirlpool - A 512-bit, collision-resistant, one-way hash function

[James Bromberger]

Package: wnpp
Severity: wishlist
Owner: James Bromberger 


* Package name: libdigest-whirlpool-perl
  Version : 1.0.6
  Upstream Author : Æar ArnfjöBjarmason 
* URL : http://search.cpan.org/dist/Digest-Whirlpool/Whirlpool.pm
* License : Artistic
  Programming Lang: Perl
  Description : Digest::Whirlpool - A 512-bit, collision-resistant, one-way 
hash function

WHIRLPOOL is a 512-bit, collision-resistant, one-way hash function developed by 
Paulo S. L. M. Barreto and Vincent Rijmen. It has been recommended by the 
NESSIE project (along with SHA-256/384/512) and adopted as ISO/IEC 10118-3.

-- System Information:
Debian Release: 5.0.1
  APT prefers stable
  APT policy: (900, 'stable'), (500, 'testing')
Architecture: i386 (i686)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Possible mass bug filing: non-doc packages recommending doc packages

[Frank Küster]

Neil Williams  wrote:

> On Fri, 08 May 2009 11:59:27 +0200
> Frank Küster  wrote:
>
>> Frank Lin PIAT  wrote:
>> 
>> > The development documentation for libraries and programming languages
>> > should not be installed by the runtime.
>> >
>> > This probably means that packages like perl, python, texlive... should
>> > provide a $foo, $foo-doc and $foo-runtime (or -bin, or lib$foo, or
>> > whatever). Other package that needs to depend on that tool should then
>> > depend on $foo-runtime.
>> 
>> How could we separate texlive-$foo and texlive-$foo-runtime? 
>> 
>> And would it make any sense? While many people install python just
>> because an application they want needs the interpreter, users don't
>> usually install a TeX system because something needs it - but because
>> they want to right texts.
>
> Not true, I have

Very true, had I written what I had in mind: s/users/most users/. 

>> Only in the special case of software documentation does it happen that
>> the documentation is completely written, and the "user" (developer or
>> buildd) just needs the "runtime".
>
> Umm, we have a lot of people writing and building software
> documentation in things like docbook 

And that's good, but it's still a special case. 

Instead of discussing doc or nodoc, it would be much more valuable if
someone could tell us which LaTeX packages are really needed by docbook
and similar documentation systems, so that we could taylor a minmal
package for that - without a doc dependency.

Regards, Frank
-- 
Dr. Frank Küster
Debian Developer (TeXLive)
VCD Aschaffenburg-Miltenberg, ADFC Miltenberg
B90/Grüne KV Miltenberg


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Possible mass bug filing: non-doc packages recommending doc packages

[Don Armstrong]

On Thu, 07 May 2009, Y Giridhar Appaji Nag wrote:
> From policy 7.2 Binary Dependencies - Depends, Recommends, Suggests, Enhances,
> Pre-Depends
> 
> Recommends
> 
> This declares a strong, but not absolute, dependency.
> 
> The Recommends field should list packages that would be found together
> with this one in all but unusual installations.

This determination is necessarily a judgement call, and is kind of up
to the maintainer. If you run across specific instances of packages
where the documentation Recommends appears gratuitous, filing wishlist
bugs with specific rationale that would be convincing to the
maintainer is reasonable, but it shouldn't be a mass filing. Frankly,
if I were you, I'd restrict myself to particularly large -doc packages
which are pulled in by packages with high popcon scores to start with,
at least.

> With Install-Recommends being the default, many packages pull in a
> lot of associated documentation. These documentation packages are
> sometimes large and could be suggested rather than recommended.

In cases where you actually care about the size of the documentation,
you're presumably being extra careful about the packages which are
Recommends:, and probably aren't installing them automatically.


Don Armstrong

-- 
This message brought to you by weapons of mass destruction related
program activities, and the letter G.

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Possible mass bug filing: non-doc packages recommending doc packages

[Steve Langasek]

On Fri, May 08, 2009 at 06:55:43PM +0200, Stefano Zacchiroli wrote:
> On Fri, May 08, 2009 at 10:14:05AM +0200, Frank Lin PIAT wrote:
> > While I support the effort to reduce disk space usage, I strongly
> > disagree with this proposal.

> > A software is worth nothing without appropriate documentation.

> No, that's subjective, with the subject being the package
> maintainer. If the maintainer considered the software "worth nothing"
> without doc, he could have (in the past) marked the -doc package as
> *dependency* as that was the only way in the past to have it installed
> by default.

Yes, and the MBF proposal *doesn't* take into account packages that
previously *did* have a hard dep on their doc packages and only demoted it
to a Recommends: once the default behavior changed.

Cf.  swat, samba-doc.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Using uscan with VCS hosting sites

[Raphael Geissert]

Hi Ben,

Ben Finney wrote:
[...]
> 
> So, how do I go from “the URL for the project source is
> http://bitbucket.org/ned/coveragepy/>”, to a ‘debian/watch’ file
> that will enable ‘uscan’ to discover the current version is
> ‘coverage-3.0b2’, and its original source tarball is downloadable from
> http://bitbucket.org/ned/coveragepy/get/79dd373074de.gz>?
> 

I can't think of any way to do what you want with version 2/3 watch files.
It should be possible to do it once the version four watch files spec is
established and implemented, as I do plan to add support to extract the
version information from a plain text (or anything that can be parsed as
plain text) file and later build a url with it. I must say that I haven't
yet decided how to do that, as I guess some would need to extract the base
url from some other page, or find the final link based on the version on
some other page, or so.

What you want is basically #395439 plus a feature that could be used to
build links out of freshmeat's xml data.

Cheers,
Raphael Geissert



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: postfix as default-mta? [Re: Bug#508644: new release goal default-mta?]

[Wolf Wiegand]

Hi,

Christian Surchi wrote:

> ssmpt is not able to handle a queue, so I imagine that it needs
> necessarily a permanent connection with a smarthost... am I wrong? 

No, you're right.

> I don't like this one for *any* machine.

I wouldn't like this as the default debian setup. Risking losing mails
isn't an option.

Actually, for the default setup, I'd prefer a solution that targets the
Joe Normal-user who doesn't (want to) know what an MTA is for, because
he/she only uses an MUA that delivers mail to the provider's smarthost
anyway (Thunderbird or Evolution for example).

For example: By default, install a very minimalistic MTA that only
delivers mail to the local spool file (and that cannot be configured to
do anything else). Then introduce a way to notify the user when there's
new mail in the spool file and to directly show the mail to the user
(Maybe an extra tool running under Gnome or KDE. Or a default
Thunderbird/Evolution-configuration that will always fetch mails from
the spool file).

Everyone who needs more than this (probably most of the
debian-devel-audience, including me) can install $preferred_mta.


Cheers,

Wolf
-- 
Sünde ist nicht eine begrenzte Liste moralischer Verfehlungen. Sünde ist eine 
selbstbezogene Lebensführung, in der Menschen die Konsequenzen ihrer 
Handlungsweise ignorieren. (Richard Chartres, Bischof von London)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Possible mass bug filing: non-doc packages recommending doc packages

[Josselin Mouette]

Le jeudi 07 mai 2009 à 17:55 +0530, Y Giridhar Appaji Nag a écrit :
> Debian GNOME Maintainers 
>devhelp (U)

False positive. A documentation browser is useless without documentation
to browse.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


signature.asc
Description: Ceci est une partie de message numériquement signée

Re: Possible mass bug filing: non-doc packages recommending doc packages

[Stefano Zacchiroli]

On Fri, May 08, 2009 at 10:14:05AM +0200, Frank Lin PIAT wrote:
> While I support the effort to reduce disk space usage, I strongly
> disagree with this proposal.
> 
> A software is worth nothing without appropriate documentation.

No, that's subjective, with the subject being the package
maintainer. If the maintainer considered the software "worth nothing"
without doc, he could have (in the past) marked the -doc package as
*dependency* as that was the only way in the past to have it installed
by default.

I don't think that the mere fact that we changed the default behavior
of apt-get/aptitude should get in the way of that maintainer's
choice. If we used to live in a world where, by maintainer choice, doc
was not installed by default, that world should IMO stay the same.

That is why I interpret the spirit of the proposal, and that is why
I'm in favor of it.

Just my 0.02€,
Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: Possible mass bug filing: non-doc packages recommending doc packages

[Stefano Zacchiroli]

On Thu, May 07, 2009 at 09:47:56PM -0700, Daniel Burrows wrote:
>   As a practical matter, downgrading these dependencies will cause
> aptitude and other package managers to believe that the documentation
> is unnecessary and suggest removing it.

Even if the user marked as non-automatic the involved -doc packages?

Anyhow, even if it is the case, I'm tempted to just reply "too
bad". The admin will notice that and take it as an occasion for doing
a review of which doc she really wants and which she wants not.

Also, I see no other way of doing that transition ... Do you have any
aptitude-fu suggestion? :)

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: Possible mass bug filing: non-doc packages recommending doc packages

[Carsten Hey]

On Fri, May 08, 2009 at 04:06:47PM +0200, Cyril Brulebois wrote:
> Daniel Burrows  (07/05/2009):
> >   As a practical matter, downgrading these dependencies will cause
> > aptitude and other package managers to believe that the documentation
> > is unnecessary and suggest removing it.
>
> So that one has a chance to notice possibly unneeded doc? Works for me.

You don't need to wait for these dependencies to be changed to notice
possibly unneeded docs:

deborphan -n --guess-doc | grep -- '-doc$'

The need to grep for doc packages for this use case can be avoided after
a option to ignore libraries has been be added to deborphan, which will
happen when tags replace sections in Debian or, if requested, earlier.


Carsten


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Possible mass bug filing: non-doc packages recommending doc packages

[Cyril Brulebois]

Daniel Burrows  (07/05/2009):
>   As a practical matter, downgrading these dependencies will cause
> aptitude and other package managers to believe that the documentation
> is unnecessary and suggest removing it.

So that one has a chance to notice possibly unneeded doc? Works for me.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: texlive restrictive licence in main prevents derived works?

[Norbert Preining]

On Fr, 08 Mai 2009, Neil Williams wrote:
> It wouldn't be so bad if texlive-base didn't depend (not recommend)
> texlive-doc-base.

But texlive-doc-base is absolutely minimal, are you concerned about the
size of this small package?

> I still want to *not* have to install texlive-doc-base on systems that
> only want to use docbook-utils and have Install-Recommends turned off. I
> don't see why texlive makes that impossible.

Hmm, doc-base contains the most basic documentation of the system. Well,
I guess I can really make that a Recommends, nothing of real importance
here if you prefer.

Best wishes

Norbert

---
Dr. Norbert Preining Vienna University of Technology
Debian Developer  Debian TeX Group
gpg DSA: 0x09C5B094  fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
---
ABERCRAVE (vb.)
To strongly desire to swing from the pole on the rear footplate of a
bus.
--- Douglas Adams, The Meaning of Liff


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Book a luxury villa

[LHL]

office and home ltd | 2 shorland drive  | rotherham |  | s60 5up | UK


This email was sent to debian-devel@lists.debian.org, by 
f...@office-n-home.co.uk.
To unsubscribe from this list - please use this link: 
http://app.simplycast.com/unsubscribe.asp?outgoing_idno=5504948&e=3008852&gId=5503551.
 If this message was received in error, please report it to:
 mailto:repor...@scsend.com?subject=5503551z3008852z5504948
This email was powered by http://www.simplycast.com

Re: deprecating /usr as a standalone filesystem?

[Brett Parker]

On 08 May 14:35, Peter Palfrader wrote:
> On Fri, 08 May 2009, David Weinehall wrote:
> 
> > On Thu, May 07, 2009 at 07:27:08PM -0500, Manoj Srivastava wrote:
> > > No. But we do leave /usr read-only the rest of the time, which
> > >  is often 99.999% of the time. A separate /usr is required for this.
> > 
> > Uhm, no?
> > 
> > mount --bind /usr /usr
> > 
> > Should do the trick (the same mount -o remount,rw / remount,ro then
> > applies).  all thanks to the magic of subtrees :)
> 
> Yeah.  Right.
> 
> wea...@intrepid:~/tmp$ mkdir foo
> wea...@intrepid:~/tmp$ touch foo/bar
> wea...@intrepid:~/tmp$ sudo mount -o bind,ro foo foo
> wea...@intrepid:~/tmp$ touch foo/baz
> wea...@intrepid:~/tmp$ 
> 
> bind mounts don't do ro.

http://lwn.net/Articles/281157/

As of 2.6.26 it's possible, but still not right:
fleur:/tmp# rmdir foo
fleur:/tmp# mkdir foo
fleur:/tmp# touch foo/blah
fleur:/tmp# mount -o bind foo foo
fleur:/tmp# mount -o remount,ro foo
fleur:/tmp# touch foo/blah
touch: cannot touch `foo/blah': Read-only file system
fleur:/tmp# umount foo
fleur:/tmp# touch foo/blah
fleur:/tmp# 

So it works, just not quite as you'd expect :/

Cheers,
-- 
Brett Parker


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: deprecating /usr as a standalone filesystem?

[Peter Palfrader]

On Fri, 08 May 2009, Peter Palfrader wrote:

> wea...@intrepid:~/tmp$ mkdir foo
> wea...@intrepid:~/tmp$ touch foo/bar
> wea...@intrepid:~/tmp$ sudo mount -o bind,ro foo foo
> wea...@intrepid:~/tmp$ touch foo/baz
> wea...@intrepid:~/tmp$ 
> 
> bind mounts don't do ro.

I have been told, that starting with 2.6.26 they do.  But only *iff* the
ro is done with a remount after the initial bind mounting.  How very not
useful.

-- 
   |  .''`.  ** Debian GNU/Linux **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: deprecating /usr as a standalone filesystem?

[Peter Palfrader]

On Fri, 08 May 2009, David Weinehall wrote:

> On Thu, May 07, 2009 at 07:27:08PM -0500, Manoj Srivastava wrote:
> > No. But we do leave /usr read-only the rest of the time, which
> >  is often 99.999% of the time. A separate /usr is required for this.
> 
> Uhm, no?
> 
> mount --bind /usr /usr
> 
> Should do the trick (the same mount -o remount,rw / remount,ro then
> applies).  all thanks to the magic of subtrees :)

Yeah.  Right.

wea...@intrepid:~/tmp$ mkdir foo
wea...@intrepid:~/tmp$ touch foo/bar
wea...@intrepid:~/tmp$ sudo mount -o bind,ro foo foo
wea...@intrepid:~/tmp$ touch foo/baz
wea...@intrepid:~/tmp$ 

bind mounts don't do ro.
-- 
   |  .''`.  ** Debian GNU/Linux **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Possible mass bug filing: non-doc packages recommending doc packages

[Hendrik Sattler]

Zitat von Neil Williams :

I rarely write TeX but I write a lot of docbook and expect to be able
to convert that to PDF when necessary - without needing to care about
how that happens or how to write TeX myself.


Well, you might as well use the FO output and use fop to convert to  
PDF. This implies that you use docbook XML.


HS



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: texlive restrictive licence in main prevents derived works?

[Neil Williams]

On Fri, 8 May 2009 13:10:02 +0200
Norbert Preining  wrote:

> > How did that get into main?
> 
> Long discussion, please see debian-legal quite some time ago. The point
> is that modifications are allowed but the modifyied work needs to be
> renamed (like with tex the program) as long as the status of the
> packages is "Maintained" plus prominent notices etc.
> http://lists.debian.org/debian-legal/2004/07/msg00079.html
> and many other links.

OK, it's just a naming thing. Not sure how we can handle that in
Emdebian - renaming isn't automated, at least not currently. "Gripping"
texlive-doc-base results in only three files:

./usr/share/doc/texlive-doc-base/copyright.gz
./usr/share/bug/texlive-doc-base/script
./usr/share/bug/texlive-doc-base/control

http://www.emdebian.org/grip/

743K 2009-05-08 12:16 texlive-doc-base_2007.dfsg.2-2_all.deb
 18K 2009-05-08 12:22 texlive-doc-base_2007.dfsg.2-2em1_all.deb

Hence why I'd like to understand the problem and work out how Emdebian
can have useful packages like docbook-utils without getting into
problems with tex.

Am I going to have to blacklist packages in main that don't allow
modifications without renaming? There's no easy way of identifying such
packages either.
 
> In fact it was always like that that we installed the doc files
> unconditionally, only on user demand and after recommends were installed
> by default we allowed ourselves after discussion with some upstream
> authors to split the doc files out.
> 
> In fact, there are upstream authors (not texlive upstream, but of the
> tex packages itself) that *force* us also in TeX Live (upstream) to
> include the documentation *in*any*case* (currently only one such case).
> Well, force, we could remove the packages, but that wouldn't be a good
> idea since it is one very important.
> 
> So we are left with the current situation. It is not that bad because
> auto-builders do not install recommends, the rest is up to the sysadmin.

It wouldn't be so bad if texlive-base didn't depend (not recommend)
texlive-doc-base.

This element still remains:

"The bug in that dependency chain is in
texlive-base which has "Depends: texlive-doc-base" - in the context of
'apt-get install docbook-utils', that is entirely unwarranted."

Shouldn't that be a Recommends?

I still want to *not* have to install texlive-doc-base on systems that
only want to use docbook-utils and have Install-Recommends turned off. I
don't see why texlive makes that impossible.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpxxA3V4zIx4.pgp
Description: PGP signature

Re: texlive restrictive licence in main prevents derived works?

[Norbert Preining]

On Fr, 08 Mai 2009, jeffrey.ratcli...@gmail.com wrote:
> And yet on http://www.latex-project.org/lppl/:
> 
> "The LaTeX project public license is a free software license"
> 
> With "free software" being linked to http://www.debian.org/intro/free
> 
> Hmmm...

Argg, google for debian-legal LPPL, thanks.

Best wishes

Norbert

---
Dr. Norbert Preining Vienna University of Technology
Debian Developer  Debian TeX Group
gpg DSA: 0x09C5B094  fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
---
FRAMLINGHAM (n.)
A kind of burglar alarm usage. It is cunningly designed so that it can
ring at full volume in the street without apparently disturbing
anyone. Other types of framlingams are burglar alarms fitted to
business premises in residential areas, which go off as a matter of
regular routine at 5.31 p.m. on a Friday evening and do not get turned
off til 9.20 a.m. on Monday morning.
--- Douglas Adams, The Meaning of Liff


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#527557: marked as done (general: should have a help tracker for each package)

[Debian Bug Tracking System]

Your message dated Fri, 8 May 2009 13:15:18 +0200
with message-id <200905081315.25576.hol...@layer-acht.org>
and subject line Re: Bug#527557: general: should have a help tracker for each 
package
has caused the Debian Bug report #527557,
regarding general: should have a help tracker for each package
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
527557: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=527557
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: general
Severity: wishlist

Just an idea.

Currently, when I am using a new package, or if I have queries
regarding the new package, my friends are upstream and the web.
Usually, not much authentic information.

I am requesting a tracker kind approach for each package.
It could be very similar to Debian BTS. When a user has some query
regarding a package, she cannot file a bug report directly unless she's
sure that it is a bug (and not an odd behavior).

I have a query regarding fdm. Then probably I could just file a "help
report" against fdm. It'd go to the same package maintainer.
Most of the times, the package maintainer would be one of the best
person to give helping instructions about queries against any package.

We already have mailing lists, forums et cetera. So why this approach.
Well, when the user has a package, and has some query, asking her to
subscribe to the mailing list (upstream or distrib's) is not really the
very best help.

This definitely would be an extra add-on to the maintainers and there
will be high chances of users asking questions without RTFMing. For
that, we could make the Debian Policy that the "Debian HTS - Debian Help
Tracking System", will in no way relate to release schedule or quality
of the Debian distribution.


I hope my english is play and understandable.

Ritesh

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

Kernel: Linux 2.6.29-1-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


--- End Message ---
--- Begin Message ---
Hi Ritesh,

thank you for your suggestion on how to improve Debian! Even though I'm 
closing this bug on the assumption that it ain't useful to report arbitary 
wishlist bugs about things which could be implemented to improve Debian, no 
matter how sensible they are. 

This assumption is based on three main arguments:

First, there are several places to collect such ideas which IMO are better 
suited, like the Debian wiki or personal idea collections. 

Second and more importantly, if you want such a system, I think *you* should 
implement a working prototype. For example, wiki.debian.net was just done and 
then, as the Debian community liked+used it, it was moved to wiki.debian.org.

Third, yes, discussion in advance of doing such a prototype is useful. But you 
don't need to file bugs to discuss. 


And even though I agree with Neils points in his reply, please don't be 
discouraged by all of this. If you think it's a good idea, by all means go 
for it and show its a cool thing! forums.debian.net is probably an example of 
something which many Debian developers don't (or didnt, when it was started) 
consider particulary useful, but today it has many happy users :-)


regards,
Holger


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

Bug#527594: ITP: python-psutil -- process utilities module for Python

[Sandro Tosi]

Package: wnpp
Severity: wishlist
Owner: Sandro Tosi 

* Package name: python-psutil
  Version : 0.1.2
  Upstream Author : Giampaolo Rodola, Dave Daeschler, Jay Loden 
* URL : http://code.google.com/p/psutil/
* License : BSD
  Programming Lang: C, Python
  Description : process utilities module for Python

 psutil is a module providing an interface for retrieving information on
 running processes and system utilization (CPU, memory) in a portable way
 by using Python, implementing many functionalities offered by tools like
 ps, top and Windows task manager.
 .
 It currently supports Linux, OS X, FreeBSD and Windows.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: texlive restrictive licence in main prevents derived works?

[jeffrey . ratcliffe]

On May 8, 2009 12:58pm, Neil Williams  wrote:

> From the LPPL:
> /---
> | 2. You may distribute a complete, unmodified copy of the Work as you
> | received it. Distribution of only part of the Work is considered
> | modification of the Work, and no right to distribute such a Derived
> | Work may be assumed under the terms of this clause.
> \---


And yet on http://www.latex-project.org/lppl/:

"The LaTeX project public license is a free software license"

With "free software" being linked to http://www.debian.org/intro/free

Hmmm...

Re: texlive restrictive licence in main prevents derived works?

[Norbert Preining]

Hi Neil,

On Fr, 08 Mai 2009, Neil Williams wrote:
> How did that pass DFSG #3?

[...]

> DFSG 3:
> 
> Derived Works
> 
> The license must allow modifications and derived works, and must allow
> them to be distributed under the same terms as the license of the
> original software.
> 
> ? Huh ?
> 
> How did that get into main?

Long discussion, please see debian-legal quite some time ago. The point
is that modifications are allowed but the modifyied work needs to be
renamed (like with tex the program) as long as the status of the
packages is "Maintained" plus prominent notices etc.
http://lists.debian.org/debian-legal/2004/07/msg00079.html
and many other links.

And, no, we will not rename about 1500 TeX-package names.

In fact it was always like that that we installed the doc files
unconditionally, only on user demand and after recommends were installed
by default we allowed ourselves after discussion with some upstream
authors to split the doc files out.

In fact, there are upstream authors (not texlive upstream, but of the
tex packages itself) that *force* us also in TeX Live (upstream) to
include the documentation *in*any*case* (currently only one such case).
Well, force, we could remove the packages, but that wouldn't be a good
idea since it is one very important.

So we are left with the current situation. It is not that bad because
auto-builders do not install recommends, the rest is up to the sysadmin.

Best wishes

Norbert

---
Dr. Norbert Preining Vienna University of Technology
Debian Developer  Debian TeX Group
gpg DSA: 0x09C5B094  fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
---
NASEBY (n.)
The stout metal instrument used for clipping labels on to exhibits at
flower shows.
--- Douglas Adams, The Meaning of Liff


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

texlive restrictive licence in main prevents derived works?

[Neil Williams]

On Fri, 8 May 2009 12:33:15 +0200
Norbert Preining  wrote:

> On Fr, 08 Mai 2009, Neil Williams wrote:
> > TeX docs should only be installed on systems where users need to write
> > TeX - any dependencies that bring in TeX docs merely to support
> 
> Come on. That we do NOT install the docs by default is already a
> concession. We could stop this discussion and I kill all the -doc
> pakcages and include the doc files unconditionally into the packages,
> due to the requirements of the LPPL.

How did that pass DFSG #3?
 
> Do you prefer that?

Umm, I prefer DFSG compatibility and the ability to modify the source
and distribute the derived version - including that ability to modify
by judicious use of 'rm'.

If texlive ever gets into Emdebian, the docs will be stripped from the
packages without user interaction. Full stop. :-)

(Indeed, every file in /usr/share/doc/ is unilaterally and
unambiguously erased - the copyright file is retained and compressed.)

> The bottom line is that *without* user interaction the documentation
> files *HAVE*TO*BE*INSTALLED*. Full stop.

Then that, to me, makes the package non-free.
 
> From the LPPL:
> /---
> | 2.  You may distribute a complete, unmodified copy of the Work as you
> | received it.  Distribution of only part of the Work is considered
> | modification of the Work, and no right to distribute such a Derived
> | Work may be assumed under the terms of this clause.
> \---

DFSG 3:

Derived Works

The license must allow modifications and derived works, and must allow
them to be distributed under the same terms as the license of the
original software.

? Huh ?

How did that get into main?

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpU67TJ6N0m9.pgp
Description: PGP signature

Re: deprecating /usr as a standalone filesystem?

[David Weinehall]

On Thu, May 07, 2009 at 07:27:08PM -0500, Manoj Srivastava wrote:
> On Thu, May 07 2009, Ben Finney wrote:
> 
> > Manoj Srivastava  writes:
> >
> >> On Thu, May 07 2009, Josselin Mouette wrote:
> >> 
> >> > Le jeudi 07 mai 2009 à 11:02 +1000, Ben Finney a écrit :
> >> >> Those who want a read-only ‘/usr’ don't seriously try to leave it
> >> >> read-only while installing or upgrading packages, do they?
> >> 
> >> ,[ Excerpt from /etc/apt/apt.conf ]
> >> | DPkg 
> >> | {
> >> |// Auto re-mounting of a readonly /usr
> >> |Pre-Invoke  {"mount -o remount,rw /usr";};
> >> |Post-Invoke {"mount -o remount,ro /usr";};
> >> | };
> >> `
> >
> > Exactly. So this is *not* “leave /usr read-only while installing or
> > upgrading packages”. Thanks for providing another case in point.
> 
> No. But we do leave /usr read-only the rest of the time, which
>  is often 99.999% of the time. A separate /usr is required for this.

Uhm, no?

mount --bind /usr /usr

Should do the trick (the same mount -o remount,rw / remount,ro then
applies).  all thanks to the magic of subtrees :)


Regards: David
-- 
 /) David Weinehall  /) Rime on my window   (\
//  ~   //  Diamond-white roses of fire //
\)  http://www.acc.umu.se/~tao/(/   Beautiful hoar-frost   (/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Possible mass bug filing: non-doc packages recommending doc packages

[Norbert Preining]

On Fr, 08 Mai 2009, Neil Williams wrote:
> TeX docs should only be installed on systems where users need to write
> TeX - any dependencies that bring in TeX docs merely to support

Come on. That we do NOT install the docs by default is already a
concession. We could stop this discussion and I kill all the -doc
pakcages and include the doc files unconditionally into the packages,
due to the requirements of the LPPL.

Do you prefer that?

The bottom line is that *without* user interaction the documentation
files *HAVE*TO*BE*INSTALLED*. Full stop.

>From the LPPL:
/---
| 2.  You may distribute a complete, unmodified copy of the Work as you
| received it.  Distribution of only part of the Work is considered
| modification of the Work, and no right to distribute such a Derived
| Work may be assumed under the terms of this clause.
\---

Best wishes

Norbert

---
Dr. Norbert Preining Vienna University of Technology
Debian Developer  Debian TeX Group
gpg DSA: 0x09C5B094  fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
---
SIMPRIM (n.)
The little movement of false modesty by which a girl with a cavernous
visible cleavage pulls her skirt down over her knees.
--- Douglas Adams, The Meaning of Liff


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Possible mass bug filing: non-doc packages recommending doc packages

[Neil Williams]

On Fri, 08 May 2009 11:59:27 +0200
Frank Küster  wrote:

> Frank Lin PIAT  wrote:
> 
> > The development documentation for libraries and programming languages
> > should not be installed by the runtime.
> >
> > This probably means that packages like perl, python, texlive... should
> > provide a $foo, $foo-doc and $foo-runtime (or -bin, or lib$foo, or
> > whatever). Other package that needs to depend on that tool should then
> > depend on $foo-runtime.
> 
> How could we separate texlive-$foo and texlive-$foo-runtime? 
> 
> And would it make any sense? While many people install python just
> because an application they want needs the interpreter, users don't
> usually install a TeX system because something needs it - but because
> they want to right texts.

Not true, I have various texlive packages installed on systems where
I've never needed to write anything in TeX. I do use latex-beamer on
some systems but one other systems where latex-beamer is not used,
texlive is primarily brought in by docbook-utils, even if I don't need
the TeX parts of docbook-utils. Converting docbook to HTML doesn't need
TeX - only the conversion to PDF-type. We have docbook-xsl and others
for those situations where packages use docbook conversions to HTML at
build-time but docbook-utils is still useful.

Even then, there is no need for someone using docbook2pdf to understand
or even refer to the TeX documentation. Any TeX errors when converting
from docbook to PDF via TeX are a bug in the tool doing the conversion
to TeX, the user cannot be expected to care as long as their docbook
syntax is correct. TeX is not the "source" for that conversion, it is a
step-along-the-way and, as such, does not deserve to have the TeX docs
installed.

TeX docs should only be installed on systems where users need to write
TeX - any dependencies that bring in TeX docs merely to support
converting some other format into TeX as a step to TeX converting that
on to yet another format, IMHO *must not* mandate that the TeX docs are
also installed. texlive needs to make this possible for packages like
docbook-utils. That, to me, means splitting the texlive runtime out
from the docs.

I rarely write TeX but I write a lot of docbook and expect to be able
to convert that to PDF when necessary - without needing to care about
how that happens or how to write TeX myself. Please support
docbook-utils having a dependency *just* on the TeX runtime and not
requiring the TeX docs. The bug in that dependency chain is in
texlive-base which has "Depends: texlive-doc-base" - in the context of
'apt-get install docbook-utils', that is entirely unwarranted.

> Only in the special case of software documentation does it happen that
> the documentation is completely written, and the "user" (developer or
> buildd) just needs the "runtime".

Umm, we have a lot of people writing and building software
documentation in things like docbook 

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgp8hRjcWZl3e.pgp
Description: PGP signature

Re: Possible mass bug filing: non-doc packages recommending doc packages

[Michael Hanke]

On Fri, May 08, 2009 at 08:58:51AM +0200, Andreas Tille wrote:
> On Fri, 8 May 2009, Christian Perrier wrote:
>
>> I bringed the discussion in out maintenance list but dropping
>> Recommends to Suggests is likely to make us provide a "broken" home page
>> for SWAT by default. We could of course patch SWAT so that the page
>> explicitely says that adding samba-doc is needed but that would be
>> glightly ugly.
>>
>> So, that could be seen as a quite calid use case, indeed..:)
>
> As a raw estimation about 50% of the packages I maintain / sponsor use
> the doc package not only as pure standalone doc but the doc might be
> used by the help system of the native program / web application.  You
> might argue that in this case the program should be called *-data, but
> I'd call this nitpicking because the packages in itself are perfectly
> valid doc packages and make sense on their own.  So I do not think that
> this issue is really atarget for mass bug filing because chances for
> false positives are to high.  I'm fine with a lintian warning which
> can be overriden by the maintainer in case he decides recommending the
> doc package is the reight way to go.

+1

and this is what I will do for 'fsl' and 'fslview', since the
corresponding doc packages provide the online-help of the respective
applications -- even though these are plain html files that perfectly
fit into a separate doc package.


Michael

-- 
GPG key:  1024D/3144BE0F Michael Hanke
http://apsy.gse.uni-magdeburg.de/hanke
ICQ: 48230050


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Possible mass bug filing: non-doc packages recommending doc packages

[Frank Küster]

Frank Lin PIAT  wrote:

> The development documentation for libraries and programming languages
> should not be installed by the runtime.
>
> This probably means that packages like perl, python, texlive... should
> provide a $foo, $foo-doc and $foo-runtime (or -bin, or lib$foo, or
> whatever). Other package that needs to depend on that tool should then
> depend on $foo-runtime.

How could we separate texlive-$foo and texlive-$foo-runtime? 

And would it make any sense? While many people install python just
because an application they want needs the interpreter, users don't
usually install a TeX system because something needs it - but because
they want to right texts.

Only in the special case of software documentation does it happen that
the documentation is completely written, and the "user" (developer or
buildd) just needs the "runtime".

Regards, Frank
-- 
Dr. Frank Küster
Debian Developer (TeXLive)
VCD Aschaffenburg-Miltenberg, ADFC Miltenberg
B90/Grüne KV Miltenberg


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Possible mass bug filing: non-doc packages recommending doc packages

[Neil Williams]

On Fri, 8 May 2009 08:58:51 +0200 (CEST)
Andreas Tille  wrote:

> On Fri, 8 May 2009, Christian Perrier wrote:
> 
> > I bringed the discussion in out maintenance list but dropping
> > Recommends to Suggests is likely to make us provide a "broken" home page
> > for SWAT by default. We could of course patch SWAT so that the page
> > explicitely says that adding samba-doc is needed but that would be
> > glightly ugly.
> >
> > So, that could be seen as a quite calid use case, indeed..:)
> 
> As a raw estimation about 50% of the packages I maintain / sponsor use
> the doc package not only as pure standalone doc but the doc might be
> used by the help system of the native program / web application. 

In which case, the MBF could concentrate more on libraries and other
packages that have -doc packages rather than on applications. Libraries
that Recommend: libfoo-doc (as mine did and which I'll fix in the next
upload) could conceivably be bringing in the docs not when someone is
debugging the library itself (when the docs are useful) but when
someone is debugging a reverse dependency - quite possibly for a bug
that doesn't relate to the functionality provided by the library.

It is helpful for applications to be able to load the Help file - as
long as there is a useful message to the user should the -doc package
not be installed for any reason.

> You might argue that in this case the program should be called *-data, but
> I'd call this nitpicking because the packages in itself are perfectly
> valid doc packages and make sense on their own.  So I do not think that
> this issue is really atarget for mass bug filing because chances for
> false positives are to high.  I'm fine with a lintian warning which
> can be overriden by the maintainer in case he decides recommending the
> doc package is the reight way to go.

lintian is probably the best option - a lintian check can also
probably handle the distinction between a library -dev package and an
application package and the 'Certainty' functionality can deal with
corner-cases.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpLCmZoNawuQ.pgp
Description: PGP signature

Re: Possible mass bug filing: non-doc packages recommending doc packages

[Frank Lin PIAT]

On Thu, 2009-05-07 at 17:55 +0530, Y Giridhar Appaji Nag wrote:
> 
> I filed a lintian wishlist bug (#527363) requesting a I/W tag when non
> documentation packages recommend documentation packages.

While I support the effort to reduce disk space usage, I strongly
disagree with this proposal.

A software is worth nothing without appropriate documentation.
When Joe User installs a package, the documentation should be installed
as well, automatically (i.e "apt-get install perl" install the whole
upstream package).

In my opinion, the "main" package logically Depends on the -doc package,
but the actual dependency header is downgraded to Recommend so system
admin can choose to not install it.

I think it would be much nicer to file a bug against APT so the user can
choose to not install "Recommend" dependencies that sits in section
"doc". [APT maintainers will hate me here]

> With Install-Recommends being the default, many packages pull in a lot
> of associated documentation.  These documentation packages are
> sometimes large and could be suggested rather than recommended.  I
> noticed different opinions about such bugs on the BTS (See #504042
> that went on to be fixed and #526153 that was not).

Regarding the perl-doc (Bug #504042), I believe it's a different story.

The development documentation for libraries and programming languages
should not be installed by the runtime.

This probably means that packages like perl, python, texlive... should
provide a $foo, $foo-doc and $foo-runtime (or -bin, or lib$foo, or
whatever). Other package that needs to depend on that tool should then
depend on $foo-runtime.

>   I understand that upstream would sometimes like documentation to be
> installed alongside the binaries

Upstream want it because it's sensible for their (and our) users.

> but popcon numbers of -doc packages are quite lower the numbers
> corresponding to the packages that recommend them.

Don't make popcon statistics lie.

The reason why -doc popcon is much lower than associated package is
because -doc are "recommended" and Debian-installer's tasksel don't
install recommend packages. IIRC

> Would there be any objections to filing minor/wishlist bugs against
> these packages?  I am including a tentative dd-list corresponding to
> the packages[1] that I found after manually removing some packages[2].
> I will modify it based on suggestions.

Regards,

Franklin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: postfix as default-mta? [Re: Bug#508644: new release goal default-mta?]

[Neil Williams]

On Fri, 08 May 2009 08:12:35 +0300
Lars Wirzenius  wrote:

> pe, 2009-05-08 kello 11:43 +0800, Paul Wise kirjoitti:
> > I find the notion of a "default MTA" to be silly. Most desktops or
> > laptops or cellphones proably do not need an MTA. 
> 
> I'd agree, were it not for cron.

At which point, I begin to wonder if 'cron' and 'at' cannot simply be
told to use a log file if no MTA exists. Alternatively, create a
dummy-mta that converts MTA requests into log files without all the
mail headers.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpNJ85TYTvP1.pgp
Description: PGP signature

Bug#527557: general: should have a help tracker for each package

[Neil Williams]

On Fri, 08 May 2009 11:57:35 +0530
Ritesh Raj Sarraf  wrote:

> Currently, when I am using a new package, or if I have queries
> regarding the new package, my friends are upstream and the web.
> Usually, not much authentic information.

$ man package ?

If the manpage is incomplete or not sufficiently helpful for new users,
that is a bug in the package. Wishlist or minor but still a bug.
 
> I am requesting a tracker kind approach for each package.
> It could be very similar to Debian BTS. When a user has some query
> regarding a package, she cannot file a bug report directly unless she's
> sure that it is a bug (and not an odd behavior).

I can't see why the BTS wouldn't be used directly. If the problem is
that the submitter is insure whether this is correct behaviour, then
that is usually an unclear or incomplete manpage, so a bug anyway. If
the concern is that bugs are more work for overloaded maintainers then
how is a help request different?
 
> I have a query regarding fdm. Then probably I could just file a "help
> report" against fdm. It'd go to the same package maintainer.

How does that help the maintainer? It's the same amount of work, now
with a different method and possibly different tools.

Those maintainers with packages that are overloaded with bugs will
still not have time to answer help bugs anymore than they are able to
deal with the current number of bugs.

> This definitely would be an extra add-on to the maintainers and there
> will be high chances of users asking questions without RTFMing. For
> that, we could make the Debian Policy that the "Debian HTS - Debian Help
> Tracking System", will in no way relate to release schedule or quality
> of the Debian distribution.

Umm, so exactly like any standard bug report that is severity important
or lower?

A tracker like you describe would just be ignored in many cases, I
don't see how that would help anyone.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpvmks7ErrDV.pgp
Description: PGP signature