Hello,
while working on http://wiki.debian.org/Projects/ImprovedDpkgShlibdeps
I'm discovering some arch-specific differences in the "objdump -T"
output of libraries.
* On ia64, static functions appear in objdump's output and they are marked
as "local".
See my previous message to debian-ia64:
Am Montag, den 13.08.2007, 22:26 +0200 schrieb Julian Andres Klode:
> Am Montag, den 13.08.2007, 15:50 -0400 schrieb Joey Hess:
>
> > Policy is actually careful to set up the invarient that "-" anywhere in
> > a version number means the package is not native. I don't know why the
> > developers re
Raphael Hertzog wrote:
> Hello,
>
> while working on http://wiki.debian.org/Projects/ImprovedDpkgShlibdeps
> I'm discovering some arch-specific differences in the "objdump -T"
> output of libraries.
>
> * On ia64, static functions appear in objdump's output and they are marked
> as "local".
>
(Please keep debian-devel in the CC. This issue is a project-wide
isssue.)
Bart Martens wrote:
> How do other tools this?
Other well-respected tools in debhelper's situation, such as?
yada
It introduces a completely nonstandard Upstream-Source field in
debian/control which it tak
On Tue, Aug 14, 2007 at 13:38:04 -0400, Joey Hess wrote:
> Bart Martens wrote:
> > Policy states that if there is no "debian_revision" then hyphens "-" are
> > not allowed in the "upstream_version".
> > http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
> > Policy also state
On Tue, Aug 14, 2007 at 19:45:11 +0200, Julien Cristau wrote:
> It also implies that if there is no debian_revision, upstream_version
> can contain a hyphen.
>
No it doesn't. Sorry about that...
Cheers,
Julien
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Tro
On Tue, Aug 14, 2007 at 01:38:04PM -0400, Joey Hess wrote:
> Bart Martens wrote:
> > Policy does not explicitly state that the presence/absence of a
> > "debian_revision" or that the presence/absence of hyphen(s) "-" indicate
> > whether or not the package is a "native Debian package".
>
>
First, a short explanation of the use case:
1. User runs poedit (aka potooledit) on a partially translated po file.
2. Poedit retrieves only the untranslated messages from the file (by
filtering it through potool -fnt) and puts them into a temporary po
file
3. Poedit launches $EDITOR on that
(For the second time, please preserve my CC.)
Bart Martens wrote:
> Yes, lintian. Two examples where lintian seems to follow/accept the
> numbering described in developer's reference:
>
> Example one: Try doing an NMU of dh-make-php with adding ".0.1". Then
> lintian produces this warning:
> W:
Julien Cristau wrote:
> It also implies that if there is no debian_revision, upstream_version
> can contain a hyphen.
Utterly false:
The may contain only alphanumerics[1] and the
characters `.' `+' `-' `:' (full stop, plus, hyphen, colon) and
should start with a di
Thank you for the additional information you have supplied regarding
this problem report. It has NOT been forwarded to the package
maintainers, but will accompany the original report in the Bug
tracking system. Please ensure that you yourself have sent a copy of
the additional information to any
[EMAIL PROTECTED] wrote:
> Because it may be more important to be able to identify an NMU from the
> version number than to be able to identify a native package from the
> version number...
I don't see why it's important to be able to tell that from a version
number at all. It's also not the ratio
On Sat, Aug 04, 2007 at 07:17:59PM +0200, Sam Hocevar <[EMAIL PROTECTED]> 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
Joey Hess <[EMAIL PROTECTED]> writes:
> (For the second time, please preserve my CC.)
> Bart Martens wrote:
>> Yes, lintian. Two examples where lintian seems to follow/accept the
>> numbering described in developer's reference:
>> Example one: Try doing an NMU of dh-make-php with adding ".0.1"
On Sun, 12 Aug 2007 19:57:51 +0200
"Carl Fürstenberg" <[EMAIL PROTECTED]> wrote:
> I knew that my list was incomplete, so if you want to regenerate the
> page, use following perl script:
>
> #!/usr/bin/perl
>
> use strict;
> use warnings;
> use Parse::DebControl;
Carl - that module is in CPAN
On 8/14/07, Neil Williams <[EMAIL PROTECTED]> wrote:
> On Sun, 12 Aug 2007 19:57:51 +0200
> "Carl Fürstenberg" <[EMAIL PROTECTED]> wrote:
>
> > I knew that my list was incomplete, so if you want to regenerate the
> > page, use following perl script:
> >
> > #!/usr/bin/perl
> >
> > use strict;
> > u
Package: wnpp
Severity: wishlist
Owner: "Carl Fürstenberg" <[EMAIL PROTECTED]>
* Package name: libparse-debcontrol-perl
Version : 2.005
Upstream Author : Jay Bonci <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/~jaybonci/Parse-DebControl-2.005/
* License : A
NMUs of native packages have always seemed sorta strange to me, and I think
I've figured out why as I was painting a room. Painting is a great way to
think, since you already are in a frame of mind that avoids painting yourself
into corners. ;-)
Many native packages are not Debian-specifc software
On (14/08/07 17:44), Joey Hess wrote:
> Many native packages are not Debian-specifc software, but instead
> debian-originated software (examples: dpkg, apt). Other unrelated distros
> might choose to use native Debian software. Just because it's
> debian-originated software, doesn't mean that the p
On Tue, Aug 14, 2007 at 05:44:52PM -0400, Joey Hess wrote:
> NMUs of native packages have always seemed sorta strange to me, and I think
> I've figured out why as I was painting a room. Painting is a great way to
> think, since you already are in a frame of mind that avoids painting yourself
> into
On Tue, 14 Aug 2007, James Westby wrote:
> Also, I guess you are opening up the possibility of creating a
> source package containing both a .tar.gz and .diff.gz, which will
> also confuse some tools I expect.
Those tools really should be looking at the dsc or calling dpkg-source
-x instead (which
Hi everyone,
recently ghostscript 8.60 was released [1] which is now available under
the GPL.
The features of ESP Ghostscript have been merged into Ghostscript GPL
and the upstream of gs-esp has officially declared gs-esp obsolete [2].
The Debian gs-afpl package has been orphaned some time ago [3
Steve Langasek <[EMAIL PROTECTED]> writes:
> On Tue, Aug 14, 2007 at 05:44:52PM -0400, Joey Hess wrote:
>> We could do away with the concept of NMUs of native software, and do
>> away with this uncertanty, ambiguity, bugginess, etc. Simply say that
>> when a NMU of a native package is done, the pa
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org
Package name: audtty
Version: 0.1.5a
Upstream Author: Tony Vroon <[EMAIL PROTECTED]>
Christian Birchinger <[EMAIL PROTECTED]>
Kiyoshi Aman <[EMAIL PROTECTED]>
URL:
James Westby wrote:
> However you say
>
> The .orig.tar.gz from the maintainer's last release is kept in the archive
>
> but for a native package there is no .orig.tar.gz, there is a .tar.gz.
You're right. I wonder if there's a good way to deal with this
discreprency and rename the .tar.gz to
Steve Langasek wrote:
> I'm in total agreement with this. I was staying out of this thread because
> I've been one of the proponents of using -0.x for NMUs of native packages in
> spite of the inconsistency with Policy, and I wasn't sure that this
> reasoning wasn't just a post-hoc rationalization
On Tue, Aug 14, 2007 at 08:20:25PM -0400, Joey Hess wrote:
> Steve Langasek wrote:
> > I'm in total agreement with this. I was staying out of this thread because
> > I've been one of the proponents of using -0.x for NMUs of native packages in
> > spite of the inconsistency with Policy, and I wasn'
Package: wnpp
Severity: wishlist
Owner: Peter Collingbourne <[EMAIL PROTECTED]>
* Package name: ladr
Version : 0.0.200708
Upstream Author : William McCune <[EMAIL PROTECTED]>
* URL : http://www.cs.unm.edu/~mccune/mace4/
* License : GPL
Programming Lang: C
D
Package: wnpp
Severity: wishlist
Owner: Peter Collingbourne <[EMAIL PROTECTED]>
* Package name: prover9-doc
Version : 0.0.200708
Upstream Author : William McCune <[EMAIL PROTECTED]>
* URL : http://www.cs.unm.edu/~mccune/mace4/
* License : GPL
Programming Lang
Package: wnpp
Severity: wishlist
Owner: Magnus Therning <[EMAIL PROTECTED]>
* Package name: keysafe
Version : 0.3.5
Upstream Author : Magnus Therning <[EMAIL PROTECTED]>
* URL : http://therning.org/magnus/computer/keysafe
* License : GPL
Programming Lang: Pyt
On Tuesday 14 August 2007 4:44:52 pm Joey Hess wrote:
> Many native packages are not Debian-specifc software, but instead
> debian-originated software (examples: dpkg, apt). Other unrelated distros
> might choose to use native Debian software. Just because it's
> debian-originated software, doesn't
So in summary, what is the verdict?
I am inclined to add a non-versioned conflicts for now, as I suspect
it might be a while before this can be solved in a better way.
Also: No, I don't want to maintain a patch in Heimdal that renames the
library.
If upstream could be convinced to rename the lib
[Marcin Owsiany]
> What happens in step 3 is that vim looks at an ascii-only file (since
> msgids are in POSIX locale) and when the user inputs the translation in
> her own language, the editor decides to use encoding B (since it's the
> locale default).
>
> Then in step 5 poedit merges the origi
On Tue, Aug 14, 2007 at 02:03:16PM +0100, Thiemo Seufer wrote:
> I presume this applies only to static functions whose address wasn't
> taken inside the module. Otherwise this would be a bug for e.g. callbacks
> exported via a function pointer.
I mentioned it in my reply to Raphael [1] but I think
UseR! 2007 at Iowa State University, Ames, IA, August 8-10, 2007
Following two successful UseR! conferences in Vienna in 2004 and 2006, the
first North American UseR! was help last week at Iowa State. I presented two
papers of which one has specific Debian content (more on that one below).
I.
35 matches
Mail list logo
