[bug #64983] PDF generation fails with texinfo/7.1

[Yavor Doganov]

URL:
  <https://savannah.gnu.org/bugs/?64983>

 Summary: PDF generation fails with texinfo/7.1
   Group: GNUstep
   Submitter: yavor
   Submitted: Tue 05 Dec 2023 10:14:17 AM EET
Category: Makefiles
Severity: 3 - Normal
  Item Group: Documentation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any


___

Follow-up Comments:


---
Date: Tue 05 Dec 2023 10:14:17 AM EET By: Yavor Doganov 
With texinfo/7.1, PDF generation for two documents in the gnustep-make package
(gnustep-make.texi and gnustep-filesystem.texi) fails with the following
error:


$ texi2pdf gnustep-filesystem.texi 
This is pdfTeX, Version 3.141592653-2.6-1.40.25 (TeX Live 2023/Debian)
(preloaded format=pdfetex)
 restricted \write18 enabled.
entering extended mode
(./gnustep-filesystem.texi (/usr/share/texmf/tex/texinfo/texinfo.tex
Loading texinfo [version 2023-09-19.19]: pdf, fonts, glyphs, page headings,
tables, conditionals, indexing, sectioning, toc, environments, defuns,
macros,
cross references, insertions,
(/usr/share/texlive/texmf-dist/tex/generic/epsf/epsf.tex
This is `epsf.tex' v2.7.4 <14 February 2011>
) localization, formatting, microtype, and turning on texinfo input format.)
[1{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}] [2]
(/tmp/gnustep-make-2.9.1/Documentation/gnustep-filesystem.toc
/tmp/gnustep-make-2.9.1/Documentation/gnustep-filesystem.toc:1: Undefined
contr
ol sequence.
@numsecentry ...dafter @xdef @csname @curchapname 
  @endcsname {@the @wd 0}@fi 
l.1 ...e System Domain}{1.1}{The System Domain}{1}
  
? 
/tmp/gnustep-make-2.9.1/Documentation/gnustep-filesystem.toc:1: Emergency
stop.

@numsecentry ...dafter @xdef @csname @curchapname 
  @endcsname {@the @wd 0}@fi 
l.1 ...e System Domain}{1.1}{The System Domain}{1}
  
/tmp/gnustep-make-2.9.1/Documentation/gnustep-filesystem.toc:1:  ==> Fatal
erro
r occurred, no output PDF file produced!
Transcript written on gnustep-filesystem.log.
This is pdfTeX, Version 3.141592653-2.6-1.40.25 (TeX Live 2023/Debian)
(preloaded format=pdfetex)
 restricted \write18 enabled.
entering extended mode
(./gnustep-filesystem.texi (/usr/share/texmf/tex/texinfo/texinfo.tex
Loading texinfo [version 2023-09-19.19]: pdf, fonts, glyphs, page headings,
tables, conditionals, indexing, sectioning, toc, environments, defuns,
macros,
cross references, insertions,
(/usr/share/texlive/texmf-dist/tex/generic/epsf/epsf.tex
This is `epsf.tex' v2.7.4 <14 February 2011>
) localization, formatting, microtype, and turning on texinfo input format.)
[1{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}] [2]
(/tmp/gnustep-make-2.9.1/Documentation/gnustep-filesystem.toc
/tmp/gnustep-make-2.9.1/Documentation/gnustep-filesystem.toc:1: Undefined
contr
ol sequence.
@numsecentry ...dafter @xdef @csname @curchapname 
  @endcsname {@the @wd 0}@fi 
l.1 ...e System Domain}{1.1}{The System Domain}{1}
  
? 
/tmp/gnustep-make-2.9.1/Documentation/gnustep-filesystem.toc:1: Emergency
stop.

@numsecentry ...dafter @xdef @csname @curchapname 
  @endcsname {@the @wd 0}@fi 
l.1 ...e System Domain}{1.1}{The System Domain}{1}
  
/tmp/gnustep-make-2.9.1/Documentation/gnustep-filesystem.toc:1:  ==> Fatal
erro
r occurred, no output PDF file produced!
Transcript written on gnustep-filesystem.log.
/usr/bin/texi2dvi: pdfetex exited with bad status, quitting.


I guess the culprit is that a sectioning command is used for the top node
while it is not destined for printed output (that's why texinfo documentation
advised to enclose it in an @ifnottex conditional but that's now done
automatically behind the scenes).  Note that even with older texinfo versions,
the PDF file for gnustep-filesystem is generated wrongly: it lacks the
introductory text at the beginning, starting with "The System Domain" right
after the contents.

Attached is a trivial patch that fixes these problems.






___
File Attachments:


---
Date: Tue 05 Dec 2023 10:14:17 AM EET  Name:
0001-Fix-PDF-generation-with-texinfo-7.1.patch  Size: 27KiB   By: yavor

<http://savannah.gnu.org/bugs/download.php?file_id=55405>

___

Reply to this item at:

[bug #64493] Spelling errors in gdnc.m and gspath.1

[Yavor Doganov]

URL:
  <https://savannah.gnu.org/bugs/?64493>

 Summary: Spelling errors in gdnc.m and gspath.1
   Group: GNUstep
   Submitter: yavor
   Submitted: Sun 30 Jul 2023 02:42:28 PM EEST
Category: Base/Foundation
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any


___

Follow-up Comments:


---
Date: Sun 30 Jul 2023 02:42:28 PM EEST By: Yavor Doganov 
That's an old patch that I have apparently forgotten to forward.  Fixes a few
obvious spelling errors.






___
File Attachments:


---
Date: Sun 30 Jul 2023 02:42:28 PM EEST  Name: 0001-Fix-spelling-errors.patch 
Size: 2KiB   By: yavor

<http://savannah.gnu.org/bugs/download.php?file_id=54998>

___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64493>

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64492] HTMLLinker.1: warnings with groff/1.23.0

[Yavor Doganov]

URL:
  <https://savannah.gnu.org/bugs/?64492>

 Summary: HTMLLinker.1: warnings with groff/1.23.0
   Group: GNUstep
   Submitter: yavor
   Submitted: Sun 30 Jul 2023 01:44:12 PM EEST
Category: Base/Foundation
Severity: 3 - Normal
  Item Group: Documentation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any


___

Follow-up Comments:


---
Date: Sun 30 Jul 2023 01:44:12 PM EEST By: Yavor Doganov 
A typo of mine causes a warning with recent groff (1.23.0):


$ LC_ALL=C.UTF-8 MANROFFSEQ='' MANWIDTH=80 man --warnings -E UTF-8 -l -Tutf8
-Z Tools/HTMLLinker.1 >/dev/null
troff::50: warning: cannot select font '\'


Patch attached.






___
File Attachments:


---
Date: Sun 30 Jul 2023 01:44:12 PM EEST  Name: 0001-Fix-a-groff-warning.patch 
Size: 1KiB   By: yavor

<http://savannah.gnu.org/bugs/download.php?file_id=54997>

___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64492>

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64434] 1.29.0 testsuite failures on Debian

[Yavor Doganov]

URL:
  <https://savannah.gnu.org/bugs/?64434>

 Summary: 1.29.0 testsuite failures on Debian
   Group: GNUstep
   Submitter: yavor
   Submitted: Mon 17 Jul 2023 05:58:59 PM EEST
Category: Base/Foundation
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any


___

Follow-up Comments:


---
Date: Mon 17 Jul 2023 05:58:59 PM EEST By: Yavor Doganov 
I apologise that it took me so long to report this.  On Debian unstable (GCC
13.1.0, GLIBC 2.37, ICU 72.1) 26 tests related to time zones fail:


base/NSCalendar/era.m:
Failed test: (2023-07-17 11:47:52.610 +)   era.m:51...
getHour:minute:second:nanosecond:fromDate: returns correct hour

base/NSCalendarDate/test00.m:
Failed test: (2023-07-17 11:47:57.170 +) test00.m:113 ...
+dateWithString:calendarFormat:locale: handles Africa/Addis_Ababa
Failed test: (2023-07-17 11:47:57.171 +) test00.m:252 ... date check
with 2002-03-31 01:30:00
Failed test: (2023-07-17 11:47:57.171 +) test00.m:267 ... date check
with 2002-03-31 01:30:00
Failed test: (2023-07-17 11:47:57.171 +) test00.m:271 ... date check
with 2002-03-31 00:30:00
Failed test: (2023-07-17 11:47:57.172 +) test00.m:428 ... date year
calculation preserves timezone

base/NSCalendarDate/test02.m:
Failed test: (2023-07-17 11:47:57.678 +) test02.m:171 ... %Z format
works in description
Failed test: (2023-07-17 11:47:57.678 +) test02.m:175 ... %z format
works in description
Failed test: (2023-07-17 11:47:57.678 +) test02.m:195 ... %H%M format
works in description

base/NSDateFormatter/general.m:
Failed test: (2023-07-17 11:48:23.996 +)   general.m:81 ... EST time
zone is correctly accounted for.

base/NSTimeZone/create.m:
Failed test: (2023-07-17 11:52:32.777 +) create.m:32 ...
+timeZoneWithAbbreviation works
Failed test: (2023-07-17 11:52:32.777 +) create.m:36 ...
+timeZoneWithName works

base/NSTimeZone/localtime.m:
Failed test: (2023-07-17 11:52:33.060 +) localtime.m:62 ...
+timeZoneWithName works
Failed test: (2023-07-17 11:52:33.060 +) localtime.m:67 ... pre-1996
standard time offset vs UTC found for System Europe/Paris
Failed test: (2023-07-17 11:52:33.060 +) localtime.m:71 ... pre-1996
DST time offset vs UTC found for System Europe/Paris
Failed test: (2023-07-17 11:52:33.060 +) localtime.m:76 ... post-1996
standard time offset vs UTC found for System Europe/Paris
Failed test: (2023-07-17 11:52:33.060 +) localtime.m:80 ... post-1996
DST time offset vs UTC found for System Europe/Paris

base/NSTimeZone/use.m:
Failed test: (2023-07-17 11:52:33.395 +)   use.m:60 ... can calculate
next DST transition
Failed test: (2023-07-17 11:52:33.395 +)   use.m:67 ... Correctly
localizes Europe/Brussels standard time zone name
Failed test: (2023-07-17 11:52:33.395 +)   use.m:71 ... Correctly
localizes Europe/Brussels DST time zone name
Failed test: (2023-07-17 11:52:33.395 +)   use.m:75 ... Correctly
localizes Europe/Brussels short time zone name
Failed test: (2023-07-17 11:52:33.395 +)   use.m:79 ... Correctly
localizes Europe/Brussels short DST time zone name
Failed test: (2023-07-17 11:52:33.395 +)   use.m:87 ... Correctly
localizes America/Sao_Paulo standard time zone name
Failed test: (2023-07-17 11:52:33.395 +)   use.m:91 ... Correctly
localizes America/Sao_Paulo DST time zone name
Failed test: (2023-07-17 11:52:33.395 +)   use.m:110 ... Returns
correct Daylight Saving offset.
Failed test: (2023-07-17 11:52:33.396 +)   use.m:113 ... Returns
correct Daylight Saving offset.


>From the test log:

Running base/NSCalendar/era.m...
Start set:   era.m:31 ... NSCalendar getEra:year:month:day:fromDate and
getHour:minute:second:nanosecond:fromDate tests

Unable to create time zone for name: 'Etc/UTC'
(source '(null)').

You can override the timezone name by setting the 'Local Time Zone'
NSUserDefault via the 'defaults' command line utility, a Preferences
application, or some other utility.
eg "defaults write NSGlobalDomain 'Local Time Zone' 'Africa/Nairobi'"
See '(null)'
for the standard timezones such as 'GB-Eire' or 'America/Chicago'.


The problem is that Debian has /usr/share/zoneinfo/posix removed with the
reasoning that it's unnecessary legacy while current GNUstep code relies on
it.  I suggest a simple fix as in the attached patch (TZDIR is defined in
tzdb.h).

With that patch applied, two test files abort:

base/NSCalendarDate/test00.m:
Failed file: test00.m aborted without running all tests!

base/NSTimeZone/create.m:
Failed file: create.m aborted 

[bug #61727] Premature cleanup in NSPopUpButtonCell -dealloc crashes application

[Yavor Doganov]

Follow-up Comment #8, bug #61727 (project gnustep):

I confirm it works, thanks very much!

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #61727] Premature cleanup in NSPopUpButtonCell -dealloc crashes application

[Yavor Doganov]

Follow-up Comment #3, bug #61727 (project gnustep):

I always suspect a bug in the application, especially if it's old code with
dead upstream as is the case.  I spent some time studying the code, trying to
fix some obvious bugs, etc.  It took me a while to come to the conclusion that
the crash is caused by that commit.  Running with NSZombieEnabled confirms the
theory from the code comment:


$ NSZombieEnabled=YES GTAMSAnalyzer
2021-12-24 08:58:13.907 GTAMSAnalyzer[57081:57081] NSDocumentClass Document
not found
2021-12-24 08:58:18.922 GTAMSAnalyzer[57081:57081] *** -[myProject
respondsToSelector:]: message sent to deallocated instance 0x557026edb7d0
2021-12-24 08:58:18.922 GTAMSAnalyzer[57081:57081] *** -[myProject
respondsToSelector:]: message sent to deallocated instance 0x557026edb7d0
2021-12-24 08:58:18.923 GTAMSAnalyzer[57081:57081] *** -[myProject
respondsToSelector:]: message sent to deallocated instance 0x557026edb7d0
2021-12-24 08:58:18.923 GTAMSAnalyzer[57081:57081] *** -[myProject
respondsToSelector:]: message sent to deallocated instance 0x557026edb7d0
2021-12-24 08:58:18.925 GTAMSAnalyzer[57081:57081] *** -[myProject
respondsToSelector:]: message sent to deallocated instance 0x557026edb7d0
2021-12-24 08:58:18.925 GTAMSAnalyzer[57081:57081] *** -[myProject
respondsToSelector:]: message sent to deallocated instance 0x557026edb7d0
2021-12-24 08:58:18.925 GTAMSAnalyzer[57081:57081] *** -[myProject
respondsToSelector:]: message sent to deallocated instance 0x557026edb7d0
2021-12-24 08:58:18.925 GTAMSAnalyzer[57081:57081] *** -[myProject
respondsToSelector:]: message sent to deallocated instance 0x557026edb7d0


Closing the project window deallocates it but it also updates the menus which
in turn try to access the target that no longer exists, exactly as the comment
says.  A workaround in the app would be to retain self in myProject -init but
that's a memory leak and not really a bug fix.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #61727] Premature cleanup in NSPopUpButtonCell -dealloc crashes application

[Yavor Doganov]

URL:
  

 Summary: Premature cleanup in NSPopUpButtonCell -dealloc
crashes application
 Project: GNUstep
Submitted by: yavor
Submitted on: Thu 23 Dec 2021 05:40:10 PM EET
Category: Gui/AppKit
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

GTAMSAnalyzer crashes with GUI 0.29; backtrace at
https://bugs.debian.org/1001537.  Cannot reproduce with earlier GUI versions. 
Relevant valgrind output:


==6853== Process terminating with default action of signal 11 (SIGSEGV)
==6853==  Access not within mapped region at address 0xDEADFB0E
==6853==at 0x569CD55: objc_msg_lookup (sendmsg.c:442)
==6853==by 0x4AD1DBA: _i_NSApplication__targetForAction_to_from_
(NSApplication.m:2294)
==6853==by 0x4B93B67: _i_NSMenu___autoenableItem_ (NSMenu.m:1179)
==6853==by 0x4B98D36: _i_NSMenu__update (NSMenu.m:1255)
==6853==by 0x4BBE5E0: _i_NSPopUpButtonCell__setMenuItem_
(NSPopUpButtonCell.m:640)
==6853==by 0x4BBEDEB:
_i_NSPopUpButtonCell__synchronizeTitleAndSelectedItem
(NSPopUpButtonCell.m:842)
==6853==by 0x4BBFA1A: _i_NSPopUpButtonCell__dealloc
(NSPopUpButtonCell.m:152)
==6853==by 0x4B2B1C0: _i_NSControl__dealloc (NSControl.m:125)
==6853==by 0x4C46BDB: _i_NSView__removeSubview_ (NSView.m:965)
==6853==by 0x4C55B6F: _i_NSView__dealloc (NSView.m:745)
==6853==by 0x4C46BDB: _i_NSView__removeSubview_ (NSView.m:965)
==6853==by 0x4C55B6F: _i_NSView__dealloc (NSView.m:745)


If I revert commit b7f5fb2, the problem goes away.  I think what is happening
is exactly as described in the code comment which was deleted in that commit:


/* 
 * We don't use methods here to clean up the selected item, the menu
 * item and the menu as these methods internally update the menu,
 * which tries to access the target of the menu item (or of this cell). 
 * When the popup is relases this target may already have been freed, 
 * so the local reference to it is invalid and will result in a 
 * segmentation fault. 
 */





___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #61482] plutil manpage not installed

[Yavor Doganov]

URL:
  

 Summary: plutil manpage not installed
 Project: GNUstep
Submitted by: yavor
Submitted on: Sun 14 Nov 2021 04:00:09 PM EET
Category: Base/Foundation
Severity: 3 - Normal
  Item Group: Documentation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

The plutil manpage is present but not installed.  The attached trivial patch
fixes this along with some roff warnings:


$ LC_ALL=C.UTF-8 MANROFFSEQ='' MANWIDTH=80 man --warnings -E UTF-8 -l -Tutf8
-Z Tools/plutil.1 >/dev/null
mdoc warning: Empty input line #55
mdoc warning: Empty input line #60
Usage: .Bl {-hang | -ohang | -tag | -diag | -inset}
 [-width ]
 [-offset ] [-compact]
   .Bl -column [-offset ]   ...
   .Bl {-item | -enum [-nested] | -bullet | -hyphen | -dash}
 [-offset ] [-compact] (#62)
troff: :63: warning: macro 'doc-list-type-stack0' not defined
mdoc error: .It without preceding .Bl (#63)
mdoc warning: .It macros in lists of type ''
  require arguments (#63)
troff: :63: warning: macro 'doc-' not defined (possibly
missing space after 'do')
mdoc error: .It without preceding .Bl (#65)
mdoc warning: .It macros in lists of type ''
  require arguments (#65)
troff: :65: warning: macro 'doc-' not defined (possibly
missing space after 'do')
mdoc warning: extraneous .El call (#67)




___

File Attachments:


---
Date: Sun 14 Nov 2021 04:00:09 PM EET  Name: 0001-Install-plutil-manpage.patch
 Size: 2KiB   By: yavor



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #58638] [GWorkspace] Build failure with GCC 10

[Yavor Doganov]

URL:
  

 Summary: [GWorkspace] Build failure with GCC 10
 Project: GNUstep
Submitted by: yavor
Submitted on: Sun 21 Jun 2020 06:33:18 PM EEST
Category: Application
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

See https://bugs.debian.org/957324.  Patch attached.



___

File Attachments:


---
Date: Sun 21 Jun 2020 06:33:18 PM EEST  Name: gcc-10.patch  Size: 560B   By:
yavor



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #58546] GSTLS certificate expiration test always fails on 32-bit architectures

[Yavor Doganov]

Follow-up Comment #4, bug #58546 (project gnustep):

AFAIK, the time_t limitation is on all 32 bit systems, at least glibc-based
ones.  IIRC, there were some discussions to address this issue but it turned
out that such a change would break the ABI.

Perhaps you mean *BSD systems or some Unix flavours?

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #58548] Typos in NSApplication.h

[Yavor Doganov]

URL:
  

 Summary: Typos in NSApplication.h
 Project: GNUstep
Submitted by: yavor
Submitted on: Fri 12 Jun 2020 10:26:21 AM EEST
Category: Gui/AppKit
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Cenon fails to build against GUI 0.28.0 -- see https://bugs.debian.org/962503.
 Obvious patch attached.



___

File Attachments:


---
Date: Fri 12 Jun 2020 10:26:21 AM EEST  Name:
0001-Remove-semicolons-from-the-NSAppKitVersionNumber-def.patch  Size: 4KiB  
By: yavor



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #58546] GSTLS certificate expiration test always fails on 32-bit architectures

[Yavor Doganov]

URL:
  

 Summary: GSTLS certificate expiration test always fails on
32-bit architectures
 Project: GNUstep
Submitted by: yavor
Submitted on: Thu 11 Jun 2020 08:07:00 PM EEST
Category: Base/Foundation
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

See the attached patch.  Another solution is to replace the test certificate
with a one that expires before 2038.



___

File Attachments:


---
Date: Thu 11 Jun 2020 08:07:00 PM EEST  Name: gstls-time_t-limitation.patch 
Size: 1KiB   By: yavor



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #58190] NSLocale/general.m test still fails with ICU >= 65

[Yavor Doganov]

Follow-up Comment #2, bug #58190 (project gnustep):

Thanks; works for me.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #58172] Precompiled header test broken with GCC >= 9

[Yavor Doganov]

Follow-up Comment #2, bug #58172 (project gnustep):

Thanks.  It looks like this is a Debian-specific modification to GCC; sorry
for the misleading information.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #58277] GSSpeechRecognitionServer manpage

[Yavor Doganov]

URL:
  

 Summary: GSSpeechRecognitionServer manpage
 Project: GNUstep
Submitted by: yavor
Submitted on: Thu 30 Apr 2020 03:40:32 PM EEST
Category: Gui/AppKit
Severity: 3 - Normal
  Item Group: Documentation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Please find attached a patch providing a tiny manpage for
GSSpeechRecognitionServer.



___

File Attachments:


---
Date: Thu 30 Apr 2020 03:40:32 PM EEST  Name:
0001-Add-GSSpeechRecognitionServer-manpage.patch  Size: 3KiB   By: yavor



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #58190] NSLocale/general.m test still fails with ICU >= 65

[Yavor Doganov]

URL:
  

 Summary: NSLocale/general.m test still fails with ICU >= 65
 Project: GNUstep
Submitted by: yavor
Submitted on: Thu 16 Apr 2020 04:54:04 PM EEST
Category: Base/Foundation
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

This was initially reported at https://github.com/gnustep/libs-base/issues/103
and fixed in commit 5248b6e.  Unfortunately the fix doesn't work when building
in a chroot (as is the case for the Debian package) because Locale.canonical
is not installed when the testsuite is being run.  Therefore I propose to use
the new locale identifier as in the attached patch and as suggested by user
xnox in the issue above.  It should work with all supported ICU versions.

If the old mapping needs to be tested as well, it may be done as an additional
test marked as hopeful or guarded by the appropriate ICU version check.



___

File Attachments:


---
Date: Thu 16 Apr 2020 04:54:04 PM EEST  Name:
0001-Use-new-locale-identifier-for-NSLocale-test-should-w.patch  Size: 1KiB  
By: yavor



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #58172] Precompiled header test broken with GCC >= 9

[Yavor Doganov]

URL:
  

 Summary: Precompiled header test broken with GCC >= 9
 Project: GNUstep
Submitted by: yavor
Submitted on: Tue 14 Apr 2020 02:17:13 PM EEST
Category: Makefiles
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

The script config-precomp-test/run-test.sh puts $LIBS before the program which
makes it fail with GCC 9 or later (where -Wl,--as-needed is implied):


$ LC_ALL=C gcc-8 -lobjc config-precomp-test.m
$ LC_ALL=C gcc-9 -lobjc config-precomp-test.m
/usr/bin/ld: /tmp/cczUhnH0.o: in function `main':
config-precomp-test.m:(.text+0x24): undefined reference to `objc_get_class'
/usr/bin/ld: config-precomp-test.m:(.text+0x36): undefined reference to
`objc_msg_lookup'
/usr/bin/ld: /tmp/cczUhnH0.o: in function `__objc_gnu_init':
config-precomp-test.m:(.text+0x59): undefined reference to
`__objc_exec_class'
collect2: error: ld returned 1 exit status
$ LC_ALL=C gcc-9 config-precomp-test.m -lobjc
$


Patch attached.



___

File Attachments:


---
Date: Tue 14 Apr 2020 02:17:13 PM EEST  Name:
0001-Amend-precompiled-header-test-so-that-it-works-with-.patch  Size: 3KiB  
By: yavor



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #57335] PNG writing support appears to be broken

[Yavor Doganov]

Follow-up Comment #4, bug #57335 (project gnustep):

I confirm it works for me, thanks very much.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #57335] PNG writing support appears to be broken

[Yavor Doganov]

Follow-up Comment #2, bug #57335 (project gnustep):

[comment #1 comment #1:]
> the white bits where shown as black. Is this the bug you are reporting?

Yes.

> What you did is switch off this conversion.

Yes, but not as a "fix", I was hoping that it might give you a clue what's
going wrong.

> And for simple data where alpha is either 1 or 0 this results in correct
images.

I just tried with a half-transparent image (alpha 0.5) and to my surprise the
conversion is correct with current code.  But I'm afraid that "simple data" is
quite a common case, especially for icons.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #57335] PNG writing support appears to be broken

[Yavor Doganov]

URL:
  

 Summary: PNG writing support appears to be broken
 Project: GNUstep
Submitted by: yavor
Submitted on: Sun 01 Dec 2019 06:54:28 PM EET
Category: Gui/AppKit
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Conversion between the different (supported) image formats is supposed to work
flawlessly, as should be demonstrated with the attached simple program.  I
tried it on several GNUstep app icons in TIFF format and it produces unusable
PNG images.

After some investigation it turned out that this is due to the implicit
conversion in NSBitmapImageRep -_PNGRepresentationWithProperties:, due to this
condition (NSBitmapImageRep+PNG.m:325):

+++
if ([self isPlanar] || !(_format & NSAlphaNonpremultipliedBitmapFormat))


If I change it to ([self isPlanar]) only then the resulting PNG images are
fine.



___

File Attachments:


---
Date: Sun 01 Dec 2019 06:54:28 PM EET  Name: foo.m  Size: 853B   By: yavor
Example program for converting an image to PNG


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #55690] Black images when linked with libicns; smalles icon is always loaded

[Yavor Doganov]

Follow-up Comment #5, bug #55690 (project gnustep):

As always, your patch is much simpler, more efficient and it works equally
well.  Thanks!

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #55690] Black images when linked with libicns; smalles icon is always loaded

[Yavor Doganov]

Follow-up Comment #3, bug #55690 (project gnustep):

I extracted the images with icns2png and you were right that these are 1 bit
images.

Attaching a new patch; tested with and without libicns, with TalkSoup,
TextEdit (which lacks 48x48 icon) and Lynkeos (which loads .icns images for
the app icon and also some other toolbar icons).

(file #46247)
___

Additional Item Attachment:

File name: 55690.patchSize:2 KB




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #55690] Black images when linked with libicns; smalles icon is always loaded

[Yavor Doganov]

Follow-up Comment #2, bug #55690 (project gnustep):

The icons are completely black -- they have the shape (contour) of the image
but are filled entirely in black colour.  There is no white colour at all so
one has to use her imagination to figure out what that thing is.

But you are probably right that these are the 1 bit images.  I'll try to
rework the patch so that all representations are available (as was your
intention when you implemented this method).

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #55690] Black images when linked with libicns; smalles icon is always loaded

[Yavor Doganov]

URL:
  

 Summary: Black images when linked with libicns; smalles icon
is always loaded
 Project: GNUstep
Submitted by: yavor
Submitted on: Mon 11 Feb 2019 12:13:38 AM EET
Category: Gui/AppKit
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

With libicns/0.8.1, all images derived from .icns files are black.  This
happens because icns_get_image32_with_mask_from_family from libicns is able to
handle more formats unlike the implementation in NSBitmapImageRep+ICNS.m which
caters only for the 32-bit format.  IOW, when loading TalkSoup.icns, the array
contains 4 elements with the built-in implementation but 7 elements when
linked with external libicns.

Another issue (regardless of the libicns implementation used) is that always
the smallest icon is loaded as the app icon; it happens to be the first in the
array as the .icns file is processed sequentially.  I guess this is because
the first one is tried and it passes as "best representation"...  However it
looks really ugly for apps that use .icns files for the app icon (TalkSoup,
TextEdit, Lynkeos, FreeCell).

Attached is a patch that solves both of these problems, albeit in a clumsy
way.



___

File Attachments:


---
Date: Mon 11 Feb 2019 12:13:38 AM EET  Name:
0001-Fix-image-extraction-with-libicns-place-48x48-icon-a.patch  Size: 3KiB  
By: yavor



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #55625] Crash in GSHorizontalTypesetter -_getProposedRectFor:withLineHeight:

[Yavor Doganov]

Follow-up Comment #2, bug #55625 (project gnustep):

Thanks, this is definitely better.  I confirm that it works as expected.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #55526] FTBFS on GNU/kFreeBSD: NSWorkspace.m:1252:27: error: 'MOUNTED_PATH' undeclared

[Yavor Doganov]

Follow-up Comment #5, bug #55526 (project gnustep):

Riccardo, it builds successfully, feel free to close this bug.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #55625] Crash in GSHorizontalTypesetter -_getProposedRectFor:withLineHeight:

[Yavor Doganov]

URL:
  

 Summary: Crash in GSHorizontalTypesetter
-_getProposedRectFor:withLineHeight:
 Project: GNUstep
Submitted by: yavor
Submitted on: Fri 01 Feb 2019 08:42:17 PM EET
Category: Gui/AppKit
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

GNU/Linux x86_64, GUI 0.27.0, GCC 8.2.0

This happens with Lynkeos 3.1, when stacking images from a SER file (image
sequence container) with 125 images.  I cannot reproduce if I reduce the
amount of images to 10-15.

Backtrace:

Thread 1 "Lynkeos" received signal SIGSEGV, Segmentation fault.
0x74c33d33 in objc_msg_lookup (receiver=receiver@entry=0x55d6f5f0,
op=op@entry=0x7588c5c0 <_OBJC_SELECTOR_TABLE+384>) at
/build/gcc-8-ukX2xj/gcc-8-8.2.0/src/libobjc/sendmsg.c:442
442 /build/gcc-8-ukX2xj/gcc-8-8.2.0/src/libobjc/sendmsg.c: Няма такъв
файл или директория.
(gdb) thread apply all bt

Thread 6 (Thread 0x7fffe24c3700 (LWP 21302)):
#0  0x5560cb87 in -[LynkeosDrizzleInterpolator
interpolateInPLane:atX:atY:] (self=, _cmd=,
plane=, x=, y=) at
./GNUstep/../Sources/LynkeosDrizzleInterpolator.m:277
#1  0x5566c30a in -[SER(ImageBuffer)
_initWithData:format:width:lineW:height:atX:Y:W:H:withTransform:withOffsets:]
(self=, _cmd=0x5573f440 <_OBJC_SELECTOR_TABLE+2048>,
data=, format=, width=,
lineW=, height=440, x=125, y=39, w=280, h=270, transform=...,
offsets=0x7fffd801e2e0) at ./GNUstep/../Sources/SER_ImageBuffer.m:177
#2  0x5566d5ad in -[SER(Reader)
_getCustomImageSampleAtIndex:atX:Y:W:H:withTransform:withOffsets:]
(self=0x561b3b80, _cmd=, index=,
x=, y=, w=, h=270, transform=...,
offsets=0x7fffd801e2e0) at ./GNUstep/../Sources/SER_Reader.m:482
#3  0x5563ae9a in -[MyImageListItem
getCustomImageSampleinRect:withTransform:withOffsets:] (self=0x565d50e0,
_cmd=, rect=..., transform=..., offsets=) at
./GNUstep/../Sources/MyImageListItem.m:1056
#4  0x5564772f in -[MyImageStacker processItem:] (self=0x7fffd80231e0,
_cmd=, item=0x565d50e0) at
./GNUstep/../Sources/MyImageStacker.m:273
#5  0x5565c341 in -[MyProcessingThread(Private) processList]
(self=0x7fffd800ad30, _cmd=) at
./GNUstep/../Sources/MyProcessingThread.m:120
#6  0x5565c525 in +[MyProcessingThread threadWithAttributes:]
(self=, _cmd=, attr=0x581af160) at
./GNUstep/../Sources/MyProcessingThread.m:180
#7  0x74f56608 in nsthreadLauncher (thread=0x55d53780) at
NSThread.m:1311
#8  0x758cdfa3 in start_thread (arg=) at
pthread_create.c:486
#9  0x74b3e7ef in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 1 (Thread 0x7fffe91753c0 (LWP 21287)):
#0  0x74c33d33 in objc_msg_lookup
(receiver=receiver@entry=0x55d6f5f0, op=op@entry=0x7588c5c0
<_OBJC_SELECTOR_TABLE+384>) at
/build/gcc-8-ukX2xj/gcc-8-8.2.0/src/libobjc/sendmsg.c:442
#1  0x7564450c in -[GSHorizontalTypesetter
_getProposedRectFor:withLineHeight:] (self=0x56f34070, _cmd=, newParagraph=, line_height=13.998) at
GSHorizontalTypesetter.m:486
#2  0x756446cb in -[GSHorizontalTypesetter _addExtraLineFragment]
(self=0x56f34070, _cmd=) at GSHorizontalTypesetter.m:527
#3  0x75645d2c in -[GSHorizontalTypesetter layoutLineNewParagraph:]
(self=0x56f34070, _cmd=, newParagraph=1 '\001') at
GSHorizontalTypesetter.m:610
#4  0x756464bd in -[GSHorizontalTypesetter
layoutGlyphsInLayoutManager:inTextContainer:startingAtGlyphIndex:previousLineFragmentRect:nextGlyphIndex:numberOfLineFragments:]
(self=0x56f34070, _cmd=, layoutManager=,
textContainer=0x56f6c680, glyphIndex=,
previousLineFragRect=..., nextGlyphIndex=0x7fffcc9c, howMany=0) at
GSHorizontalTypesetter.m:1293
#5  0x756403df in -[GSLayoutManager(LayoutHelpers)
_doLayoutToContainer:] (self=0x56001540, _cmd=, cindex=0)
at GSLayoutManager.m:1957
#6  0x75641bc0 in -[GSLayoutManager(layout)
glyphRangeForTextContainer:] (self=0x56001540, _cmd=,
container=) at GSLayoutManager.m:2647
#7  0x755a2b27 in cache_lookup (hasSize=hasSize@entry=1 '\001',
size=..., useScreenFonts=) at NSStringDrawing.m:289
#8  0x755a2dc7 in -[NSAttributedString(NSStringDrawing)
drawWithRect:options:] (self=0x563d2370, _cmd=, rect=...,
options=) at NSStringDrawing.m:482
#9  0x754b685f in -[NSButtonCell drawTitle:withFrame:inView:]
(self=0x57a66250, _cmd=, titleToDisplay=0x563d2370,
cellFrame=..., controlView=) at NSButtonCell.m:1062
#10 0x754b6bf6 in -[NSButtonCell drawInteriorWithFrame:inView:]
(self=0x57a66250, _cmd=, cellFrame=...,
controlView=0x5842d9e0) at NSButtonCell.m:1355
#11 0x754bd0dd in -[NSCell 

[bug #55526] FTBFS on GNU/kFreeBSD: NSWorkspace.m:1252:27: error: 'MOUNTED_PATH' undeclared

[Yavor Doganov]

Follow-up Comment #4, bug #55526 (project gnustep):

Thanks; I won't be able to build-test it until the next gnustep-gui upload to
Debian.

GNU/kFreeBSD is more closer to GNU/Linux than to FreeBSD, because the
underlying C library (glibc) is the same.  This is basically a GNU system but
running with another kernel.  Part of the confusion comes because people talk
about Linux as an OS when in fact it's just a kernel.

For programming purposes, you can (and should) treat GNU/kFreeBSD as a glibc
platform -- you are already using the portable macros as documented in the
glibc manual (albeit confusingly redefined to the deprecated ones) so that
should be sufficient.

The conditionals in -mountedLocalVolumePaths are of no concern since the
HAVE_GETMNTINFO branch will be compiled on GNU/kFreeBSD, which is fine.  It is
also fine to compile the other branch (HAVE_GETMNTENT) and you can enforce it
on GNU/kFreeBSD if you wish so with the appropriate defines.

But the result should be the same.  When Bruno Haibble ported the GNU C
Library to the FreeBSD kernel (hats off to this hacker!), he implemented
interfaces which were not feasible with the Linux kernel but were expected and
customary with a FreeBSD kernel, like getmntinfo.

So there it is, a hybrid system which proves the defines were wrong as it is
perfectly possible to have both.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #55526] FTBFS on GNU/kFreeBSD: NSWorkspace.m:1252:27: error: 'MOUNTED_PATH' undeclared

[Yavor Doganov]

Follow-up Comment #2, bug #55526 (project gnustep):

Yes, the code which triggers this is new (your changes) which is why we got
away with it until now.  I don't see anything unsafe with the patch; this code
will work on GNU/kFreeBSD in the same way as on GNU/Linux.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #55526] FTBFS on GNU/kFreeBSD: NSWorkspace.m:1252:27: error: 'MOUNTED_PATH' undeclared

[Yavor Doganov]

URL:
  

 Summary: FTBFS on GNU/kFreeBSD: NSWorkspace.m:1252:27: error:
'MOUNTED_PATH' undeclared
 Project: GNUstep
Submitted by: yavor
Submitted on: Sun 20 Jan 2019 06:57:10 PM EET
Category: Gui/AppKit
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

GUI 0.27.0 fails to build on GNU/kFreeBSD with:


gcc NSWorkspace.m -c \
  -MMD -MP -Wdate-time -D_FORTIFY_SOURCE=2 -DGNUSTEP_TARGET_DIR=\".\"
-DGNUSTEP_TARGET_CPU=\"x86_64\" -DGNUSTEP_TARGET_OS=\"kfreebsd-gnu\"
-DLIBRARY_COMBO=\"gnu-gnu-gnu\" -DGNUSTEP_BASE_HAVE_LIBXML=1
-DBACKEND_BUNDLE=1 -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 -fPIC -Wall
-DGSWARN -DGSDIAGNOSE -Wno-import -g -O2 -g -O2
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -fgnu-runtime -Wall
-fconstant-string-class=NSConstantString -I../Headers/Additions -I../Headers
-I./. -I. -I/usr/local/include/GNUstep -I/usr/include/GNUstep -Wdate-time
-D_FORTIFY_SOURCE=2 -fopenmp -DMAGICKCORE_HDRI_ENABLE=0
-DMAGICKCORE_QUANTUM_DEPTH=16
-I/usr/include/x86_64-kfreebsd-gnu//ImageMagick-6 -I/usr/include/ImageMagick-6
-I/usr/include/libpng16 \
   -o obj/libgnustep-gui.obj/NSWorkspace.m.o
NSWorkspace.m:71:4: warning: #warning "Mounted path file for you OS guessed to
/etc/mtab"; [-Wcpp]
 #  warning "Mounted path file for you OS guessed to /etc/mtab";
^~~
NSWorkspace.m: In function '-[NSWorkspace
getFileSystemInfoForPath:isRemovable:isWritable:isUnmountable:description:type:]':
NSWorkspace.m:1252:17: warning: implicit declaration of function 'setmntent';
did you mean 'getmntinfo'? [-Wimplicit-function-declaration]
   FILE  *fptr = setmntent(MOUNTED_PATH, "r");
 ^
 getmntinfo
NSWorkspace.m:1252:27: error: 'MOUNTED_PATH' undeclared (first use in this
function); did you mean 'AUDIT_PATH'?
   FILE  *fptr = setmntent(MOUNTED_PATH, "r");
   ^~~~
   AUDIT_PATH
NSWorkspace.m:1252:27: note: each undeclared identifier is reported only once
for each function it appears in
NSWorkspace.m:1255:16: warning: implicit declaration of function 'getmntent';
did you mean 'getmntinfo'? [-Wimplicit-function-declaration]
   while ((me = getmntent(fptr)) != 0)
^
getmntinfo
NSWorkspace.m:1255:14: warning: assignment to 'struct mntent *' from 'int'
makes pointer from integer without a cast [-Wint-conversion]
   while ((me = getmntent(fptr)) != 0)
  ^
In file included from /usr/include/string.h:634,
 from /usr/include/x86_64-kfreebsd-gnu/sys/mount.h:38,
 from NSWorkspace.m:39:
NSWorkspace.m:1257:18: error: dereferencing pointer to incomplete type 'struct
mntent'
 if (strcmp(me->MNT_MEMB, [fullPath fileSystemRepresentation]) == 0)
  ^~
NSWorkspace.m:1262:3: warning: implicit declaration of function 'endmntent'
[-Wimplicit-function-declaration]
   endmntent(fptr);
   ^
/usr/share/GNUstep/Makefiles/rules.make:479: recipe for target
'obj/libgnustep-gui.obj/NSWorkspace.m.o' failed


GNU/kFreeBSD provides both getmntinfo and getmntent but the conditionals
assume it's either one of them (as is the case on GNU/Linux where getmntinfo
is missing).

Please consider applying the attached obvious patch which has been tested on
Debian's GNU/kFreeBSD autobuilders.  (I believe you can do it with "git am".)



___

File Attachments:


---
Date: Sun 20 Jan 2019 06:57:10 PM EET  Name:
0001-Fix-build-failure-on-GNU-kFreeBSD.patch  Size: 1KiB   By: yavor



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

Re: linking fails / icon broken in window maker / gorm

[Yavor Doganov]

В Sun, 16 Sep 2018 16:26:57 +0200, Gürkan Myczko написа:

> When I try to build ModPlugPlay.app (to link it against
> libopenmpt-modplug-dev+libao-dev instead libmodplug-dev),
> I'm getting linking errors like:

Check your makefile:  ADDITIONAL_LDFLAGS should be ADDITIONAL_GUI_LIBS or 
ModPlugPlay_GUI_LIBS.

I'm not familiar with the details but I wonder why would you want to link 
with a library that provides a compatibility layer around another library 
instead of the real library itself?


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #54496] gui: NSBitmapImageRep does not support BMP

[Yavor Doganov]

Follow-up Comment #1, bug #54496 (project gnustep):

BMP is supported through ImageMagick, if the library was configured with
--enable-imagemagick.  On my system, NSImage +imageFileTypes returns 242 types
(including 3 variants of the BMP format).

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #54307] Wrong margins especially when printing one page

[Yavor Doganov]

Follow-up Comment #6, bug #54307 (project gnustep):

I also tested printing multiple pages, there is no change in the behavior with
Ink and TextEdit.  I don't know how to do that with Graphos, though...

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #54307] Wrong margins especially when printing one page

[Yavor Doganov]

Follow-up Comment #4, bug #54307 (project gnustep):

The last part of the test was removed by Eric Wasylishen on 23 December 2011
(commit d374f0a) precisely because of this problem.  However, he reverted it
one hour later (commit 2f0f50c) with a comment that it broke Graphos
printing.

I have a CUPS server with two different printers configured.  I can confirm
that with this change printing a single page works correctly for me with Ink,
TextEdit and Graphos.  I don't know what Graphos breakage he had in mind back
then, perhaps he will remember?  Or we can ask Riccardo to test as he is
undoubtedly more familiar with Graphos.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #54307] Wrong margins especially when printing one page

[Yavor Doganov]

Follow-up Comment #2, bug #54307 (project gnustep):

I thought the margins are always symmetrical, but anyway, your approach is
clearly better.

You are right that the NSPrintOperation change is just a dirty workaround and
apparently I haven't considered all subsequences.  I hope some solution can be
found.  Thanks for looking into this.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #54307] Wrong margins especially when printing one page

[Yavor Doganov]

URL:
  

 Summary: Wrong margins especially when printing one page
 Project: GNUstep
Submitted by: yavor
Submitted on: Fri 13 Jul 2018 06:45:26 PM EEST
Category: Gui/AppKit
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Reported initially by Patrick Cardona in these threads:
http://lists.gnu.org/archive/html/discuss-gnustep/2018-07/msg3.html
http://lists.gnu.org/archive/html/discuss-gnustep/2018-07/msg5.html

There are several unrelated issues:

1. Some PPD files contain (valid) lines like the following:

*PrintQuality Draft/Draft:

This results in exception when parsing (example file at
http://lists.gnu.org/archive/html/discuss-gnustep/2018-07/msg00017.html).

2. In NSPageLayout -tableView:objectValueForTableColumn:row: the margins for
the standard papers are not correctly computed.  imageRect already has the
printable margins but that is not taken into account so an expression like
paperSize.height - imageRect.size.height makes the topMargin twice larger than
it should be.  Likewise for rightMargin.  Also, the result is actually in pts
which gives funny figures; it should be converted to cm/in.

3. In NSPrintInfo -initWithDictionary: the margins should be set according to
ImageableArea as the FIXME comment says.

4. When a page with short text (few lines) has to be printed, the text does
not appear at the top of the page, as is expected, but is shifted way down
below.  That's the most annoying item.  There are some changes by Greg in the
"printing_fixes" branch which I think are related.  I haven't tested them but
IMHO his approach is wrong and breaks printing of multiple pages (which
appears to be working correctly right now).

The attached patch fixes all 4 issues for me although I admit I'm not sure
whether it is correct.  The whole repagination logic seems way too
awkward/convoluted to me and breaks reasonable WYSIWYG expectations.



___

File Attachments:


---
Date: Fri 13 Jul 2018 06:45:26 PM EEST  Name:
0001-Miscellaneous-printing-fixes.patch  Size: 4KiB   By: yavor



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #53941] NSProcessInfo -systemUptime test sometimes fails on GNU/Hurd

[Yavor Doganov]

Follow-up Comment #2, bug #53941 (project gnustep):

Thanks, works for me.  Sorry for missing Windows, I just wasn't careful
enough.

I see nothing wrong in making tests conditional based on defines; running the
testsuite assumes a configured tree.  Besides, that is already done for some
tests that rely on ICU or libxml being available.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #53941] NSProcessInfo -systemUptime test sometimes fails on GNU/Hurd

[Yavor Doganov]

URL:
  

 Summary: NSProcessInfo -systemUptime test sometimes fails on
GNU/Hurd
 Project: GNUstep
Submitted by: yavor
Submitted on: Sat 19 May 2018 12:55:21 PM EEST
Category: Base/Foundation
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

On GNU/Hurd, procfs is optional -- the system works just as well without it. 
Debian's hurd-i386 buildds are configured with procfs but for some reason from
time to time the test (as well as the configure test for procfs) fails.  See
https://lists.debian.org/debian-hurd/2018/02/msg00017.html for details.

As this method is a no-op if neither procfs nor sysctlbyname are available I'd
suggest to not compile/run the test if these conditions are not met.  Patch
attached.



___

File Attachments:


---
Date: Sat 19 May 2018 12:55:21 PM EEST  Name:
conditional-systemUptime-test.patch  Size: 1KiB   By: yavor



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #53035] NSNumberFormatter test failure with ICU 60.2

[Yavor Doganov]

Follow-up Comment #2, bug #53035 (project gnustep):

Unfortunately the fix is incorrect.

The test failed on all of Debian's big-endian architectures (except m68k and
powerpcspe which are configured globally to skip tests for performance
reasons).  Sorry for not spotting that earlier; patch attached.

(file #44167)
___

Additional Item Attachment:

File name: 53035.patchSize:1 KB


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #52518] [GWorkspace] Unnecessarily complex build system

[Yavor Doganov]

Follow-up Comment #8, bug #52518 (project gnustep):

I didn't observe any problems on the platforms I have access to.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #53223] [xlib] font_cacher should not be built if WITH_XFT=yes

[Yavor Doganov]

URL:
  

 Summary: [xlib] font_cacher should not be built if
WITH_XFT=yes
 Project: GNUstep
Submitted by: yavor
Submitted on: Sun 25 Feb 2018 01:09:53 PM EET
Category: Backend
Severity: 3 - Normal
  Item Group: Change Request
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

I am sorry to report another xlib-related bug.  What "inspired" my interest in
xlib is this bug report:

https://bugs.debian.org/885786

When I first looked at the xlib directory I didn't realize there were two
different variants and that font_cacher is completely unused by the "modern"
flavor.  The attached patch fixes this and also adds a manpage which I had to
write for Debian (feel free to discard it).

Ideally, we would like to follow strictly upstream's preference and not
package art and xlib.  But this would require packaging opal which is
currently not possible.

Ever since cairo was made the default backend we made special effort to
enforce it for new installations.  That was a difficult thing to do because
"art" sorts before "cairo" so we had to find a different approach.  It seems
to be working; according to popcon there are 1109 machines with the cairo
package installed and only 5 with art:

https://qa.debian.org/popcon.php?package=gnustep-back

Of these 5 machines that have art installed, 3 are mine (permanently connected
and with the popularity-contest package installed).

I couldn't find any information in the README/NEWS files or the official
GNUstep website that art and xlib are deprecated.  It seems to be common
knowledge among regular GNUstep users but I think it's reasonable to expect
that new users are unaware of this.
The second part of the patch adds a deprecation warning which is printed at
the end of the configure run.  Hopefully this will decrease the usage of the
deprecated backends even further.



___

File Attachments:


---
Date: Sun 25 Feb 2018 01:09:53 PM EET  Name:
0001-Add-font_cacher-manpage-install-font_cacher-conditio.patch  Size: 5KiB  
By: yavor



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #53216] [Opal] Please switch to lcms2

[Yavor Doganov]

URL:
  

 Summary: [Opal] Please switch to lcms2
 Project: GNUstep
Submitted by: yavor
Submitted on: Sat 24 Feb 2018 09:10:38 AM EET
Category: Libraries
Severity: 3 - Normal
  Item Group: Change Request
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Version 2 was released in 2010, most projects migrated in 2011/12.  Most major
distros removed the old version in 2013, some in 2014.

The attached patch does this, hopefully done right.  It's possible to support
both versions but I'm not sure if it's really worth it.

I was finally able to test the opal backend and found out it has several
problems.  Thought I introduced them with my patch but they persist if I build
the master branch with a manually built/installed lcms1 (version 1.19).



___

File Attachments:


---
Date: Sat 24 Feb 2018 09:10:38 AM EET  Name: 0001-Switch-to-lcms2.patch  Size:
11KiB   By: yavor



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

Re: gnustep base test failure

[Yavor Doganov]

В Thu, 15 Feb 2018 08:46:40 +, Richard Frith-Macdonald написа:

> I have changed the testcase in git to use a fixed negative currency
> format, rather than the one ICU supplies for the pt_BR locale, in
> order to avoid that variability.

Now it fails for me with ICU 57.1 (str is _R$1.235) and 60.2 (str is
_R$1.235, see Bug#53035).


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #26535] user created NSImage not displaying properly

[Yavor Doganov]

Follow-up Comment #5, bug #26535 (project gnustep):

Yes, I think this makes sense.  My initial version was to check if the current
thread is the main thread but that's useless.  Any drawing in secondary
threads occurs after +sharedApplication which sets up the server in the main
thread.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #26535] user created NSImage not displaying properly

[Yavor Doganov]

Follow-up Comment #3, bug #26535 (project gnustep):

I stumbled upon the second issue.  Lynkeos does all of its image processing in
worker threads so basically it doesn't work at all on GNUstep.  I was about to
write a similar test application but fortunately I found this bug.

With the attached *surprisingly* trivial patches drawing in secondary threads
works at least with the cairo backend.  Art and xlib display black rectangles
in Scott's test app but that's a general problem because the same happens with
the non-threaded variants (only file image is displayed).  I haven't tested
the opal backend as I can't build the opal library.

Lynkeos works only with cairo.  There is some flickering when the processed
image is being refreshed.  With art/xlib I get a weird glibc SIGABRT when it
is loading the main XIB file and instantiating objects.

I haven't done the equivalent for the woe32 server as I'm not familiar with
the code and can't test it anyway.

I am not sure at all if this is the right approach and what is the performance
penalty.  There should be some because XInitThreads enables the X locking
mechanism and it must be called unconditionally.

I hope this is one small step forward, though.

(file #43212, file #43213)
___

Additional Item Attachment:

File name: gui.patch  Size:0 KB
File name: back.patch Size:0 KB


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #53080] NSPortMessage msgid is ignored when sending the message

[Yavor Doganov]

URL:
  

 Summary: NSPortMessage msgid is ignored when sending the
message
 Project: GNUstep
Submitted by: yavor
Submitted on: Wed 07 Feb 2018 12:44:50 AM EET
Category: Base/Foundation
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

While porting Lynkeos I noticed that the value of the NSPortMessage _msgid
ivar is ignored when the message is being sent.  The current Base behavior is
raising an exception in Lynkeos because its -handlePortMessage: implementation
expects messages to have certain msgids while all messages are sent with msgid
0, despite the fact that -setMsgid: is sent on the newly created instances to
set a different msgid.

The attached trivial patch fixes it for me.  (BTW, this ivar is declared as
unsigned while the NSPort method expects NSInteger.)



___

File Attachments:


---
Date: Wed 07 Feb 2018 12:44:50 AM EET  Name: msgid.patch  Size: 1KiB   By:
yavor



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #53060] [xlib] Significant slowness with some apps, font-related

[Yavor Doganov]

Follow-up Comment #4, bug #53060 (project gnustep):

I found my mistake -- lineHeight was not set.  Not sure if the patch is
correct but it appears to work.  PikoPixel is still slowish but it's bearable,
nothing compared to the previous slowness.  Other problematic apps display
reasonably fast (as fast as the backend is capable, I guess).

Please discard my previous patches, this one applies directly to git master. 
I'm happy to make any corrections provided that you give me some directions
and I actually understand them.

(file #43175)
___

Additional Item Attachment:

File name: 0001-xlib-Simplify-code-by-deriving-GSXft-from-FC-classes.patch
Size:18 KB


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #53060] [xlib] Significant slowness with some apps, font-related

[Yavor Doganov]

Follow-up Comment #2, bug #53060 (project gnustep):

Normally I woldn't want to touch xlib with a barge pole.  But Debian is likely
to be removing libart in the very near future so we would have to drop the art
backend.  We packaged xlib recently only because I want to have at least two
backends, it's useful for testing purposes.  I would like to package opal but
there are issues with missing libraries (lcms) and the GNUstep opal library
clashing with the VoIP opal library that is used by ekiga.  Both art and xlib
are clearly marked as deprecated in the package descriptions and the
README.Debian file.  

My first approach to this problem was to make GSXftFontInfo inherit from
FCFontInfo (and likewise, GSXftFontEnumerator from FCFontEnumerator,
overriding +faceInfoClass and +fontWithName:).  I probably made some grave
mistake(s) because I get:

can't find text container for glyph (internal error)

from NSLayoutManager.  If you want I can tidy up that patch and can attach it
for you to take a look.  It could spare you some time if my mistake is not
fundamental and there's something little yet essential that I'm missing.

By the way, fontconfig has been a hard dependency for Xft since time
immemoriam so the HAVE_FC branch in the code doesn't make sense to me.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #53060] [xlib] Significant slowness with some apps, font-related

[Yavor Doganov]

URL:
  

 Summary: [xlib] Significant slowness with some apps,
font-related
 Project: GNUstep
Submitted by: yavor
Submitted on: Sun 04 Feb 2018 02:06:04 AM EET
Category: Backend
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

The xlib backend is nearly unusable with some apps.  On my main workstation
(not powerful but with many fonts installed) it takes about a minute for
SimpleAgenda to appear and become responsive.  Then if I click on another tab,
I have to wait ~15 seconds; the UI is blocked until then.

The log shows some of these:

2018-02-04 01:00:14.278 SimpleAgenda[24146:24146] attempt to initialize
character set with invalid bitmap

Putting a break on NSCharacterSet.m:206 reveals:


Breakpoint 1, -[NSBitmapCharSet initWithBitmap:] (self=0x574a8340, 
_cmd=, bitmap=0x574140c0) at NSCharacterSet.m:206
206   NSLog(@"attempt to initialize character set with invalid bitmap");
(gdb) p length
$1 = 1114112
(gdb) bt 2
#0  0x76848a78 in -[NSBitmapCharSet initWithBitmap:]
(self=0x574a8340, _cmd=, bitmap=0x574140c0) at
NSCharacterSet.m:206
#1  0x768463fc in +[NSCharacterSet
characterSetWithBitmapRepresentation:] (self=, _cmd=, data=0x574140c0)
at NSCharacterSet.m:800
#2  0x7fffeb20d919 in -[GSXftFontInfo coveredCharacterSet]
(self=0x55f376f0, _cmd=) at GSXftFontInfo.m:368


The first patch addresses this but the slowness remains.  With
--GNU-Debug=NSFont, there is intensive output after the loop in
-enumerateFontsAndFamilies.  There are an awful lot of repetitions of the
debug output in -setupAttributes, for the same fonts over and over:

+verabtim+
2018-02-04 01:28:29.778 SimpleAgenda[24287:24287] Loaded font: Samyak Tamil
2018-02-04 01:28:29.805 SimpleAgenda[24287:24287] Loaded font: Noto Sans
Telugu UI
2018-02-04 01:28:29.826 SimpleAgenda[24287:24287] Loaded font: URW Gothic L
2018-02-04 01:28:29.858 SimpleAgenda[24287:24287] Loaded font: TeX Gyre
Cursor
2018-02-04 01:28:29.886 SimpleAgenda[24287:24287] Loaded font: Noto Sans
Malayalam-Bold
2018-02-04 01:28:29.912 SimpleAgenda[24287:24287] Loaded font: STIXGeneral
2018-02-04 01:28:29.948 SimpleAgenda[24287:24287] Loaded font: AnjaliOldLipi
2018-02-04 01:28:29.964 SimpleAgenda[24287:24287] Loaded font: Dingbats
2018-02-04 01:28:29.995 SimpleAgenda[24287:24287] Loaded font: Noto Sans
Oriya-Bold
2018-02-04 01:28:30.023 SimpleAgenda[24287:24287] Loaded font: Chilanka
2018-02-04 01:28:30.049 SimpleAgenda[24287:24287] Loaded font:
LucidaTypewriter
2018-02-04 01:28:30.091 SimpleAgenda[24287:24287] Loaded font: ori1Uni
2018-02-04 01:28:30.120 SimpleAgenda[24287:24287] Loaded font: URW Gothic
L-Demibold
2018-02-04 01:28:30.156 SimpleAgenda[24287:24287] Loaded font: Free
Courier-BoldOblique
2018-02-04 01:28:30.196 SimpleAgenda[24287:24287] Loaded font: FreeSerif-Bold
2018-02-04 01:28:30.227 SimpleAgenda[24287:24287] Loaded font: TeX Gyre Termes
Math
2018-02-04 01:28:30.247 SimpleAgenda[24287:24287] Loaded font: TeX Gyre
Cursor-BoldItalic
2018-02-04 01:28:30.272 SimpleAgenda[24287:24287] Loaded font: Samyak
Gujarati
2018-02-04 01:28:30.297 SimpleAgenda[24287:24287] Loaded font: Noto Sans
Georgian-Bold
2018-02-04 01:28:30.325 SimpleAgenda[24287:24287] Loaded font: Terminal-Bold


The above is just a small snippet from the output.  I have to kill the app
with kill(all) from another terminal.  CPU usage is intensive, and HDD too if
debug output is enabled.  This is reproducible with some apps like
SimpleAgenda, LuserNET, PikoPixel, Preview, Cenon (to an extent), Grr (when
you click on a feed) and especially Charmap.  I cannot reproduce with AClock,
Timemon, Gorm, PRICE, FTP, Ink or SystemPreferences.

The second patch introduces glyph caching in a very similar way as it is done
for the other backends.  I thought initially that this was the culprit but I
was completely wrong.  As I've made it anyway and it is some improvement, I
thought it wouldn't hurt to share it although it doesn't solve the problem.

This bug is reproducible with GUI/Back 0.25.0 as well.  I tried to track down
the issue but there are so many hoops through GSLayoutManager/NSGlyphGenerator
that I got utterly confused at the end, especially when I tried to compare the
behavior with the other backends.  Perhaps a proper programmer would spot and
solve the bug easily.



___

File Attachments:


---
Date: Sun 04 Feb 2018 02:06:04 AM EET  Name:
0001-xlib-Protect-against-invalid-characters-in-coveredCh.patch  Size: 1KiB  
By: yavor

[bug #53035] NSNumberFormatter test failure with ICU 60.2

[Yavor Doganov]

URL:
  

 Summary: NSNumberFormatter test failure with ICU 60.2
 Project: GNUstep
Submitted by: yavor
Submitted on: Thu 01 Feb 2018 04:35:01 PM EET
Category: Base/Foundation
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Originally reported here: https://bugs.debian.org/888908

Failed test: basic10_4.m:166 ... negativeFormat used for -ve number

With ICU 60.2, str is "_R$1.235".  I don't know how this non-breaking
space sneaks in or whether it is supposed to be there.  Ubuntu are setting
testHopeful to cope with the failure, the attached patch extends the
expression.



___

File Attachments:


---
Date: Thu 01 Feb 2018 04:35:01 PM EET  Name:
0001-Fix-test-failure-with-ICU-60.2.patch  Size: 2KiB   By: yavor



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #52730] [GWorkspace] Misc compiler warnings

[Yavor Doganov]

Follow-up Comment #2, bug #52730 (project gnustep):

The warnings occur with GUI 0.25.0, just rechecked with 0.26.2 and they are
the same.  Perhaps you test with Clang and that's why you don't get them?

There is no class NSPopUpMenu so I don't think it's bogus or a false positive.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #52494] Does not handle exceptions when loading translations

[Yavor Doganov]

Follow-up Comment #3, bug #52494 (project gnustep):

The applied fix is basically my proposed patch, with one minor nuance.  I have
already tested it.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #52941] Please detect freetype with pkg-config

[Yavor Doganov]

Follow-up Comment #2, bug #52941 (project gnustep):

Thanks.  FYI, the runstatedir stuff comes from Debian's autoconf package which
has the runstatedir patch from autoconf.git upstream (it's going to be in
autoconf 2.70).

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #52942] [xlib] Build failure with LDFLAGS=-Wl,--no-undefined

[Yavor Doganov]

URL:
  

 Summary: [xlib] Build failure with LDFLAGS=-Wl,--no-undefined
 Project: GNUstep
Submitted by: yavor
Submitted on: Sun 21 Jan 2018 10:51:34 AM EET
Category: Backend
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

The xlib backend uses freetype functions so it has to link with it:


 Linking bundle libgnustep-back-026 ...
./xlib/obj/subproject.o: In function
`_i_GSXftFontInfo__appendBezierPathWithGlyphs_count_toBezierPath_':
/home/yavor/src/gnustep/libs-back/Source/xlib/GSXftFontInfo.m:695: undefined
reference to `FT_Load_Glyph'
/home/yavor/src/gnustep/libs-back/Source/xlib/GSXftFontInfo.m:698: undefined
reference to `FT_Get_Glyph'
/home/yavor/src/gnustep/libs-back/Source/xlib/GSXftFontInfo.m:701: undefined
reference to `FT_Glyph_Transform'
/home/yavor/src/gnustep/libs-back/Source/xlib/GSXftFontInfo.m:712: undefined
reference to `FT_Outline_Decompose'
/home/yavor/src/gnustep/libs-back/Source/xlib/GSXftFontInfo.m:714: undefined
reference to `FT_Done_Glyph'
collect2: error: ld returned 1 exit status


Straightforward patch attached.



___

File Attachments:


---
Date: Sun 21 Jan 2018 10:51:34 AM EET  Name:
0001-Add-FREETYPE_LIBS-to-LIBS-when-building-xlib.patch  Size: 2KiB   By:
yavor



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #52941] Please detect freetype with pkg-config

[Yavor Doganov]

URL:
  

 Summary: Please detect freetype with pkg-config
 Project: GNUstep
Submitted by: yavor
Submitted on: Sat 20 Jan 2018 08:32:31 PM EET
Category: Backend
Severity: 3 - Normal
  Item Group: Change Request
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Debian will remove the freetype-config script from the libfreetype6-dev
package as it doesn't support multiarch properly and its output is incorrect
on foreign architectures.  I'm not sure if this change will remain
Debian-specific or is going to be merged by freetype upstream at some point.

The attached patch uses PKG_CHECK_MODULES to obtain freetype's CFLAGS/LIBS
which is basically equivalent.



___

File Attachments:


---
Date: Sat 20 Jan 2018 08:32:31 PM EET  Name:
0001-Detect-freetype-with-PKG_CHECK_MODULES.patch  Size: 7KiB   By: yavor



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #52879] 1.25.1 testsuite failures

[Yavor Doganov]

Follow-up Comment #2, bug #52879 (project gnustep):

Thanks.
BTW, the build failure on AIX is not a GCC bug and not an AIX-specific issue. 
The struct declaration has been moved to objc-private/module-abi-8.h, hence
the error.  The dynamic linker on this system lacks dladdr so LINKER_GETSYMBOL
is correctly undefined.

I guess the code should be updated to the current runtime but it seems there
are no accessor functions...  You might want to look at that as Base will not
compile on any system with incapable dynamic linker.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #52879] 1.25.1 testsuite failures

[Yavor Doganov]

URL:
  

 Summary: 1.25.1 testsuite failures
 Project: GNUstep
Submitted by: yavor
Submitted on: Sun 14 Jan 2018 12:49:41 AM EET
Category: Base/Foundation
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

GCC 7.2.0 was used on all platforms unless otherwise specified.  Here's the
summary:

Debian 5.0.7 lenny amd64 (x86_64)   FAIL
Debian 6.0.10 squeeze amd64 (x86_64)FAIL
Debian 7.10 wheezy mips64 (GCC 4.6.3)   build fails
Debian 7.11 wheezy amd64 (x86_64)   build fails
Debian 8.9 jessie i386 (x86)PASS
Debian 8.9 jessie mips64el (GCC 4.9.2)  PASS
Debian 8.10 jessie amd64 (x86_64)   PASS
Debian 9.2 stretch arm64 (aarch64)  FAIL
Debian 9.3 stretch amd64 (x86_64) (GCC 6.3.0)   PASS
Debian 9.3 stretch i386 (x86) (GCC 6.3.0)   PASS
Debian buster/sid amd64 (x86_64)PASS
Debian buster/sid i386 (x86)PASS
Debian buster/sid sparc64   FAIL

Ubuntu 14.04 trusty arm64 (aarch64) PASS
Ubuntu 16.04 xenial amd64 (x86_64)  FAIL

CentOS 7.4.1708 AltArch ppc64   PASS
CentOS 7.4.1708 AltArch ppc64le FAIL

openSUSE Leap 42.1 aarch64  FAIL

NetBSD 5.1 amd64 (x86_64) (GCC 4.8.5)   configure fails

AIX 7.1 chrp (POWER7) (GCC 6.4.0)   build fails
AIX 7.2 chrp (POWER8)   build fails

The file tests.log contains the failed tests sorted by machines; all passed
tests and duplicated failures are stripped to improve readability.  The first
patch fixes obvious testsuite failures, you might want to tweak/improve the
SKIP message(s).  The second one is a quick/easy fix for the build failure on
Debian wheezy.  Ideally, a better solution should be applied, see my comment
at tests.log.  I made separate commits because the two patches/issues are
unrelated.



___

File Attachments:


---
Date: Sun 14 Jan 2018 12:49:41 AM EET  Name: tests.log  Size: 13KiB   By:
yavor


---
Date: Sun 14 Jan 2018 12:49:41 AM EET  Name:
0001-Fix-testsuite-failures-with-disable-xml-and-disable-.patch  Size: 14KiB  
By: yavor


---
Date: Sun 14 Jan 2018 12:49:41 AM EET  Name:
0002-Require-ICU-50-for-UDAT_PATTERN.patch  Size: 7KiB   By: yavor



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #52518] [GWorkspace] Unnecessarily complex build system

[Yavor Doganov]

Follow-up Comment #6, bug #52518 (project gnustep):

What makes the patch large is the gazillion configure scripts.  If you filter
them out it should be fairly easy to review.  There are also many duplicated
configure checks and even macro definitions that the patch cumulates at one
place.  I can split it in 56 chunks if you want, but it'll certainly take much
more time to review and test them one by one.

You can also test it on all other platforms you have access to, it just takes
time.  If anything is broken I'm confident I can fix it quickly.

GNUstep Make doesn't support out of tree builds only if you follow the usual
practice for writing GNUstep makefiles.  But if you use autoconf to generate
them and the vpath GNU make directive you get VPATH builds out of the box and
without too much effort.  It's a matter of good practice to #include
 but it's entirely up to you whether to follow it.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #52729] [GWorkspace] incompatible-pointer-types compiler warnings

[Yavor Doganov]

Follow-up Comment #3, bug #52729 (project gnustep):

Thanks.  The casts are (and were) unnecessary.  I hesitated to remove them
because I saw id* was used and wondered why.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #52793] autoreconf fails

[Yavor Doganov]

URL:
  

 Summary: autoreconf fails
 Project: GNUstep
Submitted by: yavor
Submitted on: Wed 03 Jan 2018 02:11:55 PM EET
Category: Backend
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

This is similar to Bug#52779 but not identical, so I'm reporting it as a
separate bug.


$ autoreconf -fi
configure.ac:275: error: possibly undefined macro: PKG_XFT
  If this token and others are legitimate, please use m4_pattern_allow.
  See the Autoconf documentation.
configure.ac:455: error: possibly undefined macro: PKG_CAIRO
configure.ac:457: error: possibly undefined macro: PKG_CAIRO_FT
configure.ac:459: error: possibly undefined macro: PKG_CAIRO_XLIB
configure.ac:463: error: possibly undefined macro: PKG_CAIRO_GLITZ
configure.ac:465: error: possibly undefined macro: PKG_FONTCONFIG
autoreconf: /usr/bin/autoconf failed with exit status: 1
$ cp ../libs-gui/config/pkg.m4 .
$ rm aclocal.m4
$ autoreconf -fi
configure.ac:275: error: possibly undefined macro: PKG_XFT
  If this token and others are legitimate, please use m4_pattern_allow.
  See the Autoconf documentation.
configure.ac:455: error: possibly undefined macro: PKG_CAIRO
configure.ac:457: error: possibly undefined macro: PKG_CAIRO_FT
configure.ac:459: error: possibly undefined macro: PKG_CAIRO_XLIB
configure.ac:463: error: possibly undefined macro: PKG_CAIRO_GLITZ
configure.ac:465: error: possibly undefined macro: PKG_FONTCONFIG
autoreconf: /usr/bin/autoconf failed with exit status: 1


This is because newer pkg.m4 macros now use m4_pattern_forbid to reserve their
own namespace.  Proposed patch attached.

P.S. PKG_PROG_PKG_CONFIG is AC_REQUIREd by PKG_CHECK_MODULES and generally
shouldn't be necessary to be called explicitly.  However, the first call to
PKG_CHECK_MODULES (for xext) is conditional and that's why the macro is not
expanded and later it fails to detect cairo.  If you use AS_IF instead of
plain "if" autoconf would be able to "see" that and the AC_REQUIRE machinery
would work.  So, either an explicit call to PKG_PROG_PKG_CONFIG is neeeded, or
rewrite the if statement as

AS_IF([test "$HAVE_LIBXext" = no], [PKG_CHECK_MODULES([XEXT], [xext])])



___

File Attachments:


---
Date: Wed 03 Jan 2018 02:11:55 PM EET  Name: 0001-Fix-autoreconf-failure.patch
 Size: 101KiB   By: yavor



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #52518] [GWorkspace] Unnecessarily complex build system

[Yavor Doganov]

Follow-up Comment #4, bug #52518 (project gnustep):

(1) FND_LIBS (and GUI_LIBS) is recommended by the GNUstep Make manual instead
of hardcoding -base/-gui as these variables are defined to the appropriate
value on Apple and non-Apple systems.

(2) -L flags belong to LIBS and not LDFLAGS.  On some systems (proprietary
Unix flavors, I guess), the library will not be found if it's in a
non-standard directory and -L  does not appear immediately before -llib. 
GNUmakefile.preamble must be deleted as it is a generated file, I'm sorry to
have missed that.

(3) The Autoconf manual recommends to use  with the proper -I
option, and that it should be included before any other system headers. 
Nearly all GNU packages do this, it is perfectly safe.  The rationale behind
this recommendation is for predictable results in out-of-tree builds: If you
#include "config.h", the preprocessor will search first the directory where
the source file is located, IOW srcdir.  If there's a stale config.h there, it
will be used instead of the freshly generated config.h (config.status always
writes output files in builddir).

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #52780] Spelling error in make_services.1

[Yavor Doganov]

URL:
  

 Summary: Spelling error in make_services.1
 Project: GNUstep
Submitted by: yavor
Submitted on: Mon 01 Jan 2018 10:38:42 PM EET
Category: Gui/AppKit
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Patch attached.



___

File Attachments:


---
Date: Mon 01 Jan 2018 10:38:42 PM EET  Name:
0001-Fix-trivial-typo-in-make_services.1-manpage.patch  Size: 1KiB   By: yavor



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #52779] autoreconf generates broken configure

[Yavor Doganov]

Follow-up Comment #1, bug #52779 (project gnustep):

Typo in submission:

/usr/share/acloclal.m4 -> /usr/share/aclocal/pkg.m4

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #52779] autoreconf generates broken configure

[Yavor Doganov]

URL:
  

 Summary: autoreconf generates broken configure
 Project: GNUstep
Submitted by: yavor
Submitted on: Mon 01 Jan 2018 10:04:22 PM EET
Category: Gui/AppKit
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

To reproduce, run

$ autoreconf
$ ./configure

Observe the error messages; all of them are due to the completely broken
configure script.  (Naturally, compilation also fails.)  This happens because
autoreconf invokes aclocal, which in turn detects that pkg.m4 from ACDIR
(/usr/share/aclocal in my case) is newer than config/pkg.m4, so it creates
aclocal.m4, copying the macro definition from /usr/share/aclocal.m4.  Autoconf
then makes a mess since config/pkg.m4 is included via the m4 builtin macro and
on top of that is underquoted.

Attached is a non-intrusive patch which simply updates config/pkg.m4.  A
better approach which would be to use the standard/recommended way of dealing
with additional macros:

AC_CONFIG_MACRO_DIR([config])

That way, when you regenerate configure with `autoreconf -i', the macros under
config/ will be updated if a newer version of the .m4 file is available by the
package that is providing it (pkg-config for pkg.m4 and autoconf-archive for
icu.m4).

I suspect that the current approach was preferred in order to avoid aclocal
(as it is part of GNU Automake).  I think it is reasonable to expect that any
user or developer who has to modify configure.ac has automake installed. 
Also, autoreconf is the recommended way of (re)generating the GNU build system
and most users are accustomed to it.



___

File Attachments:


---
Date: Mon 01 Jan 2018 10:04:22 PM EET  Name:
0001-Update-pkg.m4-to-serial-11.patch  Size: 13KiB   By: yavor



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #52778] pkg-config usage broken in cross-compilation mode

[Yavor Doganov]

URL:
  

 Summary: pkg-config usage broken in cross-compilation mode
 Project: GNUstep
Submitted by: yavor
Submitted on: Mon 01 Jan 2018 02:52:10 PM EET
Category: Base/Foundation
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

The use of AC_PATH_PROG to locate pkg-config and then invocation of pkg-config
is broken in cross-compilation mode as it cannot find the .pc files.  For
details, please see https://bugs.debian.org/884798.

Patch attached.





___

File Attachments:


---
Date: Mon 01 Jan 2018 02:52:10 PM EET  Name:
0001-Use-PKG_PROG_PKG_CONFIG-macro-to-locate-pkg-config.patch  Size: 13KiB  
By: yavor



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #42778] Frameworks with different SONAME cannot coexist

[Yavor Doganov]

Follow-up Comment #5, bug #42778 (project gnustep):

Niels, this hunk (in comment #3) was completely intentional.  As it stands, if
a framework with a new interface version is installed, the Resources symlink
will be updated to point to the Current version.  This is wrong.  Different
versions may have different resources and this is 100% doomed to fail if some
of these resources are arch-dep, because an app still linking with the old
framework will attempt to load bundles that are linked against the new
framework.

I also thought it may break resource lookups, but it doesn't.  Let me
demonstrate:


$ ls -l /usr/lib/GNUstep/Frameworks/PopplerKit.framework/
общо 4
lrwxrwxrwx 1 root root   24 юни  5  2012 Headers ->
Versions/Current/Headers
lrwxrwxrwx 1 root root   33 дек  7 01:47 libPopplerKit.so ->
Versions/Current/libPopplerKit.so
lrwxrwxrwx 1 root root   27 дек  7 01:47 PopplerKit ->
Versions/Current/PopplerKit
drwxr-xr-x 3 root root 4096 май 19  2014 Versions


Notice the *absence* of the Resources symlink.  PopplerKit has fonts as
resources and this method in PopplerFontManager.m:


- (void) _addIncludedFonts
{
   int i;
   for (i = 0; IncludedFonts[i]; i++)
   {
  NSString* fontFile = [self _findIncludedFontFile: IncludedFonts[i]];
  if (fontFile)
  {
 [self addFontFile: fontFile];
 NSLog(@"added font %@", IncludedFonts[i]);
  }
  else
  {
 NSLog(@"WARNING: no font for %@", IncludedFonts[i]);
  }
   }
}


The fonts are available in the arch-indep location where the Resources symlink
under Versions/VER points to (as symlinks to the actual font files from the
gsfonts package in Debian, but this doesn't matter here):


$ ls -l /usr/lib/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0/
общо 204
lrwxrwxrwx 1 root root 78 юни  5  2012 Headers ->
../../../../../../include/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0
lrwxrwxrwx 1 root root 18 дек  7 01:47 libPopplerKit.so ->
libPopplerKit.so.0
lrwxrwxrwx 1 root root 22 дек  7 01:47 libPopplerKit.so.0 ->
libPopplerKit.so.0.0.1
-rw-r--r-- 1 root root 199880 дек  7 01:47 libPopplerKit.so.0.0.1
lrwxrwxrwx 1 root root 16 дек  7 01:47 PopplerKit -> libPopplerKit.so
lrwxrwxrwx 1 root root 76 юни  5  2012 Resources ->
../../../../../../share/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0

$ ls -l
/usr/lib/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0/Resources/
общо 4
lrwxrwxrwx 1 root root  47 дек  7 01:47 d05l.pfb ->
../../../../../fonts/type1/gsfonts/d05l.pfb
-rw-r--r-- 1 root root 495 дек  7 01:47 Info-gnustep.plist
lrwxrwxrwx 1 root root  47 дек  7 01:47 n019003l.pfb ->
../../../../../fonts/type1/gsfonts/n019003l.pfb
lrwxrwxrwx 1 root root  47 дек  7 01:47 n019004l.pfb ->
../../../../../fonts/type1/gsfonts/n019004l.pfb
lrwxrwxrwx 1 root root  47 дек  7 01:47 n019023l.pfb ->
../../../../../fonts/type1/gsfonts/n019023l.pfb
lrwxrwxrwx 1 root root  47 дек  7 01:47 n019024l.pfb ->
../../../../../fonts/type1/gsfonts/n019024l.pfb
lrwxrwxrwx 1 root root  47 дек  7 01:47 n021003l.pfb ->
../../../../../fonts/type1/gsfonts/n021003l.pfb
lrwxrwxrwx 1 root root  47 дек  7 01:47 n021004l.pfb ->
../../../../../fonts/type1/gsfonts/n021004l.pfb
lrwxrwxrwx 1 root root  47 дек  7 01:47 n021023l.pfb ->
../../../../../fonts/type1/gsfonts/n021023l.pfb
lrwxrwxrwx 1 root root  47 дек  7 01:47 n021024l.pfb ->
../../../../../fonts/type1/gsfonts/n021024l.pfb
lrwxrwxrwx 1 root root  47 дек  7 01:47 n022003l.pfb ->
../../../../../fonts/type1/gsfonts/n022003l.pfb
lrwxrwxrwx 1 root root  47 дек  7 01:47 n022004l.pfb ->
../../../../../fonts/type1/gsfonts/n022004l.pfb
lrwxrwxrwx 1 root root  47 дек  7 01:47 n022023l.pfb ->
../../../../../fonts/type1/gsfonts/n022023l.pfb
lrwxrwxrwx 1 root root  47 дек  7 01:47 n022024l.pfb ->
../../../../../fonts/type1/gsfonts/n022024l.pfb
lrwxrwxrwx 1 root root  47 дек  7 01:47 s05l.pfb ->
../../../../../fonts/type1/gsfonts/s05l.pfb


Relevant portion from the log:


$ ViewPDF /usr/share/GNUstep/Documentation/Gorm.pdf
...
2017-12-31 18:44:31.614 ViewPDF[3853:3853] added font n022003l.pfb
2017-12-31 18:44:31.617 ViewPDF[3853:3853] added font n022004l.pfb
2017-12-31 18:44:31.618 ViewPDF[3853:3853] added font n022024l.pfb
2017-12-31 18:44:31.618 ViewPDF[3853:3853] added font n022023l.pfb
2017-12-31 18:44:31.618 ViewPDF[3853:3853] added font n019003l.pfb
2017-12-31 18:44:31.618 ViewPDF[3853:3853] added font n019004l.pfb
2017-12-31 18:44:31.618 ViewPDF[3853:3853] added font n019024l.pfb
2017-12-31 18:44:31.619 ViewPDF[3853:3853] added font n019023l.pfb
2017-12-31 18:44:31.619 ViewPDF[3853:3853] added font s05l.pfb
2017-12-31 18:44:31.619 ViewPDF[3853:3853] added font n021004l.pfb
2017-12-31 18:44:31.619 ViewPDF[3853:3853] added font n021024l.pfb
2017-12-31 18:44:31.619 ViewPDF[3853:3853] added font n021023l.pfb
2017-12-31 18:44:31.619 ViewPDF[3853:3853] added font n021003l.pfb
2017-12-31 18:44:31.620 ViewPDF[3853:3853] added font d05l.pfb
using 

[bug #52731] [GWorkspace] Build failure on GNU/Hurd

[Yavor Doganov]

URL:
  

 Summary: [GWorkspace] Build failure on GNU/Hurd
 Project: GNUstep
Submitted by: yavor
Submitted on: Fri 22 Dec 2017 11:22:50 PM EET
Category: Application
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Attached is a patch initally submitted by Svante Signell
 at https://bugs.debian.org/767847.  I'm uncertain
what's best to do in case of malloc failure so I haven't added a check at all.



___

File Attachments:


---
Date: Fri 22 Dec 2017 11:22:50 PM EET  Name:
0001-Fix-build-failure-on-GNU-Hurd.patch  Size: 3KiB   By: yavor



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #52730] [GWorkspace] Misc compiler warnings

[Yavor Doganov]

URL:
  

 Summary: [GWorkspace] Misc compiler warnings
 Project: GNUstep
Submitted by: yavor
Submitted on: Fri 22 Dec 2017 10:50:53 PM EET
Category: Application
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

The attached patch fixes these compiler warnings:
 - @interface of class ‘NSPopUpMenu’ not found
 - ‘NSCollectionViewItem’ may not respond to ‘-setTag:’
 - logical not is only applied to the left hand side of comparison
 - initialization from distinct Objective-C type
 - variable ‘is_daemon’ set but not used
 - comparison between pointer and zero character constant

About is_daemon in mdextractor.m, perhaps it wasn't intended to be a local
variable?



___

File Attachments:


---
Date: Fri 22 Dec 2017 10:50:53 PM EET  Name:
0001-Fix-miscellaneous-compiler-warnings.patch  Size: 5KiB   By: yavor



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #52729] [GWorkspace] incompatible-pointer-types compiler warnings

[Yavor Doganov]

URL:
  

 Summary: [GWorkspace] incompatible-pointer-types compiler
warnings
 Project: GNUstep
Submitted by: yavor
Submitted on: Fri 22 Dec 2017 07:54:32 PM EET
Category: Application
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Patch attached.



___

File Attachments:


---
Date: Fri 22 Dec 2017 07:54:32 PM EET  Name:
0001-Fix-incompatible-pointer-types-compiler-warning.patch  Size: 5KiB   By:
yavor



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #52727] [GWorkspace] Executable image/plist files

[Yavor Doganov]

URL:
  

 Summary: [GWorkspace] Executable image/plist files
 Project: GNUstep
Submitted by: yavor
Submitted on: Fri 22 Dec 2017 05:53:49 PM EET
Category: Application
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Some files are executable while they shouldn't:

./GWMetadata/Preferences/MDIndexing.tiff
./GWMetadata/Preferences/Resources/Images/plainfiles.tiff
./GWMetadata/Preferences/Resources/Images/music.tiff
./GWMetadata/Preferences/Resources/Images/sources.tiff
./GWMetadata/Preferences/Resources/Images/documents.tiff
./GWMetadata/Preferences/Resources/Images/pdfdocs.tiff
./Apps_wrappers/coccinella.app/coccinella.tiff
./Apps_wrappers/coccinella.app/Resources/Info-gnustep.plist
./Apps_wrappers/opennx.app/Resources/Info-gnustep.plist
./Apps_wrappers/spdrs60.app/spdrs60_48.tiff
./Apps_wrappers/spdrs60.app/Resources/Info-gnustep.plist
./Apps_wrappers/xtrkcad.app/xtrkcad.tiff
./Apps_wrappers/xtrkcad.app/Resources/Info-gnustep.plist
./Apps_wrappers/qlandkartegt.app/qlandkartegt.tiff
./Apps_wrappers/qlandkartegt.app/Resources/Info-gnustep.plist
./Apps_wrappers/vi.app/vi.tiff




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #52726] [GWorkspace] Various spelling fixes

[Yavor Doganov]

URL:
  

 Summary: [GWorkspace] Various spelling fixes
 Project: GNUstep
Submitted by: yavor
Submitted on: Fri 22 Dec 2017 03:13:42 PM EET
Category: Application
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Patch attached.



___

File Attachments:


---
Date: Fri 22 Dec 2017 03:13:42 PM EET  Name:
0001-Fix-miscellaneous-spelling-errors.patch  Size: 8KiB   By: yavor



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #52518] [GWorkspace] Unnecessarily complex build system

[Yavor Doganov]

Follow-up Comment #1, bug #52518 (project gnustep):

Thinko, I wanted to say "--no-undefined" instead of "--as-needed".

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #52518] [GWorkspace] Unnecessarily complex build system

[Yavor Doganov]

URL:
  

 Summary: [GWorkspace] Unnecessarily complex build system
 Project: GNUstep
Submitted by: yavor
Submitted on: Sun 26 Nov 2017 09:11:13 PM EET
Category: Application
Severity: 3 - Normal
  Item Group: Change Request
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

GWorkspace's build system is incredibly convoluted: there are 56 (!) nested
configure scripts, 14 config headers and 59 makefiles that are generated,
while only a small number of them have @something@ to be AC_SUBST'ed.  I tried
to find out whether there is specific reason for this approach, but couldn't
figure out why it was done this way.  Perhaps it remained so from Enrico's
days and nobody had the chance to clean it up.

The only legitimate reason for using AC_CONFIG_SUBDIRS is when software in
sub-directories is distributed as stand-alone packages (e.g., separate
self-contained tarballs for the frameworks, extractors, viewers, ddbd and the
rest of the tools)  That is not the case and I doubt it ever will be.

The attached patch, while rather intrusive, reduces the time for running
"./configure --enable-gwmetadata" more than 10 times and reduces the size of
the tarball with approx 2.5 MB.  It also fixes quotation of Autoconf macros in
some places, replaces the obsolete AC_TRY_RUN macro with AC_RUN_IFELSE and
fixes the build with LDFLAGS=-Wl,--as-needed.

Please let me know if something doesn't work as expected or if you have some
other remarks.  Thanks.



___

File Attachments:


---
Date: Sun 26 Nov 2017 09:11:13 PM EET  Name:
0001-Simplify-build-system.patch.xz  Size: 49KiB   By: yavor



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #52494] Does not handle exceptions when loading translations

[Yavor Doganov]

Follow-up Comment #1, bug #52494 (project gnustep):

One thing is bothering me... GUI sets its own exception handler so if
application code does not catch an exception, a critical alert panel must be
shown in addition to the usual logging that comes from Base.   In this case
there is no alert panel and nothing is logged.  I thought it might be a bug in
the runtime but at first glance it doesn't seem so.  A minimalistic program
([NSApplication sharedApplication] immediately followed by code that triggers
an exception) works as expected.

I'm quite certain there's another bug here; uncaught exceptions shouldn't be
swept under the carpet.  Any ideas?

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #52494] Does not handle exceptions when loading translations

[Yavor Doganov]

URL:
  <http://savannah.gnu.org/bugs/?52494>

 Summary: Does not handle exceptions when loading translations
 Project: GNUstep
Submitted by: yavor
Submitted on: Fri 24 Nov 2017 04:36:29 PM EET
Category: Gorm
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

I tried to translate a .gorm file using Gorm's Document->Translate feature. 
Exported the strings fine but couldn't load the translated .strings file.  I
selected the file in the open panel, pressed OK, the panel disappeared but
nothing happened.  It took me some time to figure out what's going on...

The exported strings are unquoted when there is only one word and I simply
forgot to quote one translated string.  So the exception that is rasied in
GSPropertyListFromStringsFormat is not caught by Gorm.  IMHO this is not
proper behavior: Gorm should report the error, otherwise the user is left
wondering what actually happened.  Also, you should not assume that
translators are aware that strings must be quoted, so I think it is a good
idea to provide them with some hint (using the established practice of
conveying information with a comment starting with "TRANSLATORS:").

Attached is a patch that fixes this issue.  I see that the ChangeLog has not
been updated recently, but here is a suggested entry anyway:

2017-11-24  Yavor Doganov  <ya...@gnu.org>

* GormCore/GormDocument.m (translate:): Add exception handling
when loading translations.
(exportStrings:): Prepend notice for translators.



___

File Attachments:


---
Date: Fri 24 Nov 2017 04:36:29 PM EET  Name:
0001-Add-exception-handling-when-loading-translations.patch  Size: 2KiB   By:
yavor

<http://savannah.gnu.org/bugs/download.php?file_id=42468>

___

Reply to this item at:

  <http://savannah.gnu.org/bugs/?52494>

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #52483] GNUstep Make should honor @setfilename in .texi documents

[Yavor Doganov]

URL:
  

 Summary: GNUstep Make should honor @setfilename in .texi
documents
 Project: GNUstep
Submitted by: yavor
Submitted on: Wed 22 Nov 2017 10:05:58 PM EET
Category: Makefiles
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

I consider it a bug that GNUstep Make ignores the @setfilename Texinfo command
and attempts (and fails) to build/clean/install generated files with the same
output name as the .texi.  Automake has coped with this since day one, if I'm
not mistaken.  There are various valid scenarios when @setfilename is used and
set to a different file than the .texi, and IMO any sane build system should
obey.

The attached patch takes care of this.  Tested with Base, Gui, Back, Gorm and
DBusKit, with Make configured with "debian" layout.  All main targets
(all/clean/install/uninstall) work properly for me.



___

File Attachments:


---
Date: Wed 22 Nov 2017 10:05:58 PM EET  Name:
0001-Honor-setfilename-in-Texinfo-documents.patch  Size: 7KiB   By: yavor



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #42641] Use makeinfo --html to generate HTML manuals from .texi documents

[Yavor Doganov]

Follow-up Comment #1, bug #42641 (project gnustep):

This bug can be closed as a stripped version of the proposed patch has been
applied (commit:d69117e).

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #52375] [SQLClient] Spelling fixes

[Yavor Doganov]

URL:
  

 Summary: [SQLClient] Spelling fixes
 Project: GNUstep
Submitted by: yavor
Submitted on: Thu 09 Nov 2017 07:09:54 PM EET
Category: Libraries
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

There is a spelling error in SQLClient.m ("missmatch").  Trivial patch
attached.



___

File Attachments:


---
Date: Thu 09 Nov 2017 07:09:54 PM EET  Name: spelling-errors.patch  Size: 934B
  By: yavor



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #52331] use-after-free in the privateSetLocale function

[Yavor Doganov]

Follow-up Comment #4, bug #52331 (project gnustep):

> The GNUstep repositories are now located at GitHub:

That is very unfortunate.

> This is mentioned on the GNUstep web site but maybe not
> prominent enough. 

Yes, found it.  The last link under "Get it!" on the main page at gnustep.org
is confusing: it points to a wiki.gnustep.org page with instructions for the
old SVN repositories at gna.org.  

Thanks for fixing the bug, you can close this item.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #52331] use-after-free in the privateSetLocale function

[Yavor Doganov]

Follow-up Comment #2, bug #52331 (project gnustep):

Thanks, but could you please tell me where is the canonical repository?  Gna!
is gone and it looks like there wasn't migration to Savannah.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #52331] use-after-free in the privateSetLocale function

[Yavor Doganov]

URL:
  

 Summary: use-after-free in the privateSetLocale function
 Project: GNUstep
Submitted by: yavor
Submitted on: Thu 02 Nov 2017 05:21:30 PM EET
Category: Base/Foundation
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Jakub Wilk  reports via Debian (#880575):

GNUstep Base 1.25.0
Architecture: i386 (x86)

The privateSetLocale() function can use memory that has been already freed:

$ valgrind -q -- ./test-locale
  ==9722== Invalid read of size 1
  ==9722==at 0x48313D8: strlen (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
  ==9722==by 0x4A5FD89: _i_NSString__initWithCString_encoding_
(NSString.m:1246)
  ==9722==by 0x4A5CAB3: _c_NSString__stringWithCString_encoding_
(NSString.m:954)
  ==9722==by 0x48E2897: privateSetLocale (GSLocale.m:75)
  ==9722==by 0x48E37CB: GSDefaultLanguageLocale (GSLocale.m:330)
  ==9722==by 0x4A9BFCC: systemLanguages (NSUserDefaults.m:375)
  ==9722==by 0x4A9BFCC: newLanguages (NSUserDefaults.m:397)
  ==9722==by 0x4A9DF6D: _c_NSUserDefaults__standardUserDefaults
(NSUserDefaults.m:928)
  ==9722==by 0x10878E: main (test-locale.m:10)
  ==9722==  Address 0x7a78688 is 0 bytes inside a block of size 181 free'd
  ==9722==at 0x482F478: free (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
  ==9722==by 0x4E9CE77: setname (setlocale.c:201)
  ==9722==by 0x4E9CE77: setlocale (setlocale.c:456)
  ==9722==by 0x4B0D13D: GSPrivateNativeCStringEncoding (Unicode.m:2862)
  ==9722==by 0x48E2891: privateSetLocale (GSLocale.m:75)
  ==9722==by 0x48E37CB: GSDefaultLanguageLocale (GSLocale.m:330)
  ==9722==by 0x4A9BFCC: systemLanguages (NSUserDefaults.m:375)
  ==9722==by 0x4A9BFCC: newLanguages (NSUserDefaults.m:397)
  ==9722==by 0x4A9DF6D: _c_NSUserDefaults__standardUserDefaults
(NSUserDefaults.m:928)
  ==9722==by 0x10878E: main (test-locale.m:10)
  ==9722==  Block was alloc'd at
  ==9722==at 0x482E2BC: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
  ==9722==by 0x4E9C998: new_composite_name (setlocale.c:172)
  ==9722==by 0x4E9CF49: setlocale (setlocale.c:378)
  ==9722==by 0x108742: main (test-locale.m:8)

This happens because it calls setlocale twice; once directly:

 clocale = setlocale(category, clocale);

and then again indirectly: ToString -> GSPrivateNativeCStringEncoding -> 
setlocale.

The other call invalidates the clocale pointer, as allowed by POSIX: 
"The returned string pointer might be invalidated or the string content 
might be overwritten by a subsequent call to setlocale()."

Attaching the test program.  (FWIW, I can't reproduce on x86 and x86_64.)



___

File Attachments:


---
Date: Thu 02 Nov 2017 05:21:30 PM EET  Name: test-locale.m  Size: 281B   By:
yavor
Test program supposed to demonstrate the bug


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #52197] [DBusKit] Trivial spelling fixes

[Yavor Doganov]

URL:
  

 Summary: [DBusKit] Trivial spelling fixes
 Project: GNUstep
Submitted by: yavor
Submitted on: Mon 09 Oct 2017 05:00:29 PM EEST
Category: Libraries
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Attached is a patch which fixes some spelling errors:

initalized -> initialized
contan -> contain
Timout -> Timeout



___

File Attachments:


---
Date: Mon 09 Oct 2017 05:00:29 PM EEST  Name: spelling-errors.patch  Size:
2KiB   By: yavor



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #52126] GUI 0.25.1 ABI break?

[Yavor Doganov]

URL:
  

 Summary: GUI 0.25.1 ABI break?
 Project: GNUstep
Submitted by: yavor
Submitted on: Wed 27 Sep 2017 11:56:34 PM EEST
Category: Gui/AppKit
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

It looks like 0.25.1 introduced ABI incompatibility compared to 0.25.0.  Some
ivars in NSTableView and NSTableHeaderView were changed to the new
NSInteger/CGFloat types which seems to lead to ABI breakage on 64-bit
platforms. Unfortunately the SVN repository at Gna is not accessible and it
looks like the migration to Savannah has not happened, so I can't give you the
revision(s). At first glance it seems this one:

2016-10-08 Fred Kiefer 

   * Headers/AppKit/NSOutlineView.h
   * Headers/AppKit/NSTableHeaderView.h
   * Headers/AppKit/NSTableView.h
   * Source/GSThemeDrawing.m
   * Source/NSOutlineView.m
   * Source/NSTableHeaderView.m
   * Source/NSTableView.m:
   Some int -> NSInteger and float -> CGFloat transitions.




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #42782] Crash when loading a gorm file

[Yavor Doganov]

Follow-up Comment #21, bug #42782 (project gnustep):

 The issues comes from the fact that there is a file called 
 data.info that contains metadata needed for editing. Since this  file has a
.info extension and the GSImageMagickImageRep 
 reports that it can load .info files, Gorm attempts to load 
 this as an image and, naturally, fails. 

Yes, this was precisely the problem, thanks for fixing it.  I thought it was
clear from comment #6 onwards, but...

 Looking at the history it is hard to follow and I believe it
 mixes two separate problems.

Sorry about that, it is very confusing indeed.  There are three different
issues, actually:

 - The GSGormLoader bug that Fred fixed in GUI
 - The Gorm bug that you have fixed
 - The Vindaloo bug in its CenteringClipView implementation exposed by GCC 4.9
(I've fixed that in Debian at least)

You can close this bug; nothing to do here.

___

Reply to this item at:

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

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #42717] Crash in -[NSBox(Private) calcSizesAllowingNegative:]

[Yavor Doganov]

Follow-up Comment #15, bug #42717 (project gnustep):

Yes, this bug has been fixed.

___

Reply to this item at:

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

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #42871] Trivial typo in gnustep-examples

[Yavor Doganov]

URL:
  http://savannah.gnu.org/bugs/?42871

 Summary: Trivial typo in gnustep-examples
 Project: GNUstep
Submitted by: yavor
Submitted on: Tue 29 Jul 2014 12:53:39 PM EEST
Category: Testsuite
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Information is an uncountable noun (at least in the sense it is used) so it
is grammatically incorrect to use a plural form.



___

File Attachments:


---
Date: Tue 29 Jul 2014 12:53:39 PM EEST  Name: typo-fix.patch  Size: 651B   By:
yavor

http://savannah.gnu.org/bugs/download.php?file_id=31794

___

Reply to this item at:

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

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #42782] Crash when loading a gorm file

[Yavor Doganov]

Follow-up Comment #16, bug #42782 (project gnustep):

Now even older versions of Gorm open the file, but only if GUI is built with
--disable-imagemagick.  With --enable-imagemagick, Gorm crashes and with your
latest Gorm change shows an alert panel and doesn't open the file.  This
happens with any gorm file, not just Document.gorm.  I believe this is a
separate issue and related to the fact that all gorm files have .info files
inside them.

Vindaloo crashes at a later stage and the backtrace is much more palatable:

Program received signal SIGSEGV, Segmentation fault.
0x08049d24 in -[CenteringClipView constrainScrollPoint:] (self=0xb0b8, 
_cmd=0x83960f8, proposedNewOrigin=...) at CenteringClipView.m:83
83 return newScrollPoint;
(gdb) bt
#0  0x08049d24 in -[CenteringClipView constrainScrollPoint:] (self=0xb0b8,

_cmd=0x83960f8, proposedNewOrigin=...) at CenteringClipView.m:83
#1  0xb7ec5418 in _OBJC_SELECTOR_TABLE () from
/usr/lib/libgnustep-gui.so.0.24
#2  0xb7b69afb in -[NSClipView setFrame:] (self=0x83960f8, 
_cmd=0x805c978 _OBJC_SELECTOR_TABLE+888, rect=...) at NSClipView.m:569
#3  0x08049efd in -[CenteringClipView setFrame:] (self=0x83960f8, 
_cmd=0xb7f2b3a8 _OBJC_SELECTOR_TABLE+1320, aFrame=...)
at CenteringClipView.m:100
#4  0xb7c2a8b7 in -[NSScrollView tile] (self=0x82f9b68, 
_cmd=0xb7f2b220 _OBJC_SELECTOR_TABLE+928) at NSScrollView.m:1275
#5  0xb7c28275 in -[NSScrollView setContentView:] (self=0x82f9b68, 
_cmd=0x805e318 _OBJC_SELECTOR_TABLE+1432, 
aView=0xb7f2b220 _OBJC_SELECTOR_TABLE+928) at NSScrollView.m:278
#6  0x0804b31d in -[Controller(Private) _setupScrollView] (self=0x83778e0, 
_cmd=0x805e0e8 _OBJC_SELECTOR_TABLE+872) at Controller.m:359
#7  0x0804a1cf in -[Controller windowDidLoad] (self=0x83778e0, 
_cmd=0xb7f68270 _OBJC_SELECTOR_TABLE+496) at Controller.m:72
#8  0xb7ca851f in -[NSWindowController _windowDidLoad] (self=0x83778e0, 
_cmd=0xb7f680c8 _OBJC_SELECTOR_TABLE+72) at NSWindowController.m:472
#9  0xb7ca8bf4 in -[NSWindowController window] (self=0x83778e0, 
_cmd=0xb7f68130 _OBJC_SELECTOR_TABLE+176) at NSWindowController.m:318
#10 0xb7ca8719 in -[NSWindowController showWindow:] (self=0x83778e0, 
_cmd=0xb7edb1f8 _OBJC_SELECTOR_TABLE+504, sender=0x81819e0)
at NSWindowController.m:395
#11 0xb76c121a in -[NSObject performSelector:withObject:] (self=0x83778e0, 
_cmd=0xb79b9e20 _OBJC_SELECTOR_TABLE+224, 
aSelector=0xb7edb1f8 _OBJC_SELECTOR_TABLE+504, anObject=0x81819e0)
at NSObject.m:2034
#12 0xb75b0f42 in -[GSArray makeObjectsPerformSelector:withObject:] (
self=0x87dbf58, _cmd=0xb7edb200 _OBJC_SELECTOR_TABLE+512, 
aSelector=0xb7edb1f8 _OBJC_SELECTOR_TABLE+504, argument=0x81819e0)
at GSArray.m:353
#13 0xb7b91332 in -[NSDocument showWindows] (self=0x81819e0, 
_cmd=0xb7edd868 _OBJC_SELECTOR_TABLE+488) at NSDocument.m:417
#14 0xb7b95885 in -[NSDocumentController
openDocumentWithContentsOfURL:display:error:] (self=0xb7edd868
_OBJC_SELECTOR_TABLE+488, 
_cmd=0xb7f73688 _OBJC_SELECTOR_TABLE+520, url=0x8132130, flag=1 ' 01', 
err=0xb4cc) at NSDocumentController.m:712
#15 0xb7cc066f in -[GSServicesManager application:openFile:] (self=0x81945d8,

_cmd=0xb7f736b0 _OBJC_SELECTOR_TABLE+560, theApp=0x8201128, 
file=0x8126668) at GSServicesManager.m:589
#16 0xb7cc0534 in -[GSServicesManager application:openFiles:] (self=0x81945d8,

_cmd=0xb7eac128 _OBJC_SELECTOR_TABLE+1960, theApp=0x8201128, 
files=0x8160818) at GSServicesManager.m:617
#17 0xb7b2dc31 in -[NSApplication finishLaunching] (self=0x8201128, 
_cmd=0xb7eac218 _OBJC_SELECTOR_TABLE+2200) at NSApplication.m:1126
#18 0xb7b3186d in -[NSApplication run] (self=0x8201128, 
_cmd=0xb7ea2408 _OBJC_SELECTOR_TABLE+904) at NSApplication.m:1538
#19 0xb7b139bb in NSApplicationMain (argc=2, argv=0xb6e4) at
Functions.m:91
#20 0x08049857 in main (argc=2, argv=0xb6e4) at main.m:24


There's still something fishy.

(gdb) p proposedNewOrigin
$4 = optimized out
(gdb) p docRect
$5 = {origin = {x = 4.02598366e-34, y = 424}, size = {width = 471, 
height = 471}}
(gdb) p clipRect
$6 = {origin = {x = 0, y = 0}, size = {width = 471, height = 424}}
(gdb) p newScrollPoint
$7 = {x = optimized out, y = 0}
(gdb) fr 2
#2  0xb7b69afb in -[NSClipView setFrame:] (self=0x83960f8, 
_cmd=0x805c978 _OBJC_SELECTOR_TABLE+888, rect=...) at NSClipView.m:569
569   [self setBoundsOrigin: [self constrainScrollPoint: _bounds.origin]];
(gdb) po self
 h=-- v=-- CenteringClipView: 0x83960f8 f={x = 0; y = 0; width = 471;
height = 424} b={x = 0; y = 0; width = 471; height = 424}
(gdb) p _bounds.origin
No symbol _bounds in current context.


___

Reply to this item at:

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

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list

[bug #42782] Crash when loading a gorm file

[Yavor Doganov]

Follow-up Comment #17, bug #42782 (project gnustep):

Valgrind output:

==5323== Command: ./ViewPDF.app/ViewPDF /home/yavor/scratch/ba.pdf
==5323== 
2014-07-25 10:35:51.324 ViewPDF[5323] added font n022003l.pfb
2014-07-25 10:35:51.916 ViewPDF[5323] added font n022004l.pfb
2014-07-25 10:35:51.944 ViewPDF[5323] added font n022024l.pfb
2014-07-25 10:35:51.970 ViewPDF[5323] added font n022023l.pfb
2014-07-25 10:35:51.996 ViewPDF[5323] added font n019003l.pfb
2014-07-25 10:35:52.022 ViewPDF[5323] added font n019004l.pfb
2014-07-25 10:35:52.048 ViewPDF[5323] added font n019024l.pfb
2014-07-25 10:35:52.074 ViewPDF[5323] added font n019023l.pfb
2014-07-25 10:35:52.099 ViewPDF[5323] added font s05l.pfb
2014-07-25 10:35:52.126 ViewPDF[5323] added font n021004l.pfb
2014-07-25 10:35:52.151 ViewPDF[5323] added font n021024l.pfb
2014-07-25 10:35:52.177 ViewPDF[5323] added font n021023l.pfb
2014-07-25 10:35:52.203 ViewPDF[5323] added font n021003l.pfb
2014-07-25 10:35:52.229 ViewPDF[5323] added font d05l.pfb
using default fontconfig configuration
registered application font
/usr/lib/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0/Resources/n022003l.pfb
registered application font
/usr/lib/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0/Resources/n022004l.pfb
registered application font
/usr/lib/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0/Resources/n022024l.pfb
registered application font
/usr/lib/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0/Resources/n022023l.pfb
registered application font
/usr/lib/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0/Resources/n019003l.pfb
registered application font
/usr/lib/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0/Resources/n019004l.pfb
registered application font
/usr/lib/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0/Resources/n019024l.pfb
registered application font
/usr/lib/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0/Resources/n019023l.pfb
registered application font
/usr/lib/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0/Resources/s05l.pfb
registered application font
/usr/lib/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0/Resources/n021004l.pfb
registered application font
/usr/lib/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0/Resources/n021024l.pfb
registered application font
/usr/lib/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0/Resources/n021023l.pfb
registered application font
/usr/lib/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0/Resources/n021003l.pfb
registered application font
/usr/lib/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0/Resources/d05l.pfb
poppler library initialized
2014-07-25 10:36:03.531 ViewPDF[5323] PopplerKit Initialization SUCCEEDED
2014-07-25 10:36:09.114 ViewPDF[5323] use generic splash rendering
==5323== Conditional jump or move depends on uninitialised value(s)
==5323==at 0x8049CBF: _i_CenteringClipView__constrainScrollPoint_
(CenteringClipView.m:64)
==5323==by 0x44CD417: ??? (in /usr/lib/libgnustep-gui.so.0.24.0)
==5323==
==5323== Conditional jump or move depends on uninitialised value(s)
==5323==at 0x8049D41: _i_CenteringClipView__constrainScrollPoint_
(CenteringClipView.m:70)
==5323==by 0x44CD417: ??? (in /usr/lib/libgnustep-gui.so.0.24.0)
==5323== 
==5323== Conditional jump or move depends on uninitialised value(s)
==5323==at 0x8049D4D: _i_CenteringClipView__constrainScrollPoint_
(CenteringClipView.m:70)
==5323==by 0x44CD417: ??? (in /usr/lib/libgnustep-gui.so.0.24.0)
==5323== 
==5323== Conditional jump or move depends on uninitialised value(s)
==5323==at 0x8049D54: _i_CenteringClipView__constrainScrollPoint_
(CenteringClipView.m:70)
==5323==by 0x44CD417: ??? (in /usr/lib/libgnustep-gui.so.0.24.0)
==5323== 
==5323== Conditional jump or move depends on uninitialised value(s)
==5323==at 0x8049CF7: _i_CenteringClipView__constrainScrollPoint_
(CenteringClipView.m:74)
==5323==by 0x44CD417: ??? (in /usr/lib/libgnustep-gui.so.0.24.0)
==5323==
==5323== Conditional jump or move depends on uninitialised value(s)
==5323==at 0x8049D04: _i_CenteringClipView__constrainScrollPoint_
(CenteringClipView.m:80)
==5323==by 0x44CD417: ??? (in /usr/lib/libgnustep-gui.so.0.24.0)
==5323== 
==5323== Conditional jump or move depends on uninitialised value(s)
==5323==at 0x8049D17: _i_CenteringClipView__constrainScrollPoint_
(CenteringClipView.m:80)
==5323==by 0x44CD417: ??? (in /usr/lib/libgnustep-gui.so.0.24.0)
==5323== 
==5323== 
==5323== Process terminating with default action of signal 11 (SIGSEGV)
==5323==  Bad permissions for mapped region at address 0x4171AFB
==5323==at 0x8049D24: _i_CenteringClipView__constrainScrollPoint_
(CenteringClipView.m:83)
==5323==by 0x44CD417: ??? (in /usr/lib/libgnustep-gui.so.0.24.0)
==5323==


___

Reply to this item at:

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

___
  

[bug #42782] Crash when loading a gorm file

[Yavor Doganov]

Follow-up Comment #19, bug #42782 (project gnustep):

Sorry for mixing the two issues.  You are right about Vindaloo.  

Unfortunately the Gorm backtrace is unlikely to be of any use:

Starting program: /usr/bin/Gorm
/usr/lib/GNUstep/Applications/Ink.app/Resources/Document.gorm/
[Thread debugging using libthread_db enabled]
Using host libthread_db library
/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1.
2014-07-25 12:51:42.026 Gorm[2165] Tiff Error (GSTiffReadData) Not a TIFF or
MDI file, bad magic number 20039 (0x4e47)
2014-07-25 12:51:42.057 Gorm[2165] Tiff Error (GSTiffReadData) Not a TIFF or
MDI file, bad magic number 20039 (0x4e47)

Program received signal SIGSEGV, Segmentation fault.
0x09ae01d1 in ?? ()
(gdb) bt
Python Exception class 'gdb.MemoryError' Cannot access memory at address
0x5: 
#0  0x09ae01d1 in ?? ()
Cannot access memory at address 0x5


With your recent Gorm change I observe the behavior described in comment#6.

___

Reply to this item at:

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

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #42411] gdomap chroots to /tmp

[Yavor Doganov]

Follow-up Comment #3, bug #42411 (project gnustep):

The bug submitter suggests:

1) create an empty directory in /run (optionally via tmpfiles.d)

2) or ship one in /usr/share/gdomap/empty-directory-for-chroot (or so) in the
package itself

3) Don't chroot?  That is less broken than chroot into a
world-writable location.

I believe 1) is not portable while 2) is not acceptable as a general solution
since it is distro-specific.

___

Reply to this item at:

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

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #42804] Dubious configure test for -fexec-charset

[Yavor Doganov]

Follow-up Comment #4, bug #42804 (project gnustep):

Thanks.  I have filed a bug with a patch for the GCC manual.

___

Reply to this item at:

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

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #42782] Crash when loading a gorm file

[Yavor Doganov]

Follow-up Comment #13, bug #42782 (project gnustep):

I think this should be reproducible with GCC 4.8 as well, it's the
architecture that matters.  As x86 is gradually being replaced with x86_64
it's not a big surprise that the majority of users do not encounter these
bugs.  I'll try to reproduce with older compiler versions.

___

Reply to this item at:

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

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #42782] Crash when loading a gorm file

[Yavor Doganov]

Follow-up Comment #14, bug #42782 (project gnustep):

I was wrong, cannot reproduce with GCC 4.8.3.  Gorm opens the file just fine. 
Vindaloo crashes at -[CenteringClipView constrainScrollPoint:] which could be
a bug in Vindaloo as it opens the PDF file if I modify it to use plain
NSClipView. The backtrace shows a corrupt stack again:

Program received signal SIGSEGV, Segmentation fault.
0x0804bb34 in -[CenteringClipView constrainScrollPoint:] (self=0xb088, 
_cmd=0x83e7600, proposedNewOrigin=...) at CenteringClipView.m:82
82 return newScrollPoint;
(gdb) bt
#0  0x0804bb34 in -[CenteringClipView constrainScrollPoint:] (self=0xb088,

_cmd=0x83e7600, proposedNewOrigin=...) at CenteringClipView.m:82
#1  0xb0b8 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)


Two interesting things:

* In -[GSWindowTemplate initWithCoder:] there's no _object as well but no
crash either.  The execution continues.

* -[CenteringClipView setFrame:] just calls the super class implementation,
which in turn calls [self setBoundsOrigin: [self constrainScrollPoint:
_bounds.origin]]; _bounds is undefined at this point.  This method is actually
overriden with Vindaloo's own -constrainScrollPoint: where the crash happens. 
proposedNewOrigin is optimized there, it might be just garbage and not a valid
NSPoint.

___

Reply to this item at:

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

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #42778] Frameworks with different SONAME cannot coexist

[Yavor Doganov]

Follow-up Comment #2, bug #42778 (project gnustep):

Proposed patch attached.  It makes the existence of two framework versions (in
fact, multiple framework versions) possible.  It doesn't delete the installed
framework prior to the installation of the new one and symlinks are created
directly to the versioned directory instead of the Current symlink.  Also,
since Resources are version-specific (or at least they may be) it is not
correct to create a Resources symlink pointing to Current.  Headers are also
version-specific but as there can only be one .so symlink only one set of
headers can be used at any time (the Current headers, so this behavior is
retained).

Tested with RSSKit/0.3, then RSSKit/0.4 installed on top of it with
INTERFACE_VERSION set to 1, then RSSKit/0.4 with VERSION bumped to 0.4.1
(simulating a new release which is ABI-compatible with 0.4).  It appears to
work:

$ ls -l /tmp/foo/usr/lib/
общо 28
drwxr-xr-x 3 yavor yavor 4096 юли 24 14:44 GNUstep
lrwxrwxrwx 1 yavor yavor   67 юли 24 15:02 libRSSKit.so -
./GNUstep/Frameworks/RSSKit.framework/Versions/Current/libRSSKit.so
lrwxrwxrwx 1 yavor yavor   63 юли 24 14:44 libRSSKit.so.0 -
./GNUstep/Frameworks/RSSKit.framework/Versions/0/libRSSKit.so.0
lrwxrwxrwx 1 yavor yavor   65 юли 24 14:44 libRSSKit.so.0.3 -
./GNUstep/Frameworks/RSSKit.framework/Versions/0/libRSSKit.so.0.3
lrwxrwxrwx 1 yavor yavor   65 юли 24 14:47 libRSSKit.so.0.4 -
./GNUstep/Frameworks/RSSKit.framework/Versions/1/libRSSKit.so.0.4
lrwxrwxrwx 1 yavor yavor   67 юли 24 15:02 libRSSKit.so.0.4.1 -
./GNUstep/Frameworks/RSSKit.framework/Versions/1/libRSSKit.so.0.4.1
lrwxrwxrwx 1 yavor yavor   63 юли 24 15:02 libRSSKit.so.1 -
./GNUstep/Frameworks/RSSKit.framework/Versions/1/libRSSKit.so.1
$ ls -l /tmp/foo/usr/lib/GNUstep/Frameworks/RSSKit.framework/
общо 4
lrwxrwxrwx 1 yavor yavor   24 юли 24 14:46 Headers -
Versions/Current/Headers
lrwxrwxrwx 1 yavor yavor   31 юли 24 14:47 libRSSKit.so -
./Versions/Current/libRSSKit.so
lrwxrwxrwx 1 yavor yavor   25 юли 24 14:47 RSSKit -
./Versions/Current/RSSKit
drwxr-xr-x 4 yavor yavor 4096 юли 24 14:46 Versions
$ ls -l /tmp/foo/usr/lib/GNUstep/Frameworks/RSSKit.framework/Versions/
общо 8
drwxr-xr-x 4 yavor yavor 4096 юли 24 14:43 0
drwxr-xr-x 4 yavor yavor 4096 юли 24 15:00 1
lrwxrwxrwx 1 yavor yavor1 юли 24 14:46 Current - 1


Installing in the USER domain is OK too:

$ ls -l ~/GNUstep/Library/Libraries/
общо 8
lrwxrwxrwx 1 yavor yavor 60 юли 24 15:00 libRSSKit.so -
../Frameworks/RSSKit.framework/Versions/Current/libRSSKit.so
lrwxrwxrwx 1 yavor yavor 56 юли 24 14:44 libRSSKit.so.0 -
../Frameworks/RSSKit.framework/Versions/0/libRSSKit.so.0
lrwxrwxrwx 1 yavor yavor 58 юли 24 14:44 libRSSKit.so.0.3 -
../Frameworks/RSSKit.framework/Versions/0/libRSSKit.so.0.3
lrwxrwxrwx 1 yavor yavor 58 юли 24 14:47 libRSSKit.so.0.4 -
../Frameworks/RSSKit.framework/Versions/1/libRSSKit.so.0.4
lrwxrwxrwx 1 yavor yavor 60 юли 24 15:00 libRSSKit.so.0.4.1 -
../Frameworks/RSSKit.framework/Versions/1/libRSSKit.so.0.4.1
lrwxrwxrwx 1 yavor yavor 56 юли 24 15:00 libRSSKit.so.1 -
../Frameworks/RSSKit.framework/Versions/1/libRSSKit.so.1
$ ls -l ~/GNUstep/Library/Frameworks/RSSKit.framework/
общо 4
lrwxrwxrwx 1 yavor yavor   24 юли 24 14:46 Headers -
Versions/Current/Headers
lrwxrwxrwx 1 yavor yavor   31 юли 24 14:47 libRSSKit.so -
./Versions/Current/libRSSKit.so
lrwxrwxrwx 1 yavor yavor   25 юли 24 14:47 RSSKit -
./Versions/Current/RSSKit
drwxr-xr-x 4 yavor yavor 4096 юли 24 14:46 Versions
$ ls -l ~/GNUstep/Library/Frameworks/RSSKit.framework/Versions/
общо 8
drwxr-xr-x 4 yavor yavor 4096 юли 24 14:43 0
drwxr-xr-x 4 yavor yavor 4096 юли 24 15:00 1
lrwxrwxrwx 1 yavor yavor1 юли 24 14:46 Current - 1
$ ls -l ~/GNUstep/Library/Frameworks/RSSKit.framework/Versions/0/
общо 256
drwxr-xr-x 2 yavor yavor   4096 юли 24 14:43 Headers
lrwxrwxrwx 1 yavor yavor 14 юли 24 14:43 libRSSKit.so -
libRSSKit.so.0
lrwxrwxrwx 1 yavor yavor 16 юли 24 14:43 libRSSKit.so.0 -
libRSSKit.so.0.3
-rwxr-xr-x 1 yavor yavor 246948 юли 24 14:43 libRSSKit.so.0.3
drwxr-xr-x 2 yavor yavor   4096 юли 24 14:43 Resources
lrwxrwxrwx 1 yavor yavor 12 юли 24 14:43 RSSKit - libRSSKit.so
$ ls -l ~/GNUstep/Library/Frameworks/RSSKit.framework/Versions/1/
общо 504
drwxr-xr-x 2 yavor yavor   4096 юли 24 14:46 Headers
lrwxrwxrwx 1 yavor yavor 14 юли 24 15:00 libRSSKit.so -
libRSSKit.so.1
-rwxr-xr-x 1 yavor yavor 249584 юли 24 14:47 libRSSKit.so.0.4
-rwxr-xr-x 1 yavor yavor 249584 юли 24 15:00 libRSSKit.so.0.4.1
lrwxrwxrwx 1 yavor yavor 18 юли 24 15:00 libRSSKit.so.1 -
libRSSKit.so.0.4.1
drwxr-xr-x 2 yavor yavor   4096 юли 24 14:47 Resources
lrwxrwxrwx 1 yavor yavor 12 юли 24 15:00 RSSKit - libRSSKit.so


I also checked that projects that have an internal framework (whether intended
to be public or not) and set ADDITIONAL_LIB_DIRS to something like
-L../../Foo.framework/Versions/Current continue to build/link without
problems.

As this is one of the most sensitive areas in GNUstep Make, I guess 

[bug #42782] Crash when loading a gorm file

[Yavor Doganov]

Follow-up Comment #8, bug #42782 (project gnustep):

Yes, the info type is there and the array is quite large:

(gdb) po [NSImage imageFileTypes]
(tiff, tif, pnm, ppm, gif, jpeg, jpg, png, icns, 3fr, a, aai, ai, art, arw,
avi, avs, b, bgr, bgra, bie, bmp, bmp2, bmp3, brf, c, cal, cals, canvas,
caption, cin, cip, clip, cmyk, cmyka, cr2, crw, cur, cut, dcm, dcr, dcx, dds,
dfont, djvu, dng, dot, dpx, epdf, epi, eps, eps2, eps3, epsf, epsi, ept, ept2,
ept3, erf, exr, fax, fits, fractal, fts, g, g3, gif87, gradient, gray, group4,
hald, hdr, histogram, hrz, htm, html, icb, ico, icon, info, inline, ipl,
isobrl, j2c, j2k, jbg, jbig, jng, jp2, jpc, jpx, k, k25, kdc, label, m, m2v,
m4v, mac, map, mat, matte, mef, miff, mng, mono, mov, mp4, mpc, mpeg, mpg,
mrw, msl, msvg, mtv, mvg, nef, nrw, null, o, orf, otb, otf, pal, palm, pam,
pango, pattern, pbm, pcd, pcds, pcl, pct, pcx, pdb, pdf, pdfa, pef, pes, pfa,
pfb, pfm, pgm, pgx, picon, pict, pix, pjpeg, plasma, png24, png32, png8,
preview, ps, ps2, ps3, psb, psd, ptif, pwp, r, radial-gradient, raf, ras,
rgb, rgba, rgbo, rla, rle, scr, sct, sfw, sgi, shtml, sr2, srf, stegano, sun,
svg, svgz, text, tga, thumbnail, tiff64, tile, tim, ttc, ttf, txt, ubrl, uil,
uyvy, vda, vicar, vid, viff, vst, wbmp, wmf, wmv, wmz, wpg, x, x3f, xbm, xc,
xcf, xpm, xps, xv, xwd, y, ycbcr, ycbcra, yuv)


Apparently these extra types come from GSImageMagickImageRep; I get them on
amd64 too.

___

Reply to this item at:

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

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #42782] Crash when loading a gorm file

[Yavor Doganov]

Follow-up Comment #9, bug #42782 (project gnustep):

FYI, the bug is reproducible if I rebuild GUI with --disable-imagemagick (the
image file types are just tiff, tif, pnm, ppm, gif, jpeg, jpg, png, icns in
that case).  The gdb backtrace is meaningless again and the valgrind output
is:

==8543== Command: Gorm ./English.lproj/Document.gorm/
==8543== 
vex x86-IR: unhandled instruction bytes: 0x6D 0x7 0x8 0xC7
==8543== Invalid write of size 1
==8543==at 0xBEB7BF4A: ???
==8543==  Address 0x75b99204 is not stack'd, malloc'd or (recently) free'd
==8543== 
==8543== 
==8543== Process terminating with default action of signal 11 (SIGSEGV)
==8543==  Access not within mapped region at address 0x75B99204
==8543==at 0xBEB7BF4A: ???


___

Reply to this item at:

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

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #42782] Crash when loading a gorm file

[Yavor Doganov]

Follow-up Comment #11, bug #42782 (project gnustep):

Yes, I used Gorm 1.2.20 + your latest changes.  Most probably it is not an
issue with Gorm at all.

I'd really wish to provide more information...  Perhaps I could put
breakpoints at some places and step through from there, this would at least
give you some clue, as blurry as that may be.  As Gorm is a fairly complex
program, I'm trying Vindaloo first.  I already figured out that Vindaloo
crashes in -[Document -makeWindowControllers], right after [self
addWindowController: ctrl]; ctrl is initalized properly with
-initWithWindowNibName: with [self windowNibName] as argument (which returns
@Document).  Stepping from there:

(gdb) n
-[NSDocumentController openDocumentWithContentsOfURL:display:error:] (
self=0x840c0a8, _cmd=0xb7f73648 _OBJC_SELECTOR_TABLE+520, url=0x840ae20,

flag=1 ' 01', err=0xb4cc) at NSDocumentController.m:708
708   [self noteNewRecentDocument: document];
(gdb) n
710   if (flag  [self shouldCreateUI])
(gdb) n
712   [document showWindows];
(gdb) 

Program received signal SIGSEGV, Segmentation fault.
0xbfffef8a in ?? ()


Putting breakpoints further:

Breakpoint 2, -[NSDocument showWindows] (self=0x82a1268, 
_cmd=0xb7edd828 _OBJC_SELECTOR_TABLE+488) at NSDocument.m:415
415 {
(gdb) po _window_controllers 
(Controller: 0x83e54f8)
(gdb) n
417   withObject: self];
(gdb) n
416   [_window_controllers makeObjectsPerformSelector: 
@selector(showWindow:)
(gdb) n
417   withObject: self];
(gdb) n

Program received signal SIGSEGV, Segmentation fault.
0xbfffef8a in ?? ()

Breakpoint 3, -[NSWindowController showWindow:] (
self=0xb7edb1b8 _OBJC_SELECTOR_TABLE+504, 
_cmd=0xb7edb1b8 _OBJC_SELECTOR_TABLE+504, sender=0x81fdb90)
at NSWindowController.m:394
394 {
(gdb) n
395   NSWindow *window = [self window];
(gdb) po self
Controller: 0x83e73e8
(gdb) po [self window]

Program received signal SIGSEGV, Segmentation fault.
0xbfffef6a in ?? ()

Breakpoint 4, -[NSWindowController window] (self=0x83ea168, 
_cmd=0xb7f680f0 _OBJC_SELECTOR_TABLE+176) at NSWindowController.m:297
297 {
(gdb) n
298   if (_window == nil  ![self isWindowLoaded])
(gdb) n
308   [self windowWillLoad];
(gdb) p _window
$5 = (struct NSWindow *) 0x0
(gdb) n
309   if (_owner != self 
(gdb) po self
Controller: 0x83ea168
(gdb) po _owner
Controller: 0x83ea168
(gdb) n
315   [self loadWindow];
(gdb) n

Program received signal SIGSEGV, Segmentation fault.

Breakpoint 5, -[NSWindowController loadWindow] (self=0x83e5340, 
_cmd=0xb7f68170 _OBJC_SELECTOR_TABLE+304) at NSWindowController.m:476
476 {
(gdb) n
479   if ([self isWindowLoaded]) 
(gdb) n
484   table = [NSDictionary dictionaryWithObject: _owner forKey: 
NSNibOwner];
(gdb) po table
value has been optimized out
(gdb) n
485   if ([NSBundle loadNibFile: [self windowNibPath]
(gdb) po self
Controller: 0x83e5340
(gdb) po [self windowNibPath]
/home/yavor/scratch/viewpdf.app-0.2dfsg1/ViewPDF.app/Resources/English.lproj/Document.gorm
(gdb) po _owner
Controller: 0x83e5340
(gdb) n
487 withZone: [_owner zone]])
(gdb) n
485   if ([NSBundle loadNibFile: [self windowNibPath]
(gdb) n
487 withZone: [_owner zone]])
(gdb) n

Program received signal SIGSEGV, Segmentation fault.
0xbfffef8a in ?? ()

Breakpoint 6, +[NSBundle(NSBundleAdditions)
loadNibFile:externalNameTable:withZone:] (self=0xb79d43e0
_OBJC_Class_NSBundle, 
_cmd=0xb7f68250 _OBJC_SELECTOR_TABLE+528, fileName=0x8268c18, 
context=0x8267fe0, zone=0xb7a3f0c0 default_zone)
at NSBundleAdditions.m:234
234 {
(gdb) n
235   NSNib *nib = [[NSNib alloc] initWithContentsOfURL: [NSURL
fileURLWithPath: fileName]];
(gdb) po fileName
/home/yavor/scratch/viewpdf.app-0.2dfsg1/ViewPDF.app/Resources/English.lproj/Document.gorm
(gdb) po [NSURL fileURLWithPath: fileName]
file://localhost/home/yavor/scratch/viewpdf.app-0.2dfsg1/ViewPDF.app/Resources/English.lproj/Document.gorm/
(gdb) po context
{NSOwner = Controller: 0x83e5568; }
(gdb) n
237 withZone: zone];
(gdb) po nib
value has been optimized out
(gdb) n
235   NSNib *nib = [[NSNib alloc] initWithContentsOfURL: [NSURL
fileURLWithPath: fileName]];
(gdb) n
239   RELEASE(nib);
(gdb) n
235   NSNib *nib = [[NSNib alloc] initWithContentsOfURL: [NSURL
fileURLWithPath: fileName]];
(gdb) n
237 withZone: zone];
(gdb) n
236   BOOL loaded = [nib instantiateNibWithExternalNameTable: context
(gdb) n

Program received signal SIGSEGV, Segmentation fault.
0xbfffef8a in ?? ()

Breakpoint 7, -[NSNib instantiateNibWithExternalNameTable:withZone:] (
self=0x8411090, _cmd=0xb7ebc0d0 _OBJC_SELECTOR_TABLE+208, 
externalNameTable=0x8410c28, zone=0xb7a3f0c0 default_zone) at
NSNib.m:152
152  

[bug #42782] Crash when loading a gorm file

[Yavor Doganov]

Follow-up Comment #6, bug #42782 (project gnustep):

Gorm doesn't crash now but it doesn't load the file either.  An alert panel is
shown with title Alert and No information as message.  The image file
is, oddly enough, data.info.  Here's the backtrace when this method is
reached:

Breakpoint 1, -[GormImage initWithData:withFileName:inWrapper:] (
self=0x9010440, _cmd=0xb7fae9a0 _OBJC_SELECTOR_TABLE+32, 
aData=0x81a0498, aName=0x9028d60, flag=1 ' 01') at GormImage.m:84
84[smallImage setSize: NSMakeSize(70, originalSize.height / 
ratioW)];
(gdb) po aName
data.info
(gdb) bt
#0  -[GormImage initWithData:withFileName:inWrapper:] (self=0x9010440, 
_cmd=0xb7fae9a0 _OBJC_SELECTOR_TABLE+32, aData=0x81a0498, 
aName=0x9028d60, flag=1 ' 01') at GormImage.m:84
#1  0xb7f15136 in +[GormImage imageForData:withFileName:inWrapper:] (
self=0xb7faea60 _OBJC_Class_GormImage, 
_cmd=0xb7fd9238 _OBJC_SELECTOR_TABLE+952, aData=0x81a0498, 
aName=0x9028d60, flag=1 ' 01') at GormImage.m:56
#2  0xb7f46a2b in -[GormWrapperLoader loadFileWrapper:withDocument:] (
self=0x8b1b310, _cmd=0xb2c26980 _OBJC_SELECTOR_TABLE+1216, 
wrapper=0x9082728, doc=0x8544568) at GormWrapperLoader.m:87
#3  0xb2c1fd2f in -[GormGormWrapperLoader loadFileWrapper:withDocument:] (
self=0x8b1b310, _cmd=0xb7fa4208 _OBJC_SELECTOR_TABLE+3336, 
wrapper=0x9082728, doc=0x8544568) at GormGormWrapperLoader.m:361
#4  0xb7f071eb in -[GormDocument loadFileWrapperRepresentation:ofType:] (
self=0x8544568, _cmd=0xb7dc22b8 _OBJC_SELECTOR_TABLE+696, 
wrapper=0x9082728, type=0x8143480) at GormDocument.m:3373
#5  0xb7a7782f in -[NSDocument readFromFileWrapper:ofType:error:] (
self=0x8544568, _cmd=0xb7dc22d0 _OBJC_SELECTOR_TABLE+720, 
wrapper=0x9082728, type=0x8143480, error=0xb53c) at NSDocument.m:723
#6  0xb7a77768 in -[NSDocument readFromURL:ofType:error:] (self=0x8544568, 
_cmd=0xb7dc20b8 _OBJC_SELECTOR_TABLE+184, url=0x9082728, type=0x8143480,

error=0xb53c) at NSDocument.m:757
#7  0xb7a78d41 in -[NSDocument initForURL:withContentsOfURL:ofType:error:] (
self=0x8544568, _cmd=0xb7dc2108 _OBJC_SELECTOR_TABLE+264, 
forUrl=0x99d4120, url=0x99d4120, type=0x8143480, error=0xb53c)
at NSDocument.m:163
#8  0xb7a78bf5 in -[NSDocument initWithContentsOfURL:ofType:error:] (
self=0x8544568, _cmd=0xb7dc4800 _OBJC_SELECTOR_TABLE+384, url=0x99d4120,

type=0x8143480, error=0xb53c) at NSDocument.m:189
#9  0xb7a7d222 in -[NSDocumentController
makeDocumentWithContentsOfURL:ofType:error:] (self=0x8544568, _cmd=0xb7dc48d8
_OBJC_SELECTOR_TABLE+600, 
url=0x99d4120, type=0x8143480, err=0xb53c)
at NSDocumentController.m:446
#10 0xb7a7c76c in -[NSDocumentController
openDocumentWithContentsOfURL:display:error:] (self=0x8831348, _cmd=0xb7e5a688
_OBJC_SELECTOR_TABLE+520, 
url=0x99d4120, flag=1 ' 01', err=0xb53c) at
NSDocumentController.m:690
#11 0xb7ba748f in -[GSServicesManager application:openFile:] (self=0x81ca890,

_cmd=0xb7e5a6b0 _OBJC_SELECTOR_TABLE+560, theApp=0x81f6ee8, 
file=0x811b3c8) at GSServicesManager.m:589
#12 0xb7ba7354 in -[GSServicesManager application:openFiles:] (self=0x81ca890,

_cmd=0xb7d93128 _OBJC_SELECTOR_TABLE+1960, theApp=0x81f6ee8, 
files=0x816e008) at GSServicesManager.m:617
#13 0xb7a14c31 in -[NSApplication finishLaunching] (self=0x81f6ee8, 
_cmd=0xb7d93218 _OBJC_SELECTOR_TABLE+2200) at NSApplication.m:1126
#14 0xb7a1886d in -[NSApplication run] (self=0x81f6ee8, 
_cmd=0xb7d89408 _OBJC_SELECTOR_TABLE+904) at NSApplication.m:1538
#15 0xb79fa9bb in NSApplicationMain (argc=2, argv=0xb754) at
Functions.m:91
#16 0x08049327 in main (argc=2, argv=0xb754) at main.m:30


___

Reply to this item at:

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

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #42717] Crash in -[NSBox(Private) calcSizesAllowingNegative:]

[Yavor Doganov]

Follow-up Comment #11, bug #42717 (project gnustep):

No crash if I apply your changes in r38003.

If it is a compiler bug, most probably it is present in earlier versions as
this bug was reported last year when 4.9 was not released yet.  However, it
may be that GCC is taking advantage of the undefined behaviour scenario and
is optimizing in a way that leads to a crash.  Very often code that works with
-O0 but fails with -O2 reveals a bug in the code, not the compiler.  In any
case, if it is a compiler bug, it should be haunted down and fixed rather than
the code adapted to cope with it.  IMHO.  It might be difficult to write a
self-contained example exposing the bug, though.

___

Reply to this item at:

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

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #42778] Frameworks with different SONAME cannot coexist

[Yavor Doganov]

Follow-up Comment #1, bug #42778 (project gnustep):

Actually, it is even more serious than that.  Installing a new version of the
framework will wipe out the old one completely, so there will only be one
Version, with Current pointing to it.  This is done unconditionally as the
first command of the internal_framework_install_ recipe.  The current behavior
defeats the whole idea of frameworks (not that I ever understood what
frameworks are for in the first place).

What I wrote in the first message (that the old libBar is still in Versions/0)
is true when the framework is packaged as it is installed in a tmp dir during
build and there's no previous framework version to delete there.

Steps to reproduce (with a random GNUstep framework):

$ make
$ make install DESTDIR=/tmp/foo
$ make clean
$ make install INTERFACE_VERSION=5 DESTDIR=/tmp/foo

And the shocking result:

$ ls -l /tmp/foo/usr/lib/
общо 20
drwxr-xr-x 3 yavor yavor 4096 юли 21 19:01 GNUstep
lrwxrwxrwx 1 yavor yavor   67 юли 21 19:02 libRSSKit.so -
./GNUstep/Frameworks/RSSKit.framework/Versions/Current/libRSSKit.so
lrwxrwxrwx 1 yavor yavor   69 юли 21 19:01 libRSSKit.so.0 -
./GNUstep/Frameworks/RSSKit.framework/Versions/Current/libRSSKit.so.0
lrwxrwxrwx 1 yavor yavor   71 юли 21 19:02 libRSSKit.so.0.4 -
./GNUstep/Frameworks/RSSKit.framework/Versions/Current/libRSSKit.so.0.4
lrwxrwxrwx 1 yavor yavor   69 юли 21 19:02 libRSSKit.so.5 -
./GNUstep/Frameworks/RSSKit.framework/Versions/Current/libRSSKit.so.5

libRSSKit.so.0 is a broken symlink.  As a result applications that linked with
RSSKit cannot be started.

$ ls -l /tmp/foo/usr/lib/GNUstep/Frameworks/RSSKit.framework/Versions/
общо 4
drwxr-xr-x 4 yavor yavor 4096 юли 21 19:02 5
lrwxrwxrwx 1 yavor yavor1 юли 21 19:02 Current - 5

There should be a 0 directory there with the old library.

Would you accept a patch that stops deleting the installed framework and also
creates symlinks directly to Versions/$ver instead of Versions/Current?  The
.so symlink must probably still point to Current for projects linking with an
internal framework to continue to work.

___

Reply to this item at:

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

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep