Bug#858436: eiskaltdcpp: Please migrate to openssl1.1 in buster

[Boris Pek]

Hi,

> this is a remainder about the openssl transition [0]. We really want to
> remove libssl1.0-dev from unstable for Buster. I will raise the severity
> of this bug to serious in a month. Please react before that happens.
>
> [0] https://bugs.debian.org/871056#55

Just for note. OpenSSL >= 1.1 will be supported in a next stable release of
EiskaltDC++ (2.4.0) which is going to be released soon. I will update the
package once this happens. But updated package should go through NEW queue
due to changing of SOVERSION of internal library. So I cannot predict the
time when package will reach archive.

Best regards,
Boris

Bug#877288: r-base: fix calling methods on dots generics

[Graham Inggs]

Control: reassign -1 src:r-base 3.4.1.20170921-1
Control: affects -1 =
Control: retitle -1 r-base: fix calling methods on dots generics

Hi Dirk

r-bioc-biocgenerics, r-bioc-s4vectors and r-bioc-iranges all got 
workarounds for this and autopkgtests are passing again [1][2].


The regression was fixed in R-3-4-branch r73465.  I have no idea if 
anything else in the archive is affected as not all packages have 
working autopkgtests.  Would you please consider uploading 'R 3.4.2 
Patched' from svn >= r73465?  r73475 includes a test.


Regards
Graham


[1] https://ci.debian.net/packages/r/r-bioc-iranges/unstable/amd64/
[2] 
https://ci.debian.net/packages/r/r-bioc-variantannotation/unstable/amd64/

Bug#878368: Fails to build libnginx-mod-rtmp

[Thomas Leuxner]

Package: nginx
Version: 1.13.6-1
Severity: serious

Hi,

building 1.13.6 fails in my build environment:

dpkg-buildpackage -j16

[...]
 install -d debian/libnginx-mod-rtmp/usr/share/doc/libnginx-mod-rtmp
cp --reflink=auto -a debian/modules/nginx-rtmp/README.md 
debian/libnginx-mod-rtmp/usr/share/doc/libnginx-mod-rtmp
cp: cannot stat ‘debian/modules/nginx-rtmp/README.md’: No such file or directory
dh_installdocs: cp --reflink=auto -a debian/modules/nginx-rtmp/README.md 
debian/libnginx-mod-rtmp/usr/share/doc/libnginx-mod-rtmp returned exit code 1
debian/rules:141: recipe for target 'binary' failed
make: *** [binary] Error 2
dpkg-buildpackage: error: debian/rules binary gave error exit status 2

Building 1.13.5 works fine in the same environment. I was unable to track down 
the actual culprit but it seems to have path issues generating the docs.

Regards
Thomas


signature.asc
Description: PGP signature

Bug#874656: libegl1-mesa: Makes team fortress 2 crash the entire machine

[Andreas Boll]

Control: severity -1 important

(Adding original bug reporter)

On Tue, Oct 03, 2017 at 06:32:25AM +0200, Antoine Le Gonidec wrote:
> On Thu, 28 Sep 2017 23:15:27 +0200 Salvo Tomaselli 
> wrote:
> > I had downgraded my mesa. I wanted to try again but I can't upgrade it
> > because of some llvm breakage at the moment.
> > (…)
> > I seguenti pacchetti hanno dipendenze non soddisfatte:
> > libllvm5.0 : Rompe: libllvm5.0:i386 (!= 1:5.0-2) but 1:5.0-1 is to be 
> > installed
> > libllvm5.0:i386 : Rompe: libllvm5.0 (!= 1:5.0-1) but 1:5.0-2 is installed
> 
> You can still install these packages without waiting for the resolution
> of bug #876752 by forcing the highest common version for these two
> architectures:
> apt install libllvm5.0{,:i386}=1:5.0~+rc2-1
> 
> You need to have the testing repositories in your APT sources or this
> won’t work.
> 

Hi Salvo,

could you try to use llvm from testing?
Does this issue affect other opengl apps (e.g. other (non-)steam games, amd64
games, ...) too?

In the meantime I'm lowering the severity to important to let Mesa
migrate to testing since it blocks lots of packages.

Thanks,
Andreas


signature.asc
Description: PGP signature

Bug#878367: compton FTCBFS: uses the build architecture pkg-config

[Helmut Grohne]

Source: compton
Version: 0.1~beta2+20150922-1
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

compton fails to cross build from source, because its Makefile hard
codes the build architecture pkg-config. After making pkg-config
substitutable (and automatically getting substituted by dh_auto_build),
compton cross builds successfully. Please consider applying the attached
patch.

Helmut
Index: compton-0.1~beta2+20150922/Makefile
===
--- compton-0.1~beta2+20150922.orig/Makefile
+++ compton-0.1~beta2+20150922/Makefile
@@ -2,6 +2,7 @@
 # GNU make may get unhappy.
 
 CC ?= gcc
+PKG_CONFIG ?= pkg-config
 
 PREFIX ?= /usr
 BINDIR ?= $(PREFIX)/bin
@@ -33,7 +34,7 @@
 
   # libconfig-1.3* does not define LIBCONFIG_VER* macros, so we use
   # pkg-config to determine its version here
-  CFG += $(shell pkg-config --atleast-version=1.4 libconfig || echo '-DCONFIG_LIBCONFIG_LEGACY')
+  CFG += $(shell $(PKG_CONFIG) --atleast-version=1.4 libconfig || echo '-DCONFIG_LIBCONFIG_LEGACY')
 endif
 
 #  PCRE regular expression 
@@ -51,7 +52,7 @@
 #  DRM VSync 
 # Enables support for "drm" VSync method
 ifeq "$(NO_VSYNC_DRM)" ""
-  INCS += $(shell pkg-config --cflags libdrm)
+  INCS += $(shell $(PKG_CONFIG) --cflags libdrm)
   CFG += -DCONFIG_VSYNC_DRM
 endif
 
@@ -121,8 +122,8 @@
   # CFLAGS += -Weverything -Wno-disabled-macro-expansion -Wno-padded -Wno-gnu
 endif
 
-LIBS += $(shell pkg-config --libs $(PACKAGES))
-INCS += $(shell pkg-config --cflags $(PACKAGES))
+LIBS += $(shell $(PKG_CONFIG) --libs $(PACKAGES))
+INCS += $(shell $(PKG_CONFIG) --cflags $(PACKAGES))
 
 CFLAGS += -Wall
 

Bug#878326: cups FTCBFS: runs host architecture utilities during build again

[Didier 'OdyX' Raboud]

Control: tags -1 +pending

