from:"Yavor Doganov"

Hidden bugs in Objective-C packages due to language standard mismatch

2024-08-19 Thread Yavor Doganov

GCC 14 promoted certain warnings to errors but these do not affect
Objective-C packages.  The GNU Objective-C compiler does not define
__STDC_VERSION__ meaning that the C standard in effect is gnu89:
-Wimplicit-function-declaration [1], -Wincompatible-pointer-types,
etc. remain just warnings.  (FWIW, clang does the opposite: it sets
-std=gnu11 for Objective-C code but even with -std=gnu17 these remain
just warnings.)

I have rebuilt 64 packages (62 GNUstep + 2 non-GNUstep) with
-std=gnu17 and the result was 15 FTBFS bugs.  I attach a list with the
affected packages at the end of the message.

Can we have authoritative answers from a relase team member to the
following questions:

A. Should we consider these bugs and if so, what severity?

B. If the answer to A is positive, should we enforce -std=gnu17 when
   building Objective-C code to align with the C world [2]?  Of course
   this would mean that these bugs will become RC as soon as the
   change lands in unstable.

C. If the answer to B is positive, which is the most suitable package
   to enforce the standard:
   * gnustep-make (either as DEB_OBJCFLAGS_MAINT_APPEND definition in
 /usr/share/GNUstep/debian/config.mk or injecting -std=gnu17 in
 the rules).  Not all GNUstep packages use gnustep-make and of
 course non-GNUstep Objective-C packages don't.
   * dpkg (in OBJCFLAGS).  Not all packages honor dpkg's buildflags
 although these cases should be considered bugs, IMHO.
   * GCC?

[1] -Wimplicit-function-declaration is not a problem because even if
it's only a warning, the package will fail at link time with
"undefined reference to `function'".
[2] Objective-C is a strict superset of C so any sanity/security
concerns that apply for C apply equally so for Objective-C.

Debian GNUstep maintainers 
   chess.app   [-Wincompatible-pointer-types]
   fontmanager.app [-Wincompatible-pointer-types]
   gnustep-examples[-Wincompatible-pointer-types]
   gnustep-gui [-Wincompatible-pointer-types]
   gnustep-sqlclient   [-Wint-conversion]
   gorm.app[-Wincompatible-pointer-types]
   gridlock.app[-Wint-conversion]
   grr.app [-Wincompatible-pointer-types]
   helpviewer.app  [-Wint-conversion]
   mpdcon.app  [-Wincompatible-pointer-types]
   price.app   [-Wincompatible-pointer-types]

Debian SOGo Maintainers 
   sogo[-Wint-conversion]
   sope[-Wincompatible-pointer-types]

Eric Heintzmann 
   addresses-for-gnustep   [-Wint-conversion]

Jonathan Schleifer 
   objfw   [-Wincompatible-pointer-types]
   (package uses clang so required setting
   -Werror= to imitate GCC behavior)

Bug#1077325: bullseye-pu: package poe.app/0.5.1-6+deb11u1

2024-07-28 Thread Yavor Doganov

Package: release.debian.org
Severity: normal
Tags: bullseye
X-Debbugs-Cc: poe@packages.debian.org
Control: affects -1 + src:poe.app
User: release.debian@packages.debian.org
Usertags: pu

This is basically the same as bookworm-pu #1077323 but since I cannot
be sure that the same SRM will review it and for the sake of
completeness, I include the full information.

[ Reason ]
I would like to fix #1076829 in bullseye's final point release as
currently the package is completely unusable.  The bug was introduced
during the bullseye release cycle or even earlier when apparently some
default GNUstep behavior has changed.  I always try to test every
package after every GNUstep transition but it seems I have missed this
one (or more likely, I only checked that it started and loaded an .ogg
file).  Mea culpa.

In addition to the grave bug above, the second patch fixes an
unpleasant issue with the preferences: when the user chooses which
Vorbis comments to be available for editing, nothing happens (a
gnustep-back warning is printed on stdout that drawing is not allowed
due to missing target).  This also stems from a change in GNUstep's
behavior which no longer allows arbitrary drawing operations.  I would
classify this issue as important.

[ Impact ]
The package is completely unusable without the change in
editable-cells.patch.

[ Tests ]
I tested the updated package on a bullseye machine.

[ Risks ]
Changes are pretty trivial, no risk involved AFAICT.

[ Checklist ]
  [X] *all* changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in oldstable
  [X] the issue is verified as fixed in unstable

[ Changes ]
* d/gbp.conf: Set debian-branch.
* d/control: Set Vcs-Git branch.
* d/patches/editable-cells.patch: Fixes RC bug #1076829.
* d/patches/preferences-draw.patch: Fix for the issue described above.
diff -u poe.app-0.5.1/debian/changelog poe.app-0.5.1/debian/changelog
--- poe.app-0.5.1/debian/changelog
+++ poe.app-0.5.1/debian/changelog
@@ -1,3 +1,14 @@
+poe.app (0.5.1-6+deb11u1) bullseye; urgency=medium
+
+  * debian/gbp.conf: New file.
+  * debian/control (Vcs-Git): Set branch to bullseye.
+  * debian/patches/editable-cells.patch: New; make comment cells editable
+(Closes: #1076829).
+  * debian/patches/preferences-draw.patch: New; fix drawing when an
+NSActionCell in the preferences is acted on to change state.
+
+ -- Yavor Doganov   Sun, 28 Jul 2024 07:44:53 +0300
+
 poe.app (0.5.1-6) unstable; urgency=medium
 
   * Team upload.
diff -u poe.app-0.5.1/debian/control poe.app-0.5.1/debian/control
--- poe.app-0.5.1/debian/control
+++ poe.app-0.5.1/debian/control
@@ -9,7 +9,7 @@
   libvorbis-dev,
   imagemagick
 Standards-Version: 4.5.0
-Vcs-Git: https://salsa.debian.org/gnustep-team/poe.app.git
+Vcs-Git: https://salsa.debian.org/gnustep-team/poe.app.git -b bullseye
 Vcs-Browser: https://salsa.debian.org/gnustep-team/poe.app
 Homepage: https://www.eskimo.com/~pburns/Poe/
 
diff -u poe.app-0.5.1/debian/patches/series poe.app-0.5.1/debian/patches/series
--- poe.app-0.5.1/debian/patches/series
+++ poe.app-0.5.1/debian/patches/series
@@ -1 +1,3 @@
 link-libs.patch
+editable-cells.patch
+preferences-draw.patch
only in patch2:
unchanged:
--- poe.app-0.5.1.orig/debian/gbp.conf
+++ poe.app-0.5.1/debian/gbp.conf
@@ -0,0 +1,2 @@
+[DEFAULT]
+debian-branch = bullseye
only in patch2:
unchanged:
--- poe.app-0.5.1.orig/debian/patches/editable-cells.patch
+++ poe.app-0.5.1/debian/patches/editable-cells.patch
@@ -0,0 +1,21 @@
+Description: Make comment cells editable.
+Bug-Debian: https://bugs.debian.org/1076829
+Author: Yavor Doganov 
+Forwarded: no
+Last-Update: 2024-07-24
+---
+
+--- poe.app.orig/EditorWindowController.m
 poe.app/EditorWindowController.m
+@@ -161,6 +161,11 @@
+   [aTableView display];
+   }
+ }
++  else
++{
++  [aCell setEditable: YES];
++  [aCell setSelectable: YES];
++}
+ 
+ //  if([[aTableColumn identifier] isEqualToString: @"value"] &&
+ //_oggFile comments] objectAtIndex: rowIndex] objectForKey: @"tag"] 
only in patch2:
unchanged:
--- poe.app-0.5.1.orig/debian/patches/preferences-draw.patch
+++ poe.app-0.5.1/debian/patches/preferences-draw.patch
@@ -0,0 +1,52 @@
+Description: Fix drawing when a user clicks over an NSActionCell.
+Author: Yavor Doganov 
+Forwarded: no
+Last-Update: 2024-07-25
+---
+
+--- poe.app.orig/SwitchTableView.m
 poe.app/SwitchTableView.m
+@@ -120,9 +120,11 @@
+ // if the mouse is within the cell
+ if (NSMouseInRect(location, mouseCellFrame, YES))
+   {
++[self lockFocus];
+ [mouseCell highlight: YES 
+withFrame: mouseCellFrame 
+inView: self];
++[self unlockFocus];
+ [_window flushWindow];
+ if ([mouseCell trackMouse:

Bug#1077323: bookworm-pu: package poe.app/0.5.1-6+deb12u1

2024-07-28 Thread Yavor Doganov

Package: release.debian.org
Severity: normal
Tags: bookworm
X-Debbugs-Cc: poe@packages.debian.org
Control: affects -1 + src:poe.app
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
I would like to fix #1076829 in stable as currently the package is
completely unusable.  The bug was introduced during the bullseye
release cycle or even earlier when apparently some default GNUstep
behavior has changed.  I always try to test every package after every
GNUstep transition but it seems I have missed this one (or more
likely, I only checked that it started and loaded an .ogg file).
Mea culpa.

In addition to the grave bug above, the second patch fixes an
unpleasant issue with the preferences: when the user chooses which
Vorbis comments to be available for editing, nothing happens (a
gnustep-back warning is printed on stdout that drawing is not allowed
due to missing target).  This also stems from a change in GNUstep's
behavior which no longer allows arbitrary drawing operations.  I would
classify this issue as important.

[ Impact ]
The package is completely unusable without the change in
editable-cells.patch.

[ Tests ]
I tested the updated package on a bookworm machine.

[ Risks ]
Changes are pretty trivial, no risk involved AFAICT.

[ Checklist ]
  [X] *all* changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in stable
  [X] the issue is verified as fixed in unstable

[ Changes ]
* d/gbp.conf: Set debian-branch.
* d/control: Set Vcs-Git branch.
* d/patches/editable-cells.patch: Fixes RC bug #1076829.
* d/patches/preferences-draw.patch: Fix for the issue described above.
diff -u poe.app-0.5.1/debian/changelog poe.app-0.5.1/debian/changelog
--- poe.app-0.5.1/debian/changelog
+++ poe.app-0.5.1/debian/changelog
@@ -1,3 +1,14 @@
+poe.app (0.5.1-6+deb12u1) bookworm; urgency=medium
+
+  * debian/gbp.conf: New file.
+  * debian/control (Vcs-Git): Set branch to bookworm.
+  * debian/patches/editable-cells.patch: New; make comment cells editable
+(Closes: #1076829).
+  * debian/patches/preferences-draw.patch: New; fix drawing when an
+NSActionCell in the preferences is acted on to change state.
+
+ -- Yavor Doganov   Sun, 28 Jul 2024 07:22:30 +0300
+
 poe.app (0.5.1-6) unstable; urgency=medium
 
   * Team upload.
diff -u poe.app-0.5.1/debian/control poe.app-0.5.1/debian/control
--- poe.app-0.5.1/debian/control
+++ poe.app-0.5.1/debian/control
@@ -9,7 +9,7 @@
   libvorbis-dev,
   imagemagick
 Standards-Version: 4.5.0
-Vcs-Git: https://salsa.debian.org/gnustep-team/poe.app.git
+Vcs-Git: https://salsa.debian.org/gnustep-team/poe.app.git -b bookworm
 Vcs-Browser: https://salsa.debian.org/gnustep-team/poe.app
 Homepage: https://www.eskimo.com/~pburns/Poe/
 
diff -u poe.app-0.5.1/debian/patches/series poe.app-0.5.1/debian/patches/series
--- poe.app-0.5.1/debian/patches/series
+++ poe.app-0.5.1/debian/patches/series
@@ -1 +1,3 @@
 link-libs.patch
+editable-cells.patch
+preferences-draw.patch
only in patch2:
unchanged:
--- poe.app-0.5.1.orig/debian/gbp.conf
+++ poe.app-0.5.1/debian/gbp.conf
@@ -0,0 +1,2 @@
+[DEFAULT]
+debian-branch = bookworm
only in patch2:
unchanged:
--- poe.app-0.5.1.orig/debian/patches/editable-cells.patch
+++ poe.app-0.5.1/debian/patches/editable-cells.patch
@@ -0,0 +1,21 @@
+Description: Make comment cells editable.
+Bug-Debian: https://bugs.debian.org/1076829
+Author: Yavor Doganov 
+Forwarded: no
+Last-Update: 2024-07-24
+---
+
+--- poe.app.orig/EditorWindowController.m
 poe.app/EditorWindowController.m
+@@ -161,6 +161,11 @@
+   [aTableView display];
+   }
+ }
++  else
++{
++  [aCell setEditable: YES];
++  [aCell setSelectable: YES];
++}
+ 
+ //  if([[aTableColumn identifier] isEqualToString: @"value"] &&
+ //_oggFile comments] objectAtIndex: rowIndex] objectForKey: @"tag"] 
only in patch2:
unchanged:
--- poe.app-0.5.1.orig/debian/patches/preferences-draw.patch
+++ poe.app-0.5.1/debian/patches/preferences-draw.patch
@@ -0,0 +1,52 @@
+Description: Fix drawing when a user clicks over an NSActionCell.
+Author: Yavor Doganov 
+Forwarded: no
+Last-Update: 2024-07-25
+---
+
+--- poe.app.orig/SwitchTableView.m
 poe.app/SwitchTableView.m
+@@ -120,9 +120,11 @@
+ // if the mouse is within the cell
+ if (NSMouseInRect(location, mouseCellFrame, YES))
+   {
++[self lockFocus];
+ [mouseCell highlight: YES 
+withFrame: mouseCellFrame 
+inView: self];
++[self unlockFocus];
+ [_window flushWindow];
+ if ([mouseCell trackMouse: e
+inRect: mouseCellFrame 
+@@ -131,9 +133,11 @@
+   done = mouseUp = YES;
+ else
+   {
++[self lockFocus];
+

Bug#1072036: release.debian.org: Transition for gsl-2.8 / libgsl28

2024-07-21 Thread Yavor Doganov

On Fri, 12 Jul 2024 22:58:25 +0300,
Lucas Nussbaum wrote:
> If it ends up that you cannot do it, let me know and I can do it.

Fortunately this was not necessary.

Here are the results of my attempt (apologies that it took me so long).
These packages have issues with the new GSL version:

cpl-plugin-xshoo#1076251 FTBFS (not in testing)
libmath-gsl-perl#1076470 not binNMUable due to a strict
libgsl-dev B-D; maintainer ready to upload a
fixed new upstream release
ruby-gsl#1076659 FTBFS (patch available)

These packages have troubles of their own and are currently not
buildable:

coot#1076203 unsatisfiable B-D (builds fine with
python3-distutils removed from B-D)
inkscape#1073348 FTBFS (compiles and links fine with the patch
available but then I hit #1050236, testsuite failure)
sagemath#1056885, #1042683 FTBFS (not in testing)

I couldn't build this package (can you do it yourself, Dirk?):

deal.ii Out of memory; g++ killed (a machine with > 4 GB needed)

Bug#1072036: release.debian.org: Transition for gsl-2.8 / libgsl28

2024-07-11 Thread Yavor Doganov

Dirk Eddelbuettel wrote:
> On 11 July 2024 at 17:37, Lucas Nussbaum wrote:
> | Since we are only talking about approximately 294 source packages to
> | rebuild, isn't that something that you could do on your own machine?
> 
> I think I pass on that.

I volunteer to do test rebuilds of the rdeps (but have in mind that my
most powerful machine is rather slow, so it'll take a while) and to
report bugs (severity: important) that are blockers to this bug
against any package that FTBFS with the new GSL version.

In case you accept my proposal, we only have to agree about the
usertag and whether I should X-Debbugs-CC you in the bug reports.
What about:

User: e...@debian.org
Usertags: gsl_2.8-transition
Tags: sid trixie ftbfs

Bug#1075998: transition: gorm.app

2024-07-09 Thread Yavor Doganov

Emilio Pozuelo Monfort wrote:
> On 09/07/2024 09:40, Yavor Doganov wrote:
> > The only reverse dependency gnustep-dl2 will require a sourceful
> > upload.
> 
> Go ahead.

Thanks, uploaded.  May I assume that we also have your permission to
upload gnustep-dl2 and steptalk from experimental (both have proper
Build-Depends set to ensure they get built against the new versions)?

Bug#1076000: transition: steptalk

2024-07-09 Thread Yavor Doganov

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: stept...@packages.debian.org
Control: affects -1 + src:steptalk
Control: block -1 with 1075999
User: release.debian@packages.debian.org
Usertags: transition

This package has been neglected by our team (ltnu reports last upload
was 10 years ago) and it has some subtle bugs which could be fixed
only by moving to an upstream snapshot.  We had to bump the SONAME
(from libsteptalk0 to Debian-specific libsteptalk0d) because examining
the diff has shown there is an ABI break.

The only rdep adun.app builds fine against the new version; the ben
tracker is also correct.

Bug#1075999: transition: gnustep-dl2

2024-07-09 Thread Yavor Doganov

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: gnustep-...@packages.debian.org
Control: affects -1 + src:gnustep-dl2
Control: block -1 with 1075998
User: release.debian@packages.debian.org
Usertags: transition

To fix some long-standing bugs in this package we decided to move to a
git snapshot which introduces an ABI break, so we had to bump the
Debian-specific SONAME once again, from libgnustep-dl2-0d to
libgnustep-dl2-0deb (cherry-picking these fixes would have been
possible but they would break the ABI nevertheless).

As gnustep-dl2 requires a sourceful upload for the gorm.app
transition, we suggest to carry out this transition at the same time.
The sole rdep steptalk builds successfully but as there is a pending
steptalk transition as well, we may combine them if you decide so.

The ben tracker at release.d.o looks good.

Bug#1075998: transition: gorm.app

2024-07-09 Thread Yavor Doganov

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: gorm@packages.debian.org
Control: affects -1 + src:gorm.app
User: release.debian@packages.debian.org
Usertags: transition

Upstream has renamed the public Gorm library from libGorm to
libInterfaceBuilder so on behalf of the GNUstep team I'd like to ask
for a transition slot.

The only reverse dependency gnustep-dl2 will require a sourceful
upload.

The ben tracker at release.d.o is correct.

Bug#1072853: transition: gnustep-base, gnustep-gui

2024-06-08 Thread Yavor Doganov

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: pkg-gnustep-maintain...@lists.alioth.debian.org
User: release.debian@packages.debian.org
Usertags: transition

Hi release managers,

On behalf of the GNUstep team I'd like to request a transition slot
for a combined gnustep-base/gnustep-gui transition (one-round binNMUs):

libgnustep-base1.29 -> 1.30
libgnustep-gui0.30 -> 0.31

The new libraries are available in experimental, built on all release
architectures.  Build-testing the rdeps revealed only one issue
(lynkeos.app, #1072736) which has been fixed in unstable so no
sourceful uploads (except gnustep-back) will be required.

FYI, the new gnustep-gui version adds support for ImageMagick 7
(release.d.o #1060103).

The automatically generated trackers look fine.

Bug#1040335: transition: gnustep-sqlclient

2023-07-04 Thread Yavor Doganov

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: gnustep-sqlcli...@packages.debian.org
Control: affects -1 + src:gnustep-sqlclient
Control: forwarded -1 
https://release.debian.org/transitions/html/auto-gnustep-sqlclient.html

We would like to have release team's permission to update the
gnustep-sqlclient library (libsqlclient1.8 -> 1.9).
The only rdep is adun.app, it builds fine and can be safely binNMUed.

Thanks.

Bug#1039875: transition: gnustep-performance

2023-06-28 Thread Yavor Doganov

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: gnustep-performa...@packages.debian.org
Control: affects -1 + src:gnustep-performance
Control: forwarded -1 
https://release.debian.org/transitions/html/auto-gnustep-performance.html

We (GNUstep team) would like to update gnustep-performance
(libperformance0.5 -> 0.6).  The new version is sitting in
experimental and the sole reverse dependency gnustep-sqlclient builds
fine against it.

Thanks.

Bug#1038996: transition: pantomime

2023-06-24 Thread Yavor Doganov

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: pantom...@packages.debian.org, 
pkg-gnustep-maintain...@lists.alioth.debian.org
Control: affects -1 + src:pantomime
Control: block -1 with 1032830

On behalf of the GNUstep team I'd like to request a transition slot
for pantomime (libpantomime1.3 > 1.4).  Out of the two rdeps
lusernet.app builds successfully while gnumail will require a
sourceful upload due to incompatible API changes (#1032830).

The automatically generated Ben tracker [1] looks fine.

Thanks for your work.

[1] https://release.debian.org/transitions/html/auto-pantomime.html

Bug#1028602: transition: gnustep-base, gnustep-gui

2023-01-28 Thread Yavor Doganov

Sebastian Ramacher wrote:
> On 2023-01-13 15:15:10 +0200, Yavor Doganov wrote:
> > I realise we are already late and in all likelihood we've missed
> > the last bookworm train, which is rather unpleasant for us and
> > GNUstep users but entirely our fault.
> 
> I am not quite sure what you mean with unpleasant. What would be
> unpleasant for GNUstep users?

I meant that in case the transition is postponed to trixie, bookworm
will ship with old releases of core GNUstep.  It happened for bullseye
when I missed to inform upstream about Debian's freeze/release
schedule.  This time the upstream releases were made in time but we
failed to meet the deadline again.

Bug#1028602: transition: gnustep-base, gnustep-gui

2023-01-13 Thread Yavor Doganov

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: pkg-gnustep-maintain...@lists.alioth.debian.org
Control: affects -1 + src:gnustep-base src:gnustep-gui

Dear Release team,

We would like your permission to carry out a GNUstep transition (two
libraries simultaneously with one round of binNMUs):

  libgnustep-base1.28 -> 1.29
  libgnustep-gui0.29  -> 0.30

I realise we are already late and in all likelihood we've missed the
last bookworm train, which is rather unpleasant for us and GNUstep
users but entirely our fault.  In case it's not possible to do it now
(after tiff/poppler) then please have us in mind for the early stages
of the trixie development cycle.

gnustep-base/1.29.0-1 is available in experimental, not yet built on
mipsen, ppc64el and s390x.  But note that 1.28.1-2 was built in
unstable on all release architectures; 1.29.0 is essentially the same
except the version bump (the damage done was corrected; see #1028189).

gnustep-gui/0.30.0-1 is also available in experimental, not yet built
on ppc64el and s390x but I do not expect any problems there.

While build-testing all rdeps on amd64, the following problems were
observed:

agenda.app   #1028185  gnustep-gui bug, will be fixed with next upload
gnustep-dl2  #1028577  fixed locally; needs a sourceful upload
pantomime#1028578  likewise
sope #1028579  patch sent to the BTS; needs a sourceful upload

In addition, gnustep-back will require a sourceful upload (that is
always the case).

The automatic ben trackers at release.d.o look fine.

Bug#1000982: transition: gnustep-base, gnustep-gui

2021-12-01 Thread Yavor Doganov

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: pkg-gnustep-maintain...@lists.alioth.debian.org

We would like the Release Team's permission to carry out a GNUstep
transition, namely

  libgnustep-base1.27 -> 1.28
  libgnustep-gui0.28  -> 0.29

As usual, it's better to be done simultaneously (only one round
binNMUs for both libraries) since everything that depends on -gui also
depends on -base.  As always, gnustep-back will need a sourceful
upload and should not be binNMUed.

I have build-tested all rdeps and no problems were observed, at least
on amd64.  The auto tracker(s) at release.d.o is/are correct.

Bug#962584: transition: gnustep-base, gnustep-gui

2020-06-10 Thread Yavor Doganov

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

On behalf of the GNUstep team I'd like to ask for a slot to carry out
a GNUstep transition:

  libgnustep-base1.26 -> 1.27
  libgnustep-gui0.27  -> 0.28

I tested all rdeps; they build successfully on amd64 except cenon.app
(#962503).  In fact this is a gnustep-gui bug which will be fixed with
the upload to unstable so cenon.app can be binNMUed along with the
rest of the packages.

As always, gnustep-back (the rendering part of the gnustep-gui
library) will require a sourceful upload.

Bug#942110: stretch-pu: package gnustep-base/1.24.9-3.1+deb9u1

2019-10-10 Thread Yavor Doganov

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

I'd like to fix a vulnerability in the gdomap daemon (no DSA).  It is
fixed in testing/unstable and already approved/uploaded for buster
(release.d.o #940943).  The patch is the same.

Debdiff attached.
diff -Nru gnustep-base-1.24.9/debian/changelog 
gnustep-base-1.24.9/debian/changelog
--- gnustep-base-1.24.9/debian/changelog2017-02-02 21:12:50.0 
+0200
+++ gnustep-base-1.24.9/debian/changelog2019-10-10 08:33:21.0 
+0300
@@ -1,3 +1,12 @@
+gnustep-base (1.24.9-3.1+deb9u1) stretch; urgency=medium
+
+  * debian/patches/gdomap-udp-amplification.patch: New; fix UDP
+amplification vulnerability.  Thanks to Alan Jenkins.
+  * debian/patches/series: Update.
+  * debian/gbp.conf: New file.
+
+ -- Yavor Doganov   Thu, 10 Oct 2019 08:33:21 +0300
+
 gnustep-base (1.24.9-3.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru gnustep-base-1.24.9/debian/gbp.conf 
gnustep-base-1.24.9/debian/gbp.conf
--- gnustep-base-1.24.9/debian/gbp.conf 1970-01-01 02:00:00.0 +0200
+++ gnustep-base-1.24.9/debian/gbp.conf 2019-10-10 08:33:08.0 +0300
@@ -0,0 +1,3 @@
+[DEFAULT]
+pristine-tar = True
+debian-branch = stretch
diff -Nru gnustep-base-1.24.9/debian/patches/gdomap-udp-amplification.patch 
gnustep-base-1.24.9/debian/patches/gdomap-udp-amplification.patch
--- gnustep-base-1.24.9/debian/patches/gdomap-udp-amplification.patch   
1970-01-01 02:00:00.0 +0200
+++ gnustep-base-1.24.9/debian/patches/gdomap-udp-amplification.patch   
2019-10-10 08:32:24.0 +0300
@@ -0,0 +1,61 @@
+Description: Fix UDP amplification vulnerability
+ A couple of is_local_net() tests were wrong: they used "&&" with
+ masks, but that is the logical shortcut operator.  The correct
+ bitwise operator is "&".  The result was that is_local_net() was
+ always returning true.
+ .
+ Only allow local processes to send GDO_SERVERS requests.  This
+ request is only useful locally.  Do not allow remote requests for the
+ server list.  Our response can be large, so it would make a great UDP
+ amplification attack.
+ . 
+ Patch by Alan Jenkins ; issue
+ reported to the Debian security team.
+Origin: upstream, commit:de9740c
+Last-Update: 2019-10-10
+---
+
+--- gnustep-base.orig/Tools/gdomap.c
 gnustep-base/Tools/gdomap.c
+@@ -419,7 +419,7 @@
+ 
+   for (i = 0; i < interfaces; i++)
+ {
+-  if ((mask[i].s_addr && addr[i].s_addr) == (mask[i].s_addr && a.s_addr))
++  if ((mask[i].s_addr & addr[i].s_addr) == (mask[i].s_addr & a.s_addr))
+   {
+ return 1;
+   }
+@@ -3090,6 +3090,21 @@
+   unsigned inti;
+   unsigned intj;
+ 
++  /*
++   *  See if this is a request from a local process.
++   *
++   *  This request is only useful locally.  Do not allow remote
++   *  requests for the server list.  Our response can be large,
++   *  so it would make a great UDP amplification attack.
++   */
++  if (is_local_host(ri->addr.sin_addr) == 0)
++  {
++snprintf(ebuf, sizeof(ebuf), "Illegal attempt to list servers!");
++gdomap_log(LOG_ERR);
++clear_chan(desc);
++return;
++  }
++
+   free(wi->buf);
+   wi->buf = (char*)calloc(sizeof(uint32_t)
+   + (prb_used+1)*IASIZE, 1);
+@@ -3250,8 +3265,8 @@
+   {
+ continue;
+   }
+-if ((mask[i].s_addr && addr[i].s_addr) ==
+-  (mask[i].s_addr && ri->addr.sin_addr.s_addr))
++if ((mask[i].s_addr & addr[i].s_addr) ==
++  (mask[i].s_addr & ri->addr.sin_addr.s_addr))
+   {
+ laddr = addr[i];
+ memcpy(wbuf, &laddr, IASIZE);
diff -Nru gnustep-base-1.24.9/debian/patches/series 
gnustep-base-1.24.9/debian/patches/series
--- gnustep-base-1.24.9/debian/patches/series   2016-08-09 18:49:12.0 
+0300
+++ gnustep-base-1.24.9/debian/patches/series   2019-10-09 19:25:53.0 
+0300
@@ -19,3 +19,4 @@
 fix-gdnc.patch
 fix-tests-timings.patch
 fix-test-icu2.patch
+gdomap-udp-amplification.patch

Bug#940943: buster-pu: package gnustep-base/1.26.0-4+deb10u1

2019-09-22 Thread Yavor Doganov

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

I'd like to update the gnustep-base package in buster to fix #939119.
Additionally, the OP has also discovered a vulnerability in the gdomap
daemon which was reported to the Debian security team.  Haven't got a
response from them but the patch was approved by the upstream
maintainer and subsequently committed to the upstream repository.

Tested on a buster system; debdiff attached.
diff -Nru gnustep-base-1.26.0/debian/changelog 
gnustep-base-1.26.0/debian/changelog
--- gnustep-base-1.26.0/debian/changelog2019-02-01 23:20:45.0 
+0200
+++ gnustep-base-1.26.0/debian/changelog2019-09-22 12:44:38.0 
+0300
@@ -1,3 +1,16 @@
+gnustep-base (1.26.0-4+deb10u1) buster; urgency=medium
+
+  * debian/gnustep-base-runtime.preinst: New file; handle the poor
+upgrade from stretch to buster which left the gdomap daemon enabled
+(Closes: #939119).  Thanks to Alan Jenkins.
+  * debian/NEWS: Document that the gdomap daemon is disabled forcefully.
+  * debian/patches/gdomap-udp-amplification.patch: New; fix UDP
+amplification vulnerability.  Patch by Alan Jenkins.
+  * debian/patches/series: Update.
+  * debian/gbp.conf: Set debian-branch to buster.
+
+ -- Yavor Doganov   Sun, 22 Sep 2019 12:44:38 +0300
+
 gnustep-base (1.26.0-4) unstable; urgency=medium
 
   * debian/patches/armhf-test.patch: New; ignore a failing test on armhf
diff -Nru gnustep-base-1.26.0/debian/gbp.conf 
gnustep-base-1.26.0/debian/gbp.conf
--- gnustep-base-1.26.0/debian/gbp.conf 2019-01-10 14:50:12.0 +0200
+++ gnustep-base-1.26.0/debian/gbp.conf 2019-09-22 12:44:07.0 +0300
@@ -1,2 +1,3 @@
 [DEFAULT]
 pristine-tar = True
+debian-branch = buster
diff -Nru gnustep-base-1.26.0/debian/gnustep-base-runtime.preinst 
gnustep-base-1.26.0/debian/gnustep-base-runtime.preinst
--- gnustep-base-1.26.0/debian/gnustep-base-runtime.preinst 1970-01-01 
02:00:00.0 +0200
+++ gnustep-base-1.26.0/debian/gnustep-base-runtime.preinst 2019-09-22 
12:26:06.0 +0300
@@ -0,0 +1,24 @@
+#!/bin/sh
+
+set -e
+set -u
+
+# Upgrades from stretch to buster have made the gdomap daemon enabled
+# by default which is undesirable.  Explicitly delete the symlinks and
+# let update-rc.d recreate them in postinst.  See #939119.
+# Remove after bullseye is released.
+if [ "$1" = "upgrade" ]; then
+if dpkg --compare-versions "$2" lt 1.26.0-4+deb10u1; then
+ENABLED=no
+if [ -f /etc/default/gdomap ]; then
+. /etc/default/gdomap
+fi
+if [ "$ENABLED" != "yes" ]; then
+find /etc/rc?.d -name "*gdomap" -delete
+fi
+fi
+fi
+
+#DEBHELPER#
+
+exit 0
diff -Nru gnustep-base-1.26.0/debian/NEWS gnustep-base-1.26.0/debian/NEWS
--- gnustep-base-1.26.0/debian/NEWS 2018-01-01 12:39:24.0 +0200
+++ gnustep-base-1.26.0/debian/NEWS 2019-09-22 12:32:35.0 +0300
@@ -1,3 +1,12 @@
+gnustep-base (1.26.0-4+deb10u1) buster; urgency=medium
+
+  The gdomap daemon has been inadvertently enabled in 1.25.1-1 while
+  implementing a new Debian Policy requirement (§9.3.3.1).  This version
+  forcefully disables it again.  If you want the daemon running, run
+  "update-rc.d gdomap enable" to enable it.
+
+ -- Yavor Doganov   Sun, 22 Sep 2019 12:32:33 +0300
+
 gnustep-base (1.25.0-1) experimental; urgency=medium
 
   The example programs using the GNUstep Base library have been moved to
diff -Nru gnustep-base-1.26.0/debian/patches/gdomap-udp-amplification.patch 
gnustep-base-1.26.0/debian/patches/gdomap-udp-amplification.patch
--- gnustep-base-1.26.0/debian/patches/gdomap-udp-amplification.patch   
1970-01-01 02:00:00.0 +0200
+++ gnustep-base-1.26.0/debian/patches/gdomap-udp-amplification.patch   
2019-09-22 12:40:24.0 +0300
@@ -0,0 +1,61 @@
+Description: Fix UDP amplification vulnerability
+ A couple of is_local_net() tests were wrong: they used "&&" with
+ masks, but that is the logical shortcut operator.  The correct
+ bitwise operator is "&".  The result was that is_local_net() was
+ always returning true.
+ .
+ Only allow local processes to send GDO_SERVERS requests.  This
+ request is only useful locally.  Do not allow remote requests for the
+ server list.  Our response can be large, so it would make a great UDP
+ amplification attack.
+ . 
+ Patch by Alan Jenkins ; issue
+ reported to the Debian security team.
+Origin: upstream, commit:de9740c
+Last-Update: 2019-09-22
+---
+
+--- gnustep-base.orig/Tools/gdomap.c
 gnustep-base/Tools/gdomap.c
+@@ -419,7 +419,7 @@
+ 
+   for (i = 0; i < interfaces; i++)
+ {
+-  if ((mask[i].s_addr && addr[i].s_addr) == (mask[i].s_addr && a.s_addr))
++  if ((mask[i].s_addr & addr[i].s_addr) == (mask[i].s_addr & a.s_addr))
+   {
+

Bug#918844: transition: gnustep-base, gnustep-gui

2019-01-18 Thread Yavor Doganov

Yavor Doganov wrote:
> Emilio Pozuelo Monfort wrote:
> > On 16/01/2019 09:31, Yavor Doganov wrote:
> > > Are you going to force gnustep-base to testing or you want me to do
> > > something else?
> > 
> > I don't plan on forcing this.
> 
> OK.

It looks like Paul Gevers added a ci hint to install gnustep-performance
from unstable so it passed and the GNUstep stack migrated.  Thanks, Paul!

> > I would rather this is solved one way or another, either via strict
> > dependencies or by versioned breaks if possible.
> 
> I'm going to upload gnustep-base/1.26.0-3 with strict dependencies as
> there are other issues which makes this necessary; hopefully the
> gnustep-sqlclient autopkgtest in testing will be skipped then.

I still plan to do this (also for -gui), which would: 1) avoid manual
hints in the future; 2) the order will be guaranteed so you can
schedule all binNMUs for future transitions in one shot; 3) will
prevent the sheer breakage which happens when two GNUstep core library
versions are installed.

Not sure if something else needs to be done or this bug can be closed?

Bug#918844: transition: gnustep-base, gnustep-gui

2019-01-17 Thread Yavor Doganov

Emilio Pozuelo Monfort wrote:
> On 16/01/2019 09:31, Yavor Doganov wrote:
> > Are you going to force gnustep-base to testing or you want me to do
> > something else?
> 
> I don't plan on forcing this.

OK.

> I would rather this is solved one way or another, either via strict
> dependencies or by versioned breaks if possible. I leave that up to
> you.

I don't think versioned breaks on a binNMUed package is a good idea;
the version may vary accross architectures.  It is also not a feasible
long-term solution as more packages will fail when we add more tests
in the future.

I find it odd that the ci test is installing a package that's going to
be decrufted once gnustep-base migrates to testing -- it is basically
testing an impossible scenario.  But I think I understand why it is
implemented this way.

I'm going to upload gnustep-base/1.26.0-3 with strict dependencies as
there are other issues which makes this necessary; hopefully the
gnustep-sqlclient autopkgtest in testing will be skipped then.

> > * lusernet.app was built against libpantomime1.2
> 
> Scheduled.

Thanks.

Bug#918844: transition: gnustep-base, gnustep-gui

2019-01-16 Thread Yavor Doganov

On Sat, 12 Jan 2019 01:24:54 +0200,
Yavor Doganov wrote:
> Emilio Pozuelo Monfort wrote:
> > And yes, a combined list would be appreciated if the rebuilds need
> > to be done in order.
> 
> In previous transitions, the order was guaranteed because rdeps higher
> up the stack were in state BD-Uninstallable until the library packages
> they depend upon were rebuilt and installed.  But in this cycle we
> have relaxed the dependencies between the -base/-gui binary packages
> to allow co-installation of different library versions, thus
> supporting partial upgrades.

I would appreciate the release team's opinion regarding this
experiment; I think it failed not only because of the regressions [1]
when both library versions are installed but because testing migration
is now blocked by regression in gnustep-sqlclient's autopkgtests.

[1] 
https://alioth-lists.debian.net/pipermail/pkg-gnustep-maintainers/2019-January/004782.html

Should we switch back to tight dependencies, thus allowing only one
gnustep-{base,gui} version to be installed?  I believe that's also the
reason for the gnustep-sqlclient's autopkgtest failure in testing as
libperformance0.5 (from src:gnustep-performance) linked against
gnustep-base/1.25 is installed during the test.  If the dependencies
were tight the test would be skipped in testing.

Are you going to force gnustep-base to testing or you want me to do
something else?

> What's important is that any package in this category which compiles
> and runs tests at build time will FTBFS because the tests will abort.
> This is precisely what happened to me with sogo when I tested it for
> this transition; see #918795 for explanation (I closed the bug as it
> turned out that sogo builds fine).  TTBOMK, gnustep-sqlclient and sogo
> are the only rdeps that have tests,

Same problem here; gnustep-sqlclient and sogo failed to build on
kfreebsd-amd64 as the builds were attempted with non-binNMUed
gnustep-performance and sope/sbjson.

Other problems so far:

* lusernet.app was built against libpantomime1.2 on all release
  architectures + hurd-i386.  Builds for debian-ports are fine AFAICS.
  Would you schedule another round with the appropriate extra-depends
  or you want me to make a sourceful upload?

* All binNMUs on kfreebsd-i386 were in vain because gnustep-base is
  not installed there yet and gnustep-gui is not even built.

* There are some installability issues on kfreebsd-* due to libheif
  not being rebuilt for the last x265 transition.  Should I ask on
  -bsd/-wb-team for help here?

* 3 packages FTBFS on GNU/Hurd due to a known issue with the buildds;
  I asked Samuel to give them back.

Bug#918844: transition: gnustep-base, gnustep-gui

2019-01-11 Thread Yavor Doganov

Yavor Doganov wrote:
> Level 2
> ===
> # both -base and -gui; applies for the next levels as well
+ grr.app

I forgot grr.app here; mea culpa.

Bug#918844: transition: gnustep-base, gnustep-gui

2019-01-11 Thread Yavor Doganov

Emilio Pozuelo Monfort wrote:
> Go ahead with this.

Thanks a lot for the green light.  Both uploaded; gnustep-base would
need a give-back on armhf at the right moment as it got picked by the
arm64 buildd again.

> And yes, a combined list would be appreciated if the rebuilds need
> to be done in order. If order doesn't matter and I can schedule all
> the levels in one go, then I can combine them myself.

In previous transitions, the order was guaranteed because rdeps higher
up the stack were in state BD-Uninstallable until the library packages
they depend upon were rebuilt and installed.  But in this cycle we
have relaxed the dependencies between the -base/-gui binary packages
to allow co-installation of different library versions, thus
supporting partial upgrades.  (Incidentally, this should assist
transitions too as I think they will migrate as soon as their rdeps
with autopkgtests are binNMUed and their tests pass.  Previously, the
whole GNUstep stack migrated as one unit, usually waiting for the
slower arches to catch up.)

So the order will be undefined now if the binNMUs are scheduled at
once.  Packages up the stack that happen to build before their
dependencies below (e.g., lusernet.app building before pantomime) will
end up with warnings like:

| Linking app LuserNET ...
| /usr/bin/ld: warning: libgnustep-base.so.1.25, needed by 
/usr/lib/libPantomime.so, may conflict with libgnustep-base.so.1.26

This is harmless and relinking is not needed, but the lusernet.app
package will be broken for users (the program will abort on startup)
until pantomime is binNMUed.  I guess that's somewhat reluctantly
allowed during transitions ("unwritten law"); some packages are broken
right now in sid for users who upgraded -base and -gui because of the
programs from the -runtime packages which are available only for the
new library versions now.

What's important is that any package in this category which compiles
and runs tests at build time will FTBFS because the tests will abort.
This is precisely what happened to me with sogo when I tested it for
this transition; see #918795 for explanation (I closed the bug as it
turned out that sogo builds fine).  TTBOMK, gnustep-sqlclient and sogo
are the only rdeps that have tests, so you can schedule binNMUs for

gnustep-performance
sbjson
sope

first, wait for them to be installed everywhere and then schedule all
the rest in one go.  Alternatively, if the above is technically
difficult, schedule everything in one go and be ready for give-backs
on architectures where the wrong order leads to FTBFS.

And finally, if you feel now is not the proper time to experiment, you
can schedule them in batches, preserving the order and mimicking the
past transitions where the order naturally followed the dependency
chain.

Here is hopefully the complete list (I split them based on the
dependencies on the core libraries only to allow you to tweak the
binNMU changelogs, if you wish so; it doesn't matter otherwise):

Level 1
===
# packages that depend only on -base
biococoa
dbuskit
gnustep-netclasses
gnustep-performance
mknfonts.tool
openvpn-auth-ldap
pantomime
rsskit
sbjson
sope
unar

# packages that depend both on -base and -gui
aclock.app
addresses-for-gnustep
affiche
batmon.app
camera.app
cenon.app
charmap.app
chess.app
cynthiune.app
edenmath.app
etoile
fontmanager.app
ftp.app
gnustep-examples
gomoku.app
gorm.app
gridlock.app
gtamsanalyzer.app
helpviewer.app
lynkeos.app
mpdcon.app
paje.app
pikopixel.app
plopfolio.app
poe.app
popplerkit.framework
preview.app
price.app
projectcenter.app
renaissance
systempreferences.app
terminal.app
textedit.app
timemon.app
volumecontrol.app
wrapperfactory.app
zipper.app

Level 2
===
# only -base
gnustep-sqlclient
sogo

# both -base and -gui; applies for the next levels as well
agenda.app
gnumail
gnustep-dl2
gworkspace
lusernet.app
talksoup.app
viewpdf.app

Level 3
===
steptalk

Level 4
===
adun.app

Reverse dependencies that are deliberately omitted:

- fortunate.app (FTBFS, pending sourceful upload);
- gnustep-back (sourceful upload due at my sponsor's discretion; it
  tracks -gui versioning closely);
- pantomime1.2 (scheduled for removal; no point rebuilding it).

Bug#918844: transition: gnustep-base, gnustep-gui

2019-01-09 Thread Yavor Doganov

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

On behalf of the GNUstep team I'd like to ask for your permission to
carry out a last gasp GNUstep transition (libgnustep-base1.25 -> 1.26
and libgnustep-gui0.26 -> 0.27).

I realize it is way too late in the release cycle and the transition
freeze is imminent.  The poor timing is entirely my fault becuase
until last week upstream were unaware of the Debian buster release
schedule.  I didn't inform them in advance as I thought there were not
that many changes to warrant new releases.  It was poor judgement on
my part and I'll make sure to avoid it in the future.  They've been
working hard in the past few days to get the relases out in time
specifically for buster.

The changes are really minimalistic compared to any of the previous
transitions.  In fact gnustep-base/1.26 is ABI-compatible with 1.25 if
it is configured for the GCC/GNU runtime (as is for Debian).  The
SONAME was bumped for consistency because the support for the new
libobjc2 ABI (a.k.a. the GNUstep runtime, not packaged for Debian)
breaks the gnustep-base ABI.  The incompatible changes in gnustep-gui
affect only a few classes; the rest is minimal API additions and
bugfixes.  So in theory, this should be the smoothest GNUstep
transtion ever.  An argument in favor of this presumptuous statement
is that for the first time only one of the rdeps fails to build.

Here's a summary of the issues:

* gnustep-base/1.26 FTBFS on:

  - armhf: That's a known issue (#918366), it will build on a native
  armhf buildd.  Arguably, we should fix this bug ASAP but AFAICS it
  is not RC (yet) and will not impede the transition.

  - ia64: Never built there since this architecture was resurrected.
  I suspect it is due to libffi as its own testsuite is failing.
  Things are looking better with libffi/3.3 so we'll see.  Nothing to
  do here as there are no GNUstep packages on ia64.

  - powerpc/ppc64: This came out as a surprise but it looks like a
  transient problem (#918781).  I really hope it is.  In the worst
  case I can disable the failing tests temporarily.

  - Not yet built on mips64el, mipsel and kfreebsd-*.  I don't expect
  problems there.

* Rdeps that FTBFS:

  - sogo: #918795.  I'm not marking it as blocking the transition
  because sogo is not in testing due to #914524.

* Rdeps not tested:

  - fortunate.app: unrelated FTBFS (#897623), not in testing.
  
  - pantomime1.2: I plan to file a RM bug against ftp.d.o as soon as
  lusernet.app is rebuilt for the pantomime transition (release.d.o
  #916445).

The automatic trackers look OK to me.  Should you ACK the transition
for buster, I would suggest to do binNMUs for both libraries at once,
to spare buildds' resources.  Let me know if you need the combined
list of the rdeps in the right order.  Note that lusernet.app is
likely to require extra-depends on libpantomime-dev (>= 1.3),
otherwise the wrong library is likely to be be picked because the
package still build-depends on libpantomime1.2-dev.

As always, gnustep-back should not be binNMUed, there will be a
sourceful upload.

Bug#916445: transition: pantomime

2018-12-14 Thread Yavor Doganov

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

On behalf of the GNUstep team I would like to request a transition
slot for a pantomime transition.

Note that src:pantomime1.2 (providing libpantomime1.2 and
libpantomime1.2-dev) was renamed back to src:pantomime (providing
libpantomime1.3 and now the versionless -dev package libpantomime-dev).
The previous transition was in 2006, before the binNMU era, so we are
now bringing the package to the current library packaging practice.

The new library version is available in experimental; both reverse
dependencies (gnumail and lusernet.app) build successfully with it.
However, gnumail will be severely broken by the new format of the IMAP
cache so I'd really prefer to make a sourceful upload of a new
upstream version addressing this problem.  lusernet.app is not
affected and can be binNMUed.

I couldn't find an automatic tracker at release.d.o; most probably it
was not created because the source package has been renamed.

Ben file:

title = "pantomime";
is_affected = .depends ~ "libpantomime1.2" | .depends ~ "libpantomime1.3";
is_good = .depends ~ "libpantomime1.3";
is_bad = .depends ~ "libpantomime1.2";

Bug#894027: stretch-pu: package addresses-for-gnustep/0.4.8-2+deb9u1

2018-04-02 Thread Yavor Doganov

Julien Cristau wrote:
> On Sun, Mar 25, 2018 at 17:00:43 +0300, Yavor Doganov wrote:
> > If possible, I would like to fix #889534 and #889536 (missing
> > dependencies).

> What does this translate to in terms of changes to binary packages?

Needed libraries added to Depends:, here are the binary debdiffs:

$ debdiff libaddresses0_0.4.8-2+b2_i386.deb 
libaddresses0_0.4.8-2+deb9u1_i386.deb 
[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files in first .deb but not in second
-
-rw-r--r--  root/root   /usr/share/doc/libaddresses0/changelog.Debian.i386.gz

Control files: lines which differ (wdiff format)

Depends: libc6 (>= 2.4), libgcc1 (>= [-1:3.0)-] {+1:3.0), libgnustep-base1.24 
(>= 1.24.7), libobjc4 (>= 4.2.1)+}
Installed-Size: [-269-] {+268+}
Source: addresses-for-gnustep [-(0.4.8-2)-]
Version: [-0.4.8-2+b2-] {+0.4.8-2+deb9u1+}

$ debdiff libaddressview0_0.4.8-2+b2_i386.deb 
libaddressview0_0.4.8-2+deb9u1_i386.deb 
[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files in first .deb but not in second
-
-rw-r--r--  root/root   /usr/share/doc/libaddressview0/changelog.Debian.i386.gz

Control files: lines which differ (wdiff format)

Depends: {+gnustep-back0.25, gnustep-gui-runtime, libaddresses0 (>= 0.4.6),+} 
libc6 (>= [-2.4)-] {+2.4), libgnustep-base1.24 (>= 1.24.7), libgnustep-gui0.25, 
libobjc4 (>= 4.2.1)+}
Installed-Size: [-295-] {+294+}
Source: addresses-for-gnustep [-(0.4.8-2)-]
Version: [-0.4.8-2+b2-] {+0.4.8-2+deb9u1+}

> Is this an issue for users in practice, or mainly a
> theoretical/correctness issue?

I would say it's the latter.  Any program linking against libaddresses
or libaddressview presumably already links with gnustep-base/gui and
the Objective-C runtime.  There are cases when the dynamic linker
loads the libraries in the wrong order which may lead to runtime
failure if loadable modules (bundles) are not linked properly.  But I
haven't seen this in practice and I'd say it's unlikely to occur on
modern systems.

Bug#894027: stretch-pu: package addresses-for-gnustep/0.4.8-2+deb9u1

2018-03-25 Thread Yavor Doganov

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

If possible, I would like to fix #889534 and #889536 (missing
dependencies).  Debdiff against the package version in stable
attached.  Thanks.

-- System Information:
Debian Release: 9.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 4.9.0-6-686-pae (SMP w/1 CPU core)
Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8), 
LANGUAGE=bg_BG.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru addresses-for-gnustep-0.4.8/debian/changelog 
addresses-for-gnustep-0.4.8/debian/changelog
--- addresses-for-gnustep-0.4.8/debian/changelog2015-11-17 
01:16:26.0 +0200
+++ addresses-for-gnustep-0.4.8/debian/changelog2018-03-25 
16:17:58.0 +0300
@@ -1,3 +1,12 @@
+addresses-for-gnustep (0.4.8-2+deb9u1) stretch; urgency=medium
+
+  * Team upload.
+  * debian/patches/link-libs.patch: New, link against all needed libraries
+(Closes: #889534, #889536).
+  * debian/patches/series: Update.
+
+ -- Yavor Doganov   Sun, 25 Mar 2018 16:17:58 +0300
+
 addresses-for-gnustep (0.4.8-2) unstable; urgency=medium
 
   * Fix danggling symlinks in libaddressview-dev and libaddresses-dev
diff -Nru addresses-for-gnustep-0.4.8/debian/patches/link-libs.patch 
addresses-for-gnustep-0.4.8/debian/patches/link-libs.patch
--- addresses-for-gnustep-0.4.8/debian/patches/link-libs.patch  1970-01-01 
02:00:00.0 +0200
+++ addresses-for-gnustep-0.4.8/debian/patches/link-libs.patch  2018-03-25 
16:17:58.0 +0300
@@ -0,0 +1,28 @@
+Description: Link against needed libraries.
+ Avoid linking the Addresses framework with GNUstep GUI.
+Bug-Debian: https://bugs.debian.org/889534
+Bug-Debian: https://bugs.debian.org/889536
+Origin: upstream, commit:r3597
+Last-Update: 2018-03-05
+---
+
+--- gnustep-addresses.orig/Frameworks/AddressView/GNUmakefile
 gnustep-addresses/Frameworks/AddressView/GNUmakefile
+@@ -36,4 +36,4 @@
+ -include GNUmakefile.postamble
+ 
+ ADDITIONAL_LIB_DIRS += -L../Addresses/Addresses.framework 
+-ADDITIONAL_GUI_LIBS = -lAddresses
+\ No newline at end of file
++LIBRARIES_DEPEND_UPON = -lAddresses $(GUI_LIBS) $(FND_LIBS) $(OBJC_LIBS) 
$(SYSTEM_LIBS)
+--- gnustep-addresses.orig/Frameworks/Addresses/GNUmakefile
 gnustep-addresses/Frameworks/Addresses/GNUmakefile
+@@ -42,6 +42,8 @@
+ Addresses_LOCALIZED_RESOURCE_FILES=PropertiesAndLabels.strings
+ Addresses_LANGUAGES=Dutch English French German Spanish
+ 
++LIBRARIES_DEPEND_UPON = $(FND_LIBS) $(OBJC_LIBS) $(SYSTEM_LIBS)
++
+ -include GNUmakefile.preamble
+ -include GNUmakefile.local
+ include $(GNUSTEP_MAKEFILES)/framework.make
diff -Nru addresses-for-gnustep-0.4.8/debian/patches/series 
addresses-for-gnustep-0.4.8/debian/patches/series
--- addresses-for-gnustep-0.4.8/debian/patches/series   2015-11-05 
21:05:21.0 +0200
+++ addresses-for-gnustep-0.4.8/debian/patches/series   2018-03-25 
16:17:58.0 +0300
@@ -1 +1,2 @@
+link-libs.patch
 fix-adserver-format.patch

Bug#888438: transition: gnustep-gui

2018-01-27 Thread Yavor Doganov

On Thu, 25 Jan 2018 18:18:42 +0200,
Emilio Pozuelo Monfort wrote:
> On 25/01/18 16:56, Yavor Doganov wrote:
> > We would like to have a slot for a gnustep-gui transition (0.25 -> 0.26).  

> Go ahead.

Uploaded to unstable and built/installed on all architectures except
ia64, kfreebsd* and sparc64.

The gnustep-base testsuite fails on ia64; I'm almost sure it is due to
buggy libffi.  AFAICS from the build log, the bug is probably fixed in
the libffi version in experimental.  Since the GNUstep stack is not
yet built on ia64 no binNMUs are needed anyway.

On sparc64, imagemagick is uninstallable because of openexr #822583.
That's an old bug and I wonder how gnustep-gui/0.25.0-5 built there
just three months ago.

Bug#888438: transition: gnustep-gui

2018-01-25 Thread Yavor Doganov

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
Control: forwarded -1 
https://release.debian.org/transitions/html/auto-gnustep-gui.html

We would like to have a slot for a gnustep-gui transition (0.25 -> 0.26).  
Version 0.26.2-1 is in experimental, built on all release architectures.

We have tested the rdeps, all build successfully against the new
version of the library.  As always, gnustep-back will require a
sourceful upload; the rest can be binNMUed.

Ben file:

title = "gnustep-gui";
is_affected = .depends ~ "libgnustep-gui0.25" | .depends ~ "libgnustep-gui0.26";
is_good = .depends ~ "libgnustep-gui0.26";
is_bad = .depends ~ "libgnustep-gui0.25";

Bug#886636: stretch-pu: package gnumail/1.2.2-1.1+deb9u1

2018-01-08 Thread Yavor Doganov

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Hi SRMs,

Please approve an update of gnumail to fix #886305.  The libssl
dependency is unused:

$ dpkg -l gnumail.app | grep ^i
ii  gnumail.app1.2.2-1.1i386 Mail client for GNUstep
$ ldd -u /usr/bin/GNUMail | grep ssl
/usr/lib/i386-linux-gnu/libssl.so.1.1

And it makes the package undistributable because its license is GPL-2+
without explicit OpenSSL exception.  The fix is straightforward;
debdiff attached.

$ dpkg -l gnumail.app | grep ^i
ii  gnumail.app1.2.2-1.1+deb9u1 i386 Mail client for GNUstep
$ ldd /usr/bin/GNUMail | grep ssl
$
$ dpkg -I gnumail.app_1.2.2-1.1+deb9u1_i386.deb | grep ssl
$
diff -Nru gnumail-1.2.2/debian/changelog gnumail-1.2.2/debian/changelog
--- gnumail-1.2.2/debian/changelog  2017-01-22 06:04:03.0 +0200
+++ gnumail-1.2.2/debian/changelog  2018-01-08 11:06:31.0 +0200
@@ -1,3 +1,10 @@
+gnumail (1.2.2-1.1+deb9u1) stretch; urgency=medium
+
+  * debian/patches/link-libs.patch: Update to eradicate unnecessary
+linking with OpenSSL (Closes: #886305).
+
+ -- Yavor Doganov   Mon, 08 Jan 2018 11:06:31 +0200
+
 gnumail (1.2.2-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru gnumail-1.2.2/debian/patches/link-libs.patch 
gnumail-1.2.2/debian/patches/link-libs.patch
--- gnumail-1.2.2/debian/patches/link-libs.patch2017-01-22 
06:04:03.0 +0200
+++ gnumail-1.2.2/debian/patches/link-libs.patch2018-01-08 
11:06:31.0 +0200
@@ -1,12 +1,12 @@
-Subject: Link libs
+Description: Remove unnecessary linking with OpenSSL.
+Author: Yavor Doganov 
+Bug-Debian: https://bugs.debian.org/886305
+Forwarded: https://savannah.nongnu.org/bugs/?52817
+Last-Update: 2018-01-08
+---
 
-* Framework/GNUMail/GNUmakefile: replace GNUMail_GUI_LIBS by 
LIBRARIES_DEPEND_UPON and add all missing libs.
-
-From: Yavor Doganov  
-Last-Update: 2016-10-02
-
 a/Framework/GNUMail/GNUmakefile
-+++ b/Framework/GNUMail/GNUmakefile
+--- gnumail.orig/Framework/GNUMail/GNUmakefile
 gnumail/Framework/GNUMail/GNUmakefile
 @@ -100,7 +100,8 @@
WelcomePanel.m
  
@@ -17,3 +17,14 @@
  ADDITIONAL_INCLUDE_DIRS = -I.
  
  # We want to get all the warnings... 
+--- gnumail.orig/GNUmakefile
 gnumail/GNUmakefile
+@@ -60,7 +60,7 @@
+   Resources/Turkish
+ 
+ GNUMail_LIB_DIRS = -L../$(GNUSTEP_LIBRARIES_ROOT) 
-LFramework/GNUMail/GNUMail.framework/Versions/Current/$(GNUSTEP_TARGET_LDIR) 
-LFramework/GNUMail/GNUMail.framework
+-GNUMail_GUI_LIBS = -lGNUMail -lPantomime -lAddresses -lAddressView -lssl 
-lcrypto
++GNUMail_GUI_LIBS = -lGNUMail -lPantomime -lAddresses -lAddressView
+ GNUMail_LOCALIZED_RESOURCE_FILES = Localizable.strings
+ 
+ ADDITIONAL_INCLUDE_DIRS += -I./Framework/GNUMail

Bug#885184: stretch-pu: package agenda.app/0.42.2-1+deb9u1

2017-12-25 Thread Yavor Doganov

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Hi SRMs,

Would you approve an update for agenda.app to fix #884098?
Proposed change was tested on a stretch machine; debdiff attached.

(Note that jessie is not affected; it has the same agenda.app version
but an older gnustep-gui version that doesn't exhibit the bug.)

-- System Information:
Debian Release: 9.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 4.9.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8), 
LANGUAGE=bg_BG.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru agenda.app-0.42.2/debian/changelog agenda.app-0.42.2/debian/changelog
--- agenda.app-0.42.2/debian/changelog  2012-05-29 18:00:21.0 +0300
+++ agenda.app-0.42.2/debian/changelog  2017-12-25 22:09:00.0 +0200
@@ -1,3 +1,11 @@
+agenda.app (0.42.2-1+deb9u1) stretch; urgency=medium
+
+  * debian/patches/fix-editors-exception.patch: New, fixes creation of
+tasks and appointments (Closes: #884098).
+  * debian/patches/series: New file.
+
+ -- Yavor Doganov   Mon, 25 Dec 2017 22:09:00 +0200
+
 agenda.app (0.42.2-1) unstable; urgency=low
 
   * New upstream release:
diff -Nru agenda.app-0.42.2/debian/patches/fix-editors-exception.patch 
agenda.app-0.42.2/debian/patches/fix-editors-exception.patch
--- agenda.app-0.42.2/debian/patches/fix-editors-exception.patch
1970-01-01 02:00:00.0 +0200
+++ agenda.app-0.42.2/debian/patches/fix-editors-exception.patch
2017-12-25 22:09:00.0 +0200
@@ -0,0 +1,40 @@
+Description: Fix NSException when creating a new task or appointment.
+ Upstream is uncertain that this is the right fix; I concur.  It looks
+ like the problem stems from the fact that TaskEditor/AppointmentEditor
+ are window controllers but don't derive from NSWindowController and
+ thus do not inherit the -document method.  Upstream doesn't remember
+ why he opted to subclass NSObject; it's not feasible to change the
+ superclass now.
+Origin: upstream, commit:fa5ccf2
+Bug-Debian: https://bugs.debian.org/884098
+Last-Update: 2017-12-25
+---
+
+--- agenda.app.orig/AppointmentEditor.m
 agenda.app/AppointmentEditor.m
+@@ -38,6 +38,11 @@
+   return self;
+ }
+ 
++- (id)document
++{
++   return nil;
++}
++
+ - (id)initWithEvent:(Event *)event
+ {
+   StoreManager *sm = [StoreManager globalManager];
+--- agenda.app.orig/TaskEditor.m
 agenda.app/TaskEditor.m
+@@ -33,6 +33,11 @@
+   return self;
+ }
+ 
++- (id)document
++{
++   return nil;
++}
++
+ - (id)initWithTask:(Task *)task
+ {
+   StoreManager *sm = [StoreManager globalManager];
diff -Nru agenda.app-0.42.2/debian/patches/series 
agenda.app-0.42.2/debian/patches/series
--- agenda.app-0.42.2/debian/patches/series 1970-01-01 02:00:00.0 
+0200
+++ agenda.app-0.42.2/debian/patches/series 2017-12-25 22:09:00.0 
+0200
@@ -0,0 +1 @@
+fix-editors-exception.patch

Bug#883455: transition: gnustep-sqlclient

2017-12-04 Thread Yavor Doganov

Emilio Pozuelo Monfort wrote:
> > libsqlclient1.7 -> libsqlclient1.8

> Sure, go ahead.

Thanks, 1.8.1-3 is now built and installed on all architectures.

Please schedule binNMUs for adun.app (you can omit sparc64 as it just
got built there; it was in BD-Uninstallable state due to #880477).

Bug#883455: transition: gnustep-sqlclient

2017-12-04 Thread Yavor Doganov

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

I would like to request a mini-transition for gnustep-sqlclient:
libsqlclient1.7 -> libsqlclient1.8

There is only one reverse dependency (adun.app); it builds fine with
the new version of the library.

Ben file:

title = "gnustep-sqlclient";
is_affected = .depends ~ "libsqlclient1.7" | .depends ~ "libsqlclient1.8";
is_good = .depends ~ "libsqlclient1.8";
is_bad = .depends ~ "libsqlclient1.7";

Bug#879738: transition: gnustep-base

2017-10-31 Thread Yavor Doganov

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.

Bug#879738: transition: gnustep-base

2017-10-30 Thread Yavor Doganov

On Thu, 26 Oct 2017 11:15:53 +0300,
Emilio Pozuelo Monfort wrote:
> On 25/10/17 10:28, Yavor Doganov wrote:
> > We would like to carry out a gnustep-base transition:
> > libgnustep-base1.24 -> libgnustep-base1.25

> Please go ahead.

1.25.0-2 is built and installed on all arches; please schedule the
binNMUs at your earliest convenience.  Thanks.

Bug#879738: transition: gnustep-base

2017-10-25 Thread Yavor Doganov

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

We would like to carry out a gnustep-base transition:
libgnustep-base1.24 -> libgnustep-base1.25

The major change is the removal of the garbage collector which was
never used in Debian anyway.  Version 1.25.0-1 is in experimental,
built on all arches except powerpcspe (it looks like it has some
trouble catching up).  We tested all reverse dependencies; there are
two packages which FTBFS [1] but they have been fixed in
unstable/testing so can be binNMUed with the rest.

I don't expect any sourceful uploads for the rdeps.
The automatically generated ben tracker looks correct to me.

Ben file:

title = "gnustep-base";
is_affected = .depends ~ "libgnustep-base1.24" | .depends ~ 
"libgnustep-base1.25";
is_good = .depends ~ "libgnustep-base1.25";
is_bad = .depends ~ "libgnustep-base1.24";

[1] 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?which=tag&users=pkg-gnustep-maintain...@lists.alioth.debian.org&data=gnustep-base1.25-transition

Bug#771645: unblock: systempreferences.app/1.2.0-2

2014-11-30 Thread Yavor Doganov

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

Please unblock package systempreferences.app, it fixes RC bug #768764.

unblock systempreferences.app/1.2.0-2
diff --git a/debian/changelog b/debian/changelog
index 54c2d5d..81fa231 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+systempreferences.app (1.2.0-2) unstable; urgency=medium
+
+  * debian/libpreferencepanes-dev.install:
+  * debian/libpreferencepanes1.install: Update for gnustep-make/2.6.6-3
+(Closes: #768764).
+  * debian/control (libpreferencepanes-dev) : Add
+libpreferencepanes1 (<< 1.2.0-2).
+
+ -- Yavor Doganov   Fri, 28 Nov 2014 09:38:58 +0200
+
 systempreferences.app (1.2.0-1) unstable; urgency=medium
 
   * New upstream release:
diff --git a/debian/control b/debian/control
index da555f6..626929f 100644
--- a/debian/control
+++ b/debian/control
@@ -31,8 +31,10 @@ Depends: libpreferencepanes1 (= ${binary:Version}),
 	 libgnustep-gui-dev,
 	 ${gnustep:Depends},
 	 ${misc:Depends}
-Breaks: systempreferences.app (<< 1.2.0)
-Replaces: systempreferences.app (<< 1.2.0)
+Breaks: systempreferences.app (<< 1.2.0),
+	libpreferencepanes1 (<< 1.2.0-2)
+Replaces: systempreferences.app (<< 1.2.0),
+	  libpreferencepanes1 (<< 1.2.0-2)
 Description: GNUstep preferences library - development files
  System Preferences is an application which allows one to manage the
  settings of many aspects of the GNUstep environment and its
diff --git a/debian/libpreferencepanes-dev.install b/debian/libpreferencepanes-dev.install
index b06fc00..0f9eba9 100644
--- a/debian/libpreferencepanes-dev.install
+++ b/debian/libpreferencepanes-dev.install
@@ -3,6 +3,7 @@ usr/lib/*.so
 usr/lib/GNUstep/Frameworks/*.framework/Versions/?/Headers
 usr/lib/GNUstep/Frameworks/*.framework/Versions/?/PreferencePanes
 usr/lib/GNUstep/Frameworks/*.framework/Versions/?/*.so
+usr/lib/GNUstep/Frameworks/*.framework/Versions/Current
 usr/lib/GNUstep/Frameworks/*.framework/PreferencePanes
 usr/lib/GNUstep/Frameworks/*.framework/*.so
 usr/lib/GNUstep/Frameworks/*.framework/Headers
diff --git a/debian/libpreferencepanes1.install b/debian/libpreferencepanes1.install
index 5eccb12..8aa5ddf 100644
--- a/debian/libpreferencepanes1.install
+++ b/debian/libpreferencepanes1.install
@@ -1,5 +1,3 @@
 usr/lib/*.so.*
 usr/lib/GNUstep/Frameworks/*.framework/Versions/?/*.so.*
 usr/lib/GNUstep/Frameworks/*.framework/Versions/?/Resources
-usr/lib/GNUstep/Frameworks/*.framework/Versions/Current
-usr/lib/GNUstep/Frameworks/*.framework/Resources

Bug#770497: unblock: gnustep-back/0.24.0-4

2014-11-21 Thread Yavor Doganov

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

Please unblock package gnustep-back, it fixes RC bug #770141.

Debdiff attached.

unblock gnustep-back/0.24.0-4
diff --git a/debian/changelog b/debian/changelog
index e392e3c..2bb4641 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+gnustep-back (0.24.0-4) unstable; urgency=medium
+
+  * debian/patches/cairo-scrolling.patch: New; fix scrolling with
+cairo/1.14.0 (Closes: #770141).
+  * debian/patches/series: Update.
+
+ -- Yavor Doganov   Wed, 19 Nov 2014 08:11:48 +0200
+
 gnustep-back (0.24.0-3) unstable; urgency=medium
 
   * debian/gnustep-back-common.postinst: Ignore errors from mv which lead
diff --git a/debian/patches/cairo-scrolling.patch b/debian/patches/cairo-scrolling.patch
new file mode 100644
index 000..055fbab
--- /dev/null
+++ b/debian/patches/cairo-scrolling.patch
@@ -0,0 +1,21 @@
+Description: Disable workaround for a cairo bug fixed in 1.14.0.
+Bug-Debian: http://bugs.debian.org/770141
+Origin: upstream, commit: r38135
+Last-Update: 2014-11-19
+---
+
+--- gnustep-back-0.24.0.orig/Source/cairo/CairoGState.m
 gnustep-back-0.24.0/Source/cairo/CairoGState.m
+@@ -1316,9 +1316,10 @@
+   ssize = [source->_surface size];
+ }
+ 
+-  if (cairo_version() >= CAIRO_VERSION_ENCODE(1, 8, 0))
++  if ((cairo_version() >= CAIRO_VERSION_ENCODE(1, 8, 0))
++  && (cairo_version() <= CAIRO_VERSION_ENCODE(1, 13, 0)))
+ {  
+-  // For cairo > 1.8 we seem to need this adjustment
++  // For cairo > 1.8 and < 1.13 we seem to need this adjustment
+   srcRectInBase.origin.y -= 2 * (source->offset.y - ssize.height);
+ }
+ 
diff --git a/debian/patches/series b/debian/patches/series
index 82c2919..98e673d 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,4 @@
+cairo-scrolling.patch
 fontconfig-libs.patch
 format-security.patch
 debian-fonts.patch

Bug#770360: unblock: pantomime1.2/1.2.2~r289+dfsg-2

2014-11-20 Thread Yavor Doganov

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

Please unblock package pantomime1.2, it fixes RC bug #756852 by using
the GNUstep NSFileHandle extensions instead of the OpenSSL library
(the patch was tested extensively with gnumail).

pantomime1.2 (1.2.2~r289+dfsg-2) unstable; urgency=medium

  * debian/patches/gnutls.patch: New; use GnuTLS via gnustep-base instead
of OpenSSL to avoid licensing issues with lusernet.app and gnumail
(Closes: #756852).
  * debian/patches/series: Update.
  * debian/control (Build-Depends): Require gnustep-base (>= 1.24.6) for
proper GSTLS support.  Remove libssl-dev.

 -- Yavor Doganov   Thu, 30 Oct 2014 17:35:36 +0200

Debdiff attached.

unblock pantomime1.2/1.2.2~r289+dfsg-2
diff --git a/debian/changelog b/debian/changelog
index b552335..f5a74eb 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+pantomime1.2 (1.2.2~r289+dfsg-2) unstable; urgency=medium
+
+  * debian/patches/gnutls.patch: New; use GnuTLS via gnustep-base instead
+of OpenSSL to avoid licensing issues with lusernet.app and gnumail
+(Closes: #756852).
+  * debian/patches/series: Update.
+  * debian/control (Build-Depends): Require gnustep-base (>= 1.24.6) for
+proper GSTLS support.  Remove libssl-dev.
+
+ -- Yavor Doganov   Thu, 30 Oct 2014 17:35:36 +0200
+
 pantomime1.2 (1.2.2~r289+dfsg-1) unstable; urgency=medium
 
   * New upstream release:
diff --git a/debian/control b/debian/control
index 74b34a8..16359ae 100644
--- a/debian/control
+++ b/debian/control
@@ -5,8 +5,7 @@ Maintainer: Debian GNUstep maintainers 
 Build-Depends: cdbs,
 	   debhelper (>= 7),
-	   libgnustep-base-dev,
-	   libssl-dev
+	   libgnustep-base-dev (>= 1.24.6)
 Standards-Version: 3.9.5
 Vcs-Git: git://anonscm.debian.org/pkg-gnustep/pantomime.git
 Vcs-Browser: http://anonscm.debian.org/gitweb/?p=pkg-gnustep/pantomime.git
diff --git a/debian/patches/gnutls.patch b/debian/patches/gnutls.patch
new file mode 100644
index 000..0ee2e5d
--- /dev/null
+++ b/debian/patches/gnutls.patch
@@ -0,0 +1,207 @@
+Description: Use GnuTLS instead of OpenSSL to avoid licensing issues.
+Author: Yavor Doganov 
+Bug-Debian: https://bugs.debian.org/756852
+Forwarded: http://lists.nongnu.org/archive/html/gap-dev-discuss/2014-08/msg0.html
+Last-Update: 2014-10-30
+---
+
+--- pantomime.orig/Framework/Pantomime/CWTCPConnection.h
 pantomime/Framework/Pantomime/CWTCPConnection.h
+@@ -24,13 +24,6 @@
+ #define _Pantomime_H_CWTCPConnection
+ 
+ #include 
+-
+-#define id openssl_id
+-#define MD5 MDFIVE
+-#include 
+-#undef MD5
+-#undef id
+-
+ #import 
+ 
+ /*!
+@@ -56,8 +49,8 @@
+ 
+ BOOL _dns_resolution_completed;
+ 
+-SSL_CTX *_ctx;
+-SSL *_ssl;
++void *_ctx;
++void *_ssl;
+ }
+ 
+ /*!
+--- pantomime.orig/Framework/Pantomime/CWTCPConnection.m
 pantomime/Framework/Pantomime/CWTCPConnection.m
+@@ -26,8 +26,7 @@
+ #include 
+ #include 
+ 
+-#include 
+-#include  //test
++#import 
+ 
+ #include 
+ #include 
+@@ -53,6 +52,14 @@
+ #include   // For FIONBIO on Solaris
+ #endif
+ 
++#if WITH_OPENSSL
++#define id openssl_id
++#define MD5 MDFIVE
++#include 
++#undef MD5
++#undef id
++#endif
++
+ #define DEFAULT_TIMEOUT 60
+ 
+ //
+@@ -65,6 +72,13 @@
+ 
+ @end
+ 
++#if !WITH_OPENSSL
++/* Private GSFileHandle methods...  */
++@interface NSFileHandle (UglyHack)
++- (NSInteger) read: (void*)buf length: (NSUInteger)len;
++- (NSInteger) write: (const void*)buf length: (NSUInteger)len;
++@end
++#endif
+ 
+ //
+ //
+@@ -73,8 +87,18 @@
+ 
+ + (void) initialize
+ {
++#if WITH_OPENSSL
+   SSL_library_init();
+   SSL_load_error_strings();
++#else
++  if (![NSFileHandle respondsToSelector: @selector(sslClass)])
++[NSException raise: NSInternalInconsistencyException
++		format: @"Apparently running on Mac OS X - building "
++		 @"`with-openssl=yes' is mandatory"];
++  if (![NSFileHandle sslClass])
++[NSException raise: NSInternalInconsistencyException
++		format: @"GNUstep Base built without GnuTLS/OpenSSL support"];
++#endif
+ }
+ 
+ //
+@@ -201,6 +225,7 @@
+   [[NSNotificationCenter defaultCenter] removeObserver: self];
+   RELEASE(_name);
+ 
++#if WITH_OPENSSL
+   if (_ssl)
+ {
+   SSL_free(_ssl);
+@@ -210,7 +235,11 @@
+ {
+   SSL_CTX_free(_ctx);
+ }
+-  
++#else
++  if (_ssl)
++RELEASE((NSFileHandle *)_ssl);
++#endif
++
+   [super dealloc];
+ }
+ 
+@@ -309,7 +338,11 @@
+ 
+   if (_ssl)
+ {
++#if WITH_OPENSSL
+   SSL_shutdown(_ssl);
++#else
++  [(NSFileHandle *)_ssl sslDisconnect];
++#endif
+ }
+ 
+   safe_close(_fd);
+@@ -330,7 +363,11 @@
+ 
+   if (_ssl)
+ {
++#if WITH_OPENSSL
+   return SSL_read(_ssl, buf, len);
++#else
++  return [(NSFileHandle *)_ssl read: buf length: len];
++#endif
+ }
+ 
+   return safe_recv(_fd, buf, len, 0);
+@@ -350,7 +387,11 @@
+ 
+   if (_ssl)
+ {
++#if WITH_OPENSSL
+   return SS

Bug#770207: wheezy-pu: package gnustep-base/1.22.1-4+deb7u1

2014-11-19 Thread Yavor Doganov

Package: release.debian.org
Severity: normal
Tags: wheezy
User: release.debian@packages.debian.org
Usertags: pu

I would like to update the gnustep-base package in wheezy to fix
CVE-2014-2980 (user security hole, medium severity, no DSA) and
probably more importantly RC bug #753603.

Both patches are from upstream, and I've been testing them on a wheezy
system for a few weeks with no ill effects. 

Proposed debdiff against the version in stable attached.
diff --git a/debian/changelog b/debian/changelog
index 598d7bc..b0513e0 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+gnustep-base (1.22.1-4+deb7u1) wheezy; urgency=medium
+
+  * debian/patches/CVE-2014-2980.patch: New; fixes user security hole in
+gdomap (Closes: #745470).
+  * debian/patches/performSelector-forwarding.patch: New; fixes regression
+in -performSelector: with message forwarding (Closes: #753603).
+  * debian/patches/series: Update.
+
+ -- Yavor Doganov   Wed, 19 Nov 2014 19:25:07 +0200
+
 gnustep-base (1.22.1-4) unstable; urgency=low
 
   * debian/rules (build-arch): Depend on the patch target to ensure that
diff --git a/debian/patches/CVE-2014-2980.patch b/debian/patches/CVE-2014-2980.patch
new file mode 100644
index 000..579ded4
--- /dev/null
+++ b/debian/patches/CVE-2014-2980.patch
@@ -0,0 +1,72 @@
+Description: Fix user security hole in gdomap (CVE-2014-2980).
+Bug: https://savannah.gnu.org/bugs/?41751
+Bug-Debian: https://bugs.debian.org/745470
+Origin: upstream, commit: r37756
+Last-Update: 2014-11-19
+---
+
+--- gnustep-base.orig/Tools/gdomap.c
 gnustep-base/Tools/gdomap.c
+@@ -279,7 +279,7 @@
+ 
+ #if	defined(HAVE_SYSLOG)
+ 
+-static int	log_priority;
++static int	log_priority = 0;
+ 
+ static void
+ gdomap_log (int prio)
+@@ -4417,16 +4417,7 @@
+   const char	*machine = 0;
+   const char	*lookupf = 0;
+   int		donamesf = 0;
+-
+-#if	defined(HAVE_SYSLOG)
+-  /* Initially, gdomap_log errors to stderr as well as to syslogd. */
+-#if	defined(SYSLOG_4_2)
+-  openlog ("gdomap", LOG_NDELAY);
+-  log_priority = LOG_DAEMON;
+-#else
+-  openlog ("gdomap", LOG_NDELAY, LOG_DAEMON);
+-#endif
+-#endif
++  int   forked = 0;
+ 
+ #if	defined(__MINGW__)
+   WORD wVersionRequested;
+@@ -4778,7 +4769,6 @@
+ #else
+   if (nofork == 0)
+ {
+-  is_daemon = 1;
+   /*
+*	Now fork off child process to run in background.
+*/
+@@ -4792,6 +4782,7 @@
+ 	/*
+ 	 *	Try to run in background.
+ 	 */
++  forked = 1;
+ #if	defined(NeXT)
+ 	setpgrp(0, getpid());
+ #else
+@@ -4851,6 +4842,19 @@
+ 
+ #endif /* !__MINGW__ */
+ 
++  if (forked)
++{
++  is_daemon = 1;
++#if	defined(HAVE_SYSLOG)
++#if	defined(SYSLOG_4_2)
++  openlog ("gdomap", LOG_NDELAY);
++  log_priority = LOG_DAEMON;
++#else
++  openlog ("gdomap", LOG_NDELAY, LOG_DAEMON);
++#endif
++#endif
++}
++
+   init_my_port();	/* Determine port to listen on.		*/
+   init_ports();		/* Create ports to handle requests.	*/
+ 
diff --git a/debian/patches/performSelector-forwarding.patch b/debian/patches/performSelector-forwarding.patch
new file mode 100644
index 000..3b4be34
--- /dev/null
+++ b/debian/patches/performSelector-forwarding.patch
@@ -0,0 +1,99 @@
+Description: Fix regression in -performSelector: with message forwarding.
+Bug: https://savannah.gnu.org/bugs/?36706
+Bug-Debian: https://bugs.debian.org/753603
+Origin: upstream, commit: r35278, r35279
+Last-Update: 2014-11-19
+---
+
+--- gnustep-base.orig/Source/GSFFIInvocation.m
 gnustep-base/Source/GSFFIInvocation.m
+@@ -185,6 +185,14 @@
+ 	}
+   if (nil == sig)
+ 	{
++  if (nil == receiver)
++{
++  /* If we have a nil receiver, so the runtime is probably trying
++   * to check for forwarding ... return NULL to let it fall back
++   * on the standard forwarding mechanism.
++   */
++  return NULL;
++}
+ 	  [NSException raise: NSInvalidArgumentException
+ 	format: @"%c[%s %s]: unrecognized selector sent to instance %p",
+ 	(class_isMetaClass(c) ? '+' : '-'),
+--- gnustep-base.orig/Source/NSObject.m
 gnustep-base/Source/NSObject.m
+@@ -1448,13 +1448,15 @@
+   if (aSelector == 0)
+ [NSException raise: NSInvalidArgumentException
+ 		format: @"%@ null selector given", NSStringFromSelector(_cmd)];
+-  /*
+-   *	If 'self' is an instance, object_getClass() will get the class,
+-   *	and class_getMethodImplementation() will get the instance method.
+-   *	If 'self' is a class, object_getClass() will get the meta-class,
+-   *	and class_getMethodImplementation() will get the class method.
++  /* The Apple runtime API would do:
++   * return class_getMethodImplementation(object_getClass(self), aSelector);
++   * but this cannot ask self for information about any method reached by
++   * forwarding, so the returned

Bug#769623: unblock: dbuskit/0.1.1-2

2014-11-14 Thread Yavor Doganov

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

Please unblock package dbuskit, it fixes RC bug #768616.

Debdiff attached.

unblock dbuskit/0.1.1-2
diff --git a/debian/changelog b/debian/changelog
index da0e24f..a2436ba 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+dbuskit (0.1.1-2) unstable; urgency=medium
+
+  * debian/libdbuskit-dev.install:
+  * debian/libdbuskit0.install: Update for gnustep-make/2.6.6-3 (Closes:
+#768616).
+
+ -- Yavor Doganov   Mon, 10 Nov 2014 09:08:54 +0200
+
 dbuskit (0.1.1-1) unstable; urgency=low
 
   * Initial release (Closes: #675962).
diff --git a/debian/libdbuskit-dev.install b/debian/libdbuskit-dev.install
index 502d1e5..7f6d650 100644
--- a/debian/libdbuskit-dev.install
+++ b/debian/libdbuskit-dev.install
@@ -4,6 +4,7 @@ usr/lib/lib*.so
 usr/lib/GNUstep/Frameworks/DBusKit.framework/Versions/?/*.so
 usr/lib/GNUstep/Frameworks/DBusKit.framework/Versions/?/Headers
 usr/lib/GNUstep/Frameworks/DBusKit.framework/Versions/?/DBusKit
+usr/lib/GNUstep/Frameworks/DBusKit.framework/Versions/Current
 usr/lib/GNUstep/Frameworks/DBusKit.framework/DBusKit
 usr/lib/GNUstep/Frameworks/DBusKit.framework/*.so
 usr/lib/GNUstep/Frameworks/DBusKit.framework/Headers
diff --git a/debian/libdbuskit0.install b/debian/libdbuskit0.install
index 00921c3..23e5c0c 100644
--- a/debian/libdbuskit0.install
+++ b/debian/libdbuskit0.install
@@ -1,5 +1,3 @@
 usr/lib/lib*.so.*
 usr/lib/GNUstep/Frameworks/DBusKit.framework/Versions/?/*.so.*
 usr/lib/GNUstep/Frameworks/DBusKit.framework/Versions/?/Resources
-usr/lib/GNUstep/Frameworks/DBusKit.framework/Versions/Current
-usr/lib/GNUstep/Frameworks/DBusKit.framework/Resources

Bug#768923: unblock: rsskit/0.3-3

2014-11-11 Thread Yavor Doganov

tags 768923 - moreinfo
thanks

Jonathan Wiltshire wrote:
> On 2014-11-10 08:13, Yavor Doganov wrote:
> > Please approve rsskit/0.3-3 to fix FTBFS bug #768749 via t-p-u.

> Please ping this bug and remove moreinfo when it's uploaded.

Done, thanks.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87a93xpi6p.GNUs_not_UNIX!%ya...@gnu.org

Bug#768923: unblock: rsskit/0.3-3

2014-11-10 Thread Yavor Doganov

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

Please approve rsskit/0.3-3 to fix FTBFS bug #768749 via t-p-u.  The
bug is fixed in the version in unstable (0.4-1) but as this is a new
upstream release with a SONAME bump it is not applicable for jessie.

(My initial plan was to upload this new release way before the
transition freeze but I was waiting for upstream comments for the
relevant gnustep-make RC bug and was MIA for a few months so it didn't
work out as intended).

Proposed debdiff attached.

unblock rsskit/0.3-3
diff --git a/debian/changelog b/debian/changelog
index 2cd85b2..721024a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+rsskit (0.3-3) testing-proposed-updates; urgency=medium
+
+  * debian/librsskit-dev.install:
+  * debian/librsskit0.install: Update for gnustep-make/2.6.6-3 (Closes:
+#768749).
+
+ -- Yavor Doganov   Mon, 10 Nov 2014 09:44:38 +0200
+
 rsskit (0.3-2) unstable; urgency=low
 
   * debian/rules (binary-arch): Invoke dh_makeshlibs.
diff --git a/debian/librsskit-dev.install b/debian/librsskit-dev.install
index 86500d5..6ebcde6 100644
--- a/debian/librsskit-dev.install
+++ b/debian/librsskit-dev.install
@@ -3,6 +3,7 @@ usr/lib/lib*.so
 usr/lib/GNUstep/Frameworks/RSSKit.framework/Versions/0/*.so
 usr/lib/GNUstep/Frameworks/RSSKit.framework/Versions/0/Headers
 usr/lib/GNUstep/Frameworks/RSSKit.framework/Versions/0/RSSKit
+usr/lib/GNUstep/Frameworks/RSSKit.framework/Versions/Current
 usr/lib/GNUstep/Frameworks/RSSKit.framework/RSSKit
 usr/lib/GNUstep/Frameworks/RSSKit.framework/*.so
 usr/lib/GNUstep/Frameworks/RSSKit.framework/Headers
diff --git a/debian/librsskit0.install b/debian/librsskit0.install
index 9b9f871..96b2c80 100644
--- a/debian/librsskit0.install
+++ b/debian/librsskit0.install
@@ -1,5 +1,3 @@
 usr/lib/libRSSKit.so.*
 usr/lib/GNUstep/Frameworks/RSSKit.framework/Versions/0/*.so.*
 usr/lib/GNUstep/Frameworks/RSSKit.framework/Versions/0/Resources
-usr/lib/GNUstep/Frameworks/RSSKit.framework/Versions/Current
-usr/lib/GNUstep/Frameworks/RSSKit.framework/Resources

Bug#767725: unblock: gorm.app/1.2.20-2

2014-11-02 Thread Yavor Doganov

reopen 767725
thanks

Niels Thykier wrote:
> On 2014-11-02 07:50, Yavor Doganov wrote:
> > unblock gorm.app/1.2.20-2
> 
> Sorry, but I will have to decline your request.  The RC bug does not
> affect testing (as gorm.app is not in testing) and therefore not
> applicable for neither ageing nor an unblock.

AFAICS gorm.app/1.2.20-1 is in testing.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87wq7dn9eu.GNUs_not_UNIX!%ya...@gnu.org

Bug#767725: unblock: gorm.app/1.2.20-2

2014-11-02 Thread Yavor Doganov

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

Please unblock package gorm.app, it fixes RC bug #767066.

Debdiff attached.

unblock gorm.app/1.2.20-2
diff --git a/debian/changelog b/debian/changelog
index 05e150b..7f3e549 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+gorm.app (1.2.20-2) unstable; urgency=medium
+
+  * debian/patches/fix-gorm-loading.patch: New; fixes a crash when loading
+gorm files with ImageMagick-enabled gnustep-gui (Closes: #767066).
+  * debian/patches/series: Update.
+
+ -- Yavor Doganov   Sat, 01 Nov 2014 22:24:15 +0200
+
 gorm.app (1.2.20-1) unstable; urgency=medium
 
   * New upstream release:
diff --git a/debian/patches/fix-gorm-loading.patch b/debian/patches/fix-gorm-loading.patch
new file mode 100644
index 000..fa5e663
--- /dev/null
+++ b/debian/patches/fix-gorm-loading.patch
@@ -0,0 +1,26 @@
+Description: Fix crash when loading gorm files exposed by GSImageMagickImageRep
+Bug-Debian: https://bugs.debian.org/767066
+Bug: http://savannah.gnu.org/bugs/index.php?42782
+Origin: upstream, commit: r38136
+Last-Update: 2014-11-01
+---
+
+--- gorm.app.orig/GormCore/GormWrapperLoader.m
 gorm.app/GormCore/GormWrapperLoader.m
+@@ -77,6 +77,16 @@
+ 	  while((key = [enumerator nextObject]) != nil)
+ 	{
+ 	  NSFileWrapper *fw = [fileWrappers objectForKey: key];
++
++	  //
++	  // Images with .info can be loaded, but we have a file
++	  // called data.info which is metadata for Gorm.  Don't load it.
++	  //
++	  if ( [key isEqualToString: @"data.info"] == YES )
++		{
++		  continue;
++		}
++
+ 	  if([fw isRegularFile])
+ 		{
+ 		  NSData *fileData = [fw regularFileContents];
diff --git a/debian/patches/series b/debian/patches/series
index 8ced3ab..e1f579f 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
+fix-gorm-loading.patch
 texinfo-fixes.patch
 link-libs.patch

Bug#767724: unblock: viewpdf.app/1:0.2dfsg1-5

2014-11-02 Thread Yavor Doganov

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

Please unblock package viewpdf.app, it fixes RC bug #756588.

unblock viewpdf.app/1:0.2dfsg1-5
diff --git a/debian/changelog b/debian/changelog
index 561b471..3b25078 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+viewpdf.app (1:0.2dfsg1-5) unstable; urgency=medium
+
+  * debian/patches/fix-NSView-crash.patch: New; fix a crash on i386 when
+opening a PDF file (Closes: #756588).
+  * debian/patches/series: Update.
+
+ -- Yavor Doganov   Fri, 31 Oct 2014 18:33:36 +0200
+
 viewpdf.app (1:0.2dfsg1-4) unstable; urgency=low
 
   * debian/control (Maintainer, Uploaders): Adopt package, make the
diff --git a/debian/patches/fix-NSView-crash.patch b/debian/patches/fix-NSView-crash.patch
new file mode 100644
index 000..18bd9a5
--- /dev/null
+++ b/debian/patches/fix-NSView-crash.patch
@@ -0,0 +1,29 @@
+Description: Fix crash on i386 when opening a PDF file.
+Author: Yavor Doganov 
+Bug-Debian: https://bugs.debian.org/756588
+Forwarded: not-needed
+Last-Update: 2014-10-31
+---
+
+--- vindaloo.app.orig/CenteringClipView.m
 vindaloo.app/CenteringClipView.m
+@@ -28,6 +28,9 @@
+ 
+ - (void) centerDocumentView
+ {
++  if (![self documentView])
++return;
++
+NSRect docRect = [[self documentView] frame];
+NSRect clipRect = [self bounds];
+ 
+@@ -53,6 +56,9 @@
+ // origin point.
+ - (NSPoint) constrainScrollPoint: (NSPoint)proposedNewOrigin
+ {
++  if (![self documentView])
++return [self bounds].origin;
++
+NSRect docRect = [[self documentView] frame];
+NSRect clipRect = [self bounds];
+NSPoint newScrollPoint = proposedNewOrigin;
diff --git a/debian/patches/series b/debian/patches/series
index ab5a9c3..e2c00af 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
+fix-NSView-crash.patch
 rename.patch

Bug#767723: unblock: addresses-for-gnustep/0.4.7-2

2014-11-02 Thread Yavor Doganov

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

Please unblock package addresses-for-gnustep, it fixes RC bug #749721
which also lead to the removal of agenda.app from testing.

Debdiff attached.

unblock addresses-for-gnustep/0.4.7-2
diff --git a/Frameworks/AddressView/ADPersonPropertyView.h b/Frameworks/AddressView/ADPersonPropertyView.h
index 4f94b43..334e437 100644
--- a/Frameworks/AddressView/ADPersonPropertyView.h
+++ b/Frameworks/AddressView/ADPersonPropertyView.h
@@ -122,7 +122,7 @@ typedef enum {
 - (void) beginEditingInLastCell;
 - (void) endEditing;
 
-- (int) indexOfEditableCellWithDetails: (id) details;
+- (NSUInteger) indexOfEditableCellWithDetails: (id) details;
 
 - (NSString*) propertyForDragWithDetails: (id) details;
 - (NSImage*) imageForDraggedProperty: (NSString*) prop;
diff --git a/Frameworks/AddressView/ADPersonPropertyView.m b/Frameworks/AddressView/ADPersonPropertyView.m
index 37b4df3..d976c54 100644
--- a/Frameworks/AddressView/ADPersonPropertyView.m
+++ b/Frameworks/AddressView/ADPersonPropertyView.m
@@ -626,9 +626,9 @@ static float _globalFontSize;
   [self beginEditingInCellAtIndex: [_cells count]-1 countingBackwards: YES];
 }
 
-- (int) indexOfEditableCellWithDetails: (id) details
+- (NSUInteger) indexOfEditableCellWithDetails: (id) details
 {
-  int i;
+  NSUInteger i;
 
   for(i=0; i<[_cells count]; i++)
 {
diff --git a/Frameworks/AddressView/ADPersonView.m b/Frameworks/AddressView/ADPersonView.m
index d512929..901ca0c 100644
--- a/Frameworks/AddressView/ADPersonView.m
+++ b/Frameworks/AddressView/ADPersonView.m
@@ -205,6 +205,7 @@ static NSString *__defaultCountryCode = nil;
   int y;
   NSRect noteRect;
   id label;
+  NSString *note;
 
   properties = [NSArray arrayWithObjects: ADHomePageProperty,
 			ADPhoneProperty,
@@ -270,7 +271,9 @@ static NSString *__defaultCountryCode = nil;
   [_noteView setVerticallyResizable: YES];
   [_noteView setHorizontallyResizable: YES];
   [_noteView setDelegate: self];
-  [_noteView setString: [_person valueForProperty: ADNoteProperty]];
+  note = [_person valueForProperty: ADNoteProperty];
+  if (note != nil)
+[_noteView setString: note];
   [_noteView setFont: [NSFont systemFontOfSize: _fontSize]];
   _noteTextChanged = NO;
 
diff --git a/Frameworks/Addresses/ADMultiValue.h b/Frameworks/Addresses/ADMultiValue.h
index dd61750..dff9ead 100644
--- a/Frameworks/Addresses/ADMultiValue.h
+++ b/Frameworks/Addresses/ADMultiValue.h
@@ -31,7 +31,7 @@
 - (NSString*) labelAtIndex: (int) index;
 - (NSString*) identifierAtIndex: (int) index;
 
-- (int) indexForIdentifier: (NSString*) identifier;
+- (NSUInteger) indexForIdentifier: (NSString*) identifier;
 
 - (NSString*) primaryIdentifier;
 
diff --git a/Frameworks/Addresses/ADMultiValue.m b/Frameworks/Addresses/ADMultiValue.m
index 9ad538a..81880f8 100644
--- a/Frameworks/Addresses/ADMultiValue.m
+++ b/Frameworks/Addresses/ADMultiValue.m
@@ -15,7 +15,7 @@
 /* my includes */
 #include "ADMultiValue.h"
 
-#define IS_A(obj,cls) [obj isKindOf: [cls class]]
+#define IS_A(obj,cls) [obj isKindOfClass: [cls class]]
 
 static ADPropertyType _propTypeFromDict(NSDictionary *dict)
 {
@@ -91,9 +91,9 @@ static ADPropertyType _propTypeFromDict(NSDictionary *dict)
   return [[_arr objectAtIndex: index] objectForKey: @"ID"];
 }
 
-- (int) indexForIdentifier: (NSString*) identifier
+- (NSUInteger) indexForIdentifier: (NSString*) identifier
 {
-  int i;
+  NSUInteger i;
 
   for(i=0; i<[_arr count]; i++)
 if([[[_arr objectAtIndex: i] objectForKey: @"ID"]
diff --git a/Frameworks/Addresses/ADPListConverter.m b/Frameworks/Addresses/ADPListConverter.m
index 14ac5c7..558f719 100644
--- a/Frameworks/Addresses/ADPListConverter.m
+++ b/Frameworks/Addresses/ADPListConverter.m
@@ -29,7 +29,7 @@
 - (BOOL) useString: (NSString*) str
 {
   _plist = [str propertyList];
-  if(![_plist isKindOf: [NSDictionary class]])
+  if(![_plist isKindOfClass: [NSDictionary class]])
 {
   NSLog(@"String (%@) does not contain valid property list!\n", str);
   return NO;
diff --git a/debian/changelog b/debian/changelog
index c4f491f..754d079 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+addresses-for-gnustep (0.4.7-2) unstable; urgency=medium
+
+  * Team upload.
+  * Apply minimal fix to make the package usable with the current GNUstep
+libraries (Closes: #749721):
+- Fix overflow in implicit constant conversion;
+- Fix improper use of non-existent method;
+- Do not set string of a NSTextView to nil.
+
+ -- Yavor Doganov   Wed, 29 Oct 2014 11:25:10 +0200
+
 addresses-for-gnustep (0.4.7-1) unstable; urgency=low
 
   * New upstream release.

Bug#767722: unblock: gnustep-netclasses/1.06.dfsg-7

2014-11-01 Thread Yavor Doganov

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

Please unblock package gnustep-netclasses, it fixes RC bug #755514.

Debdiff attached.

unblock gnustep-netclasses/1.06.dfsg-7
diff --git a/debian/changelog b/debian/changelog
index a45be46..50c01e3 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+gnustep-netclasses (1.06.dfsg-7) unstable; urgency=medium
+
+  * debian/patches/NSUInteger-fixes.patch: New; fixes bug with joining a
+channel on 64-bit architectures (Closes: #755514).
+  * debian/patches/series: Update.
+
+ -- Yavor Doganov   Wed, 29 Oct 2014 17:56:36 +0200
+
 gnustep-netclasses (1.06.dfsg-6) unstable; urgency=medium
 
   * debian/source/format: Switch to 3.0 (quilt).
diff --git a/debian/patches/NSUInteger-fixes.patch b/debian/patches/NSUInteger-fixes.patch
new file mode 100644
index 000..b3d90d5
--- /dev/null
+++ b/debian/patches/NSUInteger-fixes.patch
@@ -0,0 +1,61 @@
+Description: NSUInteger fixes for 64-bit platforms.
+Bug-Debian: https://bugs.debian.org/755514
+Origin: upstream, commit: r2540
+Last-Update: 2014-10-29
+---
+
+--- gnustep-netclasses.orig/Source/IRCObject.m
 gnustep-netclasses/Source/IRCObject.m
+@@ -143,7 +143,7 @@
+ 	
+ #define NEXT_NON_SPACE(__y, __z, __string)\
+ {\
+-	int __len = [(__string) length];\
++	NSUInteger __len = [(__string) length];\
+ 	id set = [NSCharacterSet whitespaceCharacterSet];\
+ 	__z = (__y);\
+ 	while (__z < __len && \
+@@ -152,9 +152,9 @@
+ 
+ static inline NSString *get_IRC_prefix(NSString *line, NSString **prefix)
+ {
+-	int beg;
+-	int end;
+-	int len = [line length];
++	NSUInteger beg;
++	NSUInteger end;
++	NSUInteger len = [line length];
+ 	
+ 	if (len == 0)
+ 	{
+@@ -205,9 +205,9 @@
+ 	
+ static inline NSString *get_next_IRC_word(NSString *line, NSString **prefix)
+ {
+-	int beg;
+-	int end;
+-	int len = [line length];
++	NSUInteger beg;
++	NSUInteger end;
++	NSUInteger len = [line length];
+ 	
+ 	if (len == 0)
+ 	{
+@@ -440,7 +440,7 @@
+ static void rec_part(IRCObject *client, NSString *command,
+  NSString *prefix, NSArray *paramList)
+ {
+-	int x;
++	NSUInteger x;
+ 	
+ 	if (!prefix)
+ 	{	
+@@ -565,7 +565,7 @@
+  NSArray *paramList)
+ {
+ 	NSArray *newParams;
+-	int x;
++	NSUInteger x;
+ 	
+ 	if (!prefix)
+ 	{
diff --git a/debian/patches/series b/debian/patches/series
index c354cf7..a4a526d 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,4 @@
+NSUInteger-fixes.patch
 gcc-warnings.patch
 fix-log-format.patch
 link-libs.patch

Bug#767720: unblock: gnustep-back/0.24.0-3

2014-11-01 Thread Yavor Doganov

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

Please unblock (or reduce age-days accordingly) package gnustep-back;
it fixes RC bugs #663388 and #764695.

Debdiff attached.

unblock gnustep-back/0.24.0-3
diff --git a/debian/changelog b/debian/changelog
index 2d65c8e..e392e3c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,16 @@
+gnustep-back (0.24.0-3) unstable; urgency=medium
+
+  * debian/gnustep-back-common.postinst: Ignore errors from mv which lead
+to failure when font directories do not contain spaces, thanks Thomas
+Zell (Closes: #764695).
+  * debian/gnustep-back-common.prerm: Revert bogus change introduced in
+0.24.0-1 (finally closes: #663388).
+  * debian/control.m4 (Standards-Version): Bump to 3.9.6; no changes
+needed.
+  * debian/control: Regenerate.
+
+ -- Yavor Doganov   Tue, 28 Oct 2014 11:17:15 +0200
+
 gnustep-back (0.24.0-2) unstable; urgency=medium
 
   * Upload to unstable; should finally fix the piuparts issue once
diff --git a/debian/control b/debian/control
index cfa37b4..6efa135 100644
--- a/debian/control
+++ b/debian/control
@@ -4,7 +4,7 @@ Priority: optional
 Maintainer: Debian GNUstep maintainers 
 Uploaders: Gürkan Sengün ,
 	   Yavor Doganov 
-Standards-Version: 3.9.5
+Standards-Version: 3.9.6
 Build-Depends: debhelper (>= 9),
 	   m4,
 	   libgnustep-gui-dev (>= 0.24),
diff --git a/debian/control.m4 b/debian/control.m4
index 90bc3fc..bd8a058 100644
--- a/debian/control.m4
+++ b/debian/control.m4
@@ -4,7 +4,7 @@ Priority: optional
 Maintainer: Debian GNUstep maintainers 
 Uploaders: Gürkan Sengün ,
 	   Yavor Doganov 
-Standards-Version: 3.9.5
+Standards-Version: 3.9.6
 Build-Depends: debhelper (>= 9),
 	   m4,
 	   libgnustep-gui-dev (>= V_GUI),
diff --git a/debian/gnustep-back-common.postinst b/debian/gnustep-back-common.postinst
index f7b0645..a0b02c5 100644
--- a/debian/gnustep-back-common.postinst
+++ b/debian/gnustep-back-common.postinst
@@ -15,9 +15,9 @@ case "$1" in
 	  mknfonts $(fc-list : file | grep -v '\.gz' | cut -d: -f1) \
 	  2>/var/log/gnustep-back-common.log \
 	|| (echo " failed, see /var/log/gnustep-back-common.log."; exit 1)
-	# Remove whitespace in directories.
+	# Remove whitespace in directories, if any.
 	for dir in *\ */; do
-	  mv "$dir" `echo $dir | tr -d [:space:]`
+	  (mv "$dir" `echo $dir | tr -d [:space:]`) || true
 	done
 	echo " done."
 ;;
diff --git a/debian/gnustep-back-common.prerm b/debian/gnustep-back-common.prerm
index c0ee512..beb52ac 100644
--- a/debian/gnustep-back-common.prerm
+++ b/debian/gnustep-back-common.prerm
@@ -4,9 +4,6 @@ set -e
 case "$1" in
 remove)
 	rm -rf /var/lib/GNUstep
-	;;
-purge)
-	rm -rf /var/lib/GNUstep
 	rm -f /var/log/gnustep-back-common.log
 	;;
 upgrade|deconfigure)

Bug#767721: unblock: gnustep-dl2/0.12.0-13

2014-11-01 Thread Yavor Doganov

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

Please unblock (or reduce age-days) for package gnustep-dl2, it fixes
FTBFS bug #759832.

unblock gnustep-dl2/0.12.0-13
diff --git a/debian/changelog b/debian/changelog
index 69b2bd7..03a2ce3 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+gnustep-dl2 (0.12.0-13) unstable; urgency=medium
+
+  * Team upload.
+  * debian/control (Build-Depends): Replace gorm.app with libgorm-dev
+(Closes: #759832).
+
+ -- Yavor Doganov   Wed, 29 Oct 2014 18:35:54 +0200
+
 gnustep-dl2 (0.12.0-12) unstable; urgency=low
   [Yavor Doganov]
   * debian/patches/581934.patch: fixes to prevent NSInvalidArgumentException
diff --git a/debian/control b/debian/control
index ac291ed..1c58325 100644
--- a/debian/control
+++ b/debian/control
@@ -3,8 +3,15 @@ Section: gnustep
 Priority: optional
 Maintainer: Federico Gimenez Nieto 
 Uploaders: Debian GNUstep maintainers 
-Build-Depends: debhelper (>= 7), libgnustep-gui-dev, libpq-dev, librenaissance0-dev, 
-   libsqlite3-dev, gorm.app, texinfo, texlive-latex-base, imagemagick
+Build-Depends: debhelper (>= 7),
+	   libgnustep-gui-dev,
+	   libpq-dev,
+	   librenaissance0-dev, 
+   libsqlite3-dev,
+	   libgorm-dev,
+	   texinfo,
+	   texlive-latex-base,
+	   imagemagick
 Standards-Version: 3.9.5
 Vcs-Git: git://git.debian.org/pkg-gnustep/gnustep-dl2.git
 Vcs-Browser: http://git.debian.org/?p=pkg-gnustep/gnustep-dl2.git

Bug#767694: unblock: gnustep-gui/0.24.0-3

2014-11-01 Thread Yavor Doganov

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

Please unblock (or reduce age-days) package gnustep-gui, it fixes RC
bugs #754825 and #755823.  (It's being held by gnustep-base/1.24.7-1
which I believe is due to migrate without your intervention on
November 5th.)

Debdiff attached.

unblock gnustep-gui/0.24.0-3
diff --git a/debian/changelog b/debian/changelog
index 85ccf2b..3626063 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,16 @@
+gnustep-gui (0.24.0-3) unstable; urgency=medium
+
+  * debian/patches/xib-loading.patch: New; fixes a crash with XIB
+decoding/loading (Closes: #754825).
+  * debian/patches/gorm-loading.patch: New; fixes a crash in Gorm
+loading (Closes: #755823).
+  * debian/patches/series: Update.
+  * debian/control.m4 (Standards-Version): Bump to 3.9.6; no changes
+needed.
+  * debian/control: Regenerate.
+
+ -- Yavor Doganov   Tue, 28 Oct 2014 09:39:18 +0200
+
 gnustep-gui (0.24.0-2) unstable; urgency=medium
 
   * Upload to unstable.
diff --git a/debian/control b/debian/control
index 0fe9e0d..2398c52 100644
--- a/debian/control
+++ b/debian/control
@@ -4,7 +4,7 @@ Priority: optional
 Maintainer: Debian GNUstep maintainers 
 Uploaders: Gürkan Sengün ,
 	   Yavor Doganov 
-Standards-Version: 3.9.5
+Standards-Version: 3.9.6
 Build-Depends: debhelper (>= 9),
 	   m4,
 	   libgnustep-base-dev (>= 1.24.6),
diff --git a/debian/control.m4 b/debian/control.m4
index 4f80e2d..5b33272 100644
--- a/debian/control.m4
+++ b/debian/control.m4
@@ -4,7 +4,7 @@ Priority: optional
 Maintainer: Debian GNUstep maintainers 
 Uploaders: Gürkan Sengün ,
 	   Yavor Doganov 
-Standards-Version: 3.9.5
+Standards-Version: 3.9.6
 Build-Depends: debhelper (>= 9),
 	   m4,
 	   libgnustep-base-dev (>= V_BASE),
diff --git a/debian/patches/gorm-loading.patch b/debian/patches/gorm-loading.patch
new file mode 100644
index 000..82530ab
--- /dev/null
+++ b/debian/patches/gorm-loading.patch
@@ -0,0 +1,18 @@
+Description: Fix crash in Gorm loading.
+Bug: http://savannah.gnu.org/bugs/index.php?42782
+Bug-Debian: http://bugs.debian.org/755823
+Origin: upstream, commit: r38005
+Last-Update: 2014-10-28
+---
+
+--- gnustep-gui.orig/Source/GSGormLoading.m
 gnustep-gui/Source/GSGormLoading.m
+@@ -892,7 +892,7 @@
+ 	  // decode the defer flag...
+ 	  [coder decodeValueOfObjCType: @encode(BOOL) at: &_deferFlag];  
+ 	  _autoPositionMask = GSWindowAutoPositionNone;
+-	  _screenRect = [[_object screen] frame];
++	  _screenRect = [[obj screen] frame];
+ 	}
+ 
+   // FIXME: The designated initializer logic for NSWindow is in the initWithCoder: method of
diff --git a/debian/patches/series b/debian/patches/series
index 56c0e09..b5eb35d 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,3 @@
+gorm-loading.patch
+xib-loading.patch
 info-direntry.patch
diff --git a/debian/patches/xib-loading.patch b/debian/patches/xib-loading.patch
new file mode 100644
index 000..1caf686
--- /dev/null
+++ b/debian/patches/xib-loading.patch
@@ -0,0 +1,93 @@
+Description: Fix crash in XIB loading.
+Bug: http://savannah.gnu.org/bugs/index.php?42717
+Bug-Debian: http://bugs.debian.org/754825
+Origin: upstream, commit: r38003
+Last-Update: 2014-07-24
+---
+
+--- gnustep-gui-0.24.0.orig/Source/NSBox.m
 gnustep-gui-0.24.0/Source/NSBox.m
+@@ -572,6 +572,10 @@
+ 
+   [self setBorderType: borderType];
+ }
++  else
++{
++  _border_type = NSGrooveBorder;
++}
+   if ([aDecoder containsValueForKey: @"NSTitlePosition"])
+ {
+   NSTitlePosition titlePosition = [aDecoder decodeIntForKey: 
+@@ -579,6 +583,10 @@
+   
+   [self setTitlePosition: titlePosition];
+ }
++  else
++{
++  _title_position = NSAtTop;
++}
+   if ([aDecoder containsValueForKey: @"NSTransparent"])
+ {
+   // On Apple this is always NO, we keep it for old GNUstep archives
+@@ -598,12 +606,27 @@
+   
+   ASSIGN(_cell, titleCell);
+ }
++  else
++{
++  _cell = [[NSCell alloc] initTextCell: @"Title"];
++  [_cell setAlignment: NSCenterTextAlignment];
++  [_cell setBordered: NO];
++  [_cell setEditable: NO];
++  [self setTitleFont: [NSFont systemFontOfSize:
++[NSFont smallSystemFontSize]]];
++}
+   if ([aDecoder containsValueForKey: @"NSContentView"])
+ {
+   NSView *contentView = [aDecoder decodeObjectForKey: @"NSContentView"];
+ 
+   [self setContentView: contentView];
+ }
++  else
++{
++  NSView *cv = [NSView new];
++  [self setContentView: cv];
++  RELEASE(cv);
++}
+ }
+   else
+ {
+@@ -662,6 +685,12 @@
+   return r;
+ }
+ 
++  // Don

Bug#673538: transition: gnustep-base, gnustep-gui

2014-07-08 Thread Yavor Doganov

Emilio Pozuelo Monfort wrote:
> Looks like meson and uwsgi build depend on gnustep but don't link to
> it. So most likely they don't need it and the build dependency could
> be dropped.

Well, meson is a build system, there could be legitimate reasons for
the build-dependency (determining compiler flags, etc.).  It can't
link anyway as it is an arch:all package written in Python.

For uwsgi, I think it is a bug that it doesn't link with the GNUstep
libraries, see #753724.

BTW, I'm curious why were gnustep-back and openvpn-auth-ldap binNMUed?
That was unnecessary.  Probably due to some automated setup.

-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87ion7izeo.GNUs_not_UNIX!%ya...@gnu.org

Bug#673538: transition: gnustep-base, gnustep-gui

2014-07-08 Thread Yavor Doganov

Emilio Pozuelo Monfort wrote:
> Everything else looks good, so please go ahead.

Thanks; gnustep-base and -gui are now built and installed on all
architectures.  Please schedule the binNMUs at your earliest
convenience.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87k37oi8og.GNUs_not_UNIX!%ya...@gnu.org

Bug#673538: transition: gnustep-base, gnustep-gui

2014-07-07 Thread Yavor Doganov

Yavor Doganov wrote:
> I'm waiting for gnustep-back to get ACCEPTed and built everywhere.
> Once done, we're basically ready (I only have to backport my
> gnustep-base patch for the gnutls transition).

ACCEPTed and built on almost all release architectures (mipsen
slightly lagging behind).  Please let me know when it is OK to upload
to unstable.  I gather we must wait for the poppler transition to
complete.

-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87vbr9ip9g.GNUs_not_UNIX!%ya...@gnu.org

Bug#673538: transition: gnustep-base, gnustep-gui

2014-07-06 Thread Yavor Doganov

At Sun, 06 Jul 2014 11:41:07 +0200,
Paul Gevers wrote:
> On 03-07-14 18:44, Yavor Doganov wrote:
> >>> I'll ping you when the new core packages pass through NEW, OK?
> >>
> >> I don't see gnustep-gui 0.24 in NEW or in the archive. Was that ever
> >> uploaded?  How are things looking here?

Release team: gnustep-gui/0.24 is already in experimental (thanks Aron
Xu and Luca Falavigna).  I'm waiting for gnustep-back to get ACCEPTed
and built everywhere.  Once done, we're basically ready (I only have
to backport my gnustep-base patch for the gnutls transition).

> It seems the GNUStep team is seriously lacking some help to upload its
> packages. I can only assume that there is no DD on your team (or that
> the team consists of one person). 

The team consists of three people nowadays -- Gürkan Sengün, Federico
Gimenez Nieto and myself.  None of us is DD/DM.  The last DD in the
team stepped down 5 years ago.

> I am will to help with this transition by reviewing prepared
> packages and uploading.

Thanks.

> What exactly do you think is needed, all uploads related to [1]? Are
> the specific for this transition, or can they be done beforehand
> straight into unstable?

Everything that is at mentors.d.n is suitable for uploading to
unstable.  I'm holding back the packages that depend on the new
libraries.

> How sure are you that they are real problems, I read you say they
> *may* lead to issues. Is there a way to check? 

The way to check is to run the application, trying to test every bit
of functionaility on as many architectures as possible, or careful
code review.  Both are very time consuming tasks.

> Which bugs you think *must* be fixed for this transition to be
> successful?

It depends which bit of the functionality of the package is affected.
If it makes the package mostly unusable then it is obviously a RC bug.
I plan to test all of them and adjust the severities accordingly.

I would like to fix all found bugs before the freeze, regardless of
their severity.  We also want to ship the newest upstream releases,
and not versions that are obsolete and/or known to be buggy.
Currently there is a very bad publicity towards Debian in the GNUstep
community because of the wheezy release and the current status.  There
are forked Debian/Ubuntu packages maintained in a PPA which nearly
every debianized GNUstepper is using.  We definitely want to make
amends here.

> I have one request. As I don't know GNUStep and its apps (I haven't
> used any package of it before that I am aware of)

There is nothing special, really.  Things are a little bit boxy,
that's all.  aclock.app should be able to display the current time in
the clock, textedit.app should be able to do what a basic text editor
does, etc.  There are some specialized apps like adun.app or
cenon.app, I don't know how to write a proper README.testing for
those.

> We started adding these README.testing files to packages maintained
> by the accessibility team to aid team members and I really like the
> idea.

Yes, the idea is good, but that is too much work for us currently.  Is
it going to be proprosed for standartization?  If I'm going to do
this, I'd better write a proper manual for the benefit of all users.

> For an example of what I mean you can look at daisy-player

If the package doesn't have decent documentation, large bits of this
file are suitable for README.Debian, IMHO.

--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/8761jaft8y.GNUs_not_UNIX!%ya...@gnu.org

Bug#673538: transition: gnustep-base, gnustep-gui

2014-07-03 Thread Yavor Doganov

Emilio Pozuelo Monfort wrote:
> On 28/05/14 03:29, Yavor Doganov wrote:
> > libgnustep-base1.22 -> 1.24
> > libgnustep-gui0.20  -> 0.24
> 
> I have updated the tracker for that.

Thanks.

> As for libobj3 -> libobj4, there's just openvpn-auth-ldap remaining,
> which is #747989.

I'll take a look.

> What can block it is gnustep-base failing on s390x (it may be
> failing on other architectures as well, as the others were built 2
> years ago and have never been retried):

It will fail, yes, but this bug is fixed in 1.24.6-1.
Regardless, -base and -gui will fail to build everywhere due to a
(serious) bug in gnustep-make.  That's also fixed in
gnustep-make/2.6.6-2 but not uploaded yet.  See #752833 for details.

> > I rebuilt all GNUstep packages in the archive and fortunately there
> > are only two FTBFS bugs -- #749553 (cenon.app) and #749554 (sogo).
> 
> I see one is fixed and the other one has a patch.

The patch attached to the bug is not entirely correct; the right fix
is in cenon.app.git.

I filed about ~30 bugs [1] based on build logs examination only (very
weak criteria for Objective-C code).  Some are not so important
problems that have been around for a while but others are RC
candidates.  Most packages are ready for upload with a fix available.
Few of the fixes depend on the new libraries.  These bugs won't block
the transition in the trivial sense, but we must make sure they don't
sneak into jessie.  Basically, all GNUstep packages will probably need
to be updated due to the new types NS(U)Integer and CGFloat, otherwise
they will be broken at least on 64-bit architectures.

[1]
https://bugs.debian.org/cgi-bin/pkgreport.cgi?which=tag&users=pkg-gnustep-maintain...@lists.alioth.debian.org&data=gnustep-base1.24-transition
http://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=gnustep-transition&user=pkg-gnustep-maintainers%40lists.alioth.debian.org

> > I'll ping you when the new core packages pass through NEW, OK?
> 
> I don't see gnustep-gui 0.24 in NEW or in the archive. Was that ever
> uploaded?  How are things looking here?

No, unfortunately nobody volunteered to sponsor them [2] yet...  My
past sponsors are apparently busy and/or not interested anymore, so
we're a bit stuck at the moment.  I guess patience is the key.

[2]
https://bugs.debian.org/cgi-bin/pkgreport.cgi?include=originator%3Ayavor%40gnu.org;dist=unstable;package=sponsorship-requests

-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87oax6fl2u.GNUs_not_UNIX!%ya...@gnu.org

Bug#673538: transition: gnustep-base, gnustep-gui

2014-05-27 Thread Yavor Doganov

On Sat, Apr 26, 2014 at 12:44:45PM +0200, Philipp Kern wrote:
> Yavor, is there any plan to do the transition? #673538 didn't look
> like it was blocking on us.

Please accept my apologies for being MIA for so long.

I have the new GNUstep core packages ready at mentors.d.n (targeted
for experimental, of course).  There were new upstream releases in the
meantime, so we'll omit -gui0.22 entirely.  IOW:

libgnustep-base1.22 -> 1.24
libgnustep-gui0.20  -> 0.24

I rebuilt all GNUstep packages in the archive and fortunately there
are only two FTBFS bugs -- #749553 (cenon.app) and #749554 (sogo).
gnustep-dl2 also fails to build, but that's due to the
texi2html->makeinfo switch in gnustep-make and is trivial to fix (I'll
report the bug tomorrow).  In the next few days I'll examine the build
logs for compiler warnings and will report those issues that may lead
to problems at runtime.

I'll ping you when the new core packages pass through NEW, OK?

-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140528012959.ga26...@aneto.yavor.doganov.org

Bug#673538: libobjc3 -> libobjc4 transition

2012-07-02 Thread Yavor Doganov

At Sun, 01 Jul 2012 00:02:17 +0100,
Adam D. Barratt wrote:
> On Fri, 2012-06-29 at 21:20 +0300, Yavor Doganov wrote:
> > Uploading gnustep-base/1.22.1 with the libobjc4 patch will allow
> > the package to be built with gcc-4.7 on x86 archs, and with
> > gcc-4.6 on the other (where 4.6 is still the default).  [...]  The
> > patch is ABI compatible, so no recompilation should be necessary;
> > I can confirm this after my runtime tests.
> 
> That would presumably be one or both of the patches from
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667868#12 ?

Yes, both of them.

> If we postponed the main transition(s) until wheezy+1, would the
> gnustep-base upload be the only thing required for wheezy?

Yes, it would be the only thing needed if we talk about the core
GNUstep packages (-make, -base, -gui, -back).  We'll have to fix the
RC bugs in the other packages, but that goes without saying.



-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87obnxhm8v.GNUs_Not_Unix!%ya...@gnu.org

Bug#673538: libobjc3 -> libobjc4 transition

2012-06-29 Thread Yavor Doganov

Adam D. Barratt wrote:
> On 29.06.2012 14:29, Jeroen Dekkers wrote:
> > I just read that there might not be time to do the transition, but
> > this bug actually combined two transitions: the libobjc transition
> > and the gnustep transition. If the gnustep transition isn't going
> > to happen, we still need to finish libobjc4 transition on the
> > archs that have gcc 4.7 as default, right?

I don't think we *have* to, see below.

> My understanding was that if necessary (which given that the freeze is 
> tomorrow it might be), this could be resolved without a transition by 
> having gnustep-make explicitly depend on gobjc-4.6 for the wheezy cycle; 
> see #676229.
> 
> Yavor, is that correct?

You are correct that if the Release Team decides to postpone the
transition after the wheezy release, we we will resolve the current
problem without a transition (neither libgnustep-* nor libobjc).

You are not correct that we'll have to revert the change in
gnustep-make (the dependency on gobjc-4.6).  It was a hack in the
first place, and depending on gobjc-4.6 implies a transition -- at
least all GNUstep packages that were built since gcc-4.7 became the
default need to be rebuilt.  I don't see any benefit in doing this; we
may as well have a full GNUstep & libobjc transition instead.

Uploading gnustep-base/1.22.1 with the libobjc4 patch will allow the
package to be built with gcc-4.7 on x86 archs, and with gcc-4.6 on the
other (where 4.6 is still the default).  Thus, all GNUstep packages
that were recently built will depend on libobjc4 on x86, and on
libobjc3 on the rest of the architectures, as is expected.  The patch
is ABI compatible, so no recompilation should be necessary; I can
confirm this after my runtime tests.

Some GNUstep packages that were built with gcc-4.6 during the last
transition and were not touched since then (such as gtamsanalyzer.app)
will still depend on both libobjc3 on x86 (via their Depends:) and
libobjc4 (indirectly via their libgnustep-base1.22 dependency), but
libobjc.so.4 will be loaded first during GNUstep Base initialization,
so there won't be runtime issues.

The only problem for these apps is cosmetic (useless dependency on
libobjc3), but since gcc-4.6 is going to be shipped in wheezy anyway
and libobjc3 is of small size (presumably not a big problem for most
users), it is in no way critical.

-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87txxuvv2v.GNUs_Not_Unix!%ya...@gnu.org

Bug#673538: transition: gnustep-base, gnustep-gui, libobjc

2012-06-27 Thread Yavor Doganov

Mehdi Dogguy wrote:
> On 26/06/2012 20:27, Yavor Doganov wrote:
> > gnustep-dl2:   DBModeler aborts on startup with NSInvalidArgumentException
> > textedit.app:  Cannot create new documents or open existing text files
> 
> and are they fixable?

As I'm not familiar with the code, I'll have to investigate.  In
principle, everything is fixable or at least should be.

> Besides, do we have a fix for #663388?

Yep, that is trivial.



-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87395gyd92.GNUs_Not_Unix!%ya...@gnu.org

Bug#673538: transition: gnustep-base, gnustep-gui, libobjc

2012-06-26 Thread Yavor Doganov

Mehdi Dogguy wrote:
> On 20/06/2012 13:20, Yavor Doganov wrote:
> > No, but I'm going to do it now.
> 
> Any news?

Yes, with gnustep-base built with the patch I have prepared I found
only two grave issues so far:

gnustep-dl2:   DBModeler aborts on startup with NSInvalidArgumentException
textedit.app:  Cannot create new documents or open existing text files

Every other package seems to work properly without recompilation or
any special intervention (having in mind that I haven't tested every
bit of the provided functionality).

-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87vcieormf.GNUs_Not_Unix!%ya...@gnu.org

Bug#673538: transition: gnustep-base, gnustep-gui, libobjc

2012-06-20 Thread Yavor Doganov

Mehdi Dogguy wrote:
> Do you have an idea on which fixes are needed to be backported if we
> don't have time to do a transition?

Yes.

> Did you test them?

No, but I'm going to do it now.  The changes are minimal but are in a
hairy area and that makes me feel uneasy.  This combination has never
been tested upstream either.

If we have to resort to that route (no transition), then we'd need:

1) a sourceful upload of gnustep-base with the gcc-4.7/libobjc4 fix
2) binNMUs for gnustep-gui on some architectures (amd64 only, at first
   glance)
3) fix for #663388, either in gnustep-back or mknfonts.tool



-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871ulakz6c.GNUs_Not_Unix!%ya...@gnu.org

Bug#673538: transition: gnustep-base, gnustep-gui, libobjc

2012-06-01 Thread Yavor Doganov

On Sat, May 19, 2012 at 05:33:05PM +0300, Yavor Doganov wrote:
> I'll let you know of all the issues once we have the core packages
> ready.

It's looking good, I think -- gnustep-base/1.24, gnustep-gui/0.22 and
gnustep-back/0.22 are in experimental.  Summary of the bugs/issues:

gcc-4.7/libobjc4 [1]: 12 bugs total
  8 fixed
  1 "fixed" by package removal
  3 marked as "pending"

gnustep-base1.24 [2]: 2 bugs total
  1 fixed
  1 to fix (the package is not testing)

gnustep-gui0.22 [3]:  1 bug total
  1 marked as "pending"

Other issues: gnustep-back/0.22.0-1 FTBFS on the buildds, it's trivial
to fix.

Looking forward to your permission to upload -base/-gui to unstable.

[1] 
http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=tag&users=debian-...@lists.debian.org&data=ftbfs-gcc-4.7
[2] 
http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=tag&users=pkg-gnustep-maintain...@lists.alioth.debian.org&data=gnustep-base1.24-transition
[3] 
http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=tag&users=pkg-gnustep-maintain...@lists.alioth.debian.org&data=gnustep-gui0.22-transition



-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120601155854.ga20...@yavor.doganov.org

Bug#673538: transition: gnustep-base, gnustep-gui, libobjc

2012-05-19 Thread Yavor Doganov

Cyril Brulebois wrote:
> What happens if the gcc-defaults switch is finally reverted?

You'd have to schedule binNMUs on all archs where 4.7 is the default.
The same if 4.7 becomes the default compiler on more architectures, as
Matthias Klose indicated on our list.

Either way, the current state is broken, because -base is linked with
libobjc3 while -gui is mixed because it failed to built at that time,
so many GNUstep packages are unusable because they end up linking with
two ObjC runtimes.  We'll either have to fix this with a transition
(preferable for us), or backport the fixes for gnustep-base and binNMU
gnustep-gui where it is needed.

> I wouldn't bother too much gathering all involved packages, I'll just
> set up a tracker, which should determine those and the dependencies
> between them.

OK, thanks.  I'll let you know of all the issues once we have the core
packages ready.

-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ehqg6y1q.GNUs_Not_Unix!%ya...@gnu.org

Bug#673538: transition: gnustep-base, gnustep-gui, libobjc

2012-05-19 Thread Yavor Doganov

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

We'd like to carry out a GNUstep transition prior to the forthcoming release:

libgnustep-base1.22 -> 1.24
libgnustep-gui0.20  -> 0.22
libobjc3-> 4 (on architectures where gcc-4.7 is the default)

I plan to upload the new GNUstep stack to experimental within a few
days, then make a test rebuild of all GNUstep packages and identify
all bugs (GCC-related bugs have already been reported); then I'll
follow up with a summary of affected packages.

Thanks.



-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120519130703.3544.57597.reportbug@hatch

Bug#629477: transition: gnustep-base, gnustep-gui, libobjc

2011-09-08 Thread Yavor Doganov

On Mon, Sep 05, 2011 at 08:37:35PM +0200, Julien Cristau wrote:
> We'd like to have a list of packages which are part of this transition.

Dependency level 1 (build-depends only on libgnustep-base-dev):

biococoa
gnustep-netclasses
mknfonts.tool
oolite
pantomime1.2

Dependency level 2 (build-depends on libgnustep-gui-dev):

aclock.app
addresses-for-gnustep
adun.app
affiche
batmon.app
biococoa.app
camera.app
cenon.app
charmap.app
cynthiune.app
easydiff.app
edenmath.app
etoile
ftp.app
gnustep-examples
gomoku.app
gorm.app
gridlock.app
grr.app
gtamsanalyzer.app
helpviewer.app
lusernet.app (also b-d on libpantomime1.2)
lynkeos.app
mines.app
mpdcon.app
paje.app
plopfolio.app
poe.app
popplerkit.framework
preview.app
price.app
projectcenter.app
projectmanager.app
renaissance
shisen.app
stepbill.app
systempreferences.app
talksoup.app (also b-d on libnetclasses-dev)
terminal.app
textedit.app
timemon.app
volumecontrol.app
wrapperfactory.app

Dependency level 3 (gnustep-gui + at least one GUI-based ObjC library)

agenda.app (b-d on libaddresses-dev)
gnumail (b-d on libaddresses-dev, libaddressview-dev, libpantomime1.2-dev)
gnustep-dl2 (b-d on librenaissance0-dev, gorm.app)
gworkspace (b-d on libpopplerkit-dev)
viewpdf.app (b-d on libpopplerkit-dev)
zipper.app (b-d on librenaissance0-dev)

Dependency level 4 (gnustep-gui + a library from level 3)

steptalk (b-d on libgnustep-dl2-dev)

> Either as an explicit list, or a description such as 'build-depends on
> foo or bar'.  And then a way to check whether such a package is
> transitioned or not, e.g. 'depends on libfooX' vs 'depends on libfooY'.

libgnustep-base1.20 vs libgnustep-base1.22
libgnustep-gui0.18 vs libgnustep-gui0.20

Please let me know if further information is required.



-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110908074857.ga22...@southway-varna.com

Bug#629477: transition: gnustep-base, gnustep-gui, libobjc

2011-09-05 Thread Yavor Doganov

At Thu, 25 Aug 2011 21:39:10 +0200,
Julien Cristau wrote:
> On Thu, Aug 18, 2011 at 12:13:47 +0200, Philipp Kern wrote:
> > On Tue, Jun 07, 2011 at 02:03:58AM +0300, Yavor Doganov wrote:
> > > We would like to carry out a GNUstep transition
> > > (libgnustep-base1.20->1.22; libgnustep-gui0.18->0.20) *and*
> > > libobjc2->3, ideally coinciding with the migration of gcc-defaults to
> > > testing (or even better, before that).
> > 
> > That seems pretty complex to check with our existing tools.  But
> > to get an overview, can you please tell us the relevant
> > development packages people are build-depending on?  And a list of
> > affected packages to check the result.
> > 
> Ping?

Apologies for the delay.

I'm afraid I don't understand the question -- do you want a list of
other (non-GNUstep) libraries possibly affecting the transition
(poppler, ffmpeg, etc.) or you'd like to know which of the GNUstep
packages depend on gnustep-gui and which only on gnustep-base?

The GNU ObjC runtime (libobjc3) doesn't have a development package;
any GNUstep package built with the current toolchain ends up linking
against it, which inevitably leads to a crash when the program is
being run.

-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ehzv3q3d.GNUs_Not_Unix!%ya...@gnu.org

Bug#629477: transition: gnustep-base, gnustep-gui, libobjc

2011-06-08 Thread Yavor Doganov

Julien Cristau wrote:
> On Tue, Jun  7, 2011 at 21:44:15 +0300, Yavor Doganov wrote:
> > 1) The modified gnustep-make package will have no trouble migrating to
> >testing (before the transition even commences), so it would make
> >GNUstep development in wheezy broken, just like it is now in sid.
> > 
> Broken how?

Packages end up linking with libobjc3, while -base and -gui are linked
with libobjc2.

> > 2) Building the GNUstep packages with the non-default compiler on ia64
> >and sparc is, strictly speaking, a policy violation.
> > 
> What part of policy?

None; it appears I am making a mistake.  I was pretty sure that there
was something like "Packages should be built with the default
compiler", but it seems I was wrong.



-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zklsp4nf.GNUs_Not_Unix!%ya...@gnu.org

Bug#629477: transition: gnustep-base, gnustep-gui, libobjc

2011-06-07 Thread Yavor Doganov

Matthias Klose wrote:
> On 06/07/2011 01:33 AM, Yavor Doganov wrote:
> > gnustep-base/1.22.0-1 currently build-depends on gobjc (>= 4:4.6).
> > My plan was to change it to "gobjc (>= 4:4.6) [!ia64 !sparc],
> > gobjc-4.6".  Is that good enough?
> 
> no, for that case, you need to use gcc-4.6 as the driver. If you
> want to do this, maybe make the change in gnustep-make and let the
> gnustep-make package depend on gcc-4.6.

Two questions arise:

1) The modified gnustep-make package will have no trouble migrating to
   testing (before the transition even commences), so it would make
   GNUstep development in wheezy broken, just like it is now in sid.

2) Building the GNUstep packages with the non-default compiler on ia64
   and sparc is, strictly speaking, a policy violation.

If the release team does not object, we can go on and make gobjc-4.6 a
strict requirement via gnustep-make.

-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ipshbhxc.GNUs_Not_Unix!%ya...@gnu.org

Bug#629477: transition: gnustep-base, gnustep-gui, libobjc

2011-06-06 Thread Yavor Doganov

Matthias Klose wrote:
> On 06/07/2011 01:03 AM, Yavor Doganov wrote:
> > We would like to carry out a GNUstep transition
> > (libgnustep-base1.20->1.22; libgnustep-gui0.18->0.20) *and*
> > libobjc2->3, ideally coinciding with the migration of gcc-defaults to
> > testing (or even better, before that).
> 
> please make sure that you either use gobjc-4.6 explicitly, or that
> you allow differing defaults depending on the platform.

gnustep-base/1.22.0-1 currently build-depends on gobjc (>= 4:4.6).  My
plan was to change it to "gobjc (>= 4:4.6) [!ia64 !sparc], gobjc-4.6".
Is that good enough?

> > * gcc-4.5 is still the default compiler on ia64 and sparc.

> it's 4.4.

I stand corrected; it doesn't make any difference, I guess.

> this transition should wait (for unstable) until the multiarch
> enabled GCC packages are in testing.

OK.



-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87y61eo7ra.GNUs_Not_Unix!%ya...@gnu.org

Bug#629477: transition: gnustep-base, gnustep-gui, libobjc

2011-06-06 Thread Yavor Doganov

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

We would like to carry out a GNUstep transition
(libgnustep-base1.20->1.22; libgnustep-gui0.18->0.20) *and*
libobjc2->3, ideally coinciding with the migration of gcc-defaults to
testing (or even better, before that).

All new versions of the core GNUstep packages are already in
experimental. A routine rebuild revealed only 6 bugs, all of them
having a fix available now:

http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=tag&users=pkg-gnustep-maintain...@lists.alioth.debian.org&data=gnustep-base1.22-transition

The latest stable upstream release of gnustep-base (1.22.0) includes
support for the new (modernized) Objective-C runtime in GCC 4.6
(libobjc3). About 3 months ago, the GCC maintainers asked us to
postpone any GNUstep transitions until libobjc3 is available in
unstable [*]; now the transition is inevitable because gcc-4.6 is the
default compiler on most archs.

[*] http://permalink.gmane.org/gmane.linux.debian.devel.gcc/37170

Expected problems:

* gnustep-base now depends on ICU and is thus tied to future ICU
transitions.

* gcc-4.5 is still the default compiler on ia64 and sparc. As
immediate solution, I intend to add (temporarily) gobjc-4.6 to
gnustep-base' Build-Depends; that way the packages will still be
built with the default compiler (4.5), but the new ObjC runtime will
be used.

* A few runtime bugs may pop-up as usual, and as per Murphy's Law will
be discovered post-factum. I hope we can deal with them in due
time, unless there is a scary arch-specific issue like the hppa
excitement during the last transition. TBH, I am quite surprised by
the low number of bugs so far as they hardly correspond to the
drastic changes in -base. It makes me feel somewhat uneasy; we're
used to battle with a lot more problems.

--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110606230358.6909.58336.reportbug@hatch

Re: gnustep-base upload and/or transition required?

2011-05-17 Thread Yavor Doganov

tags 624928 = fixed-upstream
thanks

At Mon, 16 May 2011 20:00:59 -0700,
Matt Kraai wrote:
>  /usr/bin/ld: warning: libobjc.so.2, needed by 
> /usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../lib/libgnustep-base.so, may 
> conflict with libobjc.so.3

Argh, it looks like I missed the moment when GCC 4.6 became the
default compiler; apologies for the slightly inadequate comments at
#624928.

> When I build the package in wheezy, I see no such warning and the
> executables run fine.

Yep, that's because gcc-defaults hasn't migrated yet.

> Is a transition and/or new upload of gnustep-base required to fix
> this?

Definitely.  I suggest to upload 1.22.0 (which has proper support for
the 4.6 ObjC runtime) to experimental along with the rest of the
GNUstep stack and prepare for transition (combined gnustep-base +
gnustep-gui + libobjc).  We'll do the usual tests and fix all known
bugs in advance.

The alternative is to backport the support for the new runtime and
patch -base 1.20.2, then have only a libobjc2->3 transition.  Probably
doable, but too much work, and the result may end up binary
incompatible (in theory it should not, though).  It is also not a very
motivating job considering a GNUstep transition is being planned
anyway.

-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878vu5au5h.GNUs_Not_Unix!%ya...@gnu.org

Bug#596416: unblock: cynthiune.app/0.9.5-11

2010-09-21 Thread Yavor Doganov

reopen 596416
retitle 596416 unblock: cynthiune.app/0.9.5-12
thanks

Julien Cristau wrote:
> On Sat, Sep 11, 2010 at 09:17:24 +0300, Yavor Doganov wrote:
> > unblock cynthiune.app/0.9.5-11
> > age-days 20 cynthiune.app/0.9.5-11
> > 
> Done.  Please make sure if any bad regressions are discovered that
> they're set to RC severity to prevent the migration.

Thanks.  I noticed one problem so far -- the bundle is not built on
armel and powerpcspe.  The fix is a oneliner:

--- cynthiune.app-0.9.5/debian/changelog
+++ cynthiune.app-0.9.5/debian/changelog
@@ -1,3 +1,10 @@
+cynthiune.app (0.9.5-12) unstable; urgency=low
+
+  * debian/patches/ALSA.patch: Adjust makefile conditional to actually
+build the bundle on armel and powerpcspe (Really closes: #576228).
+
+ -- Yavor Doganov   Tue, 21 Sep 2010 22:43:29 +0300
+
 cynthiune.app (0.9.5-11) unstable; urgency=low
 
   * debian/patches/ALSA.patch: New; implement an ALSA output bundle and
--- cynthiune.app-0.9.5/debian/patches/ALSA.patch
+++ cynthiune.app-0.9.5/debian/patches/ALSA.patch
@@ -12,11 +12,13 @@
 
 --- cynthiune.app-0.9.5.orig/GNUmakefile
 +++ cynthiune.app-0.9.5/GNUmakefile
-@@ -94,6 +94,14 @@
+@@ -94,6 +94,16 @@
  
  else
  
-+ifeq (linux-gnu,$(GNUSTEP_TARGET_OS))
++# GNUSTEP_TARGET_OS is defined to `linux-gnueabi' on armel and
++# `linux-gnuspe' on powerpcspe.
++ifneq (,$(findstring linux-gnu,$(GNUSTEP_TARGET_OS)))
 +
 +ifneq (yes,$(disable-alsa))
 +BUNDLES += ALSA



-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87aana48r6.gnus_not_unix!%ya...@gnu.org

Bug#596928: unblock: gnustep-back/0.18.0-3

2010-09-14 Thread Yavor Doganov

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: freeze-exception

Please unblock package gnustep-back to fix an RC bug; the change is a
trivial dependency tweak:

  * debian/control.m4 (gnustep-back-common) : Add ttf-freefont
(Closes: #596059).
  * debian/control: Regenerate.

unblock gnustep-back/0.18.0-3



-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100915054120.770.70295.report...@hatch

Bug#596416: unblock: cynthiune.app/0.9.5-11

2010-09-10 Thread Yavor Doganov

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: freeze-exception

Please unblock package cynthiune.app to fix (unofficial?) release
goal.  If possible, I'd prefer to spend longer period in unstable.
The changelog is:

  * debian/patches/ALSA.patch: New; implement an ALSA output bundle and
make it the default on GNU/Linux (Closes: #576228).
  * debian/patches/kfreebsd-OSS-default.patch: Remove, default now handled
with the above patch.
  * debian/patches/series: Update.
  * debian/control (Build-Depends): Add libasound2-dev [linux-any].
(Standards-Version): Set to 3.9.1 (no changes needed).
  * debian/copyright: Update copyright holders/years.

 cynthiune.app-0.9.5/debian/changelog  |   13 
 cynthiune.app-0.9.5/debian/control|3 
 cynthiune.app-0.9.5/debian/copyright  |1 
 cynthiune.app-0.9.5/debian/patches/series |2 
 debian/patches/ALSA.patch |  402 ++
 debian/patches/kfreebsd-OSS-default.patch |   18 -
 6 files changed, 419 insertions(+), 20 deletions(-)

$ diffstat debian/patches/ALSA.patch 
 GNUmakefile   |8 
 GeneralPreference.m   |   50 -
 cynthiune.app-0.9.5/Bundles/ALSA/ALSA.h   |   40 
 cynthiune.app-0.9.5/Bundles/ALSA/ALSA.m   |  169 ++
 cynthiune.app-0.9.5/Bundles/ALSA/GNUmakefile  |   44 
 cynthiune.app-0.9.5/Bundles/ALSA/GNUmakefile.preamble |   31 +++
 6 files changed, 335 insertions(+), 7 deletions(-)

unblock cynthiune.app/0.9.5-11
age-days 20 cynthiune.app/0.9.5-11



-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100911061724.10851.41819.report...@hatch

Bug#596415: unblock: viewpdf.app/1:0.2dfsg1-3.1

2010-09-10 Thread Yavor Doganov

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: freeze-exception

Please unblock package viewpdf.app, it fixes an RC bug.
debian/changelog:

  * Non-maintainer upload.
  * ViewPDFInfo.plist (NSTypes): Change NSRole to "Viewer", making the app
usable with gnustep-gui/0.18 (Closes: #595763).

 ViewPDFInfo.plist |2 +-
 debian/changelog  |8 
 2 files changed, 9 insertions(+), 1 deletion(-)

unblock viewpdf.app/1:0.2dfsg1-3.1



-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100911060439.10820.60692.report...@hatch

Bug#596412: unblock: terminal.app/0.9.4+cvs20051125-6

2010-09-10 Thread Yavor Doganov

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: freeze-exception

Please unblock package terminal.app; -6 fixes a longstanding RC bug.
The changelog is:

  * Patch to fix rendering bug with new GNUstep version. (Closes: #595764)

 TerminalView.m  |7 ++-
 terminal.app-0.9.4+cvs20051125/debian/changelog |6 ++
 2 files changed, 8 insertions(+), 5 deletions(-)

unblock terminal.app/0.9.4+cvs20051125-6



-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100911055014.10790.38306.report...@hatch

Bug#596411: unblock: gnustep-gui/0.18.0-5

2010-09-10 Thread Yavor Doganov

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: freeze-exception

Please unblock package gnustep-gui, it fixes an RC bug.
The changelog is:

  * debian/patches/untitled-document-loading.patch: New; prevent loading
of untitled document in an NSDocument-based app without an editor type
(Closes: #595757).
  * debian/patches/series: Update.

 debian/patches/untitled-document-loading.patch |   17 +
 gnustep-gui-0.18.0/debian/changelog|9 +
 gnustep-gui-0.18.0/debian/patches/series   |1 +
 3 files changed, 27 insertions(+)

unblock gnustep-gui/0.18.0-5



-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100911054450.10722.8595.report...@hatch

Bug#592616: pu: package bgoffice/3.0-9+lenny1

2010-08-27 Thread Yavor Doganov

В 10:03 +0100 на 27.08.2010 (пт), Adam D. Barratt написа:
> On Fri, August 27, 2010 09:26, Yavor Doganov wrote:
> > Sure, does this mean that with this change the update is approved and
> > can be uploaded?
> 
> I'd prefer a look at an updated debdiff first; I don't envisage there
> being any other issues though.

OK, here it is.
diff -u bgoffice-3.0/debian/changelog bgoffice-3.0/debian/changelog
--- bgoffice-3.0/debian/changelog
+++ bgoffice-3.0/debian/changelog
@@ -1,3 +1,15 @@
+bgoffice (3.0-9+lenny1) stable; urgency=low
+
+  * QA upload.
+  * debian/aspell-bg.postrm: Delete; harmful during upgrades or package
+reinstallation (Closes: #589851).
+  * debian/aspell-bg.postinst: Recover from the old erroneous postrm and
+touch bg{,-en}.rws and bg.compat if the files do not exist.
+  * debian/rules (install): Create an empty var/lib/aspell/bg-en.rws.
+(binary-common): Pass -Xvar/lib/aspell to dh_md5sums.
+
+ -- Yavor Doganov   Fri, 27 Aug 2010 12:14:22 +0300
+
 bgoffice (3.0-9) unstable; urgency=low
 
   * QA upload.
diff -u bgoffice-3.0/debian/aspell-bg.postinst bgoffice-3.0/debian/aspell-bg.postinst
--- bgoffice-3.0/debian/aspell-bg.postinst
+++ bgoffice-3.0/debian/aspell-bg.postinst
@@ -9,6 +9,12 @@
 	bulgarian-aspell-dictionary $DIR/bg-w_english.multi 60
 update-alternatives --install $DIR/bg.multi \
 	bulgarian-aspell-dictionary $DIR/bg-wo_english.multi 40
+	# Touch the files deleted by old postrm (#589851).
+	# FIXME: Remove this snippet post-squeeze.
+	DIRV="/var/lib/aspell"
+	for f in $DIRV/bg.rws $DIRV/bg-en.rws $DIRV/bg.compat; do
+	[ -f $f ] || touch $f;
+	done
 	;;
 
 abort-upgrade|abort-remove|abort-deconfigure)
reverted:
--- bgoffice-3.0/debian/aspell-bg.postrm
+++ bgoffice-3.0.orig/debian/aspell-bg.postrm
@@ -1,21 +0,0 @@
-#!/bin/sh
-
-set -e
-
-case "$1" in
-purge|remove|upgrade|failed-upgrade|abort-install|abort-upgrade|disappear)
-DIR=/var/lib/aspell
-	rm -f $DIR/bg.compat $DIR/bg-en.rws $DIR/bg.rws
-	;;
-
-*)
-echo "postrm called with unknown argument '$1'" >&2
-	exit 1
-;;
-esac
-
-
-#DEBHELPER#
-
-exit 0
-
diff -u bgoffice-3.0/debian/rules bgoffice-3.0/debian/rules
--- bgoffice-3.0/debian/rules
+++ bgoffice-3.0/debian/rules
@@ -102,6 +102,9 @@
 # $WORDLIST is the wordlist filename minus the .*wl.gz extension)
 	install -d debian/aspell-bg/var/lib/aspell/
 	>debian/aspell-bg/var/lib/aspell/bg.rws
+# Make sure dpkg knows about bg-en.rws too, otherwise the file is not
+# deleted upon remove/purge.
+	>debian/aspell-bg/var/lib/aspell/bg-en.rws
 # Add a symlink /usr/lib/aspell/$WORDLIST.rws -> /var/lib/aspell/$WORDLIST.rws
 	install -d debian/aspell-bg/usr/lib/aspell/
 	ln -s /var/lib/aspell/bg.rws debian/aspell-bg/usr/lib/aspell/bg.rws
@@ -144,7 +147,7 @@
 #	dh_perl
 	dh_shlibdeps
 	dh_gencontrol
-	dh_md5sums
+	dh_md5sums -Xvar/lib/aspell
 	dh_builddeb
 
 # Build architecture independant packages using the common target.

Bug#592616: pu: package bgoffice/3.0-9+lenny1

2010-08-27 Thread Yavor Doganov

On Fri, Aug 27, 2010 at 12:06:07AM +0100, Adam D. Barratt wrote:
> On Wed, 2010-08-18 at 17:49 +0300, Yavor Doganov wrote:
> > I disagree, it is me who failed to catch that and forgot to pass
> > -Xvar/lib/aspell to dh_md5sums while preparing -11.
> 
> How about doing this for 3.0-9+lenny1 as well?

Sure, does this mean that with this change the update is approved and 
can be uploaded?



-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100827082655.ga22...@yavor.doganov.org

Re: Bug#561944: GNUstep transition

2010-08-24 Thread Yavor Doganov

Mehdi Dogguy wrote:
> On 08/24/2010 07:31 PM, Yavor Doganov wrote:
> > terminal.app and textedit.app were uploaded to DELAYED/2.
> 
> thanks luk :)

I forgot to say that, sorry :-(

> > The only blocker for the transition seems to be #593898 (provided no
> >  other RC bugs pop up in the meantime).
> 
> I guess you're already working on fixing that?

Yes -- right now I'm waiting for more info from the OP.  If you need a
summary about (my) plan for fixing this bug (here or the #593898 bug
log, as you prefer), just let me know.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877hjfc1qw.gnus_not_unix!%ya...@gnu.org

Bug#561944: GNUstep transition

2010-08-24 Thread Yavor Doganov

On Tue, Aug 10, 2010 at 02:26:48PM +0300, Yavor Doganov wrote:
> Already migrated, so we're launching the GNUstep attack.

gnustep-base/1.20.1-3 is already installed on hppa, and 
gnustep-netclasses built sucessfully (more or less confirming the fix).

Could you please give-back gnustep-gui and schedule binNMUs on hppa for 
all other packages as appropriate?

I have lusernet.app ready, waiting for -gui and pantomime1.2 to become 
available on hppa.

terminal.app and textedit.app were uploaded to DELAYED/2.

Mehdi said he would take care of gnustep-dl2 when the time comes.

The only blocker for the transition seems to be #593898 (provided no 
other RC bugs pop up in the meantime).



-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100824173119.ga10...@yavor.doganov.org

Re: binNMU order of ObjC/GNUstep packages

2010-08-23 Thread Yavor Doganov

Mehdi Dogguy wrote:
> That said, you could also set "good" dependencies like what has been
> done for OCaml packages for instance and make them not installable
> if it doesn't match your criteria

Interesting.  Is dh-ocaml the right package to look at?
If it's not too hard, it'll be nice to implement this for GNUstep
packages too (in squeeze+1, now it's too late for surgeries).

> (which is way better than errors at runtime or hidden breakages).

Undoubtedly.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87pqx9xjpe.gnus_not_unix!%ya...@gnu.org

Re: binNMU order of ObjC/GNUstep packages

2010-08-23 Thread Yavor Doganov

В Mon, 23 Aug 2010 07:55:44 +0200, Mehdi Dogguy написа:
> The transition monitor shows that order. If the order inferred from
> the build-dependencies is incorrect, then there is a problem in your
> packages.

There is no problem with the build-dependencies.  The only problem is
when a package gets uploaded before its dependency is binNMUed, and we
forget to rebuild it afterwards.  The transition monitor does not show
such cases.

> The last one is the only one "affected". I'll schedule the necessary
> binNMU request.

Thanks.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/i4tbr0$pc...@dough.gmane.org

binNMU order of ObjC/GNUstep packages

2010-08-22 Thread Yavor Doganov

[CCing -release because this is a FAQ during GNUstep transitions; hope
you don't mind.]

Mehdi Dogguy wrote:
> On 08/21/2010 05:28 PM, Yavor Doganov wrote:
> > BTW, talksoup.app must be binNMUed on all archs once a binNMUed 
> > gnustep-netclasses is available everywhere.
> 
> I'll schedule the necessary binNMUs. I saw it green on my monitor
> because it depends on new gnustep libs, but has been compiled with
> pre-binNMU gnustep-netclasses. I didn't really test… but is the version
> currently in the archive broken? (can be tested on amd64 and i386).

AFAICT it works, but usually these breakages are discovered
post-factum.

The reason why we insist all apps depending on additional ObjC
libraries to be rebuilt against the *binNMUed* lib is because of the
way ObjC subclassing works.

/* Pseudo code.  */

/* Public class in gnustep-netclasses.  */
@interface IRC : NSString
{
@private
  int _net_ivar;
}
@end

/* Class in the application.  */
@interface TalkSoup : IRC
{
  NSString *soup_ivar;
}
- (void) setNick: (NSString *) nick
@end

Now, consider that NSString in gnustep-base/1.19.3 has 2 ivars, but
the ivar layout is changed in 1.20.x, adding another one (which is not
unusual at all):

@interface NSString : NSObject
{
  unsigned char *_ivar1;
  NSUinteger _ivar2;
+ CGFloat _ivar3;
}
@end

When the app is being run, and new instances of the TalkSoup class are
created, the ObjC runtime determines the size of the class in order to
allocate it.  The size of the class is the size of the ivars of the
root class NSObject (the so called "isa" pointer) plus the size of the
ivars of NSString (_ivar1, _ivar2, _ivar3), plus the size of the ivars
of the IRC class (_net_ivar), plus the size of TalkSoup's own ivars
(soup_ivar).  The overall size may grow or shrink depending on the
changes in the ivar layout throughout the class hierarchy.  That's the
main reason for the frequent GNUstep transitions we have in Debian;
it's very easy to break the ABI of an Objective-C library.

When the application code then invokes the -[TalkSoup setNick:] method
on the newly created instance, it attempts to assign a valid NSString
value to its soup_ivar instance variable, but it was compiled with the
assumption that the ivar layout is

{
  Class isa;
  unsigned char *_ivar1;
  NSUinteger _ivar2;
  int _net_ivar;
  NSString *soup_ivar;
}

but the actual layout at runtime is

{
  Class isa;
  unsigned char *_ivar1;
  NSUinteger _ivar2;
  CGFloat _ivar3;
  int _net_ivar;
  NSString *soup_ivar;
}

because of NSString's newly added ivar.  The assignment would
overwrite _net_ivar, leading to obvious problem at runtime (which may
be grave and apparent, or, depending on the case, not at all obvious,
but causing some other harm to the user or user's data, or simply
unnoticed bug leading to irrational program behavior under certain
circumstances -- it entirely depends on the specific case/code).

Errors like these are extremely hard to track down and analyze; they
lead to memory clobbering and allocation failures which flow down to
libc (through libobjc).  Back in the dark times, before binNMUs were
possible, I remember I spent literally weeks in a debugger trying to
"fix" such a problem.  When I rebuilt the app with debugging symbols
to obtain a meaningful backtrace, the issue was magically gone, so my
only sensible conclusion (completely wrong, of course) at that time
was that something was messy in the environment of the DD who uploaded
the package.

Thinking aloud, some classes are almost never subclassed.  It doesn't
make sense to subclass some library classes (like renaissance), so
this particular issue is more or less rare.  It's possible that
talksoup.app does not subclass any of gnustep-netclasses' classes, in
which case there is no problem.  But because it is not feasible to
maintain up-to-date information for every affected app (redoing the
audit of the code at every new release), it is simpler and easier to
require rebuilds, even if they are not actually necessary in many
situations.  The extra time spent by the buildds is certainly less
(and less costly) than developers' time when analyzing any eventual
problems.

This is also the reason why all non-core GNUstep libraries have
patches to link against -base and/or -gui, enabling the release team
to determine the correct dependency information (in the past, we used
to spell explicitly the order how binNMUs should be scheduled).

--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87wrrixonm.gnus_not_unix!%ya...@gnu.org

Bug#592616: pu: package bgoffice/3.0-9+lenny1

2010-08-18 Thread Yavor Doganov

Георги Данчев wrote:
> I agree, that 'automatically removed by dpkg' games are best to be
> avoided for regenerated files, and it is saner to remove them in the
> postrm, since now debsums aspell-bg lists these three regenerated
> files as FAILED, which is to be expected. I failed to catch that, so
> sorry for the noise and thank you for the sharp eye on it.

I disagree, it is me who failed to catch that and forgot to pass
-Xvar/lib/aspell to dh_md5sums while preparing -11.



--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87wrronffv.gnus_not_unix!%ya...@gnu.org

Bug#592616: pu: package bgoffice/3.0-9+lenny1

2010-08-18 Thread Yavor Doganov

On Wed, Aug 18, 2010 at 02:39:04PM +0100, Julien Cristau wrote:
> On Wed, Aug 18, 2010 at 16:30:56 +0300, Yavor Doganov wrote:
> > These files are supposed to be regenerated in postinst by 
> > update-dictcommon-aspell; that's a feature.
> > 
> Then why is it shipped in the package?  Is it just so that dpkg removes
> it automatically?

That's the sole reason, yes.  From aspell-autobuildhash(8):

| Dictionaries-common scripts will call internally this script and 
| create a single hash file at /var/lib/ispell/$lang.rws, or hash files 
| at /var/lib/ispell/$subdict.rws. You must set a symlink to that files 
| from /usr/lib/aspell/$lang.rws or /usr/lib/aspell/$subdict.rws as 
| appropriate.  You are also suggested to create empty files at 
| /var/lib/aspell/$lang.rws or for all of the 
| /var/lib/aspell/$subdict.rws in the install target of your package 
| build process. This empty file will be overwritten when the real hash 
| is created, but will make the hash be removed at package removal 
| without any magic being done in the postrm and will also help to keep 
| track about which package owns that file.

-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100818140122.ga23...@yavor.doganov.org

Bug#592616: pu: package bgoffice/3.0-9+lenny1

2010-08-18 Thread Yavor Doganov

On Wed, Aug 18, 2010 at 11:44:58AM +0100, Julien Cristau wrote:
> On Wed, Aug 11, 2010 at 15:42:24 +0300, Yavor Doganov wrote:
> 
> > +# Make sure dpkg knows about bg-en.rws too, otherwise the file is not
> > +# deleted upon remove/purge.
> > +   >debian/aspell-bg/var/lib/aspell/bg-en.rws
> 
> Shipping such a file in the package means it'll get emptied every time
> the package in re-installed or upgraded.  That sounds wrong.

Yes, but I don't know why you think it's wrong.  These files are 
supposed to be regenerated in postinst by update-dictcommon-aspell; 
that's a feature.  AFAIK all other aspell packages work in a similar 
way.  Here, bg-en.rws should be treated exactly as bg.rws.



-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100818133056.ga23...@yavor.doganov.org

Re: Bug#506809: oolite: new upstream release (1.73)

2010-08-17 Thread Yavor Doganov

Ludovic Brenta wrote:
> Any objections, please raise your hand.

We're in the begining of a GNUstep transition, which is unfortunately
blocked by serious issues on hppa.  As the release team is unlikely to
approve a new upstream release at this point, any eventual problems in
oolite must be addressed with an upload of the present version to
t-p-u.

So I suggest to upload this new release to experimental, not sid.
(But feel free to consult with -release (CCed)).


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87mxslchru.gnus_not_unix!%ya...@gnu.org

Re: Bug#592603: unblock: adun.app/0.81-4

2010-08-11 Thread Yavor Doganov

Mehdi Dogguy wrote:
> Unfortunately, it won't be able to migrate directly since the
> GNUstep transition started and adun.app caught the old symbols of
> gnustep-{base,gui}.

Right, so what prevents it from migrating tomorrow except the freeze
block?  It got built on all archs before gnustep-base/1.20.1 was
uploaded; http://packages.debian.org/sid/adun.app seems to confirm
that.

> In the meantime, you can follow the transition's status on:
> 
>   http://release.debian.org/transitions/GNUstep.html

Thanks, very nice and extremely helpful!  (Are these transition
webpages automatically generated somehow?  I suspect so.)

-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8762zh3xo5.gnus_not_unix!%ya...@gnu.org

Bug#592616: pu: package bgoffice/3.0-9+lenny1

2010-08-11 Thread Yavor Doganov

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

Please allow an update of bgoffice in stable to fix #589851.
The bug is fixed in squeeze (3.0-11); minimalistic debdiff follows:

diff -u bgoffice-3.0/debian/changelog bgoffice-3.0/debian/changelog
--- bgoffice-3.0/debian/changelog
+++ bgoffice-3.0/debian/changelog
@@ -1,3 +1,14 @@
+bgoffice (3.0-9+lenny1) stable; urgency=low
+
+  * QA upload.
+  * debian/aspell-bg.postrm: Delete; harmful during upgrades or package
+reinstallation (Closes: #589851).
+  * debian/aspell-bg.postinst: Recover from the old erroneous postrm and
+touch bg{,-en}.rws and bg.compat if the files do not exist.
+  * debian/rules (install): Create an empty var/lib/aspell/bg-en.rws.
+
+ -- Yavor Doganov   Wed, 11 Aug 2010 15:09:13 +0300
+
 bgoffice (3.0-9) unstable; urgency=low
 
   * QA upload.
diff -u bgoffice-3.0/debian/aspell-bg.postinst 
bgoffice-3.0/debian/aspell-bg.postinst
--- bgoffice-3.0/debian/aspell-bg.postinst
+++ bgoffice-3.0/debian/aspell-bg.postinst
@@ -9,6 +9,12 @@
bulgarian-aspell-dictionary $DIR/bg-w_english.multi 60
 update-alternatives --install $DIR/bg.multi \
bulgarian-aspell-dictionary $DIR/bg-wo_english.multi 40
+   # Touch the files deleted by old postrm (#589851).
+   # FIXME: Remove this snippet post-squeeze.
+   DIRV="/var/lib/aspell"
+   for f in $DIRV/bg.rws $DIRV/bg-en.rws $DIRV/bg.compat; do
+   [ -f $f ] || touch $f;
+   done
;;
 
 abort-upgrade|abort-remove|abort-deconfigure)
reverted:
--- bgoffice-3.0/debian/aspell-bg.postrm
+++ bgoffice-3.0.orig/debian/aspell-bg.postrm
@@ -1,21 +0,0 @@
-#!/bin/sh
-
-set -e
-
-case "$1" in
-purge|remove|upgrade|failed-upgrade|abort-install|abort-upgrade|disappear)
-DIR=/var/lib/aspell
-   rm -f $DIR/bg.compat $DIR/bg-en.rws $DIR/bg.rws
-   ;;
-
-*)
-echo "postrm called with unknown argument '$1'" >&2
-   exit 1
-;;
-esac
-
-
-#DEBHELPER#
-
-exit 0
-
diff -u bgoffice-3.0/debian/rules bgoffice-3.0/debian/rules
--- bgoffice-3.0/debian/rules
+++ bgoffice-3.0/debian/rules
@@ -102,6 +102,9 @@
 # $WORDLIST is the wordlist filename minus the .*wl.gz extension)
install -d debian/aspell-bg/var/lib/aspell/
>debian/aspell-bg/var/lib/aspell/bg.rws
+# Make sure dpkg knows about bg-en.rws too, otherwise the file is not
+# deleted upon remove/purge.
+   >debian/aspell-bg/var/lib/aspell/bg-en.rws
 # Add a symlink /usr/lib/aspell/$WORDLIST.rws -> /var/lib/aspell/$WORDLIST.rws
install -d debian/aspell-bg/usr/lib/aspell/
ln -s /var/lib/aspell/bg.rws debian/aspell-bg/usr/lib/aspell/bg.rws



-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100811124224.23577.7768.report...@keel.southway-varna.com

Bug#592603: unblock: adun.app/0.81-4

2010-08-11 Thread Yavor Doganov

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: freeze-exception

Please unblock adun.app; -4 fixes FTBFS on mipsen which was the only
reason it wasn't able to migrate to testing for so long.

unblock adun.app/0.81-4

The debdiff between -3 and -4 follows.

diff -u adun.app-0.81/debian/control adun.app-0.81/debian/control
--- adun.app-0.81/debian/control
+++ adun.app-0.81/debian/control
@@ -7,10 +7,10 @@
   Yavor Doganov 
 Build-Depends: debhelper (>= 7),
   dpatch,
-  libgnustep-gui-dev (>= 0.12.0),
+  libgnustep-gui-dev,
   libgsl0-dev,
   imagemagick
-Standards-Version: 3.8.4
+Standards-Version: 3.9.1
 Homepage: http://diana.imim.es/Adun
 Vcs-Browser: 
http://svn.debian.org/wsvn/debian-med/trunk/packages/adun.app/trunk/?rev=0&sc=0
 Vcs-Svn: svn://svn.debian.org/svn/debian-med/trunk/packages/adun.app/trunk/
diff -u adun.app-0.81/debian/changelog adun.app-0.81/debian/changelog
--- adun.app-0.81/debian/changelog
+++ adun.app-0.81/debian/changelog
@@ -1,3 +1,14 @@
+adun.app (0.81-4) unstable; urgency=low
+
+  * debian/rules (mipsen-flags): New variable, conditionally define only
+when building on mips/mipsel as a workaround for gcc-4.4 bug #519006.
+(build-stamp): Use it.
+  * debian/control (Build-Depends): Remove obsolete version requirement
+for libgnustep-gui-dev.
+(Standards-Version): Compliant with 3.9.1 (no changes required).
+
+ -- Yavor Doganov   Mon, 09 Aug 2010 16:16:34 +0300
+
 adun.app (0.81-3) unstable; urgency=low
 
   [ Charles Plessy ]
diff -u adun.app-0.81/debian/rules adun.app-0.81/debian/rules
--- adun.app-0.81/debian/rules
+++ adun.app-0.81/debian/rules
@@ -17,6 +17,11 @@
 optim := debug=yes
 endif
 
+# Workaround for gcc-4.4 bug 519006.
+ifneq (,$(findstring mips,$(DEB_BUILD_ARCH)))
+mipsen-flags := ADDITIONAL_OBJCFLAGS=-g0 ADDITIONAL_CFLAGS=-g0
+endif
+
 build: patch build-stamp
 
 build-stamp:
@@ -33,7 +38,7 @@
 # even if no -j option is used.  GNUSTEP_MAKE_PARALLEL_BUILDING=no
 # prevents messing the MAKELEVEL again.
MAKELEVEL=0 $(MAKE) GNUSTEP_MAKE_PARALLEL_BUILDING=no $(optim) \
- messages=yes LDFLAGS="$(LDFLAGS)"
+ messages=yes LDFLAGS="$(LDFLAGS)" $(mipsen-flags)
convert UL/Resources/icon.tiff -resize 32x32 adun.xpm
touch $@
 



-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/2010084402.9618.93560.report...@keel.southway-varna.com

Re: Bug#561944: GNUstep transition

2010-08-10 Thread Yavor Doganov

Adam D. Barratt wrote:
> On Mon, 2010-08-09 at 16:39 +0200, Mehdi Dogguy wrote:
> > On  0, Yavor Doganov  wrote:
> > > Sure, but what about the libmodplug transition?  Should we wait
> > > for it or we can upload the GNUstep core libraries to unstable
> > > right now?

> > IMO, we should try to get them in Squeeze before starting this
> > transition.

> That would be my preference as well.

Already migrated, so we're launching the GNUstep attack.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87sk2mn1xj.gnus_not_unix!%ya...@gnu.org

Re: Bug#561944: GNUstep transition

2010-08-09 Thread Yavor Doganov

On Mon, Aug 09, 2010 at 01:13:22PM +0100, Neil McGovern wrote:
> Ok, so at the moment let's have a soft ACK for this transition.

Thanks!

> Could you try and get it ready to move into testing, with the RC
> bugs fixed?

Sure, but what about the libmodplug transition?  Should we wait for it
or we can upload the GNUstep core libraries to unstable right now?  (I
guess the binNMU for cynthiune.app can be scheduled later.)

-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100809123526.ga16...@yavor.doganov.org

Re: Bug#561944: GNUstep transition

2010-08-08 Thread Yavor Doganov

close 568307 0.17.1-1
close 585531 0.17.1-1
close 558993 0.17.1-1
thanks

Neil McGovern wrote:
> I note that there are 4 bugs left that aren't fixed yet (one pending),
> do you know when these are likely to be ready to transition?

#58198{5,6,7} are trivial and can be uploaded right away.  If the
maintainer doesn't react in time, I can NMU them when the transition
begins (at which point they'll be RC bugs, eligible for NMU).  Gürkan,
are you there?

The cure for #581940 (gorm.app) depends on -base/-gui from
experimental.  The specific fix can be backported easily if a new
upstream gorm.app release is not acceptable at this point.  Gürkan is
the de-facto maintainer, so he can tell more about the plan for this
bug.

The fix for #581934 (gnustep-dl2) depends on -base/-gui versions from
experimental, plus a fixed gorm.app.  I don't know how the maintainer
is planning to deal with it, I hope he's waiting for a fixed gorm.app
+ Debian-specific soname because of the ABI break.  Federico?  (I
withdraw part of what I said in the bug log: a snapshot of upstream's
repository ought to be out of question now, given that in the past few
months it has been rewritten from scratch...)

In any case, gorm.app and gnustep-dl2 are one of the few packages that
will definitely require sourceful uploads.

> 568307 [   ] Generates incomplete nfont bundles which makes the art 
> backend unusable

Fixed in experimental by providing a defoma-free art backend.
GNUstep-specific .nfont bundles are generated via fc-cache now.

> 585531 [   ] [Debian GNUstep maintainers] TimeMon Preferences 
> window's weird  behavior

A fairly old bug in the cairo backend, fixed in 0.17/0.18.  Combined
with the bug above (affecting only art), it makes GNUstep unusable in
squeeze/sid right now.  Fixed in experimental.

> 558993 [   ] Subject: FTBFS: NSWindow.m:198: fatal error: method 
> definition not in  @implementation context

An embarassing bug that could be prevented if the upload of
gnustep-base/1.19.3 didn't happen.  But the damage has been done, and
various upstream authors have been quite disturbed (e.g., latest
Ubuntu stable release shipping a non-releasable core GNUstep libraries
combination).  Nothing to do here except move forward or backward.

FWIW, technically speaking we can release without a transition, by
"just" uploading gnustep-base/1.19.1 with an epoch (however, this will
still require binNMUs of all packages that were uploaded since then
because of the NS{U}Integer/CGFloat types which break the ABI, at
least on 64-bit archs).

But if we go that route, there are quite some important bugfixes that
we'll have to backport (including security -- the not-so-recent CVEs
about gdomap vulnerabilities), and I'm not sure we'll succeed...
Needless to say, we'll be completely alone in maintaining those
modified versions throughout the squeeze lifetime; upstream doesn't
give a damn about 1.19.x/0.17.x...

--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87lj8hx8d7.gnus_not_unix!%ya...@gnu.org

Bug#561944: Bits from the (chilly) release team

2010-08-06 Thread Yavor Doganov

Neil McGovern wrote:
> As mentioned in the previous mail, we would freeze when various
> transitions are completed or being handled.

I sincerely hope you haven't forgetten #561944, and that ditching
GNUstep packages out of squeeze is not your plan.

It is somewhat depressing that we've been waiting for more than 8
months without a single word from you ("Wait until further notice",
"Wait for...", "No chance... because...", etc.).

Confirming again that we're ready to commence the GNUstep transition
as soon as the Release Team approves it, and we'll fix all breakages
in due time.  For what we can't fix, we will act aggressively: "ROM"
removals from the archive (but if we can't fix these things, what does
"maintainers" stand for?).

AFAICT, only cynthiune.app is currently involved in an ongoing
transition.  Traditionally, entagled transitions causing trouble have
been poppler (0.14 postponed post-squeeze) and ffmpeg (no new stuff
planned for squeeze TTBOMK).

Thanks for (re)considering.

P.S: (I'll be offline till Sunday noon/evng UTC+3.)

-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87pqxvu3y7.gnus_not_unix!%ya...@gnu.org

Bug#561944: transition: gnustep-gui

2010-06-26 Thread Yavor Doganov

# See also http://lists.debian.org/debian-release/2010/03/msg00226.html
retitle 561944 transition: libgnustep-base1.19 -> 1.20; libgnustep-gui0.16 -> 
0.18
thanks

Updating my initial information:

On Mon, Dec 21, 2009 at 02:59:53PM +0200, Yavor Doganov wrote:
> Expected problems:

> * This transition is combined with the removal of the defoma
>   dependency in gnustep-back, so there might be regressions we don't
>   know about yet.

TTBOMK defoma-free gnustep-back is working properly.

> * adun.app reliably fails to build on mipsen, which looks like is due
>   to a regression in binutils (#519006).

GCC actually; I added a workaround in debian-med's SVN; untested as I
don't have access to a mipsen box.

> * gobjc-4.4 regression on armel: #550049

AFAICT this is fixed, although there was no explicit confirmation from
the GCC maintainers:

http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=12;bug=550049

> * The problems that the release team had in the past with GNUstep
>   transitions and involved Objective-C libraries/frameworks (see
>   subthread [1] if you forgot about this issue) are addressed, pending
>   sponsorship of the fixed packages [2].

All sponsored now.

> * Packages which FTBFS with the new gnustep-gui or for other reasons:

The full bug list here:

http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=tag&users=pkg-gnustep-maintain...@lists.alioth.debian.org&data=gnustep-transition

Total 33 -- 28 fixed; 5 outstanding, of which 3 with patches, 1
pending and 1 fixed upstream.

gnustep-base/1.20.1, gnustep-gui/0.18.0 and gnustep-back/0.18.0 are in
experimental.  Looking forward to your approval for the transition.



-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100626142020.ga4...@yavor.doganov.org

Bug#561944: [Debian GNUstep maintainers] New GNUstep releases

2010-05-10 Thread Yavor Doganov

[ Quoting in full for the sake of the bug log. ]

On Mon, May 10, 2010 at 11:37:30AM +0200, Gürkan Sengün wrote:
>> So... what shall we do for squeeze?  The current situation is
>> really frustrating :-(.
>>
>> I think we should definitely try to release with the newest, not
>> only because they are labeled as "stable" -- there are lots of good
>> API additions and bugfixes that application developers are going to
>> rely upon.  What we have now (heck, we don't even *have* it, given
>> that gui/back is only in experimental) is already obsolete.

> I agree, we should go for the latest stable release, and your plan
> to test it before distributing it is good.

OK, I'll start working on it immediately after I fix the gnustep-base
FTBFS on powerpc and hurd-i386.  I'll try to get everything ready
within this week.

> I can help until end of May, then I'm kind of away for two months.

I hope we can complete the transition in May; the freeze is
approaching...  In any event, I can NMU if a sourceful upload with a
fix is necessary.

>> But we have to be careful not to make the situation worse, so I
>> suggest the following:
>>
>> Make 2.4.0: Upload to sid right away, no transition involved.
>>
>> Base 1.20.0: Upload to experimental (for now).  This would allow us
>> to test all packages and judge whether to go on with a 1.19->1.20
>> transition.  If we decide not to do so (for whatever reason), this
>> will not prevent an upload of gui/back to sid (base will remain in
>> experimental for a post-squeeze transition).
>>
>> GUI/Back 0.18.0: I'll prepare the packages once the new releases
>> are out, and after we upload -base/1.20.0, but will not upload at
>> all.  Instead, I'll put them in a public location so that we can
>> all test the whole GNUstep stack.  If we can manage to deal with
>> all breakages, we can then upload gui+back to experimental and
>> update the release.d.o bug with the new information (i.e. the
>> preparation for base 1.19->1.20 and gui 0.16->0.18 transitions).
>>
>> What do you think about the plan?  Does it sound good?

> Sounds good, I don't know if it's good to waste debian developer
> sponsor time for experimental uploads though. I'm very much behind
> with getting my packages updated because of lack of sponsor time.

Well, while I feel the pain too, we most definitely *cannot* upload
ABI-breaking releases to sid without the release team's approval, even
if we have to wait months for it.  Uncoordinated uploads can disrupt
the whole release process, and we certainly do not want to do that.



--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100510105024.ga19...@yavor.doganov.org

GNUstep in squeeze (was: Bits from the Release Team: What should go into squeeze?)

2010-03-17 Thread Yavor Doganov

Philipp Kern wrote:
> It would be great if every team on track could send us a short mail to
> debian-release@lists.debian.org

Much to my regret the GNUstep stack is not in a releasable shape.
There are 5 RC bugs (+2 not reported).  4 of them are trivial to fix,
I'm just waiting to accumulate more changes as finding sponsors is
hard.

The remaining 3 bugs are fixed in experimental, and propagating the
fixes to sid and subsequently testing depends on the transition bug we
have filed last year (#561944), for which we got no comments from the
release team.

As it stands now, and assuming we commence and complete the GNUstep
transition soon, squeeze will be released with base/gui 1.19.3/0.17.1,
which is a bit unfortunate as these are unstable releases.  The best
would be 1.20/0.18, but there are no upstream releases yet and some
changes are really massive and scary.

So the most realistic scenario is to stabilize what we have now, and
upload 1.20/0.18 to experimental.  If we can manage to deal with all
the problems and there's still room for new transitions (according to
your judgement), then... we'll see.

-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87r5nj44if.gnus_not_unix!%ya...@gnu.org

1 2 >

1 - 100 of 123 matches

Mail list logo