Re: Mandatory -dbg packages for libraries?

[Sune Vuorela]

On 2007-04-22, Mark Brown <[EMAIL PROTECTED]> wrote:
> I'd be interested to see some numbers on the archive size impact - my
> experience with C++ suggests that the size inflation caused by debug
> symbols can be enormous.

Openoffice currently ships a -g1 -dbg package. If it wasn't -g1, the deb
would be around 400mb.

Kdebase:
33mb -dbg package
28mb source
11-12 mb arch all debs.
20 mb arch debs.

kdelibs
26 mb -dbg package
18 mb source package
39 (!) mb -doc package
10 mb other arch all debs
10 mb arch debs.

For these two deb packages - the debug packages is around 1.5 the size
of the arch package. A couple of other kde packages seems to show the
same behaviour.

/Sune


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

how to handle changelogs in experimental/unstable

[Atsuhito Kohda]

Hi all,

I've recently adopted texmacs package and to fix a grave bug
I uploaded the package in experimental to unstable with
a fix but I found that changelogs of a package in experimental
and unstable are mutually independent, i.e. the one isn't a
subset of the other.

In this case, what is the right way to merge changelogs
in the next upload to unstable?  Should I modify it manually?
Is there any official guideline for this?

Thanks in advance,2007-4-23(Mon)

-- 
 Debian Developer & Debian JP Developer - much more I18N of Debian
 Atsuhito Kohda 
 Department of Math., Univ. of Tokushima


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

How to setup co-maintainer

[Atsuhito Kohda]

Hi all,

I maintain texmacs with a co-maintainer who is not a DD yet
but don't know exactly how to set him up in a control file 
(or anywhere).

developers-reference teaches me;

Add the co-maintainer's correct maintainer name and address 
to the Uploaders field in the global part of the debian/control 
file.

But the co-maintainer can't upload a package yet so I'm
not sure if this is true in my case.

Is it okay to put my name in Maintainer field and put
co-maintainer who is not a DD yet to Uploaders field?

Or should I put co-maintainer in Maintainer field and put
my name in Uploaders field? or is there any other reasonable
settings?

Thanks in advance, 2007-4-23(Mon)

-- 
 Debian Developer & Debian JP Developer - much more I18N of Debian
 Atsuhito Kohda 
 Department of Math., Univ. of Tokushima


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

Re: How to setup co-maintainer

[Sebastian Harl]

Hi,

On Mon, Apr 23, 2007 at 04:49:41PM +0900, Atsuhito Kohda wrote:
> developers-reference teaches me;
> 
> Add the co-maintainer's correct maintainer name and address 
> to the Uploaders field in the global part of the debian/control 
> file.
> 
> But the co-maintainer can't upload a package yet so I'm
> not sure if this is true in my case.

You can still just add him to the Uploaders field.

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl
GnuPG-ID: 0x8501C7FC
http://tokkee.org/



signature.asc
Description: Digital signature

Re: How to setup co-maintainer

[Nico Golde]

Hi,
* Atsuhito Kohda <[EMAIL PROTECTED]> [2007-04-23 10:11]:
> I maintain texmacs with a co-maintainer who is not a DD yet
> but don't know exactly how to set him up in a control file 
> (or anywhere).
> 
> developers-reference teaches me;
> 
> Add the co-maintainer's correct maintainer name and address 
> to the Uploaders field in the global part of the debian/control 
> file.
[...] 
> Or should I put co-maintainer in Maintainer field and put
> my name in Uploaders field? or is there any other reasonable
> settings?

Add yourself to Uploaders or add him, doesn't really matter. 
The package will show up on both of your ddpo sites. You can 
also start some kind of mainlingliste and add the address of 
it to the Maintainer field and you both to Uploaders.
Kind regards
Nico
-- 
Nico Golde - http://ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.


pgpGCBkeTJKee.pgp
Description: PGP signature

Re: Mandatory -dbg packages for libraries?

[Josselin Mouette]

Le dimanche 22 avril 2007 à 20:39 +0100, Neil Williams a écrit :
> I'd like to see all library source packages having a minimum of 4
> binary packages required by Policy: the SONAME, the -dev,  the -dbg and
> a -doc package. (Libraries for perl or other non-compiled languages
> would be exempt from -dbg packages but not -doc.)

I fully concur, and I think we need to go farther, by adding a debugging
package to *all* architecture-dependent packages. Of course, this
requires changes at the dak level, in the mirror scripts (not all
mirrors will want their size to double) and in APT. This was in Sam's
platform and I hope to see some efforts happen in this direction.

With the introduction of debreaper, I'd like to make automated bug
reporting a reality for the majority of unstable users, but it will be
useless if there is no solution to install the debugging symbols
automatically. Currently I plan to automate installation of the -dbg
packages when they are available, but this is grossly suboptimal and
there is no real reason to not generate them for more packages.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.

Re: Bug#420165: ITP: commons-configuration -- Java based library providing a generic configuration interface

[Arnaud Vandyck]

On 4/22/07, Marcus Better <[EMAIL PROTECTED]> wrote:

Torsten Werner wrote:
> I call the binary package
> libcommons-configuration-java but not the source package.

This is one of the two conventions used by the Java packaging team (and IMHO
the best option), cf. commons-logging and commons-daemon packages. The
other common option is to name both source and binary packages
libsomething-java.


Please, see http://www.us.debian.org/doc/packaging-manuals/java-policy/x105.html

Also, Torsten, why don't you join the pkg-java maintainer team? I see
you intent to package some java libs and apps, it'd be good to follow
our recommendations and why not join the team?
http://pkg-java.alioth.debian.org/developers.html

About the name of the lib, it's strange you seem not to know that
pkg-java already package nearly all the jakarta-commons package under
the name libcommons-XXX-java (beanutils, io, lang, net, httpclient,
daemon, logging, pool, dbcp, cli, codec, collections, digester,
discovery, el, fileupload, jexl, jxpath, launcher, modeler, validator,
sorry if I forgot one).

I strongly recommend that the Jakarta commons package be maintained by
pkg-java-maintainers.

Cheers,

--
Arnaud Vandyck


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

Bug#420564: ITP: python-asterisk -- Asterisk Manager API interface module for Python

[Julien BLACHE]

Package: wnpp
Severity: wishlist
Owner: Julien BLACHE <[EMAIL PROTECTED]>


* Package name: python-asterisk
  Version : 0.1a3+r160
  Upstream Author : David M. Wilson <[EMAIL PROTECTED]>
* URL : http://py-asterisk.berlios.de/py-asterisk.php
* License : MIT
  Programming Lang: Python
  Description : Asterisk Manager API interface module for Python

 This module provides an object oriented interface to the Asterisk Manager API,
 whilst embracing some applicable Python concepts:
  o Functionality is split into separate mix-in classes
  o Asterisk PBX errors cause fairly granular exceptions
  o Docstrings are provided for all objects
  o The module may be used asynchronously if required. It should be suitable
for inclusion in a single-threaded GUI
  o Asterisk data is translated into data stored using Python types, so
working with it should be trivial. Through the use of XMLRPCServer or
similar, it should be trivial to expose this conversion to other
languages

JB.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.20 (SMP w/2 CPU cores)
Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash


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

Re: how to handle changelogs in experimental/unstable

[Joey Schulze]

Atsuhito Kohda wrote:
> Hi all,
> 
> I've recently adopted texmacs package and to fix a grave bug
> I uploaded the package in experimental to unstable with
> a fix but I found that changelogs of a package in experimental
> and unstable are mutually independent, i.e. the one isn't a
> subset of the other.

Often the package in experimental gets superseded with a package in
unstable at a later time (i.e. weeks or even months later).  In that
case the new package uploaded to unstable should most probably
incorporate the changelog entries from experimental as well as those
from the unstable package which it also supersedes, so that package
history is preserved.

Regards,

Joey

-- 
Those who don't understand Unix are condemned to reinvent it, poorly.

Please always Cc to me when replying to me on the lists.


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

Bug#420581: ITP: libjflac-java -- Java Free Lossless Audio Codec

[Varun Hiremath]

Package: wnpp
Owner: Varun Hiremath <[EMAIL PROTECTED]>
Severity: wishlist

* Package name: libjflac-java
  Version : 1.2
  Upstream Author : David R Robison <[EMAIL PROTECTED]>
* URL or Web page : http://jflac.sourceforge.net/
* License : BSD
  Description : Java Free Lossless Audio Codec

 JFLAC is a port of the Free Lossless Audio Codec (FLAC) library to
 Java. This library allows java developers to experiment and write
 programs that use the FLAC algorithms.
 .
  Homepage: http://jflac.sourceforge.net/

-- 
Regards
Varun


signature.asc
Description: Digital signature

ITP: fontypython -- Manage your ttf fonts on your GNU/Linux

[Kartik Mistry]

Package: wnpp
Severity: wishlist
Owner: Kartik Mistry <[EMAIL PROTECTED]>

* Package name: fontypython
Version : 0.2.0
Upstream Author : Donn.C.Ingle <[EMAIL PROTECTED]>
* URL : https://savannah.nongnu.org/projects/fontypython
* License : GPL
Description : Manage your ttf fonts on your GNU/Linux

Fontypython is GUI tool written in Python and Wxwidgets to manage your
ttf fonts in GNU/Linux.
.
You can collect any fonts together (even ones not in your system font
folders) into 'pogs' and then install and remove the pogs as you need
them. In this way you can control what fonts are in your user font
folder - thus avoiding long lists of fonts in the font chooser
dialogues of your apps.

--
Thanks,

Kartik Mistry  | Eng: kartikmistry.org/blog
0xD1028C8D | Guj: kartikm.wordpress.com



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

Re: patches.ubuntu.com and the Debian PTS derivatives

[Matt Zimmerman]

On Sun, Apr 22, 2007 at 11:30:32PM -0300, Gustavo Franco wrote:
> On 4/2/07, Scott James Remnant <[EMAIL PROTECTED]> wrote:
> >As some of you may have noticed, the patches.ubuntu.com website and
> >equivalent mailing of changes to the Debian PTS and ubuntu-patches
> >mailing list has been offline, or at least intermittent, for a few
> >weeks.
> >
> >This was caused by the hosting machine running out of disk space, and
> >the Debian mirror we were using being partially incomplete for a while.
> >
> >The latter problem seems to have been fixed, and the Canonical sysadmins
> >are working on the former.
> >
> 
> Hi Scott,
> 
> Do you have any update for us on this issue?

The admins have been swamped with the Ubuntu 7.04 release, but with that out
of the way, this should be back online soon (it's needed for beginning work
on 7.10 as well).

-- 
 - mdz


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

Re: how to handle changelogs in experimental/unstable

[Atsuhito Kohda]

On Mon, 23 Apr 2007 11:52:09 +0200, Joey Schulze wrote:

> Often the package in experimental gets superseded with a package in
> unstable at a later time (i.e. weeks or even months later).  In that
> case the new package uploaded to unstable should most probably
> incorporate the changelog entries from experimental as well as those
> from the unstable package which it also supersedes, so that package
> history is preserved.

My main concern is to preserve package history.  Thanks for 
your advice.

Regards,2007-4-23(Mon)

-- 
 Debian Developer & Debian JP Developer - much more I18N of Debian
 Atsuhito Kohda 
 Department of Math., Univ. of Tokushima


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

Re: How to setup co-maintainer

[Atsuhito Kohda]

On Mon, 23 Apr 2007 09:59:44 +0200, Sebastian Harl wrote:

> > But the co-maintainer can't upload a package yet so I'm
> > not sure if this is true in my case.
> 
> You can still just add him to the Uploaders field.

I see.

On Mon, 23 Apr 2007 10:32:14 +0200, Nico Golde wrote:

> The package will show up on both of your ddpo sites. You can 
> also start some kind of mainlingliste and add the address of 
> it to the Maintainer field and you both to Uploaders.

Our co-maintenance is far more primitive, I guess.

Thanks for your help.
Regards,2007-4-23(Mon)

-- 
 Debian Developer & Debian JP Developer - much more I18N of Debian
 Atsuhito Kohda 
 Department of Math., Univ. of Tokushima


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

Re: Mandatory -dbg packages for libraries?

[Hamish Moffatt]

On Mon, Apr 23, 2007 at 07:38:15AM +0200, Mike Hommey wrote:
> On Sun, Apr 22, 2007 at 08:26:38PM -0400, Joey Hess <[EMAIL PROTECTED]> wrote:
> > Mark Brown wrote:
> > > I'd be interested to see some numbers on the archive size impact - my
> > > experience with C++ suggests that the size inflation caused by debug
> > > symbols can be enormous.
> > 
> > I don't know about C++, but for C it depends. For example, aalib is a
> > 102 kb library that compresses to 44kb. Its debug symbols are 234 kb and
> > compress to 65 kb. 
> > 
> > OTOH, people rarely need full debugging information for aalib, it's
> > probably plenty to see its functions in the backtrace, and not have line
> > number info (bear in mind that line number info includes effectively the
> > entire source code of the program). So it I build it with -g1, the
> > debug symbols size drops to 48 kb and compresses to 14 kb.
> 
> Except that -g1 drops line numbers...

Wasn't that Joey's point?

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


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

[ITH] xmltex, passivetex, offer to take over jadetex

[Frank Küster]

Hi everybody,

in the last months or even years, xmltex and passivetex have been
basically unmaintained (and they *do* have bugs), and responses from the
list which is listed as maintainer are very rare.  jadetex is actually
maintained by you, Ohura-san, but maybe gets not as much care as it
could have - and anyway the coordination with the TeX Task Force could
be better than we currently manage for a package so tightly coupled to
TeX.

On the other hand, integration of these three components into TeXLive
has already been accomplished upstream, and we only cut them out because
they existed as separate packages already in the days of teTeX only.

We therefore intend to essentially take over xmltex and passivetex, by
providing a package texlive-xml or similar[1] which would "Provide:
xmltex, passivetex", and then requesting their removal on ftp.debian.org
as RoM.

We offer to do the same with jadetex, if Ohura thinks this is the way to
go.  If you prefer to keep maintaining it separately, no problem.  This
or that way, you're invited to join our list and team.


Comments, protest?

Regards, Frank

[1] following upstream's naming, it would be texlive-htmlxml, but that
includes also tex4ht which we do not think should be integrated
-- 
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: [ITH] xmltex, passivetex, offer to take over jadetex

[Daniel Leidert]

Am Montag, den 23.04.2007, 15:46 +0200 schrieb Frank Küster:

> in the last months or even years, xmltex and passivetex have been
> basically unmaintained (and they *do* have bugs), and responses from the
> list which is listed as maintainer are very rare.  jadetex is actually
> maintained by you, Ohura-san, but maybe gets not as much care as it
> could have - and anyway the coordination with the TeX Task Force could
> be better than we currently manage for a package so tightly coupled to
> TeX.
> 
> On the other hand, integration of these three components into TeXLive
> has already been accomplished upstream, and we only cut them out because
> they existed as separate packages already in the days of teTeX only.

I already saw that and wanted to contact you to talk about a possible
overhanding of xmltex (I saw, that the xmltex page says, it's part of
texlive).

> We therefore intend to essentially take over xmltex and passivetex,

No objections from me. I CCed Ardo van Rangelrooij, who seems
responsible for xmltex as part of the Debian XML/SGML group.

> by
> providing a package texlive-xml or similar[1] which would "Provide:
> xmltex, passivetex", and then requesting their removal on ftp.debian.org
> as RoM.

passivetex has already been removed, JFTR. If you want to re-add it (as
part of texlive-xml), please also check 
http://bugs.debian.org/291813
http://bugs.debian.org/xmlto (some bugs there are IIRC related to
passivetex issues)

I'm not CCed to Debian TeX maintainers list, so please CC me, if you
answer from there.

Regards, Daniel

Bug#420605: ITP: gaim-rhythmbox -- gaim plugin to display rhythmbox's currently playing song

[Jon Dowland]

Package: wnpp
Severity: wishlist
Owner: Jon Dowland <[EMAIL PROTECTED]>

* Package name: gaim-rhythmbox
  Version : 2.0beta5
  Upstream Author : Jon Oberheide <[EMAIL PROTECTED]>
* URL : 
* License : GPL-2
  Programming Lang: C
  Description : gaim plugin to display rhythmbox's currently playing song

gaim-rhythmbox is a plugin for the gaim instant messenger
which allows you to display the song currently playing in
rhythmbox. Currently the plugin will display this
information in the User Info and status fields.

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

Kernel: Linux 2.6.18-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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]

Best Practices and Financial Risk - May NYC

[Mike Smith]

  
  

  


  

  
Best Practices & Financial RiskPresented by 
The Energy Management Institute 
When: May 21-22, 
2007Where: NYC Area
Request 
syllabus Register
Limited seating available for Energy Management 
Institute's newest training: Best Practices and Financial Risk. 

This course will give you 
an integrated framework to understand various types of financial 
risk and how to measure, monitor and manage those risks. Armed with 
this knowledge, you'll be able to identify and avoid the 
pitfalls that led to spectacular disasters both within and beyond 
the energy industry. 
Included below are highlights of 
the course. Our classroom size is limited to provide an optimal 
learning environment so reserve 
your seat as soon as possible.
WHAT YOU WILL 
LEARN 

  
  How 
  to measure, monitor and manage market risk and credit risk.  
  
  
  Which 
  types of risk management models are best suited to specific types 
  of trading and hedging portfolios.  
  
  How 
  to manage risks that elude measurement via quantitative models 
  (such as liquidity risk, operational risk, systemic risk, 
  regulatory/legal risk and reputation risk).  
  
  
  How 
  to measure a portfolio’s VaR using various 
  models. 
  
  The 
  importance of accounting for paradigm shifts and price shocks in 
  stress tests of a portfolio.  
  
  How 
  and why major corporations such as Barings Bank and Enron 
  failed.  
  
  How to avoid such failures 
  within your own corporation and how to identify the warning signs 
  of these types of financial risks among your 
  counterparties.  
  