Le jeudi, 12 octobre 2017, 22.56:25 h CEST Helmut Grohne a écrit :
> Thank you for applying my patch from #837936 to make cups cross build.
> Unfortunately, that no longer works. When cross building cups, mantohtml
> fails to run again (and #837936 was meant to fix that).
> 
> It turns out that man/Makefile is now duplicated to man/Makefile.l10n
> and it compiles its own mantohtml there with the builtin rule. Thus it
> ends up using the wrong compiler and wrong flags. After copying the
> relevant rule to man/Makefile.l10n, cups cross builds again. Please
> consider applying the attached patch.

Thanks for your scrutiny and your patch. Is there a "Cross-Builds Status" page 
I could monitor myself to proactively detect these ?

Cheers,
OdyX

Bug#878366: crossguid FTCBFS: uses the build architecture compiler

[Helmut Grohne]

Source: crossguid
Version: 0.0+git200150803-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

crossguid fails to cross build from source, because it uses the build
architecture compiler (as a make default). After setting CXX as a
triplet-prefixed compiler, crossguid cross compiles successfully. Please
consider applying the attached patch.

Helmut
diff --minimal -Nru crossguid-0.0+git200150803/debian/changelog 
crossguid-0.0+git200150803/debian/changelog
--- crossguid-0.0+git200150803/debian/changelog 2016-05-08 23:12:44.0 
+0200
+++ crossguid-0.0+git200150803/debian/changelog 2017-10-13 10:30:17.0 
+0200
@@ -1,3 +1,10 @@
+crossguid (0.0+git200150803-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Use a triplet-prefixed CXX. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 13 Oct 2017 10:30:17 +0200
+
 crossguid (0.0+git200150803-2) unstable; urgency=medium
 
   * Ensure proper upgrade from libcrossguid0v4
diff --minimal -Nru crossguid-0.0+git200150803/debian/rules 
crossguid-0.0+git200150803/debian/rules
--- crossguid-0.0+git200150803/debian/rules 2016-05-08 23:12:44.0 
+0200
+++ crossguid-0.0+git200150803/debian/rules 2017-10-13 10:30:14.0 
+0200
@@ -1,5 +1,10 @@
 #!/usr/bin/make -f
 
+include /usr/share/dpkg/architecture.mk
+ifeq ($(origin CXX),default)
+CXX := $(DEB_HOST_GNU_TYPE)-g++
+endif
+
 INSTDIRS = debian/tmp/usr/include debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)
 
 %:

Bug#878365: tuxpaint-config FTCBFS: uses the build architecture toolchain

[Helmut Grohne]

Source: tuxpaint-config
Version: 0.0.13-3
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

tuxpaint-config fails to cross build from source, because it uses the
build architecture toolchain (compiler and strip). Letting dh_auto_build
pass cross compilers to make fixes half of that. Then there still is the
-s option to install that breaks cross compilation and -dbgsym packages.
By removing it and thus deferring to dh_strip that is fixed as well.
After applying the attached patch, tuxpaint-config cross builds
successfully. Please consider using it.

Helmut
diff --minimal -Nru tuxpaint-config-0.0.13/debian/changelog 
tuxpaint-config-0.0.13/debian/changelog
--- tuxpaint-config-0.0.13/debian/changelog 2017-08-30 14:13:37.0 
+0200
+++ tuxpaint-config-0.0.13/debian/changelog 2017-10-13 10:23:10.0 
+0200
@@ -1,3 +1,12 @@
+tuxpaint-config (0.0.13-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_build pass cross compilers to make.
++ Let dh_strip perform the stripping. (Also fixes -dbgsym.)
+
+ -- Helmut Grohne   Fri, 13 Oct 2017 10:23:10 +0200
+
 tuxpaint-config (0.0.13-3) unstable; urgency=medium
 
   * QA upload.
diff --minimal -Nru tuxpaint-config-0.0.13/debian/rules 
tuxpaint-config-0.0.13/debian/rules
--- tuxpaint-config-0.0.13/debian/rules 2017-08-30 14:13:37.0 +0200
+++ tuxpaint-config-0.0.13/debian/rules 2017-10-13 10:23:08.0 +0200
@@ -11,10 +11,6 @@
 DPKG_EXPORT_BUILDFLAGS = 1
 include /usr/share/dpkg/buildflags.mk
 
-ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
-   INSTALL_PROGRAM += -s
-endif
-
 configure: configure-stamp
 configure-stamp:
dh_testdir
@@ -29,7 +25,7 @@
dh_testdir
 
# Add here commands to compile the package.
-   $(MAKE) PREFIX=/usr CFLAGS="$(CFLAGS)" CXXFLAGS="$(CXXFLAGS)" 
CPPFLAGS="$(CPPFLAGS)" LDFLAGS="$(LDFLAGS)"
+   dh_auto_build -- PREFIX=/usr CFLAGS="$(CFLAGS)" CXXFLAGS="$(CXXFLAGS)" 
CPPFLAGS="$(CPPFLAGS)" LDFLAGS="$(LDFLAGS)"
 
touch build-stamp
 

Bug#874715: mesa Games like Counter-Strike Global Offensive dont start after upgrading mesa to 17.2.0-2

[Andreas Boll]

Control: severity -1 important

On Mon, Oct 02, 2017 at 09:00:59PM +0200, Dominik Kupschke wrote:
> Hi,
> 
> I was able to start some steam games without steam-runtime.
> Also non Steam Games work properly.
> 
> Regards
> Dominik

Hi,

so it looks like an issue with the steam-runtime. Please report this
issue to Valve on github and let us know the bug number/url for
tracking.

I'm lowering the severity to important to let Mesa migrate to testing
since it blocks lots of packages.

Thanks,
Andreas


signature.asc
Description: PGP signature

Bug#878364: gnucap FTCBFS: fails to find gnucap-modelgen

[Helmut Grohne]

Source: gnucap
Version: 1:0.36~20091207-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

gnucap fails to cross build from source, because it fails to find
gnucap-modelgen. That tool is generated at build time, but since it also
needs to be executed, upstream opted for requiring an existing
gnucap-modelgen for cross builds. Thus "gnucap:native " should
be added to Build-Depends. That is a self-dependency that is only
effective during cross builds and thus it is fine. After doing so,
gnucap cross builds successfully. Please consider applying the attached
patch.

Helmut
diff --minimal -Nru gnucap-0.36~20091207/debian/changelog 
gnucap-0.36~20091207/debian/changelog
--- gnucap-0.36~20091207/debian/changelog   2011-09-27 21:46:06.0 
+0200
+++ gnucap-0.36~20091207/debian/changelog   2017-10-13 10:11:43.0 
+0200
@@ -1,3 +1,10 @@
+gnucap (1:0.36~20091207-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Add gnucap:native to Build-Depends. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 13 Oct 2017 10:11:43 +0200
+
 gnucap (1:0.36~20091207-2) unstable; urgency=low
 
   * debian/control: Bumped Standards-Version to 3.9.2
diff --minimal -Nru gnucap-0.36~20091207/debian/control 
gnucap-0.36~20091207/debian/control
--- gnucap-0.36~20091207/debian/control 2011-09-27 21:46:06.0 +0200
+++ gnucap-0.36~20091207/debian/control 2017-10-13 10:11:41.0 +0200
@@ -7,7 +7,7 @@
Wesley J. Landaker 
 DM-Upload-Allowed: yes
 Standards-Version: 3.9.2
-Build-Depends: debhelper (>= 8), libreadline-dev
+Build-Depends: debhelper (>= 8), libreadline-dev, gnucap:native 
 #, hevea, texlive
 Homepage: http://gnucap.org
 Vcs-Git: git://git.debian.org/git/pkg-electronics/gnucap.git

Bug#878363: cron: Please mark cron as Multi-Arch: foreign

[Ian Campbell]

Package: cron
Version: 3.0pl1-128.1
Severity: wishlist
Tags: patch

Hello,

I have an i386 system which I would like to update a subset of to amd64 (a
partial cross-grade). Two of the packages which I need to install are
mythtv-{database,backend}:amd64 (from dmo) which each have a dependency on cron
which cannot be satisfied by non-multiarch cron:i386 (native for the system).

Marking the package as Multi-Arch: foreign would allow the i386 version to
satisfy those dependencies.

>From https://wiki.ubuntu.com/MultiarchSpec, Multi-Arch: foreign means:

The package is not co-installable and should be allowed to satisfy the
dependencies of a package of another architecture than its own.

Since cron behaves the same whether it is i386 or amd64 I think foreign is
appropriate.

The patch is so trivial I almost hesitate to attach it, but here it is. I've
tested that with this cron:i386 installed the mythtv-{database,backend}:amd64
dependencies are satisfied.

Thanks,
Ian.

-- Package-specific info:
--- EDITOR:
not set

--- /usr/bin/editor:
/bin/nano

--- /usr/bin/crontab:
-rwxr-sr-x 1 root crontab 40264 May  3  2015 /usr/bin/crontab

--- /var/spool/cron:
drwxr-xr-x 5 root root 4096 Oct  8 10:38 /var/spool/cron

--- /var/spool/cron/crontabs:
drwx-wx--T 2 root crontab 4096 Sep 27 09:38 /var/spool/cron/crontabs

--- /etc/cron.d:
drwxr-xr-x 2 root root 4096 Sep 23 18:14 /etc/cron.d

--- /etc/cron.daily:
drwxr-xr-x 2 root root 4096 Sep 23 18:20 /etc/cron.daily

--- /etc/cron.hourly:
drwxr-xr-x 2 root root 4096 Mar 25  2017 /etc/cron.hourly

--- /etc/cron.monthly:
drwxr-xr-x 2 root root 4096 Sep 23 18:13 /etc/cron.monthly

--- /etc/cron.weekly:
drwxr-xr-x 2 root root 4096 Jun 10 13:48 /etc/cron.weekly


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf, armel, arm64

Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cron depends on:
ii  adduser  3.116
ii  debianutils  4.8.2
ii  dpkg 1.18.24
ii  init-system-helpers  1.49
ii  libc62.24-17
ii  libpam-runtime   1.1.8-3.6
ii  libpam0g 1.1.8-3.6
ii  libselinux1  2.7-2
ii  lsb-base 9.20170808

Versions of packages cron recommends:
ii  ssmtp [mail-transport-agent]  2.64-8+b2

Versions of packages cron suggests:
ii  anacron2.3-24
ii  checksecurity  2.0.16+nmu1
ii  logrotate  3.11.0-0.1

Versions of packages cron is related to:
pn  libnss-ldap   
pn  libnss-ldapd  
pn  libpam-ldap   
pn  libpam-mount  
pn  nis   
pn  nscd  

-- no debconf information
diff --git a/debian/control b/debian/control
index c55ab62..6ab8444 100644
--- a/debian/control
+++ b/debian/control
@@ -25,6 +25,7 @@ Depends:
 adduser,
 lsb-base (>= 3.0-10),
 libpam-runtime (>= 1.0.1-11)
+Multi-Arch: foreign
 Recommends:
 exim4 | postfix | mail-transport-agent
 Suggests:

Bug#878362: mozjs52: embedded code copy: icu v58

[Simon McVittie]

Source: mozjs52
Version: 52.3.1-4
Severity: normal
Control: block -1 by 878359
X-Debbugs-Cc: secur...@debian.org

mozjs52 has an embedded code copy of libicu. (The same is true for
firefox-esr and firefox.) It is newer than the current system copy,
so it is not necessarily safe to stop using it right now.

When icu >= 58 reaches testing/unstable (#878359), mozjs52 can hopefully
depend on it as a system library instead, closing this bug in the process.
This would also allow removing a lot of hacks from the mozjs52 packaging.

The major user of mozjs52 is going to be gjs, which is not a security
boundary (it's JavaScript-as-extension-language, the same role that Lua
frequently takes, rather than JavaScript-as-web-content) so this is
probably not security-sensitive for gjs, but it might become
security-sensitive if other packages migrate from mozjs or mozjs24 to
mozjs52.

smcv

Bug#867140: cqrlog: Please migrate to openssl1.1 in Buster

[Colin Tuckley]

> this is a remainder about the openssl transition [0]. We really want to
> remove libssl1.0-dev from unstable for Buster. I will raise the severity
> of this bug to serious in a month. Please react before that happens.

I've talked to upstream about this. Apparently it will be a *lot* of
work due to the API changes without a soname bump. As a result upstream
are giving the required changes a very low priority.

Please do *not* increase the priority of this bug.

The correct thing to do here is to make the old and new versions of
openssl coexist.

Bug#878327: scons printf regression causes many packages to FTBFS

[Jörg Frings-Fürst]

tags 878327 + pending
thanks


Hello Adrian,

thank you for spending your time helping to make Debian better with
this bug report.

I have applied the upstream commit, upload scons to mentors and ask
both mentors for a review and upload.



CU
Jörg

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser

Threema: SYR8SJXB
Wire:  @joergfringsfuerst
Skype: joergpenguin
Ring:  jff

IRC: j_...@freenode.net
 j_...@oftc.net

My wish list: 
 - Please send me a picture from the nature at your home.


signature.asc
Description: This is a digitally signed message part

Bug#878361: qtchooser misinterprets -qtconf

[Helmut Grohne]

Package: qtchooser
Version: 63-g13a3d08-1
Severity: important
User: helm...@debian.org
Usertags: rebootstrap

$ sudo apt-get install qt5-qmake
...
$ qmake -qtconf foo
qmake: could not find a Qt installation of 'conf'
$

That's wrong. qtchooser needs to pass -qtconf down to the actual qmake
rather than interpreting it itself.

Helmut

Bug#877040: New upstream version, including transition to webext

[Paul Wise]

On Thu, 12 Oct 2017 15:15:03 +0300 Adrian Bunk wrote:

> I am immediately raising to RC to make it more visible that based on the 
> current information:

That seems a bit premature, given that Firefox ESR will stay at
version 52 until June 2018 (according to Mozilla #webextensions).

Also, someone should probably announce an MBF for this transition.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Bug#878359: icu: new upstream release 59.1

[Simon McVittie]

Source: icu
Version: 57.1-6
Severity: wishlist

icu has a new upstream release available, which you have already packaged
in experimental. Please upload to unstable at the appropriate time, with
a transition slot from the release team if there's an ABI break.

I'm filing this bug to track its progress into unstable, so that I can
open a bug against mozjs52 for its use of an embedded code copy of icu
58, which can hopefully be discarded when we have icu >= 58 in unstable.
As soon as I have a bug number I'll close this bug as fixed in
experimental.

Thanks,
smcv

Bug#878360: debdate: Change package description to eg "Convert Gregorian dates to Debian Release dates"

[Elena ``of Valhalla'']

Package: debdate
Severity: wishlist

As discussed in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877404
there is a request not to use a name that is suggestive of a monarchy.

Of course, I agree that having a king would be pretty bad for Debian,
altought considering what the release names are this package would refer
at most to a mostly harmless puppet king.

Chris Lamb wrote that:

> "Regnal" is really quite an esoteric English word these days.

This was, however, precisely by design, as this method of dating is
quite an esoteric one that has passed in disuse (for quite a number of
good practical reason).

I've tried to look for another name for this kind of dating, but it
seems to me that at least on the historical articles on wikipedia
"regnal" is the standard name used, even in cases like the roman 
consules that wheren't kings (nor, during the empire, rulers).

Another term that occurs in those articles is "era name", which could be
made to fit, altought it is less precise.

So, if there is a proposal that I've missed that doesn't involve kings
but evokes the same feel of "out of an history wikipedia page" I would
be happy to hear it and change the short description, otherwise I can
try to use something with "era name" or keep the "regnal" one.

In the long description I would continue to use "regnal date" and add
"release date", to ease searching.

Bug#850895: [pkg-bacula-devel] Bug#850895: bacula: Please migrate to openssl1.1 in buster

[Carsten Leonhardt]

Hi Sebastian,

> this is a remainder about the openssl transition [0]. We really want to
> remove libssl1.0-dev from unstable for Buster. I will raise the severity
> of this bug to serious in a month. Please react before that happens.

I'm not sure what my reaction should be.

I myself will not attempt to migrate bacula to the new OpenSSL API, as
my programming experience is insufficient to touch this security
sensitive code.

Upstream does not see a pressing need because OpenSSL version 1.0.2 is
supported until 2019-12-31 - significantly longer than 1.0.2.

Are there any other distributions that already dropped, or will drop
OpenSSL v1.0 support in the near future that I can use as an argument
for upstream?

Lastly, the bug is tagged "help" for quite some time already, but help
doesn't seem to be forthcoming.

Regards,

Carsten

Bug#849832: No longer affects FF55/56

[Gregor Riepl]

According to https://bugzilla.mozilla.org/show_bug.cgi?id=1357323 ,
this bug should no longer affect Firefox 55 and 56, as the gonk code was
removed from the tree.

Please confirm.

Bug#878358: dnprogs FTCBFS: many reasons

[Helmut Grohne]

Source: dnprogs
Version: 2.65
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

dnprogs fails to cross build from source for many reasons. The packaging
runs plain make without passing any cross toolchain, so it ends up using
the build architecture toolchain. Indirecting that through dh_auto_build
fixes that. Then dapfs/Makefile hard codes the build architecture
compiler g++ and that of course fails processing host architecture
object files. During installation, it passes -s to install, which uses
the build architecture strip and thus fails. After fixing all of the
above, dnprogs cross builds successfully. Please consider applying the
attached patch.

Helmut
diff --minimal -Nru dnprogs-2.65/Makefile.common 
dnprogs-2.65+nmu1/Makefile.common
--- dnprogs-2.65/Makefile.common2017-07-06 21:42:10.0 +0200
+++ dnprogs-2.65+nmu1/Makefile.common   2017-10-13 06:57:30.0 +0200
@@ -157,12 +157,6 @@
 DEPLIBDAP=$(TOP)/libdap/libdnet-dap.so
 endif
 
-ifneq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
-STRIPBIN=
-else
-STRIPBIN=-s
-endif
-
 LIBS=$(LIBDAP) $(LIBDNET)
 DEPLIBS=$(DEPLIBDAP) $(DEPLIBDNET)
 
diff --minimal -Nru dnprogs-2.65/dapfs/Makefile dnprogs-2.65+nmu1/dapfs/Makefile
--- dnprogs-2.65/dapfs/Makefile 2011-12-09 15:42:32.0 +0100
+++ dnprogs-2.65+nmu1/dapfs/Makefile2017-10-13 06:57:30.0 +0200
@@ -13,7 +13,7 @@
 CFLAGS=-I../include -I ../librms -Wall $(DFLAGS) -fdollars-in-identifiers
 
 $(PROG1): $(PROG1OBJS) $(DEPLIBS)
-   g++ -o$(PROG1) $(LDFLAGS) $(PROG1OBJS) $(LIBDAP) -L../librms -lrms 
$(LIBDNET) -lfuse -lpthread
+   $(CXX) -o$(PROG1) $(LDFLAGS) $(PROG1OBJS) $(LIBDAP) -L../librms -lrms 
$(LIBDNET) -lfuse -lpthread
 
 install:
install -d $(rootprefix)/sbin
diff --minimal -Nru dnprogs-2.65/debian/changelog 
dnprogs-2.65+nmu1/debian/changelog
--- dnprogs-2.65/debian/changelog   2017-07-06 21:42:10.0 +0200
+++ dnprogs-2.65+nmu1/debian/changelog  2017-10-13 06:57:30.0 +0200
@@ -1,3 +1,13 @@
+dnprogs (2.65+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_build pass cross compilers to make.
++ Do not hard code g++ in dapfs/Makefile.
++ Remove -s from install as dh_strip takes care.
+
+ -- Helmut Grohne   Fri, 13 Oct 2017 06:57:30 +0200
+
 dnprogs (2.65) unstable; urgency=low
 
   * QA upload.
diff --minimal -Nru dnprogs-2.65/debian/rules dnprogs-2.65+nmu1/debian/rules
--- dnprogs-2.65/debian/rules   2014-07-28 12:19:45.0 +0200
+++ dnprogs-2.65+nmu1/debian/rules  2017-10-13 06:57:27.0 +0200
@@ -4,7 +4,7 @@
 
 build:
$(checkdir)
-   make prefix=/usr RELEASE=true BUILDING_DEB=true
+   dh_auto_build -- prefix=/usr RELEASE=true BUILDING_DEB=true
touch build
 
 build-arch: build

Bug#878357: needs cmocka 1.1

[Daniel Baumann]

Package: samba
Version: 2:4.7.0+dfsg-1
Severity: normal

Hi,

samba fails to build from source with cmocka 1.0, please adjust the
build-dependencies to require >= 1.1.

Regards,
Daniel

Bug#878356: cross-gcc-dev should support gcc-8

[Helmut Grohne]

Package: cross-gcc-dev
Severity: important
User: helm...@debian.org
Usertags: rebootstrap

Please add support for gcc-8. That can have multiple forms, each of
which has its own benefit:

a) Just copy the gcc-7 patches to gcc-8 and hope for the best.
b) Make the patches apply to the gcc-8 source package.
c) Verify that a cross compiler can be built.

a) has close to zero effort, b) likely takes an hour or so and c)
longer. If you can do b), that'd be very useful already, but even a)
helps. I'm happy to file followup bug reports with patches. The earlier
we start, the less work we'll have. Go go.

Helmut

Bug#878355: ITP: orocos-bfl -- Orocos Bayesian Filtering Library

[Johannes Schauer]

Package: wnpp
Severity: wishlist
Owner: Johannes Schauer 

* Package name: orocos-bfl
  Version : 0.8.0
  Upstream Author : Tinne De Laet, Klaas Gadeyne
* URL : http://www.orocos.org/bfl
* License : LGPL-2.1+
  Programming Lang: C++
  Description : Orocos Bayesian Filtering Library

Orocos (http://www.orocos.org) is the acronym of the Open Robot Control
Software project. The project's aim is to develop a general-purpose, free
software, and modular framework for robot and machine control.  The Orocos
project supports 4 C++ libraries: the Real-Time Toolkit, the Kinematics and
Dynamics Library, the Bayesian Filtering Library (BFL) and the Orocos
Component Library.

This package provides the Bayesian Filtering Library.

Bug#742704: ImplicitCad in Debian

[Petter Reinholdtsen]

[Julia Longtin]
> Hey, This is Julia Longtin, one of the ImplicitCAD maintainers. I'd like to
> see this in debian as well, but have no idea how to handle the haskell
> dependencies.

I see nothing much happened after this.  May I suggest you join the 3D-printer
packaging team on IRC and discuss how to get the dependencies included?
See https://wiki.debian.org/3D-printer > for team details.

-- 
Happy hacking
Petter Reinholdtsen