Re: Bug fix release to address broken nib loading...

[Yavor Doganov]

On Wed, 05 Jun 2024 03:26:09 +0300,
Gregory Casamento wrote:
> Let us do another release of GUI to address the recent issue with
> nib loading.

Thanks for making a new release; this kind of regression is certainly
important enough to warrant it.

I don't know what went wrong but it looks like the signature at
ftp.gnustep.org is bad:

$ gpg --verify --verbose gnustep-gui-0.31.1.tar.gz.sig 
gpg: enabled compatibility flags:
gpg: assuming signed data in 'gnustep-gui-0.31.1.tar.gz'
gpg: Signature made  6.06.2024 (чт) 12:39:51 EEST
gpg:using DSA key 83AAE47CE829A4146EF83420CA868D4C99149679
gpg:issuer "gnustep-maintai...@gnu.org"
gpg: using pgp trust model
gpg: BAD signature from "GNUstep Maintainer " 
[unknown]
gpg: binary signature, digest algorithm SHA1, key algorithm dsa1024

For Debian it doesn't matter much because even a good signature is
rejected by current dpkg:

dpkg-source: info: verifying ./gnustep-base_1.30.0.orig.tar.gz.asc
gpgv: Signature made Wed May 29 19:34:34 2024 UTC
gpgv:using DSA key 83AAE47CE829A4146EF83420CA868D4C99149679
gpgv:issuer "gnustep-maintai...@gnu.org"
gpgv: Note: signatures using the SHA1 algorithm are rejected
gpgv: Can't check signature: Bad public key
dpkg-source: warning: cannot verify upstream tarball signature for 
./gnustep-base_1.30.0.orig.tar.gz: no acceptable signature found

I'm pretty sure I told Ivan about this some time ago.  (It's not a
problem that impedes our work but would be nice to fix in the near
future.)

Re: Base 1.28.1 API/ABI break?

[Yavor Doganov]

Andreas Fink wrote:
> Failed test: (2023-01-09 08:48:49.174 +0100) general.m:37 ... 
> -classNamed returns the correct class
> Failed test: (2023-01-09 08:48:49.175 +0100)   general.m:61 ... 
> -principalClass returns TestClass for +bundleForClass:[TestClass class]

Usually this is an indication that you have an older gnustep-base
version installed; some NSBundle tests are doomed to fail in this
case.  Try building in a clean environment.

> Failed set:basic.m:9 ... problem in TLS support.

Missing gnutls-bin package?  Current code invokes certtool under the
hood for generation of self-signed certificates when necessary.

Re: Base 1.28.1 API/ABI break?

[Yavor Doganov]

Fred Kiefer wrote:
> > Am 07.01.2023 um 19:42 schrieb Yavor Doganov :
> > But when build-testing packages with GUI 0.30.0 I came upon this
> > build failure of GDL2:
> 
> Which version of GDL2 are you getting this warnings from? I think
> the code in question was removed more than ten years ago. But then
> the last release of GDL2 was 2009. Maybe a new release is required
> here?

It's 0.12.0.  GDL2 is in terrible shape in Debian, unfortunately.  We
would very much appreciate a new release in the closest future.

I don't think we can use a new GDL2 release now as it would be
incompatible with the version we have (which itself has a
Debian-specific SONAME -- we were forced to bump it some time ago
after a change that was necessary to build with new GNUstep).

Re: Base 1.28.1 API/ABI break?

[Yavor Doganov]

Riccardo Mottola wrote:
> On 1/8/23 09:32, Yavor Doganov wrote:
> > But given that Pantomime also fails to build
> 
> does Pantomime fail to build also due to string encoding constants?

Yes, version 1.3.0.  The fix is trivial, so no problem here.  As I
wrote you earlier in a private conversation, we can always upload a
new Pantomime release later provided that it's ABI-compatible.

Re: Base 1.28.1 API/ABI break?

[Yavor Doganov]

Richard Frith-Macdonald wrote:
> > On 7 Jan 2023, at 18:42, Yavor Doganov  wrote:
> > But in this case we'll certainly miss the deadline and we'll end
> > up with Base/1.28.0 and GUI/0.29.0 in the new Debian release.
> 
> How certainly?
> I could bump the gnustep-base release version today (8 Jan).

Well, I'm not sure we'll succeed even without this problem.  GUI is
not yet built on a bunch of architectures...  Reuploading Base means
another round through the so called NEW queue, then rebuilding GUI and
test-building all packages again.  Some of the autobuilders are
extremely busy these days so progress is slow.

We have only few days left, and there are other transitions already
approved that are entangled with GNUstep (tiff, imagemagick, poppler).

But given that Pantomime also fails to build (and who knows what else,
I mean third-party non-packaged stuff) perhaps it is safer to proceed
with a new release and try to do the impossible to catch the deadline.

Base 1.28.1 API/ABI break?

[Yavor Doganov]

While reviewing the diff between 1.28.0 and 1.28.1 I noticed changes
to the ivar layout of GSTLS, NSPort and some other class I can't
remember right now.  Granted, these are unlikely to be subclassed, so
I thought we could sneak this in Debian unstable without problem and
without being punished.

But when build-testing packages with GUI 0.30.0 I came upon this build
failure of GDL2:

gcc EOAdaptor.m -c \
  -MMD -MP -Wdate-time -D_FORTIFY_SOURCE=2 -DGNUSTEP_BASE_LIBRARY=1 
-DGNU_RUNTIME=1 -g -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1 
-DGNU_RUNTIME=1 -DGNUSTEP_BASE_LIBRARY=1 -fno-strict-aliasing -fexceptions 
-fobjc-exceptions -D_NATIVE_OBJC_EXCEPTIONS -pthread -fPIC -Wall -DGSWARN 
-DGSDIAGNOSE -Wno-import -g -O2 -g -O2 
-ffile-prefix-map=/build/gnustep-dl2-0.12.0=. -fstack-protector-strong -Wformat 
-Werror=format-security -DDEBUG -fconstant-string-class=NSConstantString 
-I../EOControl/. -I.. -I. -I/usr/local/include/GNUstep -I/usr/include/GNUstep \
   -o obj/EOAccess.obj/EOAdaptor.m.o
EOAdaptor.m:132:39: error: 'NSGB2312StringEncoding' undeclared here (not in a 
function); did you mean 'NSHZ_GB_2312StringEncoding'?
  132 |   { @"NSGB2312StringEncoding",NSGB2312StringEncoding },
  |   ^~
  |   NSHZ_GB_2312StringEncoding
EOAdaptor.m:135:39: error: 'NSBIG5StringEncoding' undeclared here (not in a 
function); did you mean 'NSBig5StringEncoding'?
  135 |   { @"NSBIG5StringEncoding",  NSBIG5StringEncoding },
  |   ^~~~
  |   NSBig5StringEncoding
make[6]: *** [/usr/share/GNUstep/Makefiles/rules.make:521: 
obj/EOAccess.obj/EOAdaptor.m.o] Error 1

These encodings were renamed which (IMVHO) should not happen in a
point release that should be fully compatible.  There's a similar
error when building SOPE (not maintained by us, Debian GNUstep team).

The question is, what to do now?

Usually, the correct course of action is to revert the upload to
Debian and wait for upstream to make another release with a bumped
SONAME.  But in this case we'll certainly miss the deadline and we'll
end up with Base/1.28.0 and GUI/0.29.0 in the new Debian release.

Another solution, which I prefer right now as we are seriously pressed
by time, is to upload a fixed gnustep-dl2 package, send a patch to the
sope maintainer and hope that the release team won't insist for the
revert themselves.

Re: Freeze dates for Debian's next release

[Yavor Doganov]

On Tue, 22 Mar 2022 19:36:55 +0200,
Yavor Doganov wrote:
> FYI, Debian has announced[1] the preliminary freeze dates in
> preparation for the next stable release 12 (bookworm):
> 
> 2023-01-12  - Milestone 1 - Transition and toolchain freeze
  --
> 2023-02-12  - Milestone 2 - Soft Freeze
> 2023-03-12  - Milestone 3 - Hard Freeze - for key packages and
> packages without autopkgtests
> To be announced - Milestone 4 - Full Freeze

Reminding you that the above schedule is still unchanged and it would
be nice to have the new GNUstep release(s) by the end of December or
the first January dates.  The first date is the important one for us.

> I will send a reminder/update around the summer or whenever there is
> a serious change in the schedule.

Failed to do that (again), sorry...

> [1] https://lists.debian.org/debian-devel/2022/03/msg00251.html

Freeze dates for Debian's next release

[Yavor Doganov]

FYI, Debian has announced[1] the preliminary freeze dates in
preparation for the next stable release 12 (bookworm):

2023-01-12  - Milestone 1 - Transition and toolchain freeze
2023-02-12  - Milestone 2 - Soft Freeze
2023-03-12  - Milestone 3 - Hard Freeze - for key packages and
packages without autopkgtests
To be announced - Milestone 4 - Full Freeze

IOW, to get into the next Debian release GNUstep core should plan
releasing around December this year, ideally before Christmas.
Apps like Gorm/GAP/etc can still get in if released Jan/Feb 2023
provided they don't contain a library/framework with incompatible
changes in the new release(s).

I will send a reminder/update around the summer or whenever there is a
serious change in the schedule.

[1] https://lists.debian.org/debian-devel/2022/03/msg00251.html

Re: GNUstep on Hackernews

[Yavor Doganov]

On Wed, 22 Dec 2021 22:54:32 +0200,
Ivan Vučica wrote:
> On Fri, Dec 17, 2021 at 9:34 AM Andreas Fink  wrote:
> > packages in Debian are quite old
> 
> Inaccurate.

It is both accurate and inaccurate.  More precisely, at times it is
accurate and at times it is inaccurate; it also depends what Debian
release you use for comparison.  It is inevitable that a stable
release at some point starts qualifiying as one one with "old" or even
"quite old" packages, even with best of our effort.

> At release times, I usually try to coordinate with Debian packagers.
> This time, it took a bit longer, but uploads happened in November and
> December.

This is my personal fault; I failed to coordinate with you and inform
in advance about Debian's release schedule so the current GNUstep core
releases happened at a time we couldn't include them in the current
Debian stable release (bullseye).  Then I was waiting for my sponsor
for more than 6 months for the upload of gnustep-make and subsequently
current GNUstep releases were introduced in Debian unstable with a
great delay.

> > and don't support objc2.0.
> 
> The issue here is Debian preferring to build things with GCC over
> Clang.

I'm quite certain that I've explained at least once in great detail
why this is so, on this list.  As there are still questions popping up
here and there, I intend to write a specific chapter regarding this
subject in the not-yet-finished Debian GNUstep team policy document.
It will be installable as a Debian package and the repository will be
public, like almost everything in Debian.

> If we can convince the (very kind in their efforts) maintainers of
> the packaging to try to package with Clang and libobjc2, we'd be
> golden.

The thing is, Debian is no longer a distro where a member of the
project can upload its pet package and keep it under custody until he
is formally declared maintainer.  Packages are being aggressively
removed nowadays, on the grounds of being obsolete, unpopular,
unmaintained, or with unresponsive upstream.  We fought hard with the
Debian stweards some 15 years ago for GNUstep to remain and I foresee
more battles on the horizon.

The automatic reaction of these people is to "get rid" and that's
natural.  From a Debian ftpmaster POV, a change which requires plenty
of manual action + coordination between teams and does not bring any
real benefit to the current packages is a poor change.

> I believe Yavor and Gurkan are subscribed to (some of) GNUstep
> mailing lists.

FWIW, I'm reading all GNUstep lists + (Savannah) bug traffic +
(GitHub) commit notifications + GAP + (not sure) gnustep-nonfsf.  I'm
only subscribed to some of them though, the bulk of it I follow via
Usenet (Gmane), sometimes with delay.

Re: HelpViewer 0.3 : error while linking

[Yavor Doganov]

On Sun, 21 Jun 2020 11:27:27 +0300,
Patrick Cardona via Discussion list for the GNUstep programming environment 
wrote:
> If I get some package from deb source and I try to rebuild it as the
> Debian doc says (1) I am afraid this could make a dependency conflict
> with the apps already installed by hand.

Just use the .orig.tar.gz from the Debian source package and apply the
patches as you would normally do with a regular tarball/source tree.
No need to build the .deb; it wouldn't work anyway as you're using the
GNUstep runtime.

> Do You think the best way is : I could get the deb source, apply the
> patch and make them by hand ?

Yes, ignore all Debian docs -- they are irrelevant for your use case.

Re: HelpViewer 0.3 : error while linking

[Yavor Doganov]

Riccardo Mottola wrote:
> However, the application barely functions for me when I open one of
> the examples. Most of the titles are displayed with a blue box, which
> I bet is an artifact of some sort.
> Many warnings too let's see if I can fix them all!

Take a look at the Debian patches [1]; most of these issues are
fixed.  At least it is able to display its own help and there are no
compilation warnings.

[1] https://sources.debian.org/src/helpviewer.app/0.3-8/debian/patches/

Re: Applications Folder in the System Domain

[Yavor Doganov]

Patrick Cardona via Discussion list for the GNUstep programming environment 
wrote:
> pi@raspberrypi:~ $ gnustep-config --variable=GNUSTEP_LOCAL_APPS
> /usr/local/lib/GNUstep/Applications

That's for the LOCAL domain; GNUstep apps installed via the system's
package manager(s) (apt, aptitude, synaptic, gnome-software, etc.) are
at /usr/lib/GNUstep/Applications (GNUSTEP_SYSTEM_APPS).

> But the installation of the apps is wrong as I show it in my
> previous message.

That's because you are visting the wrong directory.

> The 'Applications' folder is missing. Maybe this is the reason why I
> can't open apps from #o commmand within GWorkspace...

It works for me on a Debian system (naturally, I mean
/usr/lib/GNUstep/Applications).

Re: Applications Folder in the System Domain

[Yavor Doganov]

On Sat, 23 May 2020 01:09:55 +0300,
Patrick Cardona via Discussion list for the GNUstep programming environment 
wrote:
> As I can remember, there was an "Applications" folder where the apps 
> installed in the System Domain could be found.

On Debian and Debian-based systems this is
/usr/lib/GNUstep/Applications.

Re: Graphos.app : error whith make

[Yavor Doganov]

On Thu, 21 May 2020 21:22:45 +0300,
Patrick Cardona via Discussion list for the GNUstep programming environment 
wrote:
> Doing that, I could isolate the case where the obsolete var was declared : 
> obviously, it is due to WindowMaker.
> The wersion of WindowMaker installed from raspbian Buster is : 
> Window Maker 0.95.8 

Right; this is a WindowMaker bug which is fixed in 0.95.9 -- see
https://bugs.debian.org/922284.  I don't know how/when it will
propagate to Raspbian though.

> I am searching now where and how WindowMaker define the obsolete var.

It's set by /usr/bin/wmaker which is a shell script.

Re: Which ObjC2.0 features are missing in the latest GCC?

[Yavor Doganov]

Johannes Brakensiek wrote:
> On 25 Nov 2019, at 14:34, Yavor Doganov wrote:
> > Off the top of my head, Rik theme is about the single piece of
> > software that can't be built on stock Debian because of us
> > sticking to GCC.
> 
> thank you for making clear your point. I understood GNUstep would
> have to provide an updated runtime for all supported architectures
> and upstream software/applications that rely on clang and its
> features to make the Debian maintainers distribute it.

No, that was not my point and nowhere near to what I said.  Debian
will consider moving to Clang and the new runtime when:

1. The pool of new software is large and worthy enough to justify the
   major regression that is dropping support for about half of the
   architectures.  It means there has to be much more than Rik that we
   can't build and package now.  And it appears Rik is buildable with
   GCC, albeit a less capable version.  So it's not even a proper
   example.

2. The release team approves building an entire software stack with a
   non-default compiler and as a direct consequence dropping
   architecure support.

3. There is someone willing to do the actual work and carry out such
   transition.  That's always the case in Debian for any kind of work.

If GNUstep upstream drops GCC support, 1) will become pointless but 2)
and 3) remain.

If GNUstep upstream continues GCC support and the condition outlined
in 1) does not change, we'll stick to GCC.  We will not move just
because of some blurry promise for great new software.  I've seen this
before and it's nothing more than a wet dream.

Re: Which ObjC2.0 features are missing in the latest GCC?

[Yavor Doganov]

David Chisnall wrote:
> On 25 Nov 2019, at 13:37, Yavor Doganov  wrote:
> > RISC-V is the newest GNU/Linux architecture and it's not yet
> > supported by Clang.
> 
> Yavor, I appreciate that this is an emotional topic for you, but
> please can you try to confine yourself to the truth?

The truth is that none of the llvm-toolchain-* packages ever built on
Debian's ricv64 autobuilders.  Not even once.  Which means that if we
are going to build GNUstep with Clang in Debian, it won't be available
on riscv64.

This is likely to be fixed in the near future but I'm talking about
the reality now.

Re: Which ObjC2.0 features are missing in the latest GCC?

[Yavor Doganov]

Bertrand Dekoninck wrote:
> > Le 24 nov. 2019 à 02:24, Yavor Doganov  a écrit :
> > except probably the Rik theme
> 
> Just my two pence here : I’ve got a gcc compatible branch of rik
> (which I maintain for my ppc computers) at 
> https://github.com/BertrandDekoninck/rik.theme/tree/no_objc2

Thanks, I didn't know about this.  It was on my TODO to make it build
with GCC so it's great that it's done already.

The main reason why the Rik theme is not yet packaged for Debian is
because there's been no release yet.  I feel uncomfortable to package
software that is unreleased as it can be damaging for the upstream
developers' reputation in case there are still known bugs, etc.  I
know the theory that "every new commit is a new release" but it only
works if the downstream maintainer is familiar with the code and can
exercise proper judgement what snapshot to put in a stable distro
release.

(FYI, Debian doesn't require generated tarballs, a Git tag will
suffice.  Preferably signed.)

Re: Which ObjC2.0 features are missing in the latest GCC?

[Yavor Doganov]

Gregory Casamento wrote:
> On Fri, Nov 22, 2019 at 3:01 PM Yavor Doganov  wrote:
> > The answer is simple: because there's a lot to lose and nothing to
> > gain.

> This is patently incorrect.  The gain is time and compatibility with
> the latest code base.  I laid out the advantages and disadvantages
> of this in my previous posting.

There are no advantages for the current GNUstep packages in Debian
which is the main point I was trying to make.  I don't dispute the
fact that dropping support for GCC will simplify things a lot for
you.  At certain cost, of course, which you consider negligible.

> * More Applications, more applications means more end users (sort of
> chicken and egg thing)

That's purely hypothetical to the extent of being mere speculation.
GNUstep supports Clang and David's runtime for quite some time now,
why there are no more applications?  Why existing GNUstep applications
have not been updated to take advantage of the new features?

> What's to lose:
> * Possibly a political issue with the FSF, but there are other projects
> which depend on languages not implemented by GCC.

I'm not aware of any GNU package written in a compiled language that
cannot be built with GCC.

I don't know what you mean by "political issue" but such a drastic
change should be discussed with the GNU Project of which GNUstep is
still part of.  It is wrong to decide it with a vote that doesn't even
specify simple things like who is eligible to vote and based on what
majority the decision is going to be taken.  As a GNU maintainer you
should know these things.

> * Support for older platforms which ONLY support gcc.

RISC-V is the newest GNU/Linux architecture and it's not yet supported
by Clang.

> So, I apologize if I don't agree with the "nothing to gain" opinion.

You are free to disagree.  But as it often happens with real life, the
loss may become obvious only post factum...  You could be left only
with the "gain" which may not look like a big gain then.  It could
even look more like you have shot yourself in the foot.

Re: Which ObjC2.0 features are missing in the latest GCC?

[Yavor Doganov]

Johannes Brakensiek wrote:
> On 24 Nov 2019, at 14:16, Yavor Doganov wrote:
> > Packaging libraries and development tools just because they are cool
> > and it is expected that hordes of developers will write useful
> > programs that utilize them is not a useful activity -- you have to
> > justify their inclusion in the distro and a hypothetical future
> > benefit is not a good argument.
> 
> Well, I think different about this (otherwise Apple f.e. would never
> have shipped any new software I think), but we can agree to disagree
> here.

TBH, I don't give a flying flute what Apple ships and how; it is
irrelevant anyway.  I described the way things work in the Free World
and Debian, in particular.

> I also typed apt-get install gnustep-devel and I was provided an IDE
> that looked like it jumped out of the 90s.

JFTR, you'd get exactly the same IDE with exactly the same
capabilities if GNUstep was configured to use the "modern" features.

> I thought: Oh, not that bad, I can use Xcode and compile then. But I
> could not because the tools installed were not able to compile
> f.e. Rik.theme or .m files using recent language features.

Off the top of my head, Rik theme is about the single piece of
software that can't be built on stock Debian because of us sticking to
GCC.  NEXTSPACE relies on custom patches to GNUstep core, which means
that you'll have to build your own GNUstep environment anyway so you
may as well configure it for Clang and the new runtime.

> So, please tell me which part of this story sounds most ridiculous
> to you?

The part that developers are waiting for Debian to move to Clang so
that they can start writing free GNUstep software.

> > Are these projects directly buildable/runnable with GNUstep
> > configured for Clang and the modern runtime?  I doubt it.
> 
> No, of course they are not. But they could some day if the GNUstep
> project would decide and be able to develop some way further. That’s
> my point.

And that is exactly my point.  There are other major obstacles to
porting free Cocoa software; switching to Clang will not help.
Therefore, the argument that a move to Clang will bring us new free
software is moot.

What will happen "some day", we don't know.  Chances are that there
will be a gazillion of new features that these Cocoa apps require and
GNUstep doesn't yet implement.  At least this is the evidence from the
past few decades.

Re: Which ObjC2.0 features are missing in the latest GCC?

[Yavor Doganov]

Johannes Brakensiek wrote:
> would it be possible to somehow ship a clang runtime on Debian or
> isn’t it? If it is how could it be achieved?

It is possible but not as an option/alternative.  Either the whole
GNUstep stack moves to Clang + the new runtime or it stays with GCC +
the GCC runtime.

To achieve the former, a preliminary discussion with the release team
must be held, to sound their opinion about dropping architectures for
about 85 packages, the transition plan and the way to solve the
inevitable file conflict between libobjc4 (the GCC runtime) and
for example libobjc2-4 (the new runtime).  That's where the GCC
maintainers' opinion should be taken into account.

I guess the release team won't have any objection to dropping
unofficial architectures but if s390x/ppc64el/mips* have to be dropped
as well there could be a problem.

Then a transition should be carried out, fixing all the bugs and
dealing with all the issues that will arise, both for the core
libraries and the reverse dependencies.

Oh, and a decent rationale for the switch must be provided.  If none
of the present packages will benefit from the switch, it is hard to
justify it.

> It seems to me you are making this a „the egg or the chicken“
> problem, which it isn’t.

Yes it is.  Libraries and development tools are building blocks that
help developers to write programs.  If a program is useful and worth
packaging, a Debian maintainer starts by packaging the tools and
libraries it needs and then by packaging the program itself.

Packaging libraries and development tools just because they are cool
and it is expected that hordes of developers will write useful
programs that utilize them is not a useful activity -- you have to
justify their inclusion in the distro and a hypothetical future
benefit is not a good argument.

> If you don’t provide new tools for developers they are not going to
> build new software for their users. It’s this way around not the
> other and it’s no dilemma at all.

So you are basically saying that just because Debian does not provide
the right tools there is no software written yet?  Sorry to say that
but it's a ridiculous statement.

> For me this cause is indeed a decision whether you are most
> comfortable with the state in which GNUstep currently is or if you
> would be more comfortable when it would develop to a further state,
> maybe one where most ObjC currently is. If you want it to develop the
> decision should be simple.

This is a bogus argument, GNUstep supports these new features and
developers who want to use them can do so.  Debian cannot stop them.

> Just one last thing to add: Cocoa/Mac software development is not
> the same as proprietary software development.

No, but free Cocoa software is in the same position as the "Java Trap"
back when Java was proprietary.  Here GNUstep comes to the rescue, but
very few of their developers value freedom.  They just want to get
their app on some store and that's it.

> - https://github.com/64characters/Telephone
> - https://github.com/subethaedit/SubEthaEdit
> - http://colloquy.info/
> - https://github.com/rburgst/time-tracker-mac

Are these projects directly buildable/runnable with GNUstep configured
for Clang and the modern runtime?  I doubt it.

Re: Which ObjC2.0 features are missing in the latest GCC?

[Yavor Doganov]

Ivan Vučica wrote:
> On Fri, Nov 22, 2019 at 8:02 PM Yavor Doganov  wrote:
> > The answer is simple: because there's a lot to lose and nothing to
> > gain.

> This is unfortunately wrong. There is a lot to gain.

Right or wrong depends on the point of view, which ultimtately boils
down to one's values and beliefs.  What is gain for some may be loss
for others.  It appears we have different values, hence the
discrepancy.

> Developers who want to start using Debian-built GNUstep libraries
> can start using tons and tons of features that GCC and GCC runtime
> do not support.

Developers who want to start using these new (not so new -- 10 years
old!) features have the option to build the environment they need on
top of Debian (if that is their distro of choice) or switch to another
distro that provides prebuilt packages.

But that is the wrong answer.

You, developers, tend to forget that free software is for users.
Developers are users too in a broad sense but they are a very small
part of the whole mass of people using a particular piece of software.
If these fancy features existed for 10 years, why they have not
inclined developers to write more free software that is relying on
them?  Surely that's not because Debian stopped them?  Or because the
GNUstep project is stopping them?

My task as a free software contributor (with the extremely limited
skills I have) is to help achieve the goals of the Free Software
Movement.  Providing "tons and tons of features" to developers who
don't care at all about free software (at least the majority of them)
and who won't write a single line of code for the cause I'm aligned to
doesn't strike me as the "right" thing to do.

I don't mind helping them as a side effect of helping free software.
In this case, however, it is all about them.

> - ARC is one.
> - Blocks is another.
> - @123 syntax for NSNumber (and similar stuff for arrays and dicts and
> more) is another.
> - Improved @property support is yet another.

This is like offering rocket fuel to someone who has a car with a
diesel engine.  None of the packages in Debian is using these
features, which is why I said there's nothing to win.  There's a queue
of software packages we intend to package in Debian but neither of
them depends on these things -- except probably the Rik theme and
NEXTSPACE (which are not suitable for packaging for other reasons).

Right now I'm working on a new upstream release of a package which
uses NSNotificationCener-addObserverForName:object:queue:usingBlock:.
This is a method which is declared and supposed to be supported even
with GCC, I just don't know the (GCC) syntax I'm supposed to use so
I'm experimenting with GCC nested functions as replacement.  If that
fails, I guess I'll solve it somehow, using a different approach.
That's the first case I face ever -- I've seen methods using blocks in
upstream code before but they were no-op anyway as there was no
GNUstep implementation.  On the contrary, there are tons of
block-unrelated things which are not implemented, especially in GUI.

The biggest hurdle with porting apps IMVHO is missing functionality
and dependency on Core* stuff and other libraries with no free
implementation.  The switch to Clang is not going to solve these
problems.  The only thing it solves is making the life of developers
of properiatary software easy.  That is not my goal.

> But I'd say that Debian's packaging of GNUstep is very important and
> even if the core doesn't start depending on these features, they
> should be made available.

I don't know why Debian is important, but they cannot be made
available as an option.  It would mean duplicate packages with
different names -- the release team will not allow it and the
ftpmasters will not allow it.

You probably weren't around when we (GNUstep people in Debian) had to
scrap and fight to prevent it from being removed.  GNUstep in Debian
back then was undermaintained and violated the FHS, it was also full
of bugs (that is, obvious bugs such as frequent failures to build from
source) and blatant bugs solely due to packaging.  Hubert wrote a tool
to FHS-ify most of the packages, we fixed most bugs and we had a
helping hand from the Debian GCC maintainers who said it would be very
worthwile to keep GNUstep in Debian, at least as a testing ground for
GCC.

And that's what it's been, more or less; GNUstep had a rapid decline
in the user base some years ago and it appears it is not going to
recover.  All the Clangs in the world are not going to help you with
that.  But in your quest for popularity you may lose some of the solid
foundations that are still keeping this project afloat.

> What's lost is builds on some architectures. Can't those architectures
> keep using GCC-targeting libraries or be actively disabled?

No.  Packages which no longer build for a particular architecture must
be removed manually by the ftpmasters, after a request i

Re: Which ObjC2.0 features are missing in the latest GCC?

[Yavor Doganov]

[ Posting this via NNTP, hope it works. ]

Ivan Vučica wrote:
> Distro packagers should also voice their opinion on whether they can
> switch to Clang (and, hopefully, libobjc2), which I'd invite them to
> do no matter what the decision is on presence of Clang-dependent
> code in GNUstep core libs.

I guess distro packagers who prefer Clang (or have no reasonable
choice as that is the default and perhaps the only compiler on their
distro) have made their choice already.

Regarding Debian, I would like to point out that I cannot speak for
them.  I am neither a Debian Developer nor a Debian Maintainer.  I
also cannot speak for the Debian GNUstep team as I don't hold any
special position there.

But I'll have to repeat what I've said several times to fellow team
members and other people asking me the question "Why Debian's GNUstep
doesn't switch to Clang?".  The answer is simple: because there's a
lot to lose and nothing to gain.

Re: Savannah bug tracker disabled?

[Yavor Doganov]

Gregory Casamento wrote:
> Someone refusing to submit bugs due to the fact that they might need
> a github account isn't going to change that.

It was not my intention to change that and I never said that I would
stop submitting bugs.  I am not a significant contributor to this
project so I don't have a say how you organize your workflow.  It's
entirely up to you and the other members.  I'm not even a programmer.

But I will not violate my principles and start using GitHub just
because you decided so.  These may be "petty political arguments" for
you but they are very important for me.

> I shut down the savannah bug tracker for a very simple reason.  WE
> AREN'T HOSTING SOURCE ON SAVANNAH ANYMORE.

FWIW, tracking bugs and hosting code are two different things that
don't necessarily overlap.

Re: Savannah bug tracker disabled?

[Yavor Doganov]

Gregory Casamento wrote:
> Yes, it is disabled to avoid confusion.

An announcement would have been nice.

> Existing bugs can be updated and closed, but no new ones can be
> added.

I cannot update existing bugs, perhaps only project members can.
That's OK.

> Track bugs on github where the main development is now happening.

As I don't have a GitHub account and don't plan to make one, I guess I
can report bugs to bug-gnustep@.

Savannah bug tracker disabled?

[Yavor Doganov]

I noticed that I cannot comment on bugs that I filed; there's a
message on top saying:

| You are not allowed to post comments on this tracker with your
| current authentication level.

It is not possible to submit a new bug either so the only reasonable
explanation is that the tracker was disabled by one of the project
admins.  If true, is that on purpose?  If so, what is the replacement?

Re: Gorm don't work

[Yavor Doganov]

В Fri, 25 Jan 2019 13:23:17 +0100, Fred Kiefer написа:

> It is a lot easier than that. You just made a small mistake and used an
> NSString here instead of a C String. Of course this cannot work, with
> neither of the compilers. Which just shows that nobody did recompile and
> use Gorm after your change.

FWIW, I reviewed David's change shortly after he pushed it, recompiled 
Gorm and noticed the warning but thought it was an obvious thinko that 
would be discovered and fixed fairly quickly.  I haven't run it though so 
I could not associate Germán's report with this innocent mistake.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: ANN: GNUstep GUI 0.27.0

[Yavor Doganov]

В Tue, 08 Jan 2019 10:37:12 +, David Chisnall написа:
> On 08/01/2019 06:57, Josh Freeman wrote:
>> On Jan 7, 2019, at 4:20 PM, Ivan Vucica wrote:
>>> This is version 0.27.0 of the GNUstep GUI library ('gnustep-gui').
>> 
>> Thank you, GNUstep maintainers & contributors, and congratulations
>> on the new releases!
> 
> And especially thanks to Ivan for pushing the releases out

I concur -- many thanks to all GNUstep developers and especially Ivan
for doing the releases in time for the Debian transition freeze.

TBH (I always strive to be), I didn't believe that this was
achievable.  For the first time in my life the stars align right; it
took an incredible sequence of events to make it happen.

My sponsor was quick enough to upload the packages to Debian
experimental within 24 hrs (I used the pretests that Ivan published to
prepare the packaging changes), then Gürkan pestered the Debian
ftpmasters on IRC and the new packages were accepted within a few
hours by the Debian Project Leader himself (who whappens to be
ftpmaster as well).  Finally, I managed to build-test all reverse
dependencies in time (using two machines) and apply for a full GNUstep
transition two days before the deadline, which was approved and
conducted successfully (albeit with a few problems, mostly because of
our experiment early in the development cycle to try co-installation
of different library versions).

> probably the least fun part of open source development.

I beg to differ here.  The process of releasing, although often
stressful due to the additional administrativia stuff and sometimes
done under pressure (as it certainly was the case this time), is when
you make your work available to the general public -- and this should
be a moment of joy.  You share your changes, putting a stamp on them,
and it makes you feel like you did something good, at least to some
part of humanity.

This is how I always felt as a free software (occasional/minor)
contributor; perhaps for an open source developer the feeling is
slightly different.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: TextEdit : critical error prevents loading

[Yavor Doganov]

On Sat, 04 Aug 2018 18:16:01 +0300,
Patrick CARDONA wrote:
> And so, from this fresh install, I set up my Epson printer with cups
> and I could not reproduce the bug because the cups client got
> obviously a good .PPD file. So I am sorry again not to be able to
> approve the patch.

No problem, Fred committed a fix for it along with fixes for the other
printing problems you reported.  I'll update the Debian package at
some point, including this and some other important ABI-compatible
changes.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Crash on app start due to icon

[Yavor Doganov]

On Wed, 08 Aug 2018 01:34:25 +0300,
Josh Freeman wrote:
>It seems to be a gcc/gobjc compiler/runtime bug: Sending a nil
> message using a method signature that returns a structure
> (ex. -[NSView bounds] -> NSRect) results in:
> 1. Garbage values in the returned structure's members (affects:
> 32-bit/64-bit, debug/non-debug)
> 2. A corrupted stack (affects: 32-bit w/non-debug)

Many thanks for finding this out.  It explains many hours spent in
fruitless debugging sessions and some truly obscure bugs I've seen in
Adun, Cenon, Lynkeos and other apps...  Unfortunately this bug has
nasty consequences as quite a lot of GUI methods return structs and
most users (and distros) usually build with -O2.

The good news is that I managed to find out the revisions which fixed
the bug and reintroduced it again, reworked your test program to pure
Objective-C and reported it:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86913


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Migrating GNUstep home folder to another computer

[Yavor Doganov]

В Tue, 24 Jul 2018 20:49:43 +0200, Patrick CARDONA написа:

> Maybe I do not the things the right way within GWorkspace.

Or there could be a bug that may be fixed in 0.9.4.  Has this worked 
properly on Ubuntu?

> Is GWorkspace using DBUS messaging between apps and udisks2 ?

No but this is a neat idea.

> I dropped the Ubuntu one, so my question was about migrating from Debian
> to Debian (maybe stable to testing)

There should be no problems here.

> So what happens when a user want to upgrade : are some sub-directories
> to conserve, like $HOME/GNUstep/Library and $HOME/GNUstep/Applications
> and others to be dropped ?

You shouldn't worry about it.  Each application should handle its own 
defaults and data, if some kind of migration is necessary.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Migrating GNUstep home folder to another computer

[Yavor Doganov]

В Tue, 24 Jul 2018 18:43:24 +0200, Patrick CARDONA написа:

> I started from a clean GNUstep folder, and things went better, as
> expected :
> - Alt/Meta Keys work again.

So it was due to some default that you have set in your Ubuntu
environment.

> As You told me about I could meet some downgrade behaviour due to older
> versions, do You think I should add Backports repositories in my
> /etc/apt/sources.list ?

No; there are no backports of GNUstep packages.  We never had requests
from users for backports and they wouldn't be possible in many cases
due to new versions of the libraries that are not available in stable.
That's certainly true for GNUMail's newest release which requires
Pantomime 1.3.0 and that's not available even in unstable (it's been
in the NEW queue[0] for a month, waiting for ftpmasters' approval).

[0] https://ftp-master.debian.org/new.html

> Do You thing also Testing is stable enought with GNUstep software ?

Well, it depends on your usage pattern and priorities.  Using testing
is perfectly fine in many scenarios.  Should you decide to switch to
testing, please note that upgrading is not guaranteed to work, it's
safer to use the weekly images [1].

[1] https://cdimage.debian.org/cdimage/weekly-builds/amd64/

> I thought - and obviously I was wrong - that Debian was more up to
> date than Ubuntu.

Debian is more up to date than Ubuntu, that's right (with some
exceptions when Ubuntu do some library transitions in advance).  But
you switched from Ubuntu's last stable release to Debian's last stable
release and they are never in sync.  Stretch was released more than a
year ago so it's natural that the software is older.

> Also, I would like to deal with a lighter install process : no Gnome
> desktop (no Desktop tasksel), just the basic X server, wmaker and
> GNUstep apps with a few other (firefox, and so on...) which I did
> wrappers.

This should be easily doable if you select Expert mode in the Debian
Installer.

> Maybe I should not backup the GNUstep directory ? Maybe, if I install on
> Debian again, it is not a matter...

If you install Debian testing, there shouldn't be discrepancies
because the package versions are (almost) the same in Bionic.  So it's
likely to work.

> But I need first to understand how the things could work this way. For
> example, when I use the dockapp wmudmount to mount my USB external
> drive, the disk icon do not show up on the desktop.

There is no such package, perhaps it was a typo?

> I need to refresh ("Tools/Hide desktop" then "Tools/Show desktop")
> to see this icon on the desktop of the workspace.

This is probably a GWorkspace bug, could be fixed.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Migrating GNUstep home folder to another computer

[Yavor Doganov]

В Mon, 23 Jul 2018 19:34:28 +, Yavor Doganov написа:
> В Mon, 23 Jul 2018 20:53:16 +0200, Patrick CARDONA написа:
>> - In GWorkspace, #-key (Meta or Alt) commands do not work : #-d will
>> not put the file in the Recycler Trash directory.
> 
> I'm afraid I can't reproduce this.  What window manager do you use?

Sorry, that was a stupid question; I should have taken a look at the 
screenshot.  It looks like Window Maker with Gworkspace providing the 
Dock, right?  I still can't reproduce, though.

Some window managers intercept (steal) key modifiers so that's why I 
thought it might be related.

As a general note when downgrading -- it is not guaranteed to work.  Some 
defaults may have no effect (e.g., they were only applicable for the 
higher version of the app you used); others may be of different type than 
the app expects which usually would lead to raising an exception or at 
least some unexpected behavior.  OTOH, some apps may store data in a 
format that is not backwards-compatible with the format that the old 
version of the app understands/implements.  This is not limited to 
GNUstep, most software is not downward-compatible and that is 
understandable.

I suggest that you try to reproduce your bugs without your old ~/GNUstep 
directory from the Ubuntu machine/installation.  Then, if the bugs are 
not there, you can gradually move your old ~/GNUstep contents (defaults 
and data separately) so that you can narrow down the problem.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Migrating GNUstep home folder to another computer

[Yavor Doganov]

В Mon, 23 Jul 2018 20:53:16 +0200, Patrick CARDONA написа:

> I tried to migrate from Ubuntu to a fresh Debian Stretch Install, which
> seems to be more reactive on the same computer (old macmini).

This is a "downgrade" in terms of package versions.

> But I encounter some curious behaviours:
> - In GNUMail, the Inbox window is blank : the list of messages is not
> displayed (see screeshot).

GNUMail in Debian stretch has some subtle bugs, the version in unstable 
is buggy too.  You can try removing the cache (should be in ~/GNUstep/
Library/GNUMail) and see if the problem persists.  Please also run the 
app from a terminal; some messages may provide a clue.

> - In GWorkspace, #-key (Meta or Alt) commands do not work : #-d will not
> put the file in the Recycler Trash directory.

I'm afraid I can't reproduce this.  What window manager do you use?


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: TextEdit : critical error prevents loading

[Yavor Doganov]

On Tue, 10 Jul 2018 15:45:25 +0300,
Yavor Doganov wrote:
> Patrick CARDONA wrote:
> > I just notice that the margins in the summery of the Page Layout are
> > very odd (attached screenshot) and when I print an example, the text
> > is not placed where it should be.
> 
> This is a separate issue; I think there's a bug in the way the margins
> are computed as they are also wrong for me.

Well, this turned out to be more complicated than I thought, so I
filed a bug:

https://savannah.gnu.org/bugs/index.php?54307

Some of these problems are well known and have been discussed before.
Fred, I would appreciate if you can take a look when you have the
time.

