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.
* 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 wa
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 re
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 thin
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 th
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 lin
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
> /usr/share/applets
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 a
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 -
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 xm
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
* 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
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 rec
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
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 thi
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 j
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 lint
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
> /usr/share/applets/
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 al
28 matches
Mail list logo
