Sorry for not replying earlier. I am no expert on GNUstep make, but your
change seems valid to me. The worst that should result from it is a left
over Resource folder in the build directory.
You could limit your change to the case where GNUSTEP_BUILD_DIR is equal
to . in all other cases the old
Ping!
On Thursday, December 12, 2013 07:23 CET, Sebastian Reitenbach
sebas...@l00-bugdead-prods.de wrote:
On Monday, December 9, 2013 23:00 CET, Fred Kiefer fredkie...@gmx.de wrote:
I would like to suggest to have a shared release of the GNUstep core
components before the end of
On 12.12.2013 09:20, Fred Kiefer wrote:
Am 12.12.2013 um 09:12 schrieb Sebastian Reitenbach
sebas...@l00-bugdead-prods.de:
On Thursday, December 12, 2013 08:06 CET, Germán Arias germanan...@gmx.es
wrote:
On 2013-12-11 16:58:30 -0600 Fred Kiefer fredkie...@gmx.de wrote:
I really don't
On Thursday, December 12, 2013 08:06 CET, Germán Arias germanan...@gmx.es
wrote:
On 2013-12-11 16:58:30 -0600 Fred Kiefer fredkie...@gmx.de wrote:
I really don't have a clue what is going on here. Anybody out there with
more insight?
Fred
Well, it works perfectly to me,
Am 12.12.2013 um 08:06 schrieb Germán Arias germanan...@gmx.es:
On 2013-12-11 16:58:30 -0600 Fred Kiefer fredkie...@gmx.de wrote:
I really don't have a clue what is going on here. Anybody out there with
more insight?
Fred
Well, it works perfectly to me, with the menu or keyboard
Am 12.12.2013 um 09:12 schrieb Sebastian Reitenbach
sebas...@l00-bugdead-prods.de:
On Thursday, December 12, 2013 08:06 CET, Germán Arias germanan...@gmx.es
wrote:
On 2013-12-11 16:58:30 -0600 Fred Kiefer fredkie...@gmx.de wrote:
I really don't have a clue what is going on here.
On 09.12.2013 23:00, Fred Kiefer wrote:
At the moment I am myself testing the current
GNUstep code on OpenSuse 13.1. There the copy/paste mechanism seems to
be broken. When calling copy from the menu I get the following stack dump:
Program received signal SIGPIPE, Broken pipe.
On Monday, December 9, 2013 23:00 CET, Fred Kiefer fredkie...@gmx.de wrote:
I would like to suggest to have a shared release of the GNUstep core
components before the end of this year.
This is great, and I'm all for it.
There was a base release a few months ago, but the last gui/back
On 2013-12-11 16:58:30 -0600 Fred Kiefer fredkie...@gmx.de wrote:
I really don't have a clue what is going on here. Anybody out there with
more insight?
Fred
Well, it works perfectly to me, with the menu or keyboard shortcuts.
Have you tried clean and rebuild all GNUstep?
Germán
I would like to suggest to have a shared release of the GNUstep core
components before the end of this year.
There was a base release a few months ago, but the last gui/back release
was more than six months ago. And right after that release I fixed a bug
in gui that will show up with all newer
On May 8, 2009, at 12:04 PM, Nicola Pero wrote:
On 7 May 2009, at 15:26, Adam Fedor wrote:
I can make a release of the core libraries in the next day or two
if that's OK. This was my plan:
make 2.0.9
I was thinking of releasing trunk as make 2.2.0 (instead of 2.0.9).
The idea being
On 7 May 2009, at 15:26, Adam Fedor wrote:
I can make a release of the core libraries in the next day or two if
that's OK. This was my plan:
make 2.0.9
I was thinking of releasing trunk as make 2.2.0 (instead of 2.0.9).
The idea being that 2.0.x does not support parallel building (make
I agree that we should delay the release of gui since there have been
a number of changes that have not been fully tested. While I'm sure
that they are working I have tested them with a limited set of apps
and would like to see a greater degree of testing done prior to an
official release.
The
What ever numbering system you prefer :-)
To me it is just the same and people will always find a reason to
complain about it.
For gui I would like to delay a new release for a few weeks. Gregory has
done a load of changes which will need some testing. And one set of them
(The changes for
It's been a long time now (LTN) since our last release, perhaps we
should do a new one soon? Also, in an effort to please everyone
(ETPE), I was thinking we should separate the release numbering from
the SO version numbering, at least on the unstable branch as long as
there are no ABI
@gnu.org
Sent: Tuesday, March 4, 2008 1:37:49 PM
Subject: Re: Next release
Adam Fedor wrote:
On Mar 3, 2008, at 1:40 PM, Riccardo wrote:
A newer stable release should be done indeed. Adam?
That's up to Gregory, et. al. Do we have any goals for the next stable
release? gui 1.0?
I am
Sent: Tuesday, March 4, 2008 1:37:49 PM
Subject: Re: Next release
Adam Fedor wrote:
On Mar 3, 2008, at 1:40 PM, Riccardo wrote:
A newer stable release should be done indeed. Adam?
That's up to Gregory, et. al. Do we have any goals for the next
stable release? gui 1.0?
I am still
On 08.03.2008, at 00:33, Gregory John Casamento wrote:
Currently there is a lot of space which is marked as reserved in
Apple's header files. This allows for future additions without
changing the memory layout of the class which is what leads to ABI
issues and subsequently the need for
BTW: sometimes people don't know what ABI compatibility implies in the
real world. The basic idea is that if I have a library and a tool, I
can replace 'library' with any ABI compatible library and the tool
still works. Stuff like crasher bugs being fixed.
Say, I have installed
Adam Fedor wrote:
On Mar 3, 2008, at 9:28 AM, Hubert Chathi wrote:
I was intending on tracking the GNUstep unstable branch in Debian
experimental, but we currently have some unresolved issues regarding
ffcall/libffi.
I think tracking unstable would be a good idea.
OK, I will work on
On Mar 5, 2008, at 9:51 AM, Hubert Chathi wrote:
Well, ffcall, as you know, doesn't work properly on SELinux, PAX, etc.
I had a report of libffi not working on x86_64 (see one of my previous
messages), and I don't have proper access to an x86_64 box to
debug. So
it seems like neither
Adam Fedor wrote:
On Mar 3, 2008, at 1:40 PM, Riccardo wrote:
A newer stable release should be done indeed. Adam?
That's up to Gregory, et. al. Do we have any goals for the next stable
release? gui 1.0?
I am still a bit reluctant to use the version number 1.0. We would be
committing
On Sun, 02 Mar 2008 11:51:01 +0100, Riccardo [EMAIL PROTECTED] said:
Hi,
On 2008-03-02 00:18:47 +0100 Adam Fedor [EMAIL PROTECTED] wrote:
It's time for another release. I'll make an unstable release of the core
libraries late next week. I also plan a stable base release, but I
will not
Stefan Bidigaray wrote:
Debian Unstable (Sid) tends to only track stable packages of anything!
The so called unstable Debian branch is just unstable due to package
problems, but the packages in it are generally the latest stable
(assuming there's someone maintaining them).
Yes, that is
Hi,
On 2008-03-02 21:00:53 +0100 Hubert Chathi [EMAIL PROTECTED] wrote:
Yes, Debian currently tracks the stable branch. My understanding was
that the purpose for stable was to provide a stable ABI for
application
developers to target.
But I'm hearing more about applications that need the
On Mar 3, 2008, at 9:28 AM, Hubert Chathi wrote:
I was intending on tracking the GNUstep unstable branch in Debian
experimental, but we currently have some unresolved issues regarding
ffcall/libffi.
I think tracking unstable would be a good idea. Are you having
general problems with
On Mar 3, 2008, at 1:40 PM, Riccardo wrote:
A newer stable release should be done indeed. Adam?
That's up to Gregory, et. al. Do we have any goals for the next
stable release? gui 1.0?
That last stable release, I didn't start backporting patches until six
months afterwards, when it
Hi,
On 2008-03-02 00:18:47 +0100 Adam Fedor [EMAIL PROTECTED] wrote:
It's time for another release. I'll make an unstable release of the
core
libraries late next week. I also plan a stable base release, but I
will
not make a stable release of the gui libraries, unless there is some
On Mar 2, 2008, at 3:51 AM, Riccardo wrote:
About stable, since I gather Debian tracks stable (?) it would be
nice to have some of the printing stuff backported to stable: PRICE
doesn't compile against current debian packages. But it is just my
guess: htey have an reasonably up to date
On Sun, Mar 2, 2008 at 7:35 PM, Adam Fedor [EMAIL PROTECTED] wrote:
On Mar 2, 2008, at 3:51 AM, Riccardo wrote:
About stable, since I gather Debian tracks stable (?) it would be
nice to have some of the printing stuff backported to stable: PRICE
doesn't compile against current debian
It's time for another release. I'll make an unstable release of the
core libraries late next week. I also plan a stable base release,
but I will not make a stable release of the gui libraries, unless
there is some important patch the someone wants there (or better yet,
patch the stable
Should I increase the subversion/SONAME of base? It's been a long time and
lots of stuff has been added.
We should freeze the code for core as well, probably Friday, so we have a
chance to make a release.
___
Gnustep-dev mailing list
On 23 Aug 2006, at 13:44, Adam Fedor wrote:
Should I increase the subversion/SONAME of base? It's been a long
time and lots of stuff has been added.
Certainly.
I had hoped to be able to do more (socks and ssh support for
NSStream, completion of the new apple URL handling classes etc),
Hi,
I would like to know whether there is any way to indicate the next
GNUstep release for GS_API_VERSION macro.
For example, when you add a new method, it will be available only
with the next release, but at the time you commit header/
implementation update related you cannot know
for GS_API_VERSION macro.
For example, when you add a new method, it will be available only with
the next release, but at the time you commit header/implementation
update related you cannot know for sure what will be the next version
number of the library. The maintener can decide to do either
On Aug 9, 2006, at 7:10 AM, Richard Frith-Macdonald wrote:
I understand the problem, but I don't think the best solution is to
add new macros and scripting. Rather, I think it's to adopt a
slightly more rigorous approach to making releases. What I propose is
this ...
When we make a
Am 09.08.2006 um 12:14 schrieb Quentin Mathé:
For example, when you add a new method, it will be available only
with the next release, but at the time you commit header/
implementation update related you cannot know for sure what will be
the next version number of the library.
One
On Jun 6, 2005, at 8:43 AM, Adam Fedor wrote:
Lets set the cut-off date for adding binary incompatible changes as
June 14. I'll try to get a release out by June 28 then.
Note - my definition of binary incompatible is a change that does not
allow the OS to resolve a symbol at runtime or
Lets set the cut-off date for adding binary incompatible changes as
June 14. I'll try to get a release out by June 28 then.
Note - my definition of binary incompatible is a change that does not
allow the OS to resolve a symbol at runtime or cause memory/ivar
incompatibilities when starting
is to big and too much work for me to do this all by myself.
What about explicitly assigning and publishing a core developer(s) to each
GNUstep package? The package development leader should:
- publish TODO list and goals for the package
- publish plans for the next release (can be discussed
40 matches
Mail list logo