TextEdit has hardcoded margins (72 pts) that are not exposed in the UI
and cannot be changed.  It still needs the attached minimalistic patch
to do the right thing (along with the GUI patch from the bug above).
--- textedit.app-5.0.orig/Document.m
+++ textedit.app-5.0/Document.m
@@ -697,7 +697,6 @@ NSString *OpenDocumentTextType = @"org.o
 NSPrintInfo *printInfo = [super printInfo];
 if (!setUpPrintInfoDefaults) {
setUpPrintInfoDefaults = YES;
-   [printInfo setHorizontalPagination:NSFitPagination];
[printInfo setHorizontallyCentered:NO];
[printInfo setVerticallyCentered:NO];
[printInfo setLeftMargin:72.0];
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: SimpleAgenda 0.44 - No way to add new task or new appointment

[Yavor Doganov]

В Fri, 13 Jul 2018 15:56:43 +0200, Patrick CARDONA написа:

> I hope you will forgive my poor knowledge about testing the patch.

No problem at all.  Not all users have these skills, and that's perfectly 
fine.

> So I did not found any way to add dev repository matching Agenda.app dev
> archive : when I add dev sources within Ubuntu repositories, none
> leading to gnustep.

Most probably you have to duplicate your "deb" entries with "deb-src", 
IOW if you have in /etc/apt/sources.list:

deb http://archive.ubuntu.com/ubuntu bionic universe multiverse

Add another line:

deb-src http://archive.ubuntu.com/ubuntu bionic universe multiverse

Then run "apt update" and you can "apt-get source" any package that is in 
the official Bionic archive.  (All of this is untested as I don't have 
access to an Ubuntu system and have never used it myself.)

> https://help.ubuntu.com/community/CompilingEasyHowTo

This is about compiling random software the usual way.  That is in some 
cases more difficult.  I thought rebuilding the *debian* package would be 
easier.  Anyway.

> and got the tarball
> here : https://packages.ubuntu.com/source/bionic/agenda.app

Using that link, grab the source package with this command (you must have 
devscripts installed):

dget -u http://archive.ubuntu.com/ubuntu/pool/universe/a/agenda.app/
agenda.app_0.44-1build1.dsc

Then the instructions are the same as for textedit.app.
 
> But now, since I am inside the directory, I do not find where to apply
> the patch.
> In the previous example, you gave me a debian path and here there is not
> such a path.

Right, there is no debian directory if you unpacked only the upstream 
tarball.  In this case, apply the patch like this:

$ patch -p1 https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: SimpleAgenda on FreeBSD

[Yavor Doganov]

В Thu, 12 Jul 2018 22:58:59 +0200, Riccardo Mottola написа:
> On 2018-07-12 10:09:04 + Ivan Vučica  wrote:
> 
>> If not, a hacky thing I would do is, I would try:
>>   CFLAGS="-isystem /usr/local/include" ./configure
>> instead.

Or better:

  ./configure CPPFLAGS=-I/usr/local/include

> I just tried myself building SimpleAgenda on FreeBSD.
> 
> it states:
>   --with-ical-include=DIR include path for ical headers
>   --with-ical-library=DIR library path for ical libraries
> 
> but they do not work,

Most probably it doesn't work because of this:

> -AC_ARG_WITH(ical-include, [  --with-ical-include=DIR  include path for
> ical headers], additional_include_dir+=-I"$withval", )
   ^^
That's a so called "bashism" and I suspect the default shell on FreeBSD 
is not GNU Bash.

What troubles me most is that /usr/local/include is standard and is in 
the search path of both GCC and Clang, at least on GNU/Linux.  You 
shouldn't have to do anything special if libical is installed in /usr/
local.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: SimpleAgenda 0.44 - No way to add new task or new appointment

[Yavor Doganov]

Package: agenda.app
Version: 0.44-1
Severity: important
Tags: patch

Patrick CARDONA wrote:
> When I try to add a new task (#t)  - or a new appointment - within
> SimpleAgenda.app, the OK button is disabled in the "Edit task" panel
> and the Store list is empty. So I cannot save anything.

Thanks for reporting this bug, it is easily reproducible on a fresh
installation (simulated by deleting the app defaults and
~/GNUstep/Library/Simplegenda).

In LocalStore -initWithName:, [[self config] objectForKey: ST_FILE]
returns nil so _globalFile ends up the same as _globalPath.  It then
attempts to save the file which is identical to the newly created
directory and that fails, naturally.  Which in turn sets the store as
non-writable in the -write method so you get the OK button disabled.

Riccardo's workaround actually works because adding a local calendar
file explicitly from the Preferences invokes +registerWithName: which
sets the object for that key.

The attached patch works for me.
--- agenda.app-0.44.orig/LocalStore.m
+++ agenda.app-0.44/LocalStore.m
@@ -27,9 +27,11 @@
 {
   self = [super initWithName:name];
   if (self) {
+ConfigManager *gc = [ConfigManager globalConfig];
+
 _globalPath = [[[NSSearchPathForDirectoriesInDomains(NSLibraryDirectory, 
NSUserDomainMask, YES) lastObject] 
 stringByAppendingPathComponent:@"SimpleAgenda"] retain];
-_globalFile = [[_globalPath stringByAppendingPathComponent:[[self config] 
objectForKey:ST_FILE]] retain];
+_globalFile = [[_globalPath stringByAppendingPathComponent:[[gc 
objectForKey:name] objectForKey:ST_FILE]] retain];
 _globalTaskFile = [[NSString stringWithFormat:@"%@.tasks", _globalFile] 
retain];
 [self read];
   }
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: TextEdit : critical error prevents loading

[Yavor Doganov]

Patrick CARDONA wrote:
> I am very confused, beacause I tried an update of the Epson printer
> driver in the meanwhile, just from Epson support site; and now, I am
> not able to reproduce the bug : TextEdit is running and I can show up
> printer panel and Page Layout.

This means that the updated .ppd file doesn't have the same issue like
the old one, so it is parsed and loaded successfully.

> I just notice that the margins in the summery of the Page Layout are
> very odd (attached screenshot) and when I print an example, the text
> is not placed where it should be.

This is a separate issue; I think there's a bug in the way the margins
are computed as they are also wrong for me.

> To answer your question, yes, I would appreciate to know how to apply
> the patch and will try to reproduce the bug back again to verify the
> patch.

You will need the appropriate deb-src entries in your
/etc/apt/sources.list.  Then do:

$ apt-get source gnustep-gui
$ cd gnustep-gui-*
$ cp /path/to/test.patch debian/patches
$ echo test.patch >> debian/patches/series
$ sudo apt install build-essential devscripts
$ sudo apt-get build-dep gnustep-gui
$ DEB_BUILD_OPTIONS=nocheck debuild -b -us -uc
$ sudo dpkg -i ../libgnustep-gui0.26_*.deb

Make sure you close all GNUstep applications before testing; otherwise
the library that is already loaded will be used.  Also, it goes without
saying that you should downgrade your epson driver package to the old
version containing the problematic .ppd.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: TextEdit : critical error prevents loading

[Yavor Doganov]

Patrick CARDONA wrote:
> Sorry, I can't get now the answer : I may do something wrong...

Yes, you do:

> > (gdb) break -[NSException raise]
> > Function "-[NSException raise]" not defined.
> > Make breakpoint pending on future shared library load? (y or [n]) y
> > Breakpoint 1 (-[NSException raise]) pending.

Here, type "r" and when it stops, instead of typing "bt" as I asked
initially, continue with these commands:

> > (gdb) fr 7
> > (gdb) po ppdPath

But nevermind, I was able to reproduce with the .ppd file you sent.
It is valid according to cupstestppd so I believe the problem is in
the parser, namely -addPPDKeyword:withScanner:withPPDPath:.  It
assumes the value is either quoted or unquoted string, which is not
always the case.  I'm not sure the attached patch is correct but I
would appreciate if you test it.

Do you need instructions how to apply the patch and rebuild the
gnustep-gui package?
--- gnustep-gui-0.26.2.orig/Source/NSPrinter.m
+++ gnustep-gui-0.26.2/Source/NSPrinter.m
@@ -1159,6 +1159,8 @@
   // Otherwise, scan up to the end of line or '/'
   [ppdData scanUpToCharactersFromSet: valueEndSet 
   intoString: ];
+  if (!value)
+value = @"";
 }
   // If there is a value translation, scan it
   if ([ppdData scanString: @"/" 
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: TextEdit : critical error prevents loading

[Yavor Doganov]

В Mon, 09 Jul 2018 22:14:15 +0200, Patrick CARDONA написа:

> As I can understand, it seems You were right about the printer
> hypothesis.

Yes, thank you very much.  There's a problem with parsing the PPD file. 
It could be a corrupted file or a bug.  I tried one .ppd file for your 
printer (Epson-XP-510_Series-epson-escpr-en.ppd) and could not 
reproduce.  Probably it is not the same file you are using, so it would 
be best if you just send it (in case it is not available in some official 
Ubuntu package).

You can find out which file it is with gdb.  When you reach the 
breakpoint, type "fr 7", then type "po ppdPath".


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: TextEdit : critical error prevents loading

[Yavor Doganov]

В Mon, 09 Jul 2018 21:18:12 +0200, Patrick CARDONA написа:
> On 2018-07-09 16:04:08 +0200 Yavor Doganov  wrote:
> 
> Ok : dpkg -l  returns :
>> ii  textedit.app   5.0-2i386 Text editor for GNUstep

OK, thanks.

>> No, that is the wrong file to move.  I asked for
>> /home/patrick/GNUstep/Defaults/TextEdit.plist.
>> 
> Sorry. The file "/home/patrick/GNUstep/Defaults/TextEdit.plist" does not
> exist, maybe because the app never started up to save preferences there.

OK, so the problem lies elsewhere.

>> patrick@patrick-Macmini1:~$ gdb TextEdit (...)
>> Reading symbols from TextEdit...Reading symbols from
>> /usr/lib/debug/.build-id/d3/
d7000fb36cd0134659949fd83b715a6bda667d.debug...done.
>> done.
>> (gdb) break -[NSException raise]
>> Function "-[NSException raise]" not defined.
>> Make breakpoint pending on future shared library load? (y or [n])

That's all expected and indicates you have at least textedit.app-dbgsym 
installed -- the file at /usr/lib/debug contains the detached debugging 
symbols.  Please answer "y" to the question "Make breakpoint pending on 
future shared library load?", then type "r" and when you get SIGABRT, type 
"bt" at the gdb prompt and send the output.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: TextEdit : critical error prevents loading

[Yavor Doganov]

В Mon, 09 Jul 2018 15:47:48 +0200, Patrick CARDONA написа:
> On 2018-07-08 23:14:13 +0200 Yavor Doganov  wrote:

>> ApplicationRelease = 5; (it is not exactly 5.0-2)

"dpkg -l textedit.app" should give the answer which package version you 
have installed.

>> Does it happen if you move ~/GNUstep/Defaults/TextEdit.plist away?
> When I rename "Info-gnustep.plist" to "Info-gnustep.plist.back", I get
> these messages :

No, that is the wrong file to move.  I asked for
/home/patrick/GNUstep/Defaults/TextEdit.plist.

> I have already gdb installed, but I could not install the *.dbg neither
> *.dbgsym because there seem not available within Ubuntu :

Well, you'll probably have to enable additional repositories for them; 
please check your usual Ubuntu documentation / support channels.  I found 
this wiki page for Ubuntu but I don't know if it's accurate:

https://wiki.ubuntu.com/Debug%20Symbol%20Packages


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Printing with CUPS seems to be broken within the GNUstep apps

[Yavor Doganov]

В Sun, 08 Jul 2018 19:26:02 +0200, Patrick CARDONA написа:

>> Ink[9530:9530] Loaded printing bundle at
>> /usr/lib/GNUstep/Bundles/GSPrinting/GSCUPS.bundle 2018-07-08
>> 18:55:03.940 Ink[9530:9530] The default printer name is
>> EPSON-XP-510-Series

> But the Print panel still don't show up...

Very odd... it seems like some method does not return or it gets stuck 
somewhere.  Could you please run it again like this:

$ Ink --GNU-Debug=NSPrinting

(No need to prepend "openapp" since the executable, or at least a symlink 
pointing to it, is in your PATH.)


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: TextEdit : critical error prevents loading

[Yavor Doganov]

В Sun, 08 Jul 2018 18:08:09 +0200, Patrick CARDONA написа:

> When I try to start TextEdit, a critical error message is shown :
> 
> "NSInvalidArgumentException: Tried to add nil to array"

You didn't specify the version of TextEdit, I assume it is 5.0-2?
Does it happen if you move ~/GNUstep/Defaults/TextEdit.plist away?  If it 
doesn't, it is a bug that I attempted to fix (migrating some defaults to 
the new types) but apparently the fix is not complete.

If you still get the exception, this could be related to your printing 
problem since TextEdit does setup printing on startup (unlike Ink). Could 
you please install gdb, libgnustep-base1.25-dbgsym, libgnustep-gui0.26-
dbgsym, textedit.app-dbgsym, libobjc4-dbg and run the app like this (in a 
terminal):

$ gdb TextEdit
(gdb) break -[NSException raise]
...Answer "y" to the question...
(gdb) r

When you get back to the gdb prompt, type "bt" and send the output.
Thanks.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Printing with CUPS seems to be broken within the GNUstep apps

[Yavor Doganov]

В Sun, 08 Jul 2018 17:45:45 +0200, Patrick CARDONA написа:

> - My context :
> OS : GNU/Linux Ubuntu 18.04 (LTS)
> WM : WindowMaker GNUstep - All packages from the official deb packages
> of that distro :
> Base : 1.25.1 Gui & Back : 0.26.2-3 Make : 2.7.0-3

Strange; I cannot reproduce on Debian unstable with approximately the 
same versions (only -back is 0.26.2-4 but it has unrelated changes).

> Any Idea ?

Try running Ink with --GNU-Debug=GSPrinting or perhaps additionally with 
--GNU-Debug=GSCUPS and see what it prints.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: signal SIGSEGV, Segmentation fault

[Yavor Doganov]

В Tue, 22 May 2018 13:54:08 +0200, Andreas Höschler написа:

> - (id)initWithFrame:(NSRect)frameRect {
>NSLog(@"initWithFrame ...");
>self = [super initWithFrame: frameRect];
 ^^^
>[self retain];
>...
> }

Good practice is to check the result of that assignment.  If it fails for 
some reason, it would explain (to an extent) why your program crashes 
when you attempt to assign a value to the ivar at line 168.  Also, if 
self is nil, -retain will do nothing.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: SMDoubleSlider usability on GNUstep

[Yavor Doganov]

В Wed, 07 Mar 2018 23:35:53 +0100, Fred Kiefer написа:

> To me it now looks like NSSliderCell just overrides all the value
> methods of its super calls and implements them by setting a numerical
> value directly.

It appears so.

> For NSCell and specific sub classes things are different, but only
> if these get initialised as text cells. Doing this on an
> NSSliderCell would not set the max value, which prevents that cell
> from working.

This explains why Lynkeos code like

NSSliderCell *slider = [[[NSSliderCell alloc] initTextCell:@""] 
autorelease];

doesn't work.  I had to change this to plain -init (which calls
-initImageCell: with a nil argument in the GNUstep implementation).

> I plan to do a full rewrite of NSSliderCell, without touching NSCell
> at all.

I may be wrong but I think that David's suggestion to modify
NSCell -*Value methods is correct nevertheless (this has nothing to do
with your analysis of course).

Many thanks in advance for working on this.  I'd wish I had the
appropriate knowledge and skills to help.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: SMDoubleSlider usability on GNUstep

[Yavor Doganov]

В Tue, 20 Feb 2018 23:13:21 +0200, Yavor Doganov написа:

> I turned NSCell's -setObjectValue: to a private method and changed all
> -set*Value: methods to use it.  My test program doesn't crash now and I
> can see the two knobs.  Movement is awkward (no sliding effect) and if I
> click on the first knob the second one disappears.

I reverted this change as it is causing the awkwardness, among other
problems.  Instead, I disabled SMDoubleSliderCell's -setObjectValue:
so that NSCell's method is always used.  It seems to be working
properly except:

1. When the high knob is not set to a particular value with
-set*HiValue: it is not displayed initially.  However, if I click on
the right side of the bar both knobs become visible.

2. Possibly related with the above issue, if I click on the low knob,
the high knob disappears.  It is visible where it should be during
NSCell -trackMouse:inRect:ofView:untilMouseUp: but as soon as the
mouse is up it disappears again.  When tracking the high knob both
knobs are visible as expected.

I believe these are GNUstep bugs or at least there is a difference in
the behavior compared to Cocoa (assuming the code works as expected on
Cocoa).

> Is it a problem that SMDoubleSliderCell overrides both -drawKnob: and
> -drawKnob?

I tried merging them into -drawKnob: only, no difference in the
behavior except that the high knob is not visible when the low knob is
being moved with the mouse.

3. When the low knob is moved at the beginning of the bar, it becomes
locked and can no longer be moved with the mouse.  This seems to be
caused by this code in SMDoubleSliderCell's -startTrackingAt:inView:

if ( [ self trackingLoKnob ] && NSEqualRects( loKnobRect,
[ self knobRectFlipped:[ controlView isFlipped ] ] ) )
[ self setTrackingLoKnob:( _sm_loValue > [ self minValue ] ) ];

When _sm_loValue is 0 or lower than minValue (in cases when minValue
is set explicitly to a positive value), the boolean expression is
false and only the high knob can be tracked; the low knob remains
blocked indefinitely.  I replaced > with >= and it solves the problem,
although it has the same effect as disabling this check entirely.  It
seems bogus to me, the two knobs cannot overlap.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: SMDoubleSlider usability on GNUstep

[Yavor Doganov]

David Chisnall wrote:
> Here’s a little test program that finds out:

Thanks, that was really helpful.  And it's not surprising that on
GNUstep your test program causes infinite recursion here:

> 2018-02-20 14:46:39.917 a.out[85231:11731363] -floatValue called

> The correct fix is probably:
[...]
> And apply similar fixes to the other *Value methods in NSCell.

I followed this advice and now another infinite recursion occurs:

Program received signal SIGSEGV, Segmentation fault.
0x76096e79 in _int_malloc (av=av@entry=0x763c7c20 , 
bytes=bytes@entry=32) at malloc.c:3575
3575malloc.c: Няма такъв файл или директория.
(gdb) bt
#0  0x76096e79 in _int_malloc (av=av@entry=0x763c7c20 , 
bytes=bytes@entry=32) at malloc.c:3575
#1  0x76098dc3 in __GI___libc_malloc (bytes=32) at malloc.c:3051
#2  0x770bbd4c in default_malloc (zone=, size=) at NSZone.m:122
#3  0x770107d8 in NSAllocateObject (aClass=0x774e0a60 
<_OBJC_Class_NSDoubleNumber>, extraBytes=extraBytes@entry=0, zone=
0x77545460 , zone@entry=0x0) at NSObject.m:782
#4  0x770074d0 in +[NSNumber numberWithDouble:] (self=, 
_cmd=, aValue=) at NSNumber.m:948
#5  0x777d4d0f in -[NSCell setDoubleValue:] (self=0x562f15b0, 
_cmd=, aDouble=0) at NSCell.m:410
#6  0xdc8b in -[SMDoubleSliderCell setDoubleHiValue:] 
(self=0x562f15b0, _cmd=, aDouble=0) at 
SMDoubleSliderCell.m:487
#7  0xdc8b in -[SMDoubleSliderCell setDoubleHiValue:] 
(self=0x562f15b0, _cmd=, aDouble=0) at 
SMDoubleSliderCell.m:487
...

