Bug#837010: gnustep-base: FTBFS: Tests failures

2016-09-08 Thread Eric Heintzmann 
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
>
> Relevant part (hopefully):
> > 
> > Testing NSXMLParser.m...
> > Running base/headers/NSXMLParser.m...
> > Passed test: NSXMLParser.m:9 ... include of Foundation/NSXMLParser.h 
> > works
> > Completed file:  NSXMLParser.m
> > 
> > Testing NSZone.m...
> > Running base/headers/NSZone.m...
> > Passed test: NSZone.m:9 ... include of Foundation/NSZone.h works
> > Completed file:  NSZone.m
> > 
> > Testing Unicode.m...
> > Running base/headers/Unicode.m...
> > Passed test: Unicode.m:9 ... include of GNUstepBase/Unicode.h works
> > Completed file:  Unicode.m
> > debian/rules:166: recipe for target 'override_dh_auto_test' failed
>
> The full build log is available from:
>
> http://people.debian.org/~lucas/logs/2016/09/06/gnustep-base_1.24.9-3_unstable.log
> 
I can't reproduce the issue (with pdebuild on amd64)
but looking at your build log, I see a problem with your date and time zone:

>base/NSCalendarDate/test00.m:
>Failed test: test00.m:107 ...
+dateWithString:calendarFormat:locale: handles Africa/Addis_Ababa
>Failed test: test00.m:246 ... date check with 2002-03-31 01:30:00
>Failed test: test00.m:261 ... date check with 2002-03-31 01:30:00
>Failed test: test00.m:265 ... date check with 2002-03-31 00:30:00
>Failed test: test00.m:422 ... date year calculation preserves timezone
>
>base/NSCalendarDate/test02.m:
>Failed test: test02.m:173 ... %Z format works in description
>Failed test: test02.m:177 ... %z format works in description
>Failed test: test02.m:197 ... %H%M format works in description
>
>base/NSDateFormatter/general.m:
>Failed test:   general.m:56 ... EST time zone is correctly
accounted for.
>
>
>base/NSTimeZone/create.m:
>Failed test: create.m:33 ... +timeZoneWithAbbreviation works
>Failed test: create.m:37 ... +timeZoneWithName works
>
>base/NSTimeZone/use.m:
>Failed test: use.m:57 ... can calculate next DST transition
>Failed test:   use.m:92 ... Returns correct Daylight Saving offset.
>Failed test:   use.m:95 ... Returns correct Daylight Saving offset.


>Failed test: test00.m:107 ...
+dateWithString:calendarFormat:locale: handles Africa/Addis_Ababa
>
>Failed test: test00.m:261 ... date check with 2002-03-31 01:30:00
>Failed test: test00.m:265 ... date check with 2002-03-31 00:30:00
>
>Failed test: test00.m:422 ... date year calculation preserves timezone
>
>Failed test: test02.m:173 ... %Z format works in description
>Failed test: test02.m:177 ... %z format works in description
>
>Failed test: test02.m:197 ... %H%M format works in description
>
>Failed test:   general.m:56 ... EST time zone is correctly
accounted for.
>
>Failed test: create.m:33 ... +timeZoneWithAbbreviation works
>Failed test: create.m:37 ... +timeZoneWithName works
>
>Failed test:   use.m:92 ... Returns correct Daylight Saving offset.
>Failed test:   use.m:95 ... Returns correct Daylight Saving offset.

There is also a recurrent message:

>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'.
>2016-09-06 23:03:53.983 runtime[30247:30247] Using time zone with
absolute offset 0.

Bug#835894: [Debian GNUstep maintainers] Bug#835894: terminal.app: crashes on startup: Did not find correct version of backend

2016-08-29 Thread Eric Heintzmann 

Well, it seems that teminal.app doesn't depends on gnustep-back package.

Instead it depends on libgnustep-gui0.25 which doesn't depends on 
gnustep-back.


I will look at this tomorrow

Eric


Le 29/08/2016 à 06:02, Adam Borowski a écrit :

Package: terminal.app
Version: 0.9.8-1+nmu1+b2
Severity: grave
Justification: renders package unusable

Hi!
I'm afraid terminal.app crashes at startup in unstable; this doesn't seem to
be related to my particular setup as the same happens on three different
machines (amd64, i386, armhf) with varied environments.

2016-08-29 05:12:57.421 Terminal[21768:21768] Did not find correct version
⤷of backend (libgnustep-back-025.bundle), falling back to std
⤷(libgnustep-back.bundle).
2016-08-29 05:12:57.425 Terminal[21768:21768] NSApplication.m:304  Assertion
⤷failed in initialize_gnustep_backend.  Unable to find backend back
Terminal: Uncaught exception NSInternalInconsistencyException, reason:
⤷NSApplication.m:304  Assertion failed in initialize_gnustep_backend.  Unable
⤷to find backend back



-- System Information:
Debian Release: stretch/sid
   APT prefers unstable-debug
   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(150, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.2-xfsreflink+ (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages terminal.app depends on:
ii  libc62.23-5
ii  libgnustep-base1.24  1.24.9-3
ii  libgnustep-gui0.25   0.25.0-3
ii  libobjc4 6.2.0-1

terminal.app recommends no packages.

terminal.app suggests no packages.

-- no debconf information

___
Debian GNUstep maintainers mailing list
pkg-gnustep-maintain...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-gnustep-maintainers

Bug#833755: [Debian GNUstep maintainers] Bug#833755: gnustep-base: FTBFS on buildds with gcc6/icu57

2016-08-16 Thread Eric Heintzmann 

Le 16/08/2016 à 23:40, peter green a écrit :

About a week ago you tagged this bug pending, any ETA on an upload?


The package is available at mentors:

https://mentors.debian.net/package/gnustep-base

Waiting for my sponsor, Iain R. Learmonth,  to upload it.

Eric

Bug#649419: [Debian GNUstep maintainers] Bug#649419: gnustep-base: FTBFS intermittently [amd64]: Hangs in base/NSOperation

2016-07-10 Thread Eric Heintzmann 


Le 10/07/2016 à 15:13, Emilio Pozuelo Monfort a écrit :
> On 10/07/16 12:53, Eric Heintzmann wrote:
>> If you have access to these machines, is it possible to see the
>> Tests/tests.log file ?
>> (Or at next build attempt)
> Sorry, I don't (and besides, the trees are removed when the build ends). You
> could try to build it on one of the porterboxes though.
Sadly, since I'm not an official DD or DM, I have no access to the
porterboxes.
>  Also you should make the
> package print that file upon failure.
Already done in debian/rules

override_dh_auto_test:
dh_auto_test -- \
messages=yes  || (cat Tests/tests.log; exit 1)

But it does not work where when it hangs.

>  If you use automake tests, you can do that
> with:
>
> export VERBOSE=1
>
> in your debian/rules.
Will try that locally first.
Thanks for the tip.

Maybe this patch can help (Richard ?):
https://github.com/gnustep/base/commit/6713bb48d6018c6f949a56128c07fea5f222d41f

Cheers,
Eric

Bug#649419: [Debian GNUstep maintainers] Bug#649419: gnustep-base: FTBFS intermittently [amd64]: Hangs in base/NSOperation

2016-07-10 Thread Eric Heintzmann 


Le 10/07/2016 à 12:10, Emilio Pozuelo Monfort a écrit :
> Control: severity -1 serious
>
> On Sun, 20 Nov 2011 12:09:35 -0800 Daniel Schepler  
> wrote:
>> Source: gnustep-base
>> Version: 1.22.1-2
>> Severity: important
>>
>> It seems that roughly 50% of the time, when I try to build gnustep-base 
>> here, 
>> I get:
>>
>> ...
>> --- Running tests in base/NSMutableString ---
>> --- Running tests in base/NSNumber ---
>> --- Running tests in base/NSNumberFormatter ---
>> --- Running tests in base/NSObject ---
>> --- Running tests in base/NSOperation ---
>>
>> and then it hangs here indefinitely.
> This happened in the last upload on i386 and kfreebsd.
>
> https://buildd.debian.org/status/package.php?p=gnustep-base=sidYes, I'm 
> aware of this bug.ince is 
Yes I'm aware of this bug.
Since it is a random bug, I hope next build attempts on these arch will
be successful.

>
> Are you building with sbuild locally?
I used pbuilder and pdebuild.
And, thanks to KVM and QEMU, I've successfully built locally
gnustep-base 0.24.9-2 on:
 amd64, i386, kfreebsd-i386, kfreebsd-amd64, hurd-i386 and s390x.

If you have access to these machines, is it possible to see the
Tests/tests.log file ?
(Or at next build attempt)


Thanks
Eric

Bug#827383: RFS: gmp-ecm/7.0.1+ds-2 [RC] -- Factor integers using the Elliptic Curve Method

2016-06-15 Thread Eric Heintzmann 


Le 15/06/2016 à 23:12, Jerome BENOIT a écrit :
> Hello Eric,
>
> On 15/06/16 20:57, Eric Heintzmann wrote:
>
>
> > Le 15/06/2016 à 16:41, Jerome Benoit a écrit :
> >> Package: sponsorship-requests
> >> Severity: serious
> >> Justification: fails to build from source (but built successfully
> in the past)
> >>
> >> Dear Sponsors,
> >>
> >> I am looking for sponsorship for the Debian package gmp-ecm
> [1], a mathematical package.
> >> This release mainly works around an unisolated gcc-5 issue for
> arch s390x which caused
> >> a FTBFS.
> >>
> > How did you fixed this issue ?
> > I would like to use you solution on gnustep-base.
>
> The lazy way. As it works well with gcc-6, the package is built with
> gcc-6 (only on s390x arch).
> See the git repository at Alitoh (and certainly sooner, the source
> material at Debian Sources).
Thanks for you quick answer.
In your changelogs you write about a not isolated gcc.
Is there a bug report somewhere (in debian, in gcc upstream ...)?

Thanks




signature.asc
Description: OpenPGP digital signature

Bug#827383: RFS: gmp-ecm/7.0.1+ds-2 [RC] -- Factor integers using the Elliptic Curve Method

2016-06-15 Thread Eric Heintzmann 


Le 15/06/2016 à 16:41, Jerome Benoit a écrit :
> Package: sponsorship-requests
> Severity: serious
> Justification: fails to build from source (but built successfully in the past)
>
> Dear Sponsors,
>
>   I am looking for sponsorship for the Debian package gmp-ecm [1], a 
> mathematical package.
>   This release mainly works around an unisolated gcc-5 issue for arch 
> s390x which caused
>   a FTBFS.
>
How did you fixed this issue ?
I would like to use you solution on gnustep-base.

Thanks
Eric

Bug#826592: [Debian GNUstep maintainers] Bug#826592: gnustep-gui: FTBFS: 22 Failed builds

2016-06-06 Thread Eric Heintzmann 
Yes, the tests failed to build.
This is because of the new version of gnustep-make.
But an upload of a new version of gnustep-gui is planned,
as soon as gnustep-base will be ready.

Le 06/06/2016 à 20:16, Chris Lamb a écrit :
> Source: gnustep-gui
> Version: 0.24.0-3.1
> Severity: serious
> Justification: fails to build from source
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: ftbfs
> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
>
> Dear Maintainer,
>
> gnustep-gui fails to build from source in unstable/amd64:
>
>   [..]
>
> if [ -f .//$l.lproj/$f -o -d .//$l.lproj/$f ]; then \
>   cp -fr .//$l.lproj/$f \
> ./StandardPicker.bundle/Resources/$l.lproj/; \
> else \
>   echo "Warning: .//$l.lproj/$f not found - ignoring"; \
> fi; \
>   done; \
> else \
>   echo "Warning: .//$l.lproj not found - ignoring"; \
> fi; \
>   done
>   echo "OLD_GNUSTEP_STAMP_ASTRING = _GSStandardColorPicker-" > 
> ./StandardPicker.bundle/stamp.make
>   (echo "{"; echo '  NOTE = "Automatically generated, do not edit!";'; \
> echo "  NSExecutable = \"StandardPicker\";"; \
> echo "  NSMainNibFile = \"\";"; \
> echo "  NSPrincipalClass = \"GSStandardColorPicker\";"; \
> echo "}") >StandardPicker.bundle/Resources/Info-gnustep.plist
>   if [ -r "" ]; then \
> plmerge StandardPicker.bundle/Resources/Info-gnustep.plist ; \
>   fi
>   Making all for bundle NamedPicker...
>   cd .; \
>   /usr/share/GNUstep/Makefiles/mkinstalldirs ./obj/NamedPicker.obj/
>   /usr/share/GNUstep/Makefiles/mkinstalldirs NamedPicker.bundle/.
>   gcc GSNamedColorPicker.m -c \
> -MMD -MP -Wdate-time -D_FORTIFY_SOURCE=2 -DGNUSTEP 
> -DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1 -DGNU_RUNTIME=1 
> -DGNUSTEP_BASE_LIBRARY=1 -fno-strict-aliasing -fexceptions -fobjc-exceptions 
> -D_NATIVE_OBJC_EXCEPTIONS -pthread -fPIC -Wall -DGSWARN -DGSDIAGNOSE 
> -Wno-import -g -O2 -fstack-protector-strong -Wformat -Werror=format-security 
> -g -O2 -fstack-protector-strong -Wformat -Werror=format-security 
> -fgnu-runtime -fconstant-string-class=NSConstantString -I../Headers/Additions 
> -I../Headers -I. -I/usr/local/include/GNUstep -I/usr/include/GNUstep \
>  -o obj/NamedPicker.obj/GSNamedColorPicker.m.o
>   gcc -shared  -rdynamic -Wl,-z,relro -Wl,-z,defs -Wl,--as-needed 
> -pthread  -fexceptions -o ./NamedPicker.bundle/./NamedPicker 
> ./obj/NamedPicker.obj/GSNamedColorPicker.m.o   -L../Source/./obj 
> -L../Models/./obj-L/usr/local/lib -L/usr/lib  -lgnustep-gui
> -lgnustep-base-lobjc   -lm
>   /usr/share/GNUstep/Makefiles/mkinstalldirs NamedPicker.bundle/Resources
>   for f in GSNamedColorPicker.tiff; do \
> if [ -f .//$f -o -d .//$f ]; then \
>   cp -fr .//$f ./NamedPicker.bundle/Resources/; \
> else \
>   echo "Warning: .//$f not found - ignoring"; \
> fi; \
>   done
>   echo "OLD_GNUSTEP_STAMP_ASTRING = _GSNamedColorPicker-" > 
> ./NamedPicker.bundle/stamp.make
>   (echo "{"; echo '  NOTE = "Automatically generated, do not edit!";'; \
> echo "  NSExecutable = \"NamedPicker\";"; \
> echo "  NSMainNibFile = \"\";"; \
> echo "  NSPrincipalClass = \"GSNamedColorPicker\";"; \
> echo "}") >NamedPicker.bundle/Resources/Info-gnustep.plist
>   if [ -r "" ]; then \
> plmerge NamedPicker.bundle/Resources/Info-gnustep.plist ; \
>   fi
>   Making all for bundle WheelPicker...
>   cd .; \
>   /usr/share/GNUstep/Makefiles/mkinstalldirs ./obj/WheelPicker.obj/
>   /usr/share/GNUstep/Makefiles/mkinstalldirs WheelPicker.bundle/.
>   gcc GSWheelColorPicker.m -c \
> -MMD -MP -Wdate-time -D_FORTIFY_SOURCE=2 -DGNUSTEP 
> -DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1 -DGNU_RUNTIME=1 
> -DGNUSTEP_BASE_LIBRARY=1 -fno-strict-aliasing -fexceptions -fobjc-exceptions 
> -D_NATIVE_OBJC_EXCEPTIONS -pthread -fPIC -Wall -DGSWARN -DGSDIAGNOSE 
> -Wno-import -g -O2 -fstack-protector-strong -Wformat -Werror=format-security 
> -g -O2 -fstack-protector-strong -Wformat -Werror=format-security 
> -fgnu-runtime -fconstant-string-class=NSConstantString -I../Headers/Additions 
> -I../Headers -I. -I/usr/local/include/GNUstep -I/usr/include/GNUstep \
>  -o obj/WheelPicker.obj/GSWheelColorPicker.m.o
>   gcc GSColorSliderCell.m -c \
> -MMD -MP -Wdate-time -D_FORTIFY_SOURCE=2 -DGNUSTEP 
> -DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1 -DGNU_RUNTIME=1 
> -DGNUSTEP_BASE_LIBRARY=1 -fno-strict-aliasing -fexceptions -fobjc-exceptions 
> -D_NATIVE_OBJC_EXCEPTIONS -pthread -fPIC -Wall -DGSWARN -DGSDIAGNOSE 
> -Wno-import -g -O2 -fstack-protector-strong -Wformat -Werror=format-security 
> -g -O2 -fstack-protector-strong -Wformat -Werror=format-security 
> -fgnu-runtime -fconstant-string-class=NSConstantString -I../Headers/Additions 
> -I../Headers -I. -I/usr/local/include/GNUstep -I/usr/include/GNUstep \
>  -o obj/WheelPicker.obj/GSColorSliderCell.m.o
>   gcc -shared  -rdynamic -Wl,-z,relro -Wl,-z,defs

Bug#825618: gnustep-dl2-postgresql-adaptor: fails to upgrade from wheezy to jessie to stretch: cannot switch directory to symlink

2016-05-28 Thread Eric Heintzmann 


Le 28/05/2016 à 17:08, Andreas Beckmann a écrit :
>> Le 28/05/2016 à 10:33, Andreas Beckmann a écrit :
>>>   dpkg-maintscript-helper: error: directory 
>>> '/usr/lib/GNUstep/Frameworks/PostgreSQLEOAdaptor.framework/Resources/LoginPanel.bundle/Resources'
>>>  contains files not owned by package gnustep-dl2-postgresql-adaptor:amd64, 
>>> cannot switch to symlink
>> witch files ?
>> Owned by what package ?
> # ls -la 
> /usr/lib/GNUstep/Frameworks/PostgreSQLEOAdaptor.framework/Resources/LoginPanel.bundle/Resources
> total 64
> drwxr-xr-x 2 root root80 May 28 14:52 .
> drwxr-xr-x 3 root root   100 May 28 14:52 ..
> -rw-r--r-- 1 root root   152 Apr 21  2013 Info-gnustep.plist
> -rw-r--r-- 1 root root 57916 Apr 21  2013 postgreslogo.tif
>
> # dpkg -S 
> /usr/lib/GNUstep/Frameworks/PostgreSQLEOAdaptor.framework/Resources/LoginPanel.bundle/Resources/*
> dpkg-query: no path found matching pattern 
> /usr/lib/GNUstep/Frameworks/PostgreSQLEOAdaptor.framework/Resources/LoginPanel.bundle/Resources/Info-gnustep.plist
> dpkg-query: no path found matching pattern 
> /usr/lib/GNUstep/Frameworks/PostgreSQLEOAdaptor.framework/Resources/LoginPanel.bundle/Resources/postgreslogo.tif
>
> # readlink -f 
> /usr/lib/GNUstep/Frameworks/PostgreSQLEOAdaptor.framework/Resources/LoginPanel.bundle/Resources
> /usr/lib/GNUstep/Frameworks/PostgreSQLEOAdaptor.framework/Versions/0/Resources/LoginPanel.bundle/Resources
>
> # ls -lad /usr/lib/GNUstep/Frameworks/PostgreSQLEOAdaptor.framework/Resources 
>  
> lrwxrwxrwx 1 root root 26 Apr 21  2013 
> /usr/lib/GNUstep/Frameworks/PostgreSQLEOAdaptor.framework/Resources -> 
> Versions/Current/Resources
>
> # ls -lad 
> /usr/lib/GNUstep/Frameworks/PostgreSQLEOAdaptor.framework/Versions/Current
>   
> lrwxrwxrwx 1 root root 1 Apr 21  2013 
> /usr/lib/GNUstep/Frameworks/PostgreSQLEOAdaptor.framework/Versions/Current -> > 0
>
> # dpkg -S 
> /usr/lib/GNUstep/Frameworks/PostgreSQLEOAdaptor.framework/Versions/0/Resources/LoginPanel.bundle/Resources/*
> gnustep-dl2-postgresql-adaptor: 
> /usr/lib/GNUstep/Frameworks/PostgreSQLEOAdaptor.framework/Versions/0/Resources/LoginPanel.bundle/Resources/Info-gnustep.plist
> gnustep-dl2-postgresql-adaptor: 
> /usr/lib/GNUstep/Frameworks/PostgreSQLEOAdaptor.framework/Versions/0/Resources/LoginPanel.bundle/Resources/postgreslogo.tif
>
> So you are applying the dir_to_symlink at the wrong path, since that is 
> already behind some symlink ...

OK, I think I see the problem.

I will repackage it as soon as GNUstep Core packages will be uploaded in
sid.
(I'm currently working on gnustep-gui)

Thanks for your help.

Eric

Bug#825618: gnustep-dl2-postgresql-adaptor: fails to upgrade from wheezy to jessie to stretch: cannot switch directory to symlink

2016-05-28 Thread Eric Heintzmann 
Hi

Thanks for your bug report.

But is it possible to have more info ?


Le 28/05/2016 à 10:33, Andreas Beckmann a écrit :
>   dpkg-maintscript-helper: error: directory 
> '/usr/lib/GNUstep/Frameworks/PostgreSQLEOAdaptor.framework/Resources/LoginPanel.bundle/Resources'
>  contains files not owned by package gnustep-dl2-postgresql-adaptor:amd64, 
> cannot switch to symlink

witch files ?
Owned by what package ?

Thanks

Eric

Bug#823281: gnustep-make: build-indep depends on binary-arch

2016-05-14 Thread Eric Heintzmann 


Le 14/05/2016 13:14, Eric Heintzmann a écrit :
> Hi,
>
> Le 03/05/2016 16:00, Santiago Vila a écrit :
>> On Tue, May 03, 2016 at 03:46:13PM +0200, Eric Heintzmann wrote:
>>> Thanks for this bug report and thanks for finding a solution.
>>>
>>> Anyway I plan to repackage the Core GNUstep packages (including
>>> gnustep-make),
>>> and rewriting debian/rules using dh_overrides_* targets.
>>> (If there are no objections from other Debian GNUstep Maintainers)
>>> It should solve these bugs.
>> You are welcome.
>>
>> I tried to find a solution, yes, but the current debian/rules was too
>> much convoluted and I never understood how it really worked.
>>
>> Rewriting it in "dh" seems a very good idea. Wish you luck.
>>
>> Thanks.
> The new gnustep-make package (2.6.8) is available at:
>
> https://mentors.debian.net/debian/pool/main/g/gnustep-make/gnustep-make_2.6.8-1.dsc
>
> It fixes this bug.
>
> Thanks
>

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/gnustep-make


  Alternatively, one can download the package with dget using this command:

dget -x
https://mentors.debian.net/debian/pool/main/g/gnustep-make/gnustep-make_2.6.8-1.dsc

  More information about GNUstep can be obtained from
http://gnustep.org/information/aboutGNUstep.html

  Changes since the last upload:

Bug#823281: [Debian GNUstep maintainers] Bug#823281: gnustep-make: build-indep depends on binary-arch

2016-05-14 Thread Eric Heintzmann 
Hi,

Le 03/05/2016 16:00, Santiago Vila a écrit :
> On Tue, May 03, 2016 at 03:46:13PM +0200, Eric Heintzmann wrote:
>> Thanks for this bug report and thanks for finding a solution.
>>
>> Anyway I plan to repackage the Core GNUstep packages (including
>> gnustep-make),
>> and rewriting debian/rules using dh_overrides_* targets.
>> (If there are no objections from other Debian GNUstep Maintainers)
>> It should solve these bugs.
> You are welcome.
>
> I tried to find a solution, yes, but the current debian/rules was too
> much convoluted and I never understood how it really worked.
>
> Rewriting it in "dh" seems a very good idea. Wish you luck.
>
> Thanks.
The new gnustep-make package (2.6.8) is available at:

https://mentors.debian.net/debian/pool/main/g/gnustep-make/gnustep-make_2.6.8-1.dsc

It fixes this bug.

Thanks

Bug#823281: [Debian GNUstep maintainers] Bug#823281: gnustep-make: build-indep depends on binary-arch

2016-05-03 Thread Eric Heintzmann 

Thanks for this bug report and thanks for finding a solution.

Anyway I plan to repackage the Core GNUstep packages (including 
gnustep-make),

and rewriting debian/rules using dh_overrides_* targets.
(If there are no objections from other Debian GNUstep Maintainers)
It should solve these bugs.

Thanks
Eric

Le 03/05/2016 02:07, Santiago Vila a écrit :

Package: src:gnustep-make
Version: 2.6.6-3
Severity: serious

Dear maintainer:

While investigating Bug #806197 I found the following policy
violations in debian/rules:


* The build target should depend on build-arch and build-indep.

Currently, it is like this:

# NOTE: The Build-Indep-Depends are only available, when building the
# build-indep packages.
build: build-arch # build-indep

Quoting policy speaking about build-arch and build-indep:

   The build target should either depend on those targets or take the
   same actions as invoking those targets would perform.

If I only install build-depends and not build-indep-depends, it follows
that I can only use the build-arch target, but that's *my* problem.

The build target should still build everything, for the case that I
install all the build-dependencies and want to build everything.


* The "build-indep" target depends indirectly on "binary-arch" (!).
This is what I see:

build-indep: debian/build-indep-stamp
clean_files += debian/build-indep-stamp
debian/build-indep-stamp: binary-arch


Well, binary-arch is where architecture-dependent .deb packages are
created (i.e. Arch: any). Quoting policy:

   The build-arch and build-indep targets must not do anything that
   might require root privilege.

Because actually creating .deb packages requires to be root (or fakeroot),
it follows that build-indep must *not* depend on any of the binary
targets.


This is probably the reason why "dpkg-buildpackage -A" fails (Bug #806197),
but I can't verify this easily because I don't have a fixed debian/rules.

Thanks.

___
Debian GNUstep maintainers mailing list
pkg-gnustep-maintain...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-gnustep-maintainers

Bug#805201: [Debian GNUstep maintainers] Bug#805201: gnumail: FTBFS: /usr/bin/ld: cannot find -lAddresses

2015-11-16 Thread Eric Heintzmann 



Le 15/11/2015 21:26, Chris West (Faux) a écrit :

Source: gnumail
Version: 1.2.2-1
Severity: serious
Justification: fails to build from source
Tags: sid
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-CC: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

The package fails to build:

gcc  -shared -Wl,-soname,libGNUMail.so.1  -rdynamic -Wl,-z,relro ... 
obj/GNUMail.obj/WelcomePanel.m.o   -L../   -L/usr/local/lib -L/usr/lib   -lobjc -lgnustep-base 
-lgnustep-gui -lPantomime -lAddresses -lAddressView -lm   && (cd ./GNUMail.framework/Versions/1/.; 
rm -f libGNUMail.so; if [ "libGNUMail.so.1" != "libGNUMail.so.1.2.2" ]; then rm -f 
libGNUMail.so.1; ln -s libGNUMail.so.1.2.2 libGNUMail.so.1; fi; ln -s libGNUMail.so.1 libGNUMail.so; ) || 
rm -f ./GNUMail.framework/Versions/1/./libGNUMail.so.1.2.2 ; \
(cd ./GNUMail.framework/Versions/1/.; \
   rm -f GNUMail; \
   ln -s libGNUMail.so GNUMail) \

/usr/bin/ld: cannot find -lAddresses
/usr/bin/ld: cannot find -lAddressView
collect2: error: ld returned 1 exit status
At first glance, there are strange problems of symlinks in 
libaddresses-dev and libddressview-dev packages.

I can correct the problems and prepare new packages( just need a sponsor).

Eric

Bug#805201: gnumail: FTBFS: /usr/bin/ld: cannot find -lAddresses

2015-11-16 Thread Eric Heintzmann 
On Mon, 16 Nov 2015 13:19:39 +0100 Eric Heintzmann 
<heintzmann.e...@free.fr> wrote:


> >
> > /usr/bin/ld: cannot find -lAddresses
> > /usr/bin/ld: cannot find -lAddressView
> > collect2: error: ld returned 1 exit status
> At first glance, there are strange problems of symlinks in
> libaddresses-dev and libddressview-dev packages.
> I can correct the problems and prepare new packages( just need a 
sponsor).

>
> Eric
>
>

 I've prepared new packages for addresses-for-gnustep
(see them at : http://eh666.free.fr/GNUstep/addresses-for-gnustep/index.php)
GNUMail seems to build fine against them.

Thanks
Eric

Bug#443186: xserver-xorg: Cannot start xserver

2007-09-19 Thread Eric Heintzmann 
Package: xserver-xorg
Version: 1:7.3+2
Severity: grave
Justification: renders package unusable



*** Please type your report below
this line ***
I've upgraded all my x.org packages
to version 7.3, and now I cannot
start anymore the X server. (I ve
tried with gdm and startx without
any success)
When trying to launch the X server,
after 2 or 3 seconds, it dies.
I ve tried to modify several time
xorg.conf file, and I've also tried
to remove xorg.conf file too, but it
doesn't work.

See the startx console output:



X.Org X Server 1.4.0
Release Date: 5 September 2007
X Protocol Version 11, Revision 0
Build Operating System: Linux Debian
(xorg-server 2:1.4-2)
Current Operating System: Linux
ARRAKIS 2.6.22-2-k7 #1 SMP Fri Aug
31 01:02:37 UTC 2007 i686
Build Date: 16 September 2007
02:37:21PM
 
Before reporting problems, check
http://wiki.x.org
to make sure that you have the
latest version.
Module Loader present
Markers: (--) probed, (**) from
config file, (==) default setting,
(++) from command line, (!!)
notice, (II) informational,
(WW) warning, (EE) error, (NI) not
implemented, (??) unknown.
(==) Log file:
/var/log/Xorg.0.log, Time: Wed Sep
19 01:18:49 2007
(==) Using config file:
/etc/X11/xorg.conf

(II) Module ddc already built-in
(II) Module i2c already built-in
(II) Module ramdac already
built-in
expected keysym, got
XF86KbdLightOnOff: line 70 of pc
expected keysym, got
XF86KbdBrightnessDown: line 71 of pc
expected keysym, got
XF86KbdBrightnessUp: line 72 of pc
expected keysym, got
XF86KbdLightOnOff: line 70 of pc
expected keysym, got
XF86KbdBrightnessDown: line 71 of pc
expected keysym, got
XF86KbdBrightnessUp: line 72 of pc
The XKEYBOARD keymap compiler
(xkbcomp) reports:
 Warning:  Type ONE_LEVEL
has 1 levels, but RALT has 2
symbols
   Ignoring extra
symbols
Errors from xkbcomp are not fatal to
the X server

Backtrace:
0: /usr/bin/X11/X(xf86SigHandler
+0x7e) [0x80c632e]
1: [0xe420]
2: /usr/lib/libpixman-1.so.0(pixman_image_composite+0x588) [0x4afdb4b8]
3: /usr/lib/xorg/modules//libfb.so(fbComposite+0x1ad) [0xb7c3486d]
4: /usr/lib/xorg/modules//libxaa.so(XAAComposite+0x224) [0xb7bfeca4]
5: /usr/lib/xorg/modules//libxaa.so
[0xb7c1a526]
6: /usr/bin/X11/X [0x816f8e3]
7: /usr/bin/X11/X(CompositePicture
+0x150) [0x8156c40]
8: /usr/bin/X11/X [0x815cc1f]
9: /usr/bin/X11/X [0x8159ad5]
10: /usr/bin/X11/X [0x814d24e]
11: /usr/bin/X11/X(Dispatch+0x2bf)
[0x808d00f]
12: /usr/bin/X11/X(main+0x48b)
[0x807461b]
13: /lib/i686/cmov/libc.so.6(__libc_start_main+0xe0) [0x4e622050]
14: /usr/bin/X11/X(FontFileCompleteXLFD+0x205) [0x8073991]

Fatal server error:
Caught signal 4.  Server aborting

xinit:  connection to X server lost.

X.Org X Server 1.4.0
Release Date: 5 September 2007
X Protocol Version 11, Revision 0
Build Operating System: Linux Debian (xorg-server 2:1.4-2)
Current Operating System: Linux ARRAKIS 2.6.22-2-k7 #1 SMP Fri Aug 31 01:02:37 UTC 2007 i686
Build Date: 16 September 2007  02:37:21PM
 
	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
Module Loader present
Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: /var/log/Xorg.0.log, Time: Wed Sep 19 01:18:49 2007
(==) Using config file: /etc/X11/xorg.conf
(==) ServerLayout Default Layout
(**) |--Screen Default Screen (0)
(**) |   |--Monitor B101920
(**) |   |--Device ATI Technologies Inc Radeon RV200 QW [Radeon 7500]
(**) |--Input Device Generic Keyboard
(**) |--Input Device Configured Mouse
(==) Automatically adding devices
(==) Automatically enabling devices
(WW) The directory /usr/share/fonts/X11/cyrillic does not exist.
	Entry deleted from font path.
(==) FontPath set to:
	/usr/share/fonts/X11/misc,
	/usr/share/fonts/X11/100dpi/:unscaled,
	/usr/share/fonts/X11/75dpi/:unscaled,
	/usr/share/fonts/X11/Type1,
	/usr/share/fonts/X11/100dpi,
	/usr/share/fonts/X11/75dpi,
	/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType
(==) RgbPath set to /etc/X11/rgb
(==) ModulePath set to /usr/lib/xorg/modules
(WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory)
(II) No APM support in BIOS or kernel
(II) Loader magic: 0x81d8680
(II) Module ABI versions:
	X.Org ANSI C Emulation: 0.3
	X.Org Video Driver: 2.0
	X.Org XInput driver : 2.0
	X.Org Server Extension : 0.3
	X.Org Font Renderer : 0.5
(II) Loader running on linux
(II) LoadModule: pcidata
(II) Loading /usr/lib/xorg/modules//libpcidata.so
(II) Module pcidata: vendor=X.Org Foundation
	compiled for 1.4.0, module version = 1.0.0
	ABI class: X.Org Video Driver, version 2.0
(--) using VT number 7

(II) PCI: PCI scan (all values are in hex)
(II) PCI: 00:00:0: chip 1106,3099 card 1043,8064 rev 00 class 06,00,00 hdr 00
(II) PCI: 00:01:0: chip 1106,b099 card , rev 00 class 06,04,00 hdr 01
(II) PCI: 00:05:0: chip 13f6,0111 card 1043,80e2 rev 10

Bug#307290: addresses-for-gnustep: FTBFS (testing): cannot find protocol declaration for `ContentViewersProtocol'

2005-05-03 Thread Eric Heintzmann 
Steve Langasek a écrit :
On Mon, May 02, 2005 at 08:03:55PM +0200, Eric Heintzmann wrote:
 

Package: addresses-for-gnustep
Version: 0.4.6-3
Severity: serious
Tags: sarge
When building 'addresses-for-gnustep' on i386/testing,
I get the following error:
gcc VCFViewer.m -c \
-MMD -MP -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1 
-DGNU_RUNTIME=1 -DGNUSTEP_BASE_LIBRARY=1 -D_REENTRANT -fPIC -DGSWARN 
-DGSDIAGNOSE -O2 -fno-strict-aliasing -fgnu-runtime -Wall 
-fconstant-string-class=NSConstantString 
-I/addresses-for-gnustep-0.4.6/Frameworks -I. -I/root/GNUstep/Library/Headers 
-I/usr/local/lib/GNUstep/Local/Library/Headers 
-I/usr/local/lib/GNUstep/Network/Library/Headers 
-I/usr/lib/GNUstep/System/Library/Headers \
 -o shared_obj/VCFViewer.o
In file included from VCFViewer.m:16:
VCFViewer.h:17:47: warning: GWorkspace/ContentViewersProtocol.h: No such file 
or directory
In file included from VCFViewer.m:16:
VCFViewer.h:25: error: cannot find protocol declaration for 
`ContentViewersProtocol'
make[3]: *** [shared_obj/VCFViewer.o] Error 1
With the attached patch, 'addresses-for-gnustep' can be compiled
on i386/testing. There is a new version of addresses-for-gnustep
in sid which already has this patch applied, but which will probably
not enter sarge because of #304968.
 

#304968 will be closed when gnustep-back will be a valid candidate (in 2 days).
   

gnustep-back is a valid candidate tomorrow; you ought to close this bug now.
 

What bug should I close now :
#304968 (gnustep-base)
or #307290 (addresses-for-gnustep)
or both ?
   Eric

Bug#307290: addresses-for-gnustep: FTBFS (testing): cannot find protocol declaration for `ContentViewersProtocol'

2005-05-02 Thread Eric Heintzmann 
Andreas Jochens wrote:

Package: addresses-for-gnustep
Version: 0.4.6-3
Severity: serious
Tags: sarge

When building 'addresses-for-gnustep' on i386/testing,
I get the following error:

gcc VCFViewer.m -c \
  -MMD -MP -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1 
 -DGNU_RUNTIME=1 -DGNUSTEP_BASE_LIBRARY=1 -D_REENTRANT -fPIC -DGSWARN 
 -DGSDIAGNOSE -O2 -fno-strict-aliasing -fgnu-runtime -Wall 
 -fconstant-string-class=NSConstantString 
 -I/addresses-for-gnustep-0.4.6/Frameworks -I. -I/root/GNUstep/Library/Headers 
 -I/usr/local/lib/GNUstep/Local/Library/Headers 
 -I/usr/local/lib/GNUstep/Network/Library/Headers 
 -I/usr/lib/GNUstep/System/Library/Headers \
   -o shared_obj/VCFViewer.o
In file included from VCFViewer.m:16:
VCFViewer.h:17:47: warning: GWorkspace/ContentViewersProtocol.h: No such file 
or directory
In file included from VCFViewer.m:16:
VCFViewer.h:25: error: cannot find protocol declaration for 
`ContentViewersProtocol'
make[3]: *** [shared_obj/VCFViewer.o] Error 1

With the attached patch, 'addresses-for-gnustep' can be compiled
on i386/testing. There is a new version of addresses-for-gnustep
in sid which already has this patch applied, but which will probably
not enter sarge because of #304968.


#304968 will be closed when gnustep-back will be a valid candidate (in 2 days).



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#305044: addresses-for-gnustep: FTBFS: GWorkspace/ContentViewersProtocol.h: No such file or directory

2005-04-17 Thread Eric Heintzmann 
Roland Stigge wrote:
Package: addresses-for-gnustep
Version: 0.4.6-3
Severity: serious
Hi,
building the package addresses-for-gnustep in a clean sid build environment
(with pbuilder) on i386 results in:
=
[...]
done
make[2]: Leaving directory 
`/tmp/buildd/addresses-for-gnustep-0.4.6/AddressManager'
make[1]: Leaving directory `/tmp/buildd/addresses-for-gnustep-0.4.6'
: # build Goodies
. /usr/lib/GNUstep/System/Library/Makefiles/GNUstep.sh; \
   ADDITIONAL_INCLUDE_DIRS= 
-I/tmp/buildd/addresses-for-gnustep-0.4.6/Frameworks \
   ADDITIONAL_LIB_DIRS= 
-L/tmp/buildd/addresses-for-gnustep-0.4.6/Frameworks/Addresses/Addresses.framework/Versions/Current
  
-L/tmp/buildd/addresses-for-gnustep-0.4.6/Frameworks/AddressView/AddressView.framework/Versions/Current
 \
   /usr/bin/make -C Goodies messages=yes
make[1]: Entering directory `/tmp/buildd/addresses-for-gnustep-0.4.6/Goodies'
Making all in VCFViewer...
make[2]: Entering directory 
`/tmp/buildd/addresses-for-gnustep-0.4.6/Goodies/VCFViewer'
Making all for bundle VCFViewer...
cd .; \
/usr/lib/GNUstep/System/Library/Makefiles/mkinstalldirs ./shared_obj; \
rm -f obj; \
ln -s ./shared_obj obj
/usr/lib/GNUstep/System/Library/Makefiles/mkinstalldirs VCFViewer.inspector/.
gcc VCFViewer.m -c \
 -MMD -MP -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1 
-DGNU_RUNTIME=1 -DGNUSTEP_BASE_LIBRARY=1 -D_REENTRANT -fPIC -DGSWARN 
-DGSDIAGNOSE -O2 -fno-strict-aliasing -fgnu-runtime -Wall 
-fconstant-string-class=NSConstantString 
-I/tmp/buildd/addresses-for-gnustep-0.4.6/Frameworks -I. 
-I/tmp/buildd/GNUstep/Library/Headers 
-I/usr/local/lib/GNUstep/Local/Library/Headers 
-I/usr/local/lib/GNUstep/Network/Library/Headers 
-I/usr/lib/GNUstep/System/Library/Headers \
  -o shared_obj/VCFViewer.o
In file included from VCFViewer.m:16:
VCFViewer.h:17:47: warning: GWorkspace/ContentViewersProtocol.h: No such file 
or directory
In file included from VCFViewer.m:16:
VCFViewer.h:25: error: cannot find protocol declaration for 
`ContentViewersProtocol'
make[3]: *** [shared_obj/VCFViewer.o] Error 1
make[2]: *** [VCFViewer.all.bundle.variables] Error 2
make[2]: Leaving directory 
`/tmp/buildd/addresses-for-gnustep-0.4.6/Goodies/VCFViewer'
make[1]: *** [internal-all] Error 2
make[1]: Leaving directory `/tmp/buildd/addresses-for-gnustep-0.4.6/Goodies'
make: *** [build-arch-stamp] Error 2
=
Thanks for considering.
 

Well, Gworkspace have been deeply changed. The headers are no longer at 
the place where addresses expect to find them.
I'll look and rebuild addresses at that when I will have upgraded 
gnustep core libraries and gworkspace (addresses build-depends on them).
In the meantime I suggest to not build the addresses-goodies package.

Comment these lines in debian/rules should suffice:
: # build Goodies
#   . /$(GS_MAKEFILES_DIR)/GNUstep.sh; \
#   ADDITIONAL_INCLUDE_DIRS=$(ADDITIONAL_INCLUDE_DIRS) \
#   ADDITIONAL_LIB_DIRS=$(ADDITIONAL_LIB_DIRS) \
#   $(MAKE) -C Goodies messages=yes
: # install Goodies
#   . /$(GS_MAKEFILES_DIR)/GNUstep.sh; \
#   $(MAKE) -C Goodies install \
#   GNUSTEP_INSTALLATION_DIR=$(CURDIR)/$(d_good)/$(GS_SYSTEM_ROOT)
   Eric
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#296977: gworkspace.app: GWorkspace doesn't start on a VNC 8bit display

2005-02-27 Thread Eric Heintzmann 
Paolo a écrit :
Package: gworkspace.app
Version: 0.6.5-3; reported 2005-02-26
Severity: grave
Justification: renders package unusable
 

It seems that it renders unusable remotly and not in all cases.
hello,
well, it *might* work smoothly indeed, but the fact is that I'm accessing 
a Sarge sys via a vnc session at 8bit, and all I got is:

2005-02-26 06:59:40.000 GWorkspace[31699] NOTE: Only one display per host fully 
supported.
2005-02-26 06:59:40.000 GWorkspace[31699] WARNING - XGServer is unable to use 
the fast algorithm for writing to an 8-bit display on this host - the most 
likely reason being the StandardColormap RGB_BEST_MAP has not been installed.
2005-02-26 06:59:40.000 GWorkspace[31699] Unrecognized color masks: 
0007:0038:00c0 8
2005-02-26 06:59:40.000 GWorkspace[31699] Please report this along with details 
on your pixel format (ie. the four numbers above). (Or better yet, implement it 
and send me a patch.)
which leaves me with no other choice but use anoter filemanager, hence the
severity.
-- paolo
 

I suspect this is a bug in gnustep-back and not in gworkspace itself.
Please, could test with another GNUstep apps (via vnc too) ?
Eric