On Thu, Jan 29, 2009 at 2:44 AM, Steve M. Robbins wrote:
> Hi,
>
> To begin, I think there's some confusion about UID and OID. They
> are actually the same thing, according to Clunie:
>
> What DICOM calls "UIDs" are referred to in the
> ISO OSI world as Object Identifiers (OIDs).
>
> What Mathi
2009/1/28 Adeodato Simó :
> (The recommendation above is my opinion, and there are other DDs who
> think different. Me, I believe having a readable diff.gz is motivation
> enough as to repack the tarball.)
OTOH, reading the policy manual I get the idea that a pristine
original tarball is not some
Dmitrijs Ledkovs wrote:
> I have a similar question. Upstream has file ./debian/files in their
> tarball.
>
> Lintian complained about that file so I've deleted it. But during build in
> pbuilder it gets added back from the orig tarball. How to handle this?
That's because such change cannot be r
Luca Niccoli wrote:
> A related question:
> The original debian/ contains a changelog, which documents the past
> releases (packaged in .deb for i386 by upstream); should I get rid of
> that or keep it/import it?
>
I'd say it depends on what you are doing. If you are building on the
work alread
Hello mentors,
I'm currently packaging the application jDownloader which requires very
frequent updates. The mainstream devs have solved the updating with an
auto-update feature that checks for new versions of the core part and
plugins. As I understand, this is absolutely ok as other applicati
Hi Eric,
thanks for you response. I forgot to say that updates are all stored
in the users home directory. Even a core update would place all updated
files into the home directory.
Well I already checked the debian-volatile idea but the problem is that
it is not
enabled by default. I think this
2009/1/28 Paul Wise :
> You should use a Debian-specific SONAME if upstream doesn't have one.
> Please teach upstream about SONAMEs, ABI etc and get them to do that
> stuff instead of doing it yourself.
That's actually already done, and upstream has accepted my patch to
add a soname, but hasn't ma
On Thu, Jan 29, 2009 at 01:08:34AM +, Antonio Radici wrote:
> Gonéri Le Bouder wrote:
>> On Tue, Jan 27, 2009 at 08:01:29PM +, Antonio Radici wrote:
> Hi,
> thanks for your review, I will fix these problems tomorrow.
> Just to clarify the status of battery-stats: version 0.3.3-3 was *alrea
Gonéri Le Bouder wrote:
Ok, I see. I don't think the release team will accept a so import
debdiff.
linda:~/tmp$debdiff battery-stats_0.3.3-3.dsc battery-stats_0.3.4-1.dsc|
wc -l
13569
I doubt release team will accept this in testing. If you want to see #512701
fixed in Lenny, you've to prepare
Hi Alex,
I'm not a DD, but here my opinion:
- using local libraries is an issue for licensing and security reasons
(they don't get fixed with security updates).
- this said, the same could be said of the Firefox plugins, but they're
only installed for the user running Firefox.
Hence I would sugge
On Thu, Jan 29, 2009 at 03:29:52PM +, Antonio Radici wrote:
> Sid has my last release (0.3.3-3) which caused #512701, this is why I
> released this new version :-) Whether you want to put it in sid or
> experimental it's the same for me, in any case lenny will be fine
> because it will k
On Fri, Jan 30, 2009 at 12:24 AM, Jordi Gutiérrez Hermoso
wrote:
>> patches/add-soname seems to change the whitespace in the definition of SRC,
>> why?
>
> Why not? It fits into 80 columns that way. :-)
Just a gratuitous change, also unrelated to the purpose of the patch.
>> patches/add-soname
Hi,
I need some advice on using the debian/symbols-file.
The package libctl3 needs a symbols file, so I added something like:
libctl.so.3 libtcl3 #MINVER#
scm_list_...@base
scm_object_prope...@base
(...)
to debian/libctl3.symbols.
I got these lines from the output of dpkg-gensymbols
On Thursday 29 January 2009 15:22:06 Alexander Block wrote:
> Hello mentors,
Hi,
> I'm currently packaging the application jDownloader which requires very
> frequent updates. The mainstream devs have solved the updating with an
> auto-update feature that checks for new versions of the core part a
On Thu, Jan 29, 2009 at 07:13:59PM +0100, Thorsten Alteholz wrote:
> libctl.so.3 libtcl3 #MINVER#
>scm_list_...@base
>scm_object_prope...@base
>(...)
>lintian -I -E libctl3_3.0.3-2_i386.deb
>E: libctl3: symbols-file-contains-current-version-with-debian-revision on
> symbol
Hello Thorsten,
Thorsten Alteholz wrote:
> Hi,
>
> I need some advice on using the debian/symbols-file.
> The package libctl3 needs a symbols file, so I added something like:
>
> libctl.so.3 libtcl3 #MINVER#
^^^ ^^^
BTW, about last lintian complaint: 'libctl' and 'libtcl':
one
Gonéri Le Bouder wrote:
Since battery-stats 0.3.3-2 is in testing you shouldn't upload a new
upstream release in unstable[1]. experimental is still an option.
You can prepare a 0.3.3-3 package with just the fix for #512701, after
the upload you'll have to ask the release team to accept this packa
2009/1/29 Eduardo M KALINOWSKI :
I'd say it depends on what you are doing. If you are building on the
work already there, keep the changelog. But if you are ignoring
upstream's debian/ directory and starting your packaging from scratch,
you can drop it.
By keep the changelog you mean add my
George Danchev wrote:
A more important question would be:
`is this ok with you as a Debian package maintainer and your debian users to
have such a package in Debian'.
How are you supposed to track the versions of the stuff installed and being
unpredictably upgraded in the users' $HOME?
How
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dear mentors,
I am looking for a sponsor for the new version 1.21-1
of my ITA package "libdata-compare-perl".
It builds these binary packages:
libdata-compare-perl - perl module to compare perl data structures
recursively
The package appears to be l
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dear mentors,
I am looking for a sponsor for the new version 0.13-1
of my ITA package "libscalar-properties-perl".
It builds these binary packages:
libscalar-properties-perl - perl module to add run-time properties on
scalar variables
The package ap
21 matches
Mail list logo