NSSliderCell's -init calls -setDoubleValue: which in turn calls
-setDoubleHiValue: and at the end it calls the superclass'
-setDoubleValue:.  NSCell's -setDoubleValue: calls -setObjectValue:
but it's the SMDoubleSliderCell's method that is used which resorts to
-setDoubleValue: again (calling [super setDoubleValue:]).

I turned NSCell's -setObjectValue: to a private method and changed all
-set*Value: methods to use it.  My test program doesn't crash now and
I can see the two knobs.  Movement is awkward (no sliding effect) and
if I click on the first knob the second one disappears.  But at least
there is some hope.  There's still something fishy going on but
unfortunately I don't understand the code well enough to figure it
out.

Is it a problem that SMDoubleSliderCell overrides both -drawKnob: and
-drawKnob?

___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: SMDoubleSlider usability on GNUstep

[Yavor Doganov]

David Chisnall wrote:
> This then checks whether the object responds to -doubleValue, and if
> it does calls that:
> 
> https://github.com/gnustep/libs-gui/blob/master/Source/NSCell.m#L265
> 
> Unfortunately, in this case, it appears that the object value is
> self, so you get infinite recursion.

I think this condition is always false.  _cell.has_valid_object_value
is NO and _object_value is nil.  So it jumps to NSCell.m:269 and
SMDoubleSliderCell's -stringValue is called which calls -stringHiValue
which in turn calls -doubleHiValue and from there the infinite
recursion is in place.

At least this is what I observe in the debugger.

___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

SMDoubleSlider usability on GNUstep

[Yavor Doganov]

As part of my ongoing effort to port the latest Lynkeos release to
GNUstep, I have encountered an issue with a custom class which is a
subclass of NSSlider/NSSliderCell.  The original code is available
here [1] as .dmg only, I used 7z to unpack it.

[1] http://developer.snowmintcs.com/controls/smdoubleslider/

The Lynkeos bundled version can be obtained with Subversion [2] and is
also browseable here [3].

[2] svn co 
svn://svn.code.sf.net/p/lynkeos/code/trunk/application/ThirdPartySources/SMDoubleSlider
 SMDoubleSlider
[3] 
https://sourceforge.net/p/lynkeos/code/HEAD/tree/trunk/application/ThirdPartySources/SMDoubleSlider/

It seems that the original code accesses NSSliderCell private ivars
directly (_value and some struct members); they have no GNUstep
equivalent.  In 2009, the Lynkeos developer made some changes to fix
compilation on GNUstep:

https://sourceforge.net/p/lynkeos/code/490/tree//trunk/application/ThirdPartySources/SMDoubleSlider/SMDoubleSliderCell.m?diff=517068cee88f3d0a275a1c9e:489

I assume that this works on Cocoa as there were several Lynkeos
releases since then.  It builds on GNUstep but crashes:

Program received signal SIGSEGV, Segmentation fault.
0x76b61216 in objc_msg_lookup (receiver=receiver@entry=0x562ef7f0, 
op=op@entry=0x77c6f130 <_OBJC_SELECTOR_TABLE+400>)
at /build/gcc-8-0DvHrl/gcc-8-8-20180218/src/libobjc/sendmsg.c:439
439 /build/gcc-8-0DvHrl/gcc-8-8-20180218/src/libobjc/sendmsg.c: Няма такъв 
файл или директория.
(gdb) bt
#0  0x76b61216 in objc_msg_lookup 
(receiver=receiver@entry=0x562ef7f0, op=op@entry=0x77c6f130 
<_OBJC_SELECTOR_TABLE+400>)
at /build/gcc-8-0DvHrl/gcc-8-8-20180218/src/libobjc/sendmsg.c:439
#1  0x777d2015 in -[NSCell doubleValue] (self=0x562ef7f0, 
_cmd=) at NSCell.m:269
#2  0x7778362a in -[NSActionCell doubleValue] (self=0x562ef7f0, 
_cmd=) at NSActionCell.m:187
#3  0xbfdb in -[SMDoubleSliderCell doubleHiValue] 
(self=0x562ef7f0, _cmd=) at SMDoubleSliderCell.m:448
#4  0xde93 in -[SMDoubleSliderCell stringHiValue] 
(self=0x562ef7f0, _cmd=) at SMDoubleSliderCell.m:494
#5  0x777d2021 in -[NSCell doubleValue] (self=0x562ef7f0, 
_cmd=) at NSCell.m:269
#6  0x7778362a in -[NSActionCell doubleValue] (self=0x562ef7f0, 
_cmd=) at NSActionCell.m:187
#7  0xbfdb in -[SMDoubleSliderCell doubleHiValue] 
(self=0x562ef7f0, _cmd=) at SMDoubleSliderCell.m:448
#8  0xde93 in -[SMDoubleSliderCell stringHiValue] 
(self=0x562ef7f0, _cmd=) at SMDoubleSliderCell.m:494
#9  0x777d2021 in -[NSCell doubleValue] (self=0x562ef7f0, 
_cmd=) at NSCell.m:269
#10 0x7778362a in -[NSActionCell doubleValue] (self=0x562ef7f0, 
_cmd=) at NSActionCell.m:187
...

The devil's circle goes on and on.  Am I right to conclude that
SMDoubleSlider is tightly tied to Apple's implementation and cannot
possibly work on GNUstep?  Is there anything I can do except to
disable this functionality?


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Compiling gnustep-make

[Yavor Doganov]

В Mon, 05 Feb 2018 06:47:55 +1100, Svetlana Tkachenko написа:
 
> Turns out installing gobjc-7 fixes the error message provided by GNUstep
> Make.

Sorry, there was some race condition: I read your message only after 
sending my last message.

The gnustep-make configure script should fail if it cannot find an 
Objective-C compiler so there's something really fishy here.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Compiling gnustep-make

[Yavor Doganov]

В Mon, 05 Feb 2018 06:24:14 +1100, Svetlana Tkachenko написа:

> I compiled GNUstep Make.
> Then I tried to compile GNUstep Base.
> It says this: http://dpaste.com/0AEA0ZE.txt

