Re: update on RC bug#734101: libjs-jquery-mobile not working

[Paul Gevers]

Hi Sebastiaan,

On 03/19/17 20:32, Sebastiaan Couwenberg wrote:
> Based on the popcon for openlayers dropping the -doc package is not
> likely to adversely affect users. If that makes life for others easier,
> I'm happy to stop building that binary package.

Logged from #debian-release:

[20:37:15]  ivodd: regarding libjs-jquery-mobile, one link is
offered to be broken by the maintainer of OpenLayers by not building the
-doc binary. Is that something you would consider? (see last paragraph
of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734101#41)
[20:38:17]  it would break the link with wireshark IIUC
[20:42:31]  elbrus: if dropping the -doc package helps, sure, drop it
[20:43:02]  ivodd: I think it is one step; horde is then still
in the picture

I suggest you remove the libjs-openlayers-doc package if it is useless
without libjs-jquery-mobile.

Paul



signature.asc
Description: OpenPGP digital signature
___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel

update on RC bug#734101: libjs-jquery-mobile not working

[Paul Gevers]

Follow-up for RC bug 734101, a partial investigation at BSP in
Mönchengladbach.

On Sun, 22 Jan 2017 13:54:54 +0100 Dominik George  wrote:
> I am working on fixing this in time for the freeze.

Which failed, albeit Dominik committed updates to the pkg-javascript git
repo¹. Because libjs-jquery-mobile is currently considered a key
package², IIUC because wireshark depends on it, it isn't going to be
automatically removed.

libwireshark-data depends on libjs-openlayers. And libjs-openlayers-doc,
build from the same source, depends on libjs-jquery-mobile. Also horde
depends on libjs-jquery-mobile.

I talked to Ivo De Decker (Release Team assistant) on the BSP in
Mönchengladbach, and one option out of the libjs-jquery-mobile tree may
still be a new upstream version. So attached, I start with the diffstat
of the git diff of the two upstream version in the pkg-javascript tree.
Looks like demo files were changed and more even, added, but that
shouldn't be too big of an issue. I'll try to look into the extend of
the changes in the .css and .js file, but looking at the size, that may
be huge.

However, other solutions may lay in the direction of
removing/downgrading dependencies of libjs-openlayers on
libjs-jquery-mobile (how much is it needed for a documentation
package?), removing the horde dependency (apparently the Horde usage is
broken already since 2014, see bug 749799 in CC) and similar dependency
tree resolutions. I'll try to make time to look into this, but don't
mind if other people beat me to it.

Paul

¹ http://git.debian.org/?p=pkg-javascript/jquery-mobile.git
² https://udd.debian.org/cgi-bin/key_packages.yaml.cgi

 /dev/null  
   |binary
 b/demos/_assets/css/jqm-demos.css  
   |  733 
 b/demos/_assets/img/album-bb.jpg   
   |binary
 b/demos/_assets/img/apple.png  
   |binary
 b/demos/_assets/img/bg-pattern.png 
   |binary
 b/demos/_assets/img/bike.jpg   
   |binary
 b/demos/_assets/img/blackberry_10.png  
   |binary
 b/demos/_assets/img/bmw-thumb.jpg  
   |binary
 b/demos/_assets/img/bmw.jpg
   |binary
 b/demos/_assets/img/buenosaires.jpg
   |binary
 b/demos/_assets/img/capetown.jpg   
   |binary
 b/demos/_assets/img/devices.png
   |binary
 b/demos/_assets/img/firefox_os.png 
   |binary
 b/demos/_assets/img/galaxy_express.png 
   |binary
 b/demos/_assets/img/landrover-thumb.jpg
   |binary
 b/demos/_assets/img/landrover.jpg  
   |binary
 b/demos/_assets/img/lumia_800.png  
   |binary
 b/demos/_assets/img/newyork.jpg
   |binary
 b/demos/_assets/img/nexus_7.png
   |binary
 b/demos/_assets/img/paris.jpg  
   |binary
 b/demos/_assets/img/phone_galaxy3.png  
   |binary
 b/demos/_assets/img/phone_iphone5.png  
   |binary
 b/demos/_assets/img/phone_lumia920.png 
   |binary
 b/demos/_assets/img/phone_onex.png 
   |binary
 b/demos/_assets/img/seoul.jpg  
   |binary
 b/demos/_assets/img/sydney.jpg 
   |binary
 b/demos/_assets/img/tesla-thumb.jpg
   |binary
 b/demos/_assets/img/tesla.jpg  
   |binary
 b/demos/_assets/img/tizen.png  
   |binary
 b/demos/_assets/js/h2widget.js 
   |  169 
 b/demos/_assets/js/index.js
   | 1027 
 b/demos/_assets/js/jqm-demos.js
   |  311 
 b/demos/_assets/js/view-source.js  
   |  545 
 b/demos/_search/index.html 
   |  943 
 b/demos/backbone-requirejs/backbone-require.html

Bug#728150: grass: diff for NMU version 6.4.3-2.1

[Paul Gevers]

tags 672719 + patch
tags 672719 + pending
tags 728150 + patch
tags 728150 + pending
thanks

Dear maintainer,

I've prepared an NMU for grass (versioned as 6.4.3-2.1) and
uploaded it to DELAYED/3. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru grass-6.4.3/debian/changelog grass-6.4.3/debian/changelog
--- grass-6.4.3/debian/changelog2013-09-26 11:21:23.0 +0200
+++ grass-6.4.3/debian/changelog2013-12-14 12:35:21.0 +0100
@@ -1,3 +1,13 @@
+grass (6.4.3-2.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * On ia64 build with $(HARDENING_DISABLE_PIE_CFLAGS_FILTER) filtered for
+now (closes: #728150)
+  * Add patch fix_big-endian_issues which allows grass to build on s390x
+and ppc64 (closes: #672719)
+
+ -- Paul Gevers elb...@debian.org  Sat, 14 Dec 2013 12:17:17 +0100
+
 grass (6.4.3-2) unstable; urgency=low
 
   [ M. Hamish Bowman ]
diff -Nru grass-6.4.3/debian/patches/fix_big-endian_issues 
grass-6.4.3/debian/patches/fix_big-endian_issues
--- grass-6.4.3/debian/patches/fix_big-endian_issues1970-01-01 
01:00:00.0 +0100
+++ grass-6.4.3/debian/patches/fix_big-endian_issues2013-12-14 
12:28:48.0 +0100
@@ -0,0 +1,151 @@
+Description: Fix big endian behavior
+Origin: https://trac.osgeo.org/grass/changeset/57855
+Bug: https://trac.osgeo.org/grass/ticket/1430
+Bug-Debian: http://bugs.debian.org/672719
+
+--- a/lib/vector/diglib/portable.c
 b/lib/vector/diglib/portable.c
+@@ -155,21 +155,19 @@
+   memset(buf, 0, cnt * sizeof(long));
+   /* read from buffer in changed order */
+   c1 = (unsigned char *)buffer;
+-  if (lng_order == ENDIAN_LITTLE)
+-  c2 = (unsigned char *)buf;
+-  else
+-  c2 = (unsigned char *)buf + nat_lng - PORT_LONG;
++  c2 = (unsigned char *)buf;
+   for (i = 0; i  cnt; i++) {
+   /* set to FF if the value is negative */
+   if (lng_order == ENDIAN_LITTLE) {
+   if (c1[PORT_LONG - 1]  0x80)
+   memset(c2, 0xff, sizeof(long));
++  memcpy(c2, c1, PORT_LONG);
+   }
+   else {
+   if (c1[0]  0x80)
+   memset(c2, 0xff, sizeof(long));
++  memcpy(c2 + nat_lng - PORT_LONG, c1, PORT_LONG);
+   }
+-  memcpy(c2, c1, PORT_LONG);
+   c1 += PORT_LONG;
+   c2 += sizeof(long);
+   }
+@@ -227,21 +225,19 @@
+   memset(buf, 0, cnt * sizeof(int));
+   /* read from buffer in changed order */
+   c1 = (unsigned char *)buffer;
+-  if (int_order == ENDIAN_LITTLE)
+-  c2 = (unsigned char *)buf;
+-  else
+-  c2 = (unsigned char *)buf + nat_int - PORT_INT;
++  c2 = (unsigned char *)buf;
+   for (i = 0; i  cnt; i++) {
+   /* set to FF if the value is negative */
+   if (int_order == ENDIAN_LITTLE) {
+   if (c1[PORT_INT - 1]  0x80)
+   memset(c2, 0xff, sizeof(int));
++  memcpy(c2, c1, PORT_INT);
+   }
+   else {
+   if (c1[0]  0x80)
+   memset(c2, 0xff, sizeof(int));
++  memcpy(c2 + nat_int - PORT_INT, c1, PORT_INT);
+   }
+-  memcpy(c2, c1, PORT_INT);
+   c1 += PORT_INT;
+   c2 += sizeof(int);
+   }
+@@ -299,21 +295,19 @@
+   memset(buf, 0, cnt * sizeof(short));
+   /* read from buffer in changed order */
+   c1 = (unsigned char *)buffer;
+-  if (shrt_order == ENDIAN_LITTLE)
+-  c2 = (unsigned char *)buf;
+-  else
+-  c2 = (unsigned char *)buf + nat_shrt - PORT_SHORT;
++  c2 = (unsigned char *)buf;
+   for (i = 0; i  cnt; i++) {
+   /* set to FF if the value is negative */
+   if (shrt_order == ENDIAN_LITTLE) {
+   if (c1[PORT_SHORT - 1]  0x80)
+   memset(c2, 0xff, sizeof(short));
++  memcpy(c2, c1, PORT_SHORT);
+   }
+   else {
+   if (c1[0]  0x80)
+   memset(c2, 0xff, sizeof(short));
++  memcpy(c2 + nat_shrt - PORT_SHORT, c1, PORT_SHORT);
+   }
+-  memcpy(c2, c1, PORT_SHORT);
+   c1 += PORT_SHORT;
+   c2 += sizeof(short);
+   }
+@@ -438,15 +432,15 @@
+   }
+   else {
+   buf_alloc(cnt * PORT_LONG);
+-  if (lng_order == ENDIAN_LITTLE)
+-  c1 = (unsigned char *)buf;
+-  else
+-  c1 = (unsigned char *)buf + nat_lng - PORT_LONG;
++  c1 = (unsigned char *)buf;
+   c2 = (unsigned char *)buffer;
+   for (i = 0; i  cnt; i++) {
+-  memcpy(c2, c1, PORT_LONG);
+-  c1 += PORT_LONG

Bug#728150: grass: FTBFS on ia64, preventing migration to testing

[Paul Gevers]

On 09-12-13 22:06, Paul Gevers wrote:
 I haven't tried ppc64 yet.

I can't find a ppc64 porterbox, so I can't test this for you.

Just for the heads up, this bug is currently the only reason why
lesstif2 can't be removed from Debian. Thus, I would appreciate an
upload (I can sponsor if needed).

And just for the record, without a response to this bug I will probably
generate an NMU next weekend to fix this issue with the proposed
ifeq-else statement and the patch applied for bug 672719.

Paul



signature.asc
Description: OpenPGP digital signature
___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel

Bug#728150: Re: Re: grass: FTBFS on ia64, preventing migration to testing

[Paul Gevers]

As mentioned before, I do not receive e-mails to this bug. Sorry for not
responding earlier.

On 16-11-13 02:50, Hamish wrote:
 if [ `uname -m` = ia64 ] ; then

 or is there a better way to do arch-specific lines with the aid of debhelper?

Yes (well, no actually):
{{{
# in Wheezy (and Jessie ia64) -fPIE conflicts with -fPIC. See example in
# the hardening.make file.
ifeq ($(shell dpkg-architecture -qDEB_HOST_ARCH_CPU),ia64)
CFLAGS += $(HARDENING_CFLAGS_PIC) \
$(filter-out
$(HARDENING_DISABLE_PIE_CFLAGS_FILTER),$(HARDENING_CFLAGS))
LDFLAGS+=$(HARDENING_LDFLAGS)
else
# in Jessie  Sid the problem seems fixed so we can proceed normally
CFLAGS+=$(HARDENING_CFLAGS)
LDFLAGS+=$(HARDENING_LDFLAGS)
endif
}}}

 for a longer term fix, should we forward this bug to the ia64 arch Debian 
 people?

Yes, that would be good. Maybe they are already aware, so a little
search would be good too.

 A Debian geek may know...

True, but I don't. ;)

 [offtopic, re. #672719]
 Do you want me to test this on a porterbox?
 
 yes please :)

   https://trac.osgeo.org/grass/changeset/57855

I applied the patch 57855 on s390x and the build succeeds. I haven't
tried ppc64 yet.

Paul



signature.asc
Description: OpenPGP digital signature
___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel

Bug#728150: grass: FTBFS on ia64, preventing migration to testing

[Paul Gevers]

On 02-11-13 10:00, Paul Gevers wrote:
 [Please be aware that if you reply to a bug report, the original
 reported does NOT get your message automatically.]
 
 On 31-10-13 23:38, Hamish wrote:
 yes, we're aware of it; sorry not much insight so far on how to fix it.

 also I'm a little surprised that the ppc64 and s390x big-endian error*
 seems to have fixed itself without us applying our patch-from-trunk
 to it yet. (??)
 [*] http://bugs.debian.org/672719
 
 Could it be that this is fixed (or prevented automatically) in some
 recent update in the tool chain? Do you want me to test this on a
 porterbox? Could you point me to your patch-from-trunk patch that you
 wanted to apply to fix the ppc64 and s390x FTBFS? Why did you leave that
 bug open anyway?
 
 Paul

Hmm, were did you get the impression that ppc64 and s390x actually did
build? They seem to be still failing as far as I can tell, but not
blocking anything as grass has never been build successfully on those archs.

Paul




signature.asc
Description: OpenPGP digital signature
___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel

Bug#728150: Re: grass: FTBFS on ia64, preventing migration to testing

[Paul Gevers]

On 31-10-13 23:38, Hamish wrote:
 yes, we're aware of it; sorry not much insight so far on how to fix it.

I am not 100% sure how this works, but by enabling the commented out
code in debian/rules about -fPIE and -fPIC again (line 21/22), the
builds completes successfully. I found [1] when I searched for
relocation against dynamic symbol, that is why I looked in that direction.

The other remarked that made me think this is the solution is a comment
in /usr/include/hardening-wrapper/hardening.make [2]:

In cases where mixed shared objects and executable objects are being
built, -fPIC needs to actually replace -fPIE, since gcc won't
distinguish between them yet.

Although that doesn't explain why on other arches it does work.

Paul

[1] http://www.cmake.org/Wiki/CMake_IA64_FPIC_problem
[2]
http://anonscm.debian.org/loggerhead/hardening/master/annotate/head:/hardening-wrapper/hardening.make



signature.asc
Description: OpenPGP digital signature
___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel

Bug#723974: grass FTBFS on buildds because it build depends on versioned virtual package

[Paul Gevers]

Package: grass
Version: 6.4.3-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

In the latest upload of grass, the build dependency for libtiff has been 
changed to
libtiff-dev ( 4.0.3-1~) | libtiff5-dev
However, build deamons only consider the first build dependency, and that is 
invalid
as libtiff-dev is a virtual package. So now grass is not building [1].

Policy 7.5 says this:
If a relationship field has a version number attached, only real packages will 
be
considered to see whether the relationship is satisfied (or the prohibition 
violated,
for a conflict or breakage). In other words, if a version number is specified, 
this is
a request to ignore all Provides for that package name and consider only real
packages. The package manager will assume that a package providing that virtual
package is not of the right version. A Provides field may not contain version
numbers, and the version number of the concrete package which provides a 
particular
virtual package will not be considered when considering a dependency on or 
conflict
with the virtual package name.

[1] https://buildd.debian.org/status/package.php?p=grass

Thanks for considering.

- -- System Information:
Debian Release: 7.1
  APT prefers stable
  APT policy: (500, 'stable'), (99, 'unstable'), (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)

iQEcBAEBCAAGBQJSPdsXAAoJEJxcmesFvXUK8U8H/0UJI5DhK0/+6X+dosQYFAWh
ZB4WMP+lX8UTZ+e9ycldqckqMj+y94NBJV9AQpkcsIwE8VXbOeHqvN6sUD0eZ9VY
uXt8nNiqv8ClI+dD7dffkj8rDYf2sGrt6BemHT3IV7XmwABG0/mfMRtgP99upJpO
+/NYW0TPNm3Lv6hmmMZTMk5JcpQysWJeNQxFn/fcbbBMKnzDyps8Dnia/OJDeoBB
fZ11J8qc3sT3Y1AF86S1I4bFG1mnl3VvTLXGj8jRKAxKmVay4AFJ0Wj8QLegkngX
0BYAp2I3hBhBJ7QbW+LSkoVAeR4hI46m9BFHNZwkTKr0htWX2KEtiaf1Bz6DFwo=
=fDf4
-END PGP SIGNATURE-

___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel