This one time, at band camp, Junichi Uekawa wrote:
The upstream may fix the package slightly to make
binary-incompatible change to the library, and call it
0.3.0 (well, it's only natural).
However, in the library sense, if it is binary-incompatible,
it should have a new soname, i.e. 1.0.0
Are
* Ian Duggan [EMAIL PROTECTED] [020316 23:17]:
The source is still missing the diff, there seems to be a redundant
tarball instead.
Oops. There was a bug in my upload script. Try now. Third time's the
charm, hopefully. :)
I'm still missing the .diff.gz
The redundant .tar.gz was the
On Sun, Mar 17, 2002 at 12:16:41PM +0800, Patrick Hsieh wrote:
I'm sorry if this question is not supposed to be here.
-mentors would be better - cc'ed.
But I am planing to package my shell scripts into a .deb package and
make my own apt-gettable source list. My problem is, since the .deb
Jamie Wilkinson [EMAIL PROTECTED] cum veritate scripsit:
However, in the library sense, if it is binary-incompatible,
it should have a new soname, i.e. 1.0.0
Are there ways to test libraries against other versions to check for a
binary incompatibility, or does it rely on a human
This one time, at band camp, Junichi Uekawa wrote:
# If anyone has a good tool, please tell me.
Well, I'm thinking of a way to automate these checks, hence my question.
So, as I understand it, there's an _incompatible_ API change (and thus
requiring a SONAME change) when:
* function prototypes
On Fri, 15 Mar 2002 23:17:20 +,
Will Newton [EMAIL PROTECTED] wrote:
A program I use (GNU Common Lisp) is currently orphaned (#123279) and has a
couple of RC bugs to it's name. I would like to adopt this package and also
become a Debian developer. Obviously for this I would require a
Jamie Wilkinson [EMAIL PROTECTED] cum veritate scripsit:
So, as I understand it, there's an _incompatible_ API change (and thus
requiring a SONAME change) when:
* function prototypes (incl names) that are exported are changed or obsoleted
* structs change or are obsoleted
I think I can
On Mon, Mar 18, 2002 at 12:33:40AM +1100, Jamie Wilkinson wrote:
So, as I understand it, there's an _incompatible_ API change (and thus
requiring a SONAME change) when:
* function prototypes (incl names) that are exported are changed or obsoleted
* structs change or are obsoleted
I think
Junichi Uekawa [EMAIL PROTECTED] cum veritate scripsit:
Well, now I updated the doc a little bit, I'll post it here.
I've received exactly one response so far, and I'm feeling a bit
naive about the contents of this document.
Please comment:
Library packaging Guide (very much a draft).
This is
Hi there,
I've written a small program that I'd like to package and have included
in the debian archive. It's a gnome applet that allows you to set
alarms and then be notified when those alarms go off.
I think I have all the debian/* files set up properly - I can generate a
.deb file ok and
On Sun, 2002-03-17 at 11:41, Chris AtLee wrote:
Hi there,
I've written a small program that I'd like to package and have included
in the debian archive. It's a gnome applet that allows you to set
alarms and then be notified when those alarms go off.
Have you looked at sanduhr?
--
To
On Sun, Mar 17, 2002 at 10:13:32PM +0900, Oohara Yuuma wrote:
On Fri, 15 Mar 2002 23:17:20 +,
Will Newton [EMAIL PROTECTED] wrote:
A program I use (GNU Common Lisp) is currently orphaned (#123279) and has a
couple of RC bugs to it's name. I would like to adopt this package and also
Ok...So why does gnome-applets put stuff into /usr/share/applets? Or do
those files not count as configuration files?
Chris
On Sun, 2002-03-17 at 19:30, Colin Watson wrote:
On Sun, Mar 17, 2002 at 11:41:07AM -0500, Chris AtLee wrote:
I think I have all the debian/* files set up properly - I
Title: Ovnibus a debian medical application project
Hi all,
I am involved in a debian medical project.
Please see the website of Ovnibus
http://ovnibus.free.fr
The aim of this project is to offer a debian based information system of medical applications.
The software devellopment will be with
This one time, at band camp, Junichi Uekawa wrote:
The upstream may fix the package slightly to make
binary-incompatible change to the library, and call it
0.3.0 (well, it's only natural).
However, in the library sense, if it is binary-incompatible,
it should have a new soname, i.e. 1.0.0
Are
* Ian Duggan [EMAIL PROTECTED] [020316 23:17]:
The source is still missing the diff, there seems to be a redundant
tarball instead.
Oops. There was a bug in my upload script. Try now. Third time's the
charm, hopefully. :)
I'm still missing the .diff.gz
The redundant .tar.gz was the
On Sun, Mar 17, 2002 at 12:16:41PM +0800, Patrick Hsieh wrote:
I'm sorry if this question is not supposed to be here.
-mentors would be better - cc'ed.
But I am planing to package my shell scripts into a .deb package and
make my own apt-gettable source list. My problem is, since the .deb
Jamie Wilkinson [EMAIL PROTECTED] cum veritate scripsit:
However, in the library sense, if it is binary-incompatible,
it should have a new soname, i.e. 1.0.0
Are there ways to test libraries against other versions to check for a
binary incompatibility, or does it rely on a human recognising
This one time, at band camp, Junichi Uekawa wrote:
# If anyone has a good tool, please tell me.
Well, I'm thinking of a way to automate these checks, hence my question.
So, as I understand it, there's an _incompatible_ API change (and thus
requiring a SONAME change) when:
* function prototypes
On Fri, 15 Mar 2002 23:17:20 +,
Will Newton [EMAIL PROTECTED] wrote:
A program I use (GNU Common Lisp) is currently orphaned (#123279) and has a
couple of RC bugs to it's name. I would like to adopt this package and also
become a Debian developer. Obviously for this I would require a
Jamie Wilkinson [EMAIL PROTECTED] cum veritate scripsit:
So, as I understand it, there's an _incompatible_ API change (and thus
requiring a SONAME change) when:
* function prototypes (incl names) that are exported are changed or obsoleted
* structs change or are obsoleted
I think I can
On Mon, Mar 18, 2002 at 12:33:40AM +1100, Jamie Wilkinson wrote:
So, as I understand it, there's an _incompatible_ API change (and thus
requiring a SONAME change) when:
* function prototypes (incl names) that are exported are changed or obsoleted
* structs change or are obsoleted
I think I
Junichi Uekawa [EMAIL PROTECTED] cum veritate scripsit:
Well, now I updated the doc a little bit, I'll post it here.
I've received exactly one response so far, and I'm feeling a bit
naive about the contents of this document.
Please comment:
Library packaging Guide (very much a draft).
This is
Hi there,
I've written a small program that I'd like to package and have included
in the debian archive. It's a gnome applet that allows you to set
alarms and then be notified when those alarms go off.
I think I have all the debian/* files set up properly - I can generate a
.deb file ok and
On Sun, 2002-03-17 at 11:41, Chris AtLee wrote:
Hi there,
I've written a small program that I'd like to package and have included
in the debian archive. It's a gnome applet that allows you to set
alarms and then be notified when those alarms go off.
Have you looked at sanduhr?
On Sun, Mar 17, 2002 at 11:41:07AM -0500, Chris AtLee wrote:
I think I have all the debian/* files set up properly - I can generate a
.deb file ok and lintian only complains about something that I'm not
sure can be fixed:
E: alarm-applet: file-in-usr-marked-as-conffile
On Sun, Mar 17, 2002 at 10:13:32PM +0900, Oohara Yuuma wrote:
On Fri, 15 Mar 2002 23:17:20 +,
Will Newton [EMAIL PROTECTED] wrote:
A program I use (GNU Common Lisp) is currently orphaned (#123279) and has a
couple of RC bugs to it's name. I would like to adopt this package and also
27 matches
Mail list logo