WHO SHOULD ATTENDThe course is applicable to all levels of the 
energy infrastructure, oil, natural gas, electricity & coal. 
Individuals in every functional area of responsibility in all energy 
industries whose decisions have significant financial impact will 
benefit from this program. Managers from areas such as trading, risk 
management, compliance, human resources, ethics, credit, contracts, 
operations, marketing, sales, supply & distribution, purchasing, 
financial & accounting will find the course highly 
beneficial.      
Request 
syllabus Register 
  *A fully accredited EMI Certificate in 
Best Practices & Financial Risk will be awarded to individuals 
who successfully complete this program. This course earns 14 
CPE credits. All EMI courses are CPE approved. 
EMI experts 
instruct using current data, real-life examples and practical 
experience.  

  
  
Upcoming EMI 
  Courses:Click on course title to request 
  details
  

  

  Futures, 
  Options & Derivatives:
  April 
  18-19, NYC Area
  

  Fundamentals 
  of Petroleum:
  April 
  25-26, San Francisco, CA
  

  Intro 
  to Trading & HedgingMay 8-9, Houston, 
TX
  

  Best Practices & 
  Financial Risk
  May 21-22, NYC 
  Area
  

  Energy Trading 
  Fundamentals
  May 23-24, NYC 
  Area
  

  Energy Risk 
  Management
  May 30-31, NYMEX 
  NYC
  

  Petroleum 
  Fundamentals
  June 20-21, NYC 
  Area
  

  Power & Gas 
  FundamentalsJune 20, Sacramento, 
  CA
  

  Technical 
  Analysis
  June 27-28, Los Angeles, 
  CA
  

  Futures

Re: debootstrap/cdebootstrap failure: libsasl2 cannot be installed

[Steve Langasek]

On Sun, Apr 22, 2007 at 09:35:13PM +0300, Fabian Fagerholm wrote:
> On Mon, 2007-04-23 at 00:00 +0900, Junichi Uekawa wrote:
> > Did it require a manual action from ftp-master ?  Either way I guess
> > it takes a few days to happen.

> It requires manual action. There's a bug open for its removal: #419418

There's no need to file bug reports for binary removals if you've correctly
dropped the references to those binaries from debian/control.  libsasl2 is
already in the current dak cruft-report as an NBS binary.

> > Until that time, 'pbuilder create' and 'debootstrap' and
> > 'cdebootstrap' will stay broken.

> Sorry for the inconvenience. We (the cyrus-sasl2 maintainers) could have
> tried lowering the priority of the package first, but that would also
> have required manual action by ftp-master to adjust the overrides, so it
> would've been pointless.

It would have been more time-consuming, but the point would be to not break
debootstrap for folks, so I don't know that I would call it pointless.

-- 
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: debootstrap/cdebootstrap failure: libsasl2 cannot be installed

[Santiago Vila]

On Sun, 22 Apr 2007, Steve Langasek wrote:

> On Sun, Apr 22, 2007 at 10:20:55PM +0900, Junichi Uekawa wrote:
> 
> > cdebootstrap sid failed today :
> 
> > O: The following packages have unmet dependencies:
> > O:   libsasl2: Depends: libsasl2-2 (= 2.1.22.dfsg1-8+b1) but 2.1.22.dfsg1-9 
> > is to be installed
> 
> > I'm not quite sure why cdebootstrap is trying to pull in libsasl2;
> > all packages in base seem to have already migrated to libsasl2-2.
> 
> Probably because libsasl2 itself is prio: important?

We could have avoided this by downgrading libsasl2 to standard in etch.

I don't understand why do we insist on being ultra-conservative
about fixing wrong package priorities before a release.


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

Re: Mandatory -dbg packages for libraries?

[Daniel Jacobowitz]

On Sun, Apr 22, 2007 at 07:29:55PM -0400, Joey Hess wrote:
> Even with separated debugging symbols, -dbg packages are frequently
> larger than the package they provide debugging symbols for. See for
> example xserver-xorg-core-dbg. Looking through the 227 lib*-dbg
> packages, I found few contain separated debugging symbols, except for
> packages maintained by the xorg team[1]. I'm not sure if this is due
> many people still not knowing about separated debugging symbols, or due
> to technical reasons. For example, is there a tecnical reason why
> libc6-dbg does not contain separated debugging symbols?

Yes, it's deliberate.  People rarely need them just because they're
debugging something linked to libc.so.6.  Having them slows down GDB
startup and increases its memory usage, for _every_ debug session.

You'll notice if you look closely that libc6-dbg contains two things.
One of them is a set of libraries you can use if you want to debug
libc6.  The other is a set of separate symbol files, but they contain
only frame unwind information, no symbolic or line number information.
This keeps the size and performance impact of the package down, but
makes backtraces out of libc6 hugely more reliable.

> I've considered before trying to set up a separate, parallel archive
> that would only hold the -dbg packages, but implementing that without
> initially using the Debian infrastructure would be tough, and my
> experiences with setting up[2]/maintaining the separate udeb section of
> the archive is that it adds a lot of complexity.

FWIW, I still think this is the way to go, though it would be hard.
They wouldn't need nearly as much mirroring.  e.g. they could go into
a separate pool directory...

-- 
Daniel Jacobowitz
CodeSourcery


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

Re: [ITH] xmltex, passivetex, offer to take over jadetex

[OHURA Makoto]

  Hi, Frank and all.

# I'm reading debian-tex-maint.

From: Frank Küster <[EMAIL PROTECTED]>
Subject: [ITH] xmltex, passivetex, offer to take over jadetex 
Date: Mon, 23 Apr 2007 15:46:15 +0200

> We offer to do the same with jadetex, if Ohura thinks this is the way to
> go.  If you prefer to keep maintaining it separately, no problem.  This
> or that way, you're invited to join our list and team.

  No objection form me, either.  Please include jadetex and me
into a family of texlive.

  Thanks.


  OHURA Makoto: [EMAIL PROTECTED](Debian Project)
[EMAIL PROTECTED](LILO/Netfort)
  GnuPG public key: http://www.netfort.gr.jp/~ohura/gpg.asc.txt
fingerprint: 54F6 D1B1 2EE1 81CD 65E3  A1D3 EEA2 EFA2 77DC E083
  http://www.netfort.gr.jp/~ohura/


pgpxc5omOSVX6.pgp
Description: PGP signature

Re: Mandatory -dbg packages for libraries?

[Mike Hommey]

On Mon, Apr 23, 2007 at 11:28:06PM +1000, Hamish Moffatt <[EMAIL PROTECTED]> 
wrote:
> On Mon, Apr 23, 2007 at 07:38:15AM +0200, Mike Hommey wrote:
> > On Sun, Apr 22, 2007 at 08:26:38PM -0400, Joey Hess <[EMAIL PROTECTED]> 
> > wrote:
> > > Mark Brown wrote:
> > > > I'd be interested to see some numbers on the archive size impact - my
> > > > experience with C++ suggests that the size inflation caused by debug
> > > > symbols can be enormous.
> > > 
> > > I don't know about C++, but for C it depends. For example, aalib is a
> > > 102 kb library that compresses to 44kb. Its debug symbols are 234 kb and
> > > compress to 65 kb. 
> > > 
> > > OTOH, people rarely need full debugging information for aalib, it's
> > > probably plenty to see its functions in the backtrace, and not have line
> > > number info (bear in mind that line number info includes effectively the
> > > entire source code of the program). So it I build it with -g1, the
> > > debug symbols size drops to 48 kb and compresses to 14 kb.
> > 
> > Except that -g1 drops line numbers...
> 
> Wasn't that Joey's point?

The point is that it's pretty useless to have a backtrace without line
numbers. It would be interesting if there was an option similar to -g1,
but that would keep the line numbers (without the burden of keeping the
whole source code)

Mike


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

Re: Mandatory -dbg packages for libraries?

[Steinar H. Gunderson]

On Mon, Apr 23, 2007 at 07:06:55PM +0200, Mike Hommey wrote:
> The point is that it's pretty useless to have a backtrace without line
> numbers. It would be interesting if there was an option similar to -g1,
> but that would keep the line numbers (without the burden of keeping the
> whole source code)

Are you sure the source code is in there with -g? I was pretty sure it
wasn't, only line numbers.

