Bug#934718: switcheroo-control: Failed to start Switcheroo Control Proxy service

[Eric Heintzmann]

Package: switcheroo-control
Version: 1.2-2
Severity: important

Dear Maintainer,

Switcheroo does not start.

I tried, without success:
$ systemctl restart switcheroo-control

Here is the output of journalctl -xe:

août 14 01:07:20 ARRAKIS systemd[1]: Starting Switcheroo Control Proxy
service...
-- Subject: L'unité (unit) switcheroo-control.service a commencé à démarrer
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- L'unité (unit) switcheroo-control.service a commencé à démarrer.
août 14 01:07:20 ARRAKIS switcheroo-cont[4510]: switcheroo-control could not
query vga_switcheroo status: Operation not permitted
août 14 01:07:20 ARRAKIS systemd[1]: switcheroo-control.service: Main process
exited, code=exited, status=1/FAILURE
-- Subject: Unit process exited
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- An ExecStart= process belonging to unit switcheroo-control.service has
exited.
--
-- The process' exit code is 'exited' and its exit status is 1.
août 14 01:07:20 ARRAKIS systemd[1]: switcheroo-control.service: Failed with
result 'exit-code'.
-- Subject: Unit failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- The unit switcheroo-control.service has entered the 'failed' state with
result 'exit-code'.
août 14 01:07:20 ARRAKIS systemd[1]: Failed to start Switcheroo Control Proxy
service.
-- Subject: L'unité (unit) switcheroo-control.service a échoué
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- L'unité (unit) switcheroo-control.service a échoué, avec le résultat failed.

Best regards

PS
I cannot read the switch file:
$ sudo cat /sys/kernel/debug/vgaswitcheroo/switch
cat: /sys/kernel/debug/vgaswitcheroo/switch: Opération non permise



-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (300, 'unstable'), (50, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8),
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages switcheroo-control depends on:
ii  libc6 2.28-10
ii  libglib2.0-0  2.61.2-1

switcheroo-control recommends no packages.

switcheroo-control suggests no packages.

Bug#883583: [Debian GNUstep maintainers] Bug#883583: gnustep-gui-runtime: GSCUPS bundle crashes applications on CUPS client hosts

[Eric Heintzmann]

Le 05/12/2017 à 14:38, Yavor Doganov a écrit :
> Unfortunately stable is also affected because gnustep-gui/0.25.0-4 was
> rebuilt for the imagemagick transition in January 2017 and was built
> against recent cups which has the function deprecated.
>
> Eric, do we want to fix this now or we could delay it for 0.26?  Do we
> want to fix it in stretch?
>
Let's wait this week-end for the new -gui release.

For stretch, I would like to fix this bug. (I just need to check if I
have uploading rights on stable)

Bug#879738: transition: gnustep-base

[Eric Heintzmann]

On Tue, 31 Oct 2017 22:05:41 +0200 Yavor Doganov  wrote:
> clone 879738 -1
> reassign -1 gnustep-gui-runtime/0.25.0-4
> retitle -1 gnustep-gui-runtime: Depends on gnustep-back0.25
> severity -1 serious
> thanks
>
> Emilio Pozuelo Monfort wrote:
> > On 30/10/17 17:19, Yavor Doganov wrote:
> > > 1.25.0-2 is built and installed on all arches; please schedule the
> > > binNMUs at your earliest convenience. Thanks.
> >
> > Done.
>
> Thanks, but it looks like the transition is held by a bug in
> gnustep-gui: gnustep-gui-runtime depends on gnustep-back0.25 while it
> shouldn't. libgnustep-gui-dev is pulling in -runtime and because
> -back is not binNMUed yet, it still depends on libgnustep-base1.24 so
> the Build-Depends of all packages build-depending on
> libgnustep-gui-dev cannot be satisfied.
> Classic "Catch 22" scenario.
>
> The bug was introduced in gnustep-gui/0.25.0-1 during the migration to
> modern debhelper but was not really visible before the removal of the
> .symbols files in 0.25.0-4 (the shlibs were unused until then).
>
> We'll need a sourceful upload of gnustep-gui fixing this issue in
> order to proceed with the transition.
>
> @Eric:
> In fact this is fixed in master, but how do we proceed with the
> repository now that there are lots of changes in master intended for
> experimental? We have to prepare an upload fixing only this bug.

I think we can ignore the git repo for this upload (and import manually
the changes and the changelog entry in the next upload).
Except if you see a better option

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

[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

[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

[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#830137: transition: gnustep-gui

[Eric Heintzmann]

Le 06/07/2016 à 22:59, Emilio Pozuelo Monfort a écrit :
> Control: tags -1 confirmed
>
> On 06/07/16 13:35, Eric Heintzmann wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: transition
>>
>> New upstream gnustep-gui/back bumps SONAME (change of ABI without change
>> in API)
>> , so we need to transition.
>>
>> Now with gnustep-gui/back 0.25.0 in experimental,
>> we can start transition the existing GNUstep packages to the archive.
> You can upload to unstable.
gnustep-gui 0.25.0-2 and gnustep-back 0.25.0-2 have been uploaded in
unstable

Thanks
Eric

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

[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

[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&suite=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#830137: transition: gnustep-gui

[Eric Heintzmann]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

New upstream gnustep-gui/back bumps SONAME (change of ABI without change
in API)
, so we need to transition.

Now with gnustep-gui/back 0.25.0 in experimental,
we can start transition the existing GNUstep packages to the archive.

The following source packages need to be rebuilt:

  edenmath.app
  adun.app
  zipper.app
  wrapperfactory.app
  volumecontrol.app
  viewpdf.app
  timemon.app
  textedit.app
  terminal.app
  talksoup.app
  systempreferences.app
  steptalk
  renaissance
  projectcenter.app
  price.app
  preview.app
  popplerkit.framework
  poe.app
  plopfolio.app
  paje.app
  mpdcon.app
  lynkeos.app
  lusernet.app
  helpviewer.app
  gworkspace
  gtamsanalyzer.app
  grr.app
  gridlock.app
  gorm
  gomoku.app
  gnustep-examples
  gnustep-sqlclient
  gnustep-dl2
  aclock.app
  gnumail.app
  ftp.app
  etoile
  cynthiune.app
  charmap.app
  cenon.app
  camera.app
  batmon.app
  agenda.app
  affiche
  addresses-for-gnustep


Ben file:

title = "gnustep-gui";
is_affected = .build-depends ~ "libgnustep-gui-dev"  | .depends ~
"libgnustep-
gui0.24" | .depends ~ "libgnustep-gui0.24-dbg" | .depends ~ "libgnustep-
gui0.25" | .depends ~ "libgnustep-gui0.25-dbg";
is_good = .depends ~ "libgnustep-gui0.25" | .depends ~ "libgnustep-
gui0.25-dbg";
is_bad = .depends ~ "libgnustep-gui0.24" | .depends ~
"libgnustep-gui0.24-dbg";

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

[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

[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

[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 -Wl,--as

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

[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

[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#824262: RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep build system

[Eric Heintzmann]

Hi Gianfranco,


Le 16/05/2016 15:16, Gianfranco Costamagna a écrit :
> Hi Eric,
>
> nice indeed, so please wait some more time, and ping me back in 7-15 days if 
> nobody
> picked up the work in the meanwhile.
>
>
Iain R. Learmonth has uploaded gnustep-make.

Thanks to you for helping me to improve gnustep-make packaging.

Eric

Bug#824262: RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep build system

[Eric Heintzmann]

oops !  accidentally removed gsdh_gnustep symlinks !
Fixed and reuploaded

add this line to changelog

  * Provide a new debian/gnustep-make.links.

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

Bug#824262: RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep build system

[Eric Heintzmann]

Hi

Le 17/05/2016 11:52, Gianfranco Costamagna a écrit :
>
>
> Depends: gnustep-common (>= ${source:Version}),
> gnustep-common (<< ${source:Version}.1~),
> gobjc,
> -autotools-dev,
> ${misc:Depends},
> -${gnustep:Depends}
> +${perl:Depends}
> +Replaces: gnustep-common (<< 2.6.8-1)
> +Breaks: gnustep-common (<< 2.6.8-1)
>
>
>
> seems fine [1], just two questions: why did you drop gnustep:Depends?
What is the second question ?

Thanks
Eric

Bug#824262: RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep build system

[Eric Heintzmann]

Le 17/05/2016 19:27, Eric Heintzmann a écrit :
> Hi,
> Reuploaded !

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

or

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



Updated changelog:

gnustep-make (2.6.8-1) unstable; urgency=low

  * Team upload.
  * In agreement with the Debian GNUstep maintainers,
add myself as new Co-Maintainer.
  * New upstream version
  * Remove patches applied upstream:
+ honor-CFLAGS.patch
+ info-document-missing-direntry.patch
+ library-combo-whatis-entry.patch
+ manpage-spelling-errors.patch
+ test-clean-core.patch
+ texi-section-level.patch
  * Update no-gzip-timestamps.patch.
  * Update use-makeinfo.patch.
  * Bump Standards-Version to 3.6.8 in debian/control.
  * Set debhelper compatibility level to 9.
  * Update Vcs-* fields in debian/control
  * Rewrite debian/rules:
+ Use dh $@ --with autoreconf and --buiddirectory
+ No more use autotools-dev: drop dependencies
+ Disable strict gnustep-make version 2 mode for now
+ Build and install doc in *-indep sequence (Closes: #823281, #806197)
+ Use --with-layout=debian in configure scripts:
  - remove fhs-system-includedir.patch
  - remove obsolete {gnustep:Depends} var in debian/control
+ Remove debian/control.in file, useless now
+ Remove debian/fhs/gnustep-common.disr.in, now useless
+ Remove debian/fhs/gnustep-common.links.in, now useless
+ Remove debian/gnustep-make.dirs.in, now useless
  * Provide a new debian/clean file.
  * Update debian/copyright file.
  * Update debian/watch file to version 4.
  * Replace debian/upstream/signig-key.pgp by signing-key.asc:
remove debian/source/include-binaries file.
  * Provide a new debian/gnustep-make-doc.install file.
  * Provide a new debian/gnustep-make-doc.info file.
  * Rename debian/gnustep-make-doc.doc-base to
debian/gnustep-make-doc.doc-base.gnustep-make.
  * Provides new debian/gnustep-make-doc.doc-base.* files.
  * Provide a new debian/gnustep-make.install file.
  * Provide a new debian/gnustep-make.lintian-overrides file.
  * Provide a new debian/gnustep-make.manpages file:
remove debian/gnustep-test.1 file, useless now.
  * Provide a new debian/gnustep-make.docs file.
  * Rename debian/fhs dir to debian/dh_gnustep.
  * gnustep-make now Depends on {perl:Depends}
  * New debian/addons dir:
+ remove debian/gs_make.in and debian/config.mk.in, now useless
+ new gs_make and config.mk files in debian/addons dir
+ move debian/gs_make.1 to debian/addons dir
  * Remove debian/gnustep-make.dirs.in, useless now.
  * Provide a new debian/gnustep-common.maintscript file.
  * Provide a new debian/gnustep-common.install file.
  * Provide a new debian/gnustep-common.manpages file.
  * Provide a new debian/gnustep-common.docs file.
  * Provide a new debian/gnustep-common.dirs file.
  * Provide a new debian/gnustep-common.links file.
  * Provide a new debian/gnustep-common.lintian-overrides file.
  * Move gnustep-config.1 manpage to gnustep-make package:
gnustep-make now Replaces and Breaks gnustep-common (<<2.6.8-1).

 -- Eric Heintzmann   Tue, 03 May 2016 22:13:30
+0200

Bug#824262: RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep build system

[Eric Heintzmann]

Hi,
Reuploaded !

Le 17/05/2016 18:58, Eric Heintzmann a écrit :
>
>
> Le 17/05/2016 11:52, Gianfranco Costamagna a écrit :
>> Hi,
>>> switch to autoreconf done
>>
>> nice!
>>
>> little nitpick before answering to the open points:
>> * debian/patches/manpage-spelling-errors.patch: New, fix two spelling
>> +
>> errors.
>>
>>
>> there is a new space in changelog
>> (pull-debian-source gnustep-make debdiff of the two dsc files, filterdiff 
>> the debian changes, you will
>> see it)
>>
> Fixed, thanks
>
>
>>> Breaks + Replace done
>> Depends: gnustep-common (>= ${source:Version}),
>> gnustep-common (<< ${source:Version}.1~),
>> gobjc,
>> -autotools-dev,
>> ${misc:Depends},
>> -${gnustep:Depends}
>> +${perl:Depends}
>> +Replaces: gnustep-common (<< 2.6.8-1)
>> +Breaks: gnustep-common (<< 2.6.8-1)
>>
>>
>>
>> seems fine [1], just two questions: why did you drop gnustep:Depends?
>  Let see at dh_gnustep manpage:
>
> "dh_gnustep is a program based on debhelper that is responsible for
> doing GNUstep-specific modifications, such as moving files in the
> GNUstep hierarchy within the System domain, rooted at
>  /usr/lib/GNUstep/System, to Filesystem Hierarchy Standard
> (FHS)-compliant locations."
>
> it is obsoleted by configure option --with-layout=debian
> And I have no perl skills to update it.
>
>
> Let s look again at dh_gnustep manpage:
>
> "GNUstep dependencies:
> Adds any extra dependencies needed for GNUstep.  Currently, the
> only dependency added is to ensure that the package uses the same
> filesystem layout as the other GNUstep packages installed on the
> system."
>
> In reality {gnustep:Depends} just add a dependencies to virtual package
> provided by gnustep-common: gnustep-fslayout-fhs
> Of course I can add a dependency to gnustep-fslayout-fhs,
> but since gnustep-make depends on latest gnustep-common,
> it is not needed.
>
> I will update changelog like that:
>
> + Use --with-layout=debian in configure scripts:
>   - remove fhs-system-includedir.patch
>   - remove obsolete {gnustep:Depends} var in debian/control
>> [1] 
>> http://debomatic-amd64.debian.net/distribution#unstable/gnustep-make/2.6.8-1/piuparts
>
> Thanks for the link
>
> Thanks,
> Eric
>
>
>
>

Bug#824262: RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep build system

[Eric Heintzmann]

Le 17/05/2016 11:52, Gianfranco Costamagna a écrit :
> Hi,
>> switch to autoreconf done
>
>
> nice!
>
> little nitpick before answering to the open points:
> * debian/patches/manpage-spelling-errors.patch: New, fix two spelling
> +
> errors.
>
>
> there is a new space in changelog
> (pull-debian-source gnustep-make debdiff of the two dsc files, filterdiff the 
> debian changes, you will
> see it)
>
Fixed, thanks


>> Breaks + Replace done
>
> Depends: gnustep-common (>= ${source:Version}),
> gnustep-common (<< ${source:Version}.1~),
> gobjc,
> -autotools-dev,
> ${misc:Depends},
> -${gnustep:Depends}
> +${perl:Depends}
> +Replaces: gnustep-common (<< 2.6.8-1)
> +Breaks: gnustep-common (<< 2.6.8-1)
>
>
>
> seems fine [1], just two questions: why did you drop gnustep:Depends?
 Let see at dh_gnustep manpage:

"dh_gnustep is a program based on debhelper that is responsible for
doing GNUstep-specific modifications, such as moving files in the
GNUstep hierarchy within the System domain, rooted at
 /usr/lib/GNUstep/System, to Filesystem Hierarchy Standard
(FHS)-compliant locations."

it is obsoleted by configure option --with-layout=debian
And I have no perl skills to update it.


Let s look again at dh_gnustep manpage:

"GNUstep dependencies:
Adds any extra dependencies needed for GNUstep.  Currently, the
only dependency added is to ensure that the package uses the same
filesystem layout as the other GNUstep packages installed on the
system."

In reality {gnustep:Depends} just add a dependencies to virtual package
provided by gnustep-common: gnustep-fslayout-fhs
Of course I can add a dependency to gnustep-fslayout-fhs,
but since gnustep-make depends on latest gnustep-common,
it is not needed.

I will update changelog like that:

+ Use --with-layout=debian in configure scripts:
  - remove fhs-system-includedir.patch
  - remove obsolete {gnustep:Depends} var in debian/control
>
> [1] 
> http://debomatic-amd64.debian.net/distribution#unstable/gnustep-make/2.6.8-1/piuparts

Thanks for the link

Thanks,
Eric

Bug#824262: RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep build system

[Eric Heintzmann]

Hi,

Le 16/05/2016 21:15, Gianfranco Costamagna a écrit :
> Hi Eric,
>
>
> As you wish, you can switch in a later upload, or do it now and maybe
> fix/revert in case of troubles 

switch to autoreconf done

> I don't think so, but I can review a patch/package, because some lines
> without their context have no meaning (you need to put the
> breaks+replaces in the right binary package). 

Breaks + Replace done

>> OK, I'm going to update gnustep make to do improvements you suggested.
>> Since I am not familiar with mentors rules, I have a question :
>> Should I prepare a new revision (ie 2.6.8-2) or should I update the
>> 2.6.8-1 revision and reupload it ?
>
> please upload -1 revision until it gets sponsored!

OK I've just reuploaded gnustep-make 2.6.8-1

Changes:

Updated changelog
Updated control file
Remove all debian/*/*.in files

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


Changelog:

gnustep-make (2.6.8-1) unstable; urgency=low

  * Team upload.
  * In agreement with the Debian GNUstep maintainers,
add myself as new Co-Maintainer.
  * New upstream version
  * Rremove patches applied upstream:
+ honor-CFLAGS.patch
+ info-document-missing-direntry.patch
+ library-combo-whatis-entry.patch
+ manpage-spelling-errors.patch
+ test-clean-core.patch
+ texi-section-level.patch
  * Update no-gzip-timestampss.patch.
  * Update use-makeinfo.patch.
  * Bump Standards-Version to 3.6.8 in debian/control.
  * Set debhelper combatibility level to 9.
  * Update Vcs-* fields in debian/control
  * Remove no more needed {gnustep:Depends} var in debian/control.
  * Rewrite debian/rules:
+ Use dh $@ --with autotools-dev and --buiddirectory
+ No more use autotools-dev: drop dependencies
+ Disable strict gnustep-make version 2 mode for now
+ Build and install doc in *-indep sequence (Closes: #823281, #806197)
+ Use --with-layout=debian in configure scripts:
  remove fhs-system-includedir.patch
+ Remove debian/control.in file, useless now
+ Remove debian/fhs/gnustep-common.disr.in, now useless
+ Remove debian/fhs/gnustep-common.links.in, now useless
+ Remove debian/gnustep-make.dirs.in, now useless
  * Provide a new debian/clean file.
  * Update debian/copyright file.
  * Update debian/watch file to version 4.
  * Replace debian/upstream/signig-key.pgp by signing-key.asc:
remove debian/source/include-binaries file.
  * Provide a new debian/gnustep-make-doc.install file.
  * Provide a new debian/gnustep-make-doc.info file.
  * Rename debian/gnustep-make-doc.doc-base to
debian/gnustep-make-doc.doc-base.gnustep-make.
  * Provides new debian/gnustep-make-doc.doc-base.* files.
  * Provide a new debian/gnustep-make.install file.
  * Provide a new debian/gnustep-make.lintian-overrides file.
  * Provide a new debian/gnustep-make.manpages file:
remove debian/gnustep-test.1 file, useless now.
  * Provide a new debian/gnustep-make.docs file.
  * Rename debian/fhs dir to debian/dh_gnustep.
  * gnustep-make now Depends on {perl:Depends}
  * New debian/addons dir:
+ remove debian/gs_make.in and debian/config.mk.in, now useless
+ new gs_make and config.mk files in debian/addons dir
+ move debian/gs_make.1 to debian/addons dir
  * Remove debian/gnustep-make.dirs.in, useless now.
  * Provide a new debian/gnustep-common.maintscript file.
  * Provide a new debian/gnustep-common.install file.
  * Provide a new debian/gnustep-common.manpages file.
  * Provide a new debian/gnustep-common.docs file.
  * Provide a new debian/gnustep-common.dirs file.
  * Provide a new debian/gnustep-common.links file.
  * Provide a new debian/gnustep-common.lintian-overrides file.
  * Move gnustep-config.1 manpage to gnustep-make package:
gnustep-make now Replaces: and Breaks gnustep-common (<<2.6.8-1).

 -- Eric Heintzmann   Tue, 03 May 2016 22:13:30
+0200

Bug#824262: RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep build system

[Eric Heintzmann]

Hi Gianfranco,

Le 16/05/2016 21:15, Gianfranco Costamagna a écrit :
> Hi Eric,
>
>
>> I think there are too many changes in this release.
>> Is it okay to remove autoreconf for now,
>> and replace autotools-dev by autoreconf at next release ?
>
> it is, just a side note: I never had issues with that move, and in general 
> issues
> arises when: the configure/Makefiles are patched (because you obviously need 
> to patch
> configure.ac and Makefile.am instead), or bad config.guess/config.sub files
> (and usually the result is a build failure on some ports).
>
> As you wish, you can switch in a later upload, or do it now and maybe 
> fix/revert in
> case of troubles
Finally, I'm going to swith to autoreconf now.
>> Reorg: gnustep-common and gnustep-make existed; move one file from
>> gnustep-common to gnustep-make; new gnustep-common does not require new
>> gnustep-make
>> Breaks: gnustep-make (<<2.6.8-1)  
>> Breaks: gnustep-common (<<2.6.8-1)
>>
>> Is it okay to do that?
>
> I don't think so, but I can review a patch/package, because some lines 
> without their
> context have no meaning (you need to put the breaks+replaces in the right 
> binary
> package).
Finally, I reflected and I think we should not mix different version of
gnustep-make and gnustep-common binary packages.
It is unsupported by upstream andI could lead to strange  bugs.

gnustep-common will Breaks: gnustep-make (<< {source:Version})
and
gnustep-make will Depends: gnustep-common(>= {source:Version}

It should prevents the mix of versions and thus Break or Replaces are
now useless

Thanks
Eric



signature.asc
Description: OpenPGP digital signature

Bug#824262: RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep build system

[Eric Heintzmann]

Le 16/05/2016 15:16, Gianfranco Costamagna a écrit :
> Hi Eric,
>
>
>
>> Well autotools-dev already used. No changes here.
>> About autoreconf, I'm not familiar with it.
>> I installed it to test it. Since all seems ok, I've not removed it.
>
> https://wiki.debian.org/Autoreconf
>
> I was talking more about removing autotools-dev
I think there are too many changes in this release.
Is it okay to remove autoreconf for now,
and replace autotools-dev by autoreconf at next release ?
>
>
> 3) +Replaces: gnustep-common (<< 2.6.8-1)
>
> this is something I don't understand.
> If you upgrade gnustep make bin package with old gnustep-common installed,
> we need to replace the gnustep-config.1 manpage.
>
>
> that file is currently inside gnustep-common
>
> and you moved into gnustep-make
> https://packages.debian.org/sid/alpha/gnustep-common/filelist
Yes, the executable was in gnustep-make, thus i moved the manpage to
gnustep-make.

>
> you probably need some more keywords to ensure a good upgrade path
> https://wiki.debian.org/PackageTransition

Reorg: gnustep-common and gnustep-make existed; move one file from
gnustep-common to gnustep-make; new gnustep-common does not require new
gnustep-make
   
Breaks: gnustep-make (<<2.6.8-1)
   
Breaks: gnustep-common (<<2.6.8-1)

Is it okay to do that?

>> Yes, this is a consequence of the debian/rules rewriting.
>
> line 25, you could add something like "remove control.in file, useless now"
> or similar wording, that one was my question
OK, i m going to do that
>
>> I tested it with latest upstream version of gnustep-base, gnustep-gui
>> and and gnustep-back,
>> and all seems okay. I
>> tried it with several GNUstep related debian packages and all seems to
>> works fine.
>> I also tried to rebuild several debian gnustep packages with it and I
>> did not find any FTBFS.
>
> nice indeed, so please wait some more time, and ping me back in 7-15 days if 
> nobody
> picked up the work in the meanwhile.

OK, I'm going to update gnustep make to do improvements you suggested.
Since I am not familiar with mentors rules, I have a question :
Should I prepare a new revision (ie 2.6.8-2) or should I update the
2.6.8-1 revision and reupload it ?

Thanks

Eric

Bug#824262: RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep build system

[Eric Heintzmann]

>> also, the control.in file removal is not documented I guess
> Yes, this is a consequence of the debian/rules rewriting.
I mean I've removed control target in debian/rules file,
thus I removed control.in which was not needed any longer.

Thanks
Eric

Bug#824262: Fwd: Re: gnustep-make ack

[Eric Heintzmann]

Ack from Gurkan.
Yavor doesn't reply to email.

 Message transféré 
Return-Path:gur...@phys.ethz.ch
Received:   from zimbra89-e15.priv.proxad.net (LHLO
zimbra89-e15.priv.proxad.net) (172.20.243.140) by
zimbra89-e15.priv.proxad.net with LMTP; Mon, 16 May 2016 13:52:13 +0200
(CEST)
Received:   from phd-imap.ethz.ch (mx15-g26.priv.proxad.net
[172.20.243.85]) by zimbra89-e15.priv.proxad.net (Postfix) with ESMTP id
BFD2E3085DC for ; Mon, 16 May 2016 13:52:12
+0200 (CEST)
Received:   from phd-imap.ethz.ch ([129.132.80.51]) by mx1-g20.free.fr
(MXproxy) with ESMTPS for heintzmann.e...@free.fr (version=TLSv1/SSLv3
cipher=AES256-GCM-SHA384 bits=256); Mon, 16 May 2016 13:52:09 +0200 (CEST)
X-ProXaD-SC:state=HAM score=0
Received:   from localhost (phd-mailscan.ethz.ch [192.168.127.2]) by
phd-imap.ethz.ch (Postfix) with ESMTP id 3r7f2h1CwNzjc2 for
; Mon, 16 May 2016 13:52:12 +0200 (CEST)
X-Virus-Scanned:Debian amavisd-new at phys.ethz.ch
Received:   from phd-mxin.ethz.ch ([IPv6::::192.168.127.53]) by
localhost (phd-mailscan.ethz.ch [:::192.168.127.2]) (amavisd-new,
port 10024) with LMTP id fFYxFNg-qXuB for ;
Mon, 16 May 2016 13:52:12 +0200 (CEST)
Received:   from [10.0.1.14] (84-73-61-124.dclient.hispeed.ch
[84.73.61.124]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256
bits)) (No client certificate requested) (Authenticated sender:
gur...@phd-mxin.ethz.ch) by phd-mxin.ethz.ch (Postfix) with ESMTPSA id
3r7f2h0CRBzQ50 for ; Mon, 16 May 2016 13:52:12
+0200 (CEST)
From:   Gürkan Myczko 
Content-Type:   text/plain; charset=utf-8
Content-Transfer-Encoding:  quoted-printable
Mime-Version:   1.0 (1.0)
Subject:Re: gnustep-ameke ack
Message-Id: <4397053c-73d5-4402-adc6-8f5c8fa5f...@phys.ethz.ch>
Date:   Mon, 16 May 2016 13:52:11 +0200
References: <5739ae33.40...@free.fr>
In-Reply-To:<5739ae33.40...@free.fr>
To: Eric Heintzmann 
X-Mailer:   iPhone Mail (13F68)



Hi eric

I am glad if you do so, thank you!

Gürkan


> On May 16, 2016, at 13:25, Eric Heintzmann  wrote:
> 
> Hi Gurkan,
> 
> Can you give an ack to add myself as uploader of gnustep-make ? At:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824262
> 
> Thanks
> 
> Eric
> 

Bug#824262: RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep build system

[Eric Heintzmann]

Le 16/05/2016 12:40, Gianfranco Costamagna a écrit :
> control: tags -1 moreinfo
>
> Hi Eric, some questions on the changes:
> 1) why do you need both autotools-dev and autoreconf?
Well autotools-dev already used. No changes here.
About autoreconf, I'm not familiar with it.
I installed it to test it. Since all seems ok, I've not removed it.

>
> 2) did you get an ack from maintainers to add yourself as uploader
Yes.
In addition, I've just asked them to post their ask on this list now.

>
>
> 3) +Replaces: gnustep-common (<< 2.6.8-1)
>
> this is something I don't understand.
 If you upgrade gnustep make bin package with old gnustep-common installed,
 we need to replace the gnustep-config.1 manpage.


>
> also, the control.in file removal is not documented I guess
Yes, this is a consequence of the debian/rules rewriting.
>
> maybe Aron (ccd), being the latest sponsor might give you an additional 
> review and sponsor the package

Thanks for the tip.


>
> thanks for the really nice work! 
Thanks, I worked hard last week with upstream.
> I did a test build and the build logs looks good to be, as well as the built
> binaries (however I didn't install them).
I tested it with latest upstream version of gnustep-base, gnustep-gui
and and gnustep-back,
 and all seems okay. I
 tried it with several GNUstep related debian packages and all seems to
works fine.
 I also tried to rebuild several debian gnustep packages with it and I
did not find any FTBFS.

Eric

Bug#824262: RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep build system

[Eric Heintzmann]

Le 15/05/2016 03:26, Adam Borowski a écrit :
> On Sun, May 15, 2016 at 03:04:37AM +0200, Eric Heintzmann wrote:
>> Le 15/05/2016 02:46, Adam Borowski a écrit :
>>> On Sat, May 14, 2016 at 12:39:16PM +0200, Eric Heintzmann wrote:
>>>>   I am looking for a sponsor for my package "gnustep-make"
>>>>
>>>>  * Package name: gnustep-make
>>>>Version : 2.6.8-1
>>>>
>>>> dget -x 
>>>> https://mentors.debian.net/debian/pool/main/g/gnustep-make/gnustep-make_2.6.8-1.dsc
>>> As there's LOADS of packaging changes, could you please push them to a VCS? 
>>> That'd make reviewing greatly easier.  From the new changelog I assume you
>>> used git, I just don't see anything new past 2.6.6-3 on any branches on
>>> pkg-gnustep/gnustep-make.git.
>> Sorry, but I've not used git nor any VCS because I work all alone
>> since I am the last active member of the Debian GNUstep maintainers.
>> If I had knew that make reviewing easier, I would have used Git.
>> If you want I can push my changes on pkg-gnustep/gnustep-make.git
>> but there will be only one big commit.
>> Sorry, I ve done a mistake how can I repair it ?
> Oif.  I guess trying to split this big commit would be far more work than
> just reviewing it the hard way, so there's nothing that can be done here.
> That's unfortunate as it raises the difficulty of review considerably.
>
> As gnustep-make is a complex package I'm not familiar with, I'm afraid
> I'll leave it to someone with more time and experience.
>
I think I can split this big commit in multiple commits, one for each file.
If needed I will do it.

Thanks

Bug#824262: RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep build system

[Eric Heintzmann]

Le 15/05/2016 02:46, Adam Borowski a écrit :
> Hi!
>
> On Sat, May 14, 2016 at 12:39:16PM +0200, Eric Heintzmann wrote:
>>   I am looking for a sponsor for my package "gnustep-make"
>>
>>  * Package name: gnustep-make
>>Version : 2.6.8-1
>>
>> dget -x 
>> https://mentors.debian.net/debian/pool/main/g/gnustep-make/gnustep-make_2.6.8-1.dsc
> As there's LOADS of packaging changes, could you please push them to a VCS? 
> That'd make reviewing greatly easier.  From the new changelog I assume you
> used git, I just don't see anything new past 2.6.6-3 on any branches on
> pkg-gnustep/gnustep-make.git.

Sorry, but I've not used git nor any VCS because I work all alone
since I am the last active member of the Debian GNUstep maintainers.
If I had knew that make reviewing easier, I would have used Git.
If you want I can push my changes on pkg-gnustep/gnustep-make.git
but there will be only one big commit.
Sorry, I ve done a mistake how can I repair it ?

Thanks

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

[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

[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#824262: RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep build system

[Eric Heintzmann]

Package: sponsorship-requests
Severity: important

  Dear mentors,

  I am looking for a sponsor for my package "gnustep-make"

 * Package name: gnustep-make
   Version : 2.6.8-1
   Upstream Author : GNUstep Maintainer 
 * URL : http://gnustep.org
 * License : GPL-3+
   Section : gnustep

  It builds those binary packages:

 gnustep-common - Common files for the core GNUstep environment
 gnustep-make - GNUstep build system
 gnustep-make-doc - Documentation for GNUstep Make

  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:

  
gnustep-make (2.6.8-1) unstable; urgency=low
 .
   * Team upload.
   * Add myself as new Co-Maintainer.
   * New upstream version
   * Rremove patches applied upstream:
 + honor-CFLAGS.patch
 + info-document-missing-direntry.patch
 + library-combo-whatis-entry.patch
 + manpage-spelling-errors.patch
 + test-clean-core.patch
 + texi-section-level.patch
   * Update no-gzip-timestampss.patch.
   * Update use-makeinfo.patch.
   * Bump Standards-Version to 3.6.8 in debian/control.
   * Set debhelper combatibility level to 9.
   * Update Vcs-* fields in debian/control
   * Remove no more needed {gnustep:Depends} var in debian/control.
   * Rewrite debian/rules:
 + Use dh $@ --with autotools-dev, autoreconf and buiddirectory
 + Disable strict gnustep-make version 2 mode for now
 + Build and install doc in *-indep sequence (Closes: #823281, #806197)
 + Use --with-layout=debian in configure scripts:
   remove fhs-system-includedir.patch
   * Provide a nex debian/clean file.
   * Update debian/copyright file.
   * Update debian/watch file to version 4.
   * Replace debian/upstream/signig-key.pgp by signing-key.asc:
 remove debian/source/include-binaries file.
   * Provide a new debian/gnustep-make-doc.install file.
   * Provide a new debian/gnustep-make-doc.info file.
   * Rename debian/gnustep-make-doc.doc-base to
 debian/gnustep-make-doc.doc-base.gnustep-make.
   * Provides new debian/gnustep-make-doc.doc-base.* files.
   * Provide a new debian/gnustep-make.install file.
   * Provide a new debian/gnustep-make.lintian-overrides file.
   * Provide a new debian/gnustep-make.manpages file.
   * Provide a new debian/gnustep-make.docs file.
   * Rename debian/fhs dir to debian/dh_gnustep.
   * New debian/addons dir: move gs_make and config.mk to it.
   * Update debian/gnustep-common.dirs and debian/gnustep-common.links.
   * Provide a new debian/gnustep-common.maintscript file.
   * Provide a new debian/gnustep-common.install file.
   * Provide a new debian/gnustep-common.manpages file.
   * Provide a new debian/gnustep-common.docs file.
   * Move gnustep-config.1 manpage to gnustep-make package:
 gnustep-make now Replaces: gnustep-common (<< 2.6.8-1).


  Regards,
   Eric Heintzmann

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

[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#823249: RFS: camera.app/0.8.0-10 [RC] -- GNUstep application for digital still cameras

[Eric Heintzmann]

Package: sponsorship-requests
  Severity: important

 Dear mentors,

  I am looking for a sponsor for my package "camera.app"

 * Package name: camera.app
   Version : 0.8.0-10
   Upstream Author : Stefan Kleine Stegemann 
 * URL : http://home.gna.org/gsimageapps/
 * License : GPL-2.0+
   Section : gnustep

  It builds those binary packages:

camera.app - GNUstep application for digital still cameras

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

  https://mentors.debian.net/package/camera.app


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

dget -x 
https://mentors.debian.net/debian/pool/main/c/camera.app/camera.app_0.8.0-10.dsc


  Changes since the last upload:

   * Team upload, in harmony with Gürkan,:
 - move Debian GNUstep maintainer to Maintainer field,
 - move Gürkan to Uploaders field,
 - Add myself as new Co-Maintainer.
   * Bump debhelper compat to 9.
   * Upgrade to source format 3.0 (quilt).
   * Bump Standards-Version to 3.9.8.
   * Add Vcs-Browser and Vcs-Git fields.
   * Update gnustep Build-Depends.
   * Update libgphoto2-dev Build-Depends.
   * Add ${misc:Depends} to Depends field.
   * Update Description field.
   * Reformat debian/copyright file.
   * Provide a new debian/watch file.
   * Rewrite debian/rules:
 overrides 2 GNUmakefile.preamble variables (Closes: #820707).
   * Update debian/Camera.desktop file (Closes: #618456)
 and install it using debian/install file.
   * According with lintian and #741573 don't install menu file any longer.
   * According to debian policy 9.1.1, move
 /usr/lib/GNUstep/Applications/Camera.app/Resources dir
 to /usr/share/GNUstep/Camera.app:
 - use debian/install file,
 - use dh_symlink and dpkg-maintainer-script (and thus add dependency
   to dpkg (>= 1.17.4)) to create symlink from old to new locations.
   (provide new camera.app.links and new camera.app.maintscript files).


  Regards,
   Eric Heintzmann

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

[Eric Heintzmann]

On Mon, 16 Nov 2015 13:19:39 +0100 Eric Heintzmann 
 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#805201: [Debian GNUstep maintainers] Bug#805201: gnumail: FTBFS: /usr/bin/ld: cannot find -lAddresses

[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#607527: Fwd: Re: Stefan Potyra

[Eric Heintzmann]

 Message transféré 
Return-Path:sistp...@ubuntu.com
Received: 	from zimbra89-e15.priv.proxad.net (LHLO 
zimbra89-e15.priv.proxad.net) (172.20.243.140) by 
zimbra89-e15.priv.proxad.net with LMTP; Fri, 13 Nov 2015 20:42:52 +0100 
(CET)
Received: 	from faui3es.informatik.uni-erlangen.de 
(mx24-g26.priv.proxad.net [172.20.243.94]) by 
zimbra89-e15.priv.proxad.net (Postfix) with ESMTP id 349012CE48C for 
; Fri, 13 Nov 2015 20:42:52 +0100 (CET)
Received: 	from faui3es.informatik.uni-erlangen.de ([131.188.33.16]) by 
mx1-g20.free.fr (MXproxy) for heintzmann.e...@free.fr; Fri, 13 Nov 2015 
20:42:52 +0100 (CET)

X-ProXaD-SC:state=HAM score=0
Received: 	from faui30f (faui30f [131.188.33.49]) by 
faui3es.informatik.uni-erlangen.de (8.14.4/8.14.4/Debian-4) with ESMTP 
id tADJgplf029841 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 
verify=NOT) for ; Fri, 13 Nov 2015 20:42:51 +0100
Received: 	from potyra by faui30f with local-rmail (Exim 4.72) 
(envelope-from ) id 1ZxKFH-0004WE-Rj for 
heintzmann.e...@free.fr; Fri, 13 Nov 2015 20:42:51 +0100
Received: 	from potyra by suut.fritz.box with local (Exim 4.86) 
(envelope-from ) id 1ZxKFG-Mi-Lf for 
heintzmann.e...@free.fr; Fri, 13 Nov 2015 20:42:50 +0100

Date:   Fri, 13 Nov 2015 20:42:50 +0100
From:   Stefan Potyra 
To: Eric Heintzmann. 
Subject:Re: Stefan Potyra 
Message-ID: <20151113194250.ga1...@suut.lan>
References: <563bec05.1050...@free.fr> <2015210522.ga4...@suut.lan>
MIME-Version:   1.0
Content-Type:   text/plain; charset=us-ascii
Content-Disposition:inline
In-Reply-To:<2015210522.ga4...@suut.lan>
User-Agent: Mutt/1.5.24 (2015-08-30)



Hi Eric,

addresses-for-gnustep was synced and built without problems.
Thanks for the hint and for your work on the Debian package!

Cheers,
  Stefan.

Bug#805019: gworkspace: new upstream version available

[Eric Heintzmann]

Package: gworkspace.app
Severity: normal

Dear Maintainers,

GWorkspace 0.9.3 is available.
(I can prepare a package)

Thanks
Eric



-- System Information:
Debian Release: stretch/sid
  APT prefers testing-updates
  APT policy: (910, 'testing-updates'), (900, 'testing'), (400, 'unstable'), 
(10, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#804256: lintian: false positive postrm-should-call-ldconfig

[Eric Heintzmann]

Le 12/11/2015 21:06, Adam D. Barratt a écrit :

On Thu, 2015-11-12 at 20:54 +0100, Eric Heintzmann wrote:

Le 12/11/2015 12:45, Eric Heintzmann. a écrit :

Hi,

I have a false positive too with new gworkspace package:

http://eh666.free.fr/GNUstep/temp/gworkspace.app_0.9.3-1_amd64.deb

There is a trigger added by dh_makeshlibs too.


other binaries and source package are available at:
http://eh666.free.fr/GNUstep/temp/index.php

( there are other false positives too:
* spelling-error-in-binary
* package-contains-broken-symlink
* hardening-no-fortify-functions )

This bug report is about a specific issue,
I ve posted here because gworkspace has a false positive: 
postrm-should-call-ldconfig

Sorry if it was no clear.


  which is already fixed in

thanks

Bug#804256: lintian: false positive postrm-should-call-ldconfig

[Eric Heintzmann]

Le 12/11/2015 12:45, Eric Heintzmann. a écrit :

Hi,

I have a false positive too with new gworkspace package:

http://eh666.free.fr/GNUstep/temp/gworkspace.app_0.9.3-1_amd64.deb

There is a trigger added by dh_makeshlibs too.


other binaries and source package are available at:
http://eh666.free.fr/GNUstep/temp/index.php

( there are other false positives too:
* spelling-error-in-binary
* package-contains-broken-symlink
* hardening-no-fortify-functions )

thanks
Eric

Bug#804256: lintian: false positive postrm-should-call-ldconfig

[Eric Heintzmann.]

Hi,

I have a false positive too with new gworkspace package:

http://eh666.free.fr/GNUstep/temp/gworkspace.app_0.9.3-1_amd64.deb

There is a trigger added by dh_makeshlibs too.

Thanks
Eric

Bug#607527: Stefan Potyra

[Eric Heintzmann.]

Hi,

addresses-for-gnustep fails to build from source, if --as-needed is used as a
linker flag [1,2]. The reason is that --as-needed enforces a strict ordering
(symbol users in front of symbol definitions).

Attached is a patch that fixes the problem by sorting out the libraries from
_LDFLAGS into _OBJC_LIBS (the latter is added after the object files for
linking).

Cheers,
  Stefan.


Hi stephan,

Could you retry to build addresses-for-gnustep with latest version in 
sid/unstable (0.4.8-1), please ?

Thanks

Bug#699014: [Pkg-amule-devel] Bug#699014: Bug#699014: Migrate from GConf to GSettings

[Eric Heintzmann]

Le dim. 27/01/2013 17:02, Sandro Tosi a écrit :

On Sun, Jan 27, 2013 at 10:05 AM, Eric Heintzmann
 wrote:

I've already reported this bug upstream:
http://amule.forumer.com/port-from-gconf-to-gsettings-t2300205.html

They said they are not responsible for this bug.

I dig a bit deeper in it, and the package amule-gnome-support just
installs a schema file, and calls dh_gconf, which was originally
written in Ubuntu. I know nothing about it, so If you know how to
convert it to GSettings and what it needs to be done to install it and
make it visible on the GNOME de, then we can update it.

Cheers,
--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

There is also dh_installgsettings:
http://manpages.ubuntu.com/manpages/precise/en/man1/dh_installgsettings.1.html


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#699014: [Pkg-amule-devel] Bug#699014: Bug#699014: Migrate from GConf to GSettings

[Eric Heintzmann]

Le dim. 27/01/2013 17:02, Sandro Tosi a écrit :

On Sun, Jan 27, 2013 at 10:05 AM, Eric Heintzmann
 wrote:

I've already reported this bug upstream:
http://amule.forumer.com/port-from-gconf-to-gsettings-t2300205.html

They said they are not responsible for this bug.

I dig a bit deeper in it, and the package amule-gnome-support just
installs a schema file, and calls dh_gconf, which was originally
written in Ubuntu. I know nothing about it, so If you know how to
convert it to GSettings and what it needs to be done to install it and
make it visible on the GNOME de, then we can update it.


I don't know too.
But there is an official porting guide:
http://developer.gnome.org/gio/stable/ch31.html


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#699014: [Pkg-amule-devel] Bug#699014: Migrate from GConf to GSettings

[Eric Heintzmann]

Le sam. 26/01/2013 17:55, Sandro Tosi a écrit :

>would you like to write a patch to port aMule GNOME support to
>GSettings? We can also send this patch upstream, which really likely
>appreciate it.



I've already reported this bug upstream:
http://amule.forumer.com/port-from-gconf-to-gsettings-t2300205.html

They said they are not responsible for this bug.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#699014: Migrate from GConf to GSettings

[Eric Heintzmann]

Package: amule-gnome-support
Version: 2.3.1-9

With GNOME 3.0 (april 2011), the GNOME Project decided to discontinue GConf.
It won't be maintained anymore: bugs and security holes will not be fixed.
Thus, amule-gnome-support shouldn't depend on GConf any longer.
Please, migrate to GSettings.
GStettings is the official GNOME replacement for GConf, and the GNOME 
project

is porting all of its applications to it:
https://live.gnome.org/GnomeGoals/GSettingsMigration

You will find the official from GConf to GSettings porting guide at:
http://developer.gnome.org/gio/stable/ch31.html

Bug#698032: Migrate from GConf to GSettings

[Eric Heintzmann]

Package: gkdebconf
Version: 1.2.68

With GNOME 3.0 (april 2011), the GNOME Project decided to discontinue GConf.
It won't be maintained anymore: bugs and security holes will not be fixed.
Thus, gkdebconfr shouldn't depend on GConf any longer.
Please, migrate to GSettings.
GStettings is the official GNOME replacement for GConf, and the GNOME project
is porting all of its applications to it:
https://live.gnome.org/GnomeGoals/GSettingsMigration

You will find the official from GConf to GSettings porting guide at:
http://developer.gnome.org/gio/stable/ch31.html


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#671780: What is planned about FreeDesktop XDG basedir specification for aptitude?

[Eric Heintzmann]

http://ploum.net/post/207-modify-your-application-to-use-xdg-folders
https://live.gnome.org/GnomeGoals/XDGConfigFolders
http://www.freedesktop.org/wiki/Specifications/basedir-spec


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#443186: xserver-xorg: Cannot start xserver

[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  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:

Bug#315280: Fixed in gworkspace 0.7.1

[Eric Heintzmann]

tags 315280 + fixed-upstream
stop

fixed in upstream CVS.

Enrico Sersale <[EMAIL PROTECTED]>> wrote:
>
>This works in 0.7.1.





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

Bug#315278: Fixed upstream

[Eric Heintzmann]

tags 315278 + fixed-upstream
stop

fixed in upstream CVS.

Enrico Sersale <[EMAIL PROTECTED]>> wrote:

Fixed on CVS.





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

Bug#315276: Fixed upstream

[Eric Heintzmann]

tags 315276 + fixed-upstream
stop

fixed in upstream CVS.

Enrico Sersale <[EMAIL PROTECTED]>> wrote:

Well, I've added to the dialog the count of the items you are about to 
recycle/move/copy/etc.
Now it is:

RECYCLER
Move (count) items from: /home/anton
to the Recycler?
 

And remember that you can always see the current selection in the Inspector...





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

Bug#315270: Fixed upstream

[Eric Heintzmann]

tags 315270 + fixed-upstream
stop

fixed in upstream CVS.

Enrico Sersale <[EMAIL PROTECTED]>> wrote:

Fixed on CVS.




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

Bug#315268: Fixed upstream

[Eric Heintzmann]

tags 315268 + fixed-upstream
stop

fixed in upstream CVS.

Enrico Sersale <[EMAIL PROTECTED]>> wrote:

I've fixed this but not in the way you suggest. Instead of the current 
selection, the icon represents the base path of the viewer that is 
miniaturized. This because using the selection has no sense in
the case of the spatial viewers. If a viewer is in spatial mode, the selection 
could be the base path of an other viewer window.




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

Bug#315267: Fixed upstream

[Eric Heintzmann]

tags 315267 + fixed-upstream
stop

fixed in upstream CVS.

Enrico Sersale <[EMAIL PROTECTED]>> wrote:

>From this point of wiew you are right. Fixed. Now GWorkspace supports multiple 
>viewers opened on / and remembers the contents of the shelfs.



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

Bug#315263: Won't fix

[Eric Heintzmann]

severity 315263 wishlist
tags 315263 + wontfix
stop

Not a bug. We don't need to fix it.


Anton Zinoviev > wrote:

GW can't do anything for this. If you create the directory from a terminal, for 
NSWorkspace "Foo.txt" will be a plain file.
But I've added an alert that shows up if you try to rename the directory "Foo" 
in "Foo.txt" with gworkspace. (This is the behaviour on OS X)






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

Bug#315262: Fixed upstream

[Eric Heintzmann]

tags 315262 + fixed-upstream
stop

fixed in upstream CVS.






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

Bug#315261: Allows arbitrary ascii codes in file names

[Eric Heintzmann]

tags 315261 + fixed-upstream
stop

fixed in upstream CVS.





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

Bug#205151: gworkspace: cannot copy

[Eric Heintzmann]

forwarded 205151 http://savannah.gnu.org/bugs/?func=detailitem&item_id=12477
stop

This bug has been forwarded to the upstream bugzilla:
http://savannah.gnu.org/bugs/?func=detailitem&item_id=12477

Don't hesitate to ask there.






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

Bug#327725: gnustep-make(GNU/k*BSD): FTBFS: out of date config.sub/config.guess

[Eric Heintzmann]

forwarded 327725 http://savannah.gnu.org/bugs/?func=detailitem&item_id=14502
quit

This bug has already been forwarded into the upstream bugzilla. Tag it
as forwarded.





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

Bug#327725: [Debian GNUstep maintainers] Bug#327725: gnustep-make(GNU/k*BSD): FTBFS: out of date config.sub/config.guess

[Eric Heintzmann]

Aurelien Jarno a écrit :

>Package: gnustep-make
>Version: 1.10.0-6
>Severity: important
>
>Hello,
>
>
>The current version of gnustep-make fails to build on GNU/kFreeBSD, 
>because of outdated config.guess and config.sub.
>
>The versions of config.guess and config.sub in gnustep-make are too
>old to correctly support Debian GNU/k*BSD.  A version is needed
>from this year, which is available in the autotools-dev packages
>that are in current sarge, and sid.
>  
>
Do you know if this bug is related to gnustep-make only ?
Or are gnustep-base, gnustep-gui and gnustep-back bugged too ?

Bug#315274: Menu is outside the screen when screen changes its resolution

[Eric Heintzmann]

tags 315274 + fixed-upstream
quit

Fixed in gnustep-gui 0.10.0 (Don't forget to close this bug when
packaging it)






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

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

[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'

[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#205151: [bug #12477] Alt Gr key generates ISO_Level3_Shift keysym

[Eric Heintzmann]

Adrian Robert wrote:
Follow-up Comment #1, bug #12477 (project gnustep):
I want to be sure I have this straight.  You set GSFirstAlternateKey to
'ISO_Level3_Shift' and it works, but if you DON'T set this and instead set
GSSecondAlternateKey to 'ISO_Level3_Shift', it doesn't?
 

Now it works.
--
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

[Eric Heintzmann]

Steve Langasek wrote:
Hi Eric,
 

Finally I think it's better to just not build the VCFViewer inspector.
Edit the Goodies/GNUmakefile file and remove this line :
VCFViewer  \
   

 

that's all.
   

According to the BTS, you're the maintainer of this package -- do you plan
to prepare an upload that fixes this bug?  Are you in need of a sponsor to
upload for you?
 

Uploaded (sponsored by Christian Marrillat) just before I receive your mail.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#304928: gworkspace: FTBFS on amd64: make_services: relocation error: make_services: undefined symbol: main

[Eric Heintzmann]

Kurt Roeckx wrote:
On Sun, Apr 17, 2005 at 02:32:03PM +0200, Eric Heintzmann wrote:
 

If you have gnustep-gui-common installed, could you try to type 
"make_services", and report what 's happening ?
   

# make_services
/usr/lib/GNUstep/System/Tools/make_services: relocation error: 
/usr/lib/GNUstep/System/Tools/make_services: undefined symbol: main
Gnustep-gui 0.9.5-1 should be available now on amd64.
Please, could update to it, and retry to type "make_services" ?
   Thanks, Eric
--
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

[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.
--
DARTS - Debian Archive Regression Test Suite
http://darts.alioth.debian.org/
Please note that this report has not been generated fully automatically.
DARTS just helped finding the problem.
 

Finally I think it's better to just not build the VCFViewer inspector.
Edit the Goodies/GNUmakefile file and remove this line :
VCFViewer  \
that's all.
   Eric

--
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

[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#304928: gworkspace: FTBFS on amd64: make_services: relocation error: make_services: undefined symbol: main

[Eric Heintzmann]

Kurt Roeckx wrote:
On Sun, Apr 17, 2005 at 11:59:18AM +0200, Eric Heintzmann wrote:
 

And it's not sure this is really a -base/gui/back version problem, this 
is just the first thing I thought.
   

Looking at an older build log it was tried with
libgnustep-base1.10-dev 1.10.1-3 too with the same result.  So I
don't think it's a problem related to the version.
 

Right, you have eliminated this possibility.
If you have gnustep-gui-common installed, could you try to type 
"make_services", and report what 's happening ?

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

Bug#304928: gworkspace: FTBFS on amd64: make_services: relocation error: make_services: undefined symbol: main

[Eric Heintzmann]

|reassign 304928 gnustep-gui-common
thank
|
Kurt Roeckx wrote:
On Sun, Apr 17, 2005 at 02:32:03PM +0200, Eric Heintzmann wrote:
 

If you have gnustep-gui-common installed, could you try to type 
"make_services", and report what 's happening ?
   

# make_services
/usr/lib/GNUstep/System/Tools/make_services: relocation error: 
/usr/lib/GNUstep/System/Tools/make_services: undefined symbol: main
Bug in gnustep-gui-common 0.9.4 (current upstream version is 0.9.5) 
reported on amd64 only.

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

Bug#304928: gworkspace: FTBFS on amd64: make_services: relocation error: make_services: undefined symbol: main

[Eric Heintzmann]

Kurt Roeckx wrote:
On Sat, Apr 16, 2005 at 11:49:05PM +0200, Eric Heintzmann wrote:
 

Well, you used latest gnustep base (1.10.2), but not latest 
gnustep-gui/back (0.9.4).
You should use -gui/back 0.9.5.
But of course they are not available in debian. I cannot upload them 
alone because I am not an official Debian Developer and Matthias Klose ( 
my sponsor and co-maintainer of GNUstep Core package) is on vacation.
   

So you're saying this is a general problem and really is an RC
bug?  Please adjust the severity as needed.
 

No, I mean that uses newest -base with old -gui is not tested ant not 
supported upstream. It should work but with untested stuff, you should 
expect troubles.

On i386, it build fine. It's probably an amd64 only bug, thus it's not 
an RC bug.
And it's not sure this is really a -base/gui/back version problem, this 
is just the first thing I thought.

There is also a new upstream version of gworkspace.
May I suggest that you try to define the relations between those
packages better so that such problems can be avoided in the
future.
 

Difficult, because upstream is unpredictable.
But usually, we don't upload new apps when core packages are not ready.
(gworkspace was uploaded before gnustep-base, it should have been built 
with -base 1.10.1 and not 1.10.2)

   Eric
But if you are a DD, and want to sponsor these 3 uploads ... the 
packages are ready.
   

I'm not DD.
 

If you know a DD who would want to sponsor these uploads ...
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#304928: gworkspace: FTBFS on amd64: make_services: relocation error: make_services: undefined symbol: main

[Eric Heintzmann]

Kurt Roeckx wrote:
On Sat, Apr 16, 2005 at 10:36:27PM +0200, Eric Heintzmann wrote:
Please, could you say us what version of gnustep-make, gnustep-base and 
gnustep-gui have been used to try to build gworkspace.

Setting up gnustep-make (1.10.0-5) ...
Setting up gnustep-base-common (1.10.2-1) ...
Setting up libgnustep-base1.10 (1.10.2-1) ...
Setting up gnustep-gui-common (0.9.4-4) ...
Setting up gnustep-ppd (1.0.0-4) ...
Setting up libgnustep-base1.10-dev (1.10.2-1) ...
Setting up libgnustep-gui0.9-dev (0.9.4-4) ...
Setting up libgnustep-gui0.9 (0.9.4-4) ...
Basicly, current sid.
Kurt
Well, you used latest gnustep base (1.10.2), but not latest 
gnustep-gui/back (0.9.4).
You should use -gui/back 0.9.5.
But of course they are not available in debian. I cannot upload them 
alone because I am not an official Debian Developer and Matthias Klose ( 
my sponsor and co-maintainer of GNUstep Core package) is on vacation.

But if you are a DD, and want to sponsor these 3 uploads ... the 
packages are ready.

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

Bug#304968: gnustep-base should not enter in sarge now

[Eric Heintzmann]

Package: gnustep-base
Severity: normal
Tags: sid

gnustep-base 1.10.2 should stay in sid untill gnustep-gui and gnustep-back are
ready to enter in sarge and all gnustep apps are successfully tested or rebuilt.
We want to keep sarge clean.

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (990, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-2-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


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

Bug#304928: gworkspace: FTBFS on amd64: make_services: relocation error: make_services: undefined symbol: main

[Eric Heintzmann]

Kurt Roeckx wrote:
Package: gworkspace
Version: 0.7.0-1
Severity: important
Hi,
Your package is failing to build on amd64 with the following
error:
gcc  -rdynamic-o thumbnailer.service/./thumbnailer ./shared_obj/main.o\
 -L/root/GNUstep/Library/Libraries 
-L/usr/local/lib/GNUstep/Local/Library/Libraries 
-L/usr/local/lib/GNUstep/Network/Library/Libraries 
-L/usr/lib/GNUstep/System/Library/Libraries -lgnustep-gui -lgnustep-gui 
-lgnustep-base -lpthread
-lobjc -lm
/usr/lib/GNUstep/System/Library/Makefiles/mkinstalldirs 
thumbnailer.service/Resources
(echo "{"; echo '  NOTE = "Automatically generated, do not edit!";'; \
  echo "  NSExecutable = \"thumbnailer\";"; \
  cat thumbnailerInfo.plist; \
  echo "}") >thumbnailer.service/Resources/Info-gnustep.plist ;\
if make_services --test thumbnailer.service/Resources/Info-gnustep.plist; then 
: ; else rm -f thumbnailer.service/Resources/Info-gnustep.plist; false; \
fi
make_services: relocation error: make_services: undefined symbol: main
make[4]: *** [thumbnailer.service/Resources/Info-gnustep.plist] Error 1
make[3]: *** [thumbnailer.all.service.variables] Error 2
make[3]: Leaving directory `/usr/src/gworkspace-0.7.0/Tools/thumbnailer'
make[2]: *** [internal-all] Error 2
make[2]: Leaving directory `/usr/src/gworkspace-0.7.0/Tools'
make[1]: *** [internal-all] Error 2
make[1]: Leaving directory `/usr/src/gworkspace-0.7.0'
make: *** [build-arch-stamp] Error 2

Kurt
Please, could you say us what version of gnustep-make, gnustep-base and 
gnustep-gui have been used to try to build gworkspace.

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

Bug#296977: [bugs #12478] GNUstep don't start on a VNC or qemu 8bit display

[Eric Heintzmann]

   Hi Paolo, hi Lars,
I applied Alexander's patch, and made a new gnustep-back package.
Please, could you test it and reports if it work (or not) ?
You will find the new gnustep-back package here:
http://eh666.free.fr/GNUstep/debian/tests/gnustep-back/
If you don't use i386 arch, you can easily rebuilt it using apt-src for 
example:

add this line to your /etc/apt/sources.list :
deb-src http://eh666.free.fr/ GNUstep/debian/tests/
cd to an empty dir then type:
apt-src install gnustep-back
apt-src build gnustep-back
and install the new package using dpkg
  Eric
Alexander Malmberg wrote:
Debian GNUstep maintainers wrote:
Paolo <[EMAIL PROTECTED]> reports:
I'm accessing a Sarge sys via a vnc session at 8bit, and all I got is:
[snip]
2005-02-26 06:59:40.000 GWorkspace[31699] Unrecognized color masks:
0007:0038:00c0 8

Another pixel format I never expected to see. :) Again, patch here:
http://web.telia.com/~u42308495/alex/back-art-pixel-formats-1.patch
has support, but needs testing. I'll commit it as soon as I hear that 
it works.

- Alexander Malmberg

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

Bug#291356: [Fwd: Re: gnustep-back: Log message not precise enough (fwd)]

[Eric Heintzmann]

tags + 291356 fixed-upstream
thank
 Original Message 
Subject: Re: gnustep-back: Log message not precise enough (fwd)
Date: Mon, 21 Mar 2005 15:07:01 -0700
From: Adam Fedor <[EMAIL PROTECTED]>
CC: bug-gnustep@gnu.org, Vincent Danjean <[EMAIL PROTECTED]>
Newsgroups: gmane.comp.lib.gnustep.bugs
References: <[EMAIL PROTECTED]>
On Feb 27, 2005, at 10:25 AM, Eric Heintzmann wrote:
Package: gnustep-back
Version: 0.9.4-2
Severity: normal
In Source/art/blit.m, there are two log messages :
  NSLog(@"Unrecognized color masks: %08x:%08x:%08x %i",
red_mask, green_mask, blue_mask, bpp);
  //NSLog(@"Attempting to use fallback code
  //(currently unimplemented). This will be 
_very_ slow!");
  NSLog(@"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.)");
It would be VERY useful if a reference to gnustep-back would be added 
in
these messages (or an email)

Well, I inserted a email address here to forward the report to.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#267909: FTBFS on kfreebsd-gnu

[Eric Heintzmann]

tags 267909 + fixed-upstream
thank

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

Bug#267909: FTBFS on kfreebsd-gnu

[Eric Heintzmann]

tags + 267909 fixed-upstream
thank
This bug is fixed in CVS upstream:
http://savannah.gnu.org/bugs/?func=detailitem&item_id=12316

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

Bug#299178: [Debian GNUstep maintainers] Bug#299178: gnustep-gui: FTBFS (amd64/gcc-4.0): array type has incomplete element type

[Eric Heintzmann]

tag 299178 |+ fixed-upstream|
thank
Bug fixed in upstream CVS by Richard Frith-Macdonald.
Thanks
Andreas Jochens wrote:
Package: gnustep-gui
Severity: normal
Tags: patch
When building 'gnustep-gui' on amd64 with gcc-4.0,
I get the following error:
gcc Functions.m -c \
 -MMD -MP -DGNUSTEP_INSTALL_PREFIX=/usr/lib/GNUstep/System -DGNUSTEP_TARGET_DIR=\".\" 
-DGNUSTEP_TARGET_CPU=\"x86_64\" -DGNUSTEP_TARGET_OS=\"linux-gnu\" 
-DLIBRARY_COMBO=\"gnu-gnu-gnu\" -DBACKEND_BUNDLE=1 -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../Headers/Additions -I../Headers -I./. -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/Functions.o
In file included from Functions.m:36:
../Headers/AppKit/NSGraphics.h:235: error: array type has incomplete element 
type
Functions.m:827: error: array type has incomplete element type
make[3]: *** [shared_obj/Functions.o] Error 1
With the attached patch 'gnustep-gui' can be compiled
on amd64 using gcc-4.0.
Regards
Andreas Jochens
diff -urN ../tmp-orig/gnustep-gui-0.9.4/Headers/AppKit/NSGraphics.h 
./Headers/AppKit/NSGraphics.h
--- ../tmp-orig/gnustep-gui-0.9.4/Headers/AppKit/NSGraphics.h   2003-09-20 
04:57:45.0 +0200
+++ ./Headers/AppKit/NSGraphics.h   2005-03-12 10:42:41.387659015 +0100
@@ -232,7 +232,7 @@
// Context information
APPKIT_EXPORT void NSCountWindowsForContext(int context, int *count);
-APPKIT_EXPORT void NSWindowListForContext(int context, int size, int list[][]);
+APPKIT_EXPORT void NSWindowListForContext(int context, int size, int **list);
APPKIT_EXPORT int NSGetWindowServerMemory(int context, int *virtualMemory, 
	   int *windowBackingMemory, 
	   NSString **windowDumpStream);
diff -urN ../tmp-orig/gnustep-gui-0.9.4/Source/Functions.m ./Source/Functions.m
--- ../tmp-orig/gnustep-gui-0.9.4/Source/Functions.m	2004-02-08 14:07:24.0 +0100
+++ ./Source/Functions.m	2005-03-12 10:43:45.414796253 +0100
@@ -824,7 +824,7 @@
}

void 
-NSWindowListForContext(int context, int size, int list[][])
+NSWindowListForContext(int context, int size, int **list)
{
// TODO
}

___
Debian GNUstep maintainers mailing list
[EMAIL PROTECTED]
http://lists.alioth.debian.org/mailman/listinfo/pkg-gnustep-maintainers
 


--
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

[Eric Heintzmann]

Lars Wirzenius wrote:
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.
 

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

I tried it with an 8-bit X server running under qemu. The results were
pretty much identical: neither GWorkspace nor Mines (the two GNUstep
programs I tried) would run. When I configured it to be a 24-bit screen,
Mines would run without problems.
If I understand correctly, this means all or many GNUstep program don't
work at all with an 8-bit display. Personally, I don't think this is a 
release critical problem, and possibly not even a bug, even though it is 
obviously quite annoying if that's the only thing you've got. Thus, I
would think the best way would be to assign this bug to the appropriate
GNUstep base package and lowering its severity to normal.

 

   Hi Lars,
Could try to run these commands ( not sure if you need to do that as 
user or as root ) on the machine where gworkspace is  installed:

. /usr/lib/GNUstep/System/Library/Makefiles/GNUstep.sh (there is space 
between . an / at the beginning)
defaults write NSGlobalDomain XWindowBufferUseXShm no

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

Bug#293802: Fixed in experimental

[Eric Heintzmann]

tags 293802 + fixed|-in-experimental|
thank||
Ok, tagged as "fixed-in-experimental"
   Thanks, Eric
Yavor Doganov wrote:
On 2005-02-24 22:35:12 +0200 Yavor Doganov <[EMAIL PROTECTED]> wrote:
- #293802: not fixed, but different behaviour. Now the application 
doesn't crash when switching to threaded view, but it doesn't show 
threads as well ;-)  However this might be a feature, it was 
discussed on the mailing lists so I have to read all about it.

I have tested this extensively with the experimental package; I've 
also read the whole mail archive of the gnumeil-users list so it seems 
"Thread arcs" is a feature, though a weird one.

Pls tag this bug as "fixed-in-experimental".
Sorry for the disturbance.

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

Bug#205151: gworkspace: cannot copy

[Eric Heintzmann]

[EMAIL PROTECTED] wrote:
Hi
My bug reports mixed somewhat different issues. I was complaining
that it did not worked with the mouse but back in those time the
edit menu copy was greyed out and Alt_c no shown . Out of luck i
tried the mouse as it was told it may work (i did not even know if it
was then).
However now that i rechecked this version, Alt_C is enough, but i
certainly enjoyed the copy mouse working .
Thanks for the information you gave in this report, i would never
have found out by myself the Alt_r issue .
Still an issue ...
I don't think the woody tag is right as i did not intend for woody
to support that (i used 0.5 from sid). Can you remove it (the
issue apply only to sid by now as it need a gworkspace with copy
support ) ?
 

This bug report has no woody tag (but #174095 has one).
Wontfix seems good as the report gives usefull information to resolve the
issue , though the issue cannot be fixed by the package itself
(maybe Preferences.app ?).
 

Yes, with preferences you can easily change the default settings.
Try to choose AltGr (XFree86 4.3+) as one of your First Alternate, it 
works perfectly here.

Thanks
Alban Browaeys
PS: On my xfree86(fr) (pc105) keyboard  alt_r is also
ISO_Level3_Shift.i I will try find out if it is the new
standard for Alt_r in xfree/xorg or  something specific to non us
keyboards. Maybe copy can be bound to iso_level3 on x 4.3 in
some automated way ...
 

If you find this info, send it here, and to upstream too
Eric
PS
There is a new release of GWorkspace : 0.7.0.
I'm going to package it.

--
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

[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

Bug#293802: (no subject)

[Eric Heintzmann]

Yavor Doganov a écrit :
I have imported the raw archive of gnumail-users mailing list (~1060 
messages) and GNUMail doesn't crash when switching to threaded view in 
this particular mailbox. However it still crashes alwasys when I do so 
in all my other mailboxes, and in my Inbox as well, where I have 
deliberately left messages with cyrillic headers.
Could it be connected with #293840 or I am missing something? I will 
test it thorougly these days.


   Hi Yagor,
Sorry to be late, but my computer has crashed, and I didn't find time to 
fix it.

Could you try gnumail and pantomime from debian experimental, to see if 
the bugs you have reported are fixed ?

   Eric