Bug#874386: opal-utils missing utility

[Frederic Bonnard]

Package: skiboot
Version: 5.4.3-1

Hi,
this is a reminder to myself : opal-utils should include getsram binary.

F.
Package: sbtVersion: 0.13.13-2Severity: serioussbt is not installable; it depends on various packages like sbt-test-interface that only exist in experimental.


pgpHsJhb7hKW9.pgp
Description: PGP signature

Bug#872738: C++14 issue on power

[Frederic Bonnard]

I forgot to say, the __linux define is missing with -std=c++14 as I
showed but I didn't say that explicitely.

F.

Bug#872738: C++14 issue on power

[Frederic Bonnard]

For some reason there is no define of __linux on ppc64el :

On ppc64el :

$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/powerpc64le-linux-gnu/7/lto-wrapper
Target: powerpc64le-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 7.2.0-1' 
--with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs 
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-7 
--program-prefix=powerpc64le-linux-gnu- --enable-shared 
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext 
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ 
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-libquadmath --enable-plugin --enable-default-pie --with-system-zlib 
--enable-objc-gc=auto --enable-secureplt --with-cpu=power8 
--enable-targets=powerpcle-linux --disable-multilib --enable-multiarch 
--disable-werror --with-long-double-128 --enable-checking=release 
--build=powerpc64le-linux-gnu --host=powerpc64le-linux-gnu 
--target=powerpc64le-linux-gnu
Thread model: posix
gcc version 7.2.0 (Debian 7.2.0-1) 

$ echo | gcc  -dM -E -|grep linux
#define __linux 1
#define __linux__ 1
#define __gnu_linux__ 1
#define linux 1

$ echo | gcc -std=c++14 -dM -E -|grep linux
cc1: warning: command line option ‘-std=c++14’ is valid for C++/ObjC++ but not 
for C
#define __linux__ 1
#define __gnu_linux__ 1

also :

$ echo | gcc-6 -std=c++14 -dM -E -|grep linux
cc1: warning: command line option ‘-std=c++14’ is valid for C++/ObjC++ but not 
for C
#define __linux__ 1
#define __gnu_linux__ 1


On amd64 :

$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 7.2.0-1' 
--with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-7 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie 
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto 
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none --without-cuda-driver 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-
 linux-gn
 u --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.2.0 (Debian 7.2.0-1) 

$ echo | gcc  -dM -E -|grep linux
#define __linux 1
#define __linux__ 1
#define __gnu_linux__ 1
#define linux 1

$ echo | gcc -std=c++14 -dM -E -|grep linux
cc1: warning: command line option ‘-std=c++14’ is valid for C++/ObjC++ but not 
for C
#define __linux 1
#define __linux__ 1
#define __gnu_linux__ 1
#define linux 1

$ echo | gcc-6 -std=c++14 -dM -E -|grep linux
cc1: warning: command line option ‘-std=c++14’ is valid for C++/ObjC++ but not 
for C
#define __linux 1
#define __linux__ 1
#define __gnu_linux__ 1
#define linux 1

Previous version of contextfree didn't use that new code.
It seems like this is still an unclear behaviour of gcc :
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69473

I'd advise to move to __linux__ which the attached patch does.


F.
Description: Fix undefined macro on powerpc
 On powerpc and maybe some other architecture, __linux macro is not defined :
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69473
 Just use __linux__ instead
Author: Frédéric Bonnard 
Bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69473
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
Index: contextfree-3.0.11.4+dfsg1/src-unix/posixSystem.cpp
===
--- contextfree-3.0.11.4+dfsg1.orig/src-unix/posixSystem.cpp2017-08-13 
19:25:02.0 +
+++ contextfree-3.0.11.4+dfsg1/src-unix/posixSystem.cpp 2017-08-21 
11:45:39.789635483 +
@@ -232,7 +232,7 @@
 size_t
 PosixSystem::getPhysicalMemory()
 {
-#ifdef __linux
+#ifdef __linux__
 #if defined(_SC_PHYS_PAGES) && defined(_SC_PAGESIZE)
 uint64_t size = sysconf(_SC_PHYS_PAGES) * 
static_cast(sysconf(_SC_PAGESIZE));
 if (size > MaximumMemory)
@@ -241,7 +241,7 @@
 #else
 return 0;
 #endif
-#else // __linux
+#else // __linux__
 int mib[2];
 mib[0] = CTL_HW;
 #if defined(HW_MEMSIZE)
@@ -267,6 +267,6 @@
 return static_cast(size);
 }
 return 0;
-#endif // 

Bug#868887: POWER9 : random segvs and illegal instructions

[Frederic Bonnard]

Source: linux
Source-Version: 4.9.30-2+deb9u1
Severity: important
Tags: patch

--

Hi,
I'm forwarding the attached patch for POWER9 (dd2.00 hardware), that it would be
nice to have in Stretch. As explained in it :

"
On POWER9 the ERAT may be incorrect on wakeup from some stop states
that lose state. This causes random segvs and illegal instructions
when these stop states are enabled.

This patch invalidates the ERAT on wakeup on POWER9 to prevent this
from causing a problem.
"

Here is the original patch :
https://patchwork.ozlabs.org/patch/780365/
It got backported and applied in Ubuntu Zesty and Artfull:
https://lists.ubuntu.com/archives/kernel-team/2017-June/085197.html
and it reached upstream as well :
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ba6d334ac230065243a92bb7cb3fd6a5f6a7f8ac

The attached patch has been backported to Debian's 4.9.30 by Michael
Neuling.

Thanks,

F.


pgpZxQUqH3V72.pgp
Description: PGP signature
commit 557e402e5707f771b8bdd51e0f210227af30c254
Author: Benjamin Herrenschmidt 
Date:   Sat Jun 24 12:29:01 2017 -0500

powerpc/64s: Invalidate ERAT on powersave wakeup for POWER9

On POWER9 the ERAT may be incorrect on wakeup from some stop states
that lose state. This causes random segvs and illegal instructions
when these stop states are enabled.

This patch invalidates the ERAT on wakeup on POWER9 to prevent this
from causing a problem.

(cherry picked from commit ba6d334ac230065243a92bb7cb3fd6a5f6a7f8ac)

Signed-off-by: Michael Neuling 
Signed-off-by: Benjamin Herrenschmidt 
Reviewed-by: Nicholas Piggin 
[mpe: Merge comment change with upstream changes]
Signed-off-by: Michael Ellerman 

diff --git a/arch/powerpc/kernel/idle_book3s.S 
b/arch/powerpc/kernel/idle_book3s.S
index b350ac5e31..9adf3ba9ab 100644
--- a/arch/powerpc/kernel/idle_book3s.S
+++ b/arch/powerpc/kernel/idle_book3s.S
@@ -375,6 +375,13 @@ _GLOBAL(power9_idle_stop)
  */
 _GLOBAL(pnv_restore_hyp_resource)
 BEGIN_FTR_SECTION
+   /*
+* Workaround for POWER9, if we lost resources, the ERAT
+* might have been mixed up and needs flushing.
+*/
+   blt cr3,1f
+   PPC_INVALIDATE_ERAT
+1:
ld  r2,PACATOC(r13);
/*
 * POWER ISA 3. Use PSSCR to determine if we






pgpzn3fqjjn6f.pgp
Description: PGP signature

Bug#765370: Help needed for this patch

[Frederic Bonnard]

Hi,
the patch didn't have much feedback on the mailing list upstream.
Julien could you help on this ?
For the time being would be possible to take the patches in the
packaging ?
sciplot is still failing.

F.


pgpnK2FXSETkl.pgp
Description: PGP signature

Bug#860809: installation-reports: ipv6 SLAAC autoconf not working with stretch's network install

[Frederic Bonnard]

Hi Philipp, thanks for taking time to look at this,

On Fri, 21 Apr 2017 14:33:45 +0200, Philipp Kern <pk...@debian.org> wrote:
> On 2017-04-20 14:03, Frederic Bonnard wrote:
> > ~ # ip addr
> > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1
> > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> > inet 127.0.0.1/8 scope host lo
> >valid_lft forever preferred_lft forever
> > inet6 ::1/128 scope host
> >valid_lft forever preferred_lft forever
> > 2: enP5p1s0f0: <BROADCAST,MULTICAST> mtu 1500 qdisc mq qlen 1000
> > link/ether 70:e2:84:14:24:ed brd ff:ff:ff:ff:ff:ff
> > 3: enP5p1s0f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq qlen 
> > 1000
> > link/ether 70:e2:84:14:24:ee brd ff:ff:ff:ff:ff:ff
> > inet6 2002:903:15f:550:72e2:84ff:fe14:24ee/64 scope global dynamic
> >valid_lft 2591627sec preferred_lft 604427sec
> > inet6 fe80::72e2:84ff:fe14:24ee/64 scope link
> >valid_lft forever preferred_lft forever
> > 
> > /etc/resolv.conf shows correct content with "search" field 
> > corresponding to the
> > domain I provided and "nameserver" is the one I provided also.
> 
> It's a bit unhelpful though that you didn't provide that information. 

Sorry about that :-/

> You seem to indicate that you need to use IPv4 to access the nameserver? 

Yes, I actually was given only static IPv4 parameters to connect the
network (and no DHCPv4 server is available on it).

> Is the real failure you report that it did not configure IPv4 correctly? 
> I.e. didn't show a prompt and continued without it?

Well yes, at least I don't mind it tries to probe for DHCPv[46] (that
makes sense) but if it fails like it seems to do here, shouldn't it
propose a manual setup? In that case, I would have continue with a
static IPv4 configuration and the installation.

I managed to get the manual setup menus, by changing the priority of the
installer, also undoing the IPv6 (if I remember correctly) and so on but
that's not straightforward.

Also when it asks for the nameserver in the ncurses gui, how am I
supposed to know that it's trying to do an IPv6 setup ? (tell me if I'm
wrong, but given the ip output, it seems it was in the middle of an IPv6
setup after having failed the IPv4 dhcp probing and thus expecting an
IPv6 nameserver)

> Is a DHCPv4 server 
> on the network where you tried this? Because the DHCP client seems to be 
> unable to acquire an address.

There is no DHCPv4 server on this network. So the installer correctly
failed that part of the setup.

> Does an IPv6 nameserver work? (Assuming your 6to4 connectivity actually 
> works.)

I don't know, I've not been provided that information, only IPv4 static
configuration parameters.
Does the fact that SLAAC autoconfiguration worked means that there is
some IPv6 network available at some point ?
Also,  I guess  that  the  installer was  expecting  an IPv6  nameserver
because  it did  SLAAC autoconfiguration  after failing  DHCPv4. Do  you
confirm that ?

If so, shouldn't the installer gui let the user know for which kind of
network setup it asks a parameter (such as the nameserver) ?

> Also it'd be helpful to see "ip -6 route" and "ip route".

No problem :

~ # ip route
~ # ip -6 route
2002:903:15f:550::/64 dev enP5p1s0f1  metric 256  expires 0sec
fe80::/64 dev enP5p1s0f1  metric 256 
default via fe80::4e96:14ff:fe59:d7f0 dev enP5p1s0f1  metric 1024  expires 0sec
unreachable default dev lo  metric -1  error -101
ff00::/8 dev enP5p1s0f1  metric 256 
unreachable default dev lo  metric -1  error -101
~ # ip add
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: enP5p1s0f0: <BROADCAST,MULTICAST> mtu 1500 qdisc mq qlen 1000
link/ether 70:e2:84:14:24:ed brd ff:ff:ff:ff:ff:ff
3: enP5p1s0f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq qlen 1000
link/ether 70:e2:84:14:24:ee brd ff:ff:ff:ff:ff:ff
inet6 2002:903:15f:550:72e2:84ff:fe14:24ee/64 scope global dynamic 
   valid_lft 2591868sec preferred_lft 604668sec
inet6 fe80::72e2:84ff:fe14:24ee/64 scope link 
   valid_lft forever preferred_lft forever


Thanks a lot Philipp,

F.


pgpk8pFMbrFhU.pgp
Description: PGP signature

Bug#860900: AST device driver better support on Power

[Frederic Bonnard]

Source: linux
Source-Version: 4.9.18-1
Tags: patch

--

Hi,
many Power (especially P9) machines use AST graphic cards.
There were many improvements and bug fixes recently on this side and it
would be nice to have those in futur 4.9.x Stretch kernels.
Some of those patches have already been taken in the linux lts 4.9
kernel, namely 4.9.15 :
- [arm64,powerpc*,x86] drm/ast: Fix test for VGA enabled
- [arm64,powerpc*,x86] drm/ast: Call open_key before enable_mmio in POST 
code
- [arm64,powerpc*,x86] drm/ast: Fix AST2400 POST failure without BMC FW or 
VBIOS

Since then and still in 4.9.24, there are no other patch for this. Those
that would be nice to have are in this list (ordered from 1st to last to
be applied) :

[not included] 6c971c09f38704513c426ba6515f22fb3d6c87d5 : drm/ast: Fixed system 
hanged if disable P2A
[included] 3856081eede297b617560b85e948cfb00bb395ec : drm/ast: Fix AST2400 
POST failure without BMC FW or VBIOS
[not included] 71f677a91046599ece96ebab21df956ce909c456 : drm/ast: Handle 
configuration without P2A bridge
[not included] 22acdbb1bdbd56cc9939e18516dfcf214a9d835b : drm/ast: const'ify 
mode setting tables
[not included] cf2f6bd402470caed4e4d75b783d2d48277a3568 : drm/ast: Remove 
spurrious include
[not included] 6475a7cce61967fca4dd793b60acf5a7dc70bc9a : drm/ast: Fix 
calculation of MCLK
[not included] 9f93c8b3c08f8c456aad86fd05caa6a1688320ff : drm/ast: Base support 
for AST2500
[not included] bad09da6deab157440a3f0dd5e6c03cdc60c0a91 : drm/ast: Fixed vram 
size incorrect issue on POWER
[not included] b368e53aae7694e0fb2bdec9667c9acc5108b629 : drm/ast: Factor 
mmc_test code in POST code
[not included] d95618ef0a05236a2642d1a829fffd90de88e5f0 : drm/ast: Rename 
ast_init_dram_2300 to ast_post_chip_2300
[not included] 94fdc2a86a927b409d9a09ba28bcb08e34f3ac8d : drm/ast: POST code 
for the new AST2500
[included] 905f21a49d388de3e99438235f3301cabf0c0ef4 : drm/ast: Fix test for 
VGA enabled
[included] 9bb92f51558f2ef5f56c257bdcea0588f31d857e : drm/ast: Call 
open_key before enable_mmio in POST code

only "[not included]" ones should be needed as 3 of them are already in
4.9.18-1 ; the latter should cause some minor fuzz.

Thanks,

F.


pgp7lh4Xeokaj.pgp
Description: PGP signature

Bug#859969: Make native related files optional on bytecode archs

[Frederic Bonnard]

Hi again Stéphane,

On Tue, 18 Apr 2017 10:28:38 +0200, Stéphane Glondu <glo...@debian.org> wrote:
> On 13/04/2017 18:39, Frederic Bonnard wrote:
> > on bytecode only architectures, the native related files won't be compiled 
> > because
> > ocamlopt is not available in ocaml. So I made those files optional in the 
> > attached patch.
> > Note that on ppc64el, ocamlopt is available starting with ocaml 4.03 and
> > .a, .cmx and .cmxa will be generated.
> 
> ocaml-dtools compiles on other bytecode only architectures. Do you have 
> an explanation on why it fails only on powerpcspe, ppc64 and sparc64?
> 
> https://buildd.debian.org/status/package.php?p=ocaml-dtools=sid

As explained, in #859966, I guess the problem occurred at a later time
and the build was re-run after this on those failing architectures, but
it should happen on other bytecode archs.

As for #859966, here is an updated patch with a correct destination
directory (tested on amd64).

F.
diff -Nru ocaml-dtools-0.3.1/debian/libdtools-ocaml-dev.install.in 
ocaml-dtools-0.3.1/debian/libdtools-ocaml-dev.install.in
--- ocaml-dtools-0.3.1/debian/libdtools-ocaml-dev.install.in2013-05-09 
00:54:19.0 +
+++ ocaml-dtools-0.3.1/debian/libdtools-ocaml-dev.install.in2013-05-09 
00:54:35.0 +
@@ -1 +1,2 @@
-src/META src/*.a src/*.cm* src/*.mli @OCamlStdlibDir@/dtools
+src/META src/*.cm* src/*.mli @OCamlStdlibDir@/dtools
+OPT: src/*.a @OCamlStdlibDir@/dtools


pgpJX9SRjbjbn.pgp
Description: PGP signature

Bug#859966: Make native related files optional on bytecode archs

[Frederic Bonnard]

Hi Stéphane,

On Tue, 18 Apr 2017 10:50:16 +0200, Stéphane Glondu  wrote:
> On 18/04/2017 10:25, Stéphane Glondu wrote:
> >> on bytecode only architectures, the native related files won't be
> >> compiled because
> >> ocamlopt is not available in ocaml. So I made those files optional in
> >> the attached patch.
> >> Note that on ppc64el, ocamlopt is available starting with ocaml 4.03 and
> >> .cmx and .cmxa will be generated.
> >
> > I am suprised. How come ocaml-ao compiles as is on other bytecode only
> > architectures, e.g. mips, s390x?
> >
> > https://buildd.debian.org/status/package.php?p=ocaml-ao=unstable
> 

As for #859969, I think we don't see the issue on other bytecode
only architectures due to the fact that the builds occurred long time
ago, before the issue actually appeared.
See the attached log where the problem happens on mips.

> Actually, debhelper changed meanwhile. In particular, changelog of 
> version 9.20160402 says:
> 
> >   * dh_install: Fix a regression where a non-existing file
> > was ignored if another file was matched for the same
> > destination dir.  Thanks to Ben Hutchings for reporting
> > the issue.  (Closes: #818834)

That explains indeed.
> Thanks for the patch. However, did you try it on a native architectures? 
> It looks like the destination dir is missing on the OPT line...

That's right, sorry for that, here is better patch which I tested on
amd64 and that puts the .cmx and .cmxa in the good place.

F.
sbuild (Debian sbuild) 0.72.0 (25 Oct 2016) on misc-debomatic2

+==+
| ocaml-ao 0.2.0-1 (mips)  Tue, 18 Apr 2017 09:52:48 + |
+==+

Package: ocaml-ao
Version: 0.2.0-1
Source Version: 0.2.0-1
Distribution: unstable
Machine Architecture: amd64
Host Architecture: mips
Build Architecture: mips

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/unstable-mips-debomatic-0176e65b-066a-4725-8496-f547cccf4e71'
 with '<>'

+--+
| Chroot Setup Commands|
+--+


/home/debomatic/debomatic/sbuildcommands/chroot-setup-commands/dpkg-speedup 
ocaml-ao_0.2.0-1 unstable mips
--


I: Finished running 
'/home/debomatic/debomatic/sbuildcommands/chroot-setup-commands/dpkg-speedup 
ocaml-ao_0.2.0-1 unstable mips'.

Finished processing commands.


+--+
| Update chroot|
+--+

Get:1 http://debomatic-mips.debian.net/debomatic/unstable unstable InRelease 
[2300 B]
Hit:2 http://ftp.debian.org/debian unstable InRelease
Hit:3 http://cdn-fastly.deb.debian.org/debian unstable InRelease
Ign:1 http://debomatic-mips.debian.net/debomatic/unstable unstable InRelease
Fetched 2300 B in 12s (178 B/s)
Reading package lists...
W: No sandbox user '_apt' on the system, can not drop privileges
W: GPG error: http://debomatic-mips.debian.net/debomatic/unstable unstable 
InRelease: The following signatures were invalid: 
5EF4B898B5705C8953CFEF9136BF8574F4914DAB
W: The repository 'http://debomatic-mips.debian.net/debomatic/unstable unstable 
InRelease' is not signed.
W: Invalid 'Date' entry in Release file 
/var/lib/apt/lists/partial/debomatic-mips.debian.net_debomatic_unstable_dists_unstable_Release
Reading package lists...
Building dependency tree...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

+--+
| Fetch source files   |
+--+


Local sources
-

/srv/debomatic-mips/ocaml-ao_0.2.0-1.dsc exists in /srv/debomatic-mips; copying 
to chroot
I: NOTICE: Log filtering will replace 'build/ocaml-ao-f9tSe2/ocaml-ao-0.2.0' 
with '<>'
I: NOTICE: Log filtering will replace 'build/ocaml-ao-f9tSe2' with 
'<>'

+--+
| Install build-essential  |
+--+


Setup apt archive
-

Merged Build-Depends: build-essential, fakeroot
Filtered Build-Depends: build-essential, fakeroot
dpkg-deb: building package 'sbuild-build-depends-core-dummy' in 

Bug#859462: Fix from upstream

[Frederic Bonnard]

Hi,
here is attached part of the patch applied upstream (
https://github.com/TelepathyIM/telepathy-qt/commit/15374115fa910ffa41ac2acce71b7f4fc0937674
)
That fixed the problem here.

F.
--- a/tests/dbus/contacts-capabilities.cpp
+++ b/tests/dbus/contacts-capabilities.cpp
@@ -111,7 +111,7 @@
 QStringList ids = QStringList() << QLatin1String("alice")
 << QLatin1String("bob") << QLatin1String("chris");
 
-gboolean supportTextChat[] = { TRUE, FALSE, FALSE };
+bool supportTextChat[] = { true, false, false };
 
 TpHandleRepoIface *serviceRepo =
 tp_base_connection_get_handles(TP_BASE_CONNECTION(mConn->service()),


pgpJbaNMhDw2p.pgp
Description: PGP signature

Bug#859969: Make native related files optional on bytecode archs

[Frederic Bonnard]

Hi,
on bytecode only architectures, the native related files won't be compiled 
because
ocamlopt is not available in ocaml. So I made those files optional in the 
attached patch.
Note that on ppc64el, ocamlopt is available starting with ocaml 4.03 and
.a, .cmx and .cmxa will be generated.

F.
diff -Nru ocaml-dtools-0.3.1/debian/libdtools-ocaml-dev.install.in 
ocaml-dtools-0.3.1/debian/libdtools-ocaml-dev.install.in
--- ocaml-dtools-0.3.1/debian/libdtools-ocaml-dev.install.in2013-05-09 
00:54:19.0 +
+++ ocaml-dtools-0.3.1/debian/libdtools-ocaml-dev.install.in2013-05-09 
00:54:35.0 +
@@ -1 +1,2 @@
-src/META src/*.a src/*.cm* src/*.mli @OCamlStdlibDir@/dtools
+src/META src/*.cm* src/*.mli @OCamlStdlibDir@/dtools
+OPT: src/*.a


pgpk5khnNRITJ.pgp
Description: PGP signature

Bug#859966: Make native related files optional on bytecode archs

[Frederic Bonnard]

Hi,
on bytecode only architectures, the native related files won't be compiled 
because
ocamlopt is not available in ocaml. So I made those files optional in the 
attached patch.
Note that on ppc64el, ocamlopt is available starting with ocaml 4.03 and
.cmx and .cmxa will be generated.

F.
diff -u ocaml-ao-0.2.0/debian/libao-ocaml-dev.install.in 
ocaml-ao-0.2.0/debian/libao-ocaml-dev.install.in
--- ocaml-ao-0.2.0/debian/libao-ocaml-dev.install.in
+++ ocaml-ao-0.2.0/debian/libao-ocaml-dev.install.in
@@ -1 +1,2 @@
-src/META src/*.a src/*.cma src/*.cmi src/*.cmx src/*.cmxa src/*.mli 
@OCamlStdlibDir@/ao
+src/META src/*.a src/*.cma src/*.cmi src/*.mli @OCamlStdlibDir@/ao
+OPT: src/*.cmx src/*.cmxa 


pgpkn37khDsux.pgp
Description: PGP signature

Bug#859965: workaround

[Frederic Bonnard]

Hi,
I guess that ocaml generates C code that is not compliant with gcc6 :
https://gcc.gnu.org/gcc-6/porting_to.html

For the time being I propose the attached patch.
Note that I included m68k arch for the workaround because buildd shows that
it fails for this arch as the build was newer than for all other archs
but, there may be other archs failing and needing to be taken into
account)

Another action would be to check if upstream could fix this (I didn't
find any reference to that kind of improvement), so that a later version
of ocaml will just make this workaround useless.

F.
diff -Nru mldonkey-3.1.5/debian/rules mldonkey-3.1.5/debian/rules
--- mldonkey-3.1.5/debian/rules 2015-10-14 08:04:20.0 +
+++ mldonkey-3.1.5/debian/rules 2015-10-14 08:05:31.0 +
@@ -10,6 +10,10 @@
   confflags += --build $(DEB_BUILD_GNU_TYPE) --host $(DEB_HOST_GNU_TYPE)
 endif
 
+ifneq (,$(filter $(DEB_HOST_ARCH),ppc64el m68k))
+  export DEB_CXXFLAGS_MAINT_APPEND = -std=gnu++98
+endif
+
 override_dh_auto_clean:
 # Update the PO, as suggested in "man 7 po-debconf"
debconf-updatepo


pgptGcO6ZJrtU.pgp
Description: PGP signature

Bug#845751: patch backported to gcc-6 available

[Frederic Bonnard]

I see upstream has a patch for gcc-6 .
Would it be possible to import it ?

Thanks,

F.


pgpqSD_OZqxpy.pgp
Description: PGP signature

Bug#858619: -dbg package for ppc64el

[Frederic Bonnard]

Source: linux
Source-Version: 4.10-1~exp1
Tags: patch

--

Hi,
what is the policy for having a -dbg package for linux-image packages ?
Some architecture have one, some others don't.
Would it be possible that ppc64el have one, please ? :)
Ideally having it in unstable would be nice, but because of the freeze, I 
mentioned
experimental's version.
Thanks,

F.
diff -Nru linux-4.10/debian/config/ppc64el/defines 
linux-4.10/debian/config/ppc64el/defines
--- linux-4.10/debian/config/ppc64el/defines2016-01-19 14:39:35.0 
+0100
+++ linux-4.10/debian/config/ppc64el/defines2017-03-24 16:07:18.0 
+0100
@@ -4,6 +4,7 @@
 kernel-arch: powerpc
 
 [build]
+debug-info: true
 image-file: vmlinux
 vdso: true
 


pgpYonIdw1uvc.pgp
Description: PGP signature

Bug#856363: RFS: sbt-launcher-interface/1.0.0-1 ITP: sbt-launcher-interface -- Sbt launcher module

[Frederic Bonnard]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "sbt-launcher-interface"

 Package name: sbt-launcher-interface
 Version : 1.0.0-1
 Upstream Author : Mark Harrah, David MacIver
 URL : https://github.com/sbt/launcher
 License : BSD-3-clause
 Section : java

It builds those binary packages:

  libsbt-launcher-interface-java - Sbt launcher module

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

  https://mentors.debian.net/package/sbt-launcher-interface


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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/sbt-launcher-interface/sbt-launcher-interface_1.0.0-1.dsc

More information about sbt-launcher-interface can be obtained from : 
https://github.com/sbt/launcher

Note:
  I'm looking for  a sponsor to push this package  in experimental first
  as it would be part of a much bigger effort to bring sbt into Debian.
  This package is the 1st one of a set of ~10 packages that intend to
  provide the minimum runtime dependencies for sbt.
  I described more my bootstrapping approach in bug #639910.
  I guess it should bring questions and maybe they should be added to
  #639910.
  Not sure I'm on the good path, but I'm willing to help and start with
  something concrete.

Regards,
 Frederic Bonnard


pgpfgaXQc4nxs.pgp
Description: PGP signature


pgp6BqXPxromI.pgp
Description: PGP signature

Bug#856359: RFS: scopt/3.5.0-1 ITP: scopt -- Simple scala command line options parsing

[Frederic Bonnard]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "scopt"

 Package name: scopt
 Version : 3.5.0-1
 Upstream Author : scopt contributors
 URL : https://github.com/scopt/scopt
 License : Expat
 Section : java

It builds those binary packages:

  libscopt-java - Simple scala command line options parsing

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

  https://github.com/scopt/scopt


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

  dget -x https://mentors.debian.net/debian/pool/main/s/scopt/scopt_3.5.0-1.dsc

More information about scopt can be obtained from : 
https://github.com/scopt/scopt

Note:
  I'm looking for  a sponsor to push this package  in experimental first
  as it would be part of a much bigger effort to bring sbt into Debian.
  This package is the 1st one of a set of ~10 packages that intend to
  provide the minimum runtime dependencies for sbt.
  I described more my bootstrapping approach in bug #639910.
  I guess it should bring questions and maybe they should be added to
  #639910.
  Not sure I'm on the good path, but I'm willing to help and start with
  something concrete.

Regards,
 Frederic Bonnard


pgpFXHsAUuqDu.pgp
Description: PGP signature


pgpr_TlQmjLJB.pgp
Description: PGP signature

Bug#855941: What is done in Debian Java team for multi source tarball packages (Was: Bug#855941: RFS: scala-pickling/0.10.1-1 ITP: scala-pickling -- Fast, customizable, boilerplate-free pickling suppo

[Frederic Bonnard]

Hi Andreas,
indeed, not only is it made of several source tarballs but some of them
are binary for now (as explained here :
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639910#118) and maybe
this can be a bit of an issue for VCS. But some time in the futur these extra
bootstrap sources should disappear.
Anyway thanks for reviewing.

F.

On Mon, 27 Feb 2017 15:24:55 +0100, Andreas Tille <andr...@an3as.eu> wrote:
> Hi again,
> 
> I just noticed that scala-pickling consists of multiple source tarballs.
> Unfortunately git-buildpackage does not deal properly with this type of
> packages.  So my step to move it to Git was somehow useless.  I think to
> move forward I'll set
> 
>   Maintainer: Debian Java Maintainers 
> <pkg-java-maintain...@lists.alioth.debian.org>
>   Uploaders: Frédéric Bonnard <fre...@linux.vnet.ibm.com>
> 
> check the packaging and upload to new if it is OK.  While the package
> is waiting in the new queue we can discuss how to deal with the VCS.
> 
> Kind regards
> 
>   Andreas.
> 
> On Mon, Feb 27, 2017 at 03:06:00PM +0100, Andreas Tille wrote:
> > Hi Frederic,
> > 
> > On Mon, Feb 27, 2017 at 01:47:08PM +0100, Frederic Bonnard wrote:
> > > sorry for the late answer and thanks for your help (I followed your
> > > idea)
> > > I just asked for Debian Java team membership.
> > > I may have to dig more about that team Git repository process as I don't
> > > know much about it at the moment :)
> > 
> > It might help to get you started if I inject right into git which you
> > can clone via
> > 
> > gbp clone ssh://git.debian.org/git/pkg-java/scala-pickling.git
> > 
> > Just let me know if you need further assistance
> > 
> > Kind regards
> > 
> >Andreas.
> > 
> > > On Mon, 27 Feb 2017 13:34:06 +0100, Andreas Tille <andr...@an3as.eu> 
> > > wrote:
> > > > Hi Frederic,
> > > > 
> > > > I'm not sure whether you received my offer to sponsor the package
> > > > if you would inject it into a team Git repository.
> > > > 
> > > > Kind regards
> > > > 
> > > >  Andreas.
> > > > 
> > > > On Fri, Feb 24, 2017 at 08:09:07PM +0100, Andreas Tille wrote:
> > > > > Hi,
> > > > > 
> > > > > I'd willing to sponsor scala-pickling since I need sbt for some 
> > > > > project.
> > > > > However, my personal policy is to sponsor only team maintained 
> > > > > packages.
> > > > > So please if you are not yet a member of the Debian Java team (which
> > > > > IMHO perfectly fits for this package) join the team and commit the
> > > > > packaging to Debian Java Git.  Just let me know if you need help to do
> > > > > so.
> > > > > 
> > > > > Kind regards and thanks for working on this package
> > > > > 
> > > > > Andreas.
> > > > > 
> > > > > -- 
> > > > > http://fam-tille.de
> > > > > 
> > > > > 
> > > > 
> > > > -- 
> > > > http://fam-tille.de
> > > > 
> > 
> > 
> > 
> > -- 
> > http://fam-tille.de
> > 
> > 
> 
> -- 
> http://fam-tille.de
> 


pgpBa97NyyUKL.pgp
Description: PGP signature

Bug#855941: RFS: scala-pickling/0.10.1-1 ITP: scala-pickling -- Fast, customizable, boilerplate-free pickling support for Scala

[Frederic Bonnard]

Hi Andreas,
sorry for the late answer and thanks for your help (I followed your
idea)
I just asked for Debian Java team membership.
I may have to dig more about that team Git repository process as I don't
know much about it at the moment :)

F.

On Mon, 27 Feb 2017 13:34:06 +0100, Andreas Tille  wrote:
> Hi Frederic,
> 
> I'm not sure whether you received my offer to sponsor the package
> if you would inject it into a team Git repository.
> 
> Kind regards
> 
>  Andreas.
> 
> On Fri, Feb 24, 2017 at 08:09:07PM +0100, Andreas Tille wrote:
> > Hi,
> > 
> > I'd willing to sponsor scala-pickling since I need sbt for some project.
> > However, my personal policy is to sponsor only team maintained packages.
> > So please if you are not yet a member of the Debian Java team (which
> > IMHO perfectly fits for this package) join the team and commit the
> > packaging to Debian Java Git.  Just let me know if you need help to do
> > so.
> > 
> > Kind regards and thanks for working on this package
> > 
> > Andreas.
> > 
> > -- 
> > http://fam-tille.de
> > 
> > 
> 
> -- 
> http://fam-tille.de
> 


pgpSyONhKRLcu.pgp
Description: PGP signature

Bug#639910: Packaging sbt

[Frederic Bonnard]

Hi Emmanuel/people,
[Let me know if putting 2 mailings in Cc is making too much noise.]
I'm looking for a sponsor for a 1st dependency I submitted on @mentors (
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855941 )
A few others should follow to bring a running sbt, but I'd like to show
a first real package and have your feedback before spamming other RFS.
Thanks for reading,

F.

On Fri, 9 Dec 2016 10:24:06 +0100, Frederic Bonnard <fre...@linux.vnet.ibm.com> 
wrote:
> On Thu, 8 Dec 2016 23:16:52 +0100, Emmanuel Bourg <ebo...@apache.org> wrote:
> > Le 18/11/2016 à 14:41, Frederic Bonnard a écrit :
> > 
> > Hi Frederic,
> > 
> > > There is much  work to finalize this  if that is ok,  but indeed, before
> > > continuing I'd like to know if I'm on the good path.
> > 
> > This looks like a valid approach. Did you use Scala 2.10 or 2.11 for
> > compiling SBT?
> 
> I used scala 2.11 as it's the one available in unstable.
> 
> > If you have a working SBT package I suggest uploading it
> > now to experimental/non-free, this will enable others to jump in and
> > help with the dependencies.
> 
> Well, that's where I'm unsure.
> I packaged in a functional manner all the sbt components I listed above,
> meaning, that it would need further work (on control/copyright/...etc files).
> This was a POC and functionally speaking, that seems to work.
> Now if the approach I followed is valid according to Debian policy, I'll
> do things properly to push sbt and that minimal set of dependencies in 
> experimental.
> I don't think it would be ok to do a binary upload. My idea was to do a
> full clean source upload, right ?
> If so, I'll focus on the coming days/weeks to provide all this.
> 
> F.


pgpSWtTPFwkXe.pgp
Description: PGP signature

Bug#855941: RFS: scala-pickling/0.10.1-1 ITP: scala-pickling -- Fast, customizable, boilerplate-free pickling support for Scala

[Frederic Bonnard]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "scala-pickling"

 Package name: scala-pickling
 Version : 0.10.1-1
 Upstream Author : École Polytechnique Fédérale de Lausanne
 URL : https://github.com/scala/pickling
 License : BSD-3-clause
 Section : java

It builds those binary packages:

  libscala-pickling-java - Fast, customizable, boilerplate-free pickling
support for Scala

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

  https://mentors.debian.net/package/scala-pickling


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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/scala-pickling/scala-pickling_0.10.1-1.dsc

More information about scala-pickling can be obtained from : 
https://github.com/scala/pickling

Note:
  I'm looking for  a sponsor to push this package  in experimental first
  as it would be part of a much bigger effort to bring sbt into Debian.
  This package is the 1st one of a set of ~10 packages that intend to
  provide the minimum runtime dependencies for sbt.
  I described more my bootstrapping approach in bug #639910.
  I guess it should bring questions and maybe they should be added to
  #639910.
  Not sure I'm on the good path, but I'm willing to help and start with
  something concrete.

Regards,
 Frederic Bonnard



pgpy4nP2deNTo.pgp
Description: PGP signature

Bug#855306: ITP: json4s -- Single AST to be used by other scala json libraries

[Frederic Bonnard]

Package: wnpp
Severity: wishlist

This project aims to provide a single AST to be used by other scala json
libraries. This  project also  attempts to set  lift-json free  from the
release schedule imposed by the lift framework.

License: Apache-2.0
Copyright: 2016 Lightbend, Inc.
URL: https://github.com/json4s/json4s


pgp99PSDsSjXV.pgp
Description: PGP signature

Bug#855304: ITP: sbt -- Scala Build Tool

[Frederic Bonnard]

Package: wnpp
Severity: wishlist

Sbt is a  build tool for Scala,  Java, and more. While it  is written in
Scala  and provides  many Scala  conveniences, it  is a  general purpose
build tool.
Little  or no  configuration  required for  simple projects  Scala-based
build definition that can use the full flexibility of Scala code

License: BSD-3-clause
Copyright: 2008-2014 Typesafe Inc
   2008-2014 Mark Harrah
   2008-2014 Grzegorz Kossakowski
   2008-2014 Josh Suereth
   2008-2014 Indrajit Raychaudhuri
   2008-2014 Eugene Yokota, and other contributors.
URL: https://github.com/sbt/sbt


pgpHsESg74WWl.pgp
Description: PGP signature

Bug#855303: ITP: sbt-template-resolver -- Sbt template resolver

[Frederic Bonnard]

Package: wnpp
Severity: wishlist

This is a contract interface for template resolver.
A template  resolver is a partial  function that looks at  the arguments
after sbt  new and  determines whether  it can  resolve to  a particular
template.

License: Apache-2.0
Copyright: 2016 Lightbend, Inc.
URL: https://github.com/sbt/template-resolver


pgpfkYhX_yUfq.pgp
Description: PGP signature

Bug#855305: ITP: scala-tools-sbinary -- Scala mapping library for binary types

[Frederic Bonnard]

Package: wnpp
Severity: wishlist

SBinary is  a library for  describing binary  protocols, in the  form of
mappings between  Scala types and  binary formats. It  can be used  as a
robust serialization  mechanism for  Scala objects or  a way  of dealing
with existing binary formats found in the wild.

License: Expat
Copyright: 2008 David R. MacIver
URL: https://github.com/harrah/sbinary


pgpGaUse2WKCB.pgp
Description: PGP signature

Bug#855301: ITP: scopt -- Simple scala command line options parsing

[Frederic Bonnard]

Package: wnpp
Severity: wishlist

Scopt provides two styles of parsing: immutable and mutable.
In  immutable parsing  style, a  config object  is passed  around as  an
argument into  action callbacks. On  the other hand, in  mutable parsing
style you are expected to modify the config object in place.

License: Expat
Copyright: 2017 scopt contributors
URL: https://github.com/scopt/scopt


pgpHycell2aTA.pgp
Description: PGP signature

Bug#855302: ITP: sbt-launcher-interface -- Sbt launcher module

[Frederic Bonnard]

Package: wnpp
Severity: wishlist

This project is the componetized sbt  launcher. It can be used to launch
many Maven/Ivy deployed applications and  utilities, and forms the basis
of sbt, activator and conscript's launching abilities.

License: BSD-3-clause
Copyright: 2008-2010 Mark Harrah
   2008-2010 David MacIver
URL: https://github.com/sbt/launcher


pgpZkwu6WiCso.pgp
Description: PGP signature

Bug#855299: ITP: jawn -- Scala json parser

[Frederic Bonnard]

Package: wnpp
Severity: wishlist

Jawn was designed to parse JSON into an AST as quickly as possible.
Jawn consists of three parts: a fast, generic JSON parser, a small,
somewhat anemic AST, support packages which parse to third-party ASTs

License: Expat
Copyright: 2012-2016 Erik Osheim
URL: https://github.com/non/jawn


pgplaaGaGnXyU.pgp
Description: PGP signature

Bug#855300: ITP: sbt-serialization -- Serialization facility for sbt

[Frederic Bonnard]

Package: wnpp
Severity: wishlist

Sbt  serialization  is  an  opinionated wrapper  around  Scala  pickling
focused  on sbt's  usage. In  particular  it provides:  JSON format  and
static-only core picklers.

License: Apache-2.0
Copyright: 2012-2013 Typesafe Inc.
URL: https://github.com/sbt/serialization


pgpuFmVBhxrZQ.pgp
Description: PGP signature

Bug#855298: ITP: scala-pickling -- Fast, customizable, boilerplate-free pickling support for Scala

[Frederic Bonnard]

Package: wnpp
Severity: wishlist

Scala Pickling is an automatic serialization framework made for Scala.
It's fast, boilerplate-free, and allows users to easily swap in/out different
serialization formats (such as binary, or JSON), or even to provide
their own custom serialization format.

License: BSD-3-clause
Copyright: 2012-2014 École Polytechnique Fédérale de Lausanne
   2012-2014 Typesafe, Inc.
   2014 Databricks
URL: https://github.com/scala/pickling


pgpgvGMwdgC3A.pgp
Description: PGP signature

Bug#855297: ITP: sbt-ivy -- agile dependency manager

[Frederic Bonnard]

Package: wnpp
Severity: wishlist

Sbt Ivy is patched Apache Ivy for sbt.
Ivy is a very powerful dependency manager oriented toward Java
dependency management, even though it could be used to manage
dependencies of any kind.

License: Apache-2.0
Copyright: 2009-2014, The Apache Software Foundation
   2009-2017, sbt-ivy contributors
URL: https://github.com/sbt/ivy


pgppK9CidqyJm.pgp
Description: PGP signature

Bug#855293: ITP: sbt-test-interface -- Sbt test interface

[Frederic Bonnard]

Package: wnpp
Severity: wishlist

Uniform test interface to Scala test frameworks (specs, ScalaCheck,
ScalaTest)
For test framework authors, the interfaces to implement are: Framework,
Runner2, Fingerprint (one of SubclassFingerprint or
AnnotatedFingerprint)
Sbt is a build tool for Scala, Java, and more.

License: BSD-3-clause
Copyright: 2009-2010 Josh Cough, 2009-2010 Mark Harrah
URL: https://github.com/sbt/test-interface


pgpWQk9QxC43k.pgp
Description: PGP signature

Bug#847941: RFS: libvecpf/1.1.0-1 ITP: libvecpf -- Vector Printf Library

[Frederic Bonnard]

Hi Tobias,
I don't know if you have more time now that the freeze is behind us, but let
me know if you are still interested in sponsoring this packaging.
Thank you,

F.

On Fri, 20 Jan 2017 07:23:46 +0100, Tobias Frost <t...@debian.org> wrote:
> Hi Frederic,
> 
> currently I'm short on time and as new packages are currently not the
> priority (won't be part of Stretch anyway) please let me defer that to
> past-freeze. Ping me again then and I'll take a look.
> 
> --
> tobi
> 
> Am Mittwoch, den 11.01.2017, 09:58 +0100 schrieb Frederic Bonnard:
> > Hi Tobias, Gianfranco.
> > 
> > Tobias, Thierry agreed and I change the owner, I hope it's better
> > now.
> > 
> > Any of you would have time to review the package?
> > I added Gianfranco as is my usual sponsor,  but I forgot to Cc him in
> > my
> > initial request.
> > Thanks,
> > 
> > F.
> > 
> > On Mon, 19 Dec 2016 08:12:06 +0100, Tobias Frost <t...@debian.org>
> > wrote:
> > > Control: tags -1 wontfix
> > > Control: block 806720 by -1
> > > 
> > > Hi Frederick,
> > > 
> > > the ITP is owned by Thierry Fauck, did you check with him if it is
> > > ok
> > > to take this ITP? (Should be done via the BTS and then the ITP's
> > > meta
> > > data should be corrected accordingly.
> > > 
> > > Please remove the wontfix when this has been resolved. 
> > > 
> > > --
> > > tobi
> > > 
> 


pgpqXHShdORv8.pgp
Description: PGP signature

Bug#853733: Make scala depend on a specific jline version

[Frederic Bonnard]

Source: scala
Source-Version: 2.11.8-1

--

Hi,
scala binary package depends on libjline2-java but .pom files do not reflect 
this.
So when one installs scala, the pom file shows : 

$ tail 
/usr/share/maven-repo/org/scala-lang/scala-compiler/2.11.*/scala-compiler-2.11.*.pom
 
==> 
/usr/share/maven-repo/org/scala-lang/scala-compiler/2.11.8/scala-compiler-2.11.8.pom
 <==


  
  jline
  jline
  debian
  true

  

==> 
/usr/share/maven-repo/org/scala-lang/scala-compiler/2.11.x/scala-compiler-2.11.x.pom
 <==


  
  jline
  jline
  debian
  true

  

And neither libjline-java nor libjline2-java define a debian version.
So when I try to package some scala related app, it tries to find jline and it 
breaks :

== resolving dependencies 
org.scala-lang#scala-compiler;2.11.x->jline#jline;debian [optional->master(*)]
loadData of jline#jline;debian of rootConf=default
using redefined-public to resolve jline#jline;debian
redefined-public: Checking cache for: dependency: jline#jline;debian 
{optional=[compile(*), master(*)]}
no ivy file in cache for jline#jline;debian: tried 
/home/debian/.ivy2/cache/jline/jline/ivy-debian.xml
debian-local-maven: no namespace defined: using system
no ivy file in cache for jline#jline;debian: tried 
/home/debian/.ivy2/cache/jline/jline/ivy-debian.xml
 trying file:/usr/share/maven-repo/jline/jline/debian/jline-debian.pom
tried 
file:/usr/share/maven-repo/jline/jline/debian/jline-debian.pom
debian-local-maven: resource not reachable for jline#jline;debian: 
res=file:/usr/share/maven-repo/jline/jline/debian/jline-debian.pom
 trying file:/usr/share/maven-repo/jline/jline/debian/jline-debian.jar
tried 
file:/usr/share/maven-repo/jline/jline/debian/jline-debian.jar
debian-local-maven: resource not reachable for jline#jline;debian: 
res=file:/usr/share/maven-repo/jline/jline/debian/jline-debian.jar
debian-local-maven: no ivy file nor artifact found for 
jline#jline;debian
WARN:   module not found: jline#jline;debian
WARN:  debian-local-maven: tried
WARN:   file:/usr/share/maven-repo/jline/jline/debian/jline-debian.pom
WARN:   -- artifact jline#jline;debian!jline.jar:
WARN:   file:/usr/share/maven-repo/jline/jline/debian/jline-debian.jar

Manually changing "debian" to "2.x" does 
the job.
Would it be correct ?

Thanks,

F.


pgpSrfZcjB1ri.pgp
Description: PGP signature

Bug#851258: RFS: rear/2.00+dfsg-2 ITP: rear -- Bare metal disaster recovery and system migration framework

[Frederic Bonnard]

Package: sponsorship-requests
Severity: normal

Dear mentors, Gianfranco,

I am looking for a sponsor for my package "rear".
This is an upgrade to previous 2.00+dfsg-1 and it fixes a FTBFS bug. Extract 
from d/changelog :

rear (2.00+dfsg-2) unstable; urgency=medium

  * d/control : move xmlto to Build-Depends, since it's needed for man
generation and man is part of the "any" part of the rear package (Closes:
#851209)

 -- Frédéric Bonnard <fre...@linux.vnet.ibm.com>  Fri, 13 Jan 2017 09:22:44 
+

---

 Package name: rear
 Version : 2.00+dfsg-2
 Upstream Author : Schlomo Schapiro, Gratien D'haese, Stefan Semmelroggen, Peer 
Heinlein, Dag Wieers, Jeroen Hoekx
 URL : https://github.com/rear/rear/
 License : GPL-3+, LGPL-2.1+, GPL-2+
 Section : admin

It builds those binary packages:

  rear  - Bare metal disaster recovery and system migration framework
  rear-doc   - Bare metal disaster recovery and system migration framework 
(documentation)

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

https://mentors.debian.net/package/rear


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

  dget -x 
https://mentors.debian.net/debian/pool/main/r/rear/rear_2.00+dfsg-2.dsc

More information about rear can be obtained from http://relax-and-recover.org/

Note:
  There is a load of Info lintians but this is due to the fact that rear embeds
  skeleton files/dirs that won't be use by the system installing rear, but
  those files will be used by the rear OS created to be booted later.


Regards,
 Frederic Bonnard



pgpIeYEDGgL0p.pgp
Description: PGP signature


pgp1JXTfcXoQM.pgp
Description: PGP signature

Bug#851209: rear: FTBFS: xmlto: Command not found

[Frederic Bonnard]

Damn, I'm really sorry about that.
My dpkg-buildpackage --build=any was good when I purged asciidoc* but
xmlto remained so failure didn't happened.
I moved xmlto to Build-Depends as well for the man generation, but kept
source-highlight to Build-Depends-Indep as it's used for html
documentation in the rear-doc "all" package.
I'll submit this today.
Thanks Aaron for your help and patience.

F.

On Thu, 12 Jan 2017 17:57:30 -0500, "Aaron M. Ucko"  wrote:
> Source: rear
> Version: 2.00+dfsg-1
> Severity: serious
> Justification: fails to build from source (but built successfully in the past)
> 
> Thanks for ensuring that automatic builds of rear can find asciidoc.
> However, it looks like they also need xmlto; please move that to the
> main Build-Depends field too.
> 
>   asciidoc -b docbook -d manpage rear.8.adoc
>   xmlto man rear.8.xml
>   make[3]: xmlto: Command not found
>   Makefile:28: recipe for target 'rear.8' failed
>   make[3]: *** [rear.8] Error 127
>   rm rear.8.xml
>   make[3]: Leaving directory '/«BUILDDIR»/rear-2.00+dfsg/doc'
>   Makefile:100: recipe for target 'man' failed
>   make[2]: *** [man] Error 2
>   make[2]: Leaving directory '/«BUILDDIR»/rear-2.00+dfsg'
>   debian/rules:13: recipe for target 'override_dh_auto_build-arch' failed
>   make[1]: *** [override_dh_auto_build-arch] Error 2
>   make[1]: Leaving directory '/«BUILDDIR»/rear-2.00+dfsg'
>   debian/rules:5: recipe for target 'build-arch' failed
>   make: *** [build-arch] Error 2
> 
> Thanks!
> 
> -- 
> Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
> http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu


pgpiIA8xVlNTP.pgp
Description: PGP signature

Bug#850918: RFS: rear/2.00+dfsg-1 ITP: rear -- Bare metal disaster recovery and system migration framework

[Frederic Bonnard]

Updated packaging :
https://mentors.debian.net/debian/pool/main/r/rear/rear_2.00+dfsg-1.dsc

Hello Andreas,
thanks for having a look at the packaging and letting me know for
asciidoc. Indeed, the move is interesting and asciidoc-base seems enough
for the generation of the documentation.

Other fixes :
- I changed d/watch because +dfsg was not correctly handled
  and a new version was detected upstream whereas it shouldn't.
- I fixed a forgotten  lintian "manpage-has-errors-from-man" caused by a
  too long line.
- I fixed accents in my name.

F.

On Wed, 11 Jan 2017 16:56:16 +0100, Andreas Henriksson <andr...@fatal.se> wrote:
> Hello Frederic Bonnard,
> 
> On Wed, Jan 11, 2017 at 09:28:19AM +0100, Frederic Bonnard wrote:
> > 
> > Package: sponsorship-requests
> > Severity: normal
> > 
> > Dear mentors, Gianfranco,
> > first best wishes to you all for this new year, health, success ;
> > especially in you Debian area :) .
> > 
> > I am looking for a sponsor for my package "rear".
> > This is an upgrade to previous 1.19 and it fixes a FTBFS bug. Extract from 
> > d/changelog :
> > 
> > rear (2.00+dfsg-1) unstable; urgency=medium
> > 
> >   * New upstream release
> >   * d/control : move asciidoc to Build-Depends (Closes: #849303)
> > 
> >  -- Frédéric Bonnard <fre...@linux.vnet.ibm.com>  Tue, 10 Jan 2017 15:12:34 
> > +0100
> [...]
> 
> Given asciidoc was recently restructured with a new package split and
> the asciidoc package itself became a meta-package shouldn't you also
> take this opportunity to switch your build-dep to something else, like
> possibly asciidoc-base?
> 
> (Not sure exactly what your needs are and which one of the asciidoc
> packages is suitable for you. The rear-doc package only seems to contain
> html files though and the asciidoc-base package description makes me
> think that's the suitable one.)
> 
> Regards,
> Andreas Henriksson
> 


pgpiNSsLtccYE.pgp
Description: PGP signature

Bug#847941: RFS: libvecpf/1.1.0-1 ITP: libvecpf -- Vector Printf Library

[Frederic Bonnard]

Hi Tobias, Gianfranco.

Tobias, Thierry agreed and I change the owner, I hope it's better now.

Any of you would have time to review the package?
I added Gianfranco as is my usual sponsor,  but I forgot to Cc him in my
initial request.
Thanks,

F.

On Mon, 19 Dec 2016 08:12:06 +0100, Tobias Frost  wrote:
> Control: tags -1 wontfix
> Control: block 806720 by -1
> 
> Hi Frederick,
> 
> the ITP is owned by Thierry Fauck, did you check with him if it is ok
> to take this ITP? (Should be done via the BTS and then the ITP's meta
> data should be corrected accordingly.
> 
> Please remove the wontfix when this has been resolved. 
> 
> --
> tobi
> 


pgpdbVfT5HPEu.pgp
Description: PGP signature

Bug#850918: RFS: rear/2.00+dfsg-1 ITP: rear -- Bare metal disaster recovery and system migration framework

[Frederic Bonnard]

Package: sponsorship-requests
Severity: normal

Dear mentors, Gianfranco,
first best wishes to you all for this new year, health, success ;
especially in you Debian area :) .

I am looking for a sponsor for my package "rear".
This is an upgrade to previous 1.19 and it fixes a FTBFS bug. Extract from 
d/changelog :

rear (2.00+dfsg-1) unstable; urgency=medium

  * New upstream release
  * d/control : move asciidoc to Build-Depends (Closes: #849303)

 -- Frédéric Bonnard <fre...@linux.vnet.ibm.com>  Tue, 10 Jan 2017 15:12:34 
+0100

---

 Package name: rear
 Version : 2.00+dfsg-1
 Upstream Author : Schlomo Schapiro, Gratien D'haese, Stefan Semmelroggen, Peer 
Heinlein, Dag Wieers, Jeroen Hoekx
 URL : https://github.com/rear/rear/
 License : GPL-3+, LGPL-2.1+, GPL-2+
 Section : admin

It builds those binary packages:

  rear  - Bare metal disaster recovery and system migration framework
  rear-doc   - Bare metal disaster recovery and system migration framework 
(documentation)

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

https://mentors.debian.net/package/rear


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

  dget -x 
https://mentors.debian.net/debian/pool/main/r/rear/rear_2.00+dfsg-1.dsc

More information about rear can be obtained from http://relax-and-recover.org/

Note:
  There is a load of Info lintians but this is due to the fact that rear embeds
  skeleton files/dirs that won't be use by the system installing rear, but
  those files will be used by the rear OS created to be booted later.


Regards,
 Frederic Bonnard



pgpAZPxXp0vRJ.pgp
Description: PGP signature

Bug#848233: sphde FTBFS on mips and mipsel: missing mips32 support

[Frederic Bonnard]

Hello Radovan,
patches you provided for this bug and #844613 have been applied
upstream.
If you don't mind, I'll ask a new release to sphde team to have support
for mips* and I'll update the packaging with your pie patch.
Thanks a lot for all the work you did on mips*,

F.

On Thu, 15 Dec 2016 13:28:09 +, Radovan Birdic  
wrote:
> Package: sphde
> Version: 1.3.0-1
> Severity: important
> Tags: sid + patch
> Justification: FTBFS
> User: debian-m...@lists.debian.org
> Usertags: mips-patch
> 
> 
> Package sphde_1.3.0-1 FTBFS on mips and mipsel with following error:
> 
> > /usr/bin/ld: /usr/lib/gcc/mipsel-linux-gnu/6/crtbeginT.o: relocation 
> > R_MIPS_HI16 against `a local symbol' can not be used when making a shared 
> > object; recompile with -fPIC
> > /usr/lib/gcc/mipsel-linux-gnu/6/crtbeginT.o: error adding symbols: Bad value
> > collect2: error: ld returned 1 exit status
> 
> Full build log:
> https://buildd.debian.org/status/fetch.php?pkg=sphde=mipsel=1.3.0-1=1473250605
> 
> First, we need to remove "-pie" flag from LDFLAGS (for mips and mipsel 
> arches) to reslove mentioned error.
> After that, build fails because there is no support for mips32 architecture.
> We need to define proper addresses (__SAS_BASE_ADDRESS, RegionSize, 
> SegmentSize and __SAS_SHMAP_MAX) for mips/mipsel into "sasconf.h" file.
> 
> I have created and attached a patches that includes these changes and 
> resolves these issues.
> Patch remove-pie-for-mips32.patch removes "pie" flag from LDFLAGS for 
> mips/mipsel.
> Patch add-mips32-support.patch adds support for mips/mipsel architectures.
> 
> Note:
> First it is necessary to apply the patch I have proposed here:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844613
> 
> 
> With these patches package builds successfully.
> 
> Regards,
> Radovan> --- sphde-1.3.0_orig/debian/rules2016-08-31 12:40:30.0 
> +
> +++ sphde-1.3.0/debian/rules  2016-12-15 09:07:47.0 +
> @@ -7,6 +7,11 @@ ifeq ($(shell dpkg-architecture -qDEB_HO
>   export DEB_LDFLAGS_MAINT_STRIP = -pie
>  endif
>  
> +ifneq (,$(filter $(shell dpkg-architecture -qDEB_HOST_ARCH),mips mipsel))
> + export DEB_LDFLAGS_MAINT_STRIP = -pie
> +endif
> +
> +
>  %:
>   dh $@  --with autoreconf,pkgkde_symbolshelper
>  
> --- sphde-1.3.0.orig/src/sasconf.h
> +++ sphde-1.3.0/src/sasconf.h
> @@ -86,6 +86,13 @@
>  # define __SAS_SHMAP_MAX 0x000100L   /*  16MB */
>  #endif
>  
> +#ifdef __mips__
> +# define __SAS_BASE_ADDRESS  0x6000UL/* 1,5GB */
> +# define RegionSize  0x1000UL/* 256MB */
> +# define SegmentSize 0x0100UL/*  16MB */
> +# define __SAS_SHMAP_MAX 0x0100UL/*  16MB */
> +#endif
> +
>  /* 
>   * If the platform is not recognized above, select some resonable default.
>   */

Bug#848128: RFS: rear/1.19-1 ITP: rear -- Bare metal disaster recovery and system migration framework

[Frederic Bonnard]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "rear". Previous RFS was
sponsored but got rejected by ftpmasters because one file was not DFSG
compliant (this documentation file was removed in current packaging and
source code was repacked without it).

 Package name: rear
 Version : 1.19-1
 Upstream Author : Schlomo Schapiro, Gratien D'haese, Stefan Semmelroggen, Peer 
Heinlein, Dag Wieers, Jeroen Hoekx
 URL : https://github.com/rear/rear/
 License : GPL-3+, LGPL-2.1+, GPL-2+
 Section : admin

It builds those binary packages:

  rear  - Bare metal disaster recovery and system migration framework
  rear-doc   - Bare metal disaster recovery and system migration framework 
(documentation)

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

https://mentors.debian.net/package/rear


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

  dget -x 
https://mentors.debian.net/debian/pool/main/r/rear/rear_1.19+dfsg-1.dsc

More information about rear can be obtained from http://relax-and-recover.org/

Note:
  There is a load of Info lintians but this is due to the fact that rear embeds
  skeleton files/dirs that won't be use by the system installing rear, but
  those files will be used by the rear OS created to be booted later.


Regards,
 Frederic Bonnard

Bug#847941: RFS: libvecpf/1.1.0-1 ITP: libvecpf -- Vector Printf Library

[Frederic Bonnard]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "libvecpf"

 Package name: libvecpf
 Version : 1.1.0-1
 Upstream Author : libvecpf team
 URL : https://github.com/Libvecpf/libvecpf
 License : LGPL-2.1+, GPL-3+ with Autoconf exception, 
GNU-All-Permissive-License, GPL-2+
 Section : admin

It builds those binary packages:

  libvecpf-dev - Vector Printf Library development files
  libvecpf1  - Vector Printf Library

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

https://mentors.debian.net/package/libvecpf


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

  dget -x 
https://mentors.debian.net/debian/pool/main/libv/libvecpf/libvecpf_1.1.0-1.dsc

More information about libvecpf can be obtained from 
https://github.com/Libvecpf/libvecpf

Note:
  This package  is for powerpc, ppc64  and ppc64el only as  it may print
  out vector data types related to Altivec.


Regards,
 Frederic Bonnard

Bug#847105:

[Frederic Bonnard]

Hi guys,
also, Lucio, do you do your builds in clean schroots?
In a new schroot, you'll be in the same condition as people trying to
build your packages. Once you build a package once, you can re-run
dpkg-buildpackage to be sure, you handle correctly rebuild in the same
directory.
Also for lintian, you can use this command :
$ lintian --info --display-info --display-experimental --pedantic 
--show-overrides  --color auto


F.

On Fri, 09 Dec 2016 09:48:42 -0200, Breno Leitao  wrote:
> Hello Lucio,
> 
> Thanks for submitting the package to Debian, but I still see major lintian
> errors on the package you submit.
> 
> Please address, at least, error and warnings lintian erros. These are
> important before asking for sponsorship.
> 
> Closing the pedantic bugs is a plus. :-)
> 
> Also, it seems to be generating a key during the build? Why do you need a key
> generated during the build?
> 
> It seems also that the package is not built using dpkg-buildpackage, but
> being build with debuild. That is weird, and I didn't investigated why.
> Enabling it to build with dpkg-buildpackage is also crucial.
> 
> This is the problem I am having:
> 
>   rm -f en_US.gmo && /usr/bin/msgfmt -c --statistics --verbose -o en_US.gmo
>  en_US.po
>   pt_BR.po: 1 translated message.
>   zh_CN.po: 1 translated message.
>   zh_CN.po: 1 translated message.
>   mv: cannot stat 't-zh_CN.gmo': No such file or directory
>   Makefile:128: recipe for target 'zh_CN.gmo' failed
> 
> Weird enough, this file t-zh_CN.gmo does not exists, neither any reference
> for it.
> 
> PS: Please keep this RFS opened, and we will track the package progress by
> this RFS.
> 
> Thank you,
> Breno
> 

Bug#639910: Packaging sbt

[Frederic Bonnard]

On Thu, 8 Dec 2016 23:16:52 +0100, Emmanuel Bourg <ebo...@apache.org> wrote:
> Le 18/11/2016 à 14:41, Frederic Bonnard a écrit :
> 
> Hi Frederic,
> 
> > There is much  work to finalize this  if that is ok,  but indeed, before
> > continuing I'd like to know if I'm on the good path.
> 
> This looks like a valid approach. Did you use Scala 2.10 or 2.11 for
> compiling SBT?

I used scala 2.11 as it's the one available in unstable.

> If you have a working SBT package I suggest uploading it
> now to experimental/non-free, this will enable others to jump in and
> help with the dependencies.

Well, that's where I'm unsure.
I packaged in a functional manner all the sbt components I listed above,
meaning, that it would need further work (on control/copyright/...etc files).
This was a POC and functionally speaking, that seems to work.
Now if the approach I followed is valid according to Debian policy, I'll
do things properly to push sbt and that minimal set of dependencies in 
experimental.
I don't think it would be ok to do a binary upload. My idea was to do a
full clean source upload, right ?
If so, I'll focus on the coming days/weeks to provide all this.

F.

Bug#639910: Packaging sbt

[Frederic Bonnard]

Hi Marko and thanks for answering :)

> Sorry, I didn't try to understand the details of your latest effort, but
> just to give you a heads up - I was/have been working on packaging SBT
> too.

No problem with that, that may not be trivial and well explained 

> A couple of months ago or so I started reviving the effort to get SBT
> into Debian:
> 
> https://osdir.com/ml/general/2016-10/msg31364.html

great to see enthusiast people

> In a nutshell, Emmanuel packaged Scala 2.10 because it's a dependency
> for SBT, and the scala package moved to 2.11.8 in the meantime. Me being
> a newbie wrt Debian packaging had a hard time using it in the form he
> made it available in (it is not in the official Debian repos, but in a
> Java Debian team repo) to continue working on packaging SBT, and due to
> me being busy at school and overwhelmed with issues in packaging SBT, I
> silently drifted away.
> 
> Nevertheless, it'd be great if there was a group of us and if we could
> dust this effort off and make more progress.
> 
> I don't know if it's just me, but I find it hard to contribute in the
> current setting - there are just so many things to do to package SBT,
> there is so much I don't know about, then what is probably a simple and
> quick task for experienced developers takes a whole eternity for me, and
> I have a feeling as if most of the time I'm just moving around with a
> blindfold over my eyes. This is not to say I don't appreciate what
> others have helped with (it was mostly Emmanuel); I do appreciate it!

It's not just you. 
Packaging, debian policy, scala, java world etc... each is a specific
world that needs knowledge, and all of this together is needed for this
sbt bootstrap task.
Add to this random availibility to learn because of life and the
"project" won't progress fast :-/

> The way I see it, it would be most effective if we made a clear list of
> things to do, splitted it into small tasks, and then a few of us got
> together online (e.g., IRC) and worked on this for a couple of hours. Of
> course, with someone experienced on board to guide those of us that are
> less experienced.

This is only my opinion, but I think the core bootstrapping may not be
the easiest way to learn packaging.
Though, if we take what I've started to do, we may be able to split
things and find newbie friendly subtasks. It's just that defining
adapted task is also some work and I may be short of time, especially
with Christmas coming.
Given the feedback that Emmanuel (or any other experienced Debianist) will give,
I'll try to spend some time to define easy subtasks.

F.

> 
> -- 
> Regards,
> Marko Dimjašević 
> https://dimjasevic.net/marko  PGP key ID: 1503F0AA
> Learn email self-defense! https://emailselfdefense.fsf.org

Bug#639910: Packaging sbt

[Frederic Bonnard]

Sorry to ping you on that again.
Any one having feedback on the validity of that bootstrap process ? Mehdi ? 
Emmanuel ? :)
Thanks,

F.

On Fri, 18 Nov 2016 14:41:27 +0100, Frederic Bonnard 
<fre...@linux.vnet.ibm.com> wrote:
> Hello Mehdi/Emmanuel/all,
> back on that topic,  I did some work and would need  your feedback on it
> before going further.
> 
> What Mehdi said in his last comment, inspired me the following :
> 
> For sbt source package, I created 4 "sources" tarball :
> 1. sbt_0.13.13~RC1.orig.tar.gz : this is  the upstream source release of
> sbt : https://github.com/sbt/sbt
> 2. sbt_0.13.13~RC1.orig-bootstrapsbt.tar.xz : this is the binary (mainly
> sbt-launch.jar)  of the  previous sbt  version,  in our  case :  0.13.12
> previous
> 3. sbt_0.13.13~RC1.orig-bootstrapdeps.tar.xz  : these  are all  the jars
> that sbt 0.13.12 binary would fetch when running against that particular
> project.
> 4.  sbt_0.13.13~RC1.orig-launcher.tar.xz  :  additional source  for  the
> launcher : https://github.com/sbt/sbt-launcher-packag  e
> 
> 1 and 4 are simply the tarballs from upstream projects.
> 2 and 3 are created from debian/rules get-orig-source target.
> 2  is the  binary tarball  that upstream  already provides,  but it's  a
> "minimal" sbt  without all the  jars needed to  run. At launch  time, it
> would detect that and will fetch all them.
> For 3, I use the sbt binary of  2, to fetch all the jars it needs online
> and I build a tarball from that.
> This enables  to build the  source of  the project offline  (forcing it)
> with all needed jars.
> 
> The point is  that the sbt package  I built is "nude". If  I install the
> package built, the  0.13.13~RC1 version of sbt would need  a minimal set
> of jars that is  missing (in the same way of 2)  and "sbt" command would
> fail.
> So I did the  same for all the dependencies needed  by this minimal sbt,
> so that running "sbt" from the command line won't complain.
> That is, for all dependencies that are  not already in Debian, I built a
> package and as most of them (if not all if I remember) are sbt projects,
> I  did that  3-tarball-source,  with the  upstream  project, a  prebuild
> 0.13.12 minimal binary sbt and a tarball of binary jars dependencies for
> the latter.
> This enabled to build packages for :
>   https://github.com/bmc/classutil
>   https://github.com/bmc/grizzled-scala
>   https://github.com/bmc/scalasti
>   https://github.com/foundweekends/giter8
>   https://github.com/non/jawn
>   https://github.com/json4s/json4s
>   https://github.com/sbt/serialization
>   https://github.com/sbt/test-interface
>   https://github.com/scala/pickling
>   https://github.com/harrah/sbinary
>   https://github.com/scopt/scopt
> and have a working sbt command  line without connecting online but using
> Debian's local maven-repo.
> 
> There is much  work to finalize this  if that is ok,  but indeed, before
> continuing I'd like to know if I'm on the good path.
> 
> F.
> 
> On Wed, 6 Jan 2016 01:58:13 +0100, Mehdi Dogguy <me...@dogguy.org> wrote:
> > Hi,
> > 
> > On 05/01/2016 16:32, Emmanuel Bourg wrote:
> > > The "easiest" solution is probably to start with a non-free sbt package
> > > containing a prebuilt version of sbt, and then upload in main a sbt
> > > package depending on itself with the prebuilt sbt removed. I would use
> > > only one sbt package, instead of sbt-bootstrap in non-free and sbt in 
> > > main.
> > > 
> > 
> > Note that you can very much include a working sbt binary in the source
> > package and use it the bootstrap sbt. The only condition that we must
> > respect is to not ship that binary in the package, but ship the built
> > binary only. This is done for many packages: OCaml for its bootstrap
> > and most probably ghc (didn't check tbh). Also, compiling gcc requires
> > a gcc. :-P
> > 
> > My 2 cents,
> > 
> > -- 
> > Mehdi
> > 

Bug#836983: arm64 too

[Frederic Bonnard]

Just for the record, this bug also happens on arm64.
This seems to be a regression. I'm trying to bisect that.


F.

Bug#845647: Missing file /usr/share/javascript/jquery-ui/ui/i18n/jquery-ui-i18n.js

[Frederic Bonnard]

Source: jqueryui
Source-Version: 1.12.1+dfsg-1
Tags: patch

--

Hi,
this file used to exist in 1.10.1+dfsg-1 but it disappeared in 1.12.1+dfsg-1.
Is that something expected ?
https://packages.debian.org/jessie/all/libjs-jquery-ui/filelist
https://packages.debian.org/sid/all/libjs-jquery-ui/filelist
There is .js and .min.js for each language but not a global one (and a
minified version of a global one). See also :
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720556#10
Did I miss something ?
Thanks,

F.

Bug#781530: Importing libdfp into Debian

[Frederic Bonnard]

> Yes, I can reupload libdfp from ubuntu into debian and close this ITP.

That would be nice, thanks.

> Do you want to still be listed as the maintainer/uploader?

Actually, I was not listed as such so far :)

> I'm not making commitments to maintain this in Debian longer term =)

If you add me as maintainer, I can take care of that.

F.

Bug#781530: Importing libdfp into Debian

[Frederic Bonnard]

Dimitri,
I see you are the latest maintainer having worked on libdfp.
Would you have some time to import libdfp from Ubuntu to Debian ?
If not, would you mind I do that ?
Regards,

F.

Bug#844613: sphde FTBFS on mips64el: error: missing mip64 support

[Frederic Bonnard]

Thanks a lot Radovan,
I've let the upstream know about your patch.

F.

On Thu, 17 Nov 2016 15:55:43 +, Radovan Birdic  
wrote:
> Package: sphde
> Version: 1.3.0-1
> Severity: important
> Tags: sid + patch
> Justification: FTBFS
> User: debian-m...@lists.debian.org
> Usertags: mips-patch
> 
> 
> Package sphde_1.3.0-1 FTBFS on mips64el with following error:
> 
> > In file included from tests/sasindex_t.c:22:0:
> > tests/sasindex_t.c: In function 'sassim_index_test2':
> > ./sasindexkey.h:222:17: error: 'key_val.key_element.data_0' may be used 
> > uninitialized in this function [-Werror=maybe-uninitialized]
> >dest->data[0] = key_val.key_element.data_0;
> 
> Full build log:
> https://buildd.debian.org/status/fetch.php?pkg=sphde=mips64el=1.3.0-1=1473264403
> 
> Build fails because there is no support for mips64 architecture.
> We need to change sasconf.h and sassim.cpp files, to define addresses and to 
> adjust struct logNodeType for mips64 arch.
> 
> I have created and attached a patch that includes these changes and resolves 
> this issue.
> With this patch package builds successfully.
> 
> Regards,
> Radovan> --- sphde-1.3.0.orig/src/sasconf.h
> +++ sphde-1.3.0/src/sasconf.h
> @@ -78,6 +78,14 @@
>  # define __SAS_SHMAP_MAX 0x040L   /* 4MB */
>  #endif
>  
> +#ifdef __mips64
> +# define __WORDSIZE_64
> +# define __SAS_BASE_ADDRESS  0x40L   /* 256GB */
> +# define RegionSize  0x20L   /* 128GB */
> +# define SegmentSize 0x001000L   /* 256MB */
> +# define __SAS_SHMAP_MAX 0x000100L   /*  16MB */
> +#endif
> +
>  /* 
>   * If the platform is not recognized above, select some resonable default.
>   */
> --- sphde-1.3.0.orig/src/sassim.cpp
> +++ sphde-1.3.0/src/sassim.cpp
> @@ -119,7 +119,8 @@ typedef struct
>  {
>  #ifdef __WORDSIZE_64
>  #if defined (__x86_64__) || \
> -(defined (__LITTLE_ENDIAN__) && defined (__powerpc64__))
> +(defined (__LITTLE_ENDIAN__) && defined (__powerpc64__)) \
> +|| ((__BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__) && defined(__mips64)) 
>unsigned long offset:56;
>unsigned int size:8;
>  #else

Bug#639910: Packaging sbt

[Frederic Bonnard]

Hello Mehdi/Emmanuel/all,
back on that topic,  I did some work and would need  your feedback on it
before going further.

What Mehdi said in his last comment, inspired me the following :

For sbt source package, I created 4 "sources" tarball :
1. sbt_0.13.13~RC1.orig.tar.gz : this is  the upstream source release of
sbt : https://github.com/sbt/sbt
2. sbt_0.13.13~RC1.orig-bootstrapsbt.tar.xz : this is the binary (mainly
sbt-launch.jar)  of the  previous sbt  version,  in our  case :  0.13.12
previous
3. sbt_0.13.13~RC1.orig-bootstrapdeps.tar.xz  : these  are all  the jars
that sbt 0.13.12 binary would fetch when running against that particular
project.
4.  sbt_0.13.13~RC1.orig-launcher.tar.xz  :  additional source  for  the
launcher : https://github.com/sbt/sbt-launcher-packag  e

1 and 4 are simply the tarballs from upstream projects.
2 and 3 are created from debian/rules get-orig-source target.
2  is the  binary tarball  that upstream  already provides,  but it's  a
"minimal" sbt  without all the  jars needed to  run. At launch  time, it
would detect that and will fetch all them.
For 3, I use the sbt binary of  2, to fetch all the jars it needs online
and I build a tarball from that.
This enables  to build the  source of  the project offline  (forcing it)
with all needed jars.

The point is  that the sbt package  I built is "nude". If  I install the
package built, the  0.13.13~RC1 version of sbt would need  a minimal set
of jars that is  missing (in the same way of 2)  and "sbt" command would
fail.
So I did the  same for all the dependencies needed  by this minimal sbt,
so that running "sbt" from the command line won't complain.
That is, for all dependencies that are  not already in Debian, I built a
package and as most of them (if not all if I remember) are sbt projects,
I  did that  3-tarball-source,  with the  upstream  project, a  prebuild
0.13.12 minimal binary sbt and a tarball of binary jars dependencies for
the latter.
This enabled to build packages for :
  https://github.com/bmc/classutil
  https://github.com/bmc/grizzled-scala
  https://github.com/bmc/scalasti
  https://github.com/foundweekends/giter8
  https://github.com/non/jawn
  https://github.com/json4s/json4s
  https://github.com/sbt/serialization
  https://github.com/sbt/test-interface
  https://github.com/scala/pickling
  https://github.com/harrah/sbinary
  https://github.com/scopt/scopt
and have a working sbt command  line without connecting online but using
Debian's local maven-repo.

There is much  work to finalize this  if that is ok,  but indeed, before
continuing I'd like to know if I'm on the good path.

F.

On Wed, 6 Jan 2016 01:58:13 +0100, Mehdi Dogguy  wrote:
> Hi,
> 
> On 05/01/2016 16:32, Emmanuel Bourg wrote:
> > The "easiest" solution is probably to start with a non-free sbt package
> > containing a prebuilt version of sbt, and then upload in main a sbt
> > package depending on itself with the prebuilt sbt removed. I would use
> > only one sbt package, instead of sbt-bootstrap in non-free and sbt in main.
> > 
> 
> Note that you can very much include a working sbt binary in the source
> package and use it the bootstrap sbt. The only condition that we must
> respect is to not ship that binary in the package, but ship the built
> binary only. This is done for many packages: OCaml for its bootstrap
> and most probably ghc (didn't check tbh). Also, compiling gcc requires
> a gcc. :-P
> 
> My 2 cents,
> 
> -- 
> Mehdi
> 

Bug#837476: RFS: willow/0.3.1-1 [ITP #837471]

[Frederic Bonnard]

Hi Christopher,

> I've asked upstream for clarification [0]. If there isn't a
> satisfactory answer I could either exclude these images and the
> associated tests or provide alternative images for the tests.

Thanks for forwarding the issue to recurser/exif-orientation-examples :
https://github.com/recurser/exif-orientation-examples/issues/4
Let's see what they say.

> Some of the functionality, e.g. face detection, depends on OpenCV.
> OpenCV has only recently added support for Python 3, and this has not
> yet been packaged for Debian (even the python-opencv package in
> Experimental still seems to be for Python 2). So I could provide a
> python3 package, but it seemed better to wait for a python3-opencv
> package to become available.

Ok, good, thanks for the details!

F.

Bug#838870: RFS: nbsphinx/0.2.9+ds-1 [ITP] -- Jupyter Notebook Tools for Sphinx

[Frederic Bonnard]

Thanks Benoit for all the documentation work.
The package looks good to me.
Good catch for the audio link ; indeed lintian does not seem to handle 
element (I sent a patch : https://bugs.debian.org/840009 )

As a side node, I'd advise you consider (report from check-all-the-things tool) 
:
- adding some upstream metadata: https://wiki.debian.org/UpstreamMetadata
- asking upstream to sign their release (debian-watch-may-check-gpg-signature)
  : https://wiki.debian.org/Creating%20signed%20GitHub%20releases
I still have to follow those advises for my packages :)

F.

On Fri, 7 Oct 2016 00:58:08 +0100, Jerome BENOIT <calcu...@rezozer.net> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Hello,
> 
> On 05/10/16 13:26, Frederic Bonnard wrote:
> > Thanks Benoit/Ghislain,
> > indeed with experimental archive it's much better :)
> > 
> > Benoit,
> > my last point would be about privacy-breach-generic lintian.
> > You overrided it with :
> > --
> > N: The involved links are meant to illustrate URL examples, so it is 
> > meaningless
> > N: to bring the involved material in a local folder.
> > --
> > 
> > I agree that bringing stuff locally (as it is advised in the lintian
> > description) is useless when the goal is to show the code for how to embed
> > content of remote images/videos URLs.
> > Though I still think there's a breach, as loading the documentation makes 
> > your
> > browser connect to the internet, load images but also javascripts and so 
> > on, which
> > is originally the reason of this lintian definition (or let me know if I'm 
> > wrong).
> > Even if you point to DFSG-free ressources, you'll have your browser that 
> > will still
> > connect outside, and that's the issue in my understanding.
> > 
> > I've been thinking about this and reading your discussion with Paul Wise,
> > I came to the following idea : why not changing after generation the html 
> > (sed...) :
> > 
> > For images :
> > ---
> > -https://www.python.org/static/img/python-logo-large.png"/>
> > +https://www.python.org/static/img/python-logo-large.png should be 
> > displayed, but it got removed because of 
> > https://lintian.debian.org/tags/privacy-breach-generic.html.;
> > ---
> > 
> > and for the embedded video :
> > 
> > ---
> >   >  width="400"
> >  height="300"
> > -src="https://www.youtube.com/embed/WAikxUGbomY;
> > +src="about:blank"
> >  frameborder="0"
> >  allowfullscreen
> > +srcdoc="This video : https://www.youtube.com/embed/WAikxUGbomY should 
> > be displayed, but it got removed because of 
> > https://lintian.debian.org/tags/privacy-breach-generic.html.;
> >  >
> > ---
> > 
> > That way, you'll keep the source code example clean, and despite the fact 
> > the html
> > is modified, the user reading the documentation will still understand the 
> > example, what
> > it should do, what is displayed and altered and why.
> > Ok the documentation html code is modified but the goal of the doc is to get
> > the idea of the use (source code) and visual result (rather than html 
> > output that got modified)
> > I also thought of playing with Content-Security-Policy in  of the 
> > document to block
> > all outside connections but, I'm not sure all browser implement this 
> > correctly.
> > It's also less understable for the reader to understand why things 
> > disappeared (except
> > if this "framework" have information facilities). But it would be very good 
> > to fix
> > all the privacy-breach-generic in a general manner.
> 
> 
> When I wrote the lintian override, I have in mind beside the HTML output the 
> ipynb input,
> only the former is taken into account by lintian.
> Meanwhile, I relized that lintian was not able to point out an audio 
> privacy-breatch..
> 
> Anyway, I brought the suggested material. The hard part was the refreshment 
> of the debian/copyright file:
> it is getting large.
> 
> I hope the package is fine now.
> 
> Thanks,
> Jerome
> 
> 
> 
> > 
> > 
> > F.
> > 
> 
> - -- 
> Jerome BENOIT | calculus+at-rezozer^dot*net
> https://qa.debian.org/developer.php?login=calcu...@rezozer.net
> AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B
> -BEGIN PGP SIGNATURE-
> 
> iQQcBAEBCgAGBQJX9uUQAAoJED+SGaZ/NsaL7W8f/i7CCIYZzleqbHqaCn1Hhz7V
> rCfXDVGuIfVsYoRQrFZX/w7DMOX6teiwwlOTiD4kwZc8YcwX+4E+ZkaHx4zCvqii
> QqFIXUWiVgJ+Z0+ZMdMi1X+ef708K5M/92iAKWBPFp6F

Bug#840009: [PATCH] lintian : privacy-breach-generic support for

[Frederic Bonnard]

Package: lintian
Version: 2.5.48
Tags: patch

--

Dear maintainer,

it seems lintian does not currently detect privacy breaches within  
element
; Jerome Benoit noticed that in #838870.
Could you confirm and review the attached patch ?
Thank you,

F.
diff -Nru lintian-2.5.48/data/files/privacy-breaker-tag-attr lintian-2.5.48/data/files/privacy-breaker-tag-attr
--- lintian-2.5.48/data/files/privacy-breaker-tag-attr	2016-09-25 18:21:57.0 +
+++ lintian-2.5.48/data/files/privacy-breaker-tag-attr	2016-10-04 19:37:17.0 +
@@ -19,3 +19,4 @@
 track~~ src="http   && ]+)? \s+ src="()" [^>]*>)
 video src=   ~~ src="http   && ]+)? \s+ src="()" [^>]*>)
 video poster=~~ poster="http&& ]+)? \s+ poster="()" [^>]*>)
+audio~~ src="http   && ]+)? \s+ src="()" [^>]*>)
diff -Nru lintian-2.5.48/t/tests/files-privacybreach/debian/src/privacy-breach-generic/audio.html lintian-2.5.48/t/tests/files-privacybreach/debian/src/privacy-breach-generic/audio.html
--- lintian-2.5.48/t/tests/files-privacybreach/debian/src/privacy-breach-generic/audio.html	1970-01-01 00:00:00.0 +
+++ lintian-2.5.48/t/tests/files-privacybreach/debian/src/privacy-breach-generic/audio.html	2016-10-04 19:37:17.0 +
@@ -0,0 +1,7 @@
+
+
+
+ftp://1984.os/tuxistrackingme.ogg; />
+
+
+
diff -Nru lintian-2.5.48/t/tests/files-privacybreach/debian/src/privacy-breach-generic/audiotrack.html lintian-2.5.48/t/tests/files-privacybreach/debian/src/privacy-breach-generic/audiotrack.html
--- lintian-2.5.48/t/tests/files-privacybreach/debian/src/privacy-breach-generic/audiotrack.html	1970-01-01 00:00:00.0 +
+++ lintian-2.5.48/t/tests/files-privacybreach/debian/src/privacy-breach-generic/audiotrack.html	2016-10-04 19:37:17.0 +
@@ -0,0 +1,11 @@
+
+
+
+
+  
+  
+  
+  http://1984.os/notracking.vtt; kind="captions" srclang="no" label="Norwegian">
+
+
+
diff -Nru lintian-2.5.48/t/tests/files-privacybreach/tags lintian-2.5.48/t/tests/files-privacybreach/tags
--- lintian-2.5.48/t/tests/files-privacybreach/tags	2016-09-25 18:22:03.0 +
+++ lintian-2.5.48/t/tests/files-privacybreach/tags	2016-10-04 19:37:17.0 +
@@ -53,6 +53,8 @@
 E: files-privacybreach: privacy-breach-w3c-valid-html usr/share/files-privacy-breach/privacy-breach-w3c-valid-html/htmlvalid.html (http://www.w3.org/icons/valid-xhtml10)
 X: files-privacybreach: privacy-breach-generic usr/share/files-privacy-breach/privacy-breach-generic/applet.html (//1984.os/trackme2)
 X: files-privacybreach: privacy-breach-generic usr/share/files-privacy-breach/privacy-breach-generic/applet.html (http://1984.os/trackme)
+X: files-privacybreach: privacy-breach-generic usr/share/files-privacy-breach/privacy-breach-generic/audio.html (ftp://1984.os/tuxistrackingme.ogg)
+X: files-privacybreach: privacy-breach-generic usr/share/files-privacy-breach/privacy-breach-generic/audiotrack.html (http://1984.os/notracking.vtt)
 X: files-privacybreach: privacy-breach-generic usr/share/files-privacy-breach/privacy-breach-generic/div.html (//trackme.1984/index-3.html)
 X: files-privacybreach: privacy-breach-generic usr/share/files-privacy-breach/privacy-breach-generic/div.html (http://trackme.1984/index-2.html)
 X: files-privacybreach: privacy-breach-generic usr/share/files-privacy-breach/privacy-breach-generic/embed.html (//1984.os/givemydata2.swf)

Bug#837476: RFS: willow/0.3.1-1 [ITP #837471]

[Frederic Bonnard]

Hello Christopher,

- d/copyright :
  * "Source: https://github.com/torchbox/Willow/archive/v0.3.1.tar.gz; : you
should point to the URL of the project rather than the versionned tarball
itself, I guess.
  * identify -verbose  ./tests/images/orientation/landscape_4.jpg|grep -i copy
   icc:copyright: Copyright 2007 Apple Inc., all rights reserved.
Several other images have such exif data.
Maybe you can check with upstream about the entire directory.
- d/control : why not providing python3 package ?
  https://www.debian.org/doc/packaging-manuals/python-policy/ch-python3.html
- d/rules : * you can discard comments added by the generator
- lintians : for Informational "vcs-field-uses-insecure-uri" : "Note that you 
can
  often just exchange e.g. git:// with https:// for repositories."


F.

Bug#838495: RFS: python-cartopy/0.14.2-1 [ITP]

[Frederic Bonnard]

Hi Ghislain,

- d/copyright:
 * based on the headers, I think it's LGPL-3+ rather than LGPL-3
 * I see several binary files such images and dataset in the source :
   a) lib/cartopy/data/netcdf/HadISST1_SST_update.nc : according to
   lib/cartopy/data/netcdf/HadISST1_SST_update.README.txt, I found that
   licensing info :
   http://www.metoffice.gov.uk/hadobs/hadcruh/licence_ncgl.html which points to
   : 
http://www.nationalarchives.gov.uk/doc/non-commercial-government-licence/non-commercial-government-licence.htm
   which seems non free (Non Commercial)
   b) lib/cartopy/data/raster/sample/Miriam.A2012270.2050.2km.jpg has this
   readme : lib/cartopy/data/raster/sample/Miriam.A2012270.2050.2km.README.txt 
; I
   didn't find on http://lance-modis.eosdis.nasa.gov licensing infos.
   c) there's various png in lib/cartopy/tests/mpl/baseline_images and I was
   wondering also about the origin in spite of the global licensing.
   
   Are all those files mandatory? maybe stripping source would help? For c)
   tests/mpl/ is skipped anyway for now, right ?  I don't know for a) and b)
- d/rules:
 * informational lintian hardening-no-bindnow : you should enable hardening
   "all" (https://wiki.debian.org/Hardening/PIEByDefaultTransition
   , https://wiki.debian.org/Hardening). I noted that pie makes compilation
   fail, but adding :
   export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-pie
   does the job.
 * pedantic image-file-in-usr-lib : the importance of this one has been lowered
   since 3.9.6.0 . I don't know if it's much work to move arch independent
   files in /usr/share.

F.

Bug#838870: RFS: nbsphinx/0.2.9+ds-1 [ITP] -- Jupyter Notebook Tools for Sphinx

[Frederic Bonnard]

Thanks Benoit/Ghislain,
indeed with experimental archive it's much better :)

Benoit,
my last point would be about privacy-breach-generic lintian.
You overrided it with :
--
N: The involved links are meant to illustrate URL examples, so it is meaningless
N: to bring the involved material in a local folder.
--

I agree that bringing stuff locally (as it is advised in the lintian
description) is useless when the goal is to show the code for how to embed
content of remote images/videos URLs.
Though I still think there's a breach, as loading the documentation makes your
browser connect to the internet, load images but also javascripts and so on, 
which
is originally the reason of this lintian definition (or let me know if I'm 
wrong).
Even if you point to DFSG-free ressources, you'll have your browser that will 
still
connect outside, and that's the issue in my understanding.

I've been thinking about this and reading your discussion with Paul Wise,
I came to the following idea : why not changing after generation the html 
(sed...) :

For images :
---
-https://www.python.org/static/img/python-logo-large.png"/>
+https://www.python.org/static/img/python-logo-large.png should be displayed, 
but it got removed because of 
https://lintian.debian.org/tags/privacy-breach-generic.html.;
---

and for the embedded video :

---
 https://www.youtube.com/embed/WAikxUGbomY;
+src="about:blank"
 frameborder="0"
 allowfullscreen
+srcdoc="This video : https://www.youtube.com/embed/WAikxUGbomY should be 
displayed, but it got removed because of 
https://lintian.debian.org/tags/privacy-breach-generic.html.;
 >
---

That way, you'll keep the source code example clean, and despite the fact the 
html
is modified, the user reading the documentation will still understand the 
example, what
it should do, what is displayed and altered and why.
Ok the documentation html code is modified but the goal of the doc is to get
the idea of the use (source code) and visual result (rather than html output 
that got modified)
I also thought of playing with Content-Security-Policy in  of the 
document to block
all outside connections but, I'm not sure all browser implement this correctly.
It's also less understable for the reader to understand why things disappeared 
(except
if this "framework" have information facilities). But it would be very good to 
fix
all the privacy-breach-generic in a general manner.


F.

Bug#838870: RFS: nbsphinx/0.2.9+ds-1 [ITP] -- Jupyter Notebook Tools for Sphinx

[Frederic Bonnard]

Hi Jerome,

- d/control :
  * could you sort de dependencies : wrap-and-sort can help
  * by using github source tarball, you wouldn't have to deal with
suffix and get-orig-source stuff : nbsphinx.egg-info and setup.cfg are
already stripped
- d/copyright : "There are many versions of the MIT license. Please use Expat
  instead, when it matches."
  https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
- d/rules :
  * could you use $(CURDIR) instead of relative paths ?
  * about mathjax workaround, will the generation embeds the js or will it link
to the local mathjax package in python-nbsphinx-doc ? meaning, do you
confirm you don't need python-nbsphinx-doc to Depends on libjs-mathjax
? Sorry I could not build and check that to verify by myself :)
- d/patches : "debian" is not a keyword listed in DEP3 for "Origin". I guess it
would rather be "vendor" but as you provide "Author" already, "Origin" is
not required.

When I wanted to test the build, I couln'd find the following packages
: python[3]-nbconvert python[3]-nbformat python[3]-jupyter-client
python[3]-ipykernel Do you have the links to the .dsc files so that I can go
further ?
Thanks!

F.

On Sun, 25 Sep 2016 22:40:29 +0100, Jerome Benoit  wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear Sponsors,
> 
>   I am looking for sponsorship for the Debian package nbsphinx [0,1].
>   This package brings nbsphinx to Debian on behalf of the Debian
>   Python Modules Team. This is my second Debian Python Module package,
>   so it might certainly be subject to some mistakes.
> 
> Thanks in advance,
> Jerome
> 
> [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838806
> [1] https://anonscm.debian.org/git/python-modules/packages/nbsphinx.git
> 
> -- System Information:
> Debian Release: Jessie*
>   APT prefers stable
>   APT policy: (990, 'stable'), (500, 'stable-updates')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 3.16.7-ckt20-0001-mbp62 (SMP w/4 CPU cores)
> Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: sysvinit (via /sbin/init)
> 

Bug#824900: iroffer-dinoex packaging : some more checks

[Frederic Bonnard]

Hi Weilu,

here are some other remarks on your packaging :

- d/copyright :
 * src/strnatcmp.* : looks more like zlib/libpng than MIT
 * dtd/iroffer-model-10.mod : this one is not GPL-2 with OpenSSL exception
 * missing copyright :
   o src/dinoex_curl.c : from curl tool_cb_hdr.c, Copyright (C) 1998 - 2011, 
Daniel Stenberg
 * Not sure you can extend the copyright period from what is actually in the
   files : d/copyright : "Copyright: 2000-2016 Dirk Meyer"
   You may only merge
   : https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#fields
 * btw, could you confirm the false positive lintian
   "unused-file-paragraph-in-dep5-copyright" ?
   If so could you just re-order paragraphs with wildcards from more general to
   less, that'll also ease reading of the file :
   o put 1st : Files: *
   o then: Files: src/upnp.* debian/*
   o all others
   I'll reopen #776796 if you confirm that (lintian 2.5.47 here)
- d/control : I can't find the link anymore, but I think that the iroffer
  package should declare the same Conflicts/Replaces relationship with 
iroffer-dinoex. 
- d/patches : 
  * did you pushed them upstream ?
  * remove # lines in the DEP3 header if not filled upstream or if done
add "Bug: "
- wrap-and-sort can help tidying some d/ files (minor but this is a tip)
- as a general advice, try to fix all lintians >= Informational : make a patch
  for typos and submit upstream.

Thanks for the work, there was much improvements since the 1st draft.

F.

Bug#839226: [PATCH] cups : SSL is vulnerable to POODLE

[Frederic Bonnard]

Package: cups
Version: 1.5.3-5+deb7u6
Tags: patch

--

Hi,

would it be possible to review and maybe have this patch in wheezy ? (maybe also
jessie as all cups < 2.1b1 are concerned).
It has been applied in Redhat/Centos and Ubuntu in greater version (1.6.3 and
1.7.2).
I disables SSLv3 by default but gives the possibility with AllowSSL3 to turns 
SSLv3
back on and also AllowRC4 turns on just the RC4 cyphers.
I tried to backport it to 1.5.3, so double checking would be nice.
I tried it and it seems to work (also options to re-enable SSL3/RC4 cyphers).
For Jessie, it seems that the patch from Ubuntu cups-1.7.2-0ubuntu1.7 applies
with some refresh.

https://bugs.launchpad.net/ubuntu/+source/gnutls26/+bug/1510163
https://bugzilla.redhat.com/show_bug.cgi?id=1161172
https://www.cups.org/str.php?L4476


F.
Description: Disable SSLv3 with option to turn back on.
 This disables SSLv3 in cups. It also provided 2 configuration 
 options to renable by specifying SSLOptions in the cupsd.conf
 file. AllowSSL3 turns SSLv3 back on and AllowRC4 turns on just
 the RC4 cypers.
 This patch was originally taken from https://git.centos.org/raw/rpms!cups/68a3ed04baba43d09f5cdd7557dda2480070feb0/SOURCES!cups-str4476.patch
 and backported to cups 1.5.3.
Origin: vendor, https://bugzilla.redhat.com/show_bug.cgi?id=1161172
Bug: https://www.cups.org/str.php?L4476
Bug-Ubuntu: https://launchpad.net/bugs/1505328
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/cups/http.c
+++ b/cups/http.c
@@ -182,6 +182,8 @@
  * Local globals...
  */
 
+static int		tls_options = 0; /* Options for TLS connections */
+
 static const char * const http_fields[] =
 			{
 			  "Accept-Language",
@@ -3620,7 +3622,10 @@
   if (http->encryption == HTTP_ENCRYPT_REQUIRED && !http->tls)
   {
 httpSetField(http, HTTP_FIELD_CONNECTION, "Upgrade");
-httpSetField(http, HTTP_FIELD_UPGRADE, "TLS/1.0,SSL/2.0,SSL/3.0");
+if (tls_options & _HTTP_TLS_ALLOW_SSL3)
+  httpSetField(http, HTTP_FIELD_UPGRADE, "TLS/1.1,TLS/1.0,SSL/3.0");
+else
+  httpSetField(http, HTTP_FIELD_UPGRADE, "TLS/1.1,TLS/1.0");
   }
 #endif /* HAVE_SSL */
 
@@ -3906,6 +3911,10 @@
   context = SSL_CTX_new(SSLv23_client_method());
 
   SSL_CTX_set_options(context, SSL_OP_NO_SSLv2); /* Only use SSLv3 or TLS */
+  if (!(tls_options & _HTTP_TLS_ALLOW_SSL3))
+SSL_CTX_set_options(context, SSL_OP_NO_SSLv3); /* Don't use SSLv3 */
+  if (!(tls_options & _HTTP_TLS_ALLOW_RC4))
+SSL_CTX_set_cipher_list(context, "DEFAULT:-RC4");
 
   bio = BIO_new(_httpBIOMethods());
   BIO_ctrl(bio, BIO_C_SET_FILE_PTR, 0, (char *)http);
@@ -3965,7 +3974,16 @@
   gnutls_certificate_allocate_credentials(credentials);
 
   gnutls_init(>tls, GNUTLS_CLIENT);
-  gnutls_set_default_priority(http->tls);
+  if (!tls_options)
+gnutls_priority_set_direct(http->tls, "NORMAL:-ARCFOUR-128:-VERS-SSL3.0", NULL);
+  else if ((tls_options & _HTTP_TLS_ALLOW_SSL3) &&
+	   (tls_options & _HTTP_TLS_ALLOW_RC4))
+gnutls_priority_set_direct(http->tls, "NORMAL", NULL);
+  else if (tls_options & _HTTP_TLS_ALLOW_SSL3)
+gnutls_priority_set_direct(http->tls, "NORMAL:-ARCFOUR-128", NULL);
+  else
+gnutls_priority_set_direct(http->tls, "NORMAL:-VERS-SSL3.0", NULL);
+
   gnutls_server_name_set(http->tls, GNUTLS_NAME_DNS, hostname,
  strlen(hostname));
   gnutls_credentials_set(http->tls, GNUTLS_CRD_CERTIFICATE, *credentials);
@@ -4378,7 +4396,10 @@
 
   httpClearFields(http);
   httpSetField(http, HTTP_FIELD_CONNECTION, "upgrade");
-  httpSetField(http, HTTP_FIELD_UPGRADE, "TLS/1.2, TLS/1.1, TLS/1.0, SSL/3.0");
+  if (tls_options & _HTTP_TLS_ALLOW_SSL3)
+httpSetField(http, HTTP_FIELD_UPGRADE, "TLS/1.2, TLS/1.1, TLS/1.0, SSL/3.0");
+  else
+httpSetField(http, HTTP_FIELD_UPGRADE, "TLS/1.2, TLS/1.1, TLS/1.0");
 
   if ((ret = httpOptions(http, "*")) == 0)
   {
@@ -4704,6 +4725,16 @@
 }
 #endif /* HAVE_SSL */
 
+/*
+ * '_httpTLSSetOptions()' - Set TLS/SSL options.
+ */
+
+void
+_httpTLSSetOptions(int options)
+{
+  tls_options = options;
+}
+
 
 /*
  * End of "$Id: http.c 10450 2012-05-04 22:52:56Z mike $".
--- a/cups/http-private.h
+++ b/cups/http-private.h
@@ -136,6 +136,10 @@
 #endif /* HAVE_GETIFADDRS */
 #  endif /* !WIN32 */
 
+/* care - these should be the same values as the CUPSD_SSL_* equivalents */
+#define _HTTP_TLS_ALLOW_RC4	2
+#define _HTTP_TLS_ALLOW_SSL3	4
+
 
 /*
  * C++ magic...
@@ -392,6 +396,8 @@
 extern int		_httpUpdate(http_t *http, http_status_t *status);
 extern int		_httpWait(http_t *http, int msec, int usessl);
 
+extern void		_httpTLSSetOptions(int options);
+
 
 /*
  * C++ magic...
--- a/cups/usersys.c
+++ b/cups/usersys.c
@@ -63,7 +63,8 @@
 #endif /* HAVE_GSSAPI */
   const char *cups_anyroot,
   const char *cups_expiredroot,
-  const char *cups_expiredcerts);
+  const char *cups_expiredcerts,
+  int ssl_options);
 
 
 /*
@@ -248,6 +249,9 @@
   _cups_globals_t *cg = _cupsGlobals();	/* Pointer to 

Bug#838004: RFS: rear/1.18-1 ITP: rear -- Bare metal disaster recovery and system migration framework

[Frederic Bonnard]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "rear"

 Package name: rear
 Version : 1.18-1
 Upstream Author : Schlomo Schapiro, Gratien D'haese, Stefan Semmelroggen, Peer 
Heinlein, Dag Wieers, Jeroen Hoekx
 URL : https://github.com/rear/rear/
 License : GPL-3+, LGPL-2.1+, GPL-2+, CC-BY-ND-3.0
 Section : admin

It builds those binary packages:

  rear  - Bare metal disaster recovery and system migration framework
  rear-doc   - Bare metal disaster recovery and system migration framework 
(documentation)

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

https://mentors.debian.net/package/rear


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

  dget -x https://mentors.debian.net/debian/pool/main/r/rear/rear_1.18-1.dsc

More information about rear can be obtained from http://relax-and-recover.org/

Note:
  There is a load of Info lintians but this is due to the fact that rear embeds
  skeleton files/dirs that won't be use by the system installing rear, but
  those files will be used by the rear OS created to be booted later.


Regards,
 Frederic Bonnard

Bug#825289: sphde: Build takes forever

[Frederic Bonnard]

Santiago,
there was some improvements on the upstream side, especially concerning the
failures due to insufficient memory and also some tests are skipped because
the time taken is fixed on all arch (and it will be improved soon).
Did you see some improvement in your tests ?

F.

On Tue, 31 May 2016 16:13:38 +0200, Santiago Vila  wrote:
> These are the last tests I performed:
> 
> Virtual machine with 1GB RAM and 2GB swap, sbuild and eatmydata.
>   Build seems to hang.
> 
> Virtual machine with 1GB RAM and 2GB swap, sbuild and without eatmydata.
>   Build seems to hang.
> 
> Virtual machine with 2GB RAM and 2GB swap, sbuild and eatmydata.
>   Build seems to hang.
> 
> Real machine with 4GB RAM and 2GB swap and eatmydata.
>   dpkg-buildpackage by hand from unpriviledged user using a chroot.
>   Build finishes successfully.
> 
> When using sbuild, it's triggered by a cron job.
> 
> All machines, real or virtual, are running stretch.
> 

Bug#836944: gcc: autoconf test failing on amd64 with -pie -static combination

[Frederic Bonnard]

Package: gcc-6
Version: 6.2.0-3

--

Hi,
I've got an issue close to this one
: https://sourceware.org/bugzilla/show_bug.cgi?id=16428
(unstable)debian@vm81:~$ cat conftest.c 
int main() { return 0; }
(unstable)debian@vm81:~$ gcc -fPIE -pie -static conftest1.c
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/6/crtbeginT.o: relocation 
R_X86_64_32 against hidden symbol `__TMC_END__' can not be used when making a 
shared object
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libc.a(libc-start.o): 
relocation R_X86_64_32 against undefined symbol `_dl_starting_up' can not be 
used when making a shared object; recompile with -fPIC
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libc.a(check_fds.o): 
relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a 
shared object; recompile with -fPIC
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libc.a(libc-tls.o): 
relocation R_X86_64_32S against undefined symbol `_dl_static_dtv' can not be 
used when making a shared object; recompile with -fPIC
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libc.a(elf-init.o): 
relocation R_X86_64_32 against undefined symbol `__preinit_array_end' can not 
be used when making a shared object; recompile with -fPIC
...

Though, this does not happen on Ubuntu Yakkety which also uses gcc-6 
(6.2.0-3ubuntu11).
It happens on amd64 (not i386 nor ppc64el from my tests).


F.

Bug#836405: skiboot: Enable external binaries to be made available

[Frederic Bonnard]

Thanks for patch. I'll upgrade skiboot and will put these binaries as well
today.

F.

On Fri, 2 Sep 2016 15:27:53 -0300, Breno Leitao  wrote:
> Hello,
> 
> I just created a debdiff that should solve this issue.
> 
> Please let me know how does it sound.
> 
> Thank you,
> Breno
> diff -Nru skiboot-5.2.4/debian/changelog skiboot-5.2.4/debian/changelog
> --- skiboot-5.2.4/debian/changelog2016-07-18 09:55:47.0 -0400
> +++ skiboot-5.2.4/debian/changelog2016-09-02 14:08:34.0 -0400
> @@ -1,3 +1,9 @@
> +skiboot (5.2.4-2.1) UNRELEASED; urgency=medium
> +
> +  * Build and distribute external binaries. (Closes: #836405)
> +
> + -- Breno Leitao   Fri, 02 Sep 2016 14:08:34 -0400
> +
>  skiboot (5.2.4-2) unstable; urgency=medium
>  
>* Forced no-pie for Ubuntu 16.10 as previous change was not enough : in 
> 16.10
> diff -Nru skiboot-5.2.4/debian/opal-utils.install 
> skiboot-5.2.4/debian/opal-utils.install
> --- skiboot-5.2.4/debian/opal-utils.install   2015-09-01 12:36:32.0 
> -0400
> +++ skiboot-5.2.4/debian/opal-utils.install   2016-09-02 14:08:34.0 
> -0400
> @@ -1 +1,4 @@
>  usr/sbin/opal-gard
> +usr/sbin/pflash
> +usr/sbin/getscom
> +usr/sbin/putscom
> diff -Nru skiboot-5.2.4/debian/rules skiboot-5.2.4/debian/rules
> --- skiboot-5.2.4/debian/rules2016-07-18 09:52:32.0 -0400
> +++ skiboot-5.2.4/debian/rules2016-09-02 14:08:34.0 -0400
> @@ -19,14 +19,21 @@
>  override_dh_auto_build:
>   OPAL_PRD_VERSION=opal-prd-$(UPSTREAM_VERSION) make V=1 -C 
> external/opal-prd/
>   GARD_VERSION=gard-$(UPSTREAM_VERSION) make V=1 -C external/gard/
> + PFLASH_VERSION=pflash-$(UPSTREAM_VERSION) make V=1 -C external/pflash
> + make V=1 -C external/xscom-utils
>  
>  override_dh_auto_install:
>   make -C external/opal-prd/ prefix=/usr DESTDIR=../../debian/tmp/ install
>   make -C external/gard/ prefix=/usr DESTDIR=../../debian/tmp/ install
> + make -C external/pflash/ prefix=/usr DESTDIR=../../debian/tmp/ install
> + cp external/xscom-utils/getscom debian/tmp/usr/sbin
> + cp external/xscom-utils/putscom debian/tmp/usr/sbin
>  
>  override_dh_auto_clean:
>   make -C external/opal-prd/ clean
>   make -C external/gard/ clean
> + make -C external/pflash/ distclean
> + make -C external/xscom-utils distclean
>   rm -f external/opal-prd/ccan \
>   external/opal-prd/.version \
>   external/opal-prd/version.c \
> @@ -36,5 +43,6 @@
>   external/gard/common \
>   external/gard/ccan \
>   external/gard/make_version.sh \
> - external/gard/libflash
> + external/gard/libflash \
> + external/pflash/version.c
>   dh_auto_clean

Bug#834601: installation-reports

[Frederic Bonnard]

Hey,
I'm wondering if this could be related to screen being now used during
default installation type (newt here).
Is there a way to disable screen use to check is this issue is screen related ?

F.


On Wed, 17 Aug 2016 16:20:00 +0200, Erwan Prioul  
wrote:
> Package: installation-reports
> 
> Boot method: ISO image
> Image version: 
> http://cdimage.debian.org/mirror/cdimage/daily-builds/daily/current/ppc64el/iso-cd/debian-testing-ppc64el-netinst.iso
> Date: Wed Aug 17 07:44:46 CEST 2016
> 
> Machine: qemu VM
> Processor: ppc64el
> Memory: 4Gb
> 
> Initial boot:   [O]
> Detect network card:[ ]
> Configure network:  [ ]
> Detect CD:  [ ]
> Load installer modules: [ ]
> Detect hard drives: [ ]
> Partition hard drives:  [ ]
> Install base system:[ ]
> Clock/timezone setup:   [ ]
> User/password setup:[ ]
> Install tasks:  [ ]
> Install boot loader:[ ]
> Overall install:[ ]
> 
> Comments/Problems:
> 
> Right after the Grub menu, I got glitches in the screens to choose the 
> language and the next ones.
> The top menu isn't well refreshed and the list of locations isn't displayed 
> properly.
> I've gotten this issue since the 12th of July.
> 
> Here some "screenshots":
> The installer menu:
> 
>   ┌┤ [!] Debian installer main menu ├┐
>   │  │
>   │ Choose the next step in the install process: │
>   │  │
>   │  Choose language │
> │  Access software for a blind person using a braille display  │
> │  Configure the keyboard  │
> │  Detect and mount CD-ROM │
> │  Load installer components from CD   │
> │  Change debconf priority │
> │  Check the CD-ROM(s) integrity   │
> │  Save debug logs │
> │  Execute a shell │
> │  Abort the installation  │
> │  │
> └──┘
> 
> 
> 
>  moves;  selects;  activates buttons
> 
> 
> The top menu is missing (and some edges too):
> 
>   ──┤ [!!] Select a language ├┐
>   │
>   Choose the language to be used for the installation process. The│
>   selected language will also be the default language for the installed   │
>   system. │
>   │
>   Language:   │
>   │
>   C   │
>   Basque   ▒  │
>   Catalan │
>   Danish   ▒  │
>   Dutch▒  │
>   English  ▒  │
>   Finnish  ▒  │
>   French  │
>   │
>  │
>   │
> └─┘
> 
>  moves;  selects;  activates buttons
> 
> 
> After about 20 seconds the top menu appears:
> 
> [(1*installer)  2 shell  3 shell  4- log   ][ Aug 17  
> 7:44 ]
>   ──┤ [!!] Select a language ├┐
>   │
>   Choose the language to be used for the installation process. The│
>   selected language will also be the default language for the installed   │
>   system. │
>   │
>   Language:   │
>   │
>   C   

Bug#833861: /dev/ipmi* missing on ppc64*

[Frederic Bonnard]

Package: linux
Version: 4.6.4-1
Tags: patch

--

Hi,
when trying to use ipmitool locally on a ppc64el host, I get this :

---
debian@abanc:~$ ipmitool lan print 1
Could not open device at /dev/ipmi0 or /dev/ipmi/0 or /dev/ipmidev/0: No such
file or directory
---

I saw that ipmi_powernv module is not compiled in the kernel package.
I used the attached patch and it build the module and I can now load the
module, I see /dev/ipmi0 created and I can run ipmitool. I guess the same issue
will happen on ppc64.
Let me know what you think.
Thanks!


F.
diff -Nru linux-4.6.4/debian/config/kernelarch-powerpc/config linux-4.6.4/debian/config/kernelarch-powerpc/config
--- linux-4.6.4/debian/config/kernelarch-powerpc/config	2016-07-18 21:59:51.0 +0200
+++ linux-4.6.4/debian/config/kernelarch-powerpc/config	2016-07-18 21:57:31.0 +0200
@@ -172,6 +172,7 @@
 # CONFIG_IPMI_PANIC_EVENT is not set
 CONFIG_IPMI_DEVICE_INTERFACE=m
 CONFIG_IPMI_SI=m
+CONFIG_IPMI_POWERNV=m
 CONFIG_IPMI_WATCHDOG=m
 CONFIG_IPMI_POWEROFF=m
 

Bug#833751: ofpath: support for pata_macio on oldworld

[Frederic Bonnard]

Package: yaboot
Version: 1.3.17-4
Tags: patch

--

Hi,
here is a patch that should add support for pata_macio driver in ofpath on 
oldworld.
I have bug #695945 on qemu too and it seems that pata_macio driver is used and
by default qemu-system-ppc emulates an oldworld AAPL,PowerMac G3.
quik-installer uses ofpath and it fails to translate the linux device path to
OpenFirmware path, because this combination pata_macio/oldworld/PowerMac G3 is
not dealt with.
As it said in the bug above, not sure "nvsetenv boot-device \"${ofpath}0\" in
quik-installer post-install is needed. I tested quik-installer without those
lines and the installer worked. But this was on qemu and I don't have real
hardware to check more.
So I added support to the ofpath script.
ofpath wouldn't fail and will provide an OF path and I could finish the
installation properly. I checked the generated path was ok from the OF prompt
of the qemu machine.
Let me know what you think of this.
Thanks!


F.
diff -Nru yaboot-1.3.17/debian/patches/add-pata_macio-support-on-old-world.patch yaboot-1.3.17/debian/patches/add-pata_macio-support-on-old-world.patch
--- yaboot-1.3.17/debian/patches/add-pata_macio-support-on-old-world.patch	1969-12-31 19:00:00.0 -0500
+++ yaboot-1.3.17/debian/patches/add-pata_macio-support-on-old-world.patch	2016-06-07 02:27:26.0 -0400
@@ -0,0 +1,31 @@
+Description: Add support for pata_macio on oldworld
+ I have bug #695945 on qemu too and it seems that pata_macio driver is used and
+ by default qemu-system-ppc emulates an oldworld AAPL,PowerMac G3.
+ quik-installer uses ofpath and it fails to translate the linux device path of
+ OpenFirmware path, because this combination pata_macio/oldworld/PowerMac G3 is
+ not dealt with.
+Author: Frederic Bonnard <fre...@linux.vnet.ibm.com>
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/ybin/ofpath
 b/ybin/ofpath
+@@ -542,6 +542,19 @@
+ 		mesh)
+ 		echo $(cat /proc/device-tree/$ALIASES/scsi)/sd\@$DEVICE_ID:$PARTITION
+ 		;;
++		pata_macio)
++		case "$DEVNODE" in
++		sda|sdc)
++		echo $(cat /proc/device-tree/$ALIASES/ide0)\@$DEVICE_ID$PART
++		;;
++		sdb|sdd)
++		echo $(cat /proc/device-tree/$ALIASES/ide1)\@$DEVICE_ID$PART
++		;;
++		sd*)
++		echo 1>&2 "$PRG: Device: /dev/$DEVNODE is not supported"
++		;;
++		esac
++		;;
+ 		*)
+ 		echo 1>&2 "$PRG: Driver $SCSI_DRIVER is not supported"
+ 		return 1
diff -Nru yaboot-1.3.17/debian/patches/series yaboot-1.3.17/debian/patches/series
--- yaboot-1.3.17/debian/patches/series	2016-04-02 23:59:10.0 -0400
+++ yaboot-1.3.17/debian/patches/series	2016-06-07 02:27:26.0 -0400
@@ -10,3 +10,4 @@
 cell-support.patch
 typo.patch
 819549-cd.patch
+add-pata_macio-support-on-old-world.patch

Bug#830194: rpm-4.12 : preun behaviour bug

[Frederic Bonnard]

Hi Michal,
the fix has been merged upstream.
Do you think we can have the patch be applied in Debian in current rpm version
? last rpm-4.13.0-rc1 release is from September 2015. Not sure when next rpm
version will be released.
Regards,

Fred

On Thu, 7 Jul 2016 11:51:07 +0200, Michal Čihař <mic...@cihar.com> wrote:
> Hi
> 
> Dne 7.7.2016 v 11:45 Frederic Bonnard napsal(a):
> > Hi Michal,
> > I didn't open a bug upstream, but sent a pull request that was positively
> > reviewed (and I guess, merged soon).
> > As pmatilai said, the behaviour is clearly not intended.
> > Should I open a bug there also ?
> > https://github.com/rpm-software-management/rpm/pull/74
> 
> No problem, pull request is good enough as well, I just wanted to ensure
> this is known upstream and see how it's handled there.
> 
> -- 
>   Michal Čihař | http://cihar.com/ | https://weblate.org/
> 

Bug#831692: RFS: skiboot/5.2.4-2 update

[Frederic Bonnard]

Package: sponsorship-requests
Severity: normal

Dear mentors, Gianfranco,

I am looking for a sponsor for the package "skiboot". This is a packaging 
update :

skiboot (5.2.4-2) unstable; urgency=medium

  * Forced no-pie for Ubuntu 16.10 as previous change was not enough : in 16.10
gcc's default change to build PIE by default.

 -- Frederic Bonnard <fre...@linux.vnet.ibm.com>  Mon, 18 Jul 2016 15:52:41 
+0200


 Package name: skiboot
 Version : 5.2.4-2
 Upstream Author : skiboot team
 URL : http://github.com/open-power/skiboot/
 License : Apache-2.0, CC0, BSD-2-Clause, MIT/X11-BSD-like
 Section : admin

It builds those binary packages:

  opal-prd   - OPAL Processor Recovery Diagnostics daemon
  opal-utils - OPAL firmware utilities

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

https://mentors.debian.net/package/skiboot


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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/skiboot/skiboot_5.2.4-2.dsc

More information about skiboot can be obtained from 
http://github.com/open-power/skiboot/


Regards,
 Frederic Bonnard

Bug#830885: RFS: skiboot/5.2.4-1 update

[Frederic Bonnard]

Package: sponsorship-requests
Severity: normal

Dear mentors, Gianfranco,

I am looking for a sponsor for the package "skiboot". This is a packaging 
update :

skiboot (5.2.4-1) unstable; urgency=medium

  * New upstream release
  * Disabled PIE build as this makes opal-prd segfault and there is no
possibility to improve that on the code side soon.
  * Removed typos patch as it was partially applied in new version.

 -- Frederic Bonnard <fre...@linux.vnet.ibm.com>  Tue, 12 Jul 2016 17:54:46 
+0200


 Package name: skiboot
 Version : 5.2.4-1
 Upstream Author : skiboot team
 URL : http://github.com/open-power/skiboot/
 License : Apache-2.0, CC0, BSD-2-Clause, MIT/X11-BSD-like
 Section : admin

It builds those binary packages:

  opal-prd   - OPAL Processor Recovery Diagnostics daemon
  opal-utils - OPAL firmware utilities

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

https://mentors.debian.net/package/skiboot


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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/skiboot/skiboot_5.2.4-1.dsc

More information about skiboot can be obtained from 
http://github.com/open-power/skiboot/


Regards,
 Frederic Bonnard

Bug#809064: [PATCH] Bug 678085 - Cage tool freezes GIMP

[Frederic Bonnard]

Tags: patch

--

Hi,
would it be possible to take the patch in advance ?
https://github.com/GNOME/gimp/commit/b5546ac0ac4a30bfd31ccc75c22f722a1c38dee1

Thanks,

F.

Bug#830194: rpm-4.12 : preun behaviour bug

[Frederic Bonnard]

Hi Michal,
I didn't open a bug upstream, but sent a pull request that was positively
reviewed (and I guess, merged soon).
As pmatilai said, the behaviour is clearly not intended.
Should I open a bug there also ?
https://github.com/rpm-software-management/rpm/pull/74

Thanks again,

F.



On Thu, 7 Jul 2016 11:41:49 +0200, Michal Čihař <mic...@cihar.com> wrote:
> Hi
> 
> Dne 7.7.2016 v 11:34 Frederic Bonnard napsal(a):
> > Package: rpm
> > Version: 4.12.0.1+dfsg1-3
> > Tags: patch
> > 
> > --
> > 
> > 
> > Hi,
> > since rpm 4.12, if a preun scriptlet fails, the rpm is still completely 
> > removed
> > whereas it shouldn't.
> > I sent a pull request for the bug, but would like the patch to be taken in 
> > here
> > before to fix the buggy behaviour.
> 
> Can you please point me to relevant upstream bug? I'm not in favor
> including patches which are not acceptable upstream.
> 
> -- 
>   Michal Čihař | http://cihar.com/ | https://weblate.org/
> 

Bug#830194: rpm-4.12 : preun behaviour bug

[Frederic Bonnard]

Package: rpm
Version: 4.12.0.1+dfsg1-3
Tags: patch

--


Hi,
since rpm 4.12, if a preun scriptlet fails, the rpm is still completely removed
whereas it shouldn't.
I sent a pull request for the bug, but would like the patch to be taken in here
before to fix the buggy behaviour.
Thanks,


F.
diff -Nru rpm-4.12.0.1+dfsg1/debian/patches/fix-preun-scriptlet-failing-behaviour.patch rpm-4.12.0.1+dfsg1/debian/patches/fix-preun-scriptlet-failing-behaviour.patch
--- rpm-4.12.0.1+dfsg1/debian/patches/fix-preun-scriptlet-failing-behaviour.patch	1970-01-01 01:00:00.0 +0100
+++ rpm-4.12.0.1+dfsg1/debian/patches/fix-preun-scriptlet-failing-behaviour.patch	2016-07-07 11:07:30.0 +0200
@@ -0,0 +1,22 @@
+Description: Fix preun scriptlet failure not aborting rpm erase
+ Since commit f4a49c3 ( Unceremoniously
+ eliminate rpmpsmNext() ), when a preun scriptlet is failing, rpm continues to
+ be erased. Handling return code of runInstScript.
+Author: Frederic Bonnard <fre...@linux.vnet.ibm.com>
+Forwarded: https://github.com/rpm-software-management/rpm/pull/74
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/lib/psm.c
 b/lib/psm.c
+@@ -791,8 +791,10 @@
+ 	if (rc) break;
+ 	}
+ 
+-	if (!(rpmtsFlags(ts) & RPMTRANS_FLAG_NOPREUN))
++	if (!(rpmtsFlags(ts) & RPMTRANS_FLAG_NOPREUN)) {
+ 	rc = runInstScript(psm, RPMTAG_PREUN);
++	if (rc) break;
++	}
+ 
+ 	rc = rpmpsmRemove(psm);
+ 	if (rc) break;
diff -Nru rpm-4.12.0.1+dfsg1/debian/patches/series rpm-4.12.0.1+dfsg1/debian/patches/series
--- rpm-4.12.0.1+dfsg1/debian/patches/series	2015-04-24 14:00:55.0 +0200
+++ rpm-4.12.0.1+dfsg1/debian/patches/series	2016-07-07 11:04:27.0 +0200
@@ -13,3 +13,4 @@
 fix-python-multiarch-include.patch
 rpm-4.11.2-double-separator-warning.patch
 CVE-2014-8118.patch
+fix-preun-scriptlet-failing-behaviour.patch

Bug#827180: RFS: skiboot/5.2.2-2

[Frederic Bonnard]

Package: sponsorship-requests
Severity: normal

Dear mentors, Gianfranco,

I am looking for a sponsor for my package "skiboot". This is a packaging update
because I modified debian/copyright for 3 files.

 Package name: skiboot
 Version : 5.2.2-2
 Upstream Author : skiboot team
 URL : http://github.com/open-power/skiboot/
 License : Apache-2.0, CC0, BSD-2-Clause, MIT/X11-BSD-like
 Section : admin

It builds those binary packages:

  opal-prd   - OPAL Processor Recovery Diagnostics daemon
  opal-utils - OPAL firmware utilities

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

https://mentors.debian.net/package/skiboot


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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/skiboot/skiboot_5.2.2-2.dsc

More information about skiboot can be obtained from 
http://github.com/open-power/skiboot/


Regards,
 Frederic Bonnard

Bug#826141: RFS: skiboot/5.2.2-1 ITP: skiboot -- OPAL boot and runtime firmware for POWER

[Frederic Bonnard]

Hi,

new packaging is here :
https://mentors.debian.net/package/skiboot
https://mentors.debian.net/debian/pool/main/s/skiboot/skiboot_5.2.2-1.dsc

on this one,
d/rules is a bit hacky, but this is due to the firmware nature of skiboot
I guess : we don't want to compile the firmware, just the userland utilities.
There could be some improvements of course for people not flashing the cards
and compiling the whole suite with a simple make and more specialised targets.

check-all-the-things :
- added a patch for the bunch of typos. Will send this upstream
- for ccpcheck foundings, we actually compile just a part of the tree which has
  one cppcheck founding. Though there should be some reporting to be done for
  all the rest of the source tree.
- I fixed d/copyright that was missing ccan/list/*

Lintians :
- added Documentation key in .service file
- fixed hardened build with a patch
- removed 1 patch not necessary
- one typo, integrated in patch above written after check-all-the-things

3 remaining :
P: skiboot source: debian-watch-may-check-gpg-signature
P: opal-prd: no-upstream-changelog
P: opal-utils: no-upstream-changelog

F.


On Thu, 2 Jun 2016 16:37:52 + (UTC), Gianfranco Costamagna 
<locutusofb...@debian.org> wrote:
> control: owner -1 !
> control: tags -1 moreinfo
> 
> Hi, also here, please check the usual stuff (also cppcheck is reporting some 
> issues)
> 
> 
> General note: I suggest you to do only one of the reviews, and fix all of 
> them.
> I prefer to see only one package at each time, sponsor it, wait for you to fix
> the same issues on the other RFS and move to another one.
> 
> Asking to fix the same stuff on 10 packages is just a waste of time.
> 
> (BTW some packages has hacky rules file, why? Makefile doesn't work?)
> 
> cheers,
> 
> G.
> 
> 
> 
> 
> 
> Il Giovedì 2 Giugno 2016 18:18, Frederic Bonnard <fre...@linux.vnet.ibm.com> 
> ha scritto:
> 
> 
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "skiboot"
> 
> Package name: skiboot
> Version : 5.2.2-1
> Upstream Author : skiboot team
> URL : http://github.com/open-power/skiboot/
> License : Apache-2.0, CC0, BSD-2-Clause
> Section : admin
> 
> It builds those binary packages:
> 
>   opal-prd   - OPAL Processor Recovery Diagnostics daemon
>   opal-utils - OPAL firmware utilities
> 
> To access further information about this package, please visit the following 
> URL:
> 
> https://mentors.debian.net/package/skiboot
> 
> 
> Alternatively, one can download the package with dget using this command:
> 
>   dget -x 
> https://mentors.debian.net/debian/pool/main/s/skiboot/skiboot_5.2.2-1.dsc
> 
> More information about hello can be obtained from https://www.example.com.
> 
> Note:
>   This is for Power architectures.
>   I initially packaged this for Ubuntu Trusty. I pulled it from Ubuntu did a 
> few
>   changes, updated it with new upstream and here it is. It would need to be 
> synced with Ubuntu.
> 
> 
> Regards,
> Frederic Bonnard
> 

Bug#826140: RFS: ppc64-diag/2.7.0-1 ITP: ppc64-diag -- Platform error log analysis tool and rtas_errd daemon

[Frederic Bonnard]

Hi,

here is a new packaging :
https://mentors.debian.net/package/ppc64-diag
https://mentors.debian.net/debian/pool/main/p/ppc64-diag/ppc64-diag_2.7.1-1.dsc

Added -doc package.
Fixed typos, there was so many, creating loads of lintian issues.
Fixed a manpage generating a "a space character is not allowed in an escape 
name"
Added first drafts of manpages for 4 binaries.

check-all-the-things seems ok.
For lintian, here is what remains :

P: ppc64-diag source: debian-watch-may-check-gpg-signature
P: ppc64-diag-doc: no-upstream-changelog
P: ppc64-diag: no-upstream-changelog
W: ppc64-diag-doc: embedded-javascript-library 
usr/share/doc/ppc64-diag-doc/html/jquery.js please use libjs-jquery

>From what you said some time ago, I should keep the embedded one.

W: ppc64-diag: binary-without-manpage usr/sbin/ppc64_diag_register
W: ppc64-diag: binary-without-manpage usr/sbin/rtas_errd

Those are scripts called by systemd unit files. Is it acceptable or should they
be moved to another place? I saw both cases in codesearch.d.n

Thanks,

F.

On Thu, 2 Jun 2016 16:32:05 + (UTC), Gianfranco Costamagna 
<locutusofb...@debian.org> wrote:
> control: owner -1 !
> control: tags -1 moreinfo
> 
> Hi, in additions to the other reviews, lintian and check-all-the-things, 
> please:
> 
> why no-doc package? I see doxygen here
> 
> other stuff LGTM
> 
> 
> 
> 
> Il Giovedì 2 Giugno 2016 18:12, Frederic Bonnard <fre...@linux.vnet.ibm.com> 
> ha scritto:
> 
> 
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "ppc64-diag"
> 
> Package name: ppc64-diag
> Version : 2.7.0-1
> Upstream Author : Vasant Hegde <hegdevas...@in.ibm.com>
> URL : http://sourceforge.net/projects/linux-diag/files/ppc64-diag/
> License : GPL-2+
> Section : misc
> 
> It builds those binary packages:
> 
>   ppc64-diag - Platform error log analysis tool and rtas_errd daemon
> 
> To access further information about this package, please visit the following 
> URL:
> 
> https://mentors.debian.net/package/ppc64-diag
> 
> 
> Alternatively, one can download the package with dget using this command:
> 
>   dget -x 
> https://mentors.debian.net/debian/pool/main/p/ppc64-diag/ppc64-diag_2.7.0-1.dsc
> 
> More information about ppc64-diag can be obtained from 
> http://sourceforge.net/projects/linux-diag/files/ppc64-diag/
> 
> Note:
>   This is for Power architectures.
>   I initially packaged this for Ubuntu Trusty. I pulled it from Ubuntu did a 
> few
>   changes and here it is. It would need to be synced with Ubuntu.
> 
> 
> Regards,
> Frederic Bonnard
> 

Bug#826137: RFS: libservicelog/1.1.16-1 ITP: libservicelog -- Library to create and maintain a database for storing events

[Frederic Bonnard]

Hi,

here is a new upload :
https://mentors.debian.net/package/libservicelog
https://mentors.debian.net/debian/pool/main/libs/libservicelog/libservicelog_1.1.16-1.dsc

removed empty d/patches

  usr/lib/*/libservicelog-1.1.so.1*
changed to :
  usr/lib/*/*.so.*


  usr/include/servicelog-1/
  usr/lib/*/pkgconfig/servicelog-1.pc
  usr/lib/*/*.so
changed to :
  usr/include
  usr/lib/*/pkgconfig
  usr/lib/*/*.so

abort-upgrade|abort-remove|abort-deconfigure)
;;
removed from d/libservicelog-1.1-1.postinst

Added several files with specific license (though they contain Autoconf/Bison
special exception for re-licensing) to d/copyright

Lintians :
added symbol file.
Remains :
P: libservicelog source: debian-watch-may-check-gpg-signature
W: libservicelog-1.1-1: dev-pkg-without-shlib-symlink 
usr/lib/powerpc64le-linux-gnu/libservicelog-1.1.so.1.0.0 
usr/lib/powerpc64le-linux-gnu/libservicelog-1.1.so

because of

lrwxrwxrwx root/root 0 2016-06-07 12:36
./usr/lib/powerpc64le-linux-gnu/libservicelog.so -> libservicelog-1.1.so.1.0.0


F.

On Thu, 2 Jun 2016 16:23:45 + (UTC), Gianfranco Costamagna 
<locutusofb...@debian.org> wrote:
> control: owner -1 !
> control: tags -1 moreinfo
> 
> Hi,
> the same for the other two libraries applies here, in addition:
> 
> please run check-all-the-things, something should be fixed.
> 
> g.
> 
> 
> 
> 
> 
> Il Giovedì 2 Giugno 2016 18:06, Frederic Bonnard <fre...@linux.vnet.ibm.com> 
> ha scritto:
> 
> 
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "libservicelog"
> 
> Package name: libservicelog
> Version : 1.1.16-1
> Upstream Author : Vasant Hegde <hegdevas...@in.ibm.com>
> URL : 
> http://sourceforge.net/projects/linux-diag/files/libservicelog/
> License : LGPL-2+
> Section : libs
> 
> It builds those binary packages:
> 
>   libservicelog-1.1-1 - Library to create and maintain a database for storing 
> events
>   libservicelog-dev - libservicelog development files
> 
> To access further information about this package, please visit the following 
> URL:
> 
> https://mentors.debian.net/package/libservicelog
> 
> 
> Alternatively, one can download the package with dget using this command:
> 
>   dget -x 
> https://mentors.debian.net/debian/pool/main/libs/libservicelog/libservicelog_1.1.16-1.dsc
> 
> More information about libservicelog can be obtained from 
> http://sourceforge.net/projects/linux-diag/files/libservicelog/
> 
> Note:
>   This is for Power architectures.
>   I initially packaged this for Ubuntu Trusty. I pulled it from Ubuntu did a 
> few
>   changes and here it is. It would need to be synced with Ubuntu.
> 
> 
> Regards,
> Frederic Bonnard
> 

Bug#826135: RFS: lsvpd/1.7.6-1 ITP: lsvpd -- Utility to List Device Vital Product Data (VPD)

[Frederic Bonnard]

Hi,

new packaging uploaded : 
https://mentors.debian.net/package/lsvpd
https://mentors.debian.net/debian/pool/main/l/lsvpd/lsvpd_1.7.7-1.dsc

> the same for libvpd applies here
> 
> "License: GPL-2+ with librtas exception"
> 
> maybe something like
> License: GPL-2+-with-librtas-exception
> 
> is better (check lintian if complains)

Fixed and lintian doesn't complain.
Also, as for libvpd, I added all autoconf files and others.
I checked with license-reconcile and I think I forgot nobody.

> abort-upgrade|abort-remove|abort-deconfigure)
> ;;
> 
> useless ^^

done

> apt-get install -t experimental check-all-the-things:

pity, I just realize, this is really a command ..

> check-all-the-things
> 
> 
> $ codespell --quiet-level=3
> 
> 
> $ cppcheck -j1 --quiet -f . | grep -vF 'cppcheck: error: could not find or 
> open any of the paths given.'
> 
> 
> # Parsing /proc/cpuinfo is not portable at all, use /sys instead.
> $ grep -rF /proc/cpuinfo .
> 
> 
> 
> package outdated

... updated.
I also trimmed d/rules.

Remaining lintians :
P: lsvpd source: debian-watch-may-check-gpg-signature
I: lsvpd: hardening-no-fortify-functions usr/sbin/lscfg

For the latter CPPFLAGS is given to the compiler :
$ dpkg-buildflags --get CPPFLAGS
-Wdate-time -D_FORTIFY_SOURCE=2

g++ -DHAVE_CONFIG_H -I. -I./config  -I./src/include -Wall -fstack-protector-all
-Wstack-protector -Wdate-time -D_FORTIFY_SOURCE=2 -DDEST_DIR='"/usr"'
-DVPD_VERSION='"1.7.7"' -g -O2 -fPIE -fstack-protector-strong -Wformat
-Werror=format-security -c -o src/output/lsvpd.o src/output/lsvpd.cpp$

F.

> other stuff LGTM
> 
> G.
> 
> 
> Il Giovedì 2 Giugno 2016 18:00, Frederic Bonnard <fre...@linux.vnet.ibm.com> 
> ha scritto:
> 
> 
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "lsvpd"
> 
> Package name: lsvpd
> Version : 1.7.6-1
> Upstream Author : lsvpd team
> URL : http://sourceforge.net/projects/linux-diag/files/lsvpd/
> License : GPL-2+
> Section : misc
> 
> It builds those binary packages:
> 
>   lsvpd - Utility to List Device Vital Product Data (VPD)
> 
> To access further information about this package, please visit the following 
> URL:
> 
> https://mentors.debian.net/package/lsvpd
> 
> 
> Alternatively, one can download the package with dget using this command:
> 
>   dget -x 
> https://mentors.debian.net/debian/pool/main/l/lsvpd/lsvpd_1.7.6-1.dsc
> 
> More information about lsvpd can be obtained from 
> http://sourceforge.net/projects/linux-diag/files/lsvpd/ 
> 
> Note:
>   This is for Power architectures.
>   I initially packaged this for Ubuntu Trusty. I pulled it from Ubuntu did a 
> few
>   changes and here it is. It would need to be synced with Ubuntu.
> 
> 
> Regards,
> Frederic Bonnard
> 

Bug#826138: RFS: servicelog/1.1.14-1 ITP: servicelog -- Platform Service/Error Message Database

[Frederic Bonnard]

Hi,

I uploaded a new packaging :
https://mentors.debian.net/package/servicelog
https://mentors.debian.net/debian/pool/main/s/servicelog/servicelog_1.1.14-1.dsc

several enhancements, especially on d/copyright to list autoconf files and fix
the license.
Cleaned d/patches, d/rules.
Reduced lintians to :
P: servicelog source: debian-watch-may-check-gpg-signature
I: servicelog: spelling-error-in-binary usr/sbin/slog_common_event occured
occurred

check-all-the-things looks mostly ok


F.

On Thu, 2 Jun 2016 16:27:59 + (UTC), Gianfranco Costamagna 
<locutusofb...@debian.org> wrote:
> control: owner -1 !
> control: tags -1 moreinfo
> 
> Hi, in additions to the other stuff:
> 
> 
> GPL-2+ seems the right license.
> 
> other stuff LGTM
> (please also run check-all-the-things/lintian and fix stuff)
> 
> 
> 
> cheers,
> 
> G.
> 
> 
> Il Giovedì 2 Giugno 2016 18:09, Frederic Bonnard <fre...@linux.vnet.ibm.com> 
> ha scritto:
> 
> 
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "servicelog"
> 
> Package name: servicelog
> Version : 1.1.14-1
> Upstream Author : Vasant Hegde <hegdevas...@in.ibm.com>
> URL : http://sourceforge.net/projects/linux-diag/files/servicelog/
> License : GPL-2
> Section : misc
> 
> It builds those binary packages:
> 
>   servicelog - Platform Service/Error Message Database
> 
> To access further information about this package, please visit the following 
> URL:
> 
> https://mentors.debian.net/package/servicelog
> 
> 
> Alternatively, one can download the package with dget using this command:
> 
>   dget -x 
> https://mentors.debian.net/debian/pool/main/s/servicelog/servicelog_1.1.14-1.dsc
> 
> More information about servicelog can be obtained from 
> http://sourceforge.net/projects/linux-diag/files/servicelog/
> 
> Note:
>   This is for Power architectures.
>   I initially packaged this for Ubuntu Trusty. I pulled it from Ubuntu did a 
> few
>   changes and here it is. It would need to be synced with Ubuntu.
> 
> 
> Regards,
> Frederic Bonnard
> 

Bug#826134: RFS: libvpd/2.2.5-1 ITP: libvpd -- VPD Database access library

[Frederic Bonnard]

Hi,

I did new upload right there :
https://mentors.debian.net/package/libvpd
https://mentors.debian.net/debian/pool/main/libv/libvpd/libvpd_2.2.5-1.dsc

> lets see:
> 
> usr/include/libvpd-2/*
> usr/lib/*/*.so
> usr/lib/*/pkgconfig/*
> 
> maybe you can put
> usr/include
> usr/lib/*/*.so
> usr/lib/*/pkgconfig
> 
> (I didn't check the above)

done
That works. And I changed to this in the new packaging.

For usr/include/libvpd-2/* -> usr/include
I initially used that "generic" regexps but I wondered and prefered more
targetted regexps to avoid copying files that were wrongly installed in that
path, in case of a later upstream version.
Meaning that the idea was that I see things failing and fix it, or extend the 
regexp
if that's correct, but don't put things blindly in that path.
However, I used usr/include in the packaging.

> and for the library you can do something like
> usr/lib/*/lib*.so.*

done

> "etc/udev/rules.d/90-vpdupdate.rules /lib/udev/rules.d"
> isn't this something that dh_installudev should do?

done
right, I didn't see there was also a dh_installbla for udev at that time :)

> rules file has a lot of useless stuff (comments, dh_options)

done

> d/patches: remove

done

> missing licenses:
> config/install-sh: MIT/X11 (BSD like)
> config/missing: GPL (v2 or later) GENERATED FILE
> config/ar-lib: GPL (v2 or later) GENERATED FILE
> config/depcomp: GPL (v2 or later) GENERATED FILE
> config/ltmain.sh: GPL (v2 or later)

done
Actually, for the last 4, the embedded license says :
---
 As a special exception to the GNU General Public License, if you
 distribute this file as part of a program that contains a
 configuration script generated by Autoconf, you may include it under
 the same distribution terms that you use for the rest of that program.
---
Does that mean that it could be distributed with the global license of the
project? And maybe needn't being explictly listed in d/copyright ?
Anyway, I added those files as well as config.guess, config.sub, aclocal.m4,
Makefile.in and configure with their specific Copyright and License, just in
case.

> debian/copyright: LGPL (v2.1 or later)
> 
> wrong copyright:
> License: LGPL-2+
> This program is free software; you can redistribute it and/or modify
> it under the terms of the GNU Lesser General Public License as published
> by the Free Software Foundation; either version 2.1, or (at your option)
> 
> 
> 2+!=2.1+

done
Indeed, I missed something here.

> other stuff LGTM

On the lintian side, here is what remains :
P: libvpd source: debian-watch-may-check-gpg-signature
I: libvpd-2.2-2: spelling-error-in-binary 
usr/lib/powerpc64le-linux-gnu/libvpd_cxx-2.2.so.2.2.5 occured occurred
W: libvpd-2.2-2: dev-pkg-without-shlib-symlink 
usr/lib/powerpc64le-linux-gnu/libvpd-2.2.so.2.2.5 
usr/lib/powerpc64le-linux-gnu/libvpd-2.2.so
W: libvpd-2.2-2: dev-pkg-without-shlib-symlink 
usr/lib/powerpc64le-linux-gnu/libvpd_cxx-2.2.so.2.2.5 
usr/lib/powerpc64le-linux-gnu/libvpd_cxx-2.2.so

For the last 2, I think lintian gets lost with .so that are differently named :
lrwxrwxrwx root/root 0 2016-06-06 15:44 
./usr/lib/powerpc64le-linux-gnu/libvpd.so -> libvpd-2.2.so.2.2.5
lrwxrwxrwx root/root 0 2016-06-06 15:44 
./usr/lib/powerpc64le-linux-gnu/libvpd_cxx.so -> libvpd_cxx-2.2.so.2.2.5

F.

Bug#826141: RFS: skiboot/5.2.2-1 ITP: skiboot -- OPAL boot and runtime firmware for POWER

[Frederic Bonnard]

> General note: I suggest you to do only one of the reviews, and fix all of 
> them.
> I prefer to see only one package at each time, sponsor it, wait for you to fix
> the same issues on the other RFS and move to another one.
> 
> Asking to fix the same stuff on 10 packages is just a waste of time.

Got it. I've just gone in batch mode, thinking it'd be quicker as they were
already reviewed in Ubuntu.
I'll take a closer at the packages, one at a time.
Thanks!

F.

Bug#826134: Acknowledgement (RFS: libvpd/2.2.5-1 ITP: libvpd -- VPD Database access library)

[Frederic Bonnard]

There is some bad copy paste of URLs ... sorry.
Here is the fixed sections :

---
 Package name: libvpd
 Version : 2.2.5-1
 Upstream Author : Vasant Hegde 
 URL : http://sourceforge.net/projects/linux-diag/files/libvpd/
 License : LGPL-2+
 Section : libs
---

---
More information about libvpd can be obtained from  
http://sourceforge.net/projects/linux-diag/files/libvpd/
---

F.

Bug#826141: RFS: skiboot/5.2.2-1 ITP: skiboot -- OPAL boot and runtime firmware for POWER

[Frederic Bonnard]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "skiboot"

 Package name: skiboot
 Version : 5.2.2-1
 Upstream Author : skiboot team
 URL : http://github.com/open-power/skiboot/
 License : Apache-2.0, CC0, BSD-2-Clause
 Section : admin

It builds those binary packages:

  opal-prd   - OPAL Processor Recovery Diagnostics daemon
  opal-utils - OPAL firmware utilities

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

https://mentors.debian.net/package/skiboot


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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/skiboot/skiboot_5.2.2-1.dsc

More information about hello can be obtained from https://www.example.com.

Note:
  This is for Power architectures.
  I initially packaged this for Ubuntu Trusty. I pulled it from Ubuntu did a few
  changes, updated it with new upstream and here it is. It would need to be 
synced with Ubuntu.


Regards,
 Frederic Bonnard

Bug#826140: RFS: ppc64-diag/2.7.0-1 ITP: ppc64-diag -- Platform error log analysis tool and rtas_errd daemon

[Frederic Bonnard]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "ppc64-diag"

 Package name: ppc64-diag
 Version : 2.7.0-1
 Upstream Author : Vasant Hegde <hegdevas...@in.ibm.com>
 URL : http://sourceforge.net/projects/linux-diag/files/ppc64-diag/
 License : GPL-2+
 Section : misc

It builds those binary packages:

  ppc64-diag - Platform error log analysis tool and rtas_errd daemon

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

https://mentors.debian.net/package/ppc64-diag


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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/ppc64-diag/ppc64-diag_2.7.0-1.dsc

More information about ppc64-diag can be obtained from 
http://sourceforge.net/projects/linux-diag/files/ppc64-diag/

Note:
  This is for Power architectures.
  I initially packaged this for Ubuntu Trusty. I pulled it from Ubuntu did a few
  changes and here it is. It would need to be synced with Ubuntu.


Regards,
 Frederic Bonnard

Bug#826138: RFS: servicelog/1.1.14-1 ITP: servicelog -- Platform Service/Error Message Database

[Frederic Bonnard]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "servicelog"

 Package name: servicelog
 Version : 1.1.14-1
 Upstream Author : Vasant Hegde <hegdevas...@in.ibm.com>
 URL : http://sourceforge.net/projects/linux-diag/files/servicelog/
 License : GPL-2
 Section : misc

It builds those binary packages:

  servicelog - Platform Service/Error Message Database

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

https://mentors.debian.net/package/servicelog


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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/servicelog/servicelog_1.1.14-1.dsc

More information about servicelog can be obtained from 
http://sourceforge.net/projects/linux-diag/files/servicelog/

Note:
  This is for Power architectures.
  I initially packaged this for Ubuntu Trusty. I pulled it from Ubuntu did a few
  changes and here it is. It would need to be synced with Ubuntu.


Regards,
 Frederic Bonnard

Bug#826137: RFS: libservicelog/1.1.16-1 ITP: libservicelog -- Library to create and maintain a database for storing events

[Frederic Bonnard]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "libservicelog"

 Package name: libservicelog
 Version : 1.1.16-1
 Upstream Author : Vasant Hegde <hegdevas...@in.ibm.com>
 URL : 
http://sourceforge.net/projects/linux-diag/files/libservicelog/
 License : LGPL-2+
 Section : libs

It builds those binary packages:

  libservicelog-1.1-1 - Library to create and maintain a database for storing 
events
  libservicelog-dev - libservicelog development files

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

https://mentors.debian.net/package/libservicelog


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

  dget -x 
https://mentors.debian.net/debian/pool/main/libs/libservicelog/libservicelog_1.1.16-1.dsc

More information about libservicelog can be obtained from 
http://sourceforge.net/projects/linux-diag/files/libservicelog/

Note:
  This is for Power architectures.
  I initially packaged this for Ubuntu Trusty. I pulled it from Ubuntu did a few
  changes and here it is. It would need to be synced with Ubuntu.


Regards,
 Frederic Bonnard

Bug#826135: RFS: lsvpd/1.7.6-1 ITP: lsvpd -- Utility to List Device Vital Product Data (VPD)

[Frederic Bonnard]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "lsvpd"

 Package name: lsvpd
 Version : 1.7.6-1
 Upstream Author : lsvpd team
 URL : http://sourceforge.net/projects/linux-diag/files/lsvpd/
 License : GPL-2+
 Section : misc

It builds those binary packages:

  lsvpd - Utility to List Device Vital Product Data (VPD)

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

https://mentors.debian.net/package/lsvpd


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

  dget -x https://mentors.debian.net/debian/pool/main/l/lsvpd/lsvpd_1.7.6-1.dsc

More information about lsvpd can be obtained from 
http://sourceforge.net/projects/linux-diag/files/lsvpd/ 

Note:
  This is for Power architectures.
  I initially packaged this for Ubuntu Trusty. I pulled it from Ubuntu did a few
  changes and here it is. It would need to be synced with Ubuntu.


Regards,
 Frederic Bonnard

Bug#826134: RFS: libvpd/2.2.5-1 ITP: libvpd -- VPD Database access library

[Frederic Bonnard]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "libvpd"

 Package name: libvpd
 Version : 2.2.5-1
 Upstream Author : Vasant Hegde <hegdevas...@in.ibm.com>
 URL : 
http://sourceforge.net/projects/linux-diag/files/libservicelog/
 License : LGPL-2+
 Section : libs

It builds those binary packages:

  libvpd-2.2-2 - VPD Database access library
  libvpd-dev - VPD Database access library development files

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

https://mentors.debian.net/package/libvpd


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

  dget -x 
https://mentors.debian.net/debian/pool/main/libv/libvpd/libvpd_2.2.5-1.dsc

More information about libservicelog can be obtained from 
http://sourceforge.net/projects/linux-diag/files/libservicelog/

Note:
  This is for Power architectures.
  I initially packaged this for Ubuntu Trusty. I pulled it from Ubuntu did a few
  changes and here it is. It would need to be synced with Ubuntu.


Regards,
 Frederic Bonnard

Bug#740172: RFS for pulling Ubuntu 5 packages to Debian

[Frederic Bonnard]

Hi Gianfranco,
2 years ago, I created ITPs in Debian for 5 softwares that are part of RAS
(reliability, availability, and serviceability) tools, used on powerpc, ppc64, 
ppc64el.
The packages were taken by Ubuntu devs. Now there are in Ubuntu since Trusty
but not Debian. I asked two times for help, to pull those into Debian :
  https://lists.debian.org/debian-powerpc/2014/10/msg00020.html
  https://lists.debian.org/debian-powerpc/2016/03/msg00090.html

As noone answered since then, I switched those bugs to RFS yesterday, thinking
that it may be a better path for inclusion.
Is that the good way to do ?  Do you have a bit of time to pull those ?
Do you need me to do anything in that direction ?
Thanks,

Fred

Bug#740179: RFS: ppc64-diag -- Platform error log analysis tool and rtas_errd daemon

[Frederic Bonnard]

Some time ago, I packaged ppc64-diag which is used on powerpc/ppc64/ppc64el and 
it
got accepted in Ubuntu Trusty and the followings.
I'd like to see it in Debian ; I already sent two calls for this inclusion :
  https://lists.debian.org/debian-powerpc/2014/10/msg00020.html
  https://lists.debian.org/debian-powerpc/2016/03/msg00090.html
without success.

https://launchpad.net/ubuntu/+source/ppc64-diag

F.

Bug#740173: RFP: lsvpd -- Utility to List Device Vital Product Data (VPD)

[Frederic Bonnard]

Some time ago, I packaged lsvpd which is used on powerpc/ppc64/ppc64el and it
got accepted in Ubuntu Trusty and the followings.
I'd like to see it in Debian ; I already sent two calls for this inclusion :
  https://lists.debian.org/debian-powerpc/2014/10/msg00020.html
  https://lists.debian.org/debian-powerpc/2016/03/msg00090.html
without success.

https://launchpad.net/ubuntu/+source/lsvpd

F.

Bug#740175: RFS: libservicelog -- Library to create and maintain a database for storing events

[Frederic Bonnard]

Some time ago, I packaged libservicelog which is used on powerpc/ppc64/ppc64el 
and it
got accepted in Ubuntu Trusty and the followings.
I'd like to see it in Debian ; I already sent two calls for this inclusion :
  https://lists.debian.org/debian-powerpc/2014/10/msg00020.html
  https://lists.debian.org/debian-powerpc/2016/03/msg00090.html
without success.

https://launchpad.net/ubuntu/+source/libservicelog

F.

Bug#740176: RFS: servicelog -- Platform Service/Error Message Database

[Frederic Bonnard]

Some time ago, I packaged servicelog which is used on powerpc/ppc64/ppc64el and 
it
got accepted in Ubuntu Trusty and the followings.
I'd like to see it in Debian ; I already sent two calls for this inclusion :
  https://lists.debian.org/debian-powerpc/2014/10/msg00020.html
  https://lists.debian.org/debian-powerpc/2016/03/msg00090.html
without success.

https://launchpad.net/ubuntu/+source/servicelog

F.

Bug#740172: RFS for libvpd

[Frederic Bonnard]

Some time ago, I packaged libvpd which is used on powerpc/ppc64/ppc64el and it
got accepted in Ubuntu Trusty and the followings.
I'd like to see it in Debian ; I already sent two calls for this inclusion :
  https://lists.debian.org/debian-powerpc/2014/10/msg00020.html
  https://lists.debian.org/debian-powerpc/2016/03/msg00090.html
without success.

https://launchpad.net/ubuntu/+source/libvpd

F.

Bug#825289: sphde: Build takes forever

[Frederic Bonnard]

> amd64, nothing special.
> 
> Based on past experience, I suspect of some kind of weird interaction
> between sbuild, eatmydata, systemd and/or the kernel from stretch, or maybe
> the build process just does not fail gracefully on systems not having
> a lot of memory (the bad build logs I have so far happened on machines
> having 1GB RAM and 2GB swap).

Thanks for sharing your intuition on that. I'll have a look.

F.

Bug#825289: sphde: Build takes forever

[Frederic Bonnard]

Hi Santigao,
thanks for the report and details. I'd like to try to reproduce it, but
I couldn't find on which architecture you had this bug.
Could you tell me ?

F.

On Wed, 25 May 2016 17:03:36 +0200, Santiago Vila  wrote:
> I forgot: Eventually, sbuild stops the build and shows a message like
> this:
> 
> --
> [...]
> PASS: sphsinglepcqueue_tt
> PASS: sphsinglepcqueue_ttt
> make[4]: *** Deleting file 'sphdirectpcqueue_ttt.log'
> Terminated
> Makefile:2012: recipe for target 'sphdirectpcqueue_ttt.log' failed
> make[4]: *** [sphdirectpcqueue_ttt.log] Terminated
> Makefile:1858: recipe for target 'check-TESTS' failed
> make[3]: *** [check-TESTS] Terminated
> Makefile:2064: recipe for target 'check-am' failed
> make[2]: *** [check-am] Terminated
> Makefile:542: recipe for target 'check-recursive' failed
> make[1]: *** [check-recursive] Terminated
> E: Caught signal ‘Terminated’: terminating immediately
> debian/rules:7: recipe for target 'build-indep' failed
> make: *** [build-indep] Terminated
> E: Build killed with signal TERM after 150 minutes of inactivity
> --
> 
> Thanks.
> 

Bug#813603: RFS: libcxl/1.3-1 [ITP] -- libcxl -- Coherent accelerator shared library

[Frederic Bonnard]

Hi,
here is a new packaging for a new release of libcxl 1.4.
https://mentors.debian.net/package/libcxl
https://mentors.debian.net/debian/pool/main/libc/libcxl/libcxl_1.4-1.dsc

Fixes :
- control == 3.9.7
- copyright : license changed to Apache for debian/
- rules : simplified after a few patches sent upstream
- I also took : "debian/rules: override dh_makeshlibs to force dpkg-gensymbols 
to
fail if symbols appear that were not added to the symbols file." from what
Ubuntu changed https://bugs.launchpad.net/ubuntu/+bug/1541457/comments/13 .

I still needed a patch for the Makefile to fix a lintian issue, that I've sent
upstream : https://github.com/ibm-capi/libcxl/pull/15

F.


On Fri, 1 Apr 2016 19:53:47 + (UTC), Gianfranco Costamagna 
<costamagnagianfra...@yahoo.it> wrote:
> control: owner -1 !
> control: tags -1 moreinfo
> 
> Hi,
> 
> control: std-version 3.9.7
> copyright: please don't mix GPL and Apache, or other people won't be able to 
> forward patches upstream.
> 
> outfile <-- remove?
> 
> rules:
> 
> make --> $(MAKE) please
> 
> mkdir -p $(CURDIR)/debian/tmp/usr/$(LIBDIR) $(CURDIR)/debian/tmp/usr/include
> cp libcxl.a libcxl.so.$(VERS_LIB) $(CURDIR)/debian/tmp/usr/$(LIBDIR)
> cp libcxl.h $(CURDIR)/debian/tmp/usr/include
> cd $(CURDIR)/debian/tmp/usr/$(LIBDIR) && ln -sf libcxl.so.$(VERS_LIB) 
> libcxl.so.1
> cd $(CURDIR)/debian/tmp/usr/$(LIBDIR) && ln -sf libcxl.so.1 libcxl.so
> 
> 
> this should be handled by upstream makefile, there is no good reason for 
> doing it
> in rules (and other linux distro won't benefit from it)
> 
> check-all-the-things:
> $ flawfinder -Q -c .
> $ codespell --quiet-level=3
> 
> the other stuff looks good to me, but I didn't try to build it yet.
> 
> 
> 
> Il Mercoledì 3 Febbraio 2016 16:15, Frederic Bonnard 
> <fre...@linux.vnet.ibm.com> ha scritto:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "libcxl"
> 
> Package name: libcxl
> Version : 1.3-1
> Upstream Author : CAPI team
> URL : https://github.com/ibm-capi/libcxl
> License : Apache-2.0
> Section : libs
> 
> It builds those binary packages:
> 
>   libcxl-dev - Coherent accelerator shared library development files
>   libcxl1- Coherent accelerator shared library
> 
> To access further information about this package, please visit the following 
> URL:
> 
>   http://mentors.debian.net/package/libcxl
> 
> 
> Alternatively, one can download the package with dget using this command:
> 
> dget -x 
> http://mentors.debian.net/debian/pool/main/libc/libcxl/libcxl_1.3-1.dsc
> 
> More information about libcxl can be obtained from 
> https://github.com/ibm-capi/libcxl
> 
> Note:
> This library is specific to ppc64 and ppc64el architectures and requires
> a specific CAPI FPGA accelerator card.
> 
> Regards,
> Frederic Bonnard
> 

Bug#813603: RFS: libcxl/1.3-1 [ITP] -- libcxl -- Coherent accelerator shared library

[Frederic Bonnard]

Hi Mattia and Gianfranco,
yes I haven't answered recently because I've been working with upstream to tune
the installation part and deal with the interface version that was not
correctly handled. The patch is pushed upstream and I've asked for a new
tarball release this morning which should come soon as they also want to put
some other improvements inside as well.
The packaging in Ubuntu is mine ; Ubuntu guys were kind enough to accept it 
though
the 2 previous points needed to be improved
: https://bugs.launchpad.net/ubuntu/+bug/1541457/comments/10
Sorry for not updating ; I should come with something much better :)
As usual, thanks for advising,

F.


In-Reply-To: <20160523091952.ga6...@chase.mapreri.org>

On Mon, 23 May 2016 09:19:55 +, Mattia Rizzolo  wrote:
> Hi Frederic,
> 
> On Mon, May 09, 2016 at 10:53:18PM +0200, Gianfranco Costamagna wrote:
> > Hi, the package is already in Ubuntu, did you try to look at the packaging 
> > and see if it was similar?
> 
> This was the last recentish email, but anyway there have been 3 replies
> to your RFS request since Feb, but no replies from you.
> 
> Are you still interested in this package?
> 
> -- 
> regards,
> Mattia Rizzolo
> 
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
> more about me:  https://mapreri.org : :'  :
> Launchpad user: https://launchpad.net/~mapreri  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

Bug#823924: py-lmdb : current version packaged is getting old

[Frederic Bonnard]

Source: py-lmdb
Source-Version: 0.86-1


Hi there,
trying to package some python module, I needed py-lmdb >= 0.87 . I see 0.89 is
available upstream.
Any plan to upgrade the version in unstable ?
Thanks a lot,

Fred