Ivan Vučica wrote:
> Debian is soft-freezing on 2021-02-12.
Debian is already in library transition freeze so please don't rush
with the releases just for the sake of it. We had a chat with Gürkan
recently and decided that we won't manage for bullseye should there be
new GNUstep releases.
Sorry
Jordan Schidlowsky wrote:
> > On Oct 31, 2019, at 2:47 PM, Yavor Doganov wrote:
> > I fixed a bug in SOPE on SuperH just a few months ago. Over the
> > years, I recall fixes in GNUstep core libraries on HP-PA, GNU/Hurd
> > and GNU/kFreeBSD, to name a few. And non-core pa
On Fri, 01 Nov 2019 04:45:43 +0200,
lars.sonchocky-helld...@hamburg.de wrote:
> > Am 31.10.2019 um 21:47 schrieb Yavor Doganov :
> > But GCC didn't drop support for GNUstep. It just cannot cope with
> > the changes of the language/runtime that are completely under the
>
В Tue, 29 Oct 2019 12:50:23 +, David Chisnall написа:
> On 27/10/2019 16:05, Gregory Casamento wrote:
>> We are a GNU / FSF project. Dropping support for GCC would be bad
>> political mojo. There is little we can do to bridge the gap other
>> than doing these macros.
>
> I don't really
В Thu, 03 Jan 2019 08:29:45 +0100, Gürkan Myczko написа:
> On 01.01.2019 18:48, Gregory Casamento wrote:
>> The Gorm changes David committed warrant a release of the app. So I
>> concur with doing a release.
>
> Sounds great! Will it happen before 12th Jan 2019? The sooner, the
> better.
For
В Wed, 02 Jan 2019 16:48:51 +, Ivan Vučica написа:
> I realized I'm not sure what transition means. Out of curiosity, is it
> the transition from e.g. libgnustep-gui0.26 to libgnustep-gui0.27?
Yes, that's a library transition. The Debian Release team "acks" a
transition when the new
В Tue, 01 Jan 2019 23:28:35 +, Ivan Vučica написа:
> On Tue, Jan 1, 2019 at 9:43 PM Yavor Doganov wrote:
>> I believe it's too late for that.
>>
> I could cut a release this weekend, and then we do another one by the
> end of the month.
It is probably doa
В Tue, 01 Jan 2019 16:24:29 +0100, Gürkan Myczko написа:
> I think it would be great to have that new release for the next Debian
> release which is going to happen soon:
I believe it's too late for that. GUI would need its SONAME bumped which
would mean we'll have to do a transition, but the
В Tue, 20 Mar 2018 13:04:15 +, David Chisnall написа:
> For most projects, I would do this by using out-of-tree builds, but
> this doesn’t appear to work for GNUstep. Is there a mechanism for
> doing this that I can’t find, or is it just a limitation of the
> build system?
It is easy to add
В Fri, 16 Mar 2018 14:57:53 +0100, Riccardo Mottola написа:
> The crashes happen either when the pool is released in line 224 and
> NSData or in the setter of one of the properties, as the first stack
> or with a crash at line 181, which is still inside this method.
You haven't posted a
In Source/Makefile.postamble, optimization is explicitly turned off
for NSConnection.m and NSInvocation.m. This was made in August 1999
(commit 90f2d8a). I can imagine the reasoning but is it still
relevant?
I tried a build with default (-O2) optimization and I don't observe
any regression, at
В Thu, 04 Jan 2018 14:31:34 +1100, Svetlana Tkachenko написа:
> On a source based distro configuration options are exposed to the
> users but on Debian they are not and they may need to be separate
> packages.
We can build multiple binary packages from one source package. This
was David's
В Tue, 02 Jan 2018 07:37:35 +, David Chisnall написа:
> On 2 Jan 2018, at 07:29, Yavor Doganov <ya...@gnu.org> wrote:
>> В Tue, 02 Jan 2018 07:20:39 +, David Chisnall написа:
>>> Is there a good reason why we release -back as a separate package?
>>
&g
В Mon, 01 Jan 2018 23:07:11 +, Ivan Vučica написа:
> Cutting no-changes releases of back is not fun. Do we need to do it?
> Will -gui reject -back with mismatching minor version?
Debian's current packaging requires full match between the GUI/Back
versions, but that's easy to change (I
В Tue, 12 Dec 2017 10:24:27 +, David Chisnall написа:
> On 11 Dec 2017, at 21:04, Yavor Doganov <ya...@gnu.org> wrote:
>> Superfluous bumping is not so bad as retaining the SONAME if
>> there's ABI breakage but it's not a good practice and leads to
>> unnecessary b
В Mon, 11 Dec 2017 09:45:04 +, Richard Frith-Macdonald написа:
> As far as I know there should be nothng that breaks binary
> compatibility (so I'd have made it 1.25.1), but if people want a new
> library version number I don't see any problem with that.
Please don't bump the SONAME if the
В Fri, 08 Dec 2017 10:55:14 +, Ivan Vučica написа:
> On Fri, Dec 8, 2017, 10:18 Yavor Doganov <ya...@gnu.org> wrote:
> I will sign the tag with my personal key (otherwise GH would not display
> it as verified) and I will sign the tarball with the shared maintainer
> ke
В Thu, 07 Dec 2017 22:57:39 +, Ivan Vučica написа:
> Actual signature *will* be performed with the correct maintainer GPG
> key!
I don't quite understand this sentence -- does it mean that the actual
tag/release at the official GitHub GNUstep repository will be signed
with the GNUstep
[Apologies for replying to an old message.]
В Fri, 29 May 2015 13:50:19 +0200, Luboš Doležel написа:
> Dne 29.5.2015 13:40, Stefan Bidigaray napsal:
>> OK, so people have said Savannah doesn't fulfill our needs, but never
>> explained how so? And how github manages to do so? Ivan mentioned
>>
В Thu, 17 Jul 2014 19:49:38 +0200, Sebastian Reitenbach написа:
DKEndpointManager.m:282: internal compiler error: in extract_insn, at
recog.c:2077
ICE is a GCC bug; please report it with the preprocessed source. Which
version is this? I think I've seen that before, thought it was fixed
long
В Sat, 18 Sep 2010 14:04:15 -0400, Gregory Casamento написа:
3) The original reason we did this was due to the fear of the
Trademark police,
If you decide to go on with renaming, I'd suggest to recheck with the
FSF lawyers, just in case.
but other projects which have attempted to implement
David Chisnall wrote:
On 21 Sep 2010, at 10:03, Yavor Doganov wrote:
but other projects which have attempted to implement Cocoa have used
the names Foundation and AppKit without any problems.
That is not a reason to feel safe
Yes it is. The Doctrine of Latches applies.
True
В Fri, 17 Sep 2010 09:30:51 +0100, Nicola Pero написа:
FHS is a Linux 'standard', not a *NIX standard.
Actually, the FHS requires the same ;-)
Right. Also, it's incorrect to call it Linux standard. The FHS is
derived from the GNU Coding Standards, which is perhaps the oldest
document
В Fri, 17 Sep 2010 10:16:41 +0100, David Chisnall написа:
On 17 Sep 2010, at 09:20, Nicola Pero wrote:
The public NSBundle API works fine with FHS.
That is my impression too.
The problem seems to be that frameworks are no longer found in the
frameworks directory,
Probably a bug in the
В Fri, 17 Sep 2010 10:36:08 +0100, David Chisnall написа:
On 17 Sep 2010, at 09:52, Yavor Doganov wrote:
Right. Also, it's incorrect to call it Linux standard.
Sorry, a GNU/Linux standard or a GNU standard then (since it seems
to be used by HURD and Debian/kFreeBSD too).
No, the GNU
В Fri, 17 Sep 2010 10:36:08 +0100, David Chisnall написа:
I know that we have packages for Arch, for Gentoo, for FreeBSD, for
OpenBSD, and for NetBSD that do not use the FHS layout.
BTW, both Gentoo and Arch have committed to adhere to the FHS, so
having non-compliant packages is only a proof
SPUeNTRUP - Kai Henningsen wrote:
Am Fri, 17 Sep 2010 10:00:37 + (UTC)
schrieb Yavor Doganov ya...@gnu.org:
The FHS people *tried* to make it widely adopted by soliciting
input from many parties, and failed. They probably failed because
they didn't listen at all to that input.
Well
В Mon, 13 Sep 2010 12:58:20 +0100, David Chisnall написа:
GNU ObjC
has so few users that it seems hardly worth the effort to upgrade the
GNU ObjC front end to ObjC 2.0. And there are other issues:
Translation: The GNU project doesn't care about GNUstep.
Wrong.
A plea for help has been at a
Fred Kiefer wrote:
Am 28.08.2010 19:52, schrieb Yavor Doganov:
Another question: Is the fix going to be ABI-compatible with 0.18?
If you insist on ABI compatibility the best thing I can do is this
horrible hack.
Well, I'm not in the position to insist on anything. I prefer the fix
Fred Kiefer wrote:
Am 29.08.2010 11:13, schrieb Yavor Doganov:
But if you want the fix included in 0.18.1, it has to be
ABI-compatible with 0.18.0 according to the GNUstep release policy...
This change definitely is ABI compatible.
Yes, I meant to say ...if you want a clean fix included
Cenon 3.83 works correctly with GUI 0.16, but with 0.18 dies with
Cenon: Uncaught exception NSInternalInconsistencyException, reason:
Abstract model loader.
Breakpoint 1, -[NSException raise] (self=0x8594358, _cmd=0xb7b387c0) at
NSException.m:946
946 NSException.m: Няма такъв файл или
В Wed, 25 Aug 2010 19:12:36 +0100, David Chisnall написа:
[2] So can the rant about how the ChangeLog requires developers to
remember to manually track stuff that svn tracks automatically.
ChangeLogs are required by the GNU Coding Standards. (It is not
necessary to maintain them manually,
On GNU systems at least, with modern versions of gnustep-base, there is
no need to set NSLanguages at all, so I stopped doing it except on hosts
with ancient GNUstep installatons. Base is smart enough to infer the
correct setting from the system/user default locale, even respecting the
Riccardo Mottola wrote:
Yavor's patch is in theory correct, but in practice wrong. GLIBC is a
mess to work with.
It becomes a mess if you start playing with defines, yes.
Furthermore, you have to adjust them for every new porting target.
I already tried to make the original code which used
David Chisnall wrote:
I'm not sure why this explicit cast should be required. The type of
both of these should be pthread_mutex_t.
foo.c:
==
#include pthread.h
int
main (void)
{
pthread_mutex_t foo;
foo =
Yavor Doganov wrote:
Riccardo Mottola wrote:
now using __GLIBC__ causes troubles on Hurd with GCC (and possibly
other platforms which I don't remember),
The Debian archive is full of code like this, so it's strange that it
causes trouble. What is the specific error?
Without having
Riccardo Mottola wrote:
Well, I just check for GNU and GLIBC as
http://glibc-bsd.alioth.debian.org/porting/PORTING
suggests, which is a debian porting document!
Right, and I already corrected myself. I confirm my initial patch
attached to the bug is not OK.
(For the record, I still retain my
В Tue, 16 Feb 2010 18:17:23 +0100, Niels Grewe написа:
some months back, somebody complained that gnustep-base took ages for
them to build on a machine without network access. The problem was that
the gsdoc DTDs were not yet installed and autogsdoc was trying to fetch
them over the net, making
В Thu, 13 May 2010 16:24:09 +0200, Niels Grewe написа:
It was committed in revision 29654.
Ah, thanks. I realize now why I thought it was not merged -- the log
message says Patch by Niels Grewe and there is no corresponding
ChangeLog entry.
(The frivolous violation of the established (and
В Wed, 24 Feb 2010 10:42:41 +0100, Fred Kiefer написа:
if there are participate in a bigger GNU envelop project?
Just to mention that since GNUstep is part of the GNU project, it is
perfectly possible to participate under the GNU umbrella.
___
David Ayers wrote:
gnustep-dl2-nox(-dev)
EOControl/EOAccess
That's OK, but the runtime library package name should embed the
soname, e.g. gnustep-dl2-nox-0. Furthermore, we'll get 2 lintian
warnings `package-name-doesnt-match-soname' while if it is libeoaccess
there would be only one (for
Matt Rice wrote:
Sorry It just hit me that both DBModeler and GDL2 palette use the
EOModeler library which might pose a problem for making EOModeler
'private'
That's not a problem at all -- both will link against EOModeler with
RPATH, which will be shipped in the same binary package.
Matt Rice wrote:
Likewise, this should be libeointerface0/libeointerface-dev. But
you didn't mention EOModeler. Is its place here, too?
Ahh, yeah I forgot about that library, no EOModeler can go in its own
libeomodeler
But the goal is to decrease the number of the binary packages as
Matt Rice wrote:
Yavor mentions that (although they're intended to be public
libraries, nothing in GNUstep uses them)
Oh, that was misleading. What I meant is that no package in Debian
currently uses gnustep-dl2 (its libraries or whatever).
but DBModeler isn't really a standalone
Federico Giménez Nieto wrote:
2010/1/4 Matt Rice ratm...@gmail.com:
Ahh, sorry I meant the 'package GDL2Palette bundle with DBModeler',
adding a dependency on the existing Gorm.app package to it,
Yes, in my opinion it should be enough to add a dependency on gorm.app
to the new
(Typo fixes to avoid possible confusion; sorry.)
Явор Доганов wrote:
Every shared library (in /lib and /usr/lib) should be packaged as
libfooN and libfoo-dev (in rare cases libfoo2-dev).
s/libfoo2-dev/libfooN-dev/
that use the library to depend on libfoo-dev and to automatically
.
This patch reverts the (good) changes to support
:script/:lang/:otf in the NS font driver, because they rely on
the NSFontDescriptor class which is not implemented in the old
version of GNUstep GUI available in gNewSense.
Provided by: Yavor Doganov ya...@gnu.org
lisp/term/ns-win.el | 13
В Mon, 15 Jun 2009 19:54:49 +0200, Riccardo Mottola написа:
On the other hand, on Debian, if you have gworkspace you want libsqlite
which on Debian is configured to use libicu so you end up using it.
This change was reverted recently:
В Sun, 14 Jun 2009 18:56:40 +0100, Richard Frith-Macdonald написа:
On 14 Jun 2009, at 17:20, Dave MacLachlan wrote:
Google has signed off on having them submitted to the project, so the
legal steps are taken care of already.
Including copyright assignment to the FSF? That's a requirement
On Wed, May 20, 2009 at 11:24:39AM +0100, Richard Frith-Macdonald wrote:
I think what you are describing (as the correct way to do things) is
what GNUstep already tries to do ... see
http://mediawiki.gnustep.org/index.php/GNUstep_release_policy for the
actual release policy details.
On
Richard Frith-Macdonald wrote:
On 20 May 2009, at 11:53, Yavor Doganov wrote:
The SONAME of a shared library should be bumped if and only if
there is ABI break
That's a matter of opinion.
Yes, the opinion of the library maintainer(s), which ideally should
conform to best practices
В Fri, 13 Mar 2009 13:00:19 -0600, Adam Fedor написа:
We had a long discussion about this before
Yes, I remember it.
that ended in the request that stable releases have no ABI or API
changes (even additions), so that a developer and user could count
on the same set of functionality in a
В Wed, 11 Mar 2009 12:53:56 +, David Chisnall написа:
It is very easy to have a stable ABI for a procedural API because
there is no notion of subclassing. Even with GObject this is not
really a problem, as it doesn't really present an OO model.
Right you are. Even then, after years of
В Mon, 09 Mar 2009 22:23:25 +0100, Riccardo Mottola написа:
If we compare to other projects like glib2, gtk2: fine-grained packages
like debian will give you udpates only when necessary
Glib/GTK+ have a stable API/ABI throughout the whole lifetime of the
GNOME 2 platform. If you upgrade from
Hi Gürkan,
A trivial patch for this build failure is available here:
http://emacsbugs.donarmstrong.com/2264
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
[CC-ing emacs-devel instead of bug #1171, as this is a general problem.]
At Wed, 12 Nov 2008 14:19:10 -0500,
Adrian Robert wrote:
On Nov 12, 2008, at 2:11 PM, Yavor Doganov wrote:
Stefan Monnier wrote:
(better fix the underlying problem and get dumping to work for
GNUstep).
Does
В Fri, 06 Jun 2008 02:17:10 -0700, Gregory John Casamento написа:
So you think we should target the end of the month to make the release?
It would be too late for Debian, I'm afraid. According to [1] all
libraries will be frozen at the end of this month. Of course we could
always ask the
Hubert Chathi wrote:
Until the LGPL3/GPL2 issue is resolved, those are the latest
versions that we can have in Debian, or else we'd have to get rid of
Terminal.app (and a few other packages) from Debian.
It's a judgement call. IMVHO we should not hold a major GNUstep
update just for this,
Hubert Chathi wrote:
Perhaps we should take a quick poll.
This is an excellent idea, but how do you expect to do it? The lists
this discussion is being carried on have limited audience. Of course
the opinion of the gnustep-dev subscribers is valuable, and that of
the main GNUstep maintainers
В Mon, 14 Apr 2008 14:32:43 -0400, Hubert Chathi написа:
I don't think that the combined work still violations LGPLv3, because
section 4 of the LGPLv3 allows you to release the combined works under
any license that you choose, provided that you do certain things, and
the library itself can
В Sun, 13 Apr 2008 21:30:52 -0400, Hubert Chathi написа:
Just a thought that came to me, that I thought I'd throw out: one
possibility is to dual-license the GNUstep libraries under bath GPLv2
and LGPLv3 or later. This would allow us to keep GPLv2 applications
(the two big ones that I know
В Fri, 11 Apr 2008 18:42:15 -0400, Hubert Chathi написа:
On Fri, 11 Apr 2008 09:08:52 + (UTC), Yavor Doganov [EMAIL PROTECTED]
or http://price.sourceforge.net/exception.html
What problems do you see with it?
IMVHO such an exception *might* fix one side of the problem, but the
resulting
Thanks for raising the issue, and the summary.
В Thu, 10 Apr 2008 13:51:08 -0400, Hubert Chathi написа:
or http://price.sourceforge.net/exception.html
I am not sure that such an exception is sufficient to eliminate the
incompatibility problem -- in fact, I fear that it may not have a legal
В Fri, 04 Jan 2008 17:44:38 +0100, Fred Kiefer написа:
http://www.gnu.org/links/links.html#FreeGNULinuxDistributions
A asked some time ago about this but nobody replied:
http://article.gmane.org/gmane.comp.lib.gnustep.general/29151
This specific text was not written by RMS, but by one of the
Is there any development regarding this?
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Adam Fedor wrote:
Last I heard, I had given RMS what we wanted to say and he said he
would get some one to put it on the web site. But then I forgot about
it and I've lost the email from him. Perhaps I should follow up.
I spoke with John Sullivan and he confirmed that he was supposed to do
В Sun, 10 Sep 2006 12:30:14 +0200, Chris Vetter написа:
however, you *should* keep in mind that originally GNUstep was
supposed to be the development (and desktop?) environment of choice
for the GNU operating system...
This is still more or less true -- with GNOME being steadily absorbed
by
Lars Sonchocky-Helldorf wrote:
This is ideological thinking.
Free software is extremely ideological, political and social by
nature. The ultimate goal of the GNU Project is to change the
society.
But if you want to achieve an objective
in practice you'll have to think practically and
Helge Hess wrote:
Free commercial apps are welcome, but not proprietary ones.
Obviously this is non-sense. If proprietary apps wouldn't be welcome,
GNUstep would be
GPL, not LGPL. GNUstep is LGPL to explicitly allow for that.
Let me rephrase it: the fact that the core GNU libraries are
69 matches
Mail list logo
