-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
-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
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
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
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
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
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
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
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 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
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
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
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
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
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
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
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
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
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
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
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
21 matches
Mail list logo