doc-base, menu, and policy (Re: Debian Policy 3.7.3.0 uploaded)

[Charles Plessy]

Le Sun, Dec 02, 2007 at 11:15:46PM -0800, Russ Allbery a écrit :
>   * Substantial reorganization and renaming of sections in the Debian
> menu structure.  Packages with menu entries should be reviewed to
> see if the menu section has been renamed or if one of the new
> sections would be more appropriate.   [menu 
> policy]

Dear all,

according to the doc-base manual (2.3.2.1):

 _Section_
  Section where the document belongs; this should follow the
  sections outlined in The Debian Menu sub-policy
  
(http://www.debian.org/doc/packaging-manuals/menu-policy/ch2.html#s2.1).
  Required field.

I am wondering if when a .doc-base file is not updated, it makes the package
uncompliant with the new Policy, or only with the doc-base manual ?

Have a nice day,

-- 
Charles Plessy
http://charles.plessy.org
Wakō, Saitama, Japan


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

Re: Parallel build results

[Marco d'Itri]

On Dec 02, Daniel Schepler <[EMAIL PROTECTED]> wrote:

> I finally got through the test builds of all the source packages in sid for 
> i386 using dpkg-buildpackage -j3 on a dual core machine.  The results as 
> before are at http://people.debian.org/~schepler/build-logs/bymaint.html .  

Can you explain the meaning of this failure and how it should be fixed?

make[2]: warning: jobserver unavailable: using -j1.  Add `+' to parent make 
rule.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Draft new policy document format

[Manoj Srivastava]

On Sun, 2 Dec 2007 12:34:28 +0100, Stefano Zacchiroli <[EMAIL PROTECTED]> said: 

> On Sat, Dec 01, 2007 at 12:29:28AM -0600, Manoj Srivastava wrote:
>> At Debconf earlier this year, I gave a talk about the benefits

>> Comments appreciated.

> As a general comment, before seeing an actual XML-like format I would
> like to see a list of what semantic information a document in such a
> format should be able to express. E.g. "a set of rules, each of which
> with a mandatoriness level which is one among MUST/SHOULD/... bla bla
> together with bla bla". Can you please summarize such information for
> us?

Ultimately, the document in such a format should be able to
 express what the current policy documents do.  Do we really need to
 define what the technical policy expresses?

> In addition to that, just some tiny nitpicking below.

>>  Policy Rule Example
>> 
>>  MUST 

> I find this use of  inappropriate. The role is fine, but the one
> thing above is definitely not a paragraph, so it should not be tagged
> as such.

Well. It is a paragraph, with a single word as a content. I'm
 pretty sure that is legit, in English, as well as in XML.  If you wish,
 we can make the paragraph longer, by sticking in a definition of the
 priority, which helps when looking at the rule in isolation, but would
 tend to get boringly repetitive when reading a manual.

However, I am willing to change this to a better alternative.

> Unfortunately I'm writing this email offline so I'm unable to check
> whether docbook has any more appropriate element for this or where
> else can be but a  element, but something better then this
> should be looked for.

These elements contain property: action, application, attribution,
bibliomisc, bridgehead, citation, citetitle, classsynopsisinfo, code,
command, computeroutput, database, emphasis, entry, filename, firstterm,
foreignphrase, funcparams, funcsynopsisinfo, function, glosssee,
glossseealso, glossterm, hardware, interfacename, keycap,
lineannotation, link, literal, literallayout, lotentry, member, msgaud,
olink, option, optional, para, parameter, phrase, primary, primaryie,
productname, programlisting, property, quote, refdescriptor,
refentrytitle, refname, refpurpose, remark, screen, screeninfo,
secondary, secondaryie, see, seealso, seealsoie, seeie, seg, segtitle,
simpara, subtitle, synopsis, systemitem, td, term, termdef, tertiary,
tertiaryie, th, title, titleabbrev, tocback, tocentry, tocfront,
trademark, ulink, userinput. 

manoj
-- 
It's later than you think.
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: doc-base, menu, and policy (Re: Debian Policy 3.7.3.0 uploaded)

[Stefano Zacchiroli]

On Mon, Dec 03, 2007 at 05:24:06PM +0900, Charles Plessy wrote:
> according to the doc-base manual (2.3.2.1):
> 
>  _Section_
>   Section where the document belongs; this should follow the
>   sections outlined in The Debian Menu sub-policy
>   
> (http://www.debian.org/doc/packaging-manuals/menu-policy/ch2.html#s2.1).
>   Required field.
> 
> I am wondering if when a .doc-base file is not updated, it makes the package
> uncompliant with the new Policy, or only with the doc-base manual ?

I would say only with the doc-base manual, but as I've expressed before,
I found not reasonable that the doc-base hierarchy is bound to the menu
one. Beside not being meant to be browsed as a menu is (different user
goal, the ability to do an automated search which is missing in a menu,
...), that choice make hard to use doc-base for subsystems (for example
having a section with all the library references of language X).

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: Parallel build results

[Tim Cutts]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On 2 Dec 2007, at 2:21 am, Daniel Schepler wrote:

I finally got through the test builds of all the source packages in  
sid for
i386 using dpkg-buildpackage -j3 on a dual core machine.  The  
results as
before are at http://people.debian.org/~schepler/build-logs/bymaint.html 
 .

Some statistics:

   204 built BROKEN packages
  1408 FAILED
   230 FAILED, even with regular build
  8986 succeeded
  1014 succeeded, but with jobserver warnings

These are not encouraging statistics, especially considering the  
fact that
there are undoubtedly many false negatives, so I'll hold off on  
submitting

bug reports for now.


Well, am-utils lists as building broken packages, but when I looked at  
the log, it was just that the parallel build had produced the multiple  
binary packages in a different order from the serial build.  At least,  
that's my interpretation of the following from debdiff:


Files moved or copied from at least TWO packages or to at least TWO  
packages

- 
- -rw-r--r--  root/root   DEBIAN/control
From packages: am-utils-doc, am-utils, libamu4, libamu-dev
To packages: am-utils-doc, libamu4, libamu-dev, am-utils
- -rw-r--r--  root/root   DEBIAN/md5sums
From packages: am-utils-doc, am-utils, libamu4, libamu-dev
To packages: am-utils-doc, libamu4, libamu-dev, am-utils
- -rwxr-xr-x  root/root   DEBIAN/postinst
From packages: am-utils-doc, am-utils, libamu4
To packages: am-utils-doc, libamu4, am-utils
- -rwxr-xr-x  root/root   DEBIAN/postrm
From packages: am-utils, libamu4
To packages: libamu4, am-utils

Or does that mean something more basic that's wrong with the packages?

Tim
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)

iQEVAwUBR1PWWBypeFo2odvPAQLydAgArlhmYhkRt8s4FDKg8i5QYa6DlgrKJCz3
fKifS0P0w8yR3E7NLkpS5co+lFZ2Htb2xs4MMD7pWmRBXCxIsh6+6bIPnUfc/mp1
C3VfdfPwPAoER/A6EryfoBA2Y+tof7ewVjEDFaViIlWxsDhaRQgLAck/xx1m51Yd
pbnscakO7P8BK9yzirhHHJ6VmlXgU4HkES2xkzZzAumxnmrklkzRWIg52iCBhi8h
kGwTmBVAMeRlXP1Iu6sGZFGOIh72wjO2EQ7M5GsbVPYkwbPN/FoyrceSe+2hz+CO
2sA/w9f3wRhIH1WfgiLZTj4d9YGM95iNvkqhl4Wlc6A7IEkgSMvdHg==
=QcpJ
-END PGP SIGNATURE-


--
The Wellcome Trust Sanger Institute is operated by Genome Research 
Limited, a charity registered in England with number 1021457 and a 
company registered in England with number 2742969, whose registered 
office is 215 Euston Road, London, NW1 2BE. 



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

Re: Parallel build results

[Bernhard R. Link]

* Marco d'Itri <[EMAIL PROTECTED]> [071203 09:53]:
> Can you explain the meaning of this failure and how it should be fixed?
> 
> make[2]: warning: jobserver unavailable: using -j1.  Add `+' to parent make 
> rule.

That usually means a new make is started without the calling make
realizing it is starting a make. In most of the cases that means that
some makefile (like debian/rules) is calling make instead of $(MAKE).

There are also some special other cases (like when $(MAKE) is used, but not
directly but indirectly referenced, then this might be fixed by
prefixing the command with a +, but beware of the other meanings this
has.), which normally dictate a closer look, as when something is doing
such absurdities, there might be some reason to it. (well, or not)

Hochachtungsvoll,
Bernhard R. Link


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

Re: Parallel build results

[Bernhard R. Link]

* Patrick Schoenfeld <[EMAIL PROTECTED]> [071202 20:43]:
> Relevant parts for detox are:
> /usr/bin/install -c -d /tmp/buildd/detox-1.1.1/debian/tmp/etc
> /usr/bin/install: cannot create regular file
> `/tmp/buildd/detox-1.1.1/debian/tmp/etc/detoxrc.sample': No such file or
> directory
> 
> So I assume the first install command for debian/tmp/etc was not
> successful? I'm not very experienced with parallel builds and I cannot
> reproduce this on my single-core-systems. So: Is there some
> documentation or hints on how to make package building be parallel-safe?

The problem is in upstream's Makefile.in:

install: install-base install-safe-config install-sample-config

install-base: detox
...snip
${INSTALL} -d ${DESTDIR}${sysconfdir}
...snip

install-safe-config:
@if [ ! -f ${DESTDIR}${sysconfdir}/detoxrc ]; then \
${INSTALL} detoxrc ${DESTDIR}${sysconfdir}; \
..snip...

As you can see, install says it needs install-base and install-sample-config
but install-sample-config does not say it wants install-base to be run before
it is run, so nothing enforces sysconfigdir is actually created.
Only when install-safe-config is run while install-base had not yet had enough
time to complete directory creating, this produces an error.

The fix for this problem is just to tell install-safe-config (and the other
install-* stuff needing a directory) to either create the directory first or
depend on the rule that creates it.

Catching those race conditions is hard, even a -jN run might just not trigger it
if the directory creating is fast enough. Perhaps someone would like to write a
patched make that does reorderable target in reversed order and try to build the
whole archive with it (and -j1), to catch those problems more reliable.

Hochachtungsvoll,
Bernhard R. Link
-- 
"Never contain programs so few bugs, as when no debugging tools are available!"
Niklaus Wirth


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

Re: Parallel build results

[Simon Josefsson]

Daniel Schepler <[EMAIL PROTECTED]> writes:

> I finally got through the test builds of all the source packages in sid for 
> i386 using dpkg-buildpackage -j3 on a dual core machine.  The results as 
> before are at http://people.debian.org/~schepler/build-logs/bymaint.html .  

Which said:

shishi: succeeded, but with jobserver warnings

and in the logs:

...
make[1]: warning: jobserver unavailable: using -j1.  Add `+' to parent
 make rule.
...

I believe I've fixed this in the debian package CVS.  The problem was
use of 'make' rather than '$(MAKE)' in rules.

Thanks,
Simon


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

Bug#454138: ITP: libdbix-class-htmlwidget-perl -- Like FromForm but with DBIx::Class and HTML::Widget

[Al Nikolov]

Package: wnpp
Severity: wishlist
Owner: Al Nikolov <[EMAIL PROTECTED]>


* Package name: libdbix-class-htmlwidget-perl
  Version : 0.11
  Upstream Author : Thomas Klausner <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/~andremar/DBIx-Class-HTMLWidget/ 
* License : Artistic or GPL
  Programming Lang: Perl
  Description : Like FromForm but with DBIx::Class and HTML::Widget

 Something like Class::DBI::FromForm / Class::DBI::FromCGI but using
 HTML::Widget for form creation and validation and DBIx::Class as a
 ORM.
 .
 This description was automagically extracted from the module by
 dh-make-perl.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable'), (200, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-686
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)



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

Re: Parallel build results

[Daniel Schepler]

On Monday 03 December 2007 05:11:35 am Tim Cutts wrote:
> Well, am-utils lists as building broken packages, but when I looked at
> the log, it was just that the parallel build had produced the multiple
> binary packages in a different order from the serial build.  At least,
> that's my interpretation of the following from debdiff:
>
> Files moved or copied from at least TWO packages or to at least TWO
> packages
> ---
>- -rw-r--r--  root/root   DEBIAN/control
>  From packages: am-utils-doc, am-utils, libamu4, libamu-dev
> To packages: am-utils-doc, libamu4, libamu-dev, am-utils
> -rw-r--r--  root/root   DEBIAN/md5sums
>  From packages: am-utils-doc, am-utils, libamu4, libamu-dev
> To packages: am-utils-doc, libamu4, libamu-dev, am-utils
> -rwxr-xr-x  root/root   DEBIAN/postinst
>  From packages: am-utils-doc, am-utils, libamu4
> To packages: am-utils-doc, libamu4, am-utils
> -rwxr-xr-x  root/root   DEBIAN/postrm
>  From packages: am-utils, libamu4
> To packages: libamu4, am-utils
>
> Or does that mean something more basic that's wrong with the packages?

The relevant difference is actually:

Control files of package am-utils: lines which differ (wdiff format)

Depends: libamu4 (= 6.1.5-7), portmap, {+libamu4,+} libc6 (>= 2.6.1-1), 
libgdbm3, libhesiod0, libldap2 (>= 2.1.17-1), libwrap0, perl, debconf (>= 
1.2.0), ucf, debianutils (>= 1.6)

So the Depends line got changed in the parallel build.
-- 
Daniel Schepler


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

Re: Parallel build results

[Tim Cutts]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On 3 Dec 2007, at 12:43 pm, Daniel Schepler wrote:


Control files of package am-utils: lines which differ (wdiff format)

Depends: libamu4 (= 6.1.5-7), portmap, {+libamu4,+} libc6 (>=  
2.6.1-1),
libgdbm3, libhesiod0, libldap2 (>= 2.1.17-1), libwrap0, perl,  
debconf (>=

1.2.0), ucf, debianutils (>= 1.6)

So the Depends line got changed in the parallel build.


Sure, yes, I realise that one.  Don't know why it's happening though.  
It may change though as I make changes do deal with the shlibdeps  
stuff that's also going on at the moment, so I'm going to deal with  
that first, and see whether this problem persists afterwards.


Tim
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)

iQEVAwUBR1QEaBypeFo2odvPAQJ1WQgAizNT66pUw/GB72oB8zc1+RVzYrseaRFo
pqZIerbj1mr3G4rKur+wuYAfVEJDR9zgSWEmebwGuklHsa+eztWcYAgWfD8OBvmD
1vSyhIhfgN0tARQQORX7Ba9G3lM7MnLs8/Rvn3APm0/vacJDDKCucEwdsTqDGpDH
yBh6/9yxF8lLiaumiomGO+vFZTkREXk2CtxNI8nh44ijgYkSdj1QZj9lZ7cuCC3W
8FnHeLlit9l2K3EVH/0dE/3YcBt2uf3QRfURVKdtPrwpNMuGh0FkuHdScm+BPh/L
oDHtYuSxkElPam3q25a8wno15wVt5qaz+nJ43TtvsC6WGJNxIqNorw==
=I2Ko
-END PGP SIGNATURE-


--
The Wellcome Trust Sanger Institute is operated by Genome Research 
Limited, a charity registered in England with number 1021457 and a 
company registered in England with number 2742969, whose registered 
office is 215 Euston Road, London, NW1 2BE. 



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

Re: Parallel build results

[Patrick Schoenfeld]

Hi Bernhard,

On Mon, Dec 03, 2007 at 12:21:45PM +0100, Bernhard R. Link wrote:
> The problem is in upstream's Makefile.in:

thanks for the good explanation. Also to Daniel whose hint already pointed me
in the right direction. Its already fixed in latest upload.

Thanks,
Best Regards

Patrick


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

Views on bounties in Open Software Development wanted

[Martin Nilsson]

Dear Reader,

We are two students at the University of Lund, Sweden, currently writing our 
bachelor thesis. The focus for this study is the use of bounties in Open Source 
Software Development. 

If you are an Open Source developer with views on the matter, or if you have 
experience from bounties you are of extra interest to us. The purpose of this 
topic is to investigate whether you have the possibility to participate in an 
interview. The proposed interview should take less than 30 minutes. It will be 
conducted by regular phone, Skype, MSN voice call, Google Talk, or whatever way 
you prefer. 

We seek better understanding of the bounty phenomenon and would be most 
thankful if you have the opportunity to contribute. 

If this of interest we can be contacted by e-mail or MSN Messenger at either 
[EMAIL PROTECTED] or [EMAIL PROTECTED] 

Best Regards, 
Henry Marsch 
Martin Nilsson 

-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail


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

Re: Bug#451799: new evince cannot display Japanese characters correctly

[Osamu Aoki]

On Wed, Nov 28, 2007 at 01:22:49PM +0100, Ondřej Surý wrote:
> > However I don't think there is anything copyrightable in these files;
> > they only contain series of numbers that describe the mappings. Do you
> > people think it could be suitable for main?
> > (Please follow-up on -legal only for licensing discussions.)
> > 
> > Ondrej, are you willing - if the legal problems are settled out - to
> > package it? Otherwise I guess me or any of the co-maintainers could do
> > it, the packaging is absolutely trivial.
> 
> It's already packaged in pkg-freedesktop SVN, but it was rejected by
> ftp-masters due licensing problems.

If problem is only modification right, why not uploading to non-free?

Osamu

Re: Draft new policy document format

[Eric Cooper]

On Sun, Dec 02, 2007 at 12:34:28PM +0100, Stefano Zacchiroli wrote:
> In addition to that, just some tiny nitpicking below.
> [...] 

I had the same initial reaction, but when I re-read Manoj's
introduction, I think he suggests that this docbook format should be
the *output* of an XSLT tool; the various policies would be encoded as
individual XML entities with a more semantically appropriate schema
(TBD, I guess).

-- 
Eric Cooper e c c @ c m u . e d u


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

Re: Injecting versions of build-deps in the deps

[Loïc Minier]

On Sun, Dec 02, 2007, Mike Hommey wrote:
> I think there is a problem using build dependencies for that purpose:
> There are dozens of reasons why you want to build-depend on libfoo-dev
> >= version that do NOT involve working around bugs in the library at
> runtime. There are so many that it would just pollute a lot of
> dependencies for a few interesting cases, and would sadly end up going
> in the opposite way we are currently heading for with the addition of
> dpkg-gensymbols.

 First, I see this solution as a complement to dpkg-gensymbols when
 symbols are not at the proper granularity to inject deps.

 Yes, in some cases build-deps are bumped for -dev features which are
 not connected to the runtime lib -- shlibs are bumped very often for a
 very small part of the ABI and symbols have a similar problem for ABI
 which can't be expressed by matters of symbols.

 Consider a library providing parsing for "sin()" and "cos()" via
 "result_t parse(const char *)".  It gains support for "tan()" in a new
 version.  If you want to make sure that anything checking at buildtime
 for "tan()" gets it at runtime, you need to inject a very high version
 via shlibs or symbols deps all the time, and all libs get a very high
 dep -- even if they only use "sin()".

> Now, the thing is you can pretty much already do some kind of trick to
> do what you want, with shlibs.local. The only problem with shlibs.local
> is that is forces to use the shlibs in this file and only these, so if
> the package's shlibs tell to depend on a newer version, it won't be
> taken into account.

 Of course, you can argue that the packages should maintain dependencies
 on such ABI manually, but in the case of e.g. Gtk+, I don't expect to
 require 1000 packages to maintain a proper dep on libgtk2.0-0 with
 basically the same version as the build-dep.

 Many upstreams already check for a particular version of a build-dep in
 their configure.ac or whatever; this usually translates in a build-dep
 with a similar version in debian/control.  That's why I propose to use
 this data for runtime as well as it often represents what upstream
 needs at build time and runtime.
   And even if the build-dep was bumped for some other reason, I think
 it doesn't hurt much.

-- 
Loïc Minier


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

Re: Injecting versions of build-deps in the deps

[Josselin Mouette]

Hi,

Le dimanche 02 décembre 2007 à 17:11 +0100, Loïc Minier a écrit :
>  An idea that came up is to use a per-dependent package information
>  provided by the maintainer such as the build-deps version [2].  It
>  would require a map from deps to build-deps and could typically be
>  combined with the existing systems to inject a dependency >=
>  max(shlibdeps version, bdeps version).

I like it, and I also think it would be the opportunity to go further in
the direction of dependency automation.

Currently, many upstreams use pkg-config to specify their build
dependencies, and it is, regardless of other issues, a good system that
we should promote towards upstream developers. We could build on
pkg-config and replace it, during the build, by a wrapper that dumps
some information in a build-specific place when the call is successful.

Let’s say that the upstream configure.ac specifies the following:
PKG_CHECK_MODULES (FOO, x11 >= 1.0.2
gtk+2.0 >= 2.8
gconf >= 2.0)

And the source package specifies:
Build-Depends: libx11-dev (>= 2:1.0), libgtk2.0-dev (>= 2.10), libgconf2-dev 
(>= 2.0)

Every successful call to pkg-config would fill in a file, let’s say
debian/pkgconfig.deps, that would in the end contain:

# pkgconfig_file required_version dev_package shared_package
version
x11 1.0.2 libx11-dev libx11-6 2:1.0.3-7
gtk+2.0 2.8 libgtk2.0-dev libgtk2.0-0 2.12.2-1
gconf 2.0 libgconf2-dev libgconf2-4 2.20.1-1
(The package version is needed because you need to extract epochs.)

In the end, shlibs generation would be able to generate the correct
dependency, based on the highest of the three versions:
 1. the version required by upstream;
 2. the version required by the build-deps;
 3. the version generated by the symbols file.

Plus, in this specific case, it would make the build fail because the
Debian maintainer has forgotten to bump the libx11-dev build-dependency
to 2:1.0.2, which is deadly useful information.

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


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

Re: Injecting versions of build-deps in the deps

[Josselin Mouette]

Le dimanche 02 décembre 2007 à 19:35 +0100, Mike Hommey a écrit :
> I think there is a problem using build dependencies for that purpose:
> There are dozens of reasons why you want to build-depend on libfoo-dev
> >= version that do NOT involve working around bugs in the library at
> runtime. There are so many that it would just pollute a lot of
> dependencies for a few interesting cases, and would sadly end up going
> in the opposite way we are currently heading for with the addition of
> dpkg-gensymbols.

I can think of very few cases where you want to bump the
build-dependency without bumping the runtime dependency as well, and I
cannot think of cases where doing that could actually break something.

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


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

Re: Injecting versions of build-deps in the deps

[Julien Cristau]

On Mon, Dec  3, 2007 at 17:33:41 +0100, Josselin Mouette wrote:

> Every successful call to pkg-config would fill in a file, let’s say
> debian/pkgconfig.deps, that would in the end contain:
> 
> # pkgconfig_file required_version dev_package shared_package
> version
> x11 1.0.2 libx11-dev libx11-6 2:1.0.3-7
> gtk+2.0 2.8 libgtk2.0-dev libgtk2.0-0 2.12.2-1
> gconf 2.0 libgconf2-dev libgconf2-4 2.20.1-1
> (The package version is needed because you need to extract epochs.)
> 
> In the end, shlibs generation would be able to generate the correct
> dependency, based on the highest of the three versions:
>  1. the version required by upstream;
>  2. the version required by the build-deps;
>  3. the version generated by the symbols file.
> 
> Plus, in this specific case, it would make the build fail because the
> Debian maintainer has forgotten to bump the libx11-dev build-dependency
> to 2:1.0.2, which is deadly useful information.
> 
Why would you depend on any particular version of libx11-6?  The
build-dep on libx11-dev >= 1.0.2 I can understand, but the runtime
dependency has nothing to do with this.

Cheers,
Julien


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

Re: Injecting versions of build-deps in the deps

[Mike Hommey]

On Mon, Dec 03, 2007 at 05:36:43PM +0100, Josselin Mouette wrote:
> Le dimanche 02 décembre 2007 à 19:35 +0100, Mike Hommey a écrit :
> > I think there is a problem using build dependencies for that purpose:
> > There are dozens of reasons why you want to build-depend on libfoo-dev
> > >= version that do NOT involve working around bugs in the library at
> > runtime. There are so many that it would just pollute a lot of
> > dependencies for a few interesting cases, and would sadly end up going
> > in the opposite way we are currently heading for with the addition of
> > dpkg-gensymbols.
> 
> I can think of very few cases where you want to bump the
> build-dependency without bumping the runtime dependency as well.

Most of the versioned build dependencies in my packages are to
circumvent problems or changes in debian packaging of dev packages.
But maybe I don't maintain typical packages.

Mike


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

Re: Draft new policy document format

[Holger Levsen]

Hi Manoj,

On Saturday 01 December 2007 07:29, Manoj Srivastava wrote:
> At Debconf earlier this year, I gave a talk about the benefits
>  of creating language for a lintian/linda check whenever we introduce a
>  new policy rule (when appropriate, and feasible, of course)...

I've completly missed that, or at least I dont remember.. guess I was busy :)

[...]
> With this in mind, I have created an initial draft format of the
>  Debian technical policy set, and am including it in this mail.
>
> Comments appreciated.

Looks good and exciting to me! Thank you (all) for working on this!

Now that I write this "thank you" mail I notice I have something (little) to 
contribute: please keep in mind, that there are also policies without lintian 
checks, like DMUP, testing transition policies and whatnot. It would be 
great, if they could also profit from this.


regards,
Holger


pgpfxNNozVOfW.pgp
Description: PGP signature

Bug#454189: ITP: brad -- Blender based user interface for Radiance

[Bernd Zeimetz]

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

* Package name: brad
  Version : 0.2_2007-01-08
  Upstream Author : Francesco Anselmo
* URL : https://savannah.nongnu.org/projects/brad/
* License : GPL
  Programming Lang: Python
  Description : Blender based user interface for Radiance

Blended RADiance (brad) is able to export Blender models to Radiance,
both static models or animations, to make it easier to setup the
simulation parameters, to calculate luminance/illuminance values on
arbitrary grids.



The binary package will probably be called blender-radiance or
blended-radiance - not sure about this yet, though.



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

Re: Draft new policy document format

[Manoj Srivastava]

On Mon, 3 Dec 2007 10:21:10 -0500, Eric Cooper <[EMAIL PROTECTED]> said: 

> On Sun, Dec 02, 2007 at 12:34:28PM +0100, Stefano Zacchiroli wrote:
>> In addition to that, just some tiny nitpicking below.  [...]

> I had the same initial reaction, but when I re-read Manoj's
> introduction, I think he suggests that this docbook format should be
> the *output* of an XSLT tool; the various policies would be encoded as
> individual XML entities with a more semantically appropriate schema
> (TBD, I guess).

You give me too much credit :-)

I was not thinking of this as an output; though if there are
 more semantically appropriate schemas for a rule, then I would
 appreciate people presenting them here; I am not wedded to the draft
 format in any way.  I confess I spent only about 30 minutes to an hour
 drawing up the draft, so if people treat it as a strawman proposal to
 be knocked down by a better schema, the better for us, I say.

manoj
-- 
It takes all kinds to fill the freeways. Crazy Charlie
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]

Is menu orphaned? (Was: Debian Menu transition status)

[Andreas Tille]

Hi,

well, waiting more than five weeks for an answer to a question
that at least I would regard as urgent seems to show enough
patience.  The only conclulsion I could draw is that menu is
not really maintained any more.  I'm particularly interested
in this question because if this is the case I see no need
to continue supporting menu in cdd-dev / cdd-common tools.
Instead we would switch to freedesktop.org exclusively which
would be a shame because we would lose several window managers
that do not support this format - but it makes no sense to
support stuff which is not documented and requests for
documentation remain unanswered.

Bill, I just noticed that I forgot to CC you in my previous
mail which might lead to the fact that you missed my question
because you are not reading debian-devel.  While this is
my fault I would suggest you should watch possible responses
of your announcements in the archive.

Kind regards

 Andreas.

On Sat, 20 Oct 2007, Andreas Tille wrote:


On Tue, 9 Oct 2007, Bill Allombert wrote:


Others changes:
===

-- Menu support a new format called "menu-2" since 8 years.


Uhmmm, this is one of the strangest sentences I read on this list this
year.  At which time scale you would regard eight years old as new (at
least in the world of computers)?  I would rather pronounce:

 The menu format that is currently used by nearly every package
 was obsolated by the menu-2 format two years ago because the
 information about was so perfectly hidden that nobody really
 noticed.

I base my assumption that nobody really noticed on the fact that

   grep "menu-2" /usr/share/menu/*

revealed no result on my machine.


In this
format lines break are not significant, but logical lines end by a
semi-comma:

This is an example:

!C menu-2
?package(pari-gp):
 section="Applications/Science/Mathematics"
 needs="text"
 title="PARI/GP"
 command="gp"
;

I do not have strong opinion about this format, but feel free to use it.


Well, the strongest prove that you are not alone is that neither
debian-policy mentions it (see #447389), nor dh-make creates menu-2
templates (see #447390) nor lintian suggests this format (see #447391).
But how should we interpret the sentence below:


Since even potato support menu-2, there are no upgrade or backport
issue, however this might break the lintian code to parse menu file.

menu-2 is also available for menu-methods, through the definition
compat="menu-2". I highly recommend its use for menu-methods.


So you highly recommend something you have no feelings about?
What is the sense of inventing a format and not providing any
information about it.  Even grepping through /usr/share/doc/menu/html
revealed only some notes amout menu-2 but no code example locked
like above.  The manual claims to describe menu format menu-2
but considering that the code uses backspace '\' which should be
necessary according to the information above and given that the
line "!C menu-2" is mandatory as well as the final semicolon
in contrast to the statement of /usr/share/doc/menu/html/ch1.html
that this document describes the menu-2.0 format this is just
not the case (and I should probably a file against the menu
package about this).

So how could you expect developers to adopt a new format if there
is no information about it?


Imagine a large red swirl here.


I have to admit that my brain turned in a multi colored huge
swirl when I finaly was pointed to this information which was
hidden in the very end of a long mail that was posted to
debian-devel-announce (but got archived on debian-devel strangely
enough).

After settling down with this I wonder whether you could easily
turn a menu-1 format file into a menu-2 format file by just
wrapping it i between

  !C menu-2
  
  ;

or is there some other magic?

Kind regards

Andreas.


--
http://fam-tille.de


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





--
http://fam-tille.de


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

Re: Parallel build results

[Jörg Sommer]

Hello,

Marco d'Itri <[EMAIL PROTECTED]> wrote:
> On Dec 02, Daniel Schepler <[EMAIL PROTECTED]> wrote:
>
>> I finally got through the test builds of all the source packages in sid for 
>> i386 using dpkg-buildpackage -j3 on a dual core machine.  The results as 
>> before are at http://people.debian.org/~schepler/build-logs/bymaint.html .  
>
> Can you explain the meaning of this failure and how it should be fixed?
>
> make[2]: warning: jobserver unavailable: using -j1.  Add `+' to parent make 
> rule.

Quoting from http://lists.samba.org/archive/distcc/2004q1/002160.html

There are (at least?) three reasons why this might be so:

  1) The parent make didn't realize that the child process it was
 invoking was actually a "make" program.  In this case, it won't
 allow the child to connect to the jobserver.  This is typically
 because the command to invoke the child uses "make" or similar
 rather than the correct $(MAKE).  See the docs on the "+" token to
 understand the algorithm GNU make uses to determine if the child is
 a sub-make or not.

Bye, Jörg.
-- 
Wenn du nur einen Hammer hast, sieht jedes Problem aus wie ein Nagel.


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

Re: Is menu orphaned? (Was: Debian Menu transition status)

[Bill Allombert]

On Mon, Dec 03, 2007 at 10:24:42PM +0100, Andreas Tille wrote:
> Hi,
> 
> well, waiting more than five weeks for an answer to a question
> that at least I would regard as urgent seems to show enough
> patience.  The only conclulsion I could draw is that menu is
> not really maintained any more.  I'm particularly interested
> in this question because if this is the case I see no need
> to continue supporting menu in cdd-dev / cdd-common tools.
> Instead we would switch to freedesktop.org exclusively which
> would be a shame because we would lose several window managers
> that do not support this format - but it makes no sense to
> support stuff which is not documented and requests for
> documentation remain unanswered.

It is not the only conclusion you could draw.

> Bill, I just noticed that I forgot to CC you in my previous
> mail which might lead to the fact that you missed my question
> because you are not reading debian-devel.  While this is
> my fault I would suggest you should watch possible responses
> of your announcements in the archive.

Indeed another conclusion you just drawn was that I never actually
received your email. I am not subscribed to debian-devel, and I 
did not post to that list. Instead I posted to debian-devel-announce.
My email ended in debian-devel for reasons I did not anticipate.
I will resend it to debian-devel-announce.

Generally, if you want to reach me, please email me directly.

On the other hand, I am currently lacking a menu developer with a good 
understanding of C++, which delays the resolution of some bugs, but if
you just want to help me with menu QA, you are welcome too.

> >On Tue, 9 Oct 2007, Bill Allombert wrote:
> >
> >>Others changes:
> >>===
> >>
> >>-- Menu support a new format called "menu-2" since 8 years.
> >
> >Uhmmm, this is one of the strangest sentences I read on this list this
> >year.  At which time scale you would regard eight years old as new (at
> >least in the world of computers)?  I would rather pronounce:
> >
> > The menu format that is currently used by nearly every package
> > was obsolated by the menu-2 format two years ago because the
> > information about was so perfectly hidden that nobody really
> > noticed.

menu-1 format is not obsoleted. I was not the menu maintainer 8 years
ago (I was not even a Debian developer). Whatever plans Joost had
for the menu-2 format, I don't know. Until recently I thought the
menu-2 format only applied to menu-methods, but I discovered I was
wrong, so I decided to announce it.

> >I base my assumption that nobody really noticed on the fact that
> >
> >   grep "menu-2" /usr/share/menu/*
> >
> >revealed no result on my machine.

There must be a first time for everything. But try

grep "menu-2" /etc/menu-methods/*

> >>In this
> >>format lines break are not significant, but logical lines end by a
> >>semi-comma:
> >>
> >>This is an example:
> >>
> >>!C menu-2
> >>?package(pari-gp):
> >> section="Applications/Science/Mathematics"
> >> needs="text"
> >> title="PARI/GP"
> >> command="gp"
> >>;
> >>
> >>I do not have strong opinion about this format, but feel free to use it.
> >
> >Well, the strongest prove that you are not alone is that neither
> >debian-policy mentions it (see #447389), nor dh-make creates menu-2
> >templates (see #447390) nor lintian suggests this format (see #447391).
> >But how should we interpret the sentence below:

I don't see how it is relevant to debian-policy or dh-make.

> >>Since even potato support menu-2, there are no upgrade or backport
> >>issue, however this might break the lintian code to parse menu file.
> >>
> >>menu-2 is also available for menu-methods, through the definition
> >>compat="menu-2". I highly recommend its use for menu-methods.
> >
> >So you highly recommend something you have no feelings about?

I have no feeling about using menu-2 for menu file, but I recommend
it for menu-methods.

> >What is the sense of inventing a format and not providing any
> >information about it.  Even grepping through /usr/share/doc/menu/html
> >revealed only some notes amout menu-2 but no code example locked
> >like above.  The manual claims to describe menu format menu-2
> >but considering that the code uses backspace '\' which should be
> >necessary according to the information above and given that the
> >line "!C menu-2" is mandatory as well as the final semicolon
> >in contrast to the statement of /usr/share/doc/menu/html/ch1.html
> >that this document describes the menu-2.0 format this is just
> >not the case (and I should probably a file against the menu
> >package about this).

Thanks for explaining to this list all the trouble I had to 
get through before discovering menu-2.

> >So how could you expect developers to adopt a new format if there
> >is no information about it?

By posting to debian-devel-announce.

> >>Imagine a large red swirl here.
> >
> >I have to admit that my brain turned in a multi colored huge
> >swirl when I finaly was pointed to this info

Re: Is menu orphaned? (Was: Debian Menu transition status)

[Andreas Tille]

On Mon, 3 Dec 2007, Bill Allombert wrote:


Indeed another conclusion you just drawn was that I never actually
received your email. I am not subscribed to debian-devel, and I
did not post to that list. Instead I posted to debian-devel-announce.
My email ended in debian-devel for reasons I did not anticipate.
I will resend it to debian-devel-announce.


Well, my understanding of debian-devel-announce is that it is
for important announcements and debian-devel is for discussing
thise announcements.  That's why I suggested that somebody should
read possible replies to his announcements (even if I admit that
a CC in this special case would have been reasonable).


Generally, if you want to reach me, please email me directly.


Lesson learned. ;-)


On the other hand, I am currently lacking a menu developer with a good
understanding of C++, which delays the resolution of some bugs, but if
you just want to help me with menu QA, you are welcome too.


I had a look into menu code but realised that my poor C++ knowledge
is probably not enough.


The menu format that is currently used by nearly every package
was obsolated by the menu-2 format two years ago because the
information about was so perfectly hidden that nobody really
noticed.


menu-1 format is not obsoleted.


Well, I admit I'm failing to find the quote - I probably imagined
to have read it was obsoleted.


There must be a first time for everything. But try


Yes, this is right.


grep "menu-2" /etc/menu-methods/*


My problem is that after 8 years the first menu file that is
actually using it broke a script in cdd-common and I have no
idea how to fix this because there is no description of this
format.


I don't see how it is relevant to debian-policy or dh-make.


You don't want to tell me that #447389 and #447390 make no
sense.


I have no feeling about using menu-2 for menu file, but I recommend
it for menu-methods.


But why?


Thanks for explaining to this list all the trouble I had to
get through before discovering menu-2.


??
I don't understand this statement?


So how could you expect developers to adopt a new format if there
is no information about it?


By posting to debian-devel-announce.


After 8 years and without drawing the consequences to file the
apropriate bug reports especially #447391?  This sounds not very
convincing.


Apparently one is not allowed to post a followup to a previous
debian-devel-announce post, even if it is two month old. I did
not anticipated that.


Well, my first posting had a delay of eleven days and both are
listed at

   http://lists.debian.org/debian-devel/2007/10/threads.html

in the very same thread.  (BTW, I'm keen on the explanation why
your original posting does not show up in debian-devel-announce
archive but in debian-devel exclusively.)


Assuming your menu-1 file has a single entry, this is sufficient.
(Else you obviously need one ';' for each entry).


Well, to come to a productive suggestion: If menu-2 just adds
some syntax sugar that makes no real advantage - could we just
drop this new and unknown format?  Would this have any bad
consequences (except of rewriting some menu methods)?

Kind regards

 Andreas.

--
http://fam-tille.de


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

Re: Is menu orphaned? (Was: Debian Menu transition status)

[Bill Allombert]

On Mon, Dec 03, 2007 at 11:51:25PM +0100, Andreas Tille wrote:
> My problem is that after 8 years the first menu file that is
> actually using it broke a script in cdd-common and I have no
> idea how to fix this because there is no description of this
> format.
> 
> >I don't see how it is relevant to debian-policy or dh-make.
> 
> You don't want to tell me that #447389 and #447390 make no
> sense.

The menu entry format is not documented in the menu policy, so this
discard #447389. Since menu-1 is not deprecated, #447390 is a wishlist.

> >I have no feeling about using menu-2 for menu file, but I recommend
> >it for menu-methods.
> 
> But why?

Because this make functions definitions in menu-methods much more readable.
menu-2 is used in menu-methods for 8 years or so.
menu entry files are much simpler. However some people do not like the
fact that line break are significant.

> >Thanks for explaining to this list all the trouble I had to
> >get through before discovering menu-2.
> 
> ??
> I don't understand this statement?

You explained that the documentation of menu-2 was sub-par. This is
exactly the reason I took five years before learning about menu-2. 
I inherited this feature from the original menu author (Joost).

> >>>So how could you expect developers to adopt a new format if there
> >>>is no information about it?
> >
> >By posting to debian-devel-announce.
> 
> After 8 years and without drawing the consequences to file the
> apropriate bug reports especially #447391?  This sounds not very
> convincing.

Why should lintian flag menu-1 as an error ? menu-1 menu file are
absolutly fine as far as I am concerned.

> >Assuming your menu-1 file has a single entry, this is sufficient.
> >(Else you obviously need one ';' for each entry).
> 
> Well, to come to a productive suggestion: If menu-2 just adds
> some syntax sugar that makes no real advantage - could we just
> drop this new and unknown format?  Would this have any bad
> consequences (except of rewriting some menu methods)?

If you want menu-2 dead, why asking dh_make to generate menu-2 file ?
Why asking lintian to report menu-1 file as error ? Strange...

Anyway, if you have some cdd scripts that are broken by menu-2, please
send them to me and I am sure we will fix them in a short time. 
Actually you can even use update-menus to convert from menu-2 to menu-1.

Cheers,
Bill.


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

ftp.debian.org removal bugs

[Joerg Jaspert]

Hi

as I just modified parts of my code generating the removals overview
page to deal with more kinds of broken bug titles for removal bugs, a
small mail about it:

Please use a bug title format of ($PACKAGE is the source package)
RM: $PACKAGE -- REASON
for a full removal request or
RM: $PACKAGE [$ARCHLIST] -- REASON 
for a partial removal. The arch list should be enclosed in [] and
separated by a space. If the removal is meant to be done in a suite
other than unstable add the suite to the package name, separated with
a / only.

REASON should start with one or more of the acronyms listed on [1] or [2],
whichever fits best, followed by a short but descriptive text explaining
why the package should be removed. That text should be self-contained,
ie. one should not need to read the body of the request to see why the
removal should be done, as this text will end up in the removal
logfile. (But of course the body can *and* *should* contain much more
details than this short subject).

Every package that should be removed has to have its own bug report.

An example would be "RM: foo -- RoQA: bar is better" for a full removal
or "RM: bar/experimental [i386 alpha] -- superseded by foo" for a
removal of bar from experimental, i386 and alpha binaries only.

If you want to remove an orphaned package - reassign the bug and retitle
it, do not file new bugs (someone would have to manually deal with the
O: bug).

Also - feel free to retitle every removal bug that does not follow
this format.

And, as a last thing, if you see removal bugs tagged with moreinfo -
feel free to handle them. Ie. look into them why they are moreinfo[3]
and do whatever is neccessary to make the package removable (or find out
that it cant/shouldnt be removed and close the bug). When thats done and
the package finally can be removed - remove the moreinfo tag to reflect
the state change. If you are a DD you can run "dak rm -nR PACKAGE" on
merkel to see if a reverse dependency (still) applies.


The above will help me a lot in processing removal bugs.


Ah, while Im at it: There are some kinds of removals where we do not
need a bug for, namely those detected by the cruft report script
(formerly called rene):

- NBS - Not Built from Source, aka you stopped building a binary package
  from your source package.
- NVIU - Never Version In Unstable, aka you have a package in
  experimental and uploaded a newer version to unstable.
- Obsolete Source Package - the source package does not have any binary
  package in the archive anymore. Possibly because they are moved into
  different source packages.


[1] http://ftp-master.debian.org/removals.html
[2] http://ftp-master.debian.org/removals.txt  (large, contains a log of
all removals ever done)
[3] usually because the package can't be removed yet due to a reverse
dependency

-- 
bye Joerg
Definition of Cabal:
 Those people, who, when they do something currently outside of
 the official rules for behavior [your choice here] 1) are
 exempted from censure, or 2) (more accurately) by their actions
 define a new set of rules for acceptable behavior in such 
context.


pgpmeIvCaHkvk.pgp
Description: PGP signature

Doc-base section hierarchy (was: Re: doc-base, menu, and policy (Re: Debian Policy 3.7.3.0 uploaded))

[Robert Luberda]

Stefano Zacchiroli writes:

Hi,


On Mon, Dec 03, 2007 at 05:24:06PM +0900, Charles Plessy wrote:

  
(http://www.debian.org/doc/packaging-manuals/menu-policy/ch2.html#s2.1).
  Required field.

>>
>> I am wondering if when a .doc-base file is not updated, it makes the

doc-base 0.8.7, I uploaded yesterday, already refers to the new 
hierarchy defined in menu package.



I found not reasonable that the doc-base hierarchy is bound to the menu
one. 


I fully agree. Even though the newest doc-base tries to map old sections 
into new ones while generating control files in 
/var/lib/doc-base/documents, I really think that the doc-base and the 
menu hierarchies should be separated, however I need some help with 
this. If you have some ideas, how the hierarchy should be changed, I'm 
looking forward to hearing them.



The problem was already reported[1] several years ago and discussed on 
debian-devel than[2]. From that discussion I most like the proposal from 
[3] to made the hierarchy similar to that one from menu package, but 
with the "Apps" prefix removed. I think we could start from this but 
update it for the current menu structure (i.e change "Database" into 
"Data Management", "Maths" into "Science/Mathematics", etc, but remove 
any "Apps" or "Applications" prefix). Than we could add some top-level 
sections to it like "Debian".



A month ago I gathered some data about doc-base files (see [4] and [5]). 
Based on that data I prepared some statistics about current doc-base 
sections and also some mapping ("Apps/Applications" prefix removed):


OLD SECTION (COUNT)POSSIBLE NEW SECTION
 Hamradio (2)=> Amateur Radio
 Databases (7)   => Data Management
 Database (1)=> Data Management
 Data Management (2) => Data Management
 Debian (103)=> Debian
 Debian/Installation (188)   => Debian/Installation
 Editors (28)=> Editors or Editing
 Education (1)   => Education
 Emulators (47)  => Emulators
 Games (8)   => Games
 Games/Arcade (11)   => Games/Action
 Games/Adventure (3) => Games/Adventure
 Games/Tetris-Like (2)   => Games/Blocks
 Games/Board (16)=> Games/Board
 Games/Board/Chess (2)   => Games/Board/Chess
 Games/Card (5)  => Games/Card
 Games/Educational (1)   => Games/Educational # not in menu hier.
 Games/Puzzles (8)   => Games/Puzzles
 Games/Simulation (2)=> Games/Simulation
 Games/Strategy (4)  => Games/Strategy
 Games/Toys (7)  => Games/Toys
 Graphics (76)   => Graphics
 Help (27)   => Help
 Manpages (1)=> Help
 Faq (8) => Help/FAQ   or FAQ
 Howto (4)   => Help/HOWTO or HOWTO
 Rfc (16)=> Help/RFC   or Standards/RFC or RFC
 Standards (1)   => Help   or Standards
 Net (112)   => Network
 Mail (16)   => Network/Communication # like in menu
 Contrib/Libs (1)=> Programming
 Development (4) => Programming
 Devel (77)  => Programming
 Libs (4)=> Programming or Programming/$language
 Non-Free/Devel (1)  => Programming
 Programming (704)   => Programming or Programming/$language
 Programming/Java (2)=> Programming/Java
 Lisp/Documentation (1)  => Programming/Lisp
 Lisp/Net (1)=> Programming/Lisp
 Python (2)  => Programming/Python
 Libdevel (5)=> Programming
 Science (75)=> Science
 Science/Biology (5) => Science/Biology
 Electronics (6) => Science/Electronics
 Math (110)  => Science/Mathematics
 Science/Medicine (1)=> Science/Medicine
 Technical (8)   => Science/Electronics  #like in menu
 Shells (7)  => Shells
 Audio (2)   => Sound
 Sound (41)  => Sound
 Music (5)   => Sound
 System (48) => System
 Admin (23)  => System/Administration
 System/Security (1) => System/Security
 Xshells (5) => Terminal Emulators
 Text (87)   => Text
 Utilities (1)   => Utilities or Tools
 Utils (9)   => Utilities or Tools
 Tools (100) => Utilities or Tools
 Viewers (3) => Viewers
 Windowmanagers (8)  => Window Managers
 Windowmanager (2)   => Window Managers
 X11/Window Managers (1) => Window Managers

Sections with no obvious mapping:
 1 (1)   =>
 Apps (2)  

Re: Parallel build results

[Anthony Towns]

On Mon, Dec 03, 2007 at 01:28:08PM +, Tim Cutts wrote:
> -BEGIN PGP SIGNED MESSAGE-
> On 3 Dec 2007, at 12:43 pm, Daniel Schepler wrote:
>> Control files of package am-utils: lines which differ (wdiff format)
>> 
>> Depends: libamu4 (= 6.1.5-7), portmap, {+libamu4,+} libc6 (>= 2.6.1-1),
>> libgdbm3, libhesiod0, libldap2 (>= 2.1.17-1), libwrap0, perl, debconf (>=
>> 1.2.0), ucf, debianutils (>= 1.6)
>> So the Depends line got changed in the parallel build.
> Sure, yes, I realise that one.  Don't know why it's happening though.

Isn't that just due to dpkg changes?

 (1.14.8) unstable; urgency=low
   [ Raphael Hertzog ]
   * Switch perl programs to use the new Dpkg::Deps module. This changes the
 behaviour of dpkg-gencontrol and dpkg-source which will rewrite and
 simplify dependencies and build dependencies as possible. Multiple
 dependencies on the same package are replaced by their intersection.
 Closes: #178203, #186809, #222652

At the moment, dpkg 1.14.7 is in testing, dpkg 1.14.12 in unstable.

Cheers,
aj



signature.asc
Description: Digital signature

Should download managers offer some virtual package?

[Luis Rodrigo Gallardo Cruz]

It's been brought to my attention that liferea, while being able to
use wget, curl, gwget and kget to download feed attachments, does not
Recommend or Suggest any of them, or their alternatives.

Since I'd rather not maintain a long list of possible file
downloaders, I tried but failed to find some virtual package I could
Recommend for that functionality. Thus, this query: Would it be
reasonable for such packages to provide one? What would be the propper
name?


signature.asc
Description: Digital signature

Re: Is menu orphaned? (Was: Debian Menu transition status)

[Andreas Tille]

On Tue, 4 Dec 2007, Bill Allombert wrote:


The menu entry format is not documented in the menu policy, so this
discard #447389.


Well, you are right that policy should not _describe_ the menu format,
but policy should definitely _mention_ that there are at least two formats
and should give an _advise_ which to use.  I tend to reopen the bug
(depending from the outcome of this discussion).


Since menu-1 is not deprecated, #447390 is a wishlist.


If menu-1 is not deprecated then lintian should only issue an info.
Please don't blame me for drawing wrong conclusions from perfectly
lacking information.  There was an announcement of a new format and
I tend to assume that a new thing replaces the old one and we should
start informing people about this fact.


I have no feeling about using menu-2 for menu file, but I recommend
it for menu-methods.


But why?


Because this make functions definitions in menu-methods much more readable.
menu-2 is used in menu-methods for 8 years or so.
menu entry files are much simpler. However some people do not like the
fact that line break are significant.


So don't you think that this fact should be written down anywhere?
I can not cope with statements "have no feeling about using menu-2".
If we want a consistent menu system we should give maintainers clear
guidelines.


You explained that the documentation of menu-2 was sub-par. This is
exactly the reason I took five years before learning about menu-2.
I inherited this feature from the original menu author (Joost).


It was not my intention to blame you for the menu-2 issues.  I'm just
missing a clear strategy and because I think that menu has some very
interesting features we should be precise in describing what maintainers
are expected to do.  There are a lot of maintainers who think menu
is a dead horse they should stop riding and switch to freedesktop.org.
If there is no clear strategy written down I can not blame them wrong.


After 8 years and without drawing the consequences to file the
apropriate bug reports especially #447391?  This sounds not very
convincing.


Why should lintian flag menu-1 as an error ? menu-1 menu file are
absolutly fine as far as I am concerned.


Well, the bug report does not say it should mark menu-1 as error.
It says "check for" and if _I_ would be the menu maintainer I would
try to settle dwon with one format.  But if you "have no feelings"
and the difference is just a ';' or a line break we should simply
stick to the "most widely used" and drop the other one.


If you want menu-2 dead, why asking dh_make to generate menu-2 file ?
Why asking lintian to report menu-1 file as error ? Strange...


It becomes strange if you are ignoring that my suggestions are from
different times and there was some gain of information in between.
I admitted to be confused by missing information but I'm not confused
enough to suggest two contradicting things at the same time (hopefully).

 1. I want to be menu-2 dead if menu-1 obviousely is not.
 2. I want to have one single menu format if there is no strong
reason to support more than one (feelings are no reasons).
 3. I want dh_make to generate files of the _suggested_ format.
(Your announcement sounded kind of a suggestion for menu-2
and thus I felt my bug report would be reasonable.)
 4. I want lintian report (just report, not as an error) that
something else than the suggested format is used.


Anyway, if you have some cdd scripts that are broken by menu-2, please
send them to me and I am sure we will fix them in a short time.


Well, I'm sure that /usr/share/menu/cdd-menu (from cdd-common) can be
fixed to cope with /usr/share/menu/amide (from amide) to create a valid
menu.  The problem is that I'm missing a clear strategy in which way it
should be fixed.  There are several possibilities.  The cdd-menu scripts
concatenates single menu entries to build a user menu.  The concatenation
only works if the input files have the same format.

  Strategy   I: Use menu-1 for single menu entries.
   --> Fix: Ask Amide maintainer to switch to menu-1.  (very simple)

  Strategy  II: Usage of menu-2 is recommended.
   --> Fix: cdd-menu converts every menu-1 entry to menu 2 and
output a menu-2 formated list of menu entries.

  Strategy III: Menu-2 entries are an exception.
   --> Fix: cdd-menu converts every menu-2 entry to menu-1 and
output a menu-1 formated list of menu entries.

It is basically not about writing some code (even if I'd be happy to
accept patches of course ;-)) but knowing which code makes most sense.


Actually you can even use update-menus to convert from menu-2 to menu-1.


I doubt that this will work in the cdd-menu case because it just
generates the input for update-menus - but perhaps I missed something.

Another issue is that people think about generating Debian menu entries
from desktop files.  This also would require a clear strategy because
I think it is reasonable to do this conve

Re: Is menu orphaned?

[Russ Allbery]

Andreas Tille <[EMAIL PROTECTED]> writes:
> On Tue, 4 Dec 2007, Bill Allombert wrote:

>> The menu entry format is not documented in the menu policy, so this
>> discard #447389.

> Well, you are right that policy should not _describe_ the menu format,
> but policy should definitely _mention_ that there are at least two formats
> and should give an _advise_ which to use.  I tend to reopen the bug
> (depending from the outcome of this discussion).

Why?  Policy doesn't say anything at all about the format of menu files
now, so unless you're proposing adding something about the format to
Policy, it doesn't make any sense to say this there.  And I don't see what
would be gained by adding that to Policy.

> Please don't blame me for drawing wrong conclusions from perfectly
> lacking information.  There was an announcement of a new format and
> I tend to assume that a new thing replaces the old one and we should
> start informing people about this fact.

And you've now been told that you drew conclusions that weren't intended.

>  2. I want to have one single menu format if there is no strong
> reason to support more than one (feelings are no reasons).

This seems to be the real point of disagreement.  Currently there isn't
any recommended format; people can use whichever one they choose.  I think
that's the core of what you're disagreeing with.

Personally, that doesn't bother me, but if you build a consensus around
the idea that there should only be one format, I'm happy to go along with
that consensus.

>  3. I want dh_make to generate files of the _suggested_ format.
> (Your announcement sounded kind of a suggestion for menu-2
> and thus I felt my bug report would be reasonable.)
>  4. I want lintian report (just report, not as an error) that
> something else than the suggested format is used.

The bug report asking for 4 is hence premature until 2 has been decided.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Is menu orphaned?

[Andreas Tille]

[Full quote because Bill was not in your CC list.]

On Mon, 3 Dec 2007, Russ Allbery wrote:


Andreas Tille <[EMAIL PROTECTED]> writes:

On Tue, 4 Dec 2007, Bill Allombert wrote:



The menu entry format is not documented in the menu policy, so this
discard #447389.



Well, you are right that policy should not _describe_ the menu format,
but policy should definitely _mention_ that there are at least two formats
and should give an _advise_ which to use.  I tend to reopen the bug
(depending from the outcome of this discussion).


Why?  Policy doesn't say anything at all about the format of menu files
now, so unless you're proposing adding something about the format to
Policy, it doesn't make any sense to say this there.  And I don't see what
would be gained by adding that to Policy.


Please don't blame me for drawing wrong conclusions from perfectly
lacking information.  There was an announcement of a new format and
I tend to assume that a new thing replaces the old one and we should
start informing people about this fact.


And you've now been told that you drew conclusions that weren't intended.


 2. I want to have one single menu format if there is no strong
reason to support more than one (feelings are no reasons).


This seems to be the real point of disagreement.  Currently there isn't
any recommended format; people can use whichever one they choose.  I think
that's the core of what you're disagreeing with.


Yes.


Personally, that doesn't bother me, but if you build a consensus around
the idea that there should only be one format, I'm happy to go along with
that consensus.


Fine.


 3. I want dh_make to generate files of the _suggested_ format.
(Your announcement sounded kind of a suggestion for menu-2
and thus I felt my bug report would be reasonable.)
 4. I want lintian report (just report, not as an error) that
something else than the suggested format is used.


The bug report asking for 4 is hence premature until 2 has been decided.


Obviousely.

Kind regards

   Andreas.

--
http://fam-tille.de


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