Raphael Hertzog writes:
> Hi,
>
> On Thu, 16 May 2013, Felix Natter wrote:
>> Eric (the previous packager) installed this file as
>> /usr/share/doc/freeplane/history_en.txt.gz, which seems ok. But how
>> should I deal with the no-upstream-changelog lintian warning?
&
Hi,
On Thu, 16 May 2013, Felix Natter wrote:
> Eric (the previous packager) installed this file as
> /usr/share/doc/freeplane/history_en.txt.gz, which seems ok. But how
> should I deal with the no-upstream-changelog lintian warning?
Pass "history_en.txt" to dh_installchangelog
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
Le 16/05/2013 15:11, Felix Natter a écrit :
> hi,
>
> the package freeplane does not contain an upstream changelog but
> does contain a high-level change history:
>
>
hi,
the package freeplane does not contain an upstream changelog but does
contain a high-level change history:
===
1.2.23
===
Bug fix for dragging of nodes when node tool tip is shown
===
1.2.22
2013/5/14 Emmanuel Bourg :
> Hi all,
>
> I'm updating several Java packages where the source package generates
> two binaries, libfoo-java with the compiled jars and libfoo-java-doc
> with the documentation. Lintian often complains about the missing
> upstream changelog
Hi all,
I'm updating several Java packages where the source package generates
two binaries, libfoo-java with the compiled jars and libfoo-java-doc
with the documentation. Lintian often complains about the missing
upstream changelog (no-upstream-changelog). Should I put the changelog
in
tarball from the next release on, but in the mean time just don't
> worry about it, I don't think any potential sponsor will hold that
> against you.
I'd ship the upstream changelog inside your packaging instead.
--
Copyright and patents were never about promoting culture and i
Hi !
On 17/07/12 10:24, Simon Chopin wrote:
Quoting Jerome BENOIT (2012-07-17 10:11:16)
Hello List:
Hi,
I am package a library from scratch.
The upstream source package contains no changelog file,
but the library website provides matter to extract one for it.
I guess that I may have to ex
Quoting Jerome BENOIT (2012-07-17 10:11:16)
> Hello List:
Hi,
>
> I am package a library from scratch.
> The upstream source package contains no changelog file,
> but the library website provides matter to extract one for it.
>
> I guess that I may have to extract the changelog file from the we
Hello List:
I am package a library from scratch.
The upstream source package contains no changelog file,
but the library website provides matter to extract one for it.
I guess that I may have to extract the changelog file from the website:
may I forget it ?
is there any tool to do so ?
Any hin
Hello List:
On 11/02/12 22:56, Don Armstrong wrote:
On Sat, 11 Feb 2012, Jerome BENOIT wrote:
The upstream changelog of my package is in LaTeX format: as the
LaTeX is rough enough to be translated to HTML format by TtH, I will
put the HTML translation within the package. Given that, what I
On Sat, 11 Feb 2012, Jerome BENOIT wrote:
> The upstream changelog of my package is in LaTeX format: as the
> LaTeX is rough enough to be translated to HTML format by TtH, I will
> put the HTML translation within the package. Given that, what I am
> supposed to do with the LaTeX chan
Hello List:
The upstream changelog of my package is in LaTeX format:
as the LaTeX is rough enough to be translated to HTML format by TtH,
I will put the HTML translation within the package.
Given that, what I am supposed to do with the LaTeX changelog source ?
May I put it within the package as
Hi !
On 24/01/12 10:30, Rupert Swarbrick wrote:
Jerome BENOIT writes:
Is there a better way to deal with this `Changes.xml' ?
I guess that I can add some stuff in the makefile to convert it in text
format:
do specific tools exist to convert this kind of changelog in text format ?
If I were y
Jerome BENOIT writes:
>>> Is there a better way to deal with this `Changes.xml' ?
>>> I guess that I can add some stuff in the makefile to convert it in text
>>> format:
>>> do specific tools exist to convert this kind of changelog in text format ?
>>
>> If I were you, I'd ask upstream about that
Hi !
On 24/01/12 02:57, Samuel Bronson wrote:
On Mon, Jan 23, 2012 at 8:07 PM, Jerome BENOIT wrote:
Thanks for your reply:
You're quite welcome.
On 23/01/12 19:54, Samuel Bronson wrote:
On Mon, Jan 23, 2012 at 1:08 AM, Jerome BENOIT
wrote:
Is there a better way to deal with this `Ch
On Mon, Jan 23, 2012 at 8:07 PM, Jerome BENOIT wrote:
> Thanks for your reply:
You're quite welcome.
> On 23/01/12 19:54, Samuel Bronson wrote:
>>
>> On Mon, Jan 23, 2012 at 1:08 AM, Jerome BENOIT
>> wrote:
>>> Is there a better way to deal with this `Changes.xml' ?
>>> I guess that I can add
know
format in some `field' (even if I can not figure out which `field').
Hmm. According to policy (section 12.7 of version 3.9.2.0):
,----
| If an upstream changelog is available, it should be accessible as
| `/usr/share/doc//changelog.gz' in plain text. If th
well know
> format in some `field' (even if I can not figure out which `field').
Hmm. According to policy (section 12.7 of version 3.9.2.0):
,
| If an upstream changelog is available, it should be accessible as
| `/usr/share/doc//changelog.gz' in plain text. If the
Hello List:
I am working on the bibtool package.
The changelog of the upstream package is in XML format and is named `Changes.xml'.
Right now, I manage it by adding an override in the debian/rules file:
override_dh_installchangelogs:
dh_installchangelogs --keep Changes.xml
Nevertheless, n
uter running Debian (and sid in a pbuilder
environment).
But, you are right: the "debhelper" changelog for Ubuntu 8.9 states
| - dh_installchangelogs: Do not install upstream changelog in compat level
| 7. This floods packages with huge upstream changelogs which take
| precious
; my upstream package has a file "CHANGELOG" which does not get installed
>>> by default. When I just include this file name into debian/docs, lintian
>>> complains about "wrong-name-for-upstream-changelog".
>>
>> If you use debhelper compat level 7 o
Ansgar Burchardt writes:
> Ole Streicher writes:
>> my upstream package has a file "CHANGELOG" which does not get installed
>> by default. When I just include this file name into debian/docs, lintian
>> complains about "wrong-name-for-upstream-changelog"
Hi,
Ole Streicher writes:
> my upstream package has a file "CHANGELOG" which does not get installed
> by default. When I just include this file name into debian/docs, lintian
> complains about "wrong-name-for-upstream-changelog".
If you use debhelper compat level 7
On Mon, 17 Oct 2011 14:36:25 +0200, Ole Streicher wrote:
Dear list,
my upstream package has a file "CHANGELOG" which does not get
installed
by default. When I just include this file name into debian/docs,
lintian
complains about "wrong-name-for-upstream-changelog".
Is t
On Mon, Oct 17, 2011 at 8:36 PM, Ole Streicher wrote:
> my upstream package has a file "CHANGELOG" which does not get installed
> by default. When I just include this file name into debian/docs, lintian
> complains about "wrong-name-for-upstream-changelog".
>
&
Dear list,
my upstream package has a file "CHANGELOG" which does not get installed
by default. When I just include this file name into debian/docs, lintian
complains about "wrong-name-for-upstream-changelog".
Is there a simple way to rename this file? Or do I need to wri
On 04/07/2011 10:46 AM, Paul Wise wrote:
> Personally I would do one of the following, in decreasing order of
> preference. You might find that whatever the PDF is built from is
> easier to convert to plain text than the PDF itself. Check in the
> Title/Producer/Creator fields of the PDF for some h
Personally I would do one of the following, in decreasing order of
preference. You might find that whatever the PDF is built from is
easier to convert to plain text than the PDF itself. Check in the
Title/Producer/Creator fields of the PDF for some hints on what might
be the source code for the PDF
Hi all
I'm in the process of packaging a library that does not contain a
ChangeLog file, but contains that information inside the user-guide
which is either available as a PDF or the LaTeX source. Using some
scripting (pdftotext, sed, asciidoc, lynx) I can extract a quite
reasonable ChangeLog file
> On Thu, Mar 17, 2011 at 02:23:01PM +0100, Michele Gastaldo
wrote:
>> > > In your debian rules file you can use:
>> > >
dh_installchangelogs -k {your_changelog_filename}
>> > >
>> > > (the -k
is to keep the upstream changelog file name and s
On Thu, 17 Mar 2011 14:23:01 +0100, Michele Gastaldo wrote:
> > "If none is specified, it looks for files with names that seem likely to be
> > changelogs. (In compatibility level 7 and above.)"
> > So explicit dh_installchangelogs doesn't need additional arguments and dh
> > tiny rules will do ev
On Thu, Mar 17, 2011 at 02:23:01PM +0100, Michele Gastaldo wrote:
> > > In your debian rules file you can use:
> > > dh_installchangelogs -k {your_changelog_filename}
> > >
> > > (the -k is to keep the upstream changelog file name and symlink it to
> > &
> On Mon, Mar 14, 2011 at 03:10:24PM -0400, Scott Howard wrote:
> > In your debian rules file you can use:
> > dh_installchangelogs -k {your_changelog_filename}
> >
> > (the -k is to keep the upstream changelog file name and symlink it to
> > changelog.gz, fee
On Mon, Mar 14, 2011 at 03:10:24PM -0400, Scott Howard wrote:
> In your debian rules file you can use:
> dh_installchangelogs -k {your_changelog_filename}
>
> (the -k is to keep the upstream changelog file name and symlink it to
> changelog.gz, feel free to drop it if you wish, it
On Mon, Mar 14, 2011 at 2:45 PM, Michele Gastaldo
wrote:
> Hi all
> Trying to package kpartsplugin (ITP: bug #597110), I get a warning from
> lintian (wrong-name-for-upstream-changelog): there's a ChangeLog file from
> upstream I listed in debian/docs, but according to the Debian
Hi all
Trying to package kpartsplugin (ITP: bug #597110), I get a warning from
lintian (wrong-name-for-upstream-changelog): there's a ChangeLog file from
upstream I listed in debian/docs, but according to the Debian Policy Manual it
should be "gzipped" in changelog.gz
My questio
On Fri, 2009-11-27 at 12:09 +0800, Paul Wise wrote:
> It might actually be best to store all this upstream data in the
> PackageMap or somewhere associated with it and map from Debian package
> -> PackageMap name -> upstream metadata.
>
> I'm also reminded of things like DOAP, which are sometime
Le Fri, Nov 27, 2009 at 12:09:47PM +0800, Paul Wise a écrit :
> On Fri, Nov 27, 2009 at 12:03 PM, Charles Plessy wrote:
>
> > Again, all of this is very preliminary and undocumented. The main message I
> > would like to give is that indeed, for all the information that is not
> > specific
> > to
Jonathan Wiltshire writes:
> On Fri, Nov 27, 2009 at 11:50:30AM +1100, Ben Finney wrote:
>> Rather, it would be good to have a facility similar to the way the
>> Debian changelog is currently available: have the upstream changelog
>> published in a predictable location by p
Jonathan Wiltshire writes:
> On Fri, Nov 27, 2009 at 11:50:30AM +1100, Ben Finney wrote:
> > Rather, it would be good to have a facility similar to the way the
> > Debian changelog is currently available: have the upstream changelog
> > published in a predictable loc
On Fri, Nov 27, 2009 at 4:55 PM, Jonathan Wiltshire
wrote:
> Where the changelog is already part of the source package and has a
> sensible name, and the package calls dh_installchangelogs, it's already
> installed as /usr/share/doc/*/changelog and the Debian changelog as
> changelog.Debian. The
On Fri, Nov 27, 2009 at 11:50:30AM +1100, Ben Finney wrote:
> Rather, it would be good to have a facility similar to the way the
> Debian changelog is currently available: have the upstream changelog
> published in a predictable location by package name.
Where the changelog is already pa
On Fri, Nov 27, 2009 at 12:03 PM, Charles Plessy wrote:
> Again, all of this is very preliminary and undocumented. The main message I
> would like to give is that indeed, for all the information that is not
> specific
> to Debian, there must be other ways to make them flow from the maintainer to
Le Fri, Nov 27, 2009 at 11:06:51AM +0800, Paul Wise a écrit :
> On Fri, Nov 27, 2009 at 9:39 AM, Charles Plessy wrote:
>
> > I propose to store this information and similar ones in a parsable file in
> > the
> > debian directory of the packages. For instance,
> > debian/upstream-metadata.yaml.
Ben Finney wrote:
> This is what I do. Rationale: The Debian changelog, unlike the upstream
> changelog, is available for all Debian packages using standard tools
> *before* installing the package, which as a user is the time I most want
> to see what has changed in a new release
On Fri, Nov 27, 2009 at 9:39 AM, Charles Plessy wrote:
> I propose to store this information and similar ones in a parsable file in the
> debian directory of the packages. For instance, debian/upstream-metadata.yaml.
> For packages stored in a VCS, this information will be easy to retreive. The
>
Le Fri, Nov 27, 2009 at 11:50:30AM +1100, Ben Finney a écrit :
>
> Rather, it would be good to have a facility similar to the way the
> Debian changelog is currently available: have the upstream changelog
> published in a predictable location by package name.
>
> A good project
Tony Houghton writes:
> Good point. Is there not a control field where you can give a URL for
> an upstream changelog?
No, I don't think such a thing belongs in the ‘control’ file. There is
significant pressure *against* adding fields to that file, since the
addition of such a field
On Fri, 27 Nov 2009 10:35:34 +1100
Ben Finney wrote:
> Tony Houghton writes:
>
> > What should go in a Debian changelog compared to the upstream
> > changelog?
>
> Well now, there's “should” and there's “should”.
>
> > (a) Confine it to "ne
Tony Houghton writes:
> What should go in a Debian changelog compared to the upstream
> changelog?
Well now, there's “should” and there's “should”.
> (a) Confine it to "new upstream release", a list of any closed debian
> bugs and packaging changes?
Of the opt
On Thu, Nov 26, 2009 at 10:29:31PM +, Tony Houghton wrote:
> What should go in a Debian changelog compared to the upstream changelog?
>
> (a) Confine it to "new upstream release", a list of any closed debian
> bugs and packaging changes?
Keep it to a minimum (that'
On Thu, Nov 26, 2009 at 10:29:31PM +, Tony Houghton wrote:
> What should go in a Debian changelog compared to the upstream changelog?
>
> (a) Confine it to "new upstream release", a list of any closed debian
> bugs and packaging changes?
>
> (b) As above plus a s
What should go in a Debian changelog compared to the upstream changelog?
(a) Confine it to "new upstream release", a list of any closed debian
bugs and packaging changes?
(b) As above plus a summary of the most important upstream changes?
(c) Details of all the upstream changes to
Russ Allbery writes:
> I always summarize major changes in a new upstream release in
> debian/changelog whether upstream provides its own changelog or not.
> It seems polite and I know as a user it makes debian/changelog more
> useful to me than a bunch of bare "New upstream release" lines when
>
Pietro Battiston writes:
> Do you suggest me to:
> - patch the changelog/introduce a new one, and then install it, or
> - in debian/changelog, after "New upstream release", list all of those
> changes?
I always summarize major changes in a new upstream release in
debian/changelog whether upstrea
Hi,
Sandro Tosi wrote:
>> P.P.S: I'm taking care of this package since few months... under
>> previous maintainer, the upstream ChangeLog was still updated
>
> That's nicer, but I don't think it's worth a hunk in diff.gz (either
> as direct change or p
ange their policy... for the next release.
>
> not 'may', just do it.
OK, done
> > P.P.S: I'm taking care of this package since few months... under
> > previous maintainer, the upstream ChangeLog was still updated
>
> That's nicer, but I don't think
rbose.
please don't. That is the *debian* changelog.
> P.S: yes, I may ask them to change their policy... for the next release.
not 'may', just do it.
> P.P.S: I'm taking care of this package since few months... under
> previous maintainer, the upstream ChangeLog was
know if ~20
lines of changelog entry for a new upstream release would be considered
too verbose.
thanks in advance for any hint
Pietro
P.S: yes, I may ask them to change their policy... for the next release.
P.P.S: I'm taking care of this package since few months... under
previous maintainer, t
On Tuesday 30 January 2007 01:54, Magnus Holmgren wrote:
> I maintain a package where the upstream author has two changelog files: A
> brief one called Changes, summarizing the changes, and a detailed one
> called ChangeLog, which contains a detailed list of changes made to the
> various source fil
. Am I wrong?
You are correct. And anyone using the NEWS.Debian file for upstream
changelog will get LARTed when someone notices the missuse. NEWS.Debian is
supposed to be used only as a extremely high signal-to-noise ratio medium
for very important announcements about package/program behaviour c
Am Dienstag, den 30.01.2007, 00:35 -0500 schrieb Justin Pryzby:
> On Tue, Jan 30, 2007 at 02:44:00AM +0100, Daniel Leidert wrote:
> > Am Dienstag, den 30.01.2007, 01:54 +0100 schrieb Magnus Holmgren:
> > > I better ask this once and for all...
> > >
> > > I maintain a package where the upstream au
Magnus Holmgren wrote:
>> This is common with Java packages built with Maven, where a detailed
>> commit log is automatically generated and included in the sources. In
>> that case I prefer to leave out the commit log altogether
> But what if Changes says "see ChangeLog for details"?
Mention of t
On Tuesday 30 January 2007 08:52, Marcus Better wrote:
> Magnus Holmgren wrote:
> > I maintain a package where the upstream author has two changelog files: A
> > brief one called Changes, summarizing the changes, and a detailed one
> > called ChangeLog, which contains a detailed list of changes mad
Magnus Holmgren wrote:
> I maintain a package where the upstream author has two changelog files: A
> brief one called Changes, summarizing the changes, and a detailed one
> called ChangeLog, which contains a detailed list of changes made to the
> various source files.
This is common with Java pack
On Tue, Jan 30, 2007 at 02:44:00AM +0100, Daniel Leidert wrote:
> Am Dienstag, den 30.01.2007, 01:54 +0100 schrieb Magnus Holmgren:
> > I better ask this once and for all...
> >
> > I maintain a package where the upstream author has two changelog files: A
> > brief one called Changes, summarizing
Am Dienstag, den 30.01.2007, 01:54 +0100 schrieb Magnus Holmgren:
> I better ask this once and for all...
>
> I maintain a package where the upstream author has two changelog files: A
> brief one called Changes, summarizing the changes, and a detailed one called
> ChangeLog, which contains a det
On 1/29/07, Magnus Holmgren <[EMAIL PROTECTED]> wrote:
I maintain a package where the upstream author has two changelog files: A
brief one called Changes, summarizing the changes, and a detailed one called
ChangeLog, which contains a detailed list of changes made to the various
source files. Whic
I better ask this once and for all...
I maintain a package where the upstream author has two changelog files: A
brief one called Changes, summarizing the changes, and a detailed one called
ChangeLog, which contains a detailed list of changes made to the various
source files. Which one should be
Josip Rodin <[EMAIL PROTECTED]> writes:
> In all the packages I've seen with something like this, the ChangeLog was
> included as changelog.gz and NEWS was included as NEWS.gz.
Yes, please stick to the standard conventions unless upstream differs
by much. If the .tar.gz contains NEWS, and you shi
Josip Rodin <[EMAIL PROTECTED]> writes:
> In all the packages I've seen with something like this, the ChangeLog was
> included as changelog.gz and NEWS was included as NEWS.gz.
Yes, please stick to the standard conventions unless upstream differs
by much. If the .tar.gz contains NEWS, and you sh
On Wed, Sep 19, 2001 at 08:35:32AM +0200, Josip Rodin wrote:
> On Wed, Sep 19, 2001 at 07:16:49AM +0200, peter karlsson wrote:
> > > without seeing the files, why is changelog not "human readable"?
> >
> > Well, because it has a lot of noise, with minor changes to files that
> > are not interestin
On Wed, Sep 19, 2001 at 08:35:32AM +0200, Josip Rodin wrote:
> On Wed, Sep 19, 2001 at 07:16:49AM +0200, peter karlsson wrote:
> > > without seeing the files, why is changelog not "human readable"?
> >
> > Well, because it has a lot of noise, with minor changes to files that
> > are not interesti
Ultimately as packager it is your decision. If NEWS is the right file for a
user to see what has changed since the last version (was my bug fixed? di they
implement feature X yet?) then go with that.
On Wed, Sep 19, 2001 at 07:16:49AM +0200, peter karlsson wrote:
> > without seeing the files, why is changelog not "human readable"?
>
> Well, because it has a lot of noise, with minor changes to files that
> are not interesting for those that do not download the source package.
> The NEWS file, o
Sean 'Shaleh' Perry:
> without seeing the files, why is changelog not "human readable"?
Well, because it has a lot of noise, with minor changes to files that
are not interesting for those that do not download the source package.
The NEWS file, on the other hand, just lists the actual compound
cha
Ultimately as packager it is your decision. If NEWS is the right file for a
user to see what has changed since the last version (was my bug fixed? di they
implement feature X yet?) then go with that.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Conta
On Wed, Sep 19, 2001 at 07:16:49AM +0200, peter karlsson wrote:
> > without seeing the files, why is changelog not "human readable"?
>
> Well, because it has a lot of noise, with minor changes to files that
> are not interesting for those that do not download the source package.
> The NEWS file,
Sean 'Shaleh' Perry:
> without seeing the files, why is changelog not "human readable"?
Well, because it has a lot of noise, with minor changes to files that
are not interesting for those that do not download the source package.
The NEWS file, on the other hand, just lists the actual compound
ch
s this wise? Is there any
> policy on what should be considered the upstream changelog? Must the
> source level changelog be present in the binary package as well?
--
Jason Thomas Phone: +61 2 6257 7111
System Administrator - UID 0 Fax:+61 2 6257 7311
ould be considered the upstream changelog? Must the
> source level changelog be present in the binary package as well?
>
without seeing the files, why is changelog not "human readable"?
s this wise? Is there any
> policy on what should be considered the upstream changelog? Must the
> source level changelog be present in the binary package as well?
--
Jason Thomas Phone: +61 2 6257 7111
System Administrator - UID 0 Fax:+61 2 6257 7311
Hi!
I am thinking of removing the upstream source level changelog from the
binary package for jwhois, and instead use its NEWS file, which
contains a history in human readable format. Is this wise? Is there any
policy on what should be considered the upstream changelog? Must the
source level
ould be considered the upstream changelog? Must the
> source level changelog be present in the binary package as well?
>
without seeing the files, why is changelog not "human readable"?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Hi!
I am thinking of removing the upstream source level changelog from the
binary package for jwhois, and instead use its NEWS file, which
contains a history in human readable format. Is this wise? Is there any
policy on what should be considered the upstream changelog? Must the
source level
On Tue, 25 Aug 1998, Martin Schulze wrote:
joey>I'd say define one as major changelog and rename it to changelog.gz.
Yeah, when I had the problem, I just cat'ed them together because
it was the quickest solution.
John Lapeyre <[EMAIL PROTECTED]>
Tucson,AZ http://www.physics.arizona.e
Michael Bramer wrote:
> Hello
>
> I have package [g]mc. In this package are some upstream changelog-files:
> changelog_intl.gz
> changelog_pc.gz
> changelog_src.gz
> changelog_vfs.gz
>
> I put all files in /usr/doc/[g]mc/. But I get one Lintian report:
>
Hello
I have package [g]mc. In this package are some upstream changelog-files:
changelog_intl.gz
changelog_pc.gz
changelog_src.gz
changelog_vfs.gz
I put all files in /usr/doc/[g]mc/. But I get one Lintian report:
W: mc: wrong-name-for-upstream-changelog usr/doc/mc/changelog_vfs.gz
Must I
89 matches
Mail list logo