/* Steinar */
-- 
Homepage: http://www.sesse.net/


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

Re: Mandatory -dbg packages for libraries?

[Steve Greenland]

On 22-Apr-07, 17:29 (CDT), Kurt Roeckx <[EMAIL PROTECTED]> wrote: 
> On Sun, Apr 22, 2007 at 04:40:45PM -0500, Steve Greenland wrote:
> > On 22-Apr-07, 16:22 (CDT), Robert Collins <[EMAIL PROTECTED]> wrote: 
> > > 
> > > Because segfaults are often not easily reproduced. Having the ability to
> > > analyse a crash that occured when the user did not have the -dbg
> > > packages installed is not possible unless you have the original symbols
> > > the compiler created.
> > 
> > That's an argument in favor of making the base library package built
> > with debug symbols and then stripped[1], not of requiring -dbg packages.
> 
> Maybe you should take a look at what dh_strip and -dbg packages do.  It
> strips the debug symbols and puts it in a seperate file that's put in
> /usr/lib/debug.  You put those files with debug symbols only in the -dbg
> package.
> 
> This means that you can just install the -dbg package and gdb will
> automaticly pick up the debug symbols, without needing to rebuild
> anything.

Ah, thanks for clarifying. This makes more sense than what I was
(mis-)understanding.

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


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

Re: Mandatory -dbg packages for libraries?

[Steve Greenland]

On 22-Apr-07, 17:01 (CDT), Neil Williams <[EMAIL PROTECTED]> wrote: 
> 
> > 2. Why a seperate -doc? API docs should be part of the -dev package.
> 
> In practice, such attitudes are commonly expressed as RTSL. (Read The
> Source, Luke). That does NOT encourage upstream usage of Debian as a
> distro.
> 
> Is man (3) really so hard for a DD to provide?
> 
> > I'm going to guess that for *most* libraries, the docs are a trivial
> > part of the size of the -dev package. For those with significant
> > documentation, sure, a seperate -doc makes sense, just as we do now.
> 
> I think libraries should be encouraged to provide significant
> documentation - what we have now is simply not enough.

You seem to be arguing that the man pages should be in the core library
package, yes? My objection is against mandating a *separate* -doc
package. Separate doc packages make sense when the documentation is
a significant portion of the total binary package size, and thus
duplicating them in each binary package (rather than a single arch-all
package) causes more hardship on the archive and mirrors than having a
new packages causes the Packages file.

As for putting the docs in the core library file, I don't actually buy
your argument. The *VAST* majority of a libraries users are never going
to look at the man pages for that library. People who need the man pages
are going to have the -dev installed, or can easily install it. I don't
see why upstreams needs this.

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


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

Re: Mandatory -dbg packages for libraries?

[Mike Hommey]

On Mon, Apr 23, 2007 at 07:10:15PM +0200, Steinar H. Gunderson <[EMAIL 
PROTECTED]> wrote:
> On Mon, Apr 23, 2007 at 07:06:55PM +0200, Mike Hommey wrote:
> > The point is that it's pretty useless to have a backtrace without line
> > numbers. It would be interesting if there was an option similar to -g1,
> > but that would keep the line numbers (without the burden of keeping the
> > whole source code)
> 
> Are you sure the source code is in there with -g? I was pretty sure it
> wasn't, only line numbers.

You're indeed right. I wrote quicker than my thoughts.

Mike


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

Re: Error with fakeroot

[Bernd Zeimetz]

Heya,

>> You can easily run into this problem by using
>> make-kpkg --rootcmd fakeroot modules-image
>> and the nvidia module will fail with
> 
> Does this happen every time?

with the nvidia module - yes [1].
I'm pretty sure I've seen this happen with {svn,dpkg}-buildpackage
before, too - but I just don't know where. As soon as I see it again
I'll make sure to look into the problem.


Cheers,

Bernd

[1]: http://bzed.de/debian/bugs/fakeroot



-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 


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

Re: Debian Development environments.

[Alan Ezust]

let's say you need to build from source a program such as "gimp" which has
many library dependencies. You don't know what they are, and you want debian
to auto-install the -dev packages you need. apt-get build-dep is your
friend.

/etc/apt [EMAIL PROTECTED] apt-get build-dep gimp
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
 automake1.7 intltool libaa1-dev libcroco3-dev libexif-dev libgail-common
libgail-dev libgail17 libgnomecanvas2-dev libgsf-1-dev
 libgtkhtml2-0 libgtkhtml2-dev librsvg2-dev libslang2-dev libwmf-dev
libxml-parser-perl libxpm-dev patchutils python-gtk2-dev
0 upgraded, 19 newly installed, 0 to remove and 114 not upgraded.
Need to get 4506kB of archives.
After unpacking 18.5MB of additional disk space will be used.
Do you want to continue [Y/n]?


On 4/12/07, Josselin Mouette <[EMAIL PROTECTED]> wrote:


Le jeudi 12 avril 2007 à 14:25 +0100, Luis Matos a écrit :
> gnome-devel has what? anjuta, devhelp, glade and ...

... and gnome-core-devel.

> i see for example
> that it has no -dev dependency ... so ... how are people going to
> compile stuff against gnome/gtk/linux libraries? They are only
> recomends.

No.

Re: Mandatory -dbg packages for libraries?

[Joey Hess]

Tshepang Lekhonkhobe wrote:
> It would be nice if the standard iso images that Debian makes
> available could be made to exclude -dbg packages as a trade-off. It
> actually felt painful someday when doing jigdo on the archive, only to
> see loads of -dbg packages getting downloaded, and knowing I wasn't
> ever gonna use 'em.

debian-cd orders packages by popcon popularity, so if the -dbg packages
are not on the last CDs, they must be used more than the packages that
come after them.

(The first -dbg package put on a CD is libc6-dbg, which comes just after
exim in popularity. That's exim 3, not 4.)

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Mandatory -dbg packages for libraries?

[Joey Hess]

Manoj Srivastava wrote:
> On Sun, 22 Apr 2007 19:29:55 -0400, Joey Hess <[EMAIL PROTECTED]> said: 
> 
> > So while I'd love to have a way to have -dbg packages available for
> > every binary, I actually am happy with this proposal to do it for only
> > every library (plus whatever other binaries really need it). And it's
> > a direction we're already moving in, with, as I mentioned, 227
> > lib*-dbg packages already in the archive. That's more than 10% of all
> > our libraries already done[3].
> 
> So, making it a should would make 90% of our library packages
>  insta-buggy.
> 
> > So I suggest that we take this as an existing practice, document it as
> > a "should" in policy for now, document *how* to do separated debugging
> > symbols in the developers reference (which does not currently seem to
> > mention it at all), and go add -dbg versions of our library packages.
> 
> I would rather add it as a recommended practice in policy, with a
>  note that it will become a should/must as we get better coverage, and
>  _also_ provide examples of what maintainers need to do to create
>  separate debugging symbol packages in an informative footnote.

Well, we've made more than ~300 packages insta-buggy with policy
changes before. It's not insta-rc-buggy. OTOH, I don't really care; 300
bug reports could be mass-filed w/o it being a "should" in policy.

Note that I've already written some documentation for
developers-reference in #420540. The policy-relevant bits are that we
use /usr/lib/debug/, that the files should not be
executable (possibly a common mistake since objcopy preserves executable
bits IIRC), and that the package names end in -dbg and the debug packages
depend on an equal version of the package they provide debugging symbols
for.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Mandatory -dbg packages for libraries?

[Joey Hess]

Daniel Jacobowitz wrote:
> Yes, it's deliberate.  People rarely need them just because they're
> debugging something linked to libc.so.6.  Having them slows down GDB
> startup and increases its memory usage, for _every_ debug session.

Ok. Of course, this is also generally an argument against having -dbg
packages for libraries with separated symbols..

> You'll notice if you look closely that libc6-dbg contains two things.
> One of them is a set of libraries you can use if you want to debug
> libc6.  The other is a set of separate symbol files, but they contain
> only frame unwind information, no symbolic or line number information.
> This keeps the size and performance impact of the package down, but
> makes backtraces out of libc6 hugely more reliable.

What are your feelings on only including the -g1 information in library
-dbg packages in general? It does save a lot of space, but the potential
utility also goes way down.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Mandatory -dbg packages for libraries?

[Joey Hess]

Steinar H. Gunderson wrote:
> Are you sure the source code is in there with -g? I was pretty sure it
> wasn't, only line numbers.

You're right, it doesn't include the actual code, but the size is
still roughly porportional to the size of the code in the library.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Bug#388701: Why Beryl has just four packages?

[Shawn Starr]

I've stopped Beryl for now since they are officially merging with compiz. I 
need to speak to the compiz maintainer.

I have 0.2.1 in a local git repository but im likely just going to chuck it 
out. With the merge its moot now.

- Original Message 
From: Kurt Roeckx <[EMAIL PROTECTED]>
To: Shawn Starr <[EMAIL PROTECTED]>; [EMAIL PROTECTED]
Cc: Anibal Avelar <[EMAIL PROTECTED]>; debian-devel@lists.debian.org
Sent: Sunday, April 22, 2007 5:38:39 AM
Subject: Bug#388701: Why Beryl has just four packages?

On Wed, Feb 14, 2007 at 11:55:30AM -0500, Shawn Starr wrote:
> On Wednesday 14 February 2007 00:27, Anibal Avelar wrote:
> > Hi. I see you have in queue NEW three packages: beryl-plugins,
> > beryl-settings and emerald [1] and not ready (yet) beryl.
> 
> Firstly,  the beryl packages were REJECTED because of license issues. 
> Upstream 
> is working with me on resolving the non-free/license issues that remain these 
> will be fixed for the 0.2.0 stable release of Beryl  (coming soon).

>From their homepage:
Mar 14: 0.2.0 Released

But they also already have 0.2.1 versions available.


Kurt






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

Re: Mandatory -dbg packages for libraries?

[Joey Hess]

Mike Hommey wrote:
> The point is that it's pretty useless to have a backtrace without line
> numbers.

That depends on whether the problem you're debugging is a bug in the
library itself, or only a bug triggered by code that calls the library,
or in code called by the library.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Mandatory -dbg packages for libraries?

[Joey Hess]

Steinar H. Gunderson wrote:
> Are you sure the source code is in there with -g? I was pretty sure it
> wasn't, only line numbers.

I was fooled by the fact that the debug packages I was using have:

[EMAIL PROTECTED]:/usr/lib/debug/usr/lib>strings libaa.so.1.0.4|grep joey
/home/joey/src/packages/aalib/src
[EMAIL PROTECTED]:/usr/lib/debug/usr/lib>strings xorg/modules/*.so |grep 
home|head
/home/julien/src/xsf/git/xserver/xorg-server/obj-i486-linux-gnu/hw/xfree86/dixmods
/home/julien/src/xsf/git/xserver/xorg-server/obj-i486-linux-gnu/afb
/home/julien/src/xsf/git/xserver/xorg-server/obj-i486-linux-gnu/hw/xfree86/dixmods
/home/julien/src/xsf/git/xserver/xorg-server/obj-i486-linux-gnu/cfb
/home/julien/src/xsf/git/xserver/xorg-server/obj-i486-linux-gnu/mfb
/home/julien/src/xsf/git/xserver/xorg-server/obj-i486-linux-gnu/hw/xfree86/dixmods
/home/julien/src/xsf/git/xserver/xorg-server/obj-i486-linux-gnu/cfb32
/home/julien/src/xsf/git/xserver/xorg-server/obj-i486-linux-gnu/hw/xfree86/exa
/home/julien/src/xsf/git/xserver/xorg-server/obj-i486-linux-gnu/exa
/home/julien/src/xsf/git/xserver/xorg-server/obj-i486-linux-gnu/hw/xfree86/dixmods

Hmm, I hope this isn't a potential security hole.. I'd be happy if there
were a way to remove that info from the package, actually.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#420648: ITP: liburi-template-perl -- handle URI templates in perl

[Ian Beckwith]

Package: wnpp
Severity: wishlist
Owner: Ian Beckwith <[EMAIL PROTECTED]>

* Package name: liburi-template-perl
  Version : 0.06-1
  Upstream Author : Brian Cassidy <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/~bricas/URI-Template-0.06/
* License : Same as Perl (dual GPL/Artistic)
  Programming Lang: Perl
  Description : handle URI templates in perl

  This is an initial attempt to provide a wrapper around URI templates
  as described at http://bitworking.org/news/URI_Templates


I am packaging it as it is a dependency of the latest version of
libwww-opensearch-perl.

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

Kernel: Linux 2.6.18-4-686 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash



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

Re: Mandatory -dbg packages for libraries?

[Daniel Jacobowitz]

On Mon, Apr 23, 2007 at 03:08:41PM -0400, Joey Hess wrote:
> Daniel Jacobowitz wrote:
> > Yes, it's deliberate.  People rarely need them just because they're
> > debugging something linked to libc.so.6.  Having them slows down GDB
> > startup and increases its memory usage, for _every_ debug session.
> 
> Ok. Of course, this is also generally an argument against having -dbg
> packages for libraries with separated symbols..

Yes.  It's a tradeoff question.  Pretty much any other library will
affect a smaller overall percentage of users :-)

> > You'll notice if you look closely that libc6-dbg contains two things.
> > One of them is a set of libraries you can use if you want to debug
> > libc6.  The other is a set of separate symbol files, but they contain
> > only frame unwind information, no symbolic or line number information.
> > This keeps the size and performance impact of the package down, but
> > makes backtraces out of libc6 hugely more reliable.
> 
> What are your feelings on only including the -g1 information in library
> -dbg packages in general? It does save a lot of space, but the potential
> utility also goes way down.

I don't remember exactly what -g1 produces, but I think libc6-dbg is
even less - it's only .debug_frame and .symtab, nothing else at all.
I think libc6-dbg is a special case here, and we should use -g (-g2)
in general.  Another possible way to change glibc would be to have
libc6-dbg contain full debug symbols, libc6-dev contain -g1 symbols
only, and have the -dbg divert the -dev.

-- 
Daniel Jacobowitz
CodeSourcery


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

Re: Bug#388701: Why Beryl has just four packages?

[Anibal Avelar]

Hi.


On 4/23/07, Shawn Starr <[EMAIL PROTECTED]> wrote:

I've stopped Beryl for now since they are officially merging with compiz. I 
need to speak to the compiz maintainer.



I know something about this.

Do you know is officially?  The compiz and beryl teams has problems
with this process (was the last notice  I knew, but I don't follow the
process).

What don't you put a personal server while we wait for them? or in
experimental? (a personal server would be better).

If both projects joins but you don't upload them in unstable, but
while we can have beryl, I like beryl than compiz due to the
beryl-manager ;)

Regards


--
Anibal Avelar (FixXxeR) http://fixxxer.cc
GPG: 83B64656 - C143 4AD8 B017 53FA B742  D6AA CEEA F9F3 83B6 4656


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

Re: Mandatory -dbg packages for libraries?

[Daniel Jacobowitz]

On Mon, Apr 23, 2007 at 03:19:23PM -0400, Joey Hess wrote:
> Hmm, I hope this isn't a potential security hole.. I'd be happy if there
> were a way to remove that info from the package, actually.

I have done some work with debugedit, which is shipped with RPM - it's
supposed to be able to do this, but it needs a little love and to be
integrated into the post-install process.

-- 
Daniel Jacobowitz
CodeSourcery


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

Re: Debian Development environments.

[Warren Turkal]

On Monday 23 April 2007 12:58, Alan Ezust wrote:
> let's say you need to build from source a program such as "gimp" which has
> many library dependencies. You don't know what they are, and you want
> debian to auto-install the -dev packages you need. apt-get build-dep is
> your friend.

Speaking of which, will aptitude ever have this functionality? It would be 
nice to get the markauto goodness from aptitude when installing builddeps.

wt
-- 
Warren Turkal


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

Re: Mandatory -dbg packages for libraries?

[Mark Brown]

On Mon, Apr 23, 2007 at 12:22:40PM -0500, Steve Greenland wrote:
> On 22-Apr-07, 17:01 (CDT), Neil Williams <[EMAIL PROTECTED]> wrote: 

> > I think libraries should be encouraged to provide significant
> > documentation - what we have now is simply not enough.

> You seem to be arguing that the man pages should be in the core library
> package, yes? My objection is against mandating a *separate* -doc
> package. Separate doc packages make sense when the documentation is
> a significant portion of the total binary package size, and thus

Reading between the lines I think Neil is assuming that good
documentation has to be large enough to be worth splitting out.  I don't
think that's a good assumption - for example, one reason people make
libraries is to hide some complex algorithm or nasty portability
problem.  This often results in a library with a very thin API that
doesn't require much documentation.

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


signature.asc
Description: Digital signature

Re: Mandatory -dbg packages for libraries?

[Neil Williams]

On Mon, 23 Apr 2007 12:22:40 -0500
Steve Greenland <[EMAIL PROTECTED]> wrote:

> You seem to be arguing that the man pages should be in the core
> library package, yes?

I would prefer a -doc package that covers the entire API in a
comprehensive and detailed manner, registered with helper programs like
dwww and/or devhelp. In limited cases (like perl) where the library
itself is very small, a man (3) in the -dev would be sufficient IF it
covers the complete API.

> As for putting the docs in the core library file, I don't actually buy
> your argument. The *VAST* majority of a libraries users are never
> going to look at the man pages for that library. People who need the
> man pages are going to have the -dev installed, or can easily install
> it. I don't see why upstreams needs this.

Sorry, I didn't intend to give the impression that the man (3) would go
into the libfooSONAME package, instead I expect it to be present in the
-dev package. HOWEVER, with libraries like libfoo-perl, the
documentation IS part of the core library file already - most perl
libraries (/modules) do not have a -dev package, nor would they need
one. Most would also not need a -doc package but some might. Perl
documentation is trivial to generate when using POD.

--


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



pgp2tEz4LwxUV.pgp
Description: PGP signature

Re: Mandatory -dbg packages for libraries?

[Neil Williams]

On Mon, 23 Apr 2007 21:19:39 +0100
Mark Brown <[EMAIL PROTECTED]> wrote:

> Reading between the lines I think Neil is assuming that good
> documentation has to be large enough to be worth splitting out.

In a lot of cases, yes. I do accept that some libraries - and
particularly perl modules - do not need separate -doc packages.

--


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



pgppwRToTm8D3.pgp
Description: PGP signature

Re: Mandatory -dbg packages for libraries? (and API docs too)

[Neil Williams]

On Sun, 22 Apr 2007 20:39:26 +0100
Neil Williams <[EMAIL PROTECTED]> wrote:

After reading the responses so far, the -doc element of my original
idea needs modification.

> I'd like to see all library source packages having a minimum of 4
> binary packages required by Policy: the SONAME, the -dev,  the -dbg
> and a -doc package. (Libraries for perl or other non-compiled
> languages would be exempt from -dbg packages but not -doc.)

The -doc is overkill for all packages but I still feel it is important
for upstream development that all libraries have at least basic API
documentation within Debian, not just somewhere in the Google cache.

I think a -dbg package should be mandatory for all libraries that
can support it, albeit with an introductory period where it is
advisable, recommended then required.

I think that all libraries - without exception - must come with some
API documentation and the docs should be as complete and as accurate
as possible - ideally generated from the source itself. Where such
documentation makes a -doc package worthwhile, that should be done but
a man (3) page in the -dev would be sufficient in some cases. I would
like to see -doc packages - or at least substantive and reliable API
documentation - being the norm for all libraries in Debian. As with the
-dbg, the 'must' could be introduced as a recommendation prior to being
mandatory.

The tools exist for all these changes - only the incentive to use the
tools is needed.

> Things like that make Debian a nicer environment to be upstream, not
> just a nice environment to be a DD or user. I'm upstream for many of
> my Debian packages and I'd like to think that Debian unstable would
> be the distribution of choice for upstream development.

I was using Debian for upstream development long before I even
considered being a DD.

I chose Debian as a development platform for my own reasons and my
decision was "not deemed to be wise" in the eyes of some of my upstream
colleagues. As the newbie to that particular team, I was under
significant pressure to "upgrade to Fedora or SuSE". Debian needs to
reclaim the respect of upstream development teams and part of that is
making it *a lot* easier to do upstream development on Debian without
needing to become a DD as well. Debian is respected as a
distribution for users because of the multiple architecture support and
the patches and bug reports that are forwarded upstream - what is
missing (IMHO) is respect for Debian as the distribution of choice for
upstream development itself.

> Possible policy amendment:
>
> "Any library source package capable of building with debug information
> (i.e. with -g) must do so. Any such library source package must strip
> the debug symbols into separate objects, provide a binary package
> librarynamesoversion-dbg containing these separate objects
> as /usr/lib/debug/path/to/ELF/object for each /path/to/ELF/object in
> the main library package, and reference these separate objects in
> a .gnu_debuglink section in the corresponding unstripped object."
> (Thanks to Josh Triplett)
>
> I'd like to add something on -doc to that proposition but haven't
> decided how just yet.

"All library packages must include at least basic API documentation
either in the -dev package or in a dedicated -doc package where
sufficient documentation exists. Wherever possible, documentation
should cover the entire library API, be generated from the source code
of the library and be registered with helper programs like dwww and/or
devhelp etc."

(subject to being introduced as a recommendation prior to being made
mandatory.)

What happens now?

Would these changes need a GR?

Would it be sufficient to generate a bug report against Policy?

Or submit these ideas to -policy and take from there?

--


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



pgpRNdsh1sZHy.pgp
Description: PGP signature

Bug#212049: good information

[TaRiiyah Van Dusen]

The world has gone wireless and Mobile Airwaves (mbwc) is 
in the right spot in the right time with a Red Hot Product!


We are awaiting Financial Results to be announced by the 
Mobile Airwaves any moment.  With all the New Contracts they have 
acquired we are waiting for Record Earnings!


mbwc  is currently priced at around 3 cents.  
With the Mobile Airwaves being so Tightly held we awaiting the inflow
of buying to Push the price off the charts!  


Get in on this Breakout Winner Early!



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

Bug#206187: great information

[TANNIE Zeffield]

The earth has gone wireless and Mobile Airwaves (mbwc) is 
in the right place with a Red Hot Product!


We are awaiting Financial Results to be announced by the 
Mobile Airwaves any day.  With all the New Contracts they have 
acquired we are expecting Record Earnings!


mbwc  is currently under valued at around 3 cents.  
With the Mobile Airwaves being so Tightly held we expecting the inflow
of buying to Push the price off the charts!  


Get in on this Breakout Winner Early!



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

Bug#140230: good advertisement

[Sheldon West]

The world has gone wireless and Mobile Airwaves (mbwc) is 
in the right spot in the right time with a Red Hot Product!


We are awaiting Financial Results to be announced by the 
Mobile Airwaves any moment.  With all the New Contracts they have 
acquired we are awaiting Record Earnings!


mbwc  is currently priced at around 3 cents.  
With the Mobile Airwaves being so Tightly held we awaiting the inlux
of buying to Push the price off the charts!  


Get in on this Breakout Winner Early!



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

Re: Mandatory -dbg packages for libraries? (and API docs too)

[Steve Greenland]

On 23-Apr-07, 15:51 (CDT), Neil Williams <[EMAIL PROTECTED]> wrote: 
> I think that all libraries - without exception - must come with some
> API documentation and the docs should be as complete and as accurate
> as possible - ideally generated from the source itself.

That's not a Debian issue. All we can do is include the documentation
provided by upstream. Sure, a DD *can* write docs when they are missing,
but we don't (and shouldn't) require it.

Is there any case where existing valid distributable documentation is
*not* in the appropriate Debian package? (Not including issues like the
GDL).

> Debian needs to reclaim the respect of upstream development teams and
> part of that is making it *a lot* easier to do upstream development on
> Debian without needing to become a DD as well.

Huh? Why do upstreams think that they need to be DDs to use Debian?
Because we discourage non-DD upstreams from distributing crappy
non-conforming .debs alongside their crappy non-conforming .rpms? (Not
that I blame upstreams for having crappy .debs; there's a lot of policy
and a lot of technology to understand - better to let a specialist take
care of it.)

> "All library packages must include at least basic API documentation
> either in the -dev package or in a dedicated -doc package where
> sufficient documentation exists. Wherever possible, documentation
> should cover the entire library API, be generated from the source code
> of the library and be registered with helper programs like dwww and/or
> devhelp etc."

I'd remove the "generated from the source code" clause. Yes, many
projects choose to do their docs that way. Some don't.

> 
> Would these changes need a GR?

No.

> Or submit these ideas to -policy and take from there?

Yes.

Steve


-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


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

Re: Mandatory -dbg packages for libraries? (and API docs too)

[Neil Williams]

On Mon, 23 Apr 2007 16:15:02 -0500
Steve Greenland <[EMAIL PROTECTED]> wrote:

> On 23-Apr-07, 15:51 (CDT), Neil Williams <[EMAIL PROTECTED]> wrote:
> > I think that all libraries - without exception - must come with some
> > API documentation and the docs should be as complete and as accurate
> > as possible - ideally generated from the source itself.
>
> That's not a Debian issue. All we can do is include the documentation
> provided by upstream. Sure, a DD *can* write docs when they are
> missing, but we don't (and shouldn't) require it.

Why not? What is wrong with writing a basic man (3) for a library when
we already have a requirement for a man (1) for the application?

A lack of application documentation makes a system hard for users - we
know that so Policy mandates a man (1) for these people whether one
exists in the .orig or not, even if it is almost empty.

A lack of library documentation makes a system hard for upstream
developers - these people are also Debian users and deserve support
too. True, they may be more 'advanced' than the average user in terms of
their knowledge of C or the autotools - doesn't mean that DD's can
assume that they know how a DD would find out the information they
need. Upstream generally tries to be as distro-neutral as possible -
this can be very difficult with inadequate documentation.

It is a Debian issue - it is precisely because the impression has got
about that Debian is unfriendly to upstream development that this kind
of change is absolutely necessary. The information isn't being made
accessible and that results in people thinking you have to know what a
DD knows in order to work out what is wrong with the upstream build on
your system.

These are development builds, not releases - not even snapshots. Things
often break and if we want upstream releases that build nicely on
Debian, it is good to encourage more upstream developers to use Debian.
DD's win in the end - cleaner upstream development builds make for
cleaner released .orig builds, meaning less patches! That has to be
AGoodThing (tm)!

Conversely, a lack of information can result in those upstream
developers who choose to use Debian being flamed as a result of that
choice because their commits break the build for other distros (another
snippet from my pre-DD days!) I can assure you, claiming that your
changes haven't broken the build on your Debian system cuts no ice when
the change has broken everyone else's build!!! Without the docs, the
Debian user is left without the information required to either defend
their change or fix the build. Not good.

If there is no documentation, file a bug upstream and ask. If the
response is RTSL, this should at least be documented in Debian so that
users of the -dev know who to blame for the lack of docs. Having a
Debian man (3) also provides a focus for contribution of suitable
content for the man (3) which in turn could be forwarded upstream. It's
easier to add content to an existing man (3) than to create a patch to
create a whole one from scratch - especially when the contributors are
not necessarily familiar with Debian packaging beyond apt-get.

> Is there any case where existing valid distributable documentation is
> *not* in the appropriate Debian package? (Not including issues like
> the GDL).

There is a distinct lack of man (3) and "coordinated" documentation for
libraries in Debian. True, some poorly documented packages include test
programs or examples somewhere under /usr/share/doc/ but it isn't
simple to track these down. At the very least, the Debian maintainer
should make it clear where these files are located in a man (3) for the
library. Where possible though, a full -doc package is a far, far
better option if Debian actually does want to support upstream
development on Debian.

That's why I stressed the registration of docs with dww and/or devhelp.

Some libraries have very, very good docs - libglib2, libgtk2 - the
problem comes with the smaller libraries, specialised tasks that are
only used by a few applications. By definition, few people will know
these API's yet these are often the very libraries that have the least
documentation - hence mandatory -doc or man (3).

> > Debian needs to reclaim the respect of upstream development teams
> > and part of that is making it *a lot* easier to do upstream
> > development on Debian without needing to become a DD as well.
>
> Huh? Why do upstreams think that they need to be DDs to use Debian?

I can only speak from my own experience upstream on this - I wasn't new
to Debian at the time but most questions that I asked (or problems that
I experienced) came back with a response of "must be something wrong
with Debian" because something everyone else did wasn't working for me.
I didn't have the documentation available to find out what was wrong and
it was very frustrating. In the end, I resorted to a laborious method
involving rsync and simultaneous builds on Debian and Fedora prior to
commits. That kind of

Re: Mandatory -dbg packages for libraries? (and API docs too)

[Joey Hess]

Neil Williams wrote:
> Would these changes need a GR?

Why would a policy change need a GR? How could a GR possibly be the best
way to choose a sound technical policy?

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Bug#388701: Why Beryl has just four packages?

[Andrea Bolognani]

On Mon, 23 Apr 2007 14:55:47 -0500
"Anibal Avelar" <[EMAIL PROTECTED]> wrote:

> If both projects joins but you don't upload them in unstable, but
> while we can have beryl, I like beryl than compiz due to the
> beryl-manager ;)

I guess beryl-manager will be merged as well (probably renamed).

--
KiyuKo 
Resistance is futile, you will be garbage collected.


pgpucz84GoT0h.pgp
Description: PGP signature

Re: Mandatory -dbg packages for libraries? (and API docs too)

[Steve Langasek]

On Tue, Apr 24, 2007 at 12:00:59AM +0100, Neil Williams wrote:
> On Mon, 23 Apr 2007 16:15:02 -0500
> Steve Greenland <[EMAIL PROTECTED]> wrote:

> > On 23-Apr-07, 15:51 (CDT), Neil Williams <[EMAIL PROTECTED]> wrote:
> > > I think that all libraries - without exception - must come with some
> > > API documentation and the docs should be as complete and as accurate
> > > as possible - ideally generated from the source itself.

> > That's not a Debian issue. All we can do is include the documentation
> > provided by upstream. Sure, a DD *can* write docs when they are
> > missing, but we don't (and shouldn't) require it.

> Why not? What is wrong with writing a basic man (3) for a library when
> we already have a requirement for a man (1) for the application?

That the existing requirement is already too much for us to keep up with, so
adding new requirements, especially ones that require significant attention
to detail to get right, dilutes our attention for little benefit?

> A lack of library documentation makes a system hard for upstream
> developers - these people are also Debian users and deserve support
> too.

Feel free to support them by writing any manpages you think are missing.

> It is a Debian issue - it is precisely because the impression has got
> about that Debian is unfriendly to upstream development that this kind
> of change is absolutely necessary.

Huh?

> There is a distinct lack of man (3) and "coordinated" documentation for
> libraries in Debian. True, some poorly documented packages include test
> programs or examples somewhere under /usr/share/doc/ but it isn't
> simple to track these down. At the very least, the Debian maintainer
> should make it clear where these files are located in a man (3) for the
> library.

That sounds to me like an abuse of section 3 of the man hierarchy.

> Where possible though, a full -doc package is a far, far
> better option if Debian actually does want to support upstream
> development on Debian.

I think it's preposterous to assert that it's Debian's responsibility to
provide upstream documentation for libraries in order to make Debian
appealing as a platform to other upstreams.

-- 
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: Mandatory -dbg packages for libraries? (and API docs too)

[Joey Hess]

Neil Williams wrote:
> I chose Debian as a development platform for my own reasons and my
> decision was "not deemed to be wise" in the eyes of some of my upstream
> colleagues. As the newbie to that particular team, I was under
> significant pressure to "upgrade to Fedora or SuSE". Debian needs to
> reclaim the respect of upstream development teams and part of that is
> making it *a lot* easier to do upstream development on Debian without
> needing to become a DD as well. Debian is respected as a
> distribution for users because of the multiple architecture support and
> the patches and bug reports that are forwarded upstream - what is
> missing (IMHO) is respect for Debian as the distribution of choice for
> upstream development itself.

Are you generalising from your one poor personal experience with a
non-Debian-friendly upstream, or do you have a significant body of data
that I don't about masses of upsteams who are not Debian friendly?

My impression has always been that a significant proportion of upstreams
use Debian, or are at least familiar with it. I base this on, amoung
other things, interacting with hundreds of different upstreams whose
packages I have maintained in Debian, as well as working in linux
companies and personally knowing a lot of upstream developers.

The only significant documentation that is missing in Debian that I know
of is GFDL licensed docs which have been removed from main. Aside from
that, if a library is missing documentation, it's missing it because
it's not available upsteam either.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Mandatory -dbg packages for libraries?

[Ben Hutchings]

On Sun, 2007-04-22 at 22:31 +0200, Hendrik Sattler wrote:
> Am Sonntag 22 April 2007 22:12 schrieb Russ Allbery:
> > Hendrik Sattler <[EMAIL PROTECTED]> writes:
> > > Am Sonntag 22 April 2007 21:39 schrieb Neil Williams:
> > >> Apart from those limitations, is there a *technical* reason why -dbg
> > >> packages should not be available? Is it worth taking to -policy?
> > >
> > > You essentially need to build all library packages 2 times, then.
> >
> > Actually, you don't.  See the features of dh_strip introduced at debhelper
> > level V5.  And of course you can do the same thing by hand.
> >
> > gdb will read the resulting detached debugging symbols automatically.
> 
> Did you ever try to debug an application compiled with optimizations?


Of course.  There are many "undefined behaviour" bugs that will only
show up in optimised builds.  You have to stop relying on source lines
and look at the disassembly, of course.

Also, oprofile wants debugging information, and there's no sense in
turning optimisations off for that!

Ben.

-- 
Ben Hutchings
When you say `I wrote a program that crashed Windows', people just stare ...
and say `Hey, I got those with the system, *for free*'. - Linus Torvalds


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

Re: Mandatory -dbg packages for libraries?

[Ben Hutchings]

On Sun, 2007-04-22 at 22:14 +0200, Florian Weimer wrote:
> * Neil Williams:
> 
> > Apart from those limitations, is there a *technical* reason why -dbg
> > packages should not be available?
> 
> GCC's debugging information at -O2 will continue to worsen (in part as
> a result of -O2 getting better).

It's now quite capable of telling the debugger that a source line has
ended up in several different chunks of object code, and that a variable
moves around between memory and registers.

Ben.

-- 
Ben Hutchings
When you say `I wrote a program that crashed Windows', people just stare ...
and say `Hey, I got those with the system, *for free*'. - Linus Torvalds


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

Bug#420678: dmesg spam: ACPI: Unable to turn cooling device [c18e0dec] 'on'

[Bryan Donlan]

Package: general
Severity: minor

The following line is repeated continually in dmesg:
ACPI: Unable to turn cooling device [c18e0dec] 'on'

This begins shortly after hald loads and repeats about ten times a
minute.

uname -a:
Linux hanyuu 2.6.18-4-k7 #1 SMP Mon Mar 26 17:57:15 UTC 2007 i686 GNU/Linux

using:
ii  linux-image-2.6.18-4-k7 2.6.18.dfsg.1-12

lspci -vv @ http://www.fushizen.net/lspci-vv.txt

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

Kernel: Linux 2.6.18-4-k7 (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/bash


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

Re: Mandatory -dbg packages for libraries?

[Manoj Srivastava]

On Mon, 23 Apr 2007 15:05:22 -0400, Joey Hess <[EMAIL PROTECTED]> said: 


>> I would rather add it as a recommended practice in policy, with a
>> note that it will become a should/must as we get better coverage, and
>> _also_ provide examples of what maintainers need to do to create
>> separate debugging symbol packages in an informative footnote.

> Well, we've made more than ~300 packages insta-buggy with policy
> changes before. It's not insta-rc-buggy. OTOH, I don't really care;
> 300 bug reports could be mass-filed w/o it being a "should" in policy.

If I have inadvertently done so in the past, I feel the need to
 apologize, but my past mistakes do not condone me making the same
 errors again.

> Note that I've already written some documentation for
> developers-reference in #420540.

Thanks. Now that we have released Etch, I need to be getting
 back at updating policy again, there are a number of issues sitting on
 my TODO list.

> The policy-relevant bits are that we use
> /usr/lib/debug/, that the files should not be
> executable (possibly a common mistake since objcopy preserves
> executable bits IIRC), and that the package names end in -dbg and the
> debug packages depend on an equal version of the package they provide
> debugging symbols for.

Actually, the whole writeup seems good, and some of it can be
 kept informative rather than normative.

I'll queue this up for things to do when I do get some round
 tuits to spend on policy, and see about adding -dbg packages for the
 libraries I have.

manoj
-- 
My Boss needs a surge protector.  That way her mouth would be buffered
from surprise spikes in her brain.
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Mandatory -dbg packages for libraries?

[Damián Viano]

On Sun, Apr 22, 2007 at 07:29:55PM -0400, Joey Hess wrote:
> Neil Williams wrote:
> > > > Certain packages have already had bug reports requesting a -dbg
> > > > package.
> > >
> > > I'd rather see some offline debug-symbol infrastructure for all
> > > packages implemented, so that you can download the debug symbols when
> > > you need them.
> > 
> > But the -dbg package only depends on the same version of the library -
> > the library won't depend on the -dbg so those who need the -dbg are the
> > only ones who would download and install them.
> 
> Each time this has come up before, the concern has been that adding -dbg
> versions of every binary package would greatly inflate the size of the
> archive, and nearly double the total number of packages, with associated
> scalability problems.
> 
> Even with separated debugging symbols, -dbg packages are frequently
> larger than the package they provide debugging symbols for. See for
> example xserver-xorg-core-dbg. Looking through the 227 lib*-dbg
> packages, I found few contain separated debugging symbols, except for
> packages maintained by the xorg team[1]. I'm not sure if this is due
> many people still not knowing about separated debugging symbols, or due
> to technical reasons. For example, is there a tecnical reason why
> libc6-dbg does not contain separated debugging symbols?
> 
> Anyway, doubling the size of the archive is less of an issue than it
> might have been in the past, since we've done the archive split, and
> since ftp-master has 1.4 Terabytes of disk with half that unused, but
> it is still a concern, for mirrors, number of DVDs, etc.

What about some special parts on the archive for this, somethings like
what is actually used for source packages, but of course arch dependant:

deb-dbg http://http.us.debian.org/debian sid main

could translate to http://http.us.debian.org/debian/dist/sid/main/dbg-$arch
where all the -dbg packages could live. That would minimize the impact
making -dbg packages easier not to mirror and avoid cluttering packages
lists for non-developers users while only adding a 'add a deb-dbg
mirror' instruction for requesting a backtrace on a bug report.

> Scalability issues with the number of packages have also been reduced in
> some areas. apt no longer has to download the while Packages files on
> each update, so it wouldn't take 2x the bandwidth to add -dbg packages
> for every package to the Packages files. There would still be
> significant impact in apt's memory usage, in the disk space used to
> store the Packages files, in the UIs that have to somehow present or
> hide all these -dbg packages, etc.

With the above approach this impact is minimized quite nicely. 

> I've considered before trying to set up a separate, parallel archive
> that would only hold the -dbg packages, but implementing that without
> initially using the Debian infrastructure would be tough, and my
> experiences with setting up[2]/maintaining the separate udeb section of
> the archive is that it adds a lot of complexity.
> 
> Someone made a very good point that it's often and increasingly painful to
> rebuild debugging versions for the whole library chain of a binary.
> OTOH, rebuilding a debug version of the binary itself is not especially
> hard.
> 
> So while I'd love to have a way to have -dbg packages available for
> every binary, I actually am happy with this proposal to do it for only
> every library (plus whatever other binaries really need it). And it's a
> direction we're already moving in, with, as I mentioned, 227 lib*-dbg
> packages already in the archive. That's more than 10% of all our
> libraries already done[3].
> 
> So I suggest that we take this as an existing practice, document it as a
> "should" in policy for now, document *how* to do separated debugging
> symbols in the developers reference (which does not currently seem to
> mention it at all), and go add -dbg versions of our library packages.
> 
> -- 
> see shy jo, doing so for aalib now
> 
> [1] Who are doing a really nice job on their -dbg packages.
> [2] Actually, the ftp-masters did all the real setup work.
> [3] Conversely, there are only 62 -dbg packages for non-libraries..

-- 
Damián Viano(Des)  ¯ ¯ - _   _ - ¯ ¯
GPG: 0x6EB95A6F Debian ¯-_GNU_-¯ Linux
Web: http://damianv.com.ar/   ¯-¯


signature.asc
Description: Digital signature

Processed: Re: Bug#420678: dmesg spam: ACPI: Unable to turn cooling device [c18e0dec] 'on'

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reassign 420678 hal
Bug#420678: dmesg spam: ACPI: Unable to turn cooling device [c18e0dec] 'on'
Bug reassigned from package `general' to `hal'.

> thanks
Stopping processing here.

Please contact me if you need assistance.

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


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

Re: [ITH] xmltex, passivetex, offer to take over jadetex

[Ardo van Rangelrooij]

Daniel Leidert ([EMAIL PROTECTED]) wrote:
> Am Montag, den 23.04.2007, 15:46 +0200 schrieb Frank K?ster:
> 
> > in the last months or even years, xmltex and passivetex have been
> > basically unmaintained (and they *do* have bugs), and responses from the
> > list which is listed as maintainer are very rare.  jadetex is actually
> > maintained by you, Ohura-san, but maybe gets not as much care as it
> > could have - and anyway the coordination with the TeX Task Force could
> > be better than we currently manage for a package so tightly coupled to
> > TeX.
> > 
> > On the other hand, integration of these three components into TeXLive
> > has already been accomplished upstream, and we only cut them out because
> > they existed as separate packages already in the days of teTeX only.
> 
> I already saw that and wanted to contact you to talk about a possible
> overhanding of xmltex (I saw, that the xmltex page says, it's part of
> texlive).
> 
> > We therefore intend to essentially take over xmltex and passivetex,
> 
> No objections from me. I CCed Ardo van Rangelrooij, who seems
> responsible for xmltex as part of the Debian XML/SGML group.

No objections from me also.

Thanks,
Ardo
-- 
Ardo van Rangelrooij Debian XML/SGML Group
<[EMAIL PROTECTED]>  <[EMAIL PROTECTED]>
http://people.debian.org/~ardo/  http://debian-xml-sgml.alioth.debian.org/


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

Re: Mandatory -dbg packages for libraries? (and API docs too)

[Felipe Sateler]

Neil Williams wrote:


> There is a distinct lack of man (3) and "coordinated" documentation for
> libraries in Debian. True, some poorly documented packages include test
> programs or examples somewhere under /usr/share/doc/ but it isn't
> simple to track these down.

Is it unreasonable to expect libfoo's docs (independent of format or
quality) to be located under /usr/share/doc/libfoo, and not somewhere else?


> Noting if the Debian library package differs significantly to
> the library upstream and why - not somewhere in NEWS.gz or README.gz,
> but in the one place application developers will look, the API docs.

AFAIK, README.Debian is _the_ place where divergences from upstream should
be noted. I can't find (yes, I only glanced through the documents, please
correct me if I'm wrong) any reference to that neither in the Debian FAQ
nor the Debian Reference, which I assume are the 2 most important user
documents. Maybe a note should be added?


-- 

  Felipe Sateler


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