Re: Installation of Recommends by default on October 1st

[Neil Williams]

On Fri, 3 Aug 2007 00:30:44 +0200
Michael Vogt <[EMAIL PROTECTED]> wrote:
> 
> The current recommends situaton is bad, but as I see it we have two 
> options:
> a) change policy and say recommends should really be suggests
> b) fix apt and go through the transition pain

c) mass bug filing without changing apt. (It's the right list for that,
at least.)

The hardest part of this is that the decision about just what goes into
Recommends isn't something that can be easily tested by automated
scripts, lintian etc. Forcing the situation by changing apt to expose
the idiocies of the current Recommends list does seem to be a
heavy-handed way to do it.

However, I seem to be in danger of being labelled a "stick-in-the-mud"
or "resistant" to change which is completely untrue. I just don't like
this particular change. Lacking the time to do this some other way
myself due to contributions elsewhere in Debian/Emdebian, it will just
be one of those things where I disagree with a default.

As far as Emdebian is concerned, yes, it is just a change in our
cross-built apt package to make Emdebian into one of those
unusual installations where Recommends does not apply. Hopefully, in
time, I'll work out a collection of these patches where Emdebian needs
to change a low-level Debian default and create a way to still carry
these upstream within wrappers that are only enabled by an emdebian /
cross build, possibly along the lines of how gcc works with DEB_CROSS.
This is just one more for that list.

> Letting the current situation drag on forever is not really a solution
> IMHO. And we have time to fix the reommends chain and to fix the tools
> to better distinguish between real depends and recommends (that is not
> ideal currently).
> 
> In summary I think that depends will not become another form of
> depends and people will forget about them. Just the oposite, it will
> be a benefit especially for the powerusers. Regular users will just
> ignore them.

Has that issue with gksu been filed as a bug report?

I'm as guilty as anyone else about griping without always filing a
bug report but I would like to see more bug reports that move Depends
-> Recommends as well as making Recommends itself logically consistent.

> I understand that a lot of people are  not happy about a change like
> this, but I think recommends-cleanup and improving our tools should
> really make debian better and there is still time to work on the
> remaining issues :) 

I agree with fixing Recommends, I just wish it didn't have to involve
forcing people to get around to fixing it by changing apt.

> I guess my initial mail should have included much
> more details and examples to explain the rational better.

It was the fait-accompli manner of the announcement that worried me
most and I was on VAC during the previous discussions on this list. If
it had maybe started with:

After previous discussion on debian-devel , we the APT team *want
to* bring the current behaviour in experimental into unstable here
are some of the reasons and possible problems ... we expect to make this
change on  
 rather than (how it came across)
We the APT team will force this change and this is simply notification
that you've got 56 days to comply and by the way, here's how to hack
all your systems to retain the current method.

It would have reduced the feelings of panic and alarm at this end!
:-)

If the announcement also mentioned some existing problems with
Recommends (with bug reports), it would have been *so* much easier.

-- 

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


pgpdJvIhFUi9s.pgp
Description: PGP signature

Re: Packaging a difficult project

[Thomas Jollans]

On Saturday 04 August 2007, Brendon Costa wrote:
> EDoc++ binaries are currently around 20M. It does not require any
> special binutils etc, but will just use what is already available for
> the system. I am currently building a single non-policy conformant .deb
> package.

I think the concern is more about the edoc source, which would apparently 
include gcc source, which is large and already on the mirrors multiple times.


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

Re: Packaging a difficult project

[Brendon Costa]

Thomas Jollans wrote:
> On Saturday 04 August 2007, Brendon Costa wrote:
>> EDoc++ binaries are currently around 20M. It does not require any
>> special binutils etc, but will just use what is already available for
>> the system. I am currently building a single non-policy conformant .deb
>> package.
> 
> I think the concern is more about the edoc source, which would apparently 
> include gcc source, which is large and already on the mirrors multiple times.
> 

The tarball of all source necessary to build EDoc++ is 25M and extracted
 it is: 47M.

EDoc++ stores in its source tree patches against GCC along with the GCC
original tarballs, and at build time will extract the gcc tarballs into
the build directory and apply the patches before building it. This means
the builddir can be quite large, but all files in it are "derived" from
the ones in the source directory and can be deleted between builds
without any re-percussions.

I am not sure where the 1G comes from, unless talking about the
duplicity across various mirrors. I do admit however that there is an
unfortunate problem that various projects may require GCC sources (Cross
compilers are not an exception). This is unfortunate, however from what
i understand it is unavoidable. If there is a way to avoid it I would be
interested in looking at pursuing that option if it will help.

Thanks,
Brendon.





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

Re: Packaging a difficult project

[Steve Langasek]

On Sat, Aug 04, 2007 at 07:49:56PM +1000, Brendon Costa wrote:
> The tarball of all source necessary to build EDoc++ is 25M and extracted
>  it is: 47M.

> EDoc++ stores in its source tree patches against GCC along with the GCC
> original tarballs, and at build time will extract the gcc tarballs into
> the build directory and apply the patches before building it. This means
> the builddir can be quite large, but all files in it are "derived" from
> the ones in the source directory and can be deleted between builds
> without any re-percussions.

> I am not sure where the 1G comes from, unless talking about the
> duplicity across various mirrors.

No, this is an estimate based on the actual usage of pool/main/g/gcc-4.1 on
current Debian mirrors.  (12 archs * 3 versions * n binary packages)

Your note on the size of the edoc binary package would give a smaller total
than 1G, but AFAICS it would still be a rather large, rather niche package.

-- 
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: Bug#435884: ITP: rsyslog -- enhanced multi-threaded syslogd

[Bastian Blank]

On Sat, Aug 04, 2007 at 01:44:14AM -0400, Roberto C. Sánchez wrote:
> As the "target" user for this sort of package is a sysadmin type, I
> would saw it is an important enough detail that it should be in the
> short description.

But only in the relation: multi-threaded == bad. You need much more
knowledge to handle concurrency correctly.

Bastian

-- 
Worlds are conquered, galaxies destroyed -- but a woman is always a woman.
-- Kirk, "The Conscience of the King", stardate 2818.9


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

Re: Packaging a difficult project

[Brendon Costa]

Steve Langasek wrote:
>> I am not sure where the 1G comes from, unless talking about the
>> duplicity across various mirrors.
> 
> No, this is an estimate based on the actual usage of pool/main/g/gcc-4.1 on
> current Debian mirrors.  (12 archs * 3 versions * n binary packages)
> 
> Your note on the size of the edoc binary package would give a smaller total
> than 1G, but AFAICS it would still be a rather large, rather niche package.
> 
Yes that is true.



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

.deb issue

[JM Barrios]

Hello:

I am developing a .deb package an all goes well but I have problems putting
it in the Applications menu of Gnome. I have modified the debian/menu.ex
file with this content:

?package(lkmonitor):needs="x11″ section="Apps/System" \
title="Linux Kernel Monitor" command="/usr/bin/lkmonitor" \
icon="/usr/share/pixmaps/lkmonitor/spider-shadow16.png"


then I renamed the file from menu.ex to menu. I have modified
debian/postinst.ex file adding this lines:

set -e
if [ "$1″ = "configure" ] && [ -x /usr/bin/update-menus ]; then update-menus
; fi

and debian/postrm.ex file adding this lines:

set -e
if [ "$1″ = "configure" ] && [ -x /usr/bin/update-menus ]; then update-menus
; fi

I have renamed both files from postinst.ex and postrm.ex to postinst and
postrm. The package is built well and it works but it only appear in the
gnome menu as the attached file shows and without icon. Also, it shows the
application version is "Lkmonitor Version 0.1" as you can see and I want it
shows "lkmonitor version 0.3 alpha"

Thanks for reading my email

JM Barrios

Re: .deb issue

[Pierre Habouzit]

On Sat, Aug 04, 2007 at 12:57:39PM +0200, JM Barrios wrote:
> Hello:
> 
> I am developing a .deb package an all goes well but I have problems putting
> it in the Applications menu of Gnome. I have modified the debian/menu.ex
> file with this content:
> 
> ?package(lkmonitor):needs="x11″ section="Apps/System" \
> title="Linux Kernel Monitor" command="/usr/bin/lkmonitor" \
> icon="/usr/share/pixmaps/lkmonitor/spider-shadow16.png"
> 
> 
> then I renamed the file from menu.ex to menu. I have modified
> debian/postinst.ex file adding this lines:

  Use dh_installmenu that would take care of that. Also I'd say that
debian-mentors is a better list for this kind of questions. Cheers,

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgp5gkTuJfjeK.pgp
Description: PGP signature

Re: /bin/sh diversions

[Marco d'Itri]

On Aug 03, Thorsten Glaser <[EMAIL PROTECTED]> wrote:

> Give the user the tools to shoot himself into the foot. Besides, dash
> is already using the debconf dance, so why discriminate other shells
> that are fine to do it according to policy?
To reduce complexity. Complexity is bad.

> >bash (the standard
> Which standard? It's not even POSIX conformant because of its extensions.
Linux de facto standard.

> Most operating systems don't come with GNU bash either.
All Linux versions do.

> >which works with everything
> 
> set -A foo
> find . -name \*mp3 |&
> while read name; do foo[${#foo[*]}]=$name; done
> mpg123 -z "[EMAIL PROTECTED]"
> 
> I see two things in this (here splitted) one-liner I use often that don't
> work with bash, which is expected, as they are features of the Korn shell.
bash is not supposed to be a Korn shell replacement. Non sequitur.

> Please don't just say GNU/Linux/ELF/ILP32/i386 is everything; open minds.
It's everything that matters for the purpose of this discussion.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Thoughts about bts reassign

[Vincent Fourmond]

  Hello all,

  I've recently came up with some problems with the way reassign is
currently used: I filed a bug against Qt4 that had (serious) problems on
HPPA, making several packages FTBS (#435832). It turned out, as I should
have guessed, that this problems had already been reported in bug
#433768, but had turned out to be a kernel bug. Of course, when I
reported the bug to Qt4, I checked the open bug list for Qt4, but I
didn't bother to check for bugs in Qt4's dependencies and kernel and
dpkg and build-essentials and... what else ? I would be very surprised
if anyone did, actually (and I wouldn't have found the problem, as it
was retitled, with no hint of Qt4 left in the title).

  The outcome was that I lost time filing the bug report, and one of
Qt4's maintainer lost time answering. And it's not the first time. So
here is what I propose:

  When a bug filed against a package turns out to be a bug in one of the
dependencies (including implicit ones, such as the kernel and so on...),
instead of simply reassigning the bug to the faulty package, which makes
it disappear from the one that *appears* to be faulty, one should first
clone it, then reassign, and mark the original one as blocked by the
reassigned bug, something like:

clone 12345 -1
reassign -1 foo
block 12345 by -1

 This way, the bug stays open for anyone to see it, and it is linked to
the appropriate discussions in the appropriate package (nice links in
the BTS).

  What do you think about that ? This is just few more lines to
[EMAIL PROTECTED]

  Cheers,

Vincent

-- 
Vincent Fourmond, Debian Developer
http://vincent.fourmond.neuf.fr/
-- pretty boring signature, isn't it ?


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

Re: .deb issue

[JM Barrios]

Thanks for answering me Pierre. I have read the hd_installmenu manpage and I
have applied it typing only dh_installmenu -v. The output of this command
was this:

install -p -m644 debian/menu
debian/lkmonitor/usr/share/menu/lkmonitor
echo "# Automatically added by dh_installmenu">>
debian/lkmonitor.postinst.debhelper
sed "" /usr/share/debhelper/autoscripts/postinst-menu >>
debian/lkmonitor.postinst.debhelper
echo '# End automatically added section' >>
debian/lkmonitor.postinst.debhelper
echo "# Automatically added by dh_installmenu">>
debian/lkmonitor.postrm.debhelper
sed "" /usr/share/debhelper/autoscripts/postrm-menu >>
debian/lkmonitor.postrm.debhelper
echo '# End automatically added section' >>
debian/lkmonitor.postrm.debhelper

so, I tried to do a dpkg-buildpackage -rfakeroot another time and when the
process had finished I installed the .deb package but all goes in the same
way about the menus. I am going to post it in debian-mentors as you
suggested me, but if you or somebody here can tell me something more about
my problem I will be grateful because I have not found a lot of
documentation to fix my specific problem.

Thanks another time.

JM Barrios


On 8/4/07, Pierre Habouzit <[EMAIL PROTECTED]> wrote:
>
> On Sat, Aug 04, 2007 at 12:57:39PM +0200, JM Barrios wrote:
> > Hello:
> >
> > I am developing a .deb package an all goes well but I have problems
> putting
> > it in the Applications menu of Gnome. I have modified the debian/menu.ex
> > file with this content:
> >
> > ?package(lkmonitor):needs="x11″ section="Apps/System" \
> > title="Linux Kernel Monitor" command="/usr/bin/lkmonitor" \
> > icon="/usr/share/pixmaps/lkmonitor/spider-shadow16.png"
> >
> >
> > then I renamed the file from menu.ex to menu. I have modified
> > debian/postinst.ex file adding this lines:
>
>   Use dh_installmenu that would take care of that. Also I'd say that
> debian-mentors is a better list for this kind of questions. Cheers,
>
> --
> ・O・  Pierre Habouzit
> ・・O[EMAIL PROTECTED]
> OOOhttp://www.madism.org
>
>

Bug#435969: ITP: pidgin-musictracker -- Plugin for Pidgin which displays the current music track in your st

[Craig Small]

Package: wnpp
Severity: wishlist
Owner: Craig Small <[EMAIL PROTECTED]>

* Package name: pidgin-musictracker
  Version : 0.4.1
  Upstream Author : Arijit De <[EMAIL PROTECTED]>
* URL : http://code.google.com/p/musictracker/
* License : GPL
  Programming Lang: C
  Description : Plugin for Pidgin which displays the current music track in 
your status

 MusicTracker is a plugin for Pidgin (previously known as Gaim) which
displays
 the music track currently playing in the status message of various
accounts
 such as AIM, Yahoo, MSN, Gtalk (Jabber), etc., i.e. any protocol Pidgin
 supports custom statuses on.
 
 Features
  * Currently supported players: Amarok, Rhythmbox, Audacious, XMMS,
  * MPC/MPD, 
 Exaile, Banshee, Quod Libet on Linux.
  * Allows you to customize the status string with various fields
  * extracted 
  from your media player such as artist, album, track, duration,
progress bar, 
  etc.
  * Works around Pidgin's lack of support for MSN status messages by
  * using 
  the nickname instead.
  * Different status messages for various media player states such as 
  Playing, Paused and Stopped.
  * Supports per-account status format customization.
  * Optional Profanity filter for words in the status. 


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

Kernel: Linux 2.6.21-2-k7 (SMP w/1 CPU core)
Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash


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

Symbol-based dependencies on shared libraries: some news

[Raphael Hertzog]

Hello,

I'd like to give some news on my work. I've been working with the dpkg
team to prepare the integration of the new dpkg-shlibdeps... and during
that process we decided that a decentralized VCS like git would suit
better the need of the team (in particular so that Ian Jackson can more
easily maintain his Ubuntu branch, and merge changes in both directions).
So I've been distracted by the work of creating that git repository
because we integrated as much history as possible (the SVN repo had no
previous history). This is now over:
http://git.debian.org/?p=dpkg/dpkg.git;a=summary

My work is now maintained in the "dpkg-shlibdeps-buxy" branch in the
official git repository:
http://git.debian.org/?p=dpkg/dpkg.git;a=shortlog;h=dpkg-shlibdeps-buxy

We used that merge opportunity to start some clean modularization of the
perl code, Frank also created a first test suite to avoid regressions.
I updated the manual page for dpkg-shlibdeps and wrote a new one for
dpkg-gensymbols. The dpkg-gensymbols command now scans only public library
paths instead of scanning everything.

To fetch the code, please do (with git 1.5.x):
$ git clone git://git.debian.org/git/dpkg/dpkg.git
$ cd dpkg
$ git checkout --track -b dpkg-shlibdeps-buxy origin/dpkg-shlibdeps-buxy

You can build the package and install it to play with. You can integrate
dpkg-gensymbols calls in a debian/rules file, it will typically look like
this:
dpkg-gensymbols -plibcurl3 -Pdebian/libcurl3
dpkg-gensymbols -plibcurl3-gnutls -Pdebian/libcurl3-gnutls
(you should also create debian/.symbols file, see below
to grab some pre-generated files)

If you want dpkg-shlibdeps to generate smaller dependencies, you have
to provide some useful symbols file in /etc/dpkg/symbols/
(some up-to-date files here: 
http://users.alioth.debian.org/~hertzog/symbols.tar.bz2
they were generated by scanning successively etch/lenny/sid packages)

The only open issue that I'd like to investigate is how to best handle
differences between various architectures. Right now you have to provide
a single file for each architecture and in many cases, the files are very
similar except for some internal symbols.

For example compared to i386:
* hppa always add
  * _GLOBAL_OFFSET_TABLE_
  * __gmon_start__
* arm always add
  * __bss_start__
  * __data_start
  * _bss_end__
  * __end__
* powerpc
  * _restfpr_14 (and many similar)
  * _savefpr_14 (same)
* etc.

Most C libraries only have those kind of differences between the various
architectures. The glibc is a notable exception since the history of each
port is different and thus symbol versions are not synchronized between
architectures.

It looks like C++ generates much more difference (I don't know why,
possibily due to encoding of some type information in the symbol name).
Since the symbols are also much longer, the symbols file tend to get
quickly quite big.

Knowing those differences, I wonder if I should offer the possibility to have
debian/.symbols.common that would complement what can be found in
debian/.symbols. or if we need something more elaborated like
an include mechanism or a syntax to restrict a symbol on a set of architectures
(like for dependencies in Build-Depends). Please give me your opinion on this.

If you want to investigate further the differences between architectures, you
can get the full set of symbols files from yesterday on all
architectures here:
http://users.alioth.debian.org/~hertzog/symbols-all-archs.tar.bz2
(beware it's big: 123Mb)

You can also log in alioth and check ~hertzog/shlibdeps/{sid,reference}/*
(reference contains the symbols files generated by scanning successively
etch/lenny/sid, while sid contains files generated by scanning only the
last version of the packages)

Obviously, maintainers will have to decide if using symbols files is more
a benefit than a cost for their packages... packages with few reverse
dependencies written in C++ and exporting lots of symbols are likely
to not use symbol-based dependencies for the simple reason:
$ ls -s libopenvrml5c2a.symbols.i386
5016 libopenvrml5c2a.symbols.i386
$ gzip libopenvrml5c2a.symbols.i386
$ ls -s libopenvrml5c2a.symbols.i386.gz 
192 libopenvrml5c2a.symbols.i386.gz

The .deb file would be bigger of 192Kb but the Installed-Size of the
package would be 5Mb bigger for little gains...

For reference, the biggest symbol file is libgcj7-0.symbols.ia64 and is
10Mb big. On i386, out of 2405 symbols file:
- 33 packages have symbols file bigger than 1Mb 
- 310 packages have symbols file bigger than 100Kb
- 1514 packages have symbols file smaller than 20Kb

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

Re: Bug#435884: ITP: rsyslog -- enhanced multi-threaded syslogd

[Hamish Moffatt]

On Sat, Aug 04, 2007 at 12:24:58PM +0200, Bastian Blank wrote:
> On Sat, Aug 04, 2007 at 01:44:14AM -0400, Roberto C. Sánchez wrote:
> > As the "target" user for this sort of package is a sysadmin type, I
> > would saw it is an important enough detail that it should be in the
> > short description.
> 
> But only in the relation: multi-threaded == bad. You need much more
> knowledge to handle concurrency correctly.

Yes that's my reaction also.

System admins might regard multi-threaded as the key to high
performance. As programmers we consider it the key to increased
complexity and therefore more bugs.

Multi-threaded does allow you to use more than one CPU, but in the case
of syslogd ultimately the log file has to end up on disk anyway.

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


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

Re: Bug#435884: ITP: rsyslog -- enhanced multi-threaded syslogd

[Andreas Barth]

* Hamish Moffatt ([EMAIL PROTECTED]) [070804 16:22]:
> On Sat, Aug 04, 2007 at 12:24:58PM +0200, Bastian Blank wrote:
> > But only in the relation: multi-threaded == bad. You need much more
> > knowledge to handle concurrency correctly.
> 
> Yes that's my reaction also.
> 
> System admins might regard multi-threaded as the key to high
> performance. As programmers we consider it the key to increased
> complexity and therefore more bugs.

I'm quite optimistic we will soon know about the main bugs of rsyslog,
because Fedora is using that now as their main syslog server - so we can
happily package it now, view what happens on Fedora and use it. (And,
BTW, I was next to packaging rsyslog myself, but I decided I'm already
involved in far too many tasks, so didn't do it.)


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


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

Re: Thoughts about bts reassign

[Loïc Minier]

On Sat, Aug 04, 2007, Vincent Fourmond wrote:
>   When a bug filed against a package turns out to be a bug in one of the
> dependencies (including implicit ones, such as the kernel and so on...),
> instead of simply reassigning the bug to the faulty package

 It's not always a good idea to do as your propose as sometimes a bug in
 one package affects a lot of packages; what do you think of these
 alternate proposals:
 - display "ghost" bugs on the packages which were recently reassigned
   from (ie if you reassign a bug from X to Y, package X still displays
   it for some time) => this could be done on bugs.d.o, I don't know
   whether it's complex to implement
 - search through all recently reported bugs when submitting new bugs
   (instead of just presenting the list of bugs in the package one
   reports the bug against) => this would have to be implemented in all
   bug reporting tools, but might need some bugs.d.o changes as well

-- 
Loïc Minier


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

Re: Thoughts about bts reassign

[Adeodato Simó]

* Vincent Fourmond [Sat, 04 Aug 2007 13:34:31 +0200]:

> one should first clone it, then reassign,

This is sometimes done, but at maintainer's discretion only. Most likely
if it's a many-times reported bug.

Cheers,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
 Listening to: Eminem - My Fault


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

Re: Symbol-based dependencies on shared libraries: some news

[Loïc Minier]

On Sat, Aug 04, 2007, Raphael Hertzog wrote:
> Knowing those differences, I wonder if I should offer the possibility to have
> debian/.symbols.common that would complement what can be found in
> debian/.symbols. or if we need something more elaborated like
> an include mechanism or a syntax to restrict a symbol on a set of 
> architectures
> (like for dependencies in Build-Depends). Please give me your opinion on this.

 I wish for an include mechanism!  :)

 I think this also makes sense when you have multiple flavors of the
 same lib (for example libgtk versus libgtk-directfb).


 Do you strip the "well known symbols" you've seen on each arch so that
 one only has to specify the other symbols?  Or will each maintainer
 have to maintain one file per arch with arch specific symbols?

-- 
Loïc Minier


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

Re: Symbol-based dependencies on shared libraries: some news

[Andreas Metzler]

Raphael Hertzog <[EMAIL PROTECTED]> wrote:
[...]
> dpkg-gensymbols -plibcurl3 -Pdebian/libcurl3
> dpkg-gensymbols -plibcurl3-gnutls -Pdebian/libcurl3-gnutls
> (you should also create debian/.symbols file, see below
> to grab some pre-generated files)

> If you want dpkg-shlibdeps to generate smaller dependencies, you have
> to provide some useful symbols file in /etc/dpkg/symbols/
> (some up-to-date files here: 
> http://users.alioth.debian.org/~hertzog/symbols.tar.bz2
> they were generated by scanning successively etch/lenny/sid packages)
[...]

Hello,

Is /etc/dpkg/symbols/ just a temporary location?

cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


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

making debian/copyright machine-interpretable

[Sam Hocevar]

   Hello, I would like to gather comments about a proposal I have been
thinking about during the GPLv2/v3 and GPLv2/CDDL discussions. I have
finally written down what I have in mind here, and refined it with the
help of many people on IRC:

 http://wiki.debian.org/Proposals/CopyrightFormat

   I'll simply repeat the rationale here, so that you know why I feel
this is important. The diversity of free software licences means that
Debian does not only need to care about the freeness of a given work,
but also its licence's compatibility with the other parts of Debian it
uses.

   The arrival of the GPL version 3, its incompatibility with version 2,
and our inability to spot the software where the incompatibility might
be problematic is the most recent occurrence of this limitation.

   And there is more to come. The GPL version 3 is compatible with
the CDDL, but the GPL version 2 isn’t. Which means that in the near
future, GPLv2-only software cannot be distributed as part of a CDDL
operating system such as Nexenta. We have no way to know how much of
Debian should be stripped from such a system.

   I therefore would like your opinions about this proposal, its
shortcomings, and a strategy to implement it quickly and as widely as
possible.

Cheers,
-- 
Sam.


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

Re: Bug#435884: ITP: rsyslog -- enhanced multi-threaded syslogd

[Florian Weimer]

* Bastian Blank:

> On Sat, Aug 04, 2007 at 01:44:14AM -0400, Roberto C. Sánchez wrote:
>> As the "target" user for this sort of package is a sysadmin type, I
>> would saw it is an important enough detail that it should be in the
>> short description.
>
> But only in the relation: multi-threaded == bad. You need much more
> knowledge to handle concurrency correctly.

Your comment is a bit odd because Debian's syslogd (which is not
multi-threaded) did not handle concurrency correctly, resulting in a
hanging system.

Re: Symbol-based dependencies on shared libraries: some news

[Raphael Hertzog]

On Sat, 04 Aug 2007, Andreas Metzler wrote:
> Raphael Hertzog <[EMAIL PROTECTED]> wrote:
> [...]
> > dpkg-gensymbols -plibcurl3 -Pdebian/libcurl3
> > dpkg-gensymbols -plibcurl3-gnutls -Pdebian/libcurl3-gnutls
> > (you should also create debian/.symbols file, see below
> > to grab some pre-generated files)
> 
> > If you want dpkg-shlibdeps to generate smaller dependencies, you have
> > to provide some useful symbols file in /etc/dpkg/symbols/
> > (some up-to-date files here: 
> > http://users.alioth.debian.org/~hertzog/symbols.tar.bz2
> > they were generated by scanning successively etch/lenny/sid packages)
> [...]
> 
> Hello,
> 
> Is /etc/dpkg/symbols/ just a temporary location?

Yeah, obviously. It's meant to be a directory that you can use to override
the package-provided /var/lib/dpkg/info/*.symbols.

See http://wiki.debian.org/Projects/ImprovedDpkgShlibdeps for some generic
info on this project.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

Re: making debian/copyright machine-interpretable

[Roberto C . Sánchez]

On Sat, Aug 04, 2007 at 07:17:59PM +0200, Sam Hocevar wrote:
> 
>I therefore would like your opinions about this proposal, its
> shortcomings, and a strategy to implement it quickly and as widely as
> possible.
> 
I like it.  As I read the wiki page, I came up with several
"improvements."  As I continued I found that you had already come up
them and that I just had to read on.  In short, it seems well thought
out.

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: making debian/copyright machine-interpretable

[Loïc Minier]

On Sat, Aug 04, 2007, Sam Hocevar wrote:
>Hello, I would like to gather comments about a proposal I have been
> thinking about during the GPLv2/v3 and GPLv2/CDDL discussions. I have
> finally written down what I have in mind here, and refined it with the
> help of many people on IRC:
>  http://wiki.debian.org/Proposals/CopyrightFormat

 Excellent!

 Perhaps it would it make sense to use a format which would cover more
 use cases than debian/copyright.
   Some use cases I have in mind:
 - upstream source files embedding this information directly (would ease
   creation and maintenance of debian/copyright and result in a better
   quality; would also keep the information close to its source)
 - use by other distributors, by upstream, or by other tools in general
   (freshmeat, online code search or whatever)
 - encoding of license tags in binaries (like for kernel modules or like
   we have with selinux and security contexts)

 I suppose this would be possible by extending the format to allow
 embedding in comments such as C/C++/Java etc. comments.

-- 
Loïc Minier


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

Re: making debian/copyright machine-interpretable

[Russ Allbery]

Sam Hocevar <[EMAIL PROTECTED]> writes:

>I therefore would like your opinions about this proposal, its
> shortcomings, and a strategy to implement it quickly and as widely as
> possible.

It overall seems reasonable to me, although it surfaces other issues that
we've been somewhat ignoring.  For example, with a format for clearly
expressing copyrights that vary per file, it raises the question if we
should be noting such things.  Most packages that use Autoconf and friends
have files in the distribution (the generated configure and the like)
covered by a different license and copyright than the rest of the
distribution, and for the most part people are not noting this in
debian/copyright.

I'd like to see a field added to explain any repackaging of the upstream
source that was done, or an explicit statement that this should go into
the second and subsequent lines of the Source field, since I think
debian/copyright is the appropriate location for such information.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: making debian/copyright machine-interpretable

[Adam Borowski]

On Sat, Aug 04, 2007 at 07:17:59PM +0200, Sam Hocevar wrote:
>Hello, I would like to gather comments about a proposal I have been
> thinking about during the GPLv2/v3 and GPLv2/CDDL discussions. I have
> finally written down what I have in mind here, and refined it with the
> help of many people on IRC:
> 
>  http://wiki.debian.org/Proposals/CopyrightFormat

What about providing a way to programmatically cathegorize licenses,
something that would work for licenses other than different versions of GPL.

I mean:
* BSD4 (or "BSD4-like") for stuff with the advertising clause
* BSD-like (as you used yourself in the 2nd example) for MIT, old X11, etc
* rename-clause (where modified versions need a different name)
* ...

Just putting random acronyms in the license field won't make it usable for
anything more than distinguishing between GPLv2 and GPLv3; there are too
many licenses for an exhaustive list.  What I'm suggesting is to define an
authoritative list of license types, and to have that list small.  Something
just to tell the difference between no-problems-no-copyleft,
no-copyleft-but-with-issues, copyleft-but-GPL-compatible,
copyleft-but-not-GPL-compatible and the GPLs.  The latter would get
cathegories on their own because of the GPL's prominence.

The exact type of the license could be placed after a colon, like:
BSD-like:MIT.


-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: making debian/copyright machine-interpretable

[Faidon Liambotis]

Sam Hocevar wrote:
>Hello, I would like to gather comments about a proposal I have been
> thinking about during the GPLv2/v3 and GPLv2/CDDL discussions. I have
> finally written down what I have in mind here, and refined it with the
> help of many people on IRC:
> 
>  http://wiki.debian.org/Proposals/CopyrightFormat
That's great, thank you!

Some initial comments:
- Even though the GPL/OpenSSL is mentioned explicitely in the rationale,
 the rest of the document doesn't mention a good way to handle it.
- It would be nice (but may be overcomplicated, not sure) to have a
field for compatible licenses, probably only in the "other" license
case. E.g. monsterz could have a Compatible-License: GPL or a
Compatible-License: BSD. That would mostly solve the "other-bsd"/"BSD-like".
- I'm not sure if "License: GPL, BSD" for a file makes any sense (it's
GPL for all intents and purposes) and I'm afraid it will be (ab)used on
a "Files: *" to mean "some files under the BSD, others under the GPL".

Overall, this is a very good thing and besides the benefits you
mentioned wrt GPLv2/GPLv3/CDDL I think it will help us catch many old bugs.

Regards,
Faidon


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

Re: making debian/copyright machine-interpretable

[Sam Hocevar]

On Sat, Aug 04, 2007, Russ Allbery wrote:

> It overall seems reasonable to me, although it surfaces other issues that
> we've been somewhat ignoring.  For example, with a format for clearly
> expressing copyrights that vary per file, it raises the question if we
> should be noting such things.  Most packages that use Autoconf and friends
> have files in the distribution (the generated configure and the like)
> covered by a different license and copyright than the rest of the
> distribution, and for the most part people are not noting this in
> debian/copyright.
> 
> I'd like to see a field added to explain any repackaging of the upstream
> source that was done, or an explicit statement that this should go into
> the second and subsequent lines of the Source field, since I think
> debian/copyright is the appropriate location for such information.

   This is an issue I've been rather happy to ignore so far, because
it's really a lot of work for files that no one will probably ever look
at.

   However, if it must really be noted which files were changed and
how, I am not sure a new field needs to be added. Actually I think the
information fits nicely in the licensing terms without changing the
format:


Files: Makefile.in autotools/* configure
Copyright: (c) 1992-2006 Free Software Foundation, Inc.
   (c) 200X The Upstream Author
   (c) 200Y The Debian Maintainer
License: $LicenseOfUpstreamSoftware, other-BSD
 These files were regenerated from The Upstream Author's Makefile.am
 and configure.ac by The Debian Maintainer using autoconf 2.61 and
 automake 1.9.
 .
 The Free Software Foundation gives unlimited permission to copy,
 distribute and modify the resulting files.


   It is probably questionable whether the Debian maintainer is entitled
to a copyright on these files, but it is sometimes so difficult to
rebootstrap a source tree that I wouldn't be surprised one would argue
so. Anyway, it could also be removed.

Regards,
-- 
Sam.


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

Re: making debian/copyright machine-interpretable

[Don Armstrong]

On Sat, 04 Aug 2007, Sam Hocevar wrote:
> I therefore would like your opinions about this proposal, its
> shortcomings, and a strategy to implement it quickly and as widely
> as possible.

One of the other good points of this proposal is that it explicitely
indicates the copyright and licensing of the packaging work which has
been done, something that a lot of packages don't do. [Though I expect
every package intends to be under some DFSG free license.]


Don Armstrong

-- 
America was far better suited to be the World's Movie Star. The
world's tequila-addled pro-league bowler. The world's acerbic bi-polar
stand-up comedian. Anything but a somber and tedious nation of
socially responsible centurions.
 -- Bruce Sterling, _Distraction_ p122

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


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

Bug#436037: ITP: luke -- development and diagnostic tool for Lucene

[Jan-Pascal van Best]

Package: wnpp
Severity: wishlist
Owner: "Jan-Pascal van Best" <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: luke
  Version : 0.7.1
  Upstream Author : Andrzej Bialecki <[EMAIL PROTECTED]>
* URL : http://www.getopt.org/luke/
* License : Apache
  Programming Lang: Java
  Description : development and diagnostic tool for Lucene

Luke is a handy development and diagnostic tool, which accesses 
already existing Lucene indexes and allows you to display and 
modify their contents in several ways:
* browse by document number, or by term
* view documents / copy to clipboard
* retrieve a ranked list of most frequent terms
* execute a search, and browse the results
* analyze search results
* selectively delete documents from the index
* reconstruct the original document fields, edit them and re-insert to the 
index
* optimize indexes
* and much more...

Recent versions of Luke are also extensible through plugins and scripting. 

- -- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (900, 'stable'), (300, 'testing'), (100, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.22-1-k7
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGtN2mOkyycBqJzCMRAik+AJ9Cbvh8lH7TyjewGzHcoIg3PKFDEQCbBogN
1NaSun3jiVzHS/dUjwPr9YA=
=DP55
-END PGP SIGNATURE-


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

Re: making debian/copyright machine-interpretable

[Stefano Zacchiroli]

On Sat, Aug 04, 2007 at 07:17:59PM +0200, Sam Hocevar wrote:
>  http://wiki.debian.org/Proposals/CopyrightFormat

I really like the idea, thanks for this proposal!

A comment about file patterns. For possible future needs I would go for
specifying clearly the semantic of file patterns, for example whether if
the first matching pattern apply to a file (as it seems in your example
on the wikipage) or whether if the last does (as I would recommend,
since usually, for the sake of human communication, you first want to
specify the most "common" license of a source package, then the
exceptions).

Similarly, it might be useful to have Vim-like '**'-patterns to match
arbitrarily deep subdirectories, thought not really required.

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: Bug#435884: ITP: rsyslog -- enhanced multi-threaded syslogd

[Steinar H. Gunderson]

On Sun, Aug 05, 2007 at 12:21:46AM +1000, Hamish Moffatt wrote:
> System admins might regard multi-threaded as the key to high
> performance.

Your system admins sound rather odd. Lots of software is high performance
without ever using threads at all.

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


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

Re: Symbol-based dependencies on shared libraries: some news

[Raphael Hertzog]

On Sat, 04 Aug 2007, Loïc Minier wrote:
>  Do you strip the "well known symbols" you've seen on each arch so that
>  one only has to specify the other symbols?

No, because they might change with the toolchain and we want to track that
properly...

>  Or will each maintainer have to maintain one file per arch with arch
>  specific symbols?

Currently yes. I'm open to any suggestion however.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

Re: Symbol-based dependencies on shared libraries: some news

[Steve Langasek]

On Sat, Aug 04, 2007 at 10:41:25PM +0200, Raphael Hertzog wrote:
> On Sat, 04 Aug 2007, Loïc Minier wrote:
> >  Do you strip the "well known symbols" you've seen on each arch so that
> >  one only has to specify the other symbols?

> No, because they might change with the toolchain and we want to track that
> properly...

Why does it need tracking?  If these symbols were to disappear that would
be no loss, it shouldn't be relevant to the library ABIs at all.  I think it
would indeed be better to exclude these symbols from the list.

-- 
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: making debian/copyright machine-interpretable

[Florian Weimer]

* Sam Hocevar:

>Hello, I would like to gather comments about a proposal I have been
> thinking about during the GPLv2/v3 and GPLv2/CDDL discussions. I have
> finally written down what I have in mind here, and refined it with the
> help of many people on IRC:
>
>  http://wiki.debian.org/Proposals/CopyrightFormat

It's probably better to use a separate file.  If there's a syntax
error, you can't be sure if the file is in the old format, or if its a
genuine error.

Copyright statements with year numbers need to be updated once per
year, complicating merging from upstream.  Is this really worth the
effort?  Copyright holder information is probably not very valuable
without unique identifiers per copyright holder anyway.

In order to automatically detect licensing violations, the files in
the binary package would need annotations.  Annotating the source
files is not sufficient.


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

Re: making debian/copyright machine-interpretable

[Mike Hommey]

On Sat, Aug 04, 2007 at 04:19:29PM -0400, Stefano Zacchiroli <[EMAIL 
PROTECTED]> wrote:
> On Sat, Aug 04, 2007 at 07:17:59PM +0200, Sam Hocevar wrote:
> >  http://wiki.debian.org/Proposals/CopyrightFormat
> 
> I really like the idea, thanks for this proposal!
> 
> A comment about file patterns. For possible future needs I would go for
> specifying clearly the semantic of file patterns, for example whether if
> the first matching pattern apply to a file (as it seems in your example
> on the wikipage) or whether if the last does (as I would recommend,
> since usually, for the sake of human communication, you first want to
> specify the most "common" license of a source package, then the
> exceptions).
> 
> Similarly, it might be useful to have Vim-like '**'-patterns to match
> arbitrarily deep subdirectories, thought not really required.

Also, it might be better to have comma separated file lists, instead of
space separated lists. Filenames are more likely to contain spaces than
commas (Notably, in big projects that have windows ports or that come
from the windows world, filenames containing whitespaces are not
uncommon). Or maybe pipes, they are even more unlikely in a filename.

Mike


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

Re: making debian/copyright machine-interpretable

[David Moreno Garza]

On Sat, 2007-08-04 at 19:17 +0200, Sam Hocevar wrote:
>I therefore would like your opinions about this proposal, its
> shortcomings, and a strategy to implement it quickly and as widely as
> possible.

I strongly support this initiative.

This would also allow package checkers to efficiently verify copyright
information by policy and syntax and not only by scrapping text and
guessing what's missing and what everybody "should" stick to.

This may be a great release goal for lenny+1, perhaps.

--
David Moreno Garza <[EMAIL PROTECTED]> | http://www.damog.net/
 Saca tus alas y empieza a volar.



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

Re: making debian/copyright machine-interpretable

[Steinar H. Gunderson]

On Sat, Aug 04, 2007 at 11:24:49PM +0200, Mike Hommey wrote:
> Or maybe pipes, they are even more unlikely in a filename.

I remember the problem in dak where ~ was used as field separator
because nothing contained tildes anyway... until version numbers did :-)

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


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

Re: making debian/copyright machine-interpretable

[David Moreno Garza]

On Sat, 2007-08-04 at 23:24 +0200, Mike Hommey wrote:
> Also, it might be better to have comma separated file lists, instead of
> space separated lists. Filenames are more likely to contain spaces than
> commas (Notably, in big projects that have windows ports or that come
> from the windows world, filenames containing whitespaces are not
> uncommon). Or maybe pipes, they are even more unlikely in a filename.

We do should have comma-separated lists, not because file names do not
contain them often (in that case why don't we just use `ñ'?), but
because that's the usual way it's done on other RFC 2822 debian files,
such as control.

--
David Moreno Garza <[EMAIL PROTECTED]> | http://www.damog.net/
 Poor Mexico: So far from God, so close to the United States.

Re: making debian/copyright machine-interpretable

[Sam Hocevar]

On Sat, Aug 04, 2007, Florian Weimer wrote:

> It's probably better to use a separate file.  If there's a syntax
> error, you can't be sure if the file is in the old format, or if its a
> genuine error.

   But the information must be in debian/copyright. Duplicating it is
not an option.

> Copyright statements with year numbers need to be updated once per
> year, complicating merging from upstream.  Is this really worth the
> effort?  Copyright holder information is probably not very valuable
> without unique identifiers per copyright holder anyway.

   This information is required for debian/copyright, too. The proposal
just puts it in a header. Citing copyright years is not useful, but it's
probably required by law. Have you had one of your packages out of NEW
lately? :-)

> In order to automatically detect licensing violations, the files in
> the binary package would need annotations.  Annotating the source
> files is not sufficient.

   That's right, we don't know the licensing terms of binary files.
But if we stop at the "it's not sufficient" argument, we'll never get
anywhere, because it is impossible for a source package to determine the
exact licensing terms of its binary packages. I'll leave that to another
proposal.

Cheers,
-- 
Sam.


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

Re: Packaging a difficult project

[Joerg Jaspert]

On 11101 March 1977, Brendon Costa wrote:

>>> EDoc++ binaries are currently around 20M. It does not require any
>>> special binutils etc, but will just use what is already available for
>>> the system. I am currently building a single non-policy conformant .deb
>>> package.
>> I think the concern is more about the edoc source, which would apparently 
>> include gcc source, which is large and already on the mirrors multiple times.
> The tarball of all source necessary to build EDoc++ is 25M and extracted
>  it is: 47M.

> EDoc++ stores in its source tree patches against GCC along with the GCC
> original tarballs, and at build time will extract the gcc tarballs into
> the build directory and apply the patches before building it.

Duplicating any source in the archive is indeed not really what we
like. For gcc there seem to be -source packages. Can you build-depend on
them and use the source from them? That would at least get that needless
duplication away.

> This is unfortunate, however from what
> i understand it is unavoidable. If there is a way to avoid it I would be
> interested in looking at pursuing that option if it will help.

Package: gcc-4.1-source
Priority: optional
Section: devel
Installed-Size: 51816
Maintainer: Debian GCC Maintainers <[EMAIL PROTECTED]>
Architecture: all
Source: gcc-4.1
Version: 4.1.2-14
Depends: gcc-4.1-base (>= 4.1.2-2), make (>= 3.81)
Filename: pool/main/g/gcc-4.1/gcc-4.1-source_4.1.2-14_all.deb
Size: 48305110
MD5sum: 6bce483ed95cd503afea43441e64b094
SHA1: 0cb18d6aea5195c7e53efae66446f6b3522d06c9
SHA256: c4c75e97d52055d71f2c794f779cfeb9367b1b42a5724b178dee684c580574a6
Description: Source of the GNU Compiler Collection
 This package contains the sources and patches which are needed to
 build the GNU Compiler Collection (GCC).

That may be an option.


It may also be an option talkin to the gcc maintainers, if its possible
to include your thing in their package suite. Like - storing it as a
patch and modifying the build system in a way that at the end just one
more bianry package gets spit out.

Im not sure the latter is possible, but maybe, and talking to them
doesnt cost much...

-- 
bye Joerg
2.5 million B.C.: OOG the Open Source Caveman develops the axe and
releases it under the GPL. The axe quickly gains popularity as a means
of crushing moderators heads.


pgp6BPgEwsMOk.pgp
Description: PGP signature

Re: making debian/copyright machine-interpretable

[Sam Hocevar]

On Sat, Aug 04, 2007, Stefano Zacchiroli wrote:

> A comment about file patterns. For possible future needs I would go for
> specifying clearly the semantic of file patterns, for example whether if
> the first matching pattern apply to a file (as it seems in your example
> on the wikipage) or whether if the last does (as I would recommend,
> since usually, for the sake of human communication, you first want to
> specify the most "common" license of a source package, then the
> exceptions).

   I don't feel strongly about either, but what I don't like in your
recommendation is that information you read from it can be superseded
by the following lines, forcing it to read it all (or from the end) in
order to be sure of what it says.

   I guess it all comes to whether you look at the file asking "what are
the licenses in the package?" in which case you may prefer to see most
common licenses first, or "what license is file XXX?" in which case you
read the file until one of the patterns matches, and you know that's
your licensing terms.

> Similarly, it might be useful to have Vim-like '**'-patterns to match
> arbitrarily deep subdirectories, thought not really required.

   Right. Maybe I could formalise that into saying "pattern  is
what `find -wholename */' will match".

Regards,
-- 
Sam.


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

Re: making debian/copyright machine-interpretable

[Sam Hocevar]

On Sat, Aug 04, 2007, Adam Borowski wrote:

> What about providing a way to programmatically cathegorize licenses,
> something that would work for licenses other than different versions of GPL.
> 
> I mean:
> * BSD4 (or "BSD4-like") for stuff with the advertising clause
> * BSD-like (as you used yourself in the 2nd example) for MIT, old X11, etc
> * rename-clause (where modified versions need a different name)
> * ...
> 
> Just putting random acronyms in the license field won't make it usable for
> anything more than distinguishing between GPLv2 and GPLv3; there are too
> many licenses for an exhaustive list.  What I'm suggesting is to define an
> authoritative list of license types, and to have that list small.  Something
> just to tell the difference between no-problems-no-copyleft,
> no-copyleft-but-with-issues, copyleft-but-GPL-compatible,
> copyleft-but-not-GPL-compatible and the GPLs.  The latter would get
> cathegories on their own because of the GPL's prominence.

   All this information (GPL-compatibility, having issues etc.) is
external and should IMHO stay external. Otherwise if and when a GPLv4
is out, we'll need to change all the debian/copyright files to say
whether their license is GPLv4-compatible or not. Also the DFSGs can
change. I prefer to have license interpretation completely outside
debian/copyright.

Cheers,
-- 
Sam.


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

Re: making debian/copyright machine-interpretable

[Sam Hocevar]

On Sat, Aug 04, 2007, Faidon Liambotis wrote:

> Some initial comments:
> - Even though the GPL/OpenSSL is mentioned explicitely in the rationale,
>  the rest of the document doesn't mention a good way to handle it.

   That has been mentioned to me several times already. I don't know yet
what the best way to express it is, but I think it'll be something like
"GPLv2+ | other" (or the appropriate GPL version).

   There are probably ways to express the OpenSSL exception but I don't
want to make it too complicated for the maintainer. The license's not in
the list? Just put "other".

> - It would be nice (but may be overcomplicated, not sure) to have a
> field for compatible licenses, probably only in the "other" license
> case. E.g. monsterz could have a Compatible-License: GPL or a
> Compatible-License: BSD. That would mostly solve the "other-bsd"/"BSD-like".

   Can't we assume that "other-bsd" licenses are compatible with each
other and also with every other license? Because if a BSD-like license
is not compatible with another BSD license, for instance because it has
an additional minor clause, then it's not BSD, is it? It's "other".

   Anyway, let's not spend too much time worrying about special cases.
A massive 80% of all free software (be it in Debian or on Freshmeat) is
under a version of the GPL or of the LGPL. Which means that we'll be
able to ignore around 14,000 source packages when looking for issues.

> - I'm not sure if "License: GPL, BSD" for a file makes any sense (it's
> GPL for all intents and purposes) and I'm afraid it will be (ab)used on
> a "Files: *" to mean "some files under the BSD, others under the GPL".

   And you know what? I'd be perfectly happy if someone abused
that and put "Files: *" and "License: GPL, BSD" because they are
too lazy to split the file list. Because 1. such packages would be
easily detectable, and 2. in the end, we essentially care about
GPL-compatibility anyway, so we have the most important information.

Cheers,
-- 
Sam.


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

man-db's cron warns about dangling symlink

[Samuel Thibault]

Hi,

Short story:

# apt-get install mpich-bin
# dpkg -P mpich-bin
# symlinks  /usr/share/man/man1/ | grep dangling
dangling: /usr/share/man/man1/clog2alog.1.gz -> /etc/alternatives/clog2alog.1.gz
dangling: /usr/share/man/man1/upshot.1.gz -> /etc/alternatives/upshot.1.gz
dangling: /usr/share/man/man1/clog_print.1.gz -> 
/etc/alternatives/clog_print.1.gz
dangling: /usr/share/man/man1/mpirun.1.gz -> /etc/alternatives/mpirun.1.gz
etc.

And the result is that when man-db gets run from cron, it sends the
following mail:
/etc/cron.daily/man-db:
mandb: warning: /usr/share/man/man1/clog2alog.1.gz is a dangling symlink
mandb: warning: /usr/share/man/man1/upshot.1.gz is a dangling symlink
mandb: warning: /usr/share/man/man1/clog_print.1.gz is a dangling symlink
mandb: warning: /usr/share/man/man1/mpirun.1.gz is a dangling symlink
etc.

The bug is that although the mpich-bin package uses
update-alternatives --install on postinst for all these files, it uses
update-alternatives --remove only on /usr/lib/mpich/bin/mpirun, leaving
a bunch of dangling symlinks...

The reason why I'm mailing debian-devel is that I've seen this behavior
quite often in the past, in various packages.  I hence guess there
should be some automatic way to check that a package correctly removes
the alternatives it provides.

Samuel


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

Re: making debian/copyright machine-interpretable

[Stefano Zacchiroli]

On Sun, Aug 05, 2007 at 12:10:56AM +0200, Sam Hocevar wrote:
>I guess it all comes to whether you look at the file asking "what are
> the licenses in the package?" in which case you may prefer to see most
> common licenses first, or "what license is file XXX?" in which case you
> read the file until one of the patterns matches, and you know that's
> your licensing terms.

True, both indeed make sense. Just to mention another reason which IMO
supports the "most common first" criterion (but I'm sure can be twisted
to support the other :-)), once we have an unambiguous semantics for the
file patterns we can have a couple of tools like:

1) whichlicense: invoked on a pathname rooted at the root of a debian
   source package it returns the license keyword/full text associated
   with that file

2) checklicenses (which is in need of a better name): invoked with no
   arguments it checks if all shipped files in a debian source package
   are matched (after ambiguities have been resolved) by exactly one
   file pattern in debian/copyright, that would be in the same spirit of
   "dh_install --fail-missing"

*If* (1) addresses properly your latter use case ("what license is file
XXX") than we can probably live happily with the "most common first"
criterion.

> > Similarly, it might be useful to have Vim-like '**'-patterns to match
> > arbitrarily deep subdirectories, thought not really required.
>Right. Maybe I could formalise that into saying "pattern  is
> what `find -wholename */' will match".

That will do too, fine for me.

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: Bug#435838: ITP: cpm -- Console Password Manager

[Brian May]

> "John" == John Goerzen <[EMAIL PROTECTED]> writes:

John> The software uses CDK (ncurses) to handle the user
John> interface, libxml2 to store the information, the zlib
John> library to compress the data and the library GpgMe to
John> encrypt and decrypt the data securely.

The description seems pretty good. My initial tests seem to suggest it
requires an old version of libcdk that is no longer available in
Debian though:

=== cut ===
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking how to run the C preprocessor... gcc -E
checking for egrep... grep -E
checking whether gcc needs -traditional... no
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln -s works... yes
checking whether make sets $(MAKE)... yes
configure: checking libraries
checking for main in -lm... yes
checking for initscr in -lncurses... yes
checking for initCDKScreen in -lcdk... yes
checking for FascistCheck in -lcrack... yes
checking for dotconf_create in -ldotconf... yes
checking for gpgme_get_engine_info in -lgpgme... yes
checking for xmlParseFile in -lxml2... yes
checking for compress in -lz... yes

Error
Sorry, this version of CDK can not handle empty lists.
You must downgrade to a version older than cdk-4.9.11-20031210
=== cut ===

Hopefully there is a solution to this issue...
-- 
Brian May <[EMAIL PROTECTED]>


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

Re: making debian/copyright machine-interpretable

[Matthew Garrett]

Sam Hocevar <[EMAIL PROTECTED]> wrote:

>And there is more to come. The GPL version 3 is compatible with
> the CDDL, but the GPL version 2 isn?t. Which means that in the near
> future, GPLv2-only software cannot be distributed as part of a CDDL
> operating system such as Nexenta. We have no way to know how much of
> Debian should be stripped from such a system.

It would be helpful to clarify this. As far as I know, GPLv3 isn't
compatible with the CDDL in the sense of "an application may mix 
sections of source code under these two licenses" - just the "a GPLv3 
application may make use of CDDLed libraries" sense.

-- 
Matthew Garrett | [EMAIL PROTECTED]


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

debian/copyright machine-interpretable: how about the patches in the diff.gz ?

[Charles Plessy]

Le Sat, Aug 04, 2007 at 07:17:59PM +0200, Sam Hocevar a écrit :
>Hello, I would like to gather comments about a proposal I have been
> thinking about during the GPLv2/v3 and GPLv2/CDDL discussions. I have
> finally written down what I have in mind here, and refined it with the
> help of many people on IRC:
> 
>  http://wiki.debian.org/Proposals/CopyrightFormat

Dear Sam,

Nice proposal !

Here are two comments which I hope can help to enhance it:

 - To be really accurate about the copyright of the packaging work, it
   should also mention the patches in the diff.gz which are applied on
   the main sources.

 - One drawback of the greedy approach for organising the Files fields
   is that the most important copyright - the one of the programs which
   gives to the package its raison d'être - will never be at the top of
   the list.


Have a nice day,

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


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

Bug#436065: ITP: flickcurl -- C library for the Flickr API

[Kumar Appaiah]

Package: wnpp
Severity: wishlist
Owner: Kumar Appaiah <[EMAIL PROTECTED]>


* Package name: flickcurl
  Version : 0.11
  Upstream Author : Dave Beckett <[EMAIL PROTECTED]>
* URL : http://librdf.org/flickcurl/
* License : LGPL 2.1 / GPL 2 /Apache 2.0
  Programming Lang: C
  Description : C library for the Flickr API

Flickcurl is a C library for the Flickr API, handling creating the
requests, signing, token management, calling the API, marshalling
request parameters and decoding responses. It uses libcurl to call the
REST web service and libxml2 to manipulate the XML responses. The
current version supports part of the API, primarily the functions for
reading photo, people and tags description, uploading photos, changing
tags and comments.

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

Kernel: Linux 2.6.22.1 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) (ignored: LC_ALL set to 
en_US)
Shell: /bin/sh linked to /bin/bash


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

Re: debian/copyright machine-interpretable: how about the patches in the diff.gz ?

[Ben Finney]

Charles Plessy <[EMAIL PROTECTED]> writes:

>  - One drawback of the greedy approach for organising the Files fields
>is that the most important copyright - the one of the programs which
>gives to the package its raison d'être - will never be at the top of
>the list.

For many packages, there is no single "copyright of the programs",
because there are multiple copyright holders, each one with copyright
in parts of the source tree. There may even be multiple licenses.

It's good, then, that this proposal doesn't extend
-- 
 \ "If nature has made any one thing less susceptible than all |
  `\others of exclusive property, it is the action of the thinking |
_o__)   power called an idea"  -- Thomas Jefferson |
Ben Finney
 the illusion of
"the one true copyright of the programs".


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

Re: debian/copyright machine-interpretable: how about the patches in the diff.gz ?

[Ben Finney]

Charles Plessy <[EMAIL PROTECTED]> writes:

>  - One drawback of the greedy approach for organising the Files fields
>is that the most important copyright - the one of the programs which
>gives to the package its raison d'être - will never be at the top of
>the list.

For a large proportion of packages, there is no single "copyright of
the work", because there are multiple copyright holders, each one with
copyright in parts of the source tree.

For a subset of those packages with multiple copyright holders, there
are even multiple licenses over the work.

It's good, then, that this proposal doesn't extend a simplistic
illusion of "the one true copyright of the work".

-- 
 \ "If nature has made any one thing less susceptible than all |
  `\others of exclusive property, it is the action of the thinking |
_o__)   power called an idea"  -- Thomas Jefferson |
Ben Finney


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

Re: making debian/copyright machine-interpretable

[Joey Hess]

* Others have mentioned the ordering problem that puts the main license
  last. Seems that Packaging-Copyright at the top is another case of
  this problem (see you've now removed that special case name, but the
  debian/* data would still go there). "Most specific matching glob wins"[1]
  might be a better approach. Then the licenses could be ordered with the
  main one first, or in whatever order that makes sense to humans, and
  if someone wanted to write a tool to extract a given file's license,
  that could be done too.

* Having to munge the license text to fit it in the 822 format is one of
  the uglier bits of this proposal, especially since we don't require
  that license texts be DFSG free..

* It's a shame that the boilerplate about where to find the full text of
  the GPL is still needed at the end of the file. One way to avoid this
  might be to use:

  License: /usr/share/common-licenses/GPL-2
  
  The info about which versions apply would need to be expressed some
  other way though.

* I don't see much benefit in putting freeform text at the top of the
  file. Keeping it all at the bottom would simplify parsing/validating.

* Makes even more clear that debian/copyright is not the best place for
  Source URLs. They rather stick out from the other data, and this would
  be a great time to go ahead and move them to the control file.
  Dropping them entirely in favour of watch files -- not so good: It's
  good to know where a package came from even if a tarball can't be
  auto-extracted from there by uscan.

-- 
see shy jo

[1] Which is perhaps interesting to implement. Google tells me that
smake has this concept.


signature.asc
Description: Digital signature

Bug#436069: ITP: dsdp -- DSDP implements an interior-point method for semidefinite programming.

[Soeren Sonnenburg]

Package: wnpp
Severity: wishlist
Owner: Soeren Sonnenburg <[EMAIL PROTECTED]>

* Package name: dsdp
  Version : 5.8
  Upstream Author : Steven J. Benson <[EMAIL PROTECTED]> and Yinyu Ye <[EMAIL 
PROTECTED]>
* URL : http://www-unix.mcs.anl.gov/DSDP/
* License : BSD
  Programming Lang: C
  Description : DSDP implements an interior-point method for semidefinite 
programming.

 The DSDP software is a free open source implementation of an interior-point
 method for semidefinite programming. It provides primal and dual solutions,
 exploits low-rank structure and sparsity in the data, and has relatively
 low memory requirements for an interior-point method. It allows feasible
 and infeasible starting points and provides approximate certificates of
 infeasibility when no feasible solution exists. The dual-scaling
 algorithm implemented in this package has a convergence proof and
 worst-case polynomial complexity under mild assumptions on the
 data.Furthermore, the solver offers scalable parallel performance for
 large problems and a well documented interface. Some of the most popular
 applications of semidefinite programming and linear matrix inequalities
 (LMI) are model control, truss topology design, and semidefinite
 relaxations of combinatorial and global optimization problems.

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

Kernel: Linux 2.6.23-rc2-sonne (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


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

Re: making debian/copyright machine-interpretable

[Mike Hommey]

On Sat, Aug 04, 2007 at 11:13:16PM -0700, Joey Hess <[EMAIL PROTECTED]> wrote:
(...) 
> * Having to munge the license text to fit it in the 822 format is one of
>   the uglier bits of this proposal, especially since we don't require
>   that license texts be DFSG free..

Surely, any license text, be it DFSG free or not, can be reformatted.

(...) 
> * Makes even more clear that debian/copyright is not the best place for
>   Source URLs. They rather stick out from the other data, and this would
>   be a great time to go ahead and move them to the control file.
>   Dropping them entirely in favour of watch files -- not so good: It's
>   good to know where a package came from even if a tarball can't be
>   auto-extracted from there by uscan.

Seconded. By the way, it would be nice if lintian did a check of the
url. It often happens that when I look at a url in copyright files, they
are so old that they don't exist anymore.

Mike


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

Re: making debian/copyright machine-interpretable

[Russ Allbery]

Mike Hommey <[EMAIL PROTECTED]> writes:
> On Sat, Aug 04, 2007 at 11:13:16PM -0700, Joey Hess <[EMAIL PROTECTED]> wrote:

> (...) 
>> * Makes even more clear that debian/copyright is not the best place for
>>   Source URLs. They rather stick out from the other data, and this would
>>   be a great time to go ahead and move them to the control file.
>>   Dropping them entirely in favour of watch files -- not so good: It's
>>   good to know where a package came from even if a tarball can't be
>>   auto-extracted from there by uscan.

However, the upstream source information is properly free-form text.  It's
only a URL in the common case, but some upstreams involve combining
multiple tarballs, downloading CVS or Subversion snapshots, pulling git or
bzr branches, and other, more complex manipulations.  This would therefore
require another Description-like free-form text field in control, which is
a bit uglier.

> Seconded. By the way, it would be nice if lintian did a check of the
> url. It often happens that when I look at a url in copyright files, they
> are so old that they don't exist anymore.

lintian intentionally limits its scope to checks that can be done using
only information in the package and in lintian so that they reliably
return the same results every time, no matter where they're run from.
This means that lintian can't do tests that rely on having a network
connection, access to a Debian mirror, access to package dependencies, and
so forth.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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