Bug#1000982: transition: gnustep-base, gnustep-gui
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#1028602: transition: gnustep-base, gnustep-gui
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
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#940943: buster-pu: package gnustep-base/1.26.0-4+deb10u1
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#942110: stretch-pu: package gnustep-base/1.24.9-3.1+deb9u1
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#962584: transition: gnustep-base, gnustep-gui
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#916445: transition: pantomime
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#918844: transition: gnustep-base, gnustep-gui
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#918844: transition: gnustep-base, gnustep-gui
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
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
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
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
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#879738: transition: gnustep-base
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#879738: transition: gnustep-base
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
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#883455: transition: gnustep-sqlclient
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#883455: transition: gnustep-sqlclient
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#885184: stretch-pu: package agenda.app/0.42.2-1+deb9u1
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#886636: stretch-pu: package gnumail/1.2.2-1.1+deb9u1
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#888438: transition: gnustep-gui
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#888438: transition: gnustep-gui
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#894027: stretch-pu: package addresses-for-gnustep/0.4.8-2+deb9u1
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#894027: stretch-pu: package addresses-for-gnustep/0.4.8-2+deb9u1
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.
Re: Bug#560359: gnustep-common depends print_unique_pathlist.sh from gnustep-make
[I intended to CC -release in my previous message, but apparently forgot...] В 13:48 +0100 на 16.03.2010 (вт), Gerfried Fuchs написа: > * Yavor Doganov [2010-03-16 08:33:53 CET]: > > В 08:05 +0100 на 16.03.2010 (вт), Gerfried Fuchs написа: > > > I wonder, why only for squeeze, if it is release-critical? > > > > I don't think the bug is serious enough to warrant a stable update, but > > I don't mind to fix it for lenny too if the SRMs believe we should. > > I would suggest you to ask the release team for their opinion and if > they share it tag the bug with "squeeze sid" so that the BTS doesn't > think lenny is affected. SRMs, do you think that #560359 deserves to be fixed in stable via a regular point release? -- 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/1268750517.2311.44.ca...@keel.southway-varna.com
GNUstep in squeeze (was: Bits from the Release Team: What should go into squeeze?)
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
Bug#561944: [Debian GNUstep maintainers] New GNUstep releases
[ 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
Bug#561944: transition: gnustep-gui
# 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: Bits from the (chilly) release team
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
Re: Bug#561944: GNUstep transition
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
Re: Bug#561944: GNUstep transition
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
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
Bug#592603: unblock: adun.app/0.81-4
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
Bug#592616: pu: package bgoffice/3.0-9+lenny1
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
Re: Bug#592603: unblock: adun.app/0.81-4
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
Re: Bug#506809: oolite: new upstream release (1.73)
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
Bug#592616: pu: package bgoffice/3.0-9+lenny1
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
Bug#592616: pu: package bgoffice/3.0-9+lenny1
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
Георги Данчев 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
binNMU order of ObjC/GNUstep packages
[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
Re: binNMU order of ObjC/GNUstep packages
В 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
Re: binNMU order of ObjC/GNUstep packages
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
Bug#561944: GNUstep transition
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: Bug#561944: GNUstep transition
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#592616: pu: package bgoffice/3.0-9+lenny1
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
Bug#592616: pu: package bgoffice/3.0-9+lenny1
В 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#596411: unblock: gnustep-gui/0.18.0-5
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#596412: unblock: terminal.app/0.9.4+cvs20051125-6
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#596415: unblock: viewpdf.app/1:0.2dfsg1-3.1
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#596416: unblock: cynthiune.app/0.9.5-11
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
Re: gnustep-base upload and/or transition required?
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#629477: transition: gnustep-base, gnustep-gui, libobjc
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
Bug#629477: transition: gnustep-base, gnustep-gui, libobjc
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
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
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
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
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
Re: GNUstep libraries soname bump
Adeodato Simó wrote: > This transition is tied to the ffmpeg-debian transition via > lynkeos.app. I think it's a pity you can't start working on an > otherwise very isolated transition because of that, I have a fixed package ready, but would like to do more testing. I'll send a plea for sponsorship to -mentors tomorrow or latest on Tuesday. > Uploading to experimental is fine, IMHO it is always best to upload to experimental first. (BTW, the GNUstep transition is also tied to the libpoppler3->libpoppler4 transition via popplerkit.framework.) -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Debian GNUstep maintainers] GNUstep libraries soname bump
Adeodato Simó wrote: > > (BTW, the GNUstep transition is also tied to the > > libpoppler3->libpoppler4 transition via popplerkit.framework.) > > No, it is not, at least not as far as my SQL-fu can see. libpopplerkit0 > does not depend in any of the renamed libraries in the GNUstep transition, > so it's free to migrate at will. You are right that it doesn't depend on the GNUstep core libraries, but it should. See http://lists.debian.org/debian-release/2008/07/msg00068.html for some explanation. (Yes, these are bugs, IMVHO RC as per Policy 8.6.) > Or do you know more about this than the Packages.gz files do? :-) The other packages in this situation are gnustep-netclasses and pantomime1.2. If they don't get rebuilt, their reverse dependencies (gnumail.app, lusernet.app, talksoup.app, viewpdf.app, etc.) will fail miserably. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Debian GNUstep maintainers] GNUstep libraries soname bump
Adeodato Simó wrote: > So, now my question is: what happens if you rebuild those three > packages against the new GNUstep libraries, and they migrate to > testing on their own, before said base libraries and the rest of the > migrated packages? This has happened before (i.e. they almost always migrate first on their own because there is a bug or two in the rest of the GNUstep packages that we discover during the transition). It depends. If the new GNUstep libraries are compatible [1], everything is working properly. If they are not, some packages are temporarily broken in testing until the rest of the GNUstep stack migrates. (During one transition there were FTBFS bugs in testing too, as these libraries were rebuilt for the new GNUstep directory layout.) [1] GNUstep upstream always bump the SONAMEs for new major releases, even if it is not justified. They are aware of the pains that distributors experience because of this, and hopefully they'll change this practice soon. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Debian GNUstep maintainers] GNUstep libraries soname bump
Adeodato Simó wrote: > First, that I'm sure you're aware that's a serious bug that ought to > be fixed. Full ACK. > Isn't just linking to the GNUstep libraries as a Debian patch an > option? Yes, it's as trivial as that. I'll provide patches after the transition. > Second, the above means we have to either [...] It would be better if Hubert comments on this. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Debian GNUstep maintainers] GNUstep libraries soname bump
Adeodato Simó wrote: > Btw, popplerkit.framework is failing to build on some arches, could you > take a look? Yes, I saw that and already fixed in my working copy. The bug is in bindings/GNUmakefile, now exposed with gnustep-make 2.0.8. It is pointless to trick the build system to handle C++ files this way when it has native support for C++. I'll send the changes to Hubert. Now that a sourceful upload of popplerkit.framework is needed, would it be appropriate to incorporate the fix that we discussed (linking against libobjc, libgnustep-base and libgnustep-gui)? AFAICS the poppler transition is almost finished while the new GNUstep libraries are still in the NEW queue, so this seems to be the preferred course of action. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Debian GNUstep maintainers] GNUstep libraries soname bump
Adeodato Simó wrote: > > Now that a sourceful upload of popplerkit.framework is needed, would > > it be appropriate to incorporate the fix that we discussed > > If the changes are ready to be uploaded and would not introduce further > delays, sure. Everything is ready, pending Hubert's approval (as maintainer of the package). If he's overloaded I'd resort to -mentors, but I won't do that unless there's a specific ACK from him. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: GNUstep libraries soname bump
[ Let's drop -release in subsequent follow-ups, unless the Release Team has objections and/or someone wants to comment on this.] At Mon, 09 Mar 2009 07:52:50 +0100, Gürkan Sengün wrote: > Yavor Doganov wrote: > > Adeodato Simó wrote: > > You are right that it doesn't depend on the GNUstep core libraries, > > but it should. > > > >> Or do you know more about this than the Packages.gz files do? :-) > > > > The other packages in this situation are gnustep-netclasses and > > pantomime1.2. > likewise with renaissance (zipper.app) OK, I'll take a look. > and gorm.app (and gnustep-dl2) At first glance, the problem here is far more severe. gorm.app should ship its public shared libraries as separate binary packages and the private ones should be installed under /usr/lib/gorm.app. Likewise, gnustep-dl2 should ship the binary package dbmodeller.app plus eventually the tools, if they're useful elsewhere. The gnustep-dl2 source package should Build-Depend on the shared Gorm public libraries, and not on gorm.app. Additionally, we have to decide what to do with gnustep-dl2's own (gazillion) libraries, i.e.: - ship a few libeo* binary packages containing them in /usr/lib for the benefit of the Debian users building and deployoing GNUstepWeb (please correct me if I'm wrong; I think this is the only reverse dependency); - ship them under /usr/lib/gnustep-dl2 as part of the dbmodeller.app package. - ship them under /usr/lib/gnustep-dl2 but be prepared to move them to /usr/lib when GSWeb is ready for inclusion in Debian. All of this will be done after the forthcoming GNUstep transition as uploads will be stuck in NEW. Undoubtedly it is a gross violation, but not a practical problem as with the rest of the libraries. In their current shape, both gorm.app and gnustep-dl2 depend on Base/GUI, so they'll migrate together. We should not release them as they are in Squeeze, though. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Reverting the libmpc 0.1~r435-1 upload
Adeodato Simó wrote: > > cynthiune.app Bug #476381 > I’m Bcc'ing all of the involved bugs so that maintainers can send an > update on the status of their bug To be honest, I haven't worked on a patch yet because it was my understanding that this transition will wait for the (already approved) GNUstep transition. Or there is no problem from the Release Team's POV to tie them together? Anyway, I looked at the GStreamer patch Sebastian sent back then when he filed the bug, and porting looked trivial. With little luck I'll be ready with a fix pretty soon. JFTR, it is very easy to (temporarily) disable Musepack support in Cynthiune by passing disable-musepack=yes to gs_make in the build-stamp target and dropping the libmpcdec-dev build-dependency. But I'm confident this won't be necessary. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: GNUstep libraries soname bump
Adeodato Simó wrote: > By the way, are gnustep-netclasses and pantomime1.2 in the same > situation popplerkit.framework used to be, that is, using GNUstep > libraries but not linking against them? Yes, they are, plus renaissance. Will be fixed for the next transition. (Hubert, the gnustep-base powerpc issue is due to #523869, I believe.) -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Debian GNUstep maintainers] GNUstep libraries soname bump
Adeodato Simó wrote: > + Yavor Doganov (Mon, 04 May 2009 22:12:10 +0300): > > (Hubert, the gnustep-base powerpc issue is due to #523869, I believe.) > > I gave it back a bit earlier, so as it seems it should succeed now. Unfortunately it failed again because the fix for the above bug is in gcc-4.3/4.3.3-8 which is not yet built and installed on powerpc. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: GNUstep libraries soname bump
At Mon, 4 May 2009 23:13:31 +0200, Adeodato Simó wrote: > + Yavor Doganov (Mon, 04 May 2009 23:34:53 +0300): > > Adeodato Simó wrote: > > > + Yavor Doganov (Mon, 04 May 2009 22:12:10 +0300): > > > > (Hubert, the gnustep-base powerpc issue is due to #523869, I > > > > believe.) > > > > I gave it back a bit earlier, so as it seems it should succeed now. > > > Unfortunately it failed again because the fix for the above bug is in > > gcc-4.3/4.3.3-8 which is not yet built and installed on powerpc. > > Ah, I see. I'll look into giving it back once -8 is available in powerpc > and the chroots have been upgraded. 4.3.3-9 is available now on all powerpc buildds, AFAICS. Could you please give back gnustep-base/1.19.0-2 on powerpc? Thanks! -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: GNUstep libraries soname bump
В Sat, 02 May 2009 20:32:22 -0400, Hubert Chathi написа: > Has new upstream version -- will upload shortly, no bin-NMU needed: > - gnustep-dl2 > - gorm.app > - gworkspace > - price.app Hubert/Gürkan: The transition is going on nicely now that the hppa/ powerpc troubles are resolved. There are only a few packages waiting to be built and/or uploaded (mostly hppa). Could you please upload these soon? Alternatively, we can ask the release team to schedule binNMUs and postpone the new upstream uploads after the transition (this seems like a faster and safer route to me). I believe only gorm.app needs a sourceful upload (#527659). Thanks. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: GNUstep libraries soname bump
On Fri, May 22, 2009 at 02:41:39PM +0200, Adeodato Simó wrote: > > > - gnustep-dl2 > > > - gorm.app > > > - gworkspace > > > - price.app > I confirm the transition is ready except by these four packages. gorm.app and price.app were uploaded (and built/installed everywhere already). > Should I be scheduling Bin-NMUs for these packages after all? Among the team members only Hubert can upload, but I read in his blog that he's on VAC for a week (don't know since when). I'm not involved in the packaging of both gworkspace.app and gnustep-dl2, so I definitely do not want to overwrite whatever changes they've made (these packages are not in our team repo). So, risking Hubert's/Gürkan's anger, I suggest to schedule binNMUs for gnustep-dl2 and gworkspace.app. AFAICS the worst thing that can happen is some extra load on the buildds if Hubert uploads them before the migration is over + a release team member having to reset age-days accordingly. (And some extra delay, of course.) The other tiny blockers are lynkeos.app on ia64 (to be uploaded), and charmap.app on mips (stuck in "Built" state for far too long). -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: GNUstep libraries soname bump
В Wed, 27 May 2009 10:14:35 +0200, Adeodato Simó написа: > + Hubert Chathi (Tue, 26 May 2009 22:35:38 -0400): >> I should be uploading the other two soon (IIRC, gworkspace and >> gnustep-dl2 depended on other packages being built). Yes, gnustep-dl2 depends on the public shared libraries shipped en-bloc in gorm.app. Fortunately, no incompatible changes this time, so the binNMUed old version of gnustep-dl2 works (according to my quick tests on a Debian testing machine, at least). Yet another important thing to fix in the near future and preferrably before the forthcoming next GNUstep transition. > Please note however that the new GNUstep already migrated to > unstable thanks to those two packages having been Bin-NMUed, You almost certainly meant "testing" here, I suppose. @Hubert: Sorry for interfering this time, but I thought it was in our common best interest to finnish the transition ASAP and avoid unexpected entanglement of inter-related migrations that could block us (like GCC 4.4, which was a blocker but thankfully was done before ours). -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#560185: pu: package kazehakase/0.5.4-2.2+lenny1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: pu
Please approve a stable update to fix CVE-2007-1084 (#556271).
According to the bug reporter (Michael Gilbert) this is not a severe
problem (no DSA will be issued), but fixes for stable and oldstable are
warranted.
Debdiff attached. (Note: The actual diff also updates
config.{guess,sub} but as these are harmless and I'm not supposed to
fix anything else in a stable update, I've left that out. Let me know
if I must fix the handling of these files as well.)
Thanks.
diff -u kazehakase-0.5.4/debian/changelog kazehakase-0.5.4/debian/changelog
--- kazehakase-0.5.4/debian/changelog
+++ kazehakase-0.5.4/debian/changelog
@@ -1,3 +1,11 @@
+kazehakase (0.5.4-2.2+lenny1) stable; urgency=medium
+
+ * debian/patches/CVE-2007-1084.dpatch: New; disallow adding bookmarks
+with data:/javascript: URIs (CVE-2007-1084, Closes: #556271).
+ * debian/patches/00list: Update.
+
+ -- Yavor Doganov Wed, 09 Dec 2009 16:07:11 +0200
+
kazehakase (0.5.4-2.2) unstable; urgency=low
* Non-maintainer upload.
diff -u kazehakase-0.5.4/debian/patches/00list kazehakase-0.5.4/debian/patches/00list
--- kazehakase-0.5.4/debian/patches/00list
+++ kazehakase-0.5.4/debian/patches/00list
@@ -1,3 +1,4 @@
+CVE-2007-1084
20_user_agent_tag
30_bookmarkbar_DSA
50_passwordmgr
only in patch2:
unchanged:
--- kazehakase-0.5.4.orig/debian/patches/CVE-2007-1084.dpatch
+++ kazehakase-0.5.4/debian/patches/CVE-2007-1084.dpatch
@@ -0,0 +1,36 @@
+#! /bin/sh /usr/share/dpatch/dpatch-run
+## CVE-2007-1084.dpatch by Yavor Doganov
+##
+## DP: Do not allow bookmarks with data:/javascript: URIs (CVE-2007-1084).
+
+...@dpatch@
+diff -urNad kazehakase-0.5.4~/src/actions/kz-actions.c kazehakase-0.5.4/src/actions/kz-actions.c
+--- kazehakase-0.5.4~/src/actions/kz-actions.c 2008-03-29 10:20:41.0 +0200
kazehakase-0.5.4/src/actions/kz-actions.c 2009-12-09 16:03:53.0 +0200
+@@ -1076,6 +1076,26 @@
+
+ if (!uri) return;
+
++ /* Refuse to add a bookmark if the URI is data:/javascript:
++ (CVE-2007-1084). */
++ if (g_str_has_prefix(uri, "data:")
++ || g_str_has_prefix(uri, "javascript:"))
++ {
++ GtkWidget *dialog;
++
++ dialog = gtk_message_dialog_new(NULL,
++ GTK_DIALOG_DESTROY_WITH_PARENT,
++ GTK_MESSAGE_WARNING,
++ GTK_BUTTONS_CLOSE,
++ _("Adding this bookmark is disallowed for security reasons."));
++ gtk_window_set_title(GTK_WINDOW(dialog),
++ _("Security Warning"));
++ gtk_dialog_run(GTK_DIALOG(dialog));
++ gtk_widget_destroy(dialog);
++ return;
++ }
++
++
+ bookmark = kz_bookmark_new_with_attrs(title, uri, desc);
+ /* FIXME! show dialog */
+ if (sibling)
Bug#560191: opu: package kazehakase/0.4.2-1etch2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: opu
This is the same issue and fix as reported in #560185.
Please approve, thanks.
diff -u kazehakase-0.4.2/debian/patches/00list kazehakase-0.4.2/debian/patches/00list
--- kazehakase-0.4.2/debian/patches/00list
+++ kazehakase-0.4.2/debian/patches/00list
@@ -1,3 +1,4 @@
+CVE-2007-1084
05_add_missing
20_user_agent_tag
30_bookmarkbar_DSA
diff -u kazehakase-0.4.2/debian/changelog kazehakase-0.4.2/debian/changelog
--- kazehakase-0.4.2/debian/changelog
+++ kazehakase-0.4.2/debian/changelog
@@ -1,3 +1,11 @@
+kazehakase (0.4.2-1etch2) oldstable; urgency=low
+
+ * debian/patches/CVE-2007-1084.dpatch: New; disallow adding bookmarks
+with data:/javascript: URIs (CVE-2007-1084, Closes: #556271).
+ * debian/patches/00list: Update.
+
+ -- Yavor Doganov Wed, 09 Dec 2009 16:58:44 +0200
+
kazehakase (0.4.2-1etch1) stable-security; urgency=high
* Stop building against the bundled PCRE (v4.5) library, and instead
only in patch2:
unchanged:
--- kazehakase-0.4.2.orig/debian/patches/CVE-2007-1084.dpatch
+++ kazehakase-0.4.2/debian/patches/CVE-2007-1084.dpatch
@@ -0,0 +1,36 @@
+#! /bin/sh /usr/share/dpatch/dpatch-run
+## CVE-2007-1084.dpatch by Yavor Doganov
+##
+## DP: Do not allow bookmarks with data:/javascript: URIs (CVE-2007-1084).
+
+...@dpatch@
+diff -urNad kazehakase-0.4.2~/src/actions/kz-actions.c kazehakase-0.4.2/src/actions/kz-actions.c
+--- kazehakase-0.4.2~/src/actions/kz-actions.c 2006-11-11 11:27:43.0 +0200
kazehakase-0.4.2/src/actions/kz-actions.c 2009-12-09 16:57:58.0 +0200
+@@ -1133,6 +1133,26 @@
+
+ if (!uri) return;
+
++ /* Refuse to add a bookmark if the URI is data:/javascript:
++ (CVE-2007-1084). */
++ if (g_str_has_prefix(uri, "data:")
++ || g_str_has_prefix(uri, "javascript:"))
++ {
++ GtkWidget *dialog;
++
++ dialog = gtk_message_dialog_new(NULL,
++ GTK_DIALOG_DESTROY_WITH_PARENT,
++ GTK_MESSAGE_WARNING,
++ GTK_BUTTONS_CLOSE,
++ _("Adding this bookmark is disallowed for security reasons."));
++ gtk_window_set_title(GTK_WINDOW(dialog),
++ _("Security Warning"));
++ gtk_dialog_run(GTK_DIALOG(dialog));
++ gtk_widget_destroy(dialog);
++ return;
++ }
++
++
+ bookmark = kz_bookmark_new_with_attrs(title, uri, desc);
+ /* FIXME! show dialog */
+ if (sibling)
Bug#561944: transition: gnustep-gui
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Please give the green light for a libgnustep-gui0.16->0.17 transition. This is going to be harder than last time -- more packages are affected by the incompatible changes, and unfortunately we're lacking sponsors these days. There are also two toolchain problems that almost certainly will have a bad impact. Packages going away: libgnustep-gui0.16 libgnustep-gui0.16-dbg gnustep-back0.16 gnustep-back0.16-art gnustep-back0.16-cairo (Replaced with 0.17 accordingly.) 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. * adun.app reliably fails to build on mipsen, which looks like is due to a regression in binutils (#519006). It's very likely that some other packages will choke here too. * gobjc-4.4 regression on armel: #550049 I haven't seen such failures on the buildds yet, probably because there were no uploads of GNUstep packages since GCC 4.4 became the default compiler. This will surely affect a bunch of apps. * 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]. [1] http://lists.debian.org/debian-release/2009/03/msg00110.html [2] http://lists.debian.org/debian-mentors/2009/12/msg00237.html * Packages which FTBFS with the new gnustep-gui or for other reasons: - adun.app: #560514 Fix committed in debian-med SVN; can be uploaded any time as the issue is not related to -gui (Andreas/Charles, could you please take care about this at your earliest convenience? TIA!). - cynthiune.app: #476381 FTBFS due to the libmpcdec6 transition, fixed long time ago. Waiting to be sponsored, can be uploaded at any time. - etoile: GSTheme/NSToolbar/NSScrollView incompatible changes Fixed upstream, I'll cherry-pick the patches and upload when the time comes. - gnustep-dl2: #559884 gnustep-base problem, patch available, can be uploaded any time. (I think Federico is working on it, right?) - gnustep-examples: NSToolbar/NSToolbarItem incompatible changes Fixed in my Arch repo, will upload to sid when 0.17 is there. - gorm.app: #552913 Fixed in 1.2.10, waiting to be sponsored. This bug is not related to the transition, but 1.2.8 also fails to build with gnustep-gui/0.17.1-1. GNUstep people: Please test the defoma-free gnustep-back from experimental. You might want to try both with your usual settings and temporary moving ~/GNUstep/Defaults/.GNUstepDefaults away. Everything should work smoothly; everything that fails because of the migration is most likely a bug we have to fix, and I personally prefer to hold the transition while everything is ironed out in experimental. Known problems: 1) The defoma-generated stuff at /var/lib/defoma is not actually removed on upgrades (fixed in my tree already, will be included in the upload to unstable). 2) I see no way to triggerize the regeneration of the .plist files when a new font is installed/removed, because we ultimately rely on fc-list and the fontconfig cache is refreshed by fontconfig's trigger. TTBOMK there is no way to handle dependencies between triggers. (At least this is not a regression from the defoma implementation, just annoying and inefficient way to manage the system fonts available for the art GNUstep backend.) Thanks. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Debian GNUstep maintainers] 1st batch of binNMUs for GNUstep transition
On Sun, Jul 06, 2008 at 03:06:25PM -0400, Hubert Chathi wrote: > >> - gnustep-netclasses > >> - pantomime1.2 > >> - popplerkit.framework > > > Doesn't look like these need to be binNMUed as no binary packages are > > directly depending on core gnustep libraries? > > Yeah, there are some issues with GNUstep library linkages. They end up > not linking (and hence not depending) on the core gnustep libraries. I believe these upstream bugs cause us trouble (for example, pantomime1.2 migrated before the GNUstep stack in the previous transition, which lead to a FTBFS bug filed for testing, as the layout was different). It is also (according to my understanding) a Debian Policy violation when a shared library uses symbols from another library(ies) but doesn't link with it/them and hence there is no dependency. (Fixing popplerkit.framework, for which I believe I sent a patch to the GNUstep mailing list, will tie all future GNUstep transitions with the poppler transitions, which is rather unpleasant in general.) Maybe right now it is not the best time to fix these issues, but would be nice to settle them out before the Lenny release. > I guess they assumed that any application that linked against those > libraries would already be pulling in the core GNUstep libraries. Exactly, but this plays us a bad joke sometimes. > helpviewer.app, I am told, has some serious problems, which Yavor has > said he would try to fix. I am confident I'll fix the build problems, but this package is basically unusable as it doesn't work with the current XML parser. If I can't fix that within a reasonable timeframe, we must kick it out from Lenny, IMO. TTBOMK, only lynkeos.app has documentation that is supposed to be displayed by helpviewer.app (if it is able to find it at all...). In any event, please don't schedule a binNMU for helpviewer.app; it fails to build and will require a sourceful upload anyway. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fixing #493051 (biococoa.app: Contents do not match name and description.) in Lenny.
Hi Charles, В Fri, 08 Aug 2008 14:25:41 +0900, Charles Plessy написа: > I just figured out that a new upstream release of gnustep-base was > uploaded the 17th of July, FWIW, this is strictly a bugfix release, and I believe it is our intention to ask for a freeze exception after we fix #489279 (which should be RC). I don't know if there's any chance to get it approved, though: 29 files changed, 912 insertions(+), 154 deletions(-) (This is without the regenerated `configure'.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please allow another synaptic update
On Mon, 23 May 2005 12:03:31 +0200, Michael Vogt wrote: > please consider updating synaptic for debian/sarge. The version in > unstable adds a update to the brasilian translation and fixes the I'd be plsd if you don't forget to add the updated Bulgarian translation, which has some major updates regarding the usability of the translation, many mistakes and typos fixed as well as "debianization" of lots of debian-specific words :-) Thanks for the good work! -- Yavor Doganov Free Software Association - Bulgariahttp://fsa-bg.org GNOME Bulgarian Translation Project http://gnome.cult.bg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Debian GNUstep maintainers] GNUstep and FHS
* Eric Heintzmann <[EMAIL PROTECTED]> writes: > Since there is no other maintainer to try to make these packages FHS > compliant, should GNUstep be removed from Debian ? Speaking on behalf of the tiny Bulgarian GNUstep community I would like to ask you (and RMs as well) not to remove GNUstep from Debian -- this would be a substantial loss for all interested users and contributors. Since GNUstep is broken due to #314385 for more than a month I have stalled all my pending tasks and cannot even imagine what will hapen if it is removed from Debian. Compiling from CVS is not an option and installing the Debian packages is the most convenient and pleasant way for almost everybody, at least everybody I've been able to speak with. If FHS compliancy is compulsory, then probably there are two options: * Ask the RMs/QA for an exception due to GNUstep's nature * Ask the upstream developers (who are currently busy with improving GNUstep on proprietary platforms) to change the filesystem layout -- since it is vital for GNUstep to run solidly and reliably on a GNU system, such as Debian (I am CC-ing Anton Zinoviev, who was planning to make some hacks on the filesystem regarding localisation) -- Yavor Doganov Free Software Association - Bulgaria GNUstep Bulgarian Translation Project -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#1038996: transition: pantomime
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#1039875: transition: gnustep-performance
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#1040335: transition: gnustep-sqlclient
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#1072853: transition: gnustep-base, gnustep-gui
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#1075998: transition: gorm.app
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#1075999: transition: gnustep-dl2
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#1076000: transition: steptalk
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#1075998: transition: gorm.app
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#1072036: release.debian.org: Transition for gsl-2.8 / libgsl28
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#1072036: release.debian.org: Transition for gsl-2.8 / libgsl28
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#1077323: bookworm-pu: package poe.app/0.5.1-6+deb12u1
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#1077325: bullseye-pu: package poe.app/0.5.1-6+deb11u1
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:
Hidden bugs in Objective-C packages due to language standard mismatch
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#767694: unblock: gnustep-gui/0.24.0-3
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#767721: unblock: gnustep-dl2/0.12.0-13
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#767720: unblock: gnustep-back/0.24.0-3
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#767722: unblock: gnustep-netclasses/1.06.dfsg-7
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#767723: unblock: addresses-for-gnustep/0.4.7-2
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#767724: unblock: viewpdf.app/1:0.2dfsg1-5
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#767725: unblock: gorm.app/1.2.20-2
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#767725: unblock: gorm.app/1.2.20-2
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#768923: unblock: rsskit/0.3-3
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
