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 c
Ping!
On Thursday, December 12, 2013 07:23 CET, "Sebastian Reitenbach"
wrote:
>
> On Monday, December 9, 2013 23:00 CET, Fred Kiefer 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
On 12.12.2013 09:20, Fred Kiefer wrote:
> Am 12.12.2013 um 09:12 schrieb "Sebastian Reitenbach"
> :
>>> On Thursday, December 12, 2013 08:06 CET, Germán Arias
>>> wrote:
On 2013-12-11 16:58:30 -0600 Fred Kiefer wrote:
I really don't have a clue what is going on here. Anybody out
Am 12.12.2013 um 09:12 schrieb "Sebastian Reitenbach"
:
>
>> On Thursday, December 12, 2013 08:06 CET, Germán Arias
>> wrote:
>>
>>> On 2013-12-11 16:58:30 -0600 Fred Kiefer wrote:
>>>
>>> I really don't have a clue what is going on here. Anybody out there with
>>> more insight?
>>>
>>>
Am 12.12.2013 um 08:06 schrieb Germán Arias :
> On 2013-12-11 16:58:30 -0600 Fred Kiefer 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
On Thursday, December 12, 2013 08:06 CET, Germán Arias
wrote:
> On 2013-12-11 16:58:30 -0600 Fred Kiefer 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 keyboa
On 2013-12-11 16:58:30 -0600 Fred Kiefer 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
_
On Monday, December 9, 2013 23:00 CET, Fred Kiefer 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 release
> was more
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.
> 0x7f
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 Linu
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 tha
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 -j
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
base 1.19.1
gui 0.17.0
back 0.17.0
On May 6, 2009, at 11:54 AM, Gregory Casamento wrote:
Fred,
I agree. I think we're in good shape to do a release.
We can discuss any issues whe
Fred,
I agree. I think we're in good shape to do a release.
We can discuss any issues when you get back.
Thanks, GC
On Wednesday, May 6, 2009, Fred Kiefer wrote:
> I think we waited now long enough to be sure there wont be any big
> surprises when we make a new release.
> There still are impor
I think we waited now long enough to be sure there wont be any big
surprises when we make a new release.
There still are important open issues, but as far as I can see no
regressions. I will be away for the next week, perhaps this is the
perfect time for a release. When I come back I will have plen
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 c
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 autoresi
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 cha
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
gnustep-base
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 r
uld
> be. :)
>
> Later, GJC
>
> Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief
> Maintainer
>
> - Original Message From: Fred Kiefer <[EMAIL PROTECTED]> To:
> Adam Fedor <[EMAIL PROTECTED]> Cc: Developer GNUstep
> Sent: Tuesday
fer <[EMAIL PROTECTED]>
To: Adam Fedor <[EMAIL PROTECTED]>
Cc: Developer GNUstep
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
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 soluti
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 w
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
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 was
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 libf
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
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
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
>>
> It's time for another release.
Btw, gnustep-make is also ready for release - I suppose it could be called
2.0.5.
Thanks
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
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 de
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 base
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
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 b
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), b
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
Gnustep-dev@g
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
Le 9 août 06 à 17:20, Adam Fedor a écrit :
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
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 release
On 9 Aug 2006, at 11:14, Quentin Mathé wrote:
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
p 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 sure what will be the next version
> number of the library. The maint
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
I think I'll have time to do a release in the next few days.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
There's at least a non-zero chance that I'll be able to make a release
of the core libraries in the next week or two...
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
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 cau
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 a
I've just released a new version of all the core libraries. The next
release will be a binary incompatible version of the core packages. So
now is your chance to make some big changes - add ivars, change
behavior, etc.
I was hoping to make another release in a month, but if that is too
On Mar 17, 2005, at 8:13 AM, Adrian Robert wrote:
It's probably not necessary to burden "core developers" with these
tasks if others are willing to help out. There are some people who do
a lot of coding in base and gui and tend to give advice on patches and
the like. If any of them want to ser
h TODO list and goals for the package
- publish plans for the next release (can be discussed with others)
- approve releases
It's probably not necessary to burden "core developers" with these
tasks if others are willing to help out. There are some people who do
a lot of coding in
s 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 with others)
- approve releases
The last one
On Mar 16, 2005, at 3:03 AM, Stefan Urbanek wrote:
Hi,
What are the plans for the next GNUstep -bas and -gui releases?
Is it possible to make minor releases more often and to publish
plans/todos for
next major and minor releases?
Moreover, can people who make releases describe the whole process o
Le 16 mars 05, à 11:03, Stefan Urbanek a écrit :
Hi,
What are the plans for the next GNUstep -bas and -gui releases?
Is it possible to make minor releases more often and to publish
plans/todos for
next major and minor releases?
Hi Stefan,
It's a welcome addition to wiki. You can move tasks which a
Hi,
What are the plans for the next GNUstep -bas and -gui releases?
Is it possible to make minor releases more often and to publish plans/todos for
next major and minor releases?
Moreover, can people who make releases describe the whole process on the new
wiki so others delegated developers can
54 matches
Mail list logo