Inspect config.log and post the part relevant to this failure?
Have you stripped the output of `dpkg -l'?  I don't see a compiler there,
on my system it returns:

$ dpkg -l *objc* | grep ^i
ii  gobjc   4:7.2.0-1d1  amd64GNU Objective-C compiler
ii  gobjc++ 4:7.2.0-1d1  amd64GNU Objective-C++ 
compiler
ii  gobjc++-7   7.3.0-1  amd64GNU Objective-C++ 
compiler
ii  gobjc-7 7.3.0-1  amd64GNU Objective-C compiler
ii  libobjc-7-dev:amd64 7.3.0-1  amd64Runtime library for GNU 
Objective-C applications (development files)
ii  libobjc4:amd64  7.3.0-1  amd64Runtime library for GNU 
Objective-C applications
ii  libobjc4-dbg:amd64  7.3.0-1  amd64Runtime library for GNU 
Objective-C applications (debug symbols

> svetlana@debians:~$ env|grep GNUSTEP # I do not know what makes this
> GNUSTEP_USER_ROOT=/home/svetlana/GNUstep

This is set from your ~/.profile or ~/.bashrc or from another
GNUstep.sh (from an old installation) that is sourced from there.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Compiling gnustep-make

[Yavor Doganov]

В Thu, 01 Feb 2018 09:39:33 +1100, Svetlana Tkachenko написа:
> Ivan Vučica wrote:
>> Have you uninstalled a previous installation of GS fully?
> 
> I now did 'apt purge *gnustep*' and that showed that some packages
> still needed removal. However I then rebooted and tried to compile
> GNUstep Make again and it produced the same error message.

Then you definitely have some remnants from an old installation.  It
could be from a debian package (purge removes every file *dpkg* knows
about), something in /usr/local or $HOME.

I had to install GNUstep on ~20 machines recently, it worked
flawlessly with 2.7.0.  If you'are trying with the master branch it
shouldn't make any difference; there are a few unrelated commits on
top of 2.7.0.

> Yavor Doganov wrote:
>> Or you can install in the USER domain which always takes
>> precedence.
> 
> How do I install in the USER domain?

make install GNUSTEP_INSTALLATION_DOMAIN=USER

Or, if you don't have root access and/or intend to install in the USER
domain most of the time, you can put in your ~/.profile:

export GNUSTEP_INSTALLATION_DOMAIN=USER

and then use just `make install' which would install in the USER
domain.  You can still explicitly specify `make install
GNUSTEP_INSTALLATION_DOMAIN=LOCAL' in cases when you need to.

>> That's what I'm doing and it works nicely except when testing changes
>> to GNUstep Make.
> 
> Why don't you install GNUstep Make into the USER domain as well?

Well, GNUstep Make introduces the concept of domains, you cannot
install it in the USER or any other domain without extra hoops, it
honours --prefix.

> Now gnustep-base says objc headers are missing, what package is that
> in Debian? I already tried objc*dev but the error remains.

What are you trying to do?  You must have an Objective-C compiler and
runtime before configuring GNUstep Make.  You build the compiler and
the runtime first, then Make, Base, Gui, Back and the rest of the
GNUstep world.  GNUstep Base has a configure check to detect if
there's a mismatch between its own and gnustep-make's configuration.

If you have gobjc/gobjc-7 installed, you already have the GNU
Objective-C runtime headers (libobjc-7-dev).  If you intend to use
Clang and the GNUstep runtime, you have to remove gobjc, install clang
as a debian package (or build it manually if you wish) and
build/install the GNUstep runtime before configuring GNUstep make.

There is no Debian package for the GNUstep runtime (aka libobjc2).


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Compiling gnustep-make

[Yavor Doganov]

В Tue, 30 Jan 2018 06:35:03 +1100, Svetlana Tkachenko написа:
> Then the following error message:
> config-noarch.make:121: *** GNUSTEP_USER_ROOT is obsolete

When is this "then"?  When you run `make' after the successful
configure run of gnustep-make, when you run `make install' for
gnustep-make or when you attempt to build a random GNUstep tool/app
afterwards?

I suspect that you still have gnustep-make/gnustep-common installed as
official Debian packages.  GNUstep Make will not configure properly if
there is a previous installation as it'll attempt to find and use an
existing GNUstep.conf.  Debian's gnustep-make configuration still
caters for old (1.x) makefiles as we have to make sure that nothing
breaks if we remove the compatibility layer (on my TODO, after the
ongoing gnustep-gui transition).

If you intend to use a pristine GNUstep installation on a Debian
system, it's much better to wipe out all GNUstep-related Debian
packages.  Or you can install in the USER domain which always takes
precedence.  That's what I'm doing and it works nicely except when
testing changes to GNUstep Make.

If you have problems with the Debian packages, please report them to
the Debian BTS; thanks in advance.  If my theory above is correct,
this is not a problem in the Debian gnustep-make package.  Rather,
it's a problem in the upstream build system which is assuming things
it shouldn't.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Overlapping characters, unreadable text on Debian sid

[Yavor Doganov]

В Sat, 30 Dec 2017 09:16:40 +, Ivan Vučica написа:
> On Sat 30 Dec 2017 at 09:13 Riccardo Mottola 

> wrote:
>> What versions of gui/back are you using? If you are using Debian's, as
>> usual, bug them for an update.
> 
> I believe they are (correctly) waiting for new -base which is coming
> Real Soon Now™.

That's right.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Window stacking order

[Yavor Doganov]

FWIW, there's an old bug regarding this:

http://savannah.gnu.org/bugs/?13592


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Window stacking order

[Yavor Doganov]

В Tue, 11 Nov 2014 16:20:39 +, Ivan Vučica написа:

 Bug you linked to sounds like it's referencing inability to configure
 settings specifically *per-app*. Johannes's situation refers to GNUstep
 apps going above other X11 apps,

You're right; apparently I haven't read the OP's message carefully.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: base build fails due to non-fragile ABI and clang

[Yavor Doganov]

В Sun, 17 Aug 2014 22:08:53 +0200, Riccardo Mottola написа:

 Suggestions?

Not sure if it really is the problem, but passing --no-create to 
configure usually produces confusing results.  You are running all the 
tests but no output files are being created (or updated in your case).


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Change to NSData breaking on Windows

[Yavor Doganov]

В Fri, 25 Jul 2014 06:56:12 -0400, Gregory Casamento написа:

 While trying to test something on Windows, I ran into this issue:
 
  Compiling file GSFFIInvocation.m ...
  Linking library libgnustep-base ...
 Creating library file: ./obj/libgnustep-base.dll.a
 obj/libgnustep-base.obj/NSData.m.o: In function `readContentsOfFile':
 C:\GNUstep\msys\1.0\home\gregc_000\Development\gnustep\core\base\Source/
NSData.m
 :181: undefined reference to `fseeko'
 C:\GNUstep\msys\1.0\home\gregc_000\Development\gnustep\core\base\Source/
NSData.m
 :193: undefined reference to `ftello'
 C:\GNUstep\msys\1.0\home\gregc_000\Development\gnustep\core\base\Source/
NSData.m
 :204: undefined reference to `fseeko'
 collect2: ld returned 1 exit status

Have you (re)run configure? If fseeko/ftello are not implemented, they 
should be defined to fseek/ftell accordingly.

I have not tested this on Windoze.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Change to NSData breaking on Windows

[Yavor Doganov]

В Fri, 25 Jul 2014 07:15:12 -0400, Gregory Casamento написа:

 I have done a full and clean build to make certain.  They are not
 redefined as such by MinGW.  I went ahead and submitted the change I
 suggested in my email.  Please review it and give feedback if needed.

It seems that Richard has regenerated configure only, so that is why it 
is failing on Windows.  Running autoheader is also necessary for the 
config.h.in template to get updated (autoreconf should do that 
automatically).


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: segfault on solaris10/sparc

[Yavor Doganov]

В Fri, 20 Jun 2014 10:14:18 +0200, Riccardo Mottola написа:

 I wonder if we can foce executing the test without opt. flags  or
 complicate so that it doesn't get optimized..

That's easy, it is already done for other tests.

Before the test:
saved_CFLAGS=$CFLAGS
CFLAGS=

...test...

And then restore them after the test:

CFLAGS=$saved_CFLAGS

 config.align.c: In function 'main':
 config.align.c:13:16: warning: incompatible implicit declaration of
 built-in function 'malloc'
 char  *buf = malloc(30);

Missing #include stdlib.h.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Ubuntu 11.10 packages from svn

[Yavor Doganov]

At Wed, 14 Mar 2012 21:38:52 +0100,
Ivan Vučica wrote:
 Core libraries are the most important for people to be able to start
 developing. Once core libs are set up, apps for GNUstep are
 trivially built.

Not true at all, unfortunately.  For every major GNUstep upgrade, we
(Debian maintainers) are patching nearly half of the apps in the
archive.  Sometimes it's straightforward, sometimes not.  All I can
tell is it takes time and effort, especially in our case where human
resources are scarce.

 But, if gnustep-make gets the ability to produce the debian/ folder
 (and .debs) from GNUmakefiles, like it currently produces .nsi files
 for NSIS, there is no need to add support to individual apps. Unless
 customization is desired.

That would be quite a project.  The standard/recommended practices for
maintaining Debian packages are evolving constantly, sometimes at a
pace which makes it hard for us to keep up.

___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Translation of the Info Panel

[Yavor Doganov]

At Sat, 09 Oct 2010 09:39:39 +0200,
Csanyi Pal wrote:
 can one to translate Info Panel for an application?

Someone may correct me, but no -- TTBOMK this is not possible, at
least not when using the most common technique of providing a .plist
template which is later installed by gnustep-make's rules.

I think you could use this simple trick: move all translatable keys
from the .plist to application code, as standard localized Objective-C
strings.  For example, use your own method in the MainMenu.gsmarkup
file, e.g.

  menuItem title=Info Panel... action=LPTFrontStandardInfoPanel: /

with the following (example) implementation:

- (void) LPTFrontStandardInfoPanel: (id) sender
{
  NSDictionary *dict =
[NSDictionary dictionaryWithObjectsAndKeys:
_(@Write  read the parallel port.),
@ApplicationDescription,
_(@Released under the GNU General Public License 3),
@CopyrightDescription,
_(@...example...),
@SomeOtherLocalizedKey,
  nil];
  
  return [NSApp orderFrontStandardInfoPanelWithOptions: dict];
}

Use make_strings to generate/update Localizable.strings, and don't
forget to add it to the xxx_LOCALIZED_RESOURCE_FILES variable in your
makefile.  All of this is untested, although right now I can't see a
reason why it shouldn't do the job.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Renaissance, Obj-C, Handling the sound attribute of a button

[Yavor Doganov]

В Fri, 24 Sep 2010 09:00:06 +0200, Csanyi Pal написа:
 The GombHangja_Magas.wav soundfile is already there in the app's
 Resources directory.

Perhaps you could try with removing the extension from the sound 
attribute, e.g. button ... sound=GombHangja_Magas ... /?

According to the Renaissance manual, there is no need to specify the file 
extension.  But I really doubt that's the culprit...  If it still fails, 
which I think will happen, it might be a Renaissance bug.  To track it 
down, I'd suggest to put breakpoints and step through to see what 
actually happens.

What happens with a classic simple Hello World program using plain
setSound: methods (i.e. no nibs, no renaissance markup)?


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Hungarian o and u double accute doesn't display correctly

[Yavor Doganov]

Please report issues with the Debian GNUstep packages to the Debian
BTS.  Many bugs are Debian-specific; it is the responsibility of the
Debian maintainers to analyze them, and forward only those that are
real upstream bugs.

В Thu, 09 Sep 2010 20:34:01 +0200, Csanyi Pal написа:
 I was run the comand 'defaults write NSGlobalDomain NSFont DejaVuSans'

, /usr/share/doc/gnustep-back0.18/README.Debian
| NOTE: Font names for the default art backend do not match the cairo
| backend; usually, an extra space is added for cairo, e.g. DejaVu
| Sans vs DejaVuSans.
`

So you should do

   defaults write NSGlobalDomain NSFont 'DejaVu Sans'


Or better yet, just remove this setting -- that way, by default
ttf-dejavu will be used with the cairo backend, and ttf-freefont with
the art backend.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: On Debian Squeeze installed gnustep - The font specified for NSFont, Helvetica, can't be found.

[Yavor Doganov]

At Thu, 19 Aug 2010 21:17:48 +0200,
Csanyi Pal wrote:
 sudo mkdir -p /var/lib/defoma/gnustep-nfont.d/Fonts
 cd /var/lib/defoma/gnustep-nfont.d/Fonts
 sudo mknfonts $(fc-list : file | grep -v '\.gz' | cut -d: -f1)
 for dir in *\ */; do sudo mv $dir `echo $dir | tr -d [:space:]`; done

BTW, you don't have to do this if

 defaults write NSGlobalDomain GSBackend libgnustep-cairo

you use the cairo backend.  Only the art backend needs nfont bundles;
cairo uses fontconfig directly.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: On Debian Squeeze installed gnustep - The font specified for NSFont, Helvetica, can't be found.

[Yavor Doganov]

В Thu, 19 Aug 2010 21:17:48 +0200, Csanyi Pal написа:

 Cynthiune[13011] Problem posting notification: NSException: 0x11dd250
 NAME:NSRangeException REASON:RangeError in method
 -attribute:atIndex:longestEffectiveRange:inRange: in class
 NSAttributedString INFO:(nil)
 
 Segmentation Fault

This is due to the ABI break introduced in 1.19.3 on all 64-bit 
platforms, so all packages are currently broken.  It will be sorted out 
during the ongoing GNUstep transition in Debian, please be patient.

Simply rebuilding them will fix the issue:

apt-get source cynthiune.app  cd cynthiune-*
sudo apt-get build-dep cynthiune.app
dpkg-buildpackage -us -uc
sudo dpkg -i ../*.deb

The warning about the font is harmless, just set NSFont to an available 
font like DejaVu (this is also addressed in the upcoming new gnustep-back 
Debian package).


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Please test new NSLock implementation!

[Yavor Doganov]

[I am sorry I did not pay enough attention to this old thread at that
time.  (See https://savannah.gnu.org/bugs/index.php?30766#comment19
for why this is relevant now.)]

At Sun, 6 Sep 2009 17:56:34 +0100,
Richard Frith-Macdonald wrote:
 1. we don't want to expose internal workings because we don't want  
 developers to start to depend on those internals in such a way that  
 it's hard for us to change things later without breaking existing  
 applications.
 2. we don't want to expose internal workings because changes to them  
 may break API and mean that apps need to be recompiled.
 
 Issue 1 is real, but we can't quantify how important it is as it's a  
 amatter of perceptions rather than a true technical issue.  Luckily  
 it's quite easily largely fixable, simply by removing pthread.h form  
 the header and replacing the types from pthread.h with opaque dummy  
 types of the same size, so that there is no temptation for developers  
 to use them directly.  So I did that, though really, I'm not sure that  
 was worth the bother, since the ivars concerned were already clearly  
 marked as private.

As they're marked as @private, there's no way for developers to access
them in subclasses, right?  Only the size matters for the purpose of
subclassing.  So I fail to see what the issue is, and how including a
specific header and using library types in ivars for a *required*
library (configure bails out if pthread is not found) is exposing
internal workings.

 I guess it's just good to do it to avoid having the extra symbols
 polluting developers namespaces.

I admit I don't understand this.

 Issue 2 is a technical problem ... if someone subclasses one of the
 lock classes, their compiled code is obviously dependent on the size
 of the superclass and if that size changes (eg due to using a
 different pthread implementation) then the size of the superclass
 would change even though the version of the base library is
 unchanged.  So potentially an app linked with one copy of the base
 library would fail to run properly with another copy of the library
 even though it was the same version!

If the different pthread implementation is ABI incompatible, that
would mean that gnustep-base (and anything else using this new pthread
implementation) *must* be rebuilt.  Two different incompatible
implementations on one platform can only coexist if they have
different SONAME.

So, if Base is rebuilt because the size of, say, pthread_mutex_t is
different (i.e. ABI change in pthread), then config.status will
substitute @GS_PTHREAD_MUTEX_T@ to the new value, achieving what
... the compiler would do automatically with David's code before that
change.

If Base is not rebuilt (for whatever reason -- user/distro omission
for example), the opaque type will not help at all, because gs_mutex_t
would still have the wrong size -- it would match the size of
pthread_mutex_t at the time Base was compiled.  The class size will
not match the actual size at runtime, possibly leading to the breakage
the trick was intended to avoid.

In conclusion, I think this change serves no purpose and doesn't make
*anyone's* life easier.  I may be wrong, but it seems to me that using
directly pthread types in ivars does no harm at all, in practice.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Can't install Gorm on Gentoo

[Yavor Doganov]

В Mon, 16 Aug 2010 17:20:44 +0200, csanyipal написа:

 $ emerge -s gnustep-base
 gnustep-base/gnustep-base
 Latest version installed: 1.20.1

 $ emerge -s gorm
 gnustep-apps/gorm
 Latest version available: 1.2.8

That's why it doesn't build.

 How can I build the latest Gorm release on Gentoo?

I don't know, I've never used Gentoo.  I guess you'd have to ask on 
Gentoo support lists and file a bug for Gorm's FTBFS.

 Can one use and if can, how, the patch from
 http://bugs.debian.org/581940?

Applying the patch (with the `patch' program) and rebuilding it ought to 
work...


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Can't install Gorm on Gentoo

[Yavor Doganov]

В Sun, 15 Aug 2010 08:35:21 +0200, csanyipal написа:

 Any advices will be appreciated!

You are apparently using Base 1.20 or SVN trunk.  Either build the latest 
Gorm release, or grab the patch from http://bugs.debian.org/581940.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Weird focus problem with GNUstep applications in WindowMaker

[Yavor Doganov]

В Thu, 22 Jul 2010 14:31:32 +0200, Eric Brunel написа:

 but it seems they don't upgrade them very often.

Well, upgrading them in the stable suite is completely out of question.  
OTOH, backports are useless because of the SONAME bumps.

 I checked the testing and unstable releases for the versions to come;
 There are a few improvements indeed, but they're still not at the latest
 versions.

The latest Base/GUI/Back is in experimental, waiting (8 months already
:-() for permission from the Release Team for the library transition.

 And besides, I'd prefer using a stable distribution.

I am using even an even older combination on gNewSense (1.14/0.12).
Some bugs are annoying, but still bearable. 

 What are my options here?

1. Fetch the most recent Debian source packages, build and install
   the .debs.
2. Install GNUstep from SVN with GNUSTEP_INSTALLATION_DOMAIN=USER.
3. Purge your distro packages, and install GNUstep from SVN with the
   native layout.

 Debian is quite different from the standard one,

The standard one for GNUstep, you mean.  The FHS layout Debian
packages (almost) adhere to *is* the standard for the Debian
distribution; the GNUstep stack was threatened with removal a few
years ago for non-compliance.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Can't run ProjectCenter on Debian Squeeze

[Yavor Doganov]

В Mon, 19 Jul 2010 13:28:56 -0600, German Arias написа:

 But definitively was a bug on libraries, not in PC.

It is definitely not a bug in PC, and I doubt it is a bug in the 
libraries; as I mentioned at http://bugs.debian.org/589500 it is most 
probably misconfiguration (defaults write somthing wrong).


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Renaissance - how to use Grids?

[Yavor Doganov]

В Tue, 29 Jun 2010 19:39:01 +0100, Nicola Pero написа:

 I have installed GNUstep on my Debian GN U/Linux Squeeze with aptitude.
 Should I purge this installation and install gnustep from SVN? :(
 
 Unfortunately, yes.

No, there is absolutely no reason to purge the whole GNUstep stuff and
reinstall from SVN.  You will encounter various difficulties for no
good reason.

Assuming that the forthcoming Renaissance release is ABI compatible
with 0.9.0, and it works with Base 1.19.3/GUI 0.16.0, you can do:

$ apt-get source renaissance
# apt-get build-dep renaissance
# aptitude install build-essential devscripts
$ cd your-fresh-renaissance-svn-checkout
$ svn export ... (optional)
$ gs_make dist
$ cd some-other-dir
$ cp your-fresh-renaissance-svn-checkout/releases/
Renaissance-0.9.0.tar.gz .
$ tar xzvf Renaissance*  cd Renaissance*
$ cp -a your-renaissance-debian-source/debian .
$ dch -l local Temporary package of SVN trunk.
$ dpkg-buildpackage -us -uc
# dpkg -i ../*.deb

That way, when we package the new release, and it migrates to testing,
the package manager will automatically replace your custom package
with the official one.  No need to mess with the rest of the debian
GNUstep packages.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: How to localize keyEquivalent=q?

[Yavor Doganov]

Paul Chany wrote:
 OK but GNUstep doesn't support accelerators for menus/buttons, right?

TTBOMK, it does not.

 Why not?

Not sure, but several reasons (or a combination) come to mind:

1) Nobody bothered to implement this functionality.
2) Apple does not support it (I don't actually know what Apple
   supports or not -- this is just a wild guess), which often leads to
   less motivation for 1).
3) There's been little or practically no users' interest, which means
   less incentive for 1) as well.
4) You name it.  Free software projects are what they are, and that's
   how it should be.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: How to localize keyEquivalent=q?

[Yavor Doganov]

В Thu, 24 Jun 2010 11:29:45 +0200, Paul Chany написа:

 Everything is compiled in to Window.app Resources but still don't works
 the q = k or q = i translations? Why?

Because that's the right thing to do.  Localizing keybindings/shortcuts 
would lead to a horrible mess:

  - One app can be translated, another one not, so common keybindings 
like Quit, Copy, Paste, etc. will differ making the environment
inconsistent and confusing for the user.
  - With incomplete translations, you add to the mess that some of the
shortcuts will be English, some will be translated and may require
switching the keyboard (or even input method).  While using the
very same instance of the app.  More confusion.
  - Some users prefer more than one language.  For instance I have
LANGUAGE=bg:mk:ru:sr:ro.  So the translations of some programs are a
mixture of these languages.  Some are completely in Bulgarian, some 
completely in Russian, some Serbian + English, etc. etc.  (Yes, I
really like that feature of gettext).  I can't really imagine what
would happen if shortcuts were translatable...


Accelerators for menus/buttons is one thing and it's absolutely 
compulsory for them to be localizable.  But shortcuts in the application 
should be the same no matter the language, and in environments striving 
for consistency/user-friendliness shortcuts for common/known/widespread 
actions should match too across different applications.

This is not a misfeature of GNUstep and/or Renaissance.  Take a look at 
GTK+/GNOME for example.  There's a good reason for this.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Exceptions on Debian causing SIGABRT

[Yavor Doganov]

[Apologies for the belated response.]

В Sat, 24 Apr 2010 12:33:54 +0200, Denis Defreyne написа:

 I am running Debian on a 64-bit system and I am experiencing odd
 behaviour when raising exceptions. Raising an exception causes the app
 to terminate with a SIGABRT without printing the exception itself or any
 other diagnostic info.

This is a very old and rather annoying Debian bug.  It's fixed in 
experimental, and we hope to obtain permission to upload the new GNUstep 
stack to unstable Real Soon Now.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: ANN: Graphos 0.1

[Yavor Doganov]

Congratulations!  I'll file an ITP to get this into Debian.

One minor remark.  The tarball has autosaved files:

ya...@keel:/tmp/Graphos-0.1$ find -name '.#*'
./.#GNUmakefile.1.9
./.#GNUmakefile.1.4
./.#GRBezierPathEditor.m.1.6
./.#PC.project.1.11
./.#GNUmakefile.1.8
./.#PC.project.1.16
./Resources/GRDocument.gorm/.#data.info.1.1
./Resources/GRDocument.gorm/.#objects.gorm.1.2
./.#PC.project.1.17

This junk is causing us trouble.  BatMon has an even more serious issue 
since it has object files.  It is a good idea to run `make distclean' (or 
even better: cvs export) before `make dist' and make sure all these files 
are removed...


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Building some extra libs (renaissance, gnustep-guile,

[Yavor Doganov]

В Fri, 02 Oct 2009 19:39:44 +0100, Richard Frith-Macdonald написа:

 Based on a lot of trial and error, it seems that --disable-jdbc-bundle
 triggers some autoconf bug such that subsequent tests fail.

Not an Autoconf bug.  With the goal to provide smaller configure scripts 
and avoid duplicate checks, code for AC_REQUIRE'd macros is not inserted 
on every invocation of a particular macro.  IOW, AC_CHECK_HEADERS 
indirectly requires AC_PROG_CC and AC_PROG_CPP, but code for checking the 
compiler/preprocessor is not inserted at every place you call that macro, 
only before the first expansion of AC_CHECK_HEADERS (or any other macro 
that requires these variables to be set).  Autom4te discovers if/when it 
is needed by tracing configure.ac.

Because with --disable-jdbc-bundle the macro expansion falls in the 
`else' branch, the code for detecting the compiler/preprocessor is not 
executed and every further test that relies on these variables being set 
is broken.

 I have put a workaround in configure.ac in svn trunk (adding an extra  
 call to AC_CHECK_HEADERS before the test

In case of nested if/else statements like here, and in general almost 
always, the proper fix is to call AC_PROG_CC and AC_PROG_CPP earlier in 
configure.ac, before any conditionals.



___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: framework

[Yavor Doganov]

В Thu, 27 Aug 2009 13:21:48 +0100, David Chisnall написа:

 If you are linking against a GPL'd framework, you do not have to make
 your code GPL'd, you have to release your code under a GPL-compatible
 license.

This is not accurate.  If you distribute your code and it links against a 
GPL'ed library, you *must* license it under the GPL.  That's the whole 
point in using GPL for libraries:

  http://www.gnu.org/philosophy/why-not-lgpl.html

IOW, any application or library that links with (say) the GNU Scientific 
Library (GSL) must be GPLv3 or later.

OTOH, if he doesn't distribute his code at all, all licensing 
considerations are moot.



___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: framework

[Yavor Doganov]

David Chisnall wrote:
 And this is what I am talking about when I say that people should
 read and understand the GPL, and the relevant bits of international
 copyright law it depends upon, before using it...

Right...  My way of thinking is severely twisted around binary-based
distros.  I stand corrected.

 You may release a framework that depends on a GPL framework under,
 for example, an MIT license, however the combined work of your
 framework plus the GPL'd framework falls under the GPL.

(I assume you mean the X11 license -- MIT has many licenses, some of
them proprietary.)

Yes, you're right -- the only condition is the license to be
GPL-compatible.  But for all practical reasons, GPL is the only viable
option in such situations.  (That's why the Enlightenment folks asked
the GNU PDF developers to downgrade the license to LGPL, because they
have a fairly firm formal rule all components to be under a
non-copyleft license.)  Out of curiosity -- I was also wondering if
this is the same reason why you don't use libfaad in Melodie, but rely
on a library which is not widely available in distros due to software
patents concerns.

 If you are not distributing the GPL'd framework, you do not have to
 comply with the GPL, however anyone distributing your framework and
 the GPL'd framework (e.g. Linux distributions) will have to.

Yes, for example if Adun.app was under the Expat license, Debian [1]
will have to distribute it under GPL, because it links dynamically
with GSL.

[1] FWIW, Debian is not a Linux [sic] distribution.  There are ports
that do not use the Linux kernel -- GNU/kFreeBSD and GNU/Hurd, and
soon GNU/kOpenSolaris.



___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: ANNOUNCE: Terminal v0.9.5

[Yavor Doganov]

В Wed, 27 May 2009 20:55:38 -0700, Gregory John Casamento написа:
 we can discuss a name change.

Rather than changing the name, it would be much better if both parties 
agree Terminal to be maintained at one place only -- be it Backbone, GAP 
or somewhere else.  And just merge the useful modifications.

Not only this would avoid natural user confusion, but it would also help 
distributors who face the dillema which one to ship.



___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Cynthinue-0.9.5 doesn't compile

[Yavor Doganov]

Zhang Weiwu wrote:
 I could not use the debian build-dependencies because I am using a
 chopped version of Debian

OK, then download the Debian source package (from ftp.debian.org) and
look at debian/control?  Here they are (GNUstep and Debian-related
ones stripped):

Output bundles:
libesd0-dev (Esound)
libartsc0-dev   (aRTS)

Format/tags bundles:
libvorbis-dev   (Ogg Vorbis)
libmad0-dev (MP3)
libid3tag0-dev  (MP3, ID3Tag)
libmodplug-dev  (Mod)
libflac-dev (FLAC)
libaudiofile-dev(Audiofile)
libtagc0-dev(MP3, Taglib)
libavifile-0.7-dev,
libdts-dev  (Windows Media)
libmusicbrainz4-dev (required by the program itself)
libmpcdec-dev   (Musepack)

 I guess at least I would need to get these bundles and compile the 
 important ones, e.g. MP3 and OGG.  I don't know where to get them

The README file has pointers to some homepages, in case you have to
build them from source.  But if you're on a Debian-based system,
better install them from its archive, if they're available.

 I'd dream about a site that collects bundles like GAP collects 
 applications, so I can download a dozen bundles all at once.

All Cynthiune's bundles are shipped with Cynthiune; I'm not aware of
any third-party bundles.



___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Cynthinue-0.9.5 doesn't compile

[Yavor Doganov]

Zhang Weiwu wrote:
 Thanks.  However even if I applied all patches from debian 
 http://patch-tracking.debian.net/package/cynthiune.app/0.9.5-7.1 I 
 still could not compile it.

You are missing several build-dependencies.  Either install them with

# apt-get build-dep cynthiune.app

or disable the bundles you don't need with

make disable-bundle=yes

(See the toplevel GNUmakefile for the right conditionals.)

 As far as I know from the application index, Cynthinue is the only
 music player for gnustep except mpd. 

There is also Mélodie from the Étoilé project.



___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Cynthinue-0.9.5 doesn't compile

[Yavor Doganov]

Zhang Weiwu zhangweiwu at realss.com writes:

 NSCellExtensions.m: In function [NSCell(CynthiuneExtensions) widthOfText:]:
 NSCellExtensions.m:34: error: NSFontAttributeName undeclared (first use in
this function)
 NSCellExtensions.m:34: error: (Each undeclared identifier is reported only 
 once
 NSCellExtensions.m:34: error: for each function it appears in.)

Like many other (semi-)abandoned GNUstep apps, it needs modifications to compile
and run with recent GNUstep releases.  For this problem, specifically:

http://patch-tracking.debian.net/patch/misc/view/cynthiune.app/0.9.5-7.1/Frameworks/Cynthiune/NSCellExtensions.m



___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

Required default fonts by the backend not always available

[Yavor Doganov]

Package: gnustep-back0.16-cairo
Version: 0.16.0-3

(Hubert/Gürkan: FYI this is a followup to this thread:
http://thread.gmane.org/gmane.comp.lib.gnustep.general/32777)

В Thu, 07 May 2009 09:07:52 +0800, Zhang Weiwu написа:
   
 Hi thanks I solved it with:
 $ defaults write NSGlobalDomain NSFont 'DejaVu Sans' 

This should not be necessary in most common situations, although it is
recommended in /usr/share/doc/gnustep-backSONAME/README.Debian which
is a file Debian users *should* read, especially if they encounter
problems.

I can't reproduce your issue, though:

$ mv ~/GNUstep/Defaults/.GNUstepDefaults GNUstepDefaults.orig
$ defaults write NSGlobalDomain GSBackend libgnustep-cairo
$ Ink

...starts and runs perfectly fine here, with NSFont apparently
BitStream Vera Sans.  But this font is being deprecated in Debian, so
no longer installed by default (`aptitude why' tells me I have it
installed automatically here because fontconfig-config depended on
it).  The second fallback ttf-freefont is also not pulled in by the
GNUstep dependency chain, which explains your problem.

 I more or less consider this is a packager's mistake.

Debian packages cannot mess with your $HOME, so the only way to
eliminate the problem efficiently is to add DevaVu as another option
to the appropriate CairoFontEnumerator methods before the final
fallback Helvetica.  Perhaps it is a good idea this to be done
upstream, instead of a Debian-specific patch.

Another quick  dirty Debian fix is the cairo backend to depend on the
ugly ttf-bitstream-vera | ttf-freefont.  (Actually, only the latter as
ttf-bitstream-vera is scheduled for removal:
http://bugs.debian.org/461308)

 After all many people choose to use a distribution instead of
 compiling everything manually is because they want the task to fight
 dependency  configuration an optional task instead of mandantory.

Right; and these people should report such issues to the distro
instead, so that bugs get properly tracked/fixed/forwarded upstream
(if necessary) accordingly.  Which I'm doing now.



___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Terminal seems to suffer from cropped line using cairo

[Yavor Doganov]

В Thu, 07 May 2009 17:01:46 +0800, Zhang Weiwu написа:

 Debian also packaged Preferences.app instead of SystemPreferences.app
 where the latter is said to be better replacement of the former.

For historical reasons.  SystemPreferences did not exist when
Preferences was packaged; also the Backbone main developer was a
Debian developer as well.  Gürkan was also involved, I think.  Even
GAP did not exist back then, IIRC.

Looking at http://git.savannah.gnu.org/cgit/backbone.git it doesn't
seem to be completely abandoned.  They've never made releases, though.

If the GNUstep community agrees, I don't see a problem if we replace
preferences.app with systempreferences.app (removing the former from
the archive entirely) and package terminal.app with GAP as new
upstream.  textedit.app has to stay for the time being as there is no
proper replacement.



___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: linking tool to use a framework : obj_send_msg error

[Yavor Doganov]

В Sun, 12 Apr 2009 23:23:13 +0200, Thomas Kupper написа:

 Can someone give me a hint how I can track down that error?

Use ADDITIONAL_TOOL_LIBS, e.g.

ADDITIONAL_TOOL_LIBS = -llog4cocoa



___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: GSL and GNUStep

[Yavor Doganov]

В Thu, 13 Nov 2008 21:58:29 -0800, Germán Arias написа:

 Hi, How can I use GSL (GNU scientific library) in my app?

Trivially, like any other library.  For an app, use ADDITIONAL_GUI_LIBS.

You might want to look at Adun which extensively uses GSL both for the UL 
application and its own libraries.  There are some other interesting 
things too, like convenient Objective-C wrappers for GSL functions.

Beware, as far as Adun's usage of GNUstep Make is concerned, not 
everything they do is correct -- so always refer to the manual.



___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: gnustep debian app developer env setup (help needed)

[Yavor Doganov]

В Thu, 06 Nov 2008 13:22:09 -0800, EL написа:

 I tried ubuntu 8.10 desktop, it not include dev sources by default. That
 give an empression that the desktop version of ubuntu is mainly not for
 gnustep developers.

Hmm, I'm not sure what sources you have in mind.

You should be able to install a GNUstep development environment with 
aptitude install libgnustep-gui-dev.  This will pull make, gnustep-
make, gobjc, libobjc, -base-dev, etc.  I usually recommend this command 
to people who want to build and test Emacs.app.

If you need a full-blown environment, install gnustep-devel which will 
pull in additionally Gorm, PC, ProjectManager, Renaissance and all the 
documentation.

This works on Debian and should work on Ubuntu too.



___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Problem with Emacs.app

[Yavor Doganov]

В Tue, 07 Oct 2008 23:32:27 -0700, Germán André Arias Santiago написа:

 Can somebody help me with this problem?

Use Emacs CVS trunk, it has been merged there.

cvs -z3 -d:pserver:[EMAIL PROTECTED]:/sources/emacs co emacs



___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Printing

[Yavor Doganov]

В Thu, 15 May 2008 17:33:04 -0400, Hubert Chathi написа:

 (And for the record, the reason that the Debian packages are lagging
 behind is due to the GPL2/LGPL3 incompatibility issues.)

Plus, we don't want to release Lenny with unstable GNUstep that is not 
blessed as stable by upstream, do we?  Anything uploaded to unstable 
should be release quality that would end up in a Debian stable release.

That said, if there are no stable releases of Base, GUI and Back within a 
month or two (until the Debian full freeze), I guess we'll stick with the 
current versions and will handle the licensing issues afterwards.  Just 
my thoughts, of course.



___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Maintainers for Ladder and LapisPuzzle?

[Yavor Doganov]

В Mon, 07 Apr 2008 23:55:27 +0200, Riccardo Mottola написа:

 LapisPuzzle 1.1.0 has just been released [...]

Unfortunately, someone else from the Debian folks was very quick and both 
packages were removed shortly after I sent my initial message.  So 
they'll have to pass through NEW processing, which probably will not 
happen until Lenny is released.

Perhaps this is my fault, as I haven't updated the bug logs accordingly 
while we were discussing the resurrection here :-((



___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Maintainers for Ladder and LapisPuzzle?

[Yavor Doganov]

On Tue, Feb 26, 2008 at 02:29:05PM +0100, Riccardo Mottola wrote:
 On 2008-02-25 18:57:25 +0100 Yavor Doganov [EMAIL PROTECTED] wrote:
 Ladder and LapisPuzzle are scheduled for removal from Debian:

 http://bugs.debian.org/466123
 http://bugs.debian.org/466125

 the two bugs appear to be the same for both applications?

They are similar but not identical.  In Debian every request for removal 
must be filed as a separate bug.

 If anybody wants to contribute some patches to fix the biggest  
 shortcomings like key bindings, I can apply them into GAP repository,

Barry, could you please summarize the disturbing things?  If they are 
easy to fix, perhaps it is worth trying.  (The packages themselves could 
be maintained by the GNUstep team, if the Games team doesn't want them.)

 if somebody events wants to join GAP and mantain them, evenn betterl. 
 let me know.

Thanks for the offer.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Update GNUstep on Debian to more recent version?

[Yavor Doganov]

В Thu, 20 Dec 2007 00:53:16 +0100, Markus Hitter написа:

 Would it be possible to shorten this chain somewhat, i.e. map GNUstep
 trunk to Debian unstable and do a (hopefully automated) fetch weekly?

No -- everything uploaded to Debian unstable should be release 
quality.  Snapshots that are not blessed by upstream, as in this case, do 
not meet this criteria.

Furthermore, because of the gratuitous SONAME bump in every release of -
base and -gui, this will break all GNUstep applications more often than 
they break now.

Last, but not least, the Debian GNUstep team consists of 3 active people 
-- 2 of them are not DDs and all of us participate in other projects.  We 
don't have the resources to do this, but even if we did, it would be hard 
enough.  Even uploading to `experimental' would be useless, because the 
apps in sid have to be recompiled against the unstable libraries in 
`experimental' and thus should depend on them, which is forbidden by the 
Debian Policy for very good reasons (e.g. packages in `unstable' will be 
uninstallable because they will depend on packages in `experimental').



___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Update GNUstep on Debian to more recent version?

[Yavor Doganov]

В Wed, 19 Dec 2007 08:14:23 +0100, Dr. H. Nikolaus Schaller написа:

 Software-publishing-psychology suggests a timing of minor
 updates every 6 weeks.

It seems that you have installed the current Debian stable release, 
a.k.a. Etch.  Packages there are updated only when a security-related 
or critical bug is found.  The next stable release is expected at the end 
of 2008, although it might be delayed a bit.

 Is there a method in Debian to partially update the distro, i.e. choose
 which branch the package manager looks at?

Yes, /etc/apt/sources.list.  Upgrading from stable - testing - unstable 
is not guaranteed to work.  Basically, you need to change the entries in 
that file to `testing' and do `aptitude dist-upgrade', then change to 
`unstable' and repeat that step (if you're willing to upgrade to 
unstable, of course).

Current Debian sid has Gorm 1.2.2; the other packages are also up to date 
with a few exceptions.  The GNUstep stack is about to migrate to testing 
in the very near future (next weeks, if we resolve all issues).

 Before someone draws false generalized conclusions - the Aug 06 GORM
 crashes for me only when trying to save a special set of given .gorm
 files in Cocoa NIB format.

Please file a bug report (`reportbug gorm.app' or `M-x debian-bug RET p 
RET gorm.app RET' if you use Emacs).  I'll try to reproduce this on a 
stable box.

 Does someone know how such updates are made available by Debian?

Packages are uploaded to unstable (a.k.a. `sid') and migrate to `testing' 
when they pass the quarantine period (usually 10 days), are built on all 
official architectures, do not have release-critical bugs and are not 
tied to other transitions (for example, popplerkit.framework cannot 
migrate if it depends on poppler = 0.6 until all poppler-depending 
packages are built, installed, and ready to migrate).

In addition, there is `experimental' suite, which is not self-contained 
(i.e. it can be used only together with `unstable').

When Debian is about to release, `testing' is frozen (the toolchain 
first, then everything else) and updates propagate after review from the 
release team.  When all bugs in the distribution are fixed, testing is 
declared stable and usual packages migration sid - testing is open 
again.  The cycle then repeats.



___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Update GNUstep on Debian to more recent version?

[Yavor Doganov]

В Wed, 19 Dec 2007 03:01:30 -0800, [EMAIL PROTECTED] написа:

 Please file a bug report (`reportbug gorm.app' or `M-x debian-bug RET p
 RET gorm.app RET' if you use Emacs).  I'll try to reproduce this on a
 stable box.

Hmm, there are no bugs filed against the debian package gorm.app.  
Perhaps you meant http://savannah.gnu.org/bugs/?21845?

 It appears to be a quite sophisticated process which contributes to a
 high level of stability

Yes, it is.  Debian stable releases are stable as a rock, at least from 
my experience.

 - although it might be a little slow if one
 wants to use stable versions only (1,5 years from stable GNUstep on Etch
 to the next one...).

For free software developers, running stable is not suitable in most 
cases, yes -- especially if you want to use new features available in the 
new versions of the libraries, tools, modern compilers, etc.  There are 
roughly two solutions: 1) use `testing' which is regularly updated but 
doesn't break that often like unstable -- that's what I do at work; 2) 
rebuild the whole GNUstep pile yourself and remember to rebuild it every 
time there is a SONAME change (which unfortunately means every new major 
release).

 Many thanks for this description.

You're welcome.



___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: My messages reaches late

[Yavor Doganov]

There was a problem with the connection serving lists.gnu.org, 
mail.gnu.org and rt.gnu.org.  It is temporarily solved, but messages will 
probably still arrive late until the huge backlog is processed.



___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: GNUstep.sh on Debian sid

[Yavor Doganov]

В Thu, 13 Dec 2007 12:30:02 +, Gerold Rupprecht написа:

 You may want to source it from your .profile file as follows:
 
 . /usr/share/GNUstep/Makefiles/GNUstep.sh

You don't have to do that anymore.  You only need to set up 
GNUSTEP_MAKEFILES=/usr/share/GNUstep/Makefiles if you compile GNUstep 
stuff (i.e. a typical user doesn't have to do anything).  

BTW, there's a wrapper `gs_make' that does exactly this.

 If you do not source this file, you will fail to correctly open a new
 session from gdm.

Could you please provide an exact recipe to reproduce the case (I don't 
use gdm myself) -- ideally, in a Debian bug report?  What exactly fails?



___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: GNUstep slogan - discussion and voting (was: Re: Objective-C 2.0 and other new features in Leopard)

[Yavor Doganov]

If there is going to be a slogan, it has to clearly mention GNUstep's 
primary goal, which has always been software freedom.  



___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep