DEP5: Change of status to "Candidate"

[Dmitrijs Ledkovs]

Dear all

DEP5 is quite stable now (no updates for a while).

Implementation format exists and is being used by quite a few packages now.

Shall DEP-5 be changed to "Candidate" status? Do we have rough consensus?

I believe changing status to Candidate will drive further adoption &
testing as well as helper tool development.

Quote from DEP0:

### DRAFT state: discussion

* every new proposal starts as a DRAFT
* anyone can propose a draft
* each draft has a number (next free one from document index)
* normal discussion and changes to the text happen in this state
* drafts should include *extra* criteria for success (in addition to
  having obtained consensus, see below), that is, requirements to
  finally become ACCEPTED

 DRAFT -> CANDIDATE: rough consensus

In order for a DEP to become CANDIDATE, the following condition should
be met:

* consensus exists for *what* should be done, and *how* it should be
  done (agreement needs to be expressed by all affected parties, not
  just the drivers; silence is not agreement, but unanimity is not
  required, either)

-- 
With best regards


Dmitrijs Ledkovs (for short Dima),
Ледков Дмитрий Юрьевич

()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments


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

Re: DEP5: Change of status to "Candidate"

[Steve Langasek]

On Thu, Dec 10, 2009 at 08:04:33AM +, Dmitrijs Ledkovs wrote:

> DEP5 is quite stable now (no updates for a while).

No, it is not.  It is stagnant, not stable.

I don't believe there's any consensus about it; there have been list
discussions in the past with major objections to its current content that
are so far unaddressed, and the current content is, furthermore, the outcome
of a long series of non-consensual edits.  I as the DEP driver don't stand
behind it at all as a standard in its current form.

This is my fault as the DEP driver (both for letting the non-consensual
editing take place and for not guiding the discussion better), but it does
mean that I'm not about to mark the current document as a candidate.

I hope to make some progress on remedying this starting next week.

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


signature.asc
Description: Digital signature

Re: Policy conformant conffile handling...

[Frank Küster]

Frank Küster  wrote:

> Steve Langasek  wrote:
>
>> On Thu, Dec 03, 2009 at 11:40:06AM +0100, Frank Küster wrote:
>>> However, and here's the policy-related problem: Of course the admin
>>> might have changed the default paper for one particular binary
>>> manually. What should I do in this case?
>>
>> [...]
>>
>>> - let libpaper's setting overwrite everything: Probably not intended;
>>>   not policy-compliant
>>
>> Is texconfig being called from maintainer scripts?
>
> In this case, at least indirectly; since I would drop a script into
> /etc/libpaper.d/ that calls "texconfig paper $(paperconf -n -d)"

It would be okay to ask debconf questions here, wouldn't it? Then I'll
let texconfig analyse the settings in all involved config files, and if
they differ, ask the admin to which the libpaper setting should be
applied. 

Regards, Frank

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


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

About repackaging of the ‘ orig’ tarball.

[Charles Plessy]

Dear FTP team,

In the following message sent on debian-devel
(<20091209003633.gb29...@kunpuu.plessy.org>), it has been suggested that we
repack upstream original source archives when they contain generated files in
order to ease your work. Can you confirm or infirm whether you have a
preference?

Many thanks, and have a nice day,

-- Charles Plessy

Le Tue, Dec 08, 2009 at 05:36:54PM +0100, Damien Raude-Morvan a écrit :
> On Tue, 8 Dec 2009 16:56:05 +0100, Thomas Koch  wrote:
> > Hi,
> 
> Hi Thomas,
> 
> > I'm triing to package a little java library, which contains its own .jar
> > and some pregenerated docs. These files should be regenerated on build
> time.
> > So I'd like to have them removed by diff.gz
> 
> As a general guideline, generated files should be stripped from "original"
> source tarballs.
> If you choose to keep them in orig.tar.{gz,bz2}, it's complicated for
> others people (FTP Masters, reviewers, ...)
> to ensure there is not binary blob or non-free stuff inside your package.


Dear Damien and all,

I personnally tend to prefer to keep the Debian ‘orig’ tarball identical to the
upstream tarball as much as it is possible, so that by its MD5 sum it is
obvious that it is pristine.

I just asked in the same email to the FTP team if this practice is actually
unhelpful. If it is the case, maybe we could document it in the Developers
Reference.

In contrary, if the FTP team, and by extension the developers who spend much
time reviewing packages are indifferent to repackaging, I think that it is
important to have it clarified on this list, since otherwise we drift on some
tradition out of no fact.

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


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

Richiesta autorizzazione

[Giorgia Ferrari Forum Media]

Buongiorno,

sono Giorgia Ferrari, assistente Marketing di Forum Media Srl, società 
operante nel campo dell'editoria e della formazione professionale.

La presente per richiederLe l'autorizzazione, ai sensi della vigente normativa 
sulla Privacy, ad inviarLe, a titolo informativo, tramite e-mail qualche 
dettaglio sui nostri recenti prodotti editoriali specifici per il settore 
Tecnico-Amministrativo, Ambiente e Sicurezza, Risorse Umane, Management e 
Formazione Professionale.
A questo proposito vorremmo inviarLe, a titolo informativo, schede prodotto 
dettagliate in modo che Lei possa valutare un Suo possibile interesse. Nel caso 
in cui preferisca ricevere dette informazioni via fax, oppure ad altro 
indirizzo di posta elettronica, voglia cortesemente trasmetterci i 
riferimenti.
Teniamo a precisare che, nel rispetto rigoroso della normativa sulla privacy, 
valuteremo solo autorizzazioni con la modalità opt-in, ossia non 
invieremo nulla senza un Suo regolare ed espresso assenso.
RingraziandoLa per l'attenzione, Le porgo i miei più cordiali 
saluti.
Giorgia Ferrari
FORUM MEDIA
http://www.forum-media.it";>www.forum-media.it
Il vostro indirizzo e-mail è trattato in conformità 
all'Art. 13 del D.lgs 30 giugno 2003 n.196, garantendo la massima riservatezza 
ed al fine di fornire utili informazioni commerciali per la Sua/Vostra 
attività. Se non volete ricevere più messaggi inviati per conto 
dell'operatore si prega di inviare un messaggio all'indirizzo mailto:unsubscr...@forum-media.it";>unsubscr...@forum-media.it.

dpkg-trigger complains at dpkg-reconfigure time

[Norbert Preining]

Dear all,

I have a question for sure stemming from my misunderstanding of triggers.
tex-common ships dh_installtex which makes installation of fonts etc
for TeX system easy, and it is used in quite some packages. We use
triggers (on popolar demand) since the most expensive operation is
the update of the font maps (calling updmap-sys), which is handled
by triggers.

Now in the generated postinst snippets we have some down there
update-texmf-config updmap
which in turn calls 
dpkg-trigger texmf-updmap

Now when doing 
dpkg-reconfigure one-of-the-font-packages
I get
dpkg-trigger: dpkg-trigger must be called from a maintainer script (or 
with a --by-package option)

I though well, yes, it is called from a maintainer script (postinst configure)
and the package should be clear. But why does dpkg-trigger complain?

Thanks for any explanation

Norbert

Norbert Preiningprein...@{jaist.ac.jp, logic.at, debian.org}
JAIST, JapanTU Wien, Austria   Debian TeX Task Force
DSA: 0x09C5B094   fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094

DUNBAR (n.)
A highly specialised fiscal term used solely by turnstile
operatives at Regnet's Part zoo. It refers to the variable amount of
increase in the variable gate takings on a Sunday afternoon, caused by
persons going to the zoo because they are in love and believe that the
feeling of romance will be somehow enhanced by the smell of panther
sweat and rank incontinence in the reptile house.
--- Douglas Adams, The Meaning of Liff


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

Re: Re: defaulting to net.ipv6.bindv6only=1 for squeeze

[Roman Mamedov]

> Done, let's see what breaks. :-)

vnc4server: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560137

Marco, by making this change I assume you offer your personal help in dealing
with its consequences? Please feel free to submit a fix to #560137, thanks in
advance.

-- 
With respect,
Roman


signature.asc
Description: PGP signature

Re: dpkg-trigger complains at dpkg-reconfigure time

[Steve Langasek]

On Thu, Dec 10, 2009 at 04:05:25PM +0100, Norbert Preining wrote:

> I have a question for sure stemming from my misunderstanding of triggers.
> tex-common ships dh_installtex which makes installation of fonts etc
> for TeX system easy, and it is used in quite some packages. We use
> triggers (on popolar demand) since the most expensive operation is
> the update of the font maps (calling updmap-sys), which is handled
> by triggers.

> Now in the generated postinst snippets we have some down there
>   update-texmf-config updmap
> which in turn calls 
>   dpkg-trigger texmf-updmap

> Now when doing 
>   dpkg-reconfigure one-of-the-font-packages
> I get
>   dpkg-trigger: dpkg-trigger must be called from a maintainer script (or 
> with a --by-package option)

> I though well, yes, it is called from a maintainer script (postinst configure)
> and the package should be clear. But why does dpkg-trigger complain?

> Thanks for any explanation

Because dpkg-reconfigure calls the maintainer scripts directly, not by way
of dpkg, and as a result the DPKG_MAINTSCRIPT_PACKAGE variable is not set.

I think this should be regarded as a bug in dpkg-reconfigure.

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


signature.asc
Description: Digital signature

Re: defaulting to net.ipv6.bindv6only=1 for squeeze

[Marco d'Itri]

On Dec 10, Roman Mamedov  wrote:

> Marco, by making this change I assume you offer your personal help in dealing
> with its consequences? Please feel free to submit a fix to #560137, thanks in
> advance.
I provided the usual workaround, but the "correct" solution would be to
open two sockets.

BTW, the maintainers of the affected packages should remember that they
need to be fixed anyway to correctly work on the kfreebsd ports.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: dpkg-trigger complains at dpkg-reconfigure time

[Raphael Hertzog]

On Thu, 10 Dec 2009, Norbert Preining wrote:
> I though well, yes, it is called from a maintainer script (postinst configure)
> and the package should be clear. But why does dpkg-trigger complain?

Because the postinst is called by dpkg-reconfigure (of debconf) and it
doesn't set the same environment variables that dpkg does set when
it calls the postinst by itself. In particular DPKG_MAINTSCRIPT_PACKAGE
is missing.

(dpkg does also set DPKG_MAINTSCRIPT_ARCH and DPKG_RUNNING_VERSION)

It's a bug in dpkg-reconfigure, please file it or reassign.

Cheers,
-- 
Raphaël Hertzog


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

Re: dpkg-trigger complains at dpkg-reconfigure time

[Norbert Preining]

reassign 560317 dpkg
retitle 560317 dpkg-reconfigure does not set DPKG_MAINTSCRIPT_PACKAGE (et al)
thanks

On Do, 10 Dez 2009, Steve Langasek wrote:
> I think this should be regarded as a bug in dpkg-reconfigure.

On Do, 10 Dez 2009, Raphael Hertzog wrote:
> It's a bug in dpkg-reconfigure, please file it or reassign.


Ok, thanks, reassigned and retitled. Thanks for the quick answer.

Best wishes

Norbert

Norbert Preiningprein...@{jaist.ac.jp, logic.at, debian.org}
JAIST, JapanTU Wien, Austria   Debian TeX Task Force
DSA: 0x09C5B094   fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094

WETWANG (n.)
A moist penis.
--- Douglas Adams, The Meaning of Liff


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

Re: dpkg-trigger complains at dpkg-reconfigure time

[Steve Langasek]

reassign 560317 debconf
thanks

On Thu, Dec 10, 2009 at 04:27:28PM +0100, Norbert Preining wrote:
> reassign 560317 dpkg
> retitle 560317 dpkg-reconfigure does not set DPKG_MAINTSCRIPT_PACKAGE (et al)
> thanks

> On Do, 10 Dez 2009, Steve Langasek wrote:
> > I think this should be regarded as a bug in dpkg-reconfigure.

> On Do, 10 Dez 2009, Raphael Hertzog wrote:
> > It's a bug in dpkg-reconfigure, please file it or reassign.

> Ok, thanks, reassigned and retitled. Thanks for the quick answer.

Er, as stated, dpkg-reconfigure is not from dpkg.  Reassigning.

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


signature.asc
Description: Digital signature

Re: About repackaging of the ‘orig’ tarball.

[Jonathan Nieder]

Hi Charles,

Charles Plessy wrote:
> Le Tue, Dec 08, 2009 at 05:36:54PM +0100, Damien Raude-Morvan a écrit :

>> As a general guideline, generated files should be stripped from "original"
>> source tarballs.
[...]
> I personnally tend to prefer to keep the Debian ‘orig’ tarball identical to 
> the
> upstream tarball as much as it is possible, so that by its MD5 sum it is
> obvious that it is pristine.

Thank you for bringing this up.  I am not an ftpmaster, but maybe it
would be helpful to mention some other reasons to keep the
.orig.tar.gz pristine.

By distributing the pristine source, we provide a service to the free
software community outside of Debian.  When upstreams silently
disappear, distros take over as the main distribution point for their
software.  Similarly, sometimes the only place to find an older
version of a package is in the various distros’ archives.

Having to repack makes trouble for people trying to help package a new
upstream version.  A nice repacking script can help, but not by much.
Any potential contributer still has to figure out how it works and
make sure everything goes to plan.  Ignoring the files or deleting
them in the 'clean' target is much simpler.

Often, files the buildds do not use can be helpful for other users.
Configure scripts, source files generated by bison or web, and
processed documentation often fall into this category.  Patent-
encumbered code can sometimes, too.

On the other hand, some files in the upstream tarball really may be
useless for everybody.  This should be fixed upstream!  Having to
maintain a repacking script over several releases to work around
such a simple problem is really not a good sign for a packager
maintainer’s relationship with upstream.

The second reason above is most important to me: it is really
unpleasant to fight against repacking scripts.  If the terms of
redistribution make this trouble necessary, I grumble and bear it.
The rest of the time, I would like to avoid it.

Just my 2 cents.

Jonathan


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

Bug#560347: RFP: ncl -- Nexus Class Library

[Dirk Eddelbuettel]

Package: wnpp
Severity: wishlist

* Package name: ncl (Nexus Class Library)
  Version : 2.1.08 (dated 2009-11-30)
  Upstream Author : Paul O. Lewis
* URL or Web page : http://hydrodictyon.eeb.uconn.edu/ncl/
* License : GPL-2
  Description : Nexus Class Library
   The NEXUS Class Library (NCL) is an integrated collection of C++ classes
   designed to allow the user to quickly write a program that reads
   NEXUS-formatted data files. It also allows easy extension of the NEXUS format
   to include new blocks of your own design.
   .
   The NEXUS data file format was specified in the publication cited
   below. Please read this paper for further information about the format
   specification itself; the documentation for the NCL does not attempt to
   explain the structure of a NEXUS data file.
   Maddison, D. R., D. L. Swofford, and Wayne P. Maddison. 1997. NEXUS: an
   extensible file format for systematic information. Systematic Biology 46(4):
   590-621.
   .
   The basic goal of the NCL is to provide a relatively easy way to endow a
   C++ program with the ability to read NEXUS data files. The steps necessary
   to use the NCL to create a bare-bones program that can read a NEXUS data
   file are simple and few, and it is hoped that the availability of this
   class library will encourage the use of the NEXUS format. This will in
   turn encourage consistency in how programs read NEXUS files and how
   programs respond to errors in data files.
   .
   There are a large number of special data file formats in use. This places
   an extra burden on the end user, who must deal with an increasing number
   of file formats all differing in a number of ways. To convert one's data
   file to another file format often involves manual manipulation of the
   data, an activity that is inherently dangerous and probably has resulted
   in the corruption of many data files. At the very least, the large number
   of formats in existance has led to a proliferation of data file
   variants. With many copies of a given data file on a hard disk, each
   formatted differently for various analysis programs, it becomes very easy
   to change one (say, correct a datum found to be in error) and then fail to
   correct the other versions. The NEXUS file format provides a means for
   keeping one master copy of the data and using it with several programs
   without modification. The NCL provides a means for encouraging programmers
   to use the NEXUS file format in future programs they write.


I could use that for some R packaging (of 'phylobase'), but as I don't use
this directly I don't really want to be / should be the maintainer.

Any biologists in the readership who would like to work on this?

Dirk

-- 
Three out of two people have difficulties with fractions.



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

Re: About repackaging of the ???orig??? tarball.

[Andreas Tille]

On Thu, Dec 10, 2009 at 10:28:44AM -0600, Jonathan Nieder wrote:
> By distributing the pristine source, we provide a service to the free
> software community outside of Debian.

I do not agree to this general statement.  Sometimes the service to
write a proper makefile which generates autogenerated content and cleans
it up in a proper clean target is a way better service to the free
software community rather than copying tarballs containing a lot of
unneeded stuff.  I don't say that repackaging is a good thing in general
but your statement is not generally valid without looking at the tarball
in question.

> Often, files the buildds do not use can be helpful for other users.
> Configure scripts, source files generated by bison or web, and
> processed documentation often fall into this category.  Patent-
> encumbered code can sometimes, too.

What about .svn / .CVS directories and large chunks of binary data
(object files, libraries, executables for different architectures)?

> On the other hand, some files in the upstream tarball really may be
> useless for everybody.  This should be fixed upstream!

This is really true.  Any reason you see to repack the upstream
source should be discussed with upstream first.  I have some kind
of a 50% acceptance rate in the cases I tried.

> The second reason above is most important to me: it is really
> unpleasant to fight against repacking scripts.  If the terms of
> redistribution make this trouble necessary, I grumble and bear it.
> The rest of the time, I would like to avoid it.

... as you try to avoid any work which should not be needed.

Kind regards

 Andreas.

-- 
http://fam-tille.de


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

Bug#560367: ITP: libdesktop-agnostic -- A desktop-agnostic library for GLib-based projects

[Julien Lavergne]

Package: wnpp
Severity: wishlist
Owner: Julien Lavergne 

* Package name: libdesktop-agnostic
  Version : 0.0.1~bzr383
  Upstream Author : Mark Lee 
* URL : https://launchpad.net/libdesktop-agnostic
* License : LGPL 2+, GPL 2+
  Programming Lang: Vala
  Description : A desktop-agnostic library for GLib-based projects

This library provides an extensible configuration API, a unified virtual file
system API, and a desktop item editor (all with pluggable backends) for
GLib-based projects. It is not tied to any one desktop environment, although
there are desktop-specific modules.

libdesktop-agnostic is a depends of the next version of Awn 
(avant-window-navigator).



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

Re: defaulting to net.ipv6.bindv6only=1 for squeeze

[Wouter Verhelst]

On Sat, Oct 24, 2009 at 08:24:31PM +0200, Marco d'Itri wrote:
> I am proposing to set net.ipv6.bindv6only=1 by default for new
> installations, to simplify configuration and administration of systems
> using IPv6 and to make the system behaviour match the one of all other
> operating systems, which default to this or just do not provide a
> choice.

I'm a bit late to the party, but...

Can you explain (or give pointers to an explanation) what the
argumentation here is? How does not adhering to relevant standards
simplify configuration?

I'm sure I'm missing something here, just dunno what.

TIA,

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


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

Re: dpkg-trigger complains at dpkg-reconfigure time

[Joey Hess]

Raphael Hertzog wrote:
> Because the postinst is called by dpkg-reconfigure (of debconf) and it
> doesn't set the same environment variables that dpkg does set when
> it calls the postinst by itself. In particular DPKG_MAINTSCRIPT_PACKAGE
> is missing.
> 
> (dpkg does also set DPKG_MAINTSCRIPT_ARCH and DPKG_RUNNING_VERSION)
> 
> It's a bug in dpkg-reconfigure, please file it or reassign.

Does it actually make sense for dpkg-trigger to see those environment
variables when the postinst is not being run by dpkg? Seems possible that
any deferred trigger processing it then sets up will not take effect until
the next dpkg run, which could be well after dpkg-reconfigure finishes.

Perhaps dpkg-reconfigure needs to call dpkg --configure --pending ?

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#560401: O: libpkg-guide -- Debian Library Packaging guide

[Sandro Tosi]

Package: wnpp
Severity: normal

I intend to orphan the libpkg-guide package. Once I packaged it, taking the
great doc from Junichi, I had hoped to invest time in expoling the shlibs world
and keep this package up-to-date. Interests followed a different path, so it's
just honest to declare my failure at this and hand the package to someone else.

Whoever will adopt this package should be a skilled libs guy(s) and able to keep
it updated, so that people badly maintaining libs can be pointed to this
package.

Also, it would be nice if the generated HTML pages can live somewhere under
www.d.o .

The package description is:
 This guide tries to illustrate and illuminate the problems related to
 library packaging to be clear to the Developers of Debian Project, to
 hopefully raise the general awareness, and to fill the gap of Debian
 documentation lacking in the direction of library package.



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

Re: About repackaging of the ‘orig’ tarball.

[Joerg Jaspert]

On 11960 March 1977, Charles Plessy wrote:

> In the following message sent on debian-devel
> (<20091209003633.gb29...@kunpuu.plessy.org>), it has been suggested that we
> repack upstream original source archives when they contain generated files in
> order to ease your work. Can you confirm or infirm whether you have a
> preference?

No preference.
Also, there are various kinds of those files:
 - For the autocrap generated ones, you sure want to keep them.
 - The java .jars (or similar kind of) you want to make sure you rebuild
   them. If you have to repack anyways, then kick em out makes the whole
   thing more clear, but if not, noone will force you. Just make sure you
   do not use those that are in the tarball.
 - For things like .dll/.exe/whatever windows/mac/whateverothersystem
   binary files - if they take up lots of space it is much better to
   remove them. We have no use of em anyways.

Of course for all of them, even if not rebuilt due to not being
installed in .deb, make sure that the source to rebuilt them is there.

-- 
bye, Joerg
[...] could be redistributed free (as in "free bear") [...]


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

Re: Bug#559761: ITP: release -- provides information about the current releases

[Benjamin Drung]

Am Mittwoch, den 09.12.2009, 09:34 +0800 schrieb Paul Wise:
> On Wed, Dec 9, 2009 at 8:07 AM, Benjamin Drung  wrote:
> > Am Montag, den 07.12.2009, 09:03 +0100 schrieb Frank Lin PIAT:
> >> On Mon, 2009-12-07 at 00:14 +0100, Benjamin Drung wrote:
> >> > For Debian I need some informations: Until when were following
> >> > releases supported: buzz, rex, bo, hamm, slink, and potato?
> >>
> >> See http://wiki.debian.org/DebianReleases but I didn't/couldn't find the
> >> information for bo/rex/buzz. Anyone ?
> >
> > I found that page, too. The wikipedia page of Debian did not contain
> > more information.
> 
> Try the debian-history package or its maintainer.

I could not find information about the support period in this package.
Bdale, do you have more information?

Am Mittwoch, den 09.12.2009, 15:05 +0100 schrieb Javier Fernandez-Sanguino: 
> The proper source for this information is the Project History
> document, available online at
> http://www.debian.org/doc/manuals/project-history/ch-releases.en.html
> or in the debian-history package.

I could not find end of live dates on this website.

-- 
Benjamin Drung
Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org)


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: Bug#559761: ITP: release -- provides information about the current releases

[Benjamin Drung]

To sum up the naming discussion, there are two possible package names:

* distro-release-info
* release-info

The two distro-specific script will be named debian-release-info and
ubuntu-release-info. I tend to name the package distro-release-info and
the symlinked script release-info.

Any preferences, suggestions, or objections?

-- 
Benjamin Drung
Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org)


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Bug#560410: ITP: alsoft-conf -- OpenAL-Soft configuration utility

[Matias D'Ambrosio]

Package: wnpp
Severity: wishlist
Owner: "Matias D'Ambrosio" 


* Package name: alsoft-conf
  Version : 1.4.3
  Upstream Author : Matias D'Ambrosio 
* URL : http://www.anduin.net/~angasule/
* License : GPL2
  Programming Lang: C++
  Description : OpenAL-Soft configuration utility

An easy to use GUI tool to configure OpenAL-Soft.



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

Re: DEP-5: removed files

[Charles Plessy]

Le Tue, Dec 08, 2009 at 09:56:29AM +0900, Charles Plessy a écrit :
> Le Mon, Dec 07, 2009 at 12:26:52AM -0800, Steve Langasek a écrit :
> > On Wed, Dec 02, 2009 at 03:56:51PM +0100, Thibaut Paumard wrote:
> > 
> > > I remember that debian/copyright should not only list where the
> > > source was downloaded from, but also the files which were removed by
> > > the packager and the motivation for the removal (DFSG, patents,
> > > large convenience copy of a library...). At least, that's how I
> > > interpret this (from [1], I cannot find an excerpt from policy):
> > 
> > This is not a requirement of Debian Policy; there are two other ways that
> > Policy already recommends communicating this information:

[…]

> > Given that Policy says to put this elsewhere than debian/copyright, I don't
> > think it makes sense for DEP-5 to specify such sections; this is probably
> > better addressed by including support for free-form comments, as suggested
> > elsewhere.

Dear all,

while checking the section 6.7.8.2 of the Developers reference (“Repackaged
upstream source”) in the context on another thread on this list
(http://lists.debian.org/msgid-search/d921045c2e3ae5ecfba088e9d82eb...@drazzib.com),
I found the following :

  A repackaged .orig.tar.gz
  
 1. should be documented in the resulting source package. Detailed
information on how the repackaged source was obtained, and on how this 
can be
reproduced should be provided in debian/copyright. It is also a good 
idea to
provide a get-orig-source target in your debian/rules file that repeats 
the
process, as described in the Policy Manual, Main building script: 
debian/rules. 

I have no strong opinion on the subject, but I think that either the Developers
Reference should be modified to reflect current consensus and practice, or in
contrary the section 6.7.8.2 of the Dev. Ref. argues for the incorporation of
the removing information in the DEP-5 machine-readable format.

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


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

Re: defaulting to net.ipv6.bindv6only=1 for squeeze

[Marco d'Itri]

On Dec 10, Wouter Verhelst  wrote:

> Can you explain (or give pointers to an explanation) what the
> argumentation here is? How does not adhering to relevant standards
> simplify configuration?
There is no relevant standard that says what the default of IPV6_V6ONLY
should be. Currently what happens is that every OS except Linux and OS X
default to 1.
An important point is that the kfreebsd ports only support a default of
1, so these buggy programs need to be fixed anyway to work correctly on
them.

Among the benefits of using different sockets for IPv4 and IPv6 there is
the ability of running two different daemons for v4 and v6 on the same
port and simpler code, removing the need for making IPv6-mapped IPv4
addresses behave like real IPv4 addresses in logs, configuration files
and so on.

I have no objections to reverting this change in time for the release if
there are too many programs to be fixed, but so far I believe that the
results are very encouraging.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Work-needing packages report for Dec 11, 2009

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 650 (new: 2)
Total number of packages offered up for adoption: 131 (new: 0)
Total number of packages requested help for: 54 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   libmtp (#560098), orphaned 2 days ago
 Description: Media Transfer Protocol (MTP) library
 Reverse Depends: amarok audacious-plugins-dev
   audacious-plugins-extra banshee gnomad2 libmtp-dev mtp-tools mtpfs
   python-pymtp rhythmbox
 Installations reported by Popcon: 9426

   libpkg-guide (#560401), orphaned today
 Description: Debian Library Packaging guide
 Installations reported by Popcon: 33

648 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



No new packages have been given up for adoption, but a total of 131 packages
are awaiting adoption.  See http://www.debian.org/devel/wnpp/rfa_bypackage
for a complete list.



For the following packages help is requested:

   apt-cross (#540341), requested 125 days ago
 Description: retrieve, build and install libraries for
   cross-compiling
 Reverse Depends: apt-cross emdebian-buildsupport emdebian-qa
   emdebian-rootfs emdebian-tools libemdebian-tools-perl
 Installations reported by Popcon: 317

   ara (#450876), requested 760 days ago
 Description: utility for searching the Debian package database
 Installations reported by Popcon: 111

   asymptote (#517342), requested 286 days ago
 Description: script-based vector graphics language inspired by
   MetaPost
 Installations reported by Popcon: 1175

   athcool (#278442), requested 1871 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 167

   boinc (#511243), requested 336 days ago
 Description: BOINC distributed computing
 Reverse Depends: boinc-app-milkyway boinc-app-seti boinc-dbg
 Installations reported by Popcon: 1645

   cvs (#354176), requested 1386 days ago
 Description: Concurrent Versions System
 Reverse Depends: crossvc cvs-autoreleasedeb cvs-buildpackage cvs2cl
   cvs2html cvschangelogbuilder cvsconnect cvsd cvsps cvsservice (10
   more omitted)
 Installations reported by Popcon: 25101

   dctrl-tools (#448284), requested 775 days ago
 Description: Command-line tools to process Debian package
   information
 Reverse Depends: aptfs debian-goodies debtree dlocate
   haskell-devscripts libsbuild-perl linux-patch-debianlogo mlmmj
   simple-cdd ubuntu-dev-tools
 Installations reported by Popcon: 13373

   dietlibc (#544060), requested 104 days ago
 Description: diet libc - a libc optimized for small size
 Reverse Depends: libowfat-dev
 Installations reported by Popcon: 233

   dpkg (#282283), requested 1845 days ago
 Description: dselect: a user tool to manage Debian packages
 Reverse Depends: adacontrol advi advi-examples alien alqalam
   alsa-source am-utils-doc apt-build apt-cross apt-src (441 more
   omitted)
 Installations reported by Popcon: 89369

   elvis (#432298), requested 885 days ago
 Description: powerful clone of the vi/ex text editor (with X11
   support)
 Reverse Depends: elvis elvis-console elvis-tools
 Installations reported by Popcon: 402

   emdebian-tools (#540333), requested 125 days ago
 Description: emdebian crossbuilding tool set
 Reverse Depends: emdebian-buildsupport emdebian-qa emdebian-rootfs
   emdebian-tools
 Installations reported by Popcon: 182

   flightgear (#487388), requested 537 days ago
 Description: Flight Gear Flight Simulator
 Installations reported by Popcon: 654

   fluxbox (#552328), requested 46 days ago
 Description: Highly configurable and low resource X11 Window manager
 Reverse Depends: bbmail
 Installations reported by Popcon: 3124

   gentoo (#422498), requested 949 days ago
 Description: a fully GUI-configurable, two-pane X file manager
 Installations reported by Popcon: 231

   gnat-4.4 (#539562), requested 609 days ago
 Description: help needed to execute test cases
 Reverse Depends: adabrowse adacontrol asis-programs gnat gnat-4.4
   libasis2008 libasis2008-dev libaunit1-dev libaunit3 libgnadecommon1
   (21 more omitted)
 Installations reported by Popcon: 96

   gnat-gps (#496905), requested 469 days ago
 Description: co-maintainer needed
 Installations reported by Popcon: 170

   grub2 (#248397), requested 2040 days ag

Re: defaulting to net.ipv6.bindv6only=1 for squeeze

[Eduard Bloch]

#include 
* Marco d'Itri [Fri, Dec 11 2009, 12:23:36AM]:
> On Dec 10, Wouter Verhelst  wrote:
> 
> > Can you explain (or give pointers to an explanation) what the
> > argumentation here is? How does not adhering to relevant standards
> > simplify configuration?
> There is no relevant standard that says what the default of IPV6_V6ONLY
> should be. Currently what happens is that every OS except Linux and OS X
> default to 1.
> An important point is that the kfreebsd ports only support a default of
> 1, so these buggy programs need to be fixed anyway to work correctly on
> them.

From my POV as programmer it's a good change. The old behaviour (i.e.
silent creation of v4 mapped sockets) maybe made the porting (to
Linux/OS-X) of very simple network daemons easier but when you tried to
make the local address binding more flexible then things became PITA.

I.e. if you use getaddrinfo output then you need to sort out v6 sockets
out and connect on them, but then you cannot be sure about whether v4
mapping is active. You can test it by trial-and-error (binding on v4
versions and checking the results) but then you cannot be sure that they
are bound to you now (at least not without using ugly tricks).

> I have no objections to reverting this change in time for the release if
> there are too many programs to be fixed, but so far I believe that the
> results are very encouraging.

Maybe because most programmes already got burned by the problems
described above and don't rely on transparent v4 mapping anymore (IIRC I
had to fix some code last year when getaddrinfo output changed the
sort order, some assumptions in the code didn't work).

Regards,
Eduard.

-- 
 Alfie: ;) naja, wir sind nicht in Redm wo man den teppich
hochhebt und den besen auspackt und alles drunterkehrt.
 Alfie: und das was sich dann nicht mehr unterm teppich ausgeht als
produkt deklariert und verkauft ;)


signature.asc
Description: Digital signature

Re: DEP-5: removed files

[Russ Allbery]

Charles Plessy  writes:

> while checking the section 6.7.8.2 of the Developers reference
> (“Repackaged upstream source”) in the context on another thread on this
> list
> (http://lists.debian.org/msgid-search/d921045c2e3ae5ecfba088e9d82eb...@drazzib.com),
> I found the following :

>   A repackaged .orig.tar.gz
>   
>  1. should be documented in the resulting source package. Detailed
>  information on how the repackaged source was obtained, and on how
>  this can be reproduced should be provided in debian/copyright. It
>  is also a good idea to provide a get-orig-source target in your
>  debian/rules file that repeats the process, as described in the
>  Policy Manual, Main building script: debian/rules.

> I have no strong opinion on the subject, but I think that either the
> Developers Reference should be modified to reflect current consensus and
> practice, or in contrary the section 6.7.8.2 of the Dev. Ref. argues for
> the incorporation of the removing information in the DEP-5
> machine-readable format.

I personally still believe this information belongs in debian/copyright,
not in README.source.  README.source might be appropriate if there are
detailed instructions required for how someone else would create a new
upstream source tarball, but debian/copyright is the appropriate location
to describe the provenance of the upstream tarball, which in my opinion
should include a human-readable description of transformations applied to
it.

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


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

Re: defaulting to net.ipv6.bindv6only=1 for squeeze

[Russ Allbery]

Eduard Bloch  writes:
> #include 
> * Marco d'Itri [Fri, Dec 11 2009, 12:23:36AM]:

>> There is no relevant standard that says what the default of IPV6_V6ONLY
>> should be. Currently what happens is that every OS except Linux and OS
>> X default to 1.  An important point is that the kfreebsd ports only
>> support a default of 1, so these buggy programs need to be fixed anyway
>> to work correctly on them.

> From my POV as programmer it's a good change. The old behaviour (i.e.
> silent creation of v4 mapped sockets) maybe made the porting (to
> Linux/OS-X) of very simple network daemons easier but when you tried to
> make the local address binding more flexible then things became PITA.

Agreed.

> I.e. if you use getaddrinfo output then you need to sort out v6 sockets
> out and connect on them, but then you cannot be sure about whether v4
> mapping is active. You can test it by trial-and-error (binding on v4
> versions and checking the results) but then you cannot be sure that they
> are bound to you now (at least not without using ugly tricks).

Yes, exactly.  You end up having to add a bunch of code to special-case
IPv4-mapped addresses in annoying ways, and that code isn't always tested
because other OSes don't do this dual-binding.

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


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

Re: Bug#560216: Missing symbol HEIMDAL_KRB5_1.0

[Richard A Nelson]

On Thu, 10 Dec 2009, Brian May wrote:


What do I do about this issue:

On Wed, Dec 09, 2009 at 09:07:45PM +0100, Guido Günther wrote:

$ krb5-auth-dialog -A
krb5-auth-dialog: /usr/lib/libkrb5.so.25: version `HEIMDAL_KRB5_1.0' not found 
(required by krb5-auth-dialog)


If I look through the library with objdump, I see HEIMDAL_KRB5_2.0 defined not
HEIMDAL_KRB5_1.0.


libpam-heimdal is in the same boat - completely hosing any box with an
upgraded heimdal.


My guess is that upstream have increased the version number of the library
versioned symbols, but did not increase the soname number. Is this wrong?
It feels wrong to me.


The heimdal (and reverse-depends) package dependencies are pretty much
useless ...  Rolling back from the unstable version to the prior working
heimdal was a royal pita; when it seems like it should've been
sufficient to 'aptitude install heimdal-/testing', instead I had to
generate a transitive closure of the dependencies and manually select
them all - meaning they're now 'manually installed'


Is this something I should be reporting back to upstream?


I'd think a rebuild of the debian package providing krb5-auth-dialog
against current Debian Heimdal packages would suffice.


Thanks.


Good luck with this.   When I installed heimdal, it was the only choice
that allowed me to utilize the existing LDAP db - which has alot of
benefits... I may reconsider, if MIT's LDAP support is reasonable
There just doesn't seem to be a good way to keep the MIT and HEIMDAL
versions of some important packages in sync :(

--
Rick Nelson
"...very few phenomena can pull someone out of Deep Hack Mode, with two
noted exceptions: being struck by lightning, or worse, your *computer*
being struck by lightning."
(By Matt Welsh)

Re: Bug#560216: Missing symbol HEIMDAL_KRB5_1.0

[Russ Allbery]

Richard A Nelson  writes:

> Good luck with this.  When I installed heimdal, it was the only choice
> that allowed me to utilize the existing LDAP db - which has alot of
> benefits... I may reconsider, if MIT's LDAP support is reasonable
> There just doesn't seem to be a good way to keep the MIT and HEIMDAL
> versions of some important packages in sync :(

With the existence of heimdal-multidev, we're getting closer.  In fact,
that may be enough, although having libkrb5-multidev as well would be
good.  I need to talk about the libpam-heimdal maintainer about the
libpam-krb5 package taking it over and building both using the multidev
environment.

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


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

Re: licensecheck and debian/copyright

[Charles Plessy]

Le Thu, Dec 10, 2009 at 01:56:20AM +, Dmitrijs Ledkovs a écrit :
> 
> There isn't DEB-5 debian/copyright parser available. So this cannot be
> implemented in licensecheck yet.

Dear Dmitrijs,

Jon Dowland has published an example parser on this list
(http://lists.debian.org/msgid-search/20090913225846.gb16...@tchicaya.lan).
However, it is written in Python and is therefore of a little help for
licensecheck, written in Perl.

On my side, I have started to work on a parser for the relaxed syntax I propose
on my exprimental git branch of the DEP
(http://git.debian.org/?p=users/plessy/license-summary.git;a=blob_plain;f=dep5.mdwn).

In that case, it is as simple as:

 - Process paragraphs – separated by an empty line – one by one.
 - Collapse paragraphs in a hash where keys are field names, ignoring
   paragraphs that do not contain fields.

This results in an array of hashes, or in YAML dialect, a sequence of mappings.

$/ = undef;
my @paragraphs = split (/\n\n/, <>);   # Split on empty lines
my @parsed;
my $counter = 0;

foreach my $paragraph (@paragraphs) {
if (my $collapsed = collapse($paragraph)) { # Collapse each paragraph 
in a hash
$parsed[$counter++] = $collapsed;
}
}

sub collapse {
my $paragraph = shift;
my %hash;
my $current_field = 0;# Next line may still be part of 
the field content.
my @lines = split (/\n/, $paragraph);
foreach (@lines) {
if ( /^(\w+)\s*:\s*(.*)$/ ) {  # New fields terminate the previous 
one.
$current_field = $1;
$hash{$1} .= "$2";
} elsif ( /^\s(.*)$/ ) {
$hash{$current_field} .= "\n$1" if $current_field;
} else {
$current_field = 0; # Lack of indentation also terminate the 
field.
}
}
return \%hash if keys(%hash);
}

The above script still has bugs, but I hope it summarises how easy it could be
to write a parser if the DEP is constructed with this as a goal.


I originally proposed a syntax that is not the same as Debian control files,
but currently I am still dissatisfied even by my proposition. With whichever
format, it is easy to break the syntax, in particular by forgetting white space
for indentation, or the ‘space-dot’ escape sequence for the empty lines in the
‘Debian control’ syntax. From my frustrating experience when adding by hand the
contents of the artistic v2.0 license to the debian/copyright file from one of
the packages I maintain, I concluded that it can significantly impair the
adoption of DEP-5. So on this list or elsewhere, I think that there is still
some experimentation and concertation to do.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


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

Re: Bug#560216: Missing symbol HEIMDAL_KRB5_1.0

[Brian May]

On Thu, Dec 10, 2009 at 08:19:00PM -0800, Richard A Nelson wrote:
> libpam-heimdal is in the same boat - completely hosing any box with an
> upgraded heimdal.

Everything compiled against libkrb5 in heimdal will be affected.

> >My guess is that upstream have increased the version number of the library
> >versioned symbols, but did not increase the soname number. Is this wrong?
> >It feels wrong to me.
> 
> The heimdal (and reverse-depends) package dependencies are pretty much
> useless ...  Rolling back from the unstable version to the prior working
> heimdal was a royal pita; when it seems like it should've been
> sufficient to 'aptitude install heimdal-/testing', instead I had to
> generate a transitive closure of the dependencies and manually select
> them all - meaning they're now 'manually installed'

It works for me, although this was a very simple test case:

sys11:/home/brian# apt-get install libkrb5-25-heimdal/testing
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Selected version 1.2.e1.dfsg.1-4 (Debian:testing) for libkrb5-25-heimdal
The following packages were automatically installed and are no longer required:
  libidn11 libcurl3-gnutls cpio ca-certificates openssl
Use 'apt-get autoremove' to remove them.
The following extra packages will be installed:
  libhx509-4-heimdal libkrb5-25-heimdal
The following NEW packages will be installed:
  libhx509-4-heimdal
The following packages will be DOWNGRADED:
  libkrb5-25-heimdal
0 upgraded, 1 newly installed, 1 downgraded, 0 to remove and 3 not upgraded.
Need to get 523kB of archives.
After this operation, 664kB of additional disk space will be used.
Do you want to continue [Y/n]? y
Get:1 http://hq.in.vpac.org sid/main libhx509-4-heimdal 1.2.e1.dfsg.1-5 [125kB]
Get:2 http://hq.in.vpac.org testing/main libkrb5-25-heimdal 1.2.e1.dfsg.1-4 
[398kB]
Fetched 523kB in 0s (1184kB/s)  
debconf: delaying package configuration, since apt-utils is not installed
Selecting previously deselected package libhx509-4-heimdal.
(Reading database ... 12277 files and directories currently installed.)
Unpacking libhx509-4-heimdal (from 
.../libhx509-4-heimdal_1.2.e1.dfsg.1-5_i386.deb) ...
dpkg: warning: downgrading libkrb5-25-heimdal from 1.3.1.dfsg.1-4 to 
1.2.e1.dfsg.1-4.
Preparing to replace libkrb5-25-heimdal 1.3.1.dfsg.1-4 (using 
.../libkrb5-25-heimdal_1.2.e1.dfsg.1-4_i386.deb) ...
Unpacking replacement libkrb5-25-heimdal ...
Setting up libhx509-4-heimdal (1.2.e1.dfsg.1-5) ...
Setting up libkrb5-25-heimdal (1.2.e1.dfsg.1-4) ...

> >Is this something I should be reporting back to upstream?
> 
> I'd think a rebuild of the debian package providing krb5-auth-dialog
> against current Debian Heimdal packages would suffice.

I have talked to upstream (see bug #560357), and they acknowledged
they forgot to increase the soname version.

This is the correct solution, one that doesn't break older packages.
-- 
Brian May 


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

Re: dpkg-trigger complains at dpkg-reconfigure time

[Raphael Hertzog]

On Thu, 10 Dec 2009, Joey Hess wrote:
> Raphael Hertzog wrote:
> > Because the postinst is called by dpkg-reconfigure (of debconf) and it
> > doesn't set the same environment variables that dpkg does set when
> > it calls the postinst by itself. In particular DPKG_MAINTSCRIPT_PACKAGE
> > is missing.
> > 
> > (dpkg does also set DPKG_MAINTSCRIPT_ARCH and DPKG_RUNNING_VERSION)
> > 
> > It's a bug in dpkg-reconfigure, please file it or reassign.
> 
> Does it actually make sense for dpkg-trigger to see those environment
> variables when the postinst is not being run by dpkg? Seems possible that
> any deferred trigger processing it then sets up will not take effect until
> the next dpkg run, which could be well after dpkg-reconfigure finishes.

Right.

> Perhaps dpkg-reconfigure needs to call dpkg --configure --pending ?

Indeed, it's probably a good idea. Or maybe: "dpkg --triggers-only
--pending" (but reading the doc I'm not sure if --configure is not
better).

Guillem, does --triggers-only bring the package back to configured
if they were in that state before the trigger registration ?

Cheers,
-- 
Raphaël Hertzog


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