Bug#123276: Bug: 123276 still present?

[Paul Gevers]

tag 123276 moreinfo
thanks

I am currently running through old bugs of nedit. Could you please tell
me if this bug is still present in the latest version: 1:5.5-3?

Kind regards,
Paul





signature.asc
Description: OpenPGP digital signature

Bug#308635: Bug: 308635 still present?

[Paul Gevers]

tag 308635 moreinfo
thanks

I am currently running through old bugs of nedit. Could you please tell
me if this bug is still present in the latest version: 1:5.5-3?

Kind regards,
Paul



signature.asc
Description: OpenPGP digital signature

Bug#369317: What news?

[Paul Gevers]

> It's now been over two years since the last response from the former
> maintainer (?), and the bug is still present in Lenny.  What does the
> time line look like for a fix?

Upstream is (slowly) working on a maintainer release. I am adopting
nedit and have a beta of the new upstream release present for review on
mentors.debian.net. I will look into the open bugs and see how things
go. I am picking up. A lot of the nedit bugs are related to lesstif2
which had some lack of attention. I am also looking into that package to
help the maintainer.

Paul




signature.asc
Description: OpenPGP digital signature

Bug#689896: lastfmsubmitd is maintained by Debian QA group

[Paul Gevers]

Hi Zigo,

As lastfmsubmitd is maintained by the Debian QA group, I will just go
ahead and upload a new version of lastfmsubmitd with your patch applied.
I will request an unblock after the upload.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#652814: lastfmsubmitd: Should we change permissions of /var/log/lastfmsubmitd?

[Paul Gevers]

Package: lastfmsubmitd
Version: 1.0.6-3
Followup-For: Bug #652814

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The last reporter added the "su" part to logrotate. I am not comfortable with
that. I don't understand why /var/log/lastfmsubmitd should be writable by 
the whole "spool" group. I think that was a mistake by the original maintainer.
As I don't know lastfmsubmitd, I like to give others the possibility to add
comments.

Paul

- -- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-3-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages lastfmsubmitd depends on:
ii  adduser3.113+nmu3
ii  debconf [debconf-2.0]  1.5.46
ii  python 2.7.3~rc2-1
ii  python-support 1.0.15

lastfmsubmitd recommends no packages.

Versions of packages lastfmsubmitd suggests:
pn  ears  

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlB+oBUACgkQHNUte6r+CGo0wQCeM5Vtyer1L5K6lNSnlcFaMQqV
4PAAn3eGtN3hD2xJtAB4rwbH0+bzSlhc
=EvOG
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20121017120957.8328.35254.report...@wollumbin.marsaxlokk.homelinux.org

Bug#690765: lastfmsubmitd: please delete log files on purge

[Paul Gevers]

Package: lastfmsubmitd
Version: 1.0.6-3
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Policy 10.8 says:
Log files should be removed when the package is purged (but not when it is only
removed). This should be done by the postrm script when it is called with the
argument purge (see Details of removal and/or configuration purging, Section 
6.8).

Please do that.

- -- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-3-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlB+ogUACgkQHNUte6r+CGooLwCdGgstqPf2NlGd7nqFq5LvE862
yk0An0J3B6ksQjaCG3ojbiAOuAv4x47I
=c90s
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20121017121817.8265.34301.report...@wollumbin.marsaxlokk.homelinux.org

Bug#687597: openslp-dfsg: touch bug CVE-2012-4428

[Paul Gevers]

Package: openslp-dfsg
Followup-For: Bug #687597

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

As far as I can tell, no solution known yet, on 17 October 2012, 15:28 +0200.

While going through Debian QA group owned RC bugs, I touched on this bug.

http://security-tracker.debian.org/tracker/CVE-2012-4428

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlB+s40ACgkQHNUte6r+CGp99gCfb8V0OkWyTOTq68wZjuK50O/b
9tMAn2wLN1mGAPXS2YM36VgtU2hd0wVV
=selz
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20121017133301.9608.69018.report...@wollumbin.marsaxlokk.homelinux.org

Bug#692342: update information on several apt-move bugs

[Paul Gevers]

retitle 639770 apt-move: fails to open fifo-file and hangs
tags 639770 + unreproducible
retitle 398297 apt-move: wrong version selected if containing tilde '~'
merge 398297 539524
retitle 692342 apt-move uses obsolete implicit split functionality
tags 692342 + pending, patch
thanks

Seems this bug (692342) depends on the version of perl. According to the
proposed patch in bug 398297 [1], the implicit use of split has been
removed in version 5.12.

I am preparing an upload for this bug with the attached patch.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=398297#20
Description: The use of implicit split call has been removed from perl
 in version 5.12 as it had been deprecated for 15 years
Author: Paul Gevers 
Bug-Debian: http://bugs.debian.org/692342
Forwarded: no

--- a/move3
+++ b/move3
@@ -42,7 +42,7 @@
 }
 
 while (<>) {
-	split;
+	@_=split;
 
 	if ($_[0] eq "D") {
 		if (fileno(MKDIR) == undef) {


signature.asc
Description: OpenPGP digital signature

Bug#691393: work in progress

[Paul Gevers]

tag -1 +pending
thanks

Hi,

We are working on it. See [1] and bug 695130 [2].

Paul

[1] http://anonscm.debian.org/gitweb/?p=collab-maint/motif.git
[2] http://bugs.debian.org/bug=695130



signature.asc
Description: OpenPGP digital signature

pre-approval of rename openmotif -> motif for main archive

[Paul Gevers]

Hi ftp-master(s),

Maybe you have seen on debian-devel [1] that (open)motif is now released
under a DSFG-free license and that we are working on getting [2] it in
shape for debian/main. Actually, my intention is that it fully replaces
lesstif2 (which is starting to look slightly bit-rotten) in jessie.

My questions now are:
- Do you agree with the renaming of the source package from openmotif to
motif (upstream renamed it's project as well, we think we should follow
as the widget set is well known under the name motif). Binary packages
are not renamed.

- I could not find the proper documentation of what to take care of, in
case of a source rename, other than properly migrating the bugs in the
BTS. Are there more issues involved?

- If you judge the licensing to be in order, as I have, is uploading the
new source (to experimental at this stage of freeze) the right thing to
do to get it into main (after changing the d/control entry of course)?

Kind regards
Paul

[1] https://lists.debian.org/debian-devel/2012/12/msg00369.html
[2] http://anonscm.debian.org/gitweb/?p=collab-maint/motif.git



signature.asc
Description: OpenPGP digital signature

Please review package description of (open)motif

[Paul Gevers]

Hi all,

[Please keep cc in the loop.]

Currently, Graham and I are working on getting (open)motif [1] in shape
for inclusion in main. While I was going through the package I was
unhappy with the current description of the binary packages. I have
already extended the description of motif-clients, but I would like a
review of all descriptions.

I hope you can help.

Paul

[1] http://packages.qa.debian.org/o/openmotif.html
Source: motif
Section: devel
Priority: optional
Build-Depends: byacc,
   debhelper (>= 9),
   dh-autoreconf,
   dh-exec,
   flex,
   libsm-dev,
   libx11-dev,
   libxaw7-dev,
   libxext-dev,
   libxft-dev,
   libxmu-dev,
   libxt-dev,
   xbitmaps
Maintainer: Graham Inggs 
Uploaders: Paul Gevers 
Standards-Version: 3.9.4
Homepage: http://motif.ics.com/
Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/motif.git
Vcs-Git: git://anonscm.debian.org/collab-maint/motif.git

Package: libmotif4
Architecture: any
Section: libs
Multi-Arch: same
Depends: ${misc:Depends}, ${shlibs:Depends}
Pre-Depends: ${misc:Pre-Depends}, x11-common (>= 1:7.0.0)
Conflicts: libmotif3
Replaces: libmotif3
Provides: libmotif3
Description: Motif - shared libraries
 This package includes all files you need to run Motif
 applications which are linked against Motif, which
 are the shared libraries for the most part.

Package: libmotif4-dbg
Architecture: any
Depends: libmotif4 (= ${binary:Version}), ${misc:Depends}
Section: debug
Priority: extra
Conflicts: lesstif2-dbg
Description: Motif - shared libraries debugging symbols
 This package includes all files you need to run Motif
 applications which are linked against Motif, which
 are the shared libraries for the most part.
 .
 This package contains the debugging symbols.

Package: libmotif-dev
Architecture: any
Section: libdevel
Depends: libmotif4 (= ${binary:Version}), ${misc:Depends}, ${shlibs:Depends}
Conflicts: lesstif-bin, lesstif-dev, lesstif-doc, lesstif2-dev
Description: Motif - development files
 Everything you need to build Motif applications with
 Motif.  This includes header files, static libraries,
 the manual pages for the Motif API and uil (user interface
 language compiler)

Package: motif-clients
Architecture: any
Section: x11
Depends: menu, ${misc:Depends}, ${shlibs:Depends}
Pre-Depends: x11-common (>= 1:7.0.0)
Conflicts: lesstif-bin
Description: Motif window manager and virtual key bindings configure client
 Motif is the industry standard toolkit for *NIX systems. This package
 contains the Motif window manager, which has clear but classical appearance,
 and xmbind, which is used to configure virtual key bindings for motif.


signature.asc
Description: OpenPGP digital signature

Re: Please review package description of (open)motif

[Paul Gevers]

Hi Justin and the rest,

On 19-01-13 15:00, Justin B Rye wrote:
> Paul Gevers wrote:
>> [Please keep cc in the loop.]

>> Package: motif-clients
> 
> What does this package name mean, anyway?  Is the idea that it's a set
> of executables that have a client relationship towards Motif, whatever
> that means, or are they just Motif-based tools that happen (obviously)
> to be graphical, and therefore (obviously) count as X11 clients?
> 
> Either way, it seems an odd way of looking at things.  Why would a
> user search for and then install this package?  If the point of the
> exercise is to get a Motif-flavoured X environment, wouldn't it make
> more sense to call the package simply "mwm - Motif Window Manager"?

Oh, that seems very sensible to me as well. As the original creator of
the openmotif source package is not active in Debian anymore, we can not
ask. So I propose to rename (including creation of a proper transitional
package).

> It's a more general MWM configurator.  And
> since we've already mentioned MWM we could just say:
> 
>   Description: Motif window manager and setup tool
>
> But why do we even need to care about xmbind?  Most packages that
> contain window managers also contain one or two other trivial helper
> binaries; but they put the focus in the packagename and synopsis on
> the thing that users might actually want to install.  So again I'm
> back to wondering why this isn't "Description: Motif Window Manager"
> (but again that's not in my patch).

Agreeing with your argument, I would go for

  Description: Motif Window Manager

>>  Motif is the industry standard toolkit for *NIX systems. This package
> 
> Surely the standard toolkit for *NIX systems is something more like
> coreutils?  Or if we're talking "graphical" it would be X... should we
> perhaps call it "the standard GUI component toolkit for *NIX"?
> 
> We could also insert a linebreak to get a paragraph that could fit
> neatly at the start of each package description in the set as a
> boilerplate intro.

Good.

>>  contains the Motif window manager, which has clear but classical appearance,
> 
> "(It) has clear appearance" sounds like it's missing an article.
> 
> (Classical?  Now I'm imagining a Roman mosaic tiled window manager.)

Sorry, I am not a native speaker. I try to say that it looks a dated
(already a decade). Would that be a better word than?

>>  and xmbind, which is used to configure virtual key bindings for motif.
> 
> Since we're not pressed for space here I'll suggest expanding this to
> "virtual key/mouse-bindings".

Sure. Maybe we should even focus less on xmbind. Make the first part
about MWM end with a full stop and mention it more as an auxiliary tool:
 This package contains the Motif window manager, which has a clear but
 classical appearance. It is accompanied by xmbind, which is used to
 configure virtual key/mouse-bindings for Motif.

> (So "OpenMotif" is the old non-free version and now it's gone LGPL
> it's called plain "Motif"?  Okay, confusing.)

Yes. Indeed. Motif has been used in the past for the group of software
implementations of motif: the paid variant, the free (but not dsfg-free)
version openmotif and lesstif, which was the only really free
implementation of motif.

>> Source: motif
>> Section: devel
> 
> (Wait, why is the source package's Section set to something not used
> by any of the binary packages?)

Shoot. I hadn't seen that. Good point. Let me figure out where it should
go. I think it really should go into x11.

> This has a bit more content to it, but the sentence-fragment about
> building Motif apps with Motif has got to go!  Oh, and it's not true
> that this package provides all of build-essential.  How about:
> 
>   Description: Motif - development files
>Motif is the industry standard GUI component toolkit for *NIX.
>.
>This package provides everything needed for developing Motif
>applications, including header files, static libraries, the API
>manual pages, and uil, the user interface language compiler.

Nice.

Paul
Source: motif
Section: x11
Priority: optional
Build-Depends: byacc,
   debhelper (>= 9),
   dh-autoreconf,
   dh-exec,
   flex,
   libsm-dev,
   libx11-dev,
   libxaw7-dev,
   libxext-dev,
   libxft-dev,
   libxmu-dev,
   libxt-dev,
   xbitmaps
Maintainer: Graham Inggs 
Uploaders: Paul Gevers 
Standards-Version: 3.9.4
Homepage: http://motif.ics.com/
Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/motif.git
Vcs-Git: git://anonscm.

Re: First motif commits

[Paul Gevers]

On 21-01-13 20:54, Graham Inggs wrote:
> If you want.  Do you want to start a new thread there?

Just continue.

> I still have the source code for every Debian package that depends on
> libmotif-dev and lesstif2-dev on my PC, so I ran 'grep -i
> XmPrintPopupPDM -l -r *' for each of the six missing symbols you listed
> previously and did not find a single match.
> Good news is we can't break anything in Debian if we hack PrintS.c, bad
> news is we don't have any applications with which to test.

Fully ack.

> Ok, let's try 3 and see where that takes us.  I'm not keen on 2 because
> there are still proprietary applications being used that need libXm.so.3
> and libXm.so.4.

Yes, but it is still easy for system administrators to add the symlinks
themselves, if they feel comfortable with it.

> I've just come across this:
> http://bugs.motifzone.net/long_list.cgi?buglist=1545
> https://bugzilla.redhat.com/show_bug.cgi?id=229409
> 
> It seems Red Hat deprecated Xprint in 2007, it may be that the
> "official" Motif libraries are built without Xprint support.

Yes, I understand. Debian also removed xprint from the repository. But
the glue layer libxp is still there to PREVENT problems. This means that
you don't have printing support anyway, but that things don't just break.

> Maybe we have to drop the XmPrint functions in order to be binary
> compatible?

Nope, ADDITIONAL symbols is never a problem. Please read the policy
chapter 8 [1] for some background if you didn't already, especially 8.6.2.

[1] http://www.debian.org/doc/debian-policy/ch-sharedlibs.html

> What do you think of releasing another openmotif 2.3.3 package including
> the three patches from Ubuntu?
> http://changelogs.ubuntu.com/changelogs/pool/multiverse/o/openmotif/openmotif_2.3.3-6ubuntu1/changelog

No need. I think we will be uploading shortly, and then these changes
will be gone anyway. Unless you fear that it might still take a long
time. I don't think these patches warrant a release-freeze [2]. As it
is, we are still waiting for an unblock of 2.3.3-7 anyway ... uhm, oops,
I still have to file that one I see.

[2] http://release.debian.org/wheezy/freeze_policy.html

> If you are in agreement, is there anything I can do to assist?

So unless you can convince me otherwise, I don't think we should do this.

> In particular, I'd like the libmotif3 and display manager entries.  I do
> not know why Ubuntu needs the bin-utils-gold patch, and Debian doesn't
> (Debian doesn't need it in 2.3.4 because this patch is against a demo).

Unfortunately, "liking" is not on the list of freeze exceptions. I think
Debian would also need the bin-utils-gold patch if it were using the
gold linker. I believe Ubuntu actively tests for that.

Actually, I hope Logan Rosen checked my patch in 2.3.3-6 as I think it
is flawed. That is why I uploaded 2.3.3-7.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#698661: unblock: openmotif/2.3.3-7

[Paul Gevers]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Please unblock package openmotif

Openmotif 2.3.3-7 is an update to 2.3.3-5 to allow two release goals:
- - code hardening
- - multi-arch
and a fix for policy violation 6.8:
- - openmotif leaves files behind after purge.

debdiff is attached.

unblock openmotif/2.3.3-7

- -- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBCAAGBQJQ/avbAAoJEJxcmesFvXUKXeIH/0X3UNM2B5thrwhWB96itng9
f6/ZHtzGc6lfaCO2DbsEuWU7fLHipumecc9R/oeEFwAoMsVtz96tbn0eVGzJiIEw
5/gOmSDmXopO/aRgop2ycbWyrMXRMpA7VvHRaUPc1o5/PA7dD9vRYiIqs8AWq+Wu
Nvx/ru9sS/tEgh3XQ0rTij3MFlCr71Zy7rJUKasP7hnMT8M4uoSv1hwytKd/bTMs
O539WEG2YCzz0V7roM9tpZkMUHXR4WqYDUcYSvckU/+lFYzWfTSBzzxjcnxO6b2t
FdF+NVXvn4w4DWHmPN2frA8qkkyieTHAarurMg0V/3JoFP3xBgTlCu8z/vT7Mtk=
=CIpm
-END PGP SIGNATURE-
diff -u openmotif-2.3.3/debian/changelog openmotif-2.3.3/debian/changelog
--- openmotif-2.3.3/debian/changelog
+++ openmotif-2.3.3/debian/changelog
@@ -1,3 +1,31 @@
+openmotif (2.3.3-7) unstable; urgency=low
+
+  * QA upload.
+  * Improve 0005-sprintf-error-message-hardening-format-security.patch to use
+strcpy i.s.o. sprintf and properly format string.
+
+ -- Paul Gevers   Sat, 05 Jan 2013 21:36:38 +0100
+
+openmotif (2.3.3-6) unstable; urgency=low
+
+  * QA upload.
+- Set maintainer to QA group
+  * Allow multiarch (Closes: #673690)
+- Multi-Arch: same for libmotif4
+- Add Pre-Depends: multiarch-support
+- d/*.files use wild-card
+- d/rules export DEB_HOST_MULTIARCH and use it for configure with --libdir
+- Add patch to NOT move /usr/lib/X11 files (thanks Sergio Gelato)
+  * Enable hardening
+- Build-Depend on dpkg-dev (>=1.6.1)
+- d/rules: move declaration of CFLAGS earlier
+- Add patch to prevent "format not a string literal and no format arguments"
+- Add patch to prevent a case of "format '%d' expects argument of type
+  'int', but argument 5 has type 'size_t'"
+  * Remove update-menu created configuration files on purge (Closes: #656169)
+
+ -- Paul Gevers   Tue, 25 Dec 2012 09:04:47 +0100
+
 openmotif (2.3.3-5) unstable; urgency=low
 
   * Fix hopefully the build problems on mips* 
reverted:
--- openmotif-2.3.3/debian/motif-clients.postrm.off
+++ openmotif-2.3.3.orig/debian/motif-clients.postrm.off
@@ -1,3 +0,0 @@
-#!/bin/sh
-test -x /usr/bin/update-menus && /usr/bin/update-menus
-#DEBHELPER#
diff -u openmotif-2.3.3/debian/libmotif-dev.files openmotif-2.3.3/debian/libmotif-dev.files
--- openmotif-2.3.3/debian/libmotif-dev.files
+++ openmotif-2.3.3/debian/libmotif-dev.files
@@ -1,7 +1,7 @@
-/usr/lib/libMrm.a
-/usr/lib/libUil.a
-/usr/lib/libXm.a
-/usr/lib/lib*.so
+/usr/lib/*/libMrm.a
+/usr/lib/*/libUil.a
+/usr/lib/*/libXm.a
+/usr/lib/*/lib*.so
 /usr/include/Xm
 /usr/include/Mrm
 /usr/include/uil
diff -u openmotif-2.3.3/debian/rules openmotif-2.3.3/debian/rules
--- openmotif-2.3.3/debian/rules
+++ openmotif-2.3.3/debian/rules
@@ -10,10 +10,16 @@
 
 include /usr/share/quilt/quilt.make
 
+# Enable hardening options
+DPKG_EXPORT_BUILDFLAGS = 1
+include /usr/share/dpkg/buildflags.mk
+CFLAGS += -fno-strict-aliasing -D_FILE_OFFSET_BITS=64
+
 # From /usr/share/doc/autotools-dev/README.Debian.gz
 export DEB_HOST_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
 export DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
 export DEB_HOST_ARCH_CPU  ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_CPU)
+export DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
 
 ifeq ($(DEB_BUILD_GNU_TYPE), $(DEB_HOST_GNU_TYPE))
   confflags += $(DEB_HOST_GNU_TYPE)
@@ -22,18 +28,18 @@
 endif
 
 ifeq '$(DEB_HOST_ARCH_CPU)' 'mips'
-CFLAGS_NEW =-mplt
+CFLAGS +=-mplt
 endif
 
 ifeq '$(DEB_HOST_ARCH_CPU)' 'mipsel'
-CFLAGS_NEW =-mplt
+CFLAGS +=-mplt
 endif
 
 build: build-stamp
 
 build-stamp: $(QUILT_STAMPFN)
 	dh_testdir
-	CFLAGS="-g -O2 -fno-strict-aliasing -D_FILE_OFFSET_BITS=64 $(CFLAGS_NEW)" ./configure --prefix=/usr --mandir=/usr/share/man --build=$(DEB_HOST_GNU_TYPE) --host=$(DEB_HOST_GNU_TYPE)
+	./configure --prefix=/usr --mandir=/usr/share/man --build=$(DEB_HOST_GNU_TYPE) --host=$(DEB_HOST_GNU_TYPE) --libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH)
 		make;
 		touch build-stamp
 
diff -u openmotif-2.3.3/debian/libmotif4.files openmotif-2.3.3/debian/libmotif4.files
--- openmotif-2.3.3/debian/libmotif4.files
+++ openmotif-2.3.3/debian/libmotif4.files
@@ -1,3 +1,3 @@
-/usr/lib/lib*.so.*
+

Re: Bug#698661: unblock: openmotif/2.3.3-7

[Paul Gevers]

On 22-01-13 15:21, Niels Thykier wrote:
>> Openmotif 2.3.3-7 is an update to 2.3.3-5 to allow two release goals:
>> - code hardening
> 
> This does not appear to close a bug and therefore, I presume, is there
> for not on the "target list" for Wheezy?  If it is not on this list,
> then I would prefer to defer this for Jessie.  If it is on that list, I
> would be willing to accept it[1].

Hmm. I see you just updated the release goals [2]. I was follow the
requirements there to hardening [3]. So, until today this was a release
goal: "This goal is to update as many packages as possible to use
security hardening build flags via dpkg-buildflags." Of course, if it is
now unacceptable, I will remove it ASAP. Regarding your [1], where can I
actually find this list? Not that I think openmotif is on it, but anyway.

>> - multi-arch
> 
> "Multi-arch: same" conversions have not been acceptable since the start
> of the freeze.  So unfortunately, I cannot accept this change either.

I must have missed this, I really thought it was still part of the
solution. Anyways.

>> and a fix for policy violation 6.8:
>> - openmotif leaves files behind after purge.
> 
> I would very much appreciate this change.

Ok.

Paul

> [1] Mind you, we are stricting our Freeze Policy atm.  Since your
> request preceeds that official change to the policy, I am willing to
> accept the hardening change if it is on the target list.
[2] http://wiki.debian.org/ReleaseGoals/
[3] http://wiki.debian.org/ReleaseGoals/SecurityHardeningBuildFlags



signature.asc
Description: OpenPGP digital signature

Re: Bug#698661: unblock: openmotif/2.3.3-7

[Paul Gevers]

tags 698661 -moreinfo
retitle 698661 unblock: openmotif/2.3.3-8
reopen 673690
thanks

On 22-01-13 15:21, Niels Thykier wrote:
> Can you please re-upload openmotif with the M-A (and possibly the
> hardening) changes reverted.

Done.

Debdiff attached, very simple now.

Paul

diff -u openmotif-2.3.3/debian/changelog openmotif-2.3.3/debian/changelog
--- openmotif-2.3.3/debian/changelog
+++ openmotif-2.3.3/debian/changelog
@@ -1,3 +1,39 @@
+openmotif (2.3.3-8) unstable; urgency=low
+
+  * QA upload.
+  * Reverting multiarch and hardening changes since 2.3.3-5 on request of
+release-team (see bug #698661) to allow for transition to Wheezy.
+
+ -- Paul Gevers   Tue, 22 Jan 2013 20:52:01 +0100
+
+openmotif (2.3.3-7) unstable; urgency=low
+
+  * QA upload.
+  * Improve 0005-sprintf-error-message-hardening-format-security.patch to use
+strcpy i.s.o. sprintf and properly format string.
+
+ -- Paul Gevers   Sat, 05 Jan 2013 21:36:38 +0100
+
+openmotif (2.3.3-6) unstable; urgency=low
+
+  * QA upload.
+- Set maintainer to QA group
+  * Allow multiarch (Closes: #673690)
+- Multi-Arch: same for libmotif4
+- Add Pre-Depends: multiarch-support
+- d/*.files use wild-card
+- d/rules export DEB_HOST_MULTIARCH and use it for configure with --libdir
+- Add patch to NOT move /usr/lib/X11 files (thanks Sergio Gelato)
+  * Enable hardening
+- Build-Depend on dpkg-dev (>=1.6.1)
+- d/rules: move declaration of CFLAGS earlier
+- Add patch to prevent "format not a string literal and no format 
arguments"
+- Add patch to prevent a case of "format '%d' expects argument of type
+  'int', but argument 5 has type 'size_t'"
+  * Remove update-menu created configuration files on purge (Closes: #656169)
+
+ -- Paul Gevers   Tue, 25 Dec 2012 09:04:47 +0100
+
 openmotif (2.3.3-5) unstable; urgency=low
 
   * Fix hopefully the build problems on mips* 
diff -u openmotif-2.3.3/debian/control openmotif-2.3.3/debian/control
--- openmotif-2.3.3/debian/control
+++ openmotif-2.3.3/debian/control
@@ -3,7 +3,7 @@
 Priority: extra
 Build-Depends: debhelper (>= 6.0.7), libxaw7-dev, byacc, flex, libsm-dev, 
libx11-dev,
  libxext-dev, libxmu-dev, libxp-dev, libxt-dev, xbitmaps, libxft-dev, 
autotools-dev, quilt
-Maintainer: Stefan Bauer  
+Maintainer: Debian QA Group 
 Standards-Version: 3.9.1.0
 Homepage: http://www.motifzone.net/ 
 XS-Autobuild: yes
only in patch2:
unchanged:
--- openmotif-2.3.3.orig/debian/motif-clients.postrm
+++ openmotif-2.3.3/debian/motif-clients.postrm
@@ -0,0 +1,8 @@
+#!/bin/sh
+set -e
+
+# Remove configuration files created by update-menus
+if [ "$1" = "purge" ] ; then
+rm -rf /etc/X11/mwm
+fi
+#DEBHELPER#


signature.asc
Description: OpenPGP digital signature

Re: First motif commits

[Paul Gevers]

On 31-01-13 21:11, Graham Inggs wrote:
> Actually, it looks like we should ditch libmotif4 and name the separate
> packages libXm4, libUil4 and libMrm4.

Agree.

> On 31 January 2013 21:41, Graham Inggs  > wrote:
> 
> I've had a look at incorporating
> d/patches/05-multiarch-specialcase-libdir-X11.patch into
> configure.ac  as a build option, and was
> thinking that perhaps now is the time to move these platform
> independent files, as Sergio suggested, from /usr/lib/X11/bindings
> to /usr/share/X11/bindings and into a separate package
> motif-common'.

I think I agree.

> Also, /usr/lib/X11/system.mwmrc can be relocated to
> /usr/share/X11, but remain in package mwm.

Have to investigate, but I assume for know you know what you are proposing.

> At the same time we could split the three shared libraries;
> libXm.so.*, libUil.so.* and libMrm.so.* into separate packages. 
> What do you think of the names libmotif4, libmotifuil4 and
> libmotifmrm4?  I know the name of the last one is redundant (mrm is
> Motif Resource Manager), but it is consistent with the others.

See above.

> If we are in agreement with the above I'll start working on it.
> 
> I'm warming to the idea of releasing motif to experimental without
> printing support, without the missing XmPrint* exports, and without
> bumping the soname.
> As I wrote previously, I don't believe this will break anything in
> Debian.  Should we start getting bug reports of broken applications,
> at least we'll have a test case for option 3 (Maintain ABI
> compatibility, but return failures from xprint methods).

Although indeed not allowed, I see your point. Maybe we can justify it
by the move to main? Hmm, I guess not, but indeed I believe it doesn't
work now anyway as the xprint support is removed etc.

Paul



signature.asc
Description: OpenPGP digital signature

Re: First motif commits

[Paul Gevers]

On 01-02-13 08:31, Paul Gevers wrote:
> On 31-01-13 21:11, Graham Inggs wrote:
>> Actually, it looks like we should ditch libmotif4 and name the separate
>> packages libXm4, libUil4 and libMrm4.
> 
> Agree.

Not perfect yet, but I did some of the work on the split (bed time now
though). Pushed to the repo.

>> I've had a look at incorporating
>> d/patches/05-multiarch-specialcase-libdir-X11.patch into
>> configure.ac <http://configure.ac> as a build option, and was
>> thinking that perhaps now is the time to move these platform
>> independent files, as Sergio suggested, from /usr/lib/X11/bindings
>> to /usr/share/X11/bindings and into a separate package
>> motif-common'.

Does this also count for the bitmaps? (Not implemented by me yet).

>> Also, /usr/lib/X11/system.mwmrc can be relocated to
>> /usr/share/X11, but remain in package mwm.
> 
> Have to investigate, but I assume for know you know what you are proposing.

Not yet looked into, but if you think this is reasonable (it sounds like
it), please show how you want to do it.

Paul



signature.asc
Description: OpenPGP digital signature

Re: First motif commits

[Paul Gevers]

On 04-02-13 22:41, Graham Inggs wrote:
> On 3 February 2013 23:34, Paul Gevers  <mailto:elb...@debian.org>> wrote:
> 
> 
> Not perfect yet, but I did some of the work on the split (bed time now
> though). Pushed to the repo.
> 
>  
> Ah, I actually did this on Thursday and Friday last week, although I
> went as far as making a libmotif-common as well.

But you forgot to push... Lets agree that we either tell the other that
we are working on something, or just push (soon).

> I did split the bitmaps off into libmotif-common, but left them located
> at /usr/include/X11/bitmaps.
> I thought of moving these to /usr/share/X11/bitmaps, but
> /usr/include/X11/bitmaps seems to be used by other X packages as well.

I have to check the location, but it sounds good.

> This location is checked by mwm for a system menu if one does not exist
> in the user's home directory.
> Shall I push my proposed changes to git or would it be better to attach
> a diff here for discussion?
> (this is why I didn't push my proposed split for libmotif as well)

No, lets use git for that. Reverting is not difficult if you make small
git commits (please never put everything together in one big commit, but
split commits in logical segments. Especially, it could be just me, but
I like to put the commit with combined changelog changes always
separately from everything else).

Paul



signature.asc
Description: OpenPGP digital signature

Re: First motif commits

[Paul Gevers]

On 05-02-13 19:06, Graham Inggs wrote:
> I thought I had made it clear I was going to work on splitting 
> libmotif4, but no harm done.

Sorry, slight misunderstanding. I thought it was your proposal. As I had
time and hadn't seen any progress, I decided to try some of that work.
Maybe the symbols still need a slight update by the way.

> Again I have study commitments until the end of this week, but when I
> get the chance, I will compare the splits and push any additions I
> have.

I think that if we have the split of -common, it is time to upload the
package to experimental, to see if the ftp-masters can let the new
package into main. We can then also start to ask dependent package to
try out building against motif instead of lesstif2.

Paul
PS, I don't think I will have any time next week. I hope the week after
we can do the upload.



signature.asc
Description: OpenPGP digital signature

Re: First motif commits

[Paul Gevers]

On 07-02-13 07:03, Graham Inggs wrote:
> On 6 February 2013 22:07, Paul Gevers  <mailto:elb...@debian.org>> wrote:
> 
>> I think that if we have the split of -common, it is time to upload
>> the package to experimental, to see if the ftp-masters can let the
>> new package into main. We can then also start to ask dependent
>> package to try out building against motif instead of lesstif2.
> 
> 
> The only other thing I can think of is splitting libmotif-dev into 
> libxm4-dev, libmrm4-dev, libuil4-dev

Don't you think this is a little overkill? Not that I have a strong
objection, but do we really need so many packages? Hmm, looking at e.g.
libav, I guess it is not strange.

> and a new package for uil (the actual UIL compiler executable and its
> man pages) and then leaving the common bits in libmotif-dev.  What do
> you think?

So all in all, seems reasonable.

Paul



signature.asc
Description: OpenPGP digital signature

Re: First motif commits

[Paul Gevers]

On 16-02-13 17:19, Graham Inggs wrote:
> Stefano agreed with you about multiple -dev packages being overkill.  I
> did go ahead though, with splitting uil into its own package and marking
> it multiarch: foreign, it could be used for multiarch cross-compiling.

Ok, fine.

> I decided to rename your fix_lintian_reported_manpage_typos.patch and
> while updating the series file I noticed that
> 06-cast-size_t-to-int.patch hadn't been in since January 13, so I
> replaced it.

Do you really care for the numbers in front? I usually find them
annoying, especially in the future, when some patches might get dropped
because they are fixed and others not, do you then rename again? This
tends to make reading history more difficult. But if you want to, I
don't care enough to make a bigger point out of this than these lines.

> I don't have any further changes planned, so I await your comments.

I am finishing the symbols files and have two more patches fixing a typo
and fixing hyphen use in the manpages.

I am checking your latest changes and if all right, I will upload today.

Paul



signature.asc
Description: OpenPGP digital signature

Re: [SCM] Motif widgetset library branch, master, updated. 10e3e364ae46c34cbb88cba0aecab1e053bca5fa

[Paul Gevers]

Hi Graham,

On 16-02-13 23:30, Graham Inggs wrote:
> The following commit has been merged in the master branch:
> commit 10e3e364ae46c34cbb88cba0aecab1e053bca5fa
> Author: Graham Inggs 
> Date:   Sun Feb 17 00:24:02 2013 +0200
> 
> Mark transitional package libmotif4 Architecture: any, Multi-Arch: same 
> for upgrades
> 
> diff --git a/debian/control b/debian/control
> index 449690d..f586438 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -141,9 +141,10 @@ Description: Motif Window Manager (transitional package)
>   mwm. It can safely be removed.
>  
>  Package: libmotif4
> -Architecture: all
> +Architecture: any
>  Section: oldlibs
>  Priority: extra
> +Multi-Arch: same
>  Depends: libmrm4, libuil4, libxm4, ${misc:Depends}, ${shlibs:Depends}
>  Provides: libmotif3
>  Description: Motif - shared libraries (transitional package)

As libmotif4 is a virtual (empty) package, why did you change the
architecture from all to any? I don't think this makes sense.

(Of course you should not set Multi-Arch same on Arch all. See
https://wiki.ubuntu.com/MultiarchSpec#Binary_package_control_fields)

Paul





signature.asc
Description: OpenPGP digital signature

Re: [SCM] Motif widgetset library branch, master, updated. 4751c883f4b27e8e34c0da1e195555ff71740fa1

[Paul Gevers]

On 16-02-13 13:28, Graham Inggs wrote:
> The following commit has been merged in the master branch:
> commit 4751c883f4b27e8e34c0da1e19ff71740fa1
> Author: Graham Inggs 
> Date:   Sat Feb 16 14:27:33 2013 +0200
> 
> Split non-libs from libxm4 into libmotif-common
> 
> diff --git a/debian/control b/debian/control
> index 387fc9e..6d37889 100644
> --- a/debian/control
> +++ b/debian/control
>  Package: libmrm4
>  Architecture: any
>  Section: libs
>  Multi-Arch: same
>  Depends: ${misc:Depends}, ${shlibs:Depends}
>  Pre-Depends: x11-common (>= 1:7.0.0), ${misc:Pre-Depends}
> -Breaks: libmotif3 (<< 2.3.3-2), libmotif4 (<< 2.3.4)
> -Replaces: libmotif3 (<< 2.3.3-2), libmotif4 (<< 2.3.4)
>  Description: Motif - shared resource management library
>   Motif is the industry standard GUI component toolkit for *NIX.

Why did you remove the Breaks/Replaces? libmrm4 contains files that used
to be in libmotif3/libmotif4, so I believe they are needed to prevent
co-installation.

> @@ -41,8 +56,6 @@ Section: libs
>  Multi-Arch: same
>  Depends: ${misc:Depends}, ${shlibs:Depends}
>  Pre-Depends: x11-common (>= 1:7.0.0), ${misc:Pre-Depends}
> -Breaks: libmotif3 (<< 2.3.3-2), libmotif4 (<< 2.3.4)
> -Replaces: libmotif3 (<< 2.3.3-2), libmotif4 (<< 2.3.4)
>  Description: Motif - shared user interface library
>   Motif is the industry standard GUI component toolkit for *NIX.

Idem.

> @@ -53,10 +66,8 @@ Package: libxm4
>  Architecture: any
>  Section: libs
>  Multi-Arch: same
> -Depends: ${misc:Depends}, ${shlibs:Depends}
> +Depends: libmotif-common (= ${source:Version}), ${misc:Depends}, 
> ${shlibs:Depends}
>  Pre-Depends: x11-common (>= 1:7.0.0), ${misc:Pre-Depends}
> -Breaks: libmotif3 (<< 2.3.3-2), libmotif4 (<< 2.3.4)
> -Replaces: libmotif3 (<< 2.3.3-2), libmotif4 (<< 2.3.4)
>  Description: Motif - shared Xm library
>   Motif is the industry standard GUI component toolkit for *NIX.

Idem.

Paul



signature.asc
Description: OpenPGP digital signature

Re: [SCM] Motif widgetset library branch, master, updated. 4751c883f4b27e8e34c0da1e195555ff71740fa1

[Paul Gevers]

On 17-02-13 09:20, Paul Gevers wrote:
> Why did you remove the Breaks/Replaces? libmrm4 contains files that used
> to be in libmotif3/libmotif4, so I believe they are needed to prevent
> co-installation.

Hmm, I think I understand. As you removed all common files, these
packages should not contain any conflicting files anymore.

I am checking this after building if this is true.

Paul



signature.asc
Description: OpenPGP digital signature

Re: [SCM] Motif widgetset library branch, master, updated. 4751c883f4b27e8e34c0da1e195555ff71740fa1

[Paul Gevers]

On 17-02-13 09:39, Paul Gevers wrote:
> On 17-02-13 09:20, Paul Gevers wrote:
>> Why did you remove the Breaks/Replaces? libmrm4 contains files that used
>> to be in libmotif3/libmotif4, so I believe they are needed to prevent
>> co-installation.
> 
> Hmm, I think I understand. As you removed all common files, these
> packages should not contain any conflicting files anymore.
> 
> I am checking this after building if this is true.
> 
> Paul
> 

Gee, I must be a fool this morning. You already placed them back in your
last commit. Sorry for the noise.

Paul



signature.asc
Description: OpenPGP digital signature

Re: [SCM] Motif widgetset library branch, master, updated. dbe3bee6ec58bdaa141c94c66e85205408dc7d42

[Paul Gevers]

On 17-02-13 18:33, Graham Inggs wrote:
> The following commit has been merged in the master branch:
> commit dbe3bee6ec58bdaa141c94c66e85205408dc7d42
> Author: Graham Inggs 
> Date:   Sun Feb 17 19:32:23 2013 +0200
> 
> Make the Multi-Arch: same package libxm4 Provides: libmotif3/4 instead of 
> libmotif-common
> 
> diff --git a/debian/control b/debian/control
> index 7a732b9..2b6c16f 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -32,7 +32,6 @@ Recommends: libmrm4 (= ${binary:Version}),
>  libxm4 (= ${binary:Version})
>  Breaks: libmotif3 (<< 2.3.3-2), libmotif4 (<< 2.3.4)
>  Replaces: libmotif3 (<< 2.3.3-2), libmotif4 (<< 2.3.4)
> -Provides: libmotif3, libmotif4
>  Description: Motif - common files
>   Motif is the industry standard GUI component toolkit for *NIX.
>   .
> @@ -74,6 +73,7 @@ Depends: libmotif-common (= ${source:Version}),
>  Pre-Depends: x11-common (>= 1:7.0.0), ${misc:Pre-Depends}
>  Breaks: libmotif3 (<< 2.3.3-2), libmotif4 (<< 2.3.4)
>  Replaces: libmotif3 (<< 2.3.3-2), libmotif4 (<< 2.3.4)
> +Provides: libmotif3, libmotif4
>  Description: Motif - X/Motif shared library
>   Motif is the industry standard GUI component toolkit for *NIX.

Hmm, now I see that you have TWO packages that provide libmotif3 (and
libmotif4). I don't think this is correct. Only libmotif4 should provide
libmotif3, don't you agree? And libmotif4 automatically provides
libmotif4. A package could depend on libmotif4, not because of libxm4,
but because of libuil4 or libmrm4. It needs libmotif4 to pull in libuil4
or libmrm4 to work.

I was about to upload the package, but am waiting for your response now.

Paul



signature.asc
Description: OpenPGP digital signature

Re: [SCM] Motif widgetset library branch, master, updated. 10e3e364ae46c34cbb88cba0aecab1e053bca5fa

[Paul Gevers]

On 17-02-13 18:26, Graham Inggs wrote:
> Hi Paul
> 
> Why don't you think this is the proper solution?

See below.

> Previously, there were multiple libmotif4 packages,

True.

> it makes sense that there should be a transitional package for each
> one.

I think transitional packages don't have any architecture dependent
files so they always should be architecture all. Your use case is a
valid one though, that is why I don't know the proper solution. (I won't
mind uploading with your version, but appreciate the search for a better
one.)

> I'll revert to mailing the list after this mail.

Sending this to the list again.

Paul



signature.asc
Description: OpenPGP digital signature

Re: [SCM] Motif widgetset library branch, master, updated. dbe3bee6ec58bdaa141c94c66e85205408dc7d42

[Paul Gevers]

On 17-02-13 19:16, Graham Inggs wrote:
> Ah, I didn't notice that the transitional libmotif4 provided libmotif3.
> I have removed that, because it is a transitional package it can be
> uninstalled after the transition, but we still need to show that our
> libxm4 (and libmrm4 and libuil4 and libmotif-common together) still
> provide libmotif3 because of the lib*.so.3 symlinks.
> 
> Regarding the moving of the Provides from the Multi-Arch: foreign
> libmotif-common to the Multi-Arch same libxm4, I thought of a scenario
> where some could have, for example, only the x86_64 version of libmotif4
> installed, they then upgrade to our new package which now provides
> libmotif4 in a Multi-Arch: foreign package.
> They then install an old package depending on libmotif:i386.  The
> installation would proceed without pulling in the i386 libxm4. etc.

My proposal is different:
libmotif4: provides libmotif3 (I added in the description that it can
only be removed if no packages depend on libmotif3) and is indeed
multi-arch same.

All other packages CAN NEVER provide libmotif3 as for each package it
will always be incomplete, and thus no other package can provide full
libmotif3 support on it's own.

An other option is to ALSO provide a virtual libmotif3 package (very
similar to libmotif4).

I don't fully understand the difference between Multi-arch foreign and
allowed. Maybe a possible solution lies in the understanding.

Paul



signature.asc
Description: OpenPGP digital signature

Re: [SCM] Motif widgetset library branch, master, updated. dbe3bee6ec58bdaa141c94c66e85205408dc7d42

[Paul Gevers]

On 17-02-13 20:35, Paul Gevers wrote:
> On 17-02-13 19:16, Graham Inggs wrote:
>> Ah, I didn't notice that the transitional libmotif4 provided libmotif3.
>> I have removed that, because it is a transitional package it can be
>> uninstalled after the transition, but we still need to show that our
>> libxm4 (and libmrm4 and libuil4 and libmotif-common together) still
>> provide libmotif3 because of the lib*.so.3 symlinks.
>>
>> Regarding the moving of the Provides from the Multi-Arch: foreign
>> libmotif-common to the Multi-Arch same libxm4, I thought of a scenario
>> where some could have, for example, only the x86_64 version of libmotif4
>> installed, they then upgrade to our new package which now provides
>> libmotif4 in a Multi-Arch: foreign package.
>> They then install an old package depending on libmotif:i386.  The
>> installation would proceed without pulling in the i386 libxm4. etc.
> 
> My proposal is different:
> libmotif4: provides libmotif3 (I added in the description that it can
> only be removed if no packages depend on libmotif3) and is indeed
> multi-arch same.
> 
> All other packages CAN NEVER provide libmotif3 as for each package it
> will always be incomplete, and thus no other package can provide full
> libmotif3 support on it's own.

To be perfectly clear, I think ONLY libmotif4 could ever provide
libmotif3. The alternative is a libmotif3 package. This is independent
of our final choice of multi-arch for each package.

Paul



signature.asc
Description: OpenPGP digital signature

Re: [SCM] Motif widgetset library branch, master, updated. dbe3bee6ec58bdaa141c94c66e85205408dc7d42

[Paul Gevers]

On 17-02-13 21:13, Graham Inggs wrote:
> but libmrm4
> and libuil4 both depend on libxm4,

I had completely missed that. You are right, they do. But this can not
be seen from the control file, it is added by ${misc:Depends},
${shlibs:Depends}.

> which depends on libmotif-common and
> libxm4 recommends the others (for new installations), so it's a fairly
> safe bet that if you have libxm4 you'll have everything that provides
> libmotif3 and libmotif4.
> It's not perfect, but I do not know of a better solution.

I finally see what you were hinting at. The missing piece was above. But
indeed, because you can not guarantee that all three will be installed
if somebody installs a package that requires libmotif3/libmotif4, I
don't think this is the right solution. Providing a virtual package
(lets not call it transitional then) is I think better.

> An other option is to ALSO provide a virtual libmotif3 package (very
> similar to libmotif4).
>  
> I thought of this, but libmotif3 was dropped from Debian around 2010, so
> I think by now everyone has found another solution; i.e. make their own
> symlinks, or if they are Ubuntu users, upgrade to Precise.

If this is true, why do you care about providing libmotif3 at all? Just
asking.

>> To be perfectly clear, I think ONLY libmotif4 could ever provide
>> libmotif3. The alternative is a libmotif3 package. This is independent
>> of our final choice of multi-arch for each package.
> 
> I disagree, what about new installations?  Surely somebody who types
> 'sudo apt-get install libxm4' will have end up with all the requirements
> to install packages that depend on libmotif3 and libmotif4?

No. If he/she absolutely needs libmrm4 or libuil4 to run his/her foo-bin
package, he should get it no matter what. So libmotif3/libmotif4 should
absolutely pull that in or fail. Therefore, a virtual libmotif4 package
that provides libmotif3. I propose we remove the sentence "...can safely
be removed..." This problem will go away soon, as packages will depend
on the proper library directly in the future.

> One sure way to solve this is to make libxm4 depend on libmrm4 and
> libuil4, but I don't like circular dependencies.

No, me neither.

Paul



signature.asc
Description: OpenPGP digital signature

Re: [SCM] Motif widgetset library branch, master, updated. dbe3bee6ec58bdaa141c94c66e85205408dc7d42

[Paul Gevers]

On 17-02-13 21:54, Graham Inggs wrote:
> I finally see what you were hinting at. The missing piece was above. But
> indeed, because you can not guarantee that all three will be installed
> if somebody installs a package that requires libmotif3/libmotif4, I
> don't think this is the right solution. Providing a virtual package
> (lets not call it transitional then) is I think better.
> 
> 
> I am open suggestions.  But (on Ubuntu at least) if you install a
> package, all recommended packages are pulled in as well.

In Debian as well, by default. But people are allowed to override this
behavior, also on Ubuntu. The policy [1] is clear however:

Recommends
This declares a strong, but not absolute, dependency.
The Recommends field should list packages that would be found
together with this one in all but unusual installations.

So, if you want to be sure that a package that DEPENDS on libmotif3/4
has its dependency fulfilled, we need a package that provides ALL
dependencies, i.e. an (empty) libmotif4/3 package.

> I want compatibility with commercial packages that need libXm.so.3.
> Seeing that we provide these symlinks, we may as well advertise that we
> provide libmotif3 compatibility.

I thought so. Sure, no problem.

> No. If he/she absolutely needs libmrm4 or libuil4 to run his/her foo-bin
> package, he should get it no matter what. So libmotif3/libmotif4 should
> absolutely pull that in or fail. Therefore, a virtual libmotif4 package
> that provides libmotif3. I propose we remove the sentence "...can safely
> be removed..." This problem will go away soon, as packages will depend
> on the proper library directly in the future.
> 
> As above, when installing a package, all recommended packages are pull
> in as well.

In most cases, but not guaranteed, also not on Ubuntu.

Paul

[1]
http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps



signature.asc
Description: OpenPGP digital signature

Re: [SCM] Motif widgetset library branch, master, updated. dbe3bee6ec58bdaa141c94c66e85205408dc7d42

[Paul Gevers]

On 18-02-13 07:47, Graham Inggs wrote:
> I propose that the 'Provides: libmotif3, libmotif4' line be removed from
> d/control altogether:

This sounds good. Will upload tonight.

Paul



signature.asc
Description: OpenPGP digital signature

Motif 2.3.4-1 uploaded to Debian

[Paul Gevers]

On 18-02-13 08:23, Paul Gevers wrote:
> On 18-02-13 07:47, Graham Inggs wrote:
>> I propose that the 'Provides: libmotif3, libmotif4' line be removed from
>> d/control altogether:
> 
> This sounds good. Will upload tonight.

The package is waiting in NEW for approval:
http://ftp-master.debian.org/new.html

Paul



signature.asc
Description: OpenPGP digital signature

Re: First motif commits

[Paul Gevers]

On 24-02-13 07:43, Graham Inggs wrote:
> Recent changes (19 February)
> 
> Hi, I just wanted to clear up a few things regarding the recent changes
> I committed.

Good. I probably would have asked about 2 specifically.

 1. FTBFS on Ubuntu Raring:
> I'd like to rename (sorry) the patch and come up with a better
> description once I fully understand what changed in Raring.

Good.

> I think the following page holds the answer:
> http://wiki.debian.org/ToolChain/DSOLinking

I already had a look at that page when I was creating the symbols.
Indeed a lot of good info there.

> 2. Build Motif with JPG and PNG support:
> After being able to build motif on Raring, I noticed there were
> additional symbols.  I found that my test machine had libjpeg8-dev and
> libpng12-dev installed and this caused motif to build with additional
> support for these image types.  I believe we should build motif with JPG
> and PNG support, and found that motif is built this way in Red Hat [2].

Do you know what this additional support means? In principle I don't
object, but I like to understand.

> I have not made any changes yet to the symbols files.

Please do.

> 3. Fix buffer overrun in lib/Xm/FontS.c:
> I was looking at the upstream git [1] and found the only change since
> the 2.3.4 release was this buffer overrun fix committed on 31 October
> 2012.  I figured we should include it.

How did you see with what code they released 2.3.4? I could not (easily)
deduce this from upstream GIT repository.

> If you agree on the above changes, I will write up a changelog
> describing them.

Yes, please.

Additionally, I was wondering if you/we find it worth while to ask the
current maintainer of upstream what he things of co-maintainers? I
expect there are still quite some upstream bugs which are worth fixing,
although they are not reported against Debian.

Paul




signature.asc
Description: OpenPGP digital signature

Re: First motif commits

[Paul Gevers]

On 25-02-13 09:38, Graham Inggs wrote:
> It seems other distributions, e.g. Fedora are also switching to DSO
> linking [2].
> It's probably worth combining my patch along with Ubuntu's
> 0003_fix_ftbfs_binutils-gold.patch [3] and pushing it upstream.

Sounds good.

>> Additionally, I was wondering if you/we find it worth while to ask the
>> current maintainer of upstream what he things of co-maintainers? I
>> expect there are still quite some upstream bugs which are worth
>> fixing, although they are not reported against Debian.
> 
> No harm in asking.  I am a bit concerned that there hasn't been any
> upstream activity for a couple of months now.

I am not surprised. As I believe this is a company effort, I think
somebody got time to work on release a 2.3.4 version with the new
licensing. After that of course he got a new assignment. That is exactly
why I think it might be interesting to have community support as well.

> What do you think of providing a motif-sdk-examples package?
> I was thinking we could provide a compressed archive of the source code
> in /usr/share/doc/ or somewhere that users could extract to their home
> directories and then build the examples there.  I did have a brief look
> for similar packages in Debian, but didn't find any.  Maybe this is just
> redundant, as the examples are already available in the source package.

Indeed. I think the examples in the source package are good for now as
any user can install a source package (not just root). Maybe mentioning
something along those lines in a README file somewhere in one of our
packages does not hurt though. I.e. that example code is available.

Paul



signature.asc
Description: OpenPGP digital signature

Re: [SCM] Motif widgetset library branch, master, updated. debian/2.3.4-1-12-g64986ea

[Paul Gevers]

On 08-03-13 18:47, Graham Inggs wrote:
> Clean debian/system.mwmrc-menu after installing

Graham,

I prefer to do this by adding that file to a file called debian/clean.
That way you don't have to override dh_clean.

Paul



signature.asc
Description: OpenPGP digital signature

Re: [SCM] Motif widgetset library branch, master, updated. debian/2.3.4-1-10-g5f4f0e2

[Paul Gevers]

On 08-03-13 12:48, Graham Inggs wrote:
> +++ b/debian/mwm.install
> -/etc/X11/mwm/system.mwmrc-menu
> +debian/system.mwmrc-menu /etc/X11/mwm

> +++ b/debian/rules
> - cp -a clients/mwm/system.mwmrc debian/tmp/etc/X11/mwm/system.mwmrc-menu
> + cp clients/mwm/system.mwmrc debian/system.mwmrc-menu

Hi Graham,

Can you please elaborate why you find this nicer? You didn't need the
clean up before, and now you do. So, why?

Paul



signature.asc
Description: OpenPGP digital signature

Re: [SCM] Motif widgetset library branch, master, updated. debian/2.3.4-1-10-g5f4f0e2

[Paul Gevers]

On 08-03-13 12:48, Graham Inggs wrote:
> Include custom Unity Greeter badge for MWM
> diff --git a/debian/custom_mwm_badge.png b/debian/custom_mwm_badge.png
> new file mode 100644
> index 000..cfc1703
> Binary files /dev/null and b/debian/custom_mwm_badge.png differ

Where did you get this file? What is the copyright? Is this file created
as png or is it actually created in a program and does that program
store the file in a different format so that you can edit it? In the
later case, we also need that source and preferable build the png from
that source.

Paul



signature.asc
Description: OpenPGP digital signature

Re: First motif commits

[Paul Gevers]

On 03/13/13 09:46, Graham Inggs wrote:
> I've cleaned up some things, added copyright info for
> custom_mwm_badge.png and updated the changelog.

Good. Are you sure you own the complete copyright of that file? I.e.
didn't somebody else have the original copyright?

> Maybe ac_find_xft.m4 should be totally reworked, and we should probably
> consult upstream before doing that.

Sure, although by now I think you nearly know as much about the motif
code as the current upstream maintainer. I think he was just paid for a
while to work on it.

> Is there any harm in leaving the build-depends on libfreetype6-dev and
> libxrender-dev in place for now?

I saw you dropped them in the mean time. Fine. However, from your story
I understand that motif needs to link to libxft. If you want to be sure
it is linked, please DON'T assume it is pulled in via your depends, but
explicitely depend on it. In general, a depends of your package may
cease to depend on the library (maybe it is optional, or a replacement
is found) and you get strange FTBFS or worse in a case like this, your
package builds different than you intend.

> We could create a motif-demos package and copy the demos directory to
> /usr/share/doc/motif-demos, similar to what is done in gtk2.0-examples
> and gtk-3-examples.
> What do you think?

Sounds ok, but I thought originally you created your patch to save on
build time. Do you now think it is worth it to distribute the demos? Oh,
wait, you only mean the source code here. Than I think I like the
"examples" better as name then demos, but I let it up to you.

Paul



signature.asc
Description: OpenPGP digital signature

Re: First motif commits

[Paul Gevers]

On 03/14/13 07:29, Graham Inggs wrote:
> After asking that question I tried to do more reading up symbols, but
> I found the information very vague, especially about (optional)
> symbols. Out of interest, why are there so many other (optional)
> symbols?  How did you determine they were optional?

There are several *.elist files in the package. All symbols that are
exported, but are marked private in those lists, I marked as optional.
They should not have be in the symbols file, but unfortunately they are
exported anyways. By the way, these elist files seem not to be
up-to-date, although the header clearly says it is absolutely necessary :(.

> I guess Canonical might have the copyright on the white circle
> image, I'll check in the sources of unity-greeter.

Ok.

> I'm not sure about the four squares, I based that on the look of the
> icon for Xterm that is displayed in MWM [1].

If you draw them yourselves, than it is all right. No need to look
further for that.

> Shall I email upstream now and see if they are interested in support 
> from the community?

Good idea.

Paul



signature.asc
Description: OpenPGP digital signature

Re: [SCM] Motif widgetset library branch, master, updated. debian/2.3.4-1-31-g912bcbf

[Paul Gevers]

Hi Graham,

On 17-03-13 09:16, Graham Inggs wrote:
> The following commit has been merged in the master branch:
> commit 0450ba5184ed53ecf6330e0accdd727509a75d48
> +Comment: Created in GIMP using /usr/share/unity-greeter/unknown_badge.png,
> + from Ubuntu's unity-greeter package (copyright 2012 Canonical Ltd and
> + released under GPL-3), as a template. As per:
>   https://lists.ubuntu.com/archives/ubuntu-devel/2012-February/034800.html

If this is true, we do have an (small) issue. You can not just relicense
this file without permission of the copyright owner. So, you have no
choice other than state the license of this file as GPL-3 or ask
Canonical to relicense.

I don't think it is a problem to have the icon licensed under GPL-3,
although most of motif is less strict licensed under LGPL, etc, as it is
not part of the binary (library) so packages linking to it don't have
any problem.

By the way, you really should add Canonical to the copyright holders
list as well.

Paul



signature.asc
Description: OpenPGP digital signature

Re: [SCM] Motif widgetset library branch, master, updated. debian/2.3.4-1-31-g912bcbf

[Paul Gevers]

Hi Graham,

Maybe I was unclear. See what I mean below.

On 17-03-13 10:54, Graham Inggs wrote:
> I understood that this was OK since the new license was 2+.
> Or is the problem more about changing from GPL to LGPL?

The latter.

> By the way, you really should add Canonical to the copyright holders
> list as well.
> Which list is that

The one in d/copyright. Please see below. (Don't forget to add the GPL3
required text to the file.) (And are you sure it is not GPL3 or later?)

Files: debian/custom_mwm_badge.png
Copyright: 2012 Canonical Ltd
 2013 Graham Inggs 
License: GPL-3
Comment: Created in GIMP using /usr/share/unity-greeter/unknown_badge.png,
 from Ubuntu's unity-greeter package, as a template. As per:
 https://lists.ubuntu.com/archives/ubuntu-devel/2012-February/034800.html

Paul



signature.asc
Description: OpenPGP digital signature

Re: First motif commits

[Paul Gevers]

[Seems like the mail servers of Debian were out yesterday, sending again]

Hi Graham,

I have some questions in return.

On 24-03-13 08:40, Graham Inggs wrote:
> You wrote that you wouldn't upload 2.3.4-2 until 2.3.4-1 had been reviewed.
> Is it possible to re-upload our current effort as 2.3.4-1 (with the
> appropriate changes to the changelog and libxm4.symbols)?
> It may then be possible to get Ubuntu to sync motif from Debian's NEW
> queue and still make it into Raring (final beta freeze is March 28 [1]).

Are you sure? I believe the NEW queue is ONLY accessible to the
ftp-masters, as uploads might contain non-distributable material, and
the task of the ftp-masters is exactly to prevent that entering Debian.

So if that is possible, you are talking to an ftp-master, right? Then we
could just make an Ubuntu version of the package instead.

Furthermore, the feature freeze has already past for a long time, so
usually Ubuntu does not allow such large changes. Who are you
communicating with about this effort, please include me in the
communication.

Last point, I think if we would do this, I would just upload a -2
version. But I think it would put us back on the agenda. What I think is
that the ftp-masters are reluctant to look at it, but as it gets closer
to the old side of the list, it will get attention.

> Is there anything that needs to be done in wnpp bug #695130 [2]?

No. All information (I think) is in the bug report and it will be
automatically closed by our upload (my first entry in the changelog for
2.3.4-1).

Paul

> [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695130





signature.asc
Description: OpenPGP digital signature

Fwd: Re: First commits in git repository on Alioth [ Was: Re: openmotif is now LGPL, retirement of lesstif in jessie?]

[Paul Gevers]

[Mail servers were out yesterday, forwarding to the list]

 Original Message 
Subject: Re: First commits in git repository on Alioth [ Was: Re:
openmotif is now LGPL, retirement of lesstif in jessie?]
Date: Sun, 24 Mar 2013 08:38:17 +0100
From: Paul Gevers 
To: BERTRAND Joël 
CC: openmo...@packages.debian.org

Hi Joël,

Thanks for your (late) response.

On 23-03-13 23:13, BERTRAND Joël wrote:
> Sorry for the delay. I just discover your mail on my spam box. I can
> help you to offer a openmotif package. How can I start ?

We are working hard to get (open)motif in full shape. Our work [6] is on
Alioth. If you want to contribute, please follow my proposal as
described in my e-mail to you on 27 Dec 2012 (see below), skipping the
first item (I now own that bug).

A new motif package is already waiting in the NEW queue [7] for a month.

Paul

[6] http://anonscm.debian.org/gitweb/?p=collab-maint/motif.git
[7] http://ftp-master.debian.org/new/motif_2.3.4-1.html

On 27-12-12 17:37, Paul Gevers wrote:
> Hi Graham and Joël,
>
> I moved this discussion off-list from devel, and hope you don't object.
>
> On 26-12-12 01:06, Graham Inggs wrote:
>> I would be happy to join a team effort.
>
> Joël, as you can see, you have now two co-maintainers if you want. If
> you don't object, my proposal is the following:
>
> - Joël: you own and retitle bug 695130 appropriately.
> - I assume you both don't have upload rights, so I will have to do that
>   part, during the Wheezy freeze, we only target experimental.
> - I create a git repository on Alioth [1]. I hope you like git, but if
>   not we can agree on an other VCS.
> - I can import as much of the history of openmotif as I can find [2].
> - You both make to register on alioth [3] and become member of the
>   collab-maint project [4]. Please let me know your alioth registration
>   name, so I can send the mail as described on [1].
> - We should agree on the name of the source package. Graham prefers
>   motif i.s.o. openmotif :)
> - Please make sure you both are subscribed to the PTS [5] for the
>   package openmotif for the moment, and possibly to motif after upload.
>
> Joël, to not let the enthusiasm of Graham die, I propose that we wait
> for a week for your response, and in case of no response, I will start
> with the proposal above, but will wait with uploading a new package.
>
> Paul
>
> [1] http://wiki.debian.org/Alioth/PackagingProject
> [2] http://snapshot.debian.org/package/openmotif/
> [3] https://alioth.debian.org/account/register.php
> [4] https://alioth.debian.org/projects/collab-maint/
> [5] http://packages.qa.debian.org/o/openmotif.html (left bottom)
>







signature.asc
Description: OpenPGP digital signature

Fwd: Motif

[Paul Gevers]

Hi all,

I am sorry to read it, but it seems we won't have motif in experimental
before the release of Wheezy. If we want to get the package in Ubuntu
Raring, it needs to go on it's own. Graham, do you still want to do that?

Paul

 Original Message 
Subject: Motif
Date: Sat, 6 Apr 2013 00:59:59 +0200
From: Luca Falavigna 
To: Paul Gevers 

Hi!

I saw on the IRC logs you pinged me, but unfortunately I wasn't
online, so I'm writing you by mail :)

There's a nasty bug in dak, which prevents accepting a package if
components are already available in a different section, as happened
with motif, which shares libmotif-dev and libmotif4 with openmotif
package.

The workaround for this bug would require removing openmotif from
unstable, and immediately upload motiv. This is not advisable right
now because that would also trigger an automatic removal from Wheezy
for openmotif because it has no reverse (build-)dependencies.

The best solution at this point would be the following, IMO:
1) Upload motif in Ubuntu (with 0ubuntu1 as revision)
2) Have the override entries for motif deleted
3) Reupload motif in NEW
4) Wait for Wheezy to be released (very soon!)
5) Remove openmotif and immediately accept motif

I'll take care of 2) myself, and I'm going to inform you about the
time you can reupload motif again.

Cheers,
Luca




signature.asc
Description: OpenPGP digital signature

Re: Motif

[Paul Gevers]

Hi,

On 06-04-13 14:30, Graham Inggs wrote:
> I think it is very late now to try and get motif into Raring with it not
> being in Debian.

Get it, and thought so.

> Paul: when you re-upload motif in NEW, will you go straight to 2.3.4-2,
> or upload 2.3.4-1 again?
> (or just to mix things up, upload 2.3.4-2 as 2.3.4-1 since 2.3.4-1 was
> never released?).

I consider 2.3.4-1 released in the sense that it is tagged as such in
our git repository. So I think I go for 2.3.4-2, but of course that
might still depend on the state of 2.3.4-2 at that time. (I think it is
nice and shiny now).

Paul



signature.asc
Description: OpenPGP digital signature

Re: Motif

[Paul Gevers]

Hi Luca,

On 06-04-13 00:59, Luca Falavigna wrote:
> There's a nasty bug in dak, which prevents accepting a package if
> components are already available in a different section, as happened
> with motif, which shares libmotif-dev and libmotif4 with openmotif
> package.
> 
> The workaround for this bug would require removing openmotif from
> unstable, and immediately upload motiv. This is not advisable right
> now because that would also trigger an automatic removal from Wheezy
> for openmotif because it has no reverse (build-)dependencies.
> 
> The best solution at this point would be the following, IMO:
> 1) Upload motif in Ubuntu (with 0ubuntu1 as revision)
> 2) Have the override entries for motif deleted
> 3) Reupload motif in NEW
> 4) Wait for Wheezy to be released (very soon!)
> 5) Remove openmotif and immediately accept motif
> 
> I'll take care of 2) myself, and I'm going to inform you about the
> time you can reupload motif again.

As the release of wheezy has happened this weekend. Is it now a good
time to follow up on the actions above?

We are eager to work on the transition of all the lesstif2 depending
packages to motif, so that we can release Jessie without lesstif2 (which
I will try to make a release goal).

Paul



signature.asc
Description: OpenPGP digital signature

lesstif2 to motif transition

[Paul Gevers]

Hi release team,

I like to get your opinion and advise on the following.

Motif has been released with a free license last year, and I would like
to move it from non-free (called openmotif) to Debian main. Its former
free replacement lesstif2 is unsupported upstream and should be retired
(in Debian), as its goal has been reached: a free motif.

Openmotif (which we want to rename to motif) is currently in non-free
and due to a bug in dak it needs to be removed from unstable to let it
into main, which makes it less suitable to test this in experimental (as
it would leave unstable without (open-)motif).

Motif and lesstif2 build the same libraries, albeit with different
sonames, so the libraries can coexist. The -dev packages and auxiliary
packages cannot coexist as file names are shared (lesstif2 was meant as
drop in (binary compatible) replacement). According to policy (2.5) no
two packages may be in the section optional or higher if they conflict,
and packages can not depend on a package of a lower priority. So
strictly speaking motif could not take over unless we can ignore this
rule of policy during the transition.

We have not started talking to the maintainers of packages depending on
lesstif2 (other than a message to d-devel [1]), as I wanted to have the
way clear before that. Graham Inggs has tested building all the reverse
dependencies [2], though.

So my question basically is, what would be the most appropriate order to
do things?

My proposal would be (with your approval) to just get motif into
unstable/main and start converting the dependencies with the help of
their maintainers (the libraries can coexist). Because the -dev package
name has to change all build dependencies would have to get a
source-full update. I would have liked to stage everything in
experimental, but due to this (quoted from ftp-master) nasty dak bug,
that would leave unstable (non-free) without (open-)motif.

Paul

[1] https://lists.debian.org/debian-devel/2012/12/msg00369.html
[2] https://launchpad.net/~ginggs/+archive/motif




signature.asc
Description: OpenPGP digital signature

Re: lesstif2 to motif transition

[Paul Gevers]

Hi Graham,

On 06-05-13 23:01, Paul Gevers wrote:
> My proposal would be (with your approval) to just get motif into
> unstable/main and start converting the dependencies with the help of
> their maintainers (the libraries can coexist). Because the -dev package
> name has to change all build dependencies would have to get a
> source-full update. I would have liked to stage everything in
> experimental, but due to this (quoted from ftp-master) nasty dak bug,
> that would leave unstable (non-free) without (open-)motif.

I was thinking, how well did it go with your building of all reverse
dependencies, and how well would it work if lesstif2-dev would be a
transitional package that depends on libmotif-dev? If that would work at
all, I think that is a good alternative to my proposal above.

Paul



signature.asc
Description: OpenPGP digital signature

Re: lesstif2 to motif transition

[Paul Gevers]

On 07-05-13 07:55, Graham Inggs wrote:
> I think the testing went very well.  As we suspected, most packages only
> required changing the build-depends on lesstif2-dev to libmotif-dev. 
> There were a few that required the addition of libxt-dev and one or two
> that required libxext-dev and libxp-dev (although we should try to
> remove that dependency).

Can you please document that, I mean which ones? It would be great if
you would reply to the e-mail I sent yesterday to the release team with
full details, so that the team knows when they make a decision. And I
think (unsure now) that these missing dependencies are actual bugs in
those packages, so they should get filed and fixed anyway.

> Cernlib depends on libpacklib-lesstif1-dev and libpawlib-lesstif3-dev
> from paw and pcb depends on its own pcb-lesstif, these packages should
> probably be renamed.

I would leave renaming to the maintainers of those packages. We can let
them know but this is not a necessary action. Did you actually try to
RUN any of the compiled packages?

> Do -dev packages normally get transitional packages?  I can't think of a
> situation where that would be useful.

Normally not I guess, but the situation here is strange. Usually you
don't move from one package to the next as a drop in replacement.
Usually, you would need work as well due to different api and stuff.

> Ideally we need all of the packages that depend on lesstif2 to be
> rebuilt against libmotif.

Sure, but we are talking about a transition plan where the state of the
archive remains as stable as obtainable. If needed breakage is allowed,
but only when we can not come up with a solution were this don't happen.
And I was hoping that lesstif2-dev being empty and depending on libmotif
would achieve this.

> When a user upgrades they will then get
> libmotif which conflicts with lesstif2 and it will be removed.
> If a user was developing with lesstif2-dev it would be removed due to
> the conflict above, but they would not have been able to continue
> building against libmotif-dev without making changes anyway.

Why not? Aren't the headers the same? If not, how can WE replace
lesstif2 with libmotif? Anyway, the users that build are not the only
ones we need to care about. Also the current packages between libmotif
upload and full rebuild need a proper archive. We should plan this properly.

Paul



signature.asc
Description: OpenPGP digital signature

Re: lesstif2 to motif transition

[Paul Gevers]

Hi RT,

On 06-05-13 23:01, Paul Gevers wrote:
> So my question basically is, what would be the most appropriate order to
> do things?
> 
> My proposal would be (with your approval) to just get motif into
> unstable/main and start converting the dependencies with the help of
> their maintainers (the libraries can coexist). Because the -dev package
> name has to change all build dependencies would have to get a
> source-full update. I would have liked to stage everything in
> experimental, but due to this (quoted from ftp-master) nasty dak bug,
> that would leave unstable (non-free) without (open-)motif.

Having thought about this again today, how about the following proposal:

- Upload the latest packaging of motif to non-free to get the new
  packaging and rename of the source past the NEW queue.
- Ask and help the current maintainers of reverse dependencies to try
  out building their packages in experimental with libmotif-dev in
  non-free. Yes, the policy does not allow this, but as ftp-master
  agrees that we move the package to main, I expect this could be
  acceptable, if at all possible.
- When all packages are lined up, remove motif from non-free into main
  and start the transition in unstable.

Do you think this works and do you find this acceptable?

An alternative that I could come up with, but maybe it is an insane
idea, is that I update the lesstif2 package to make the lesstif2-dev
package a transitional package that depends on libmotif-dev. I believe
only the packages that need the additional build dependencies (e-mail
from Graham) would not be helped by this temporary solution, but that
can be fixed in advance. So than we could upload motif and lesstif2 to
unstable after your approval and start converting the packages to
properly build-depend on libmotif-dev.

Do you prefer that I file a proper transition bug for this issue now?
Please advice on what you find acceptable.

I propose that we start to inform the reverse dependent package
maintainers about our intent to replace lesstif2 with motif when we have
agreed on the proposed attack path from your point of view.

Paul



signature.asc
Description: OpenPGP digital signature

proposal for the reverse depending buggy packages [Was: Re: lesstif2 to motif transition]

[Paul Gevers]

Hi Graham,

Before we file bugs again the packages below I like to discuss the
phrasing. Do you agree with the following?

"""
Hi Maintainer,

Your package build depends on libxt-dev/XXX but does not declare this
relation in the debian/control file. This is currently no problem as
this is pulled in by the lesstif2-dev package that you do depend on.

In the near future we like to replace lesstif2 in Debian with the
relicensed (open-)motif package. Lesstif2 was originally created as an
free alternative for motif, but in the mean time became unmaintained and
buggy. Motif itself is now free and got its latest maintenance release
last year.

To ease the transition that will happen some time soon, we will follow
up on this, please explicitly build-depend on libxt-dev/XXX

Kind regards,
Paul & Graham.
"""

On 07-05-13 21:01, Graham Inggs wrote:
> The following packages required an additional build-depends on libxt-dev:
> 
> ferret-vis
> mesa-glw
> sqsh
> tcm
> xabacus
> xpdf
> xsol
> 
> The following packages required additional build-depends as indicated below:
> 
> gridengine - libxft-dev, libxp-dev
> hotswap - libxtdev, libxext-dev, libxp-dev
> mgdiff - libxt-dev, libxext-dev
> xawtv - libxp-dev
> xtel - libxpd-dev



signature.asc
Description: OpenPGP digital signature

Re: proposal for the reverse depending buggy packages [Was: Re: lesstif2 to motif transition]

[Paul Gevers]

Ok, I think I will file the bugs, hopefully tomorrow morning. Else it
might jump over the weekend.

I'd like to use proper usertags (just in case you want to do it).

Paul

On 07-05-13 22:08, Graham Inggs wrote:
> I agree with the message.  I can suggest some minor grammatical changes
> though.
> 
> On 7 May 2013 21:56, Paul Gevers  <mailto:elb...@debian.org>> wrote:
>  
> 
> This is currently no problem as
> this is pulled in by the lesstif2-dev package that you do depend on.
> 
> 
> I would say "This is current not a problem as"
>  
> 
> Lesstif2 was originally created as an
> free alternative for motif, but in the mean time became unmaintained and
> 
> 
> meantime - one word
>  
> 
> To ease the transition that will happen some time soon, we will follow
> 
> 
> sometime - one word
>  
> ...and then some of my own typos:
> 
> > hotswap - libxtdev, libxext-dev, libxp-dev
> 
> 
> hotswap - libxt-dev, libxext-dev, libxp-dev
>  
> 
> > xtel - libxpd-dev
> 
> 
> xtel - libxp-dev
> 




signature.asc
Description: OpenPGP digital signature

Bug#707211: [ferret-vis] please build-depend on libxt-dev

[Paul Gevers]

Source: ferret-vis
User: openmo...@packages.debian.org
Usertags: lesstif2motif
Version: 6.6.2-1.1
Severity: normal
X-Debbugs-CC: openmo...@packages.debian.org

Hi Maintainer,

Your package build depends on libxt-dev but does not declare this
relation in the debian/control file. This is currently not a problem as
this is pulled in by the lesstif2-dev package that you do depend on.

In the near future we like to replace lesstif2 in Debian with the
relicensed (open-)motif package. Lesstif2 was originally created as an
free alternative for motif, but in the meantime became unmaintained and
buggy. Motif itself is now free and got its latest maintenance release
last year.

To ease the transition that will happen sometime soon, we will follow
up on this, please explicitly build-depend on libxt-dev, as we don't
intend to include the depends on libxt-dev in libmotif-dev.

Kind regards,
Paul & Graham.



-- System Information:
Debian Release: 7.0
  APT prefers stable
  APT policy: (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash





signature.asc
Description: OpenPGP digital signature

Seems like the bug was not forwarded, oh well

[Paul Gevers]

Seems like the bug was not forwarded, oh well

The first example:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707211

I go now.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#707621: [hotswap] please build-depend on libxt-dev, libxext-dev, libxp-dev

[Paul Gevers]

Source: hotswap
User: openmo...@packages.debian.org
Usertags: lesstif2motif
Version: 0.4.0-12
Severity: normal
X-Debbugs-CC: openmo...@packages.debian.org

Hi Maintainer,

Your package build depends on libxt-dev, libxext-dev and libxp-dev but
does not declare this relation in the debian/control file. This is
currently not a problem as this is pulled in by the lesstif2-dev package
that you do depend on.

In the near future we like to replace lesstif2 in Debian with the
relicensed (open-)motif package. Lesstif2 was originally created as an
free alternative for motif, but in the meantime became unmaintained and
buggy. Motif itself is now free and got its latest maintenance release
last year.

To ease the transition that will happen sometime soon, we will follow
up on this, please explicitly build-depend on libxt-dev, libxext-dev,
and libxp-dev, as we don't intend to include these depends in libmotif-dev.

Kind regards,
Paul & Graham.



-- System Information:
Debian Release: 7.0
  APT prefers stable
  APT policy: (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash







signature.asc
Description: OpenPGP digital signature

Bug#707623: [xtel] please build-depend on libxp-dev

[Paul Gevers]

Source: xtel
User: openmo...@packages.debian.org
Usertags: lesstif2motif
Version: 3.3.0-14
Severity: normal
X-Debbugs-CC: openmo...@packages.debian.org

Hi Maintainer,

Your package build depends on libxp-dev but does not declare this
relation in the debian/control file. This is currently not a problem as
this is pulled in by the lesstif2-dev package that you do depend on.

In the near future we like to replace lesstif2 in Debian with the
relicensed (open-)motif package. Lesstif2 was originally created as an
free alternative for motif, but in the meantime became unmaintained and
buggy. Motif itself is now free and got its latest maintenance release
last year.

To ease the transition that will happen sometime soon, we will follow
up on this, please explicitly build-depend on libxp-dev, as we don't
intend to include these depends in libmotif-dev.

Kind regards,
Paul & Graham.

P.s. Debian is trying to get rid of libxp, but as long as your package
needs it, please declare explicitly.


-- System Information:
Debian Release: 7.0
  APT prefers stable
  APT policy: (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash









signature.asc
Description: OpenPGP digital signature

Bug#708462: lesstif2 to motif transition

[Paul Gevers]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-CC: openmo...@packages.debian.org

Hi RT,

I assume you prefer to receive this discussion in a transition bug,
therefore submitting it now. For reference, this is a follow-up on
https://lists.debian.org/debian-release/2013/05/msg00161.html
or 51881a33.6030...@debian.org

I like to request a transition slot for lesstif2 to (open)motif.

To keep current unstable build-able and installable, I propose the
follow transition path:
On 07-05-13 21:32, Paul Gevers wrote:
> An alternative that I could come up with, but maybe it is an insane
> idea, is that I update the lesstif2 package to make the lesstif2-dev
> package a transitional package that depends on libmotif-dev. I believe
> only the packages that need the additional build dependencies (e-mail
> from Graham) would not be helped by this temporary solution, but that
> can be fixed in advance. So than we could upload motif and lesstif2 to
> unstable after your approval and start converting the packages to
> properly build-depend on libmotif-dev.

I don't think Graham's e-mail ended up on the d-r@l.d.o e-mail list, so
I attach it to this mail.

We have started to file bugs on the packages that build depend on
lesstif2-dev but fail to declare all their other dependencies properly:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=lesstif2motif;users=openmo...@packages.debian.org

Unfortunately (due to a nasty bug in dak) openmotif needs to be removed
from non-free/unstable if we are going to move it to main, so if we want
to test the transition in experimental, we won't have a version in
unstable. Openmotif has two reverse dependencies in non-free: arb and
cluster3.

Paul

ben file:
title = "motif";
is_affected = .depends ~ "lesstif2-dev" | .depends ~ "libmotif-dev";
is_good = .depends ~ "libxm4" | .depends ~ "libmrm4" | .depends ~ "libuil4";
is_bad = .depends ~ "lesstif2";
--- Begin Message ---
Hi Release Team

Results of test rebuilds on motif's reverse dependencies.

The following packages built with only changing the build-depends on
lesstif2-dev to libmotif-dev:

alliance
ctn
ddd
dx
elk
freesci
geomview
grace
grass
gromacs
inventor
mtink
ncbi-tools6
nedit
njplot
plan
sciplot
twclock
twpsk
via
viewmol
whitedune
xastir
xbae
xball
xmakemol
xmhtml
xmpi
xpuzzles
xshisen

The following packages required an additional build-depends on libxt-dev:

ferret-vis
mesa-glw
sqsh
tcm
xabacus
xpdf
xsol

The following packages required additional build-depends as indicated below:

gridengine - libxft-dev, libxp-dev
hotswap - libxtdev, libxext-dev, libxp-dev
mgdiff - libxt-dev, libxext-dev
xawtv - libxp-dev
xtel - libxpd-dev

I did try running all of the applications, but not being familiar with all
of them, some I just ran to see that a GUI appeared without any error
messages.

I don't believe that any of the packages actually make use of libxp and
therefore the dependencies on libxp-dev can be removed without too much
effort.  This is good as we want to get rid of libxp anyway [1].

I did not test rebuilding pcb, cernlib and paw.  These packages build
and/or depend on packages with names like pcb-lesstif, libpack-lesstif1-dev
and libpawlib-lesstif3-dev. These should be left up to the maintainers of
these packages to decide what to do with them.

Regards
Graham

[1] http://bugs.debian.org/623643
--- End Message ---


signature.asc
Description: OpenPGP digital signature

Re: Motif

[Paul Gevers]

Hi Luca

On 06-05-13 00:22, Luca Falavigna wrote:
> 2013/5/5 Paul Gevers :
>> As the release of wheezy has happened this weekend. Is it now a good
>> time to follow up on the actions above?
> 
> It should, yes.
> Feel free to upload motif to unstable, then I'll take care of removing
> openmotif from the archive just before processing motif from NEW.

While we are waiting for the release team to respond to my questions
about the transition from lesstif2 to motif [1], I am considering to
have the motif package updated in non-free first. That way we already
have the name change and additional packages done, albeit in non-free.
We can migrate the package to main when the real transition can start.
This way, packages that build-depend on libmotif-dev can start trying
out with the updated package from non-free, while we can not provide the
updated package now.

What do you think? Does this work for you, or does it just mean a lot
more manual action?

I considered having the new package in experimental first, but I
remember you saying that the old package needs to be removed from
unstable/non-free and we do have two build depends there.

Paul

[1] http://bugs.debian.org/708462



signature.asc
Description: OpenPGP digital signature

Re: Motif

[Paul Gevers]

Hi Luca,

[What would be the appropriate mail-list or bug-tracker for this
discussion to happen in the open? Should I add it to the transition bug?]

On 20-05-13 09:03, Luca Falavigna wrote:
> 2013/5/18 Paul Gevers :
>> While we are waiting for the release team to respond to my questions
>> about the transition from lesstif2 to motif [1], I am considering to
>> have the motif package updated in non-free first.
> 
> I don't think that would work because autobuilders don't usually pick
> packages from experimental.

I don't understand exactly what you mean here. Do you mean "don't
usually pick packages from non-free"? Ideally we would have the new
package in experimental/main so the build-dependencies could also check
that their packages work as expected in experimental (they build, see
below).

> On the other hand, having it available
> would help maintainers starting to consider potential build failures.

The latter is partially what I meant, we already checked simple build
failure.

> I'd prefer to wait for the final say from the Release Team about this
> matter. That would probably require a preliminar test by your side,
> checking how many packages would fail to build with motif.

As mentioned [1] in the transition bug [2], we have done the tests
already [3], albeit in an Ubuntu PPA. We have already notified [4] all
build dependencies that need some minor adjustments (adding explicit
build dependencies) of the fact. So yes, there is some trivial
additional work to be done besides the change of build dependency on
lesstif2-dev -> libmotif-dev.

So far, I haven't heard a word from the RT, that is why I am also
seeking for other decent ways of getting some exposure. The transition
is a little strange, because of the move from non-free and the bug in
dak, which prevents uploading to experimental. Staging in experimental
would help, but maybe "staging" in non-free would also help.

My other option is that I create a down-loadable package myself for the
build-dependencies so they can properly test their package, but I
consider that sub-optimal.

Paul

[1] http://bugs.debian.org/708462
[2]
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=Attached+Message;att=1;bug=708462
[3] https://launchpad.net/~ginggs/+archive/motif
[4]
http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=lesstif2motif;users=openmo...@packages.debian.org



signature.asc
Description: OpenPGP digital signature

Re: Motif

[Paul Gevers]

On 20-05-13 11:55, Luca Falavigna wrote:
> I just checked, openmotif has only two rdeps, all of them in non-free,
> and just for i386 and amd64 architectures. I don't think removing
> openmotif from non-free and immediately accepting motif in main would
> cause a lot of trouble for those two packages, so the best action
> would be that way. Feel free to upload motif in main, I'll process it
> from NEW immediately after removing openmotif from the archive.
> 
> This way, you will have motif in main, and the lesstif2 -> motif
> transition can happen normally.

Ok. Then we just have to wait until the RT grants us a transition slot.
Will keep you updated.

Paul



signature.asc
Description: OpenPGP digital signature

Re: Motif

[Paul Gevers]

[Summary of previous mails: we are discussing how/when to move openmotif
to motif].

On 23-05-13 08:43, Luca Falavigna wrote:
> 2013/5/22 Paul Gevers :
>> Ok. Then we just have to wait until the RT grants us a transition slot.
>> Will keep you updated.
> 
> I don't think we need it for openmotif -> motif, as long as motif is
> ABI-compatible with openmotf.

I kindly disagree except if we do it in non-free (although I might be
wrong, but I like a statement from the RT on this).

RT: isn't the move for (open)motif from non-free to main starting the
transition of lesstif2 (libMrm.so.2.0.1 / libXm.so.2.0.1) to motif
(libMrm.so.4.0.3 / libXm.so.4.0.3) automatically from your point of view.

Paul



signature.asc
Description: OpenPGP digital signature

Re: Motif

[Paul Gevers]

Hi Luca,

On 23-05-13 08:43, Luca Falavigna wrote:
> 2013/5/22 Paul Gevers :
>> Ok. Then we just have to wait until the RT grants us a transition slot.
>> Will keep you updated.
> 
> I don't think we need it for openmotif -> motif, as long as motif is
> ABI-compatible with openmotf.

After the response from the RT, I just uploaded motif to the archive. I
expect it to appear in the NEW queue sometime soon. I hoop you can take
it from there?

Paul



signature.asc
Description: OpenPGP digital signature

Motif FTBFS on non-linux due to YYSTYPE

[Paul Gevers]

Hi Graham,

Congratulations...

Now that we have motif in Debian/main, I would like to fix the fact that
motif FTBFS on non-linux systems. That is needed if we want to replace
lesstif2 as that is now available on more Debian platforms than motif.

I think I know where it goes wrong (I have to check to be sure) but I
don't understand why the offending check is there. The problem (I think)
is in clients/uil/UilDefI.h on line 273 and was fixed for Mac OS X in
motif bug 1479:
#if defined(linux) || defined(__APPLE__)

Do you understand why the if would be there at all? I tend to just
remove it or add a defined(__GNU__), which I think will prevent the
issue. When motif has migrated to the mirrors, I will test if this is
really the issue on some porterboxes.

If we fixed the FTBFS, do you want to start filling wishlist bugs
against the reverse dependencies of lesstif2-dev? (I am working on nedit
already). Or do you want me to start them? If you do, please don't
forget to tag them with the lesstif2motif usertag.

Paul



signature.asc
Description: OpenPGP digital signature

Re: Motif FTBFS on non-linux due to YYSTYPE

[Paul Gevers]

Hmm,

Maybe I was too quick, although I don't understand why it works now, but
kfreebsd now builds with motif 2.3.4, where it didn't build with
openmotif 2.3.3.

https://buildd.debian.org/status/package.php?p=motif&suite=sid

Paul

On 25-05-13 17:47, Paul Gevers wrote:
> Hi Graham,
> 
> Congratulations...
> 
> Now that we have motif in Debian/main, I would like to fix the fact that
> motif FTBFS on non-linux systems. That is needed if we want to replace
> lesstif2 as that is now available on more Debian platforms than motif.
> 
> I think I know where it goes wrong (I have to check to be sure) but I
> don't understand why the offending check is there. The problem (I think)
> is in clients/uil/UilDefI.h on line 273 and was fixed for Mac OS X in
> motif bug 1479:
> #if defined(linux) || defined(__APPLE__)
> 
> Do you understand why the if would be there at all? I tend to just
> remove it or add a defined(__GNU__), which I think will prevent the
> issue. When motif has migrated to the mirrors, I will test if this is
> really the issue on some porterboxes.
> 
> If we fixed the FTBFS, do you want to start filling wishlist bugs
> against the reverse dependencies of lesstif2-dev? (I am working on nedit
> already). Or do you want me to start them? If you do, please don't
> forget to tag them with the lesstif2motif usertag.
> 
> Paul
> 




signature.asc
Description: OpenPGP digital signature

iswpace [was: Motif FTBFS on non-linux due to YYSTYPE]

[Paul Gevers]

Hi Graham,

[Side note: maybe we can stop using the @packages.debian.org address, I
don't think anybody else is listening.]

On 25-05-13 21:08, Graham Inggs wrote:
> Thanks for uploading!

Thank you for the nice cooperation so far, it has been a pleasure.

> I will file the bugs against the reverse dependencies of lesstif2-dev in
> Debian.

Good, but I think it is also good to wait until all architectures have
build successfully.

> I will also file one in Ubuntu to remove openmotif and replace with motif.

Good. (Same holds as above. And please let me know the bug number or
subscribe me (paul-climbing))

I believe the following is a minor thing, but I wanted to let you know
anyway. I am looking at [1], which is accessible from the top of the QA
page [2] and see that we have an interesting issue. The first item is
mentioned as an error on ia64 and powerpc:

DataF.c:4581:35: warning: array subscript is above array bounds
[-Warray-bounds]

I don't really think it is a problem at this location, but looking at
the code I see the text:
/* This routine accepts an array of wchar_t's containing wchar encodings
 * of whitespace characters (and the number of array elements), comparing
 * the wide character passed to each element of the array.  If a match
 * is found, we got a white space.  This routine exists only because
 * iswspace(3c) is not yet standard.  If a system has isw* available,
 * calls to this routine should be changed to iswspace(3c) (and callers
 * should delete initialization of the array), and this routine should
 * be deleted.  Its a stop gap measure to avoid allocating an instance
 * variable for the white_space array and/or declaring a widget wide
 * global for the data and using a macro.  Its ugly, but it works and
 * in the long run will be replaced by standard functionality. */

Maybe we should think about patching motif (and sending that upstream
obviously) to use iswspace (part of libc6). What do you think? It would
mean that motif because more locale aware with respect to whitespaces,
because now it only declares " ", \t and \n, while there are more
whitespaces.

Paul

[1] https://buildd.debian.org/~brlink/packages/m/motif.html
[2] http://packages.qa.debian.org/m/motif.html



signature.asc
Description: OpenPGP digital signature

Re: Bug#708462: lesstif2 to motif transition

[Paul Gevers]

On 09-06-13 11:05, Paul Gevers wrote:
> On 04-06-13 08:31, Julien Cristau wrote:
>> Do we know how many of the lesstif2 reverse dependencies are libraries
>> whose ABI would change if rebuilt with motif instead?
> 
> No, but I can try to find out. The original idea of lesstif was to be a
> binary compatible replacement, but I don't know how well that was
> maintained. Do you have a hint on how I can test if the ABI has changed
> of these libraries?

I found the tool icheck and am trying to use that to give the answer to
this question. I found at least one: xmhtml.

> There are 12 packages that build-depend on lesstif2 that build libraries
> (AFAICT now). I will try to improve my list, but I don't know yet how to
> test for ABI changes exactly.

I ran the following command against the udd and found indeed 10
libraries build against lesstif2-dev and depend on lesstif2:
udd=> select distinct source, package from packages where section='libs'
and source in (select source from sources where build_depends like
'%lesstif2-dev%') and ( depends like '%lesstif2%' or pre_depends like
'%lesstif2%') and release='sid';
   source|   package
-+--
 sciplot | sciplot1
 ncbi-tools6 | libvibrant6a
 inventor| libinventor0
 glw | libglw1-mesa
 xmhtml  | xmhtml1
 xbae| libxbae4
 via | libvia2
 paw | libpawlib-lesstif3-gfortran
 cernlib | libpacklib-lesstif1-gfortran
 dx  | libdx4

If I could find a proper start point I checked with the following strategy:
~$ apt-get install libmotif-dev
~$ icheck --canonify -o ../via_motif.icheck -Iinclude/ include/via.h
~$ apt-get install lesstif2-dev
~$ icheck --canonify -o ../via_lesstif.icheck -Iinclude/ include/via.h
~$ icheck --compare ../via_lesstif.icheck ../via_motif.icheck

My findings:
via (include/via.h): no diff
xmhtml (include/XmHTML/XmHTML.h): ABI/API is not compatible

I did not succeed with the others yet for different reasons.
dx: I fail to configure it (not understood yet)
glw: fails with GLwDrawA.h:147:0: Undefined identifier WidgetClass
inventor: haven't figured this one out yet.
ncbi-tools6 (vibrant/vibrant.h): doesn't play nice with icheck as it
actually BUILDS header files.
sciplot: fails to check right now on
/usr/include/X11/Core.h:51:0: Undefined identifier _XFUNCPROTOBEGIN
cernlib/paw: I haven't figured out yet how to start.

Paul



signature.asc
Description: OpenPGP digital signature

Re: Bug#708462: lesstif2 to motif transition

[Paul Gevers]

On 10-06-13 22:32, Paul Gevers wrote:
> My findings:
> via (include/via.h): no diff
> xmhtml (include/XmHTML/XmHTML.h): ABI/API is not compatible
> 
> I did not succeed with the others yet for different reasons.
> dx: I fail to configure it (not understood yet)

dx: (include/dx/dx.h after "debian/rules configure" and disabling
AC_CHECK_HEADERS(stdlib.h) in configure.ac (/usr/include/stdlib.h exist,
so I don't understand why)): no diff

> glw: fails with GLwDrawA.h:147:0: Undefined identifier WidgetClass

glw: (GLwMDrawA.h with additional include ): no diff

> inventor: haven't figured this one out yet.
> ncbi-tools6 (vibrant/vibrant.h): doesn't play nice with icheck as it
> actually BUILDS header files.

(ncbi-tools6 is already build depending on motif, I hope the maintainers
have checked this)

> sciplot: fails to check right now on

sciplot (SciPlot.h with additional include  and
): no diff

> cernlib/paw: I haven't figured out yet how to start.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#410771: Re: Bug#410771: emacs-snapshot: error "Lisp nesting exceeds `max-lisp-eval-depth'"

[Paul Gevers]

Control: tags -1 moreinfo
Control: retitle -1 emacspeak loops infinite on specific directory

Hi Tim,

Sorry for taking so long to respond to this bug, but the package
emacspeak was orphaned and just got a new maintainer.

On 24-02-07 12:04, Romain Francoise wrote:
> I believe that this is a bug in emacspeak, not in Emacs.
> 
> It's apparently looping endlessly when encountering this particular
> remote directory setup, as shown by the following sequence in the
> trace:
> 
>>emacspeak-speak-get-directory-settings("/scp:erskine:/..")
>>emacspeak-speak-get-directory-settings("/scp:erskine:/")
>>emacspeak-speak-get-directory-settings("/scp:erskine:/..")
>>emacspeak-speak-get-directory-settings("/scp:erskine:/")
>>emacspeak-speak-get-directory-settings("/scp:erskine:/..")
>>emacspeak-speak-get-directory-settings("/scp:erskine:/")
>>emacspeak-speak-get-directory-settings("/scp:erskine:/..")
> 
> I'm therefore reassigning this report to emacspeak.  Feel free to
> reassign back if this turns out to be a bug in Emacs.

It has been a long time since you reported this issue. Before I dive
into it, could you please let me know if you can still reproduce this issue?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#719757: openmotif: please package the man-pages separately so that they can be installed along with Lesstif

[Paul Gevers]

Control: reassign -1 motif

On 15-08-13 01:56, G.raud wrote:
> Having the OpenMotif manual pages in a separate package libmotif-doc instead 
> of
> inside libmotif-dev would allow this new package not to conflict with any 
> Lesstif
> packages; thus it would be possible to have some Motif manual pages installed 
> along
> with Lesstif.

Motif is now licensed with LGPL so it is finally free. We moved it to
the main archive and we try to remove Lesstif2 before we release Jessie,
making this bug moot.

However, depending on the size of the documentation, it might still be
worth it. I can't recall if we didn't look into this when we did the
motif overhaul, so reassigning to motif to not forget about this.

Paul




signature.asc
Description: OpenPGP digital signature

Re: [cluster3] please rebuild and possibly move to main

[Paul Gevers]

On 10-09-13 19:21, Thorsten Alteholz wrote:
> thanks alot for your info. Unfortunately the motif license is not the
> only hurdle to put cluster3 into main.

Clear.

> Anyway, if I understand you right, I just have to reupload the package
> to get everything straight with the motif update (so no need to change
> any dependencies)?

Yes, but if you don't have other changes that you want to upload for,
this stuff does not warrant an upload just for itself. Everything
*should* just work if you don't do anything.

Paul




signature.asc
Description: OpenPGP digital signature

Bug#482936: QA package available

[Paul Gevers]

Just for the record of this bug: I made a QA package which fixes this
bug. It is available for checking/suggestions at mentors.d.n [1].

Paul

[1]http://mentors.debian.net/cgi-bin/maintainer-packages?action=details;package=ssystem



signature.asc
Description: OpenPGP digital signature

Bug#1072302: src:gnome-shell-mailnag: fails to migrate to testing for too long: versioned dependency not yet in unstable

[Paul Gevers]

Source: gnome-shell-mailnag
Version: 40.0-5
Severity: serious
Control: close -1 40.0-7
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:gnome-shell-mailnag has been trying to 
migrate for 46 days [2]. Hence, I am filing this bug. The version in 
unstable depends on a version of gnome-shell that's not even in unstable.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=gnome-shell-mailnag



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1072780: src:transaction: fails to migrate to testing for too long: uploader built arch:all binary

[Paul Gevers]

Source: transaction
Version: 3.0.0-1
Severity: serious
Control: close -1 4.0-1
X-Debugs-CC: alexandre.deti...@gmail.com
Tags: sid trixie pending
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:transaction has been trying to migrate for 
40 days [2]. Hence, I am filing this bug.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


Your package is only blocked because the arch:all binary package(s) 
aren't built on a buildd. Unfortunately the Debian infrastructure 
doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will 
shortly do a no-changes source-only upload to DELAYED/15, closing this 
bug. Please let me know if I should delay or cancel that upload.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=transaction



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1072780: src:transaction: fails to migrate to testing for too long: uploader built arch:all binary

[Paul Gevers]

Hi,

On 15-06-2024 11:38 p.m., Colin Watson wrote:

This was fixed by transaction 4.0-2, and it looks like either you
cancelled your upload or it was automatically dropped from the DELAYED
queue.


I cancelled my upload once I spotted 4.0-2.

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#953682: src:dosage: fails to migrate to testing for too long

[Paul Gevers]

Source: dosage
Version: 2.15-2
Severity: serious
Control: fixed -1 2.15-3
Tags: sid bullseye pending
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:dosage in its
current version in unstable has been trying to migrate for 191 days.
Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have marked the version in unstable as fixing this bug, so if that
version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

Your package is only blocked because the arch:all binary package(s)
aren't built on a buildd. Unfortunately the Debian infrastructure
doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will
shortly do a no-changes source-only upload to DELAYED/15, closing this
bug. Please let me know if I should delay or cancel that upload.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html




signature.asc
Description: OpenPGP digital signature

Bug#958224: libpam-alreadyloggedin: autopkgtest regression: module 'string' has no attribute 'lowercase'

[Paul Gevers]

Source: libpam-alreadyloggedin
Version: 0.3-8
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of libpam-alreadyloggedin the autopkgtest of
libpam-alreadyloggedin fails in testing when that autopkgtest is run
with the binary packages of libpam-alreadyloggedin from unstable. It
passes when run with only packages from testing. In tabular form:

passfail
libpam-alreadyloggedin from testing0.3-8
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=libpam-alreadyloggedin

https://ci.debian.net/data/autopkgtest/testing/amd64/libp/libpam-alreadyloggedin/5030060/log.gz

autopkgtest [14:12:09]: test tests: [---
getenv(ADTTMP) ... ok
getuid() ... root
/var/run/utmp ... ok
reset umask ... ok
setup SIGALRM handler ... ok
create pam.d/login backup ... ok
create new pam.d/login ... ok
plant new pam.d/login ... ok
restore pam.d/login ... ok
Traceback (most recent call last):
  File
"/tmp/autopkgtest-lxc.d47pj_qf/downtmp/build.lDk/src/debian/tests/tests",
line 307, in 
main()
  File
"/tmp/autopkgtest-lxc.d47pj_qf/downtmp/build.lDk/src/debian/tests/tests",
line 249, in main
with c_user() as (login, password):
  File "/usr/lib/python3.8/contextlib.py", line 113, in __enter__
return next(self.gen)
  File
"/tmp/autopkgtest-lxc.d47pj_qf/downtmp/build.lDk/src/debian/tests/tests",
line 157, in c_user
login = generate_username()
  File
"/tmp/autopkgtest-lxc.d47pj_qf/downtmp/build.lDk/src/debian/tests/tests",
line 125, in generate_username
parts += [rng.choice(string.lowercase) for i in range(8)]
  File
"/tmp/autopkgtest-lxc.d47pj_qf/downtmp/build.lDk/src/debian/tests/tests",
line 125, in 
parts += [rng.choice(string.lowercase) for i in range(8)]
AttributeError: module 'string' has no attribute 'lowercase'
autopkgtest [14:12:09]: test tests: ---]



signature.asc
Description: OpenPGP digital signature

Bug#958578: wav2cdr: autopkgtest failure on arm64: Assertion `sizeof(UINT32) == 4' failed

[Paul Gevers]

Source: wav2cdr
Version: 2.3.4-3
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

With a recent upload of wav2cdr you added an autopkgtest, great. However
it fails on arm64. I copied some of the output at the bottom of this report.

Currently this failure is blocking the migration to testing [1]. Can you
please investigate the situation and fix it?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=wav2cdr

https://ci.debian.net/data/autopkgtest/testing/arm64/w/wav2cdr/4822988/log.gz

autopkgtest [19:42:21]: test command3: wav2cdr debian/tests/silence.wav
$AUTOPKGTEST_TMP/silence.mp3
autopkgtest [19:42:21]: test command3: [---
wav2cdr: wav2cdr.c:281: main: Assertion `sizeof(UINT32) == 4' failed.
bash: line 1:   837 Aborted bash -ec 'wav2cdr
debian/tests/silence.wav $AUTOPKGTEST_TMP/silence.mp3' 2> >(tee -a
/tmp/autopkgtest-lxc.zdo4nd5f/downtmp/command3-stderr >&2) > >(tee -a
/tmp/autopkgtest-lxc.zdo4nd5f/downtmp/command3-stdout)
autopkgtest [19:42:21]: test command3: ---]



signature.asc
Description: OpenPGP digital signature

Bug#960173: src:libpam-alreadyloggedin: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Source: libpam-alreadyloggedin
Version: 0.3-6
Severity: serious
Control: close -1 0.3-8
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 958224

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package
src:libpam-alreadyloggedin in its current version in unstable has been
trying to migrate for 60 days [2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=libpam-alreadyloggedin




signature.asc
Description: OpenPGP digital signature

Bug#960880: pev: autopkgtest failure: pehash did not report ASLR status

[Paul Gevers]

Source: pev
Version: 0.80-4
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

Your package pev has an autopkgtest, great. However, it fails. Can you
please investigate the situation and fix it? I copied some of the output
at the bottom of this report.

The release team has announced [1] that failing autopkgtest are now
considered RC in testing.

Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/data/autopkgtest/testing/amd64/p/pev/5529710/log.gz

autopkgtest [13:21:31]: test test-runs: [---
valgrind is /usr/bin/valgrind
==831== Memcheck, a memory error detector
==831== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==831== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==831== Command: pesec /usr/share/win32/gzip.exe
==831==
plugins: could not open directory 'src/build/plugins' -- No such file or
directory
==831==
==831== HEAP SUMMARY:
==831== in use at exit: 18 bytes in 1 blocks
==831==   total heap usage: 3 allocs, 2 frees, 4,602 bytes allocated
==831==
==831== LEAK SUMMARY:
==831==definitely lost: 0 bytes in 0 blocks
==831==indirectly lost: 0 bytes in 0 blocks
==831==  possibly lost: 0 bytes in 0 blocks
==831==still reachable: 18 bytes in 1 blocks
==831== suppressed: 0 bytes in 0 blocks
==831== Rerun with --leak-check=full to see details of leaked memory
==831==
==831== For lists of detected and suppressed errors, rerun with: -s
==831== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
error: pesec did not report ASLR status
==833== Memcheck, a memory error detector
==833== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==833== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==833== Command: pehash /usr/share/win32/gzip.exe
==833==
plugins: could not open directory 'src/build/plugins' -- No such file or
directory
==833==
==833== HEAP SUMMARY:
==833== in use at exit: 18 bytes in 1 blocks
==833==   total heap usage: 3 allocs, 2 frees, 4,602 bytes allocated
==833==
==833== LEAK SUMMARY:
==833==definitely lost: 0 bytes in 0 blocks
==833==indirectly lost: 0 bytes in 0 blocks
==833==  possibly lost: 0 bytes in 0 blocks
==833==still reachable: 18 bytes in 1 blocks
==833== suppressed: 0 bytes in 0 blocks
==833== Rerun with --leak-check=full to see details of leaked memory
==833==
==833== For lists of detected and suppressed errors, rerun with: -s
==833== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
error: pehash did not report ASLR status
autopkgtest [13:21:33]: test test-runs: ---]



signature.asc
Description: OpenPGP digital signature

Bug#961381: gsutil: autopkgtest failure: Can't locate LWP/UserAgent.pm in @INC

[Paul Gevers]

Source: gsutil
Version: 3.1-3
X-Debbugs-CC: debian...@lists.debian.org, leandrora...@debxp.org
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

You recently added an autopkgtest to your package gsutil, great.
However, it fails. Currently this failure is blocking the migration to
testing [1]. Can you please investigate the situation and fix it?

I copied some of the output at the bottom of this report.

[Release manager hat on] You'll also have to mark the tests as
"superficial" as the amount of what this tests is really minimal.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=gsutil

https://ci.debian.net/data/autopkgtest/testing/amd64/g/gsutil/5507692/log.gz

autopkgtest [03:19:01]: test command1: gsutil --version | grep -i version
autopkgtest [03:19:01]: test command1: [---
Can't locate LWP/UserAgent.pm in @INC (you may need to install the
LWP::UserAgent module) (@INC contains: /etc/perl
/usr/local/lib/x86_64-linux-gnu/perl/5.30.0 /usr/local/share/perl/5.30.0
/usr/lib/x86_64-linux-gnu/perl5/5.30 /usr/share/perl5
/usr/lib/x86_64-linux-gnu/perl/5.30 /usr/share/perl/5.30
/usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at
/usr/bin/gsutil line 26.
BEGIN failed--compilation aborted at /usr/bin/gsutil line 26.
autopkgtest [03:19:02]: test command1: ---]





signature.asc
Description: OpenPGP digital signature

Bug#961455: ngetty: autopkgtest regression: ngetty-helper: command not found

[Paul Gevers]

Source: ngetty
Version: 1.1-5
X-Debbugs-CC: debian...@lists.debian.org, guilherme@gmail.com
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of ngetty the autopkgtest of ngetty fails in
testing when that autopkgtest is run with the binary packages of ngetty
from unstable. It passes when run with only packages from testing. In
tabular form:

   passfail
getty  from testing1.1-5
all others from testingfrom testing

I copied some of the output at the bottom of this report. It seems that
either you need the needs-root restriction or need to provide the full
path to /sbin/ngetty-helper. Without needs-root, the test is run as a
regular user. Please also mark this test as superficial.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=ngetty

https://ci.debian.net/data/autopkgtest/testing/amd64/n/ngetty/5502710/log.gz

autopkgtest [21:50:06]: test command1: ngetty-helper --version | grep
version
autopkgtest [21:50:06]: test command1: [---
bash: ngetty-helper: command not found
autopkgtest [21:50:07]: test command1: ---]



signature.asc
Description: OpenPGP digital signature

Bug#961456: pwget: autopkgtest regression: Can't locate LWP/UserAgent.pm in @INC

[Paul Gevers]

Source: pwget
Version: 2016.1019+git75c6e3e-3
X-Debbugs-CC: debian...@lists.debian.org, elimar.henri...@yahoo.com.br
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of pwget the autopkgtest of pwget fails in testing
when that autopkgtest is run with the binary packages of pwget from
unstable. It passes when run with only packages from testing. In tabular
form:

   passfail
pwget  from testing2016.1019+git75c6e3e-3
all others from testingfrom testing

I copied some of the output at the bottom of this report. Seems like you
are missing a (test) dependency? Please also mark this test as superficial.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=pwget

https://ci.debian.net/data/autopkgtest/testing/amd64/p/pwget/5507726/log.gz

autopkgtest [03:27:21]: test command2: pwget -h
autopkgtest [03:27:21]: test command2: [---
Can't locate LWP/UserAgent.pm in @INC (you may need to install the
LWP::UserAgent module) (@INC contains: /etc/perl
/usr/local/lib/x86_64-linux-gnu/perl/5.30.0 /usr/local/share/perl/5.30.0
/usr/lib/x86_64-linux-gnu/perl5/5.30 /usr/share/perl5
/usr/lib/x86_64-linux-gnu/perl/5.30 /usr/share/perl/5.30
/usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at
/usr/bin/pwget line 87.
BEGIN failed--compilation aborted at /usr/bin/pwget line 87.
autopkgtest [03:27:21]: test command2: ---]





signature.asc
Description: OpenPGP digital signature

Bug#961457: idle3-tools: autopkgtest regression: idle3ctl: command not found

[Paul Gevers]

Source: idle3-tools
Version: 0.9.1-4
X-Debbugs-CC: debian...@lists.debian.org, leandrora...@debxp.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of idle3-tools the autopkgtest of idle3-tools fails
in testing when that autopkgtest is run with the binary packages of
idle3-tools from unstable. It passes when run with only packages from
testing. In tabular form:

   passfail
idle3-toolsfrom testing0.9.1-4
all others from testingfrom testing

I copied some of the output at the bottom of this report. It seems that
either you need the needs-root restriction or need to provide the full
path to /usr/sbin/idle3ctl. Without needs-root, the test is run as a
regular user. Please also mark this test as superficial.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=idle3-tools

https://ci.debian.net/data/autopkgtest/testing/amd64/i/idle3-tools/5507695/log.gz

autopkgtest [03:18:58]: test command1: idle3ctl -V | grep idle
autopkgtest [03:18:58]: test command1: [---
bash: idle3ctl: command not found
autopkgtest [03:18:58]: test command1: ---]



signature.asc
Description: OpenPGP digital signature

Bug#961933: odt2txt: autopkgtest failure: file: command not found

[Paul Gevers]

Source: odt2txt
Version: 0.5-3
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

You recently added an autopkgtest to your package odt2txt, great.
However, it fails. Currently this failure is blocking the migration to
testing [1]. Can you please investigate the situation and fix it?

I copied some of the output at the bottom of this report. Seems like
you're missing a test dependency.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=odt2txt

https://ci.debian.net/data/autopkgtest/testing/amd64/o/odt2txt/5614340/log.gz

autopkgtest [09:10:31]: test command2: cp debian/tests/file.odt
$AUTOPKGTEST_TMP;   odt2txt --raw --output=$AUTOPKGTEST_TMP/file.xml
$AUTOPKGTEST_TMP/file.odt;   file $AUTOPKGTEST_TMP/file.xml
autopkgtest [09:10:31]: test command2: [---
bash: file: command not found
autopkgtest [09:10:31]: test command2: ---]



signature.asc
Description: OpenPGP digital signature

Bug#805370: mpage licensing

[Paul Gevers]

Ping...

As a QA maintained package which is not going into the upcoming release
with a license issue open for 1.5 years, shouldn't this package be
removed from Debian?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#962062: src:wav2cdr: fails to migrate to testing for too long: autopkgtest regression on arm64

[Paul Gevers]

Source: wav2cdr
Version: 2.3.4-2
Severity: serious
Control: close -1 2.3.4-3
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 958578
X-Debbugs-CC: eribe...@debian.org

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:wav2cdr in
its current version in unstable has been trying to migrate for 60 days
[2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=wav2cdr




signature.asc
Description: OpenPGP digital signature

Bug#965222: src:gsutil: fails to migrate to testing for too long: autokgtest failure

[Paul Gevers]

Source: gsutil
Version: 3.1-1
Severity: serious
Control: close -1 3.1-3
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 961381

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:gsutil in its
current version in unstable has been trying to migrate for 63 days [2].
Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=gsutil




signature.asc
Description: OpenPGP digital signature

Bug#965221: src:pwget: fails to migrate to testing for too long: autopkgtest failure

[Paul Gevers]

Source: pwget
Version: 2016.1019+git75c6e3e-1
Severity: serious
Control: close -1 2016.1019+git75c6e3e-3
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 961456

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:pwget in its
current version in unstable has been trying to migrate for 63 days [2].
Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=pwget




signature.asc
Description: OpenPGP digital signature

Bug#969492: src:xoreos-tools: fails to migrate to testing for too long: unsatisfied Depends

[Paul Gevers]

Source: xoreos-tools
Version: 0.0.5-1
Severity: serious
Control: close -1 0.0.5-2
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:xoreos-tools
in its current version in unstable has been trying to migrate for 59
days [2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=xoreos-tools




signature.asc
Description: OpenPGP digital signature

Bug#972670: src:link-grammar: fails to migrate to testing for too long: FTBFS on arm64 and armhf autopkgtest regression

[Paul Gevers]

Source: link-grammar
Version: 5.7.0-3
Severity: serious
Control: close -1 5.8.0-1
X-Debbugs-CC: Masayuki Hatta 
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:link-grammar
in its current version in unstable has been trying to migrate for 60
days [2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=link-grammar




signature.asc
Description: OpenPGP digital signature

Bug#974872: src:splint: fails to migrate to testing for too long: uploader built arch:all binaries

[Paul Gevers]

Source: splint
Version: 1:3.1.2+dfsg-1
Severity: serious
Control: close -1 1:3.1.2+dfsg-2
X-Debbugs-CC: la...@debian.org
Tags: sid bullseye pending
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:splint in its
current version in unstable has been trying to migrate for 60 days [2].
Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

Your package is only blocked because the arch:all binary package(s)
aren't built on a buildd. Unfortunately the Debian infrastructure
doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will
shortly do a no-changes source-only upload to DELAYED/15, closing this
bug. Please let me know if I should delay or cancel that upload.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=splint




signature.asc
Description: OpenPGP digital signature

Bug#895038: libappindicator: deprecated in Debian; AppIndicator based applications, please switch to Ayatana (App)Indicator(s)

[Paul Gevers]

Hi Mike,

On Wed, 15 Apr 2020 19:06:59 + Mike Gabriel 
wrote:
> >> If you want to get this done for bullseye, please upgrade these bugs to
> >> serious. Autoremovals will take care of some of the packages. The rest will
> >> need manual fixes.
> >
> > I haven't done that. I think the severity of these bugs is a decision
> > for the maintainer of the replacement to make.
> 
> I think we should start with important and raise to serious after 8  
> weeks or so.

We're running into the freeze of bullseye soon. The first bug I checked
is still only severity important, so is it realistic to get this done
before bullseye release? If not, I propose to tag this bug as
bullseye-ignore. If yes, action is needed, this isn't going to happen
magically. At the least raising the blocking bugs to severity serious.
Help towards the maintainers of the affected packages would be very
appreciated.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#895038: libappindicator: deprecated in Debian; AppIndicator based applications, please switch to Ayatana (App)Indicator(s)

[Paul Gevers]

Hi Mike,

All bugs have caused the packages to be on the list for autoremoval. It
seems there is one bug to be filed still, can you please do that?

Paul

elbrus@coccia:~$ dak rm --no-action -R  --suite testing libappindicator
Will remove the following packages from testing:

gir1.2-appindicator-0.1 |   0.4.92-8 | amd64, arm64, armel, armhf, i386,
mips64el, mipsel, ppc64el, s390x
gir1.2-appindicator3-0.1 |   0.4.92-8 | amd64, arm64, armel, armhf,
i386, mips64el, mipsel, ppc64el, s390x
libappindicator |   0.4.92-8 | source
libappindicator-dev |   0.4.92-8 | amd64, arm64, armel, armhf, i386,
mips64el, mipsel, ppc64el, s390x
libappindicator-doc |   0.4.92-8 | all
libappindicator1 |   0.4.92-8 | amd64, arm64, armel, armhf, i386,
mips64el, mipsel, ppc64el, s390x
libappindicator3-1 |   0.4.92-8 | amd64, arm64, armel, armhf, i386,
mips64el, mipsel, ppc64el, s390x
libappindicator3-dev |   0.4.92-8 | amd64, arm64, armel, armhf, i386,
mips64el, mipsel, ppc64el, s390x

Maintainer: Debian QA Group 

--- Reason ---

--

Checking reverse dependencies...
# Broken Depends:
autokey: autokey-gtk#956762
fusion-icon: fusion-icon#956767 (fixed today)
gromit-mpx: gromit-mpx  #956769 (fixed today)
hime: hime  #956772
kylin-burner: libburner-media3-1#956774
osdlyrics: osdlyrics#956776
parcellite: parcellite  #956778
psensor: psensor#921339
redshift: redshift-gtk  #956779
screenkey: screenkey<- unfiled yet (added this year)

# Broken Build-Depends:
gcin: libappindicator3-dev  #956766
gromit-mpx: libappindicator3-dev#956769 (fixed today)
hime: libappindicator-dev   #956772
kylin-burner: libappindicator3-dev (>= 0.0.7)   #956774
osdlyrics: libappindicator-dev  #956776
parcellite: libappindicator-dev #956778
psensor: libappindicator3-dev   #921339
zeal: libappindicator-dev   #956782

Dependency problem found.




elbrus@coccia:~$ dak rm --no-action -R  --suite testing libindicator
Will remove the following packages from testing:

libindicator |0.5.0-4 | source
libindicator-dev |0.5.0-4 | amd64, arm64, armel, armhf, i386,
mips64el, mipsel, ppc64el, s390x
libindicator-tools |0.5.0-4 | amd64, arm64, armel, armhf, i386,
mips64el, mipsel, ppc64el, s390x
libindicator3-7 |0.5.0-4 | amd64, arm64, armel, armhf, i386,
mips64el, mipsel, ppc64el, s390x
libindicator3-dev |0.5.0-4 | amd64, arm64, armel, armhf, i386,
mips64el, mipsel, ppc64el, s390x
libindicator3-tools |0.5.0-4 | amd64, arm64, armel, armhf, i386,
mips64el, mipsel, ppc64el, s390x
libindicator7 |0.5.0-4 | amd64, arm64, armel, armhf, i386, mips64el,
mipsel, ppc64el, s390x

Maintainer: Debian QA Group 

--- Reason ---

--

Checking reverse dependencies...
# Broken Depends:
libappindicator: libappindicator1   # well.
 libappindicator3-1

# Broken Build-Depends:
libappindicator: libindicator-dev (>= 0.3.90)   # well.
 libindicator3-dev (>= 0.3.90)

Dependency problem found.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#983017: 9base: flaky autopkgtest on i386: stack smashing detected

[Paul Gevers]

Source: 9base
Version: 1:6-10
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

shoogle has an autopkgtest, great. However, on i386 it fails more often
than it passes [1].

Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

On top of that stack smashing seems a serious issue on it's own.

I copied the output at the bottom of this report. Can you please look
into it and make the test more robust (against network issues). If you
keep the test that requires internet, you should add the needs-internet
restriction too.

Paul

[1] https://ci.debian.net/packages/9/9base/testing/i386/

https://ci.debian.net/data/autopkgtest/testing/i386/9/9base/10243149/log.gz

autopkgtest [18:26:16]: test command14: RP=/usr/lib/plan9/bin;
$RP/fortune debian/tests/lorem.txt | $RP/sha1sum
autopkgtest [18:26:16]: test command14: [---
*** stack smashing detected ***: terminated
bash: line 1:  3091 Done$RP/fortune
debian/tests/lorem.txt
  3092 Aborted | $RP/sha1sum
autopkgtest [18:26:16]: test command14: ---]



OpenPGP_signature
Description: OpenPGP digital signature

Bug#983017: 9base: flaky autopkgtest on i386: stack smashing detected

[Paul Gevers]

Hi,

On Thu, 18 Feb 2021 08:28:06 +0100 Paul Gevers  wrote:
> shoogle has an autopkgtest, great. However, on i386 it fails more often
  ^^^ oops, that's what you get for reusing an old mail.

> I copied the output at the bottom of this report. Can you please look
> into it and make the test more robust (against network issues). If you
> keep the test that requires internet, you should add the needs-internet
> restriction too.

This paragraph also doesn't apply. Sorry for the sub-optimal report.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#959022: cgroup-tools: does not work in cgroup2 / unified hierarchy

[Paul Gevers]

Hi all,

For documentation, I log our IRC conversation here.

[20:24:27]  elbrus et al: just in case you have already seen
santiago_ 's email: what's your thought on #959022
[20:24:38] [zwiebelbot] Debian#959022: cgroup-tools: does not work in
cgroup2 / unified hierarchy - https://bugs.debian.org/959022
[20:26:24]  do you lean towards getting libcgroup updated to
support cgroupv2 or documenting in the release notes that rdeps of
libcgroup will have to switch to the old cgroupv1 setup if they need
this functionality?
[20:29:13] -*- bunk looks at
https://tracker.debian.org/news/1236679/accepted-clsync-045-2-source-into-unstable/
and wonders whether the remaining 3 rdeps should/can also drop
dependencies in the latter case.
[20:31:24]  I think zigo said cinder needs it
[20:32:10]  no idea what that is, but I understand it's part of
the OpenStack stack?
[20:33:25] -*- bunk wonders whether there is a reviewable change for the
"fix by adding/packporting cgroupv2" option, since that would IMHO sound
better than documenting manual changes in the release notes
[20:34:50]  elbrus: good question. It sounds more like,
cinder can use cgroup in certain configurations. Not sure if it's really
a hard dependency
[20:35:55]  Then again, I don't really know OpenStack either.
zigo_ are you around?
[20:38:27]  mbiebl[m]: so any user of any of these rdeps would
need to run their full system in an "less supported" way?
[20:38:46]  sounds ... not ideal
[20:38:55]  elbrus: yeah, it's an all-or-nothing setting
[20:39:01]  boo
[20:39:40]  right, this makes me a bit nervous. I'm not sure
where cgroupv1 support will be 3 years down the lane
[20:40:03]  I can imagine that systemd upstream won't have
any interest in bugs that might result of it
[20:40:04]  security risks?
[20:40:14]  or just bugs?
[20:41:02]  by the way, I'll probably copy/paste this discussion
in the bug unless anybody objects
[20:41:11]  hm, not sure if it has security implications
[20:41:46]  and what's the amount of updates systemd normally
gets in the release?
[20:41:47]  I can tell you in 3 years :-)
[20:41:56]  obviously ;)
[20:42:26]  but I mean, do you consider this a risky surface, or
is it most likely OK?
[20:46:21]  cinder using libcgroup to configure I/O bandwidth
looks like optional functionality already present upstream in buster but
only enabled in bullseye.
[20:46:51]  elbrus: AFAIU the cgroup stuff is mostly resource
control, so not security critical.  But by bookworm people should
probably finish migration to cgroupv2...
[20:46:57]  booting with hybrid/cgroupv1 probably works ok
(still).
[20:46:57]  But a/ you first need to know, that you have to
fiddle with grub / kernel command line settings to make it work
[20:46:57]  I'mf not sure if the error messages in
cinder/OpenStack give any clue what the problem is
[20:47:30]  and b/ I'd prefer if all users just would use
cgroupv2, as this makes it easier for me as systemd maintainer
[20:48:10]  ansgar: I don't think there's a question about
bookworm :)
[20:48:13]  From #d-systemd yesterday: "cgcreate: libcgroup
initialization failed: Cgroup is not mounted" seems to be the error
message from cgcreate (which cinder calls)
[20:49:24]  Maybe it's easy to patch relevant places in
cgroup-tools to include some Debian-specific note pointing to the kernel
command-line arguments or some README file?
[20:49:29]  then we should ask zigo to disable that new option?
[20:49:54]  thanks ansgar
[20:50:16]  (I have no idea how discoverable these messages are
to users if it's some other tool calling cgcreate.)
[20:50:51]  I guess the only really relevant rdep of
libcgroup is cinder i.e. the OpenStack suite
[20:50:53]  elbrus: Cinder uses "cgcreate" from cgroupv1 to do
block device QoS, so yeah, we need to document the kernel command line
parameters and keep cgroups v1 around if possible.
[20:51:12]  elbrus: I did test the command line arguments that I
documented in the bug, and it does work perfectly.
[20:51:19]  zigo: I read the bug
[20:51:47]  FSVO perfectly
[20:52:06]  the maintainer of systemd disagrees about it being
perfectly supported
[20:52:19]  nova looks similar to cinder?
[20:52:29]  then there's mininet
[20:52:52]  mininet is a leaf package
[20:53:47]  cinder looks like that too (at least on popcon)
[20:54:21]  (sorry, not leaf, didn't check that)
[20:54:26]  as said, I'm not really familiar with the
OpenStack suite of software
[20:55:03]  so I don't know if cinder is actually entirely
optional (my understanding was, it isn't)
[20:56:05]  IMHO plan A would be if santiago would have a
reasonable package to update cgroup-tools (there is some preliminary
package mentioned in the bug)
[20:56:32]  The thing to write in the command line is:
[20:56:32]  systemd.unified_cgroup_hierarchy=false
systemd.legacy_systemd_cgroup_controller=false
[20:56:49]  With it, cgroups v1 is mounted somewhere in /sys.
[20:57:04]  "new upstream version" sounds better than "keep the
old version that requires manual kernel commandline changes

Bug#993743: xdemorse: autopkgtest regression: warning on stderr

[Paul Gevers]

Source: xdemorse
Version: 3.6.4-1
X-Debbugs-CC: debian...@lists.debian.org, mo...@debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of xdemorse the autopkgtest of xdemorse fails in
testing when that autopkgtest is run with the binary packages of
xdemorse from unstable. It passes when run with only packages from
testing. In tabular form:

   passfail
xdemorse   from testing3.6.4-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. Looking at the
actual test, I wonder how useful it is. There was a discussion somewhere
recently about xvfb and maybe also about ending with "&", but I forgot
the details. It may be that the test can't fail (apart from output to
stderr, which is exactly what's happening here).

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it? I think dropping the
test until something more sensible comes up makes sense. At the very
least, it also needs to be tagged as superficial, as documented in the
release policy [2]

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=xdemorse
[2] https://release.debian.org/testing/rc_policy.txt section 6(a)

https://ci.debian.net/data/autopkgtest/testing/amd64/x/xdemorse/15038359/log.gz

autopkgtest [01:17:04]: test command1: xvfb-run -a xdemorse -v
autopkgtest [01:17:04]: test command1: [---

(xdemorse:3992): dbind-WARNING **: 01:17:04.875: AT-SPI: Error
retrieving accessibility bus address:
org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not
provided by any .service files
xdemorse 3.6.4
autopkgtest [01:17:05]: test command1: ---]



OpenPGP_signature
Description: OpenPGP digital signature

Bug#996442: src:aspell-hr: fails to migrate to testing for too long: uploader built arch:all

[Paul Gevers]

Source: aspell-hr
Version: 0.51-5
Severity: serious
Control: close -1 0.51-6
X-Debbugs-CC: jel...@debian.org
Tags: sid bookworm pending
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing
and unstable for more than 60 days as having a Release Critical bug in
testing [1]. Your package src:aspell-hr has been trying to migrate for
61 days [2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bookworm, so
it doesn't affect (old-)stable.

Your package is only blocked because the arch:all binary package(s)
aren't built on a buildd. Unfortunately the Debian infrastructure
doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will
shortly do a no-changes source-only upload to DELAYED/15, closing this
bug. Please let me know if I should delay or cancel that upload.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=aspell-hr




OpenPGP_signature
Description: OpenPGP digital signature