Bug#761032: hunspell-nl

[Mattia Rizzolo]

On Thu, Aug 31, 2017 at 07:34:45AM +0200, Rene Engelhard wrote:
> On Wed, Aug 30, 2017 at 11:12:15PM +0200, Mattia Rizzolo wrote:
> > Another possibility, which arguably is nicer for other non-Debian places
> > as well, would be to get upstream of libreoffice-dictionaries to budle a
> > newer version of that dictionary.
> 
> That could be done, but I'd prefer to make dutch build hunspell-nl anyway.
> Building hunspell-* from where they come from imho is preferred.
> 
> Here especially since dutch already builds a hunspell-needing dict in a
> myspell-nl package which should be fixed.

Sure, I wasn't asking against having src:dutch do it.

That said, be aware that the hunspell-nl binary built by
src:libreoffice-dictionaries has an higher version than src:dutch
currently has, so you'd need to take care of it.
Once you take over the binary from src:dutch I'll quickly update
libreoffice-dictionarie to stop building it.

-- 
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  `-


signature.asc
Description: PGP signature

Bug#840540: Raising severity

[Mònica Ramírez Arceda]

On 31/08/17 02:06, Lisandro Damián Nicanor Pérez Meyer wrote:
> On 30 August 2017 at 18:49, Mònica Ramírez Arceda  wrote:
> > Hi!
> >
> > On 30/08/17 23:34, Lisandro Damián Nicanor Pérez Meyer wrote:
> >> Control: severity -1 serious
> >>
> >> Hi! I have just uploaded qoauth to unstable thus starting the transition. 
> >> I don't mind nmuing dianara, feel free to ask me so. I'll do it if I don't 
> >> get any answer in ~2 days.
> > Sorry for the delayed answer. I will try to upload dianara tomorrow. If I 
> > don't do it, feel free to NMU!
> >
> > Thanks!
>
> Gracias a vos!
I have just uploaded dianara 1.3.7-3. I hope everything is working fine!

Bug#873789: init-system-helpers: autopkgtests broken in 1.49

[Steve Langasek]

Source: init-system-helpers
Version: 1.49
Severity: important
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu artful autopkgtest

Dear maintainers,

Since the upload of init-system-helpers 1.48, the autopkgtests for this
package have been consistently failing:

Failed to preset unit: File unitx2dv4Sdm.service: No such file or directory
/tmp/autopkgtest-virt-lxc.shared.f_r1n2_u/downtmp/build.JfZ/init-system-helpers-1.48/t/../script/deb-systemd-helper:
 error: systemctl preset failed on unitx2dv4Sdm.service: No such file or 
directory
not ok 13 - enable command succeeded
[...]
# Looks like you failed 35 tests of 169.
adt-run [05:58:27]: test t: ---]
adt-run [05:58:27]: test t:  - - - - - - - - - - results - - - - - - - - - -
tFAIL non-zero exit status 35

  https://ci.debian.net/packages/i/init-system-helpers/unstable/amd64/

These tests fail in both Debian and Ubuntu.  Unfortunately Debian does not
consider a regressed autopkgtest a blocker for testing (which would be
useful to help us improve the quality of the release), but Ubuntu does; so
this regression will block the new version of init-system-helpers from
inclusion in the next Ubuntu release until fixed.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#873774: Many gui apps become slow responsive after upgrading my sid

[Rolf Leggewie]

On 31.08.2017 09:36, liuxu wrote:
> Package: scim
> Version: 1.4-18
>
> many gui apps in my mate desktop env becomes slow responsive
> [...]
> After purge all scim packages, those problematic apps become normal
> immediately.
> After reinstall scim and scim-pinyin, those apps become probelmatic
> again immediately.

Hello Liuxu,

thank you for your report.  I'm sorry to hear about the troubles you are
facing.

Were you previously using version 1.4.17-1?  Does downgrading to the
version in testing help?

Regards

Rolf

Bug#873788: libqt5gui5: conffiles not removed

[Paul Wise]

Package: libqt5gui5
Version: 5.9.1+dfsg-9
Severity: normal
User: debian...@lists.debian.org
Usertags: obsolete-conffile adequate

The recent upgrade did not deal with obsolete conffiles properly.
Please use the dpkg-maintscript-helper support provided by dh_installdeb
to remove these obsolete conffiles on upgrade.

https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
http://manpages.debian.org/man/1/dh_installdeb

This bug report brought to you by adequate:

http://bonedaddy.net/pabs3/log/2013/02/23/inadequate-software/

$ pkg=libqt5gui5 ; adequate $pkg ; dpkg-query -W -f='${Conffiles}\n' $pkg | 
grep obsolete
libqt5gui5:amd64: obsolete-conffile /etc/X11/Xsession.d/90qt5-opengl
 /etc/X11/Xsession.d/90qt5-opengl fad3b80463bf21409c0ce14a94c2b514 obsolete

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages libqt5gui5 depends on:
ii  fontconfig   2.12.3-0.2
ii  libc62.24-17
ii  libdrm2  2.4.82-1
ii  libegl1-mesa [libegl1-x11]   13.0.6-1+b2
ii  libfontconfig1   2.12.3-0.2
ii  libfreetype6 2.8-0.2
ii  libgbm1  13.0.6-1+b2
ii  libgcc1  1:7.2.0-1
ii  libgl1-mesa-glx [libgl1] 13.0.6-1+b2
ii  libglib2.0-0 2.53.4-3
ii  libharfbuzz0b1.4.2-1
ii  libice6  2:1.0.9-2
ii  libinput10   1.8.0-1
ii  libjpeg62-turbo  1:1.5.2-2
ii  libmtdev11.1.5-1+b1
ii  libpng16-16  1.6.31-1
ii  libqt5core5a [qtbase-abi-5-9-0]  5.9.1+dfsg-9
ii  libqt5dbus5  5.9.1+dfsg-9
ii  libqt5network5   5.9.1+dfsg-9
ii  libsm6   2:1.2.2-1+b3
ii  libstdc++6   7.2.0-1
ii  libudev1 234-2.3
ii  libx11-6 2:1.6.4-3
ii  libx11-xcb1  2:1.6.4-3
ii  libxcb-glx0  1.12-1
ii  libxcb-icccm40.4.1-1+b1
ii  libxcb-image00.4.0-1+b2
ii  libxcb-keysyms1  0.4.0-1+b2
ii  libxcb-randr01.12-1
ii  libxcb-render-util0  0.3.9-1+b1
ii  libxcb-render0   1.12-1
ii  libxcb-shape01.12-1
ii  libxcb-shm0  1.12-1
ii  libxcb-sync1 1.12-1
ii  libxcb-xfixes0   1.12-1
ii  libxcb-xinerama0 1.12-1
ii  libxcb-xkb1  1.12-1
ii  libxcb1  1.12-1
ii  libxi6   2:1.7.9-1
ii  libxkbcommon-x11-0   0.7.1-1
ii  libxkbcommon00.7.1-1
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages libqt5gui5 recommends:
ii  libqt5svg5 5.9.1-2+b1
ii  qt5-gtk-platformtheme  5.9.1+dfsg-9

Versions of packages libqt5gui5 suggests:
pn  qt5-image-formats-plugins  
pn  qtwayland5 

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#871652: jnoise: Italian translation of package description has a little typo

[Andrey Skvortsov]

On 17-08-30 23:23, Mattia Rizzolo wrote:
> Control: tag -1 l10n
> 
> On Thu, Aug 10, 2017 at 02:24:41PM +0200, Leandro Noferini wrote:
> > Package: jnoise
> > Severity: minor
> > 
> > The word "rumero" is a typo for "rumore" -> noise
> 
> This is not coming from the package itself, but from the DDTP.
> CCing debian-i...@lists.debian.org as I have no idea how to update the
> translated description of the packages.

Hi Leandro,

you could use DDTSS for that
https://ddtp2.debian.net/ddtss/index.cgi/it

There is field 'Fetch specific description' with option 'Force
fetching even if not untranslated' there. Put name of your package
there and then you can retranslate package description. Afterwards
someone should review your translation and then it'll
be submitted.

More information you can find here:
https://www.debian.org/international/l10n/ddtp
https://wiki.debian.org/it/L10n/Italian/DDTP/DDTSS/Tools

-- 
Best regards,
Andrey Skvortsov




signature.asc
Description: PGP signature

Bug#761032: hunspell-nl

[Rene Engelhard]

Hi,

On Wed, Aug 30, 2017 at 11:12:15PM +0200, Mattia Rizzolo wrote:
> Another possibility, which arguably is nicer for other non-Debian places
> as well, would be to get upstream of libreoffice-dictionaries to budle a
> newer version of that dictionary.
> 
> Just file a bug in 
> https://bugs.documentfoundation.org/enter_bug.cgi?product=LibreOffice&component=Linguistic
> asking for the nl dictionary to be updated.  If it's an update coming
> from the same source it will be handled very quickly and land in the
> next update.

That could be done, but I'd prefer to make dutch build hunspell-nl anyway.
Building hunspell-* from where they come from imho is preferred.

Here especially since dutch already builds a hunspell-needing dict in a
myspell-nl package which should be fixed.

Regards,

Rene

Bug#849754: RFS: guerillabackup/0.0.0-1

[halfdog]

Hello Andreas,

I did not hear from you after the last mails, see messages from
04 May 2017 21:59, 23 Jun 2017 05:59. Are you still interested
in doing the (quite tricky) review?

I have now also tested the build procedures and the software on
Debian Stretch, see today's upload of package to mentors.debian.org.

Best regards,
hd

Bug#873633: [debhelper-devel] Bug#873633: Bug#873633: Bug#873633: debhelper: Add meson support to debhelper in stable

[Niels Thykier]

W. Martin Borgert:
> On 2017-08-30 20:45, Niels Thykier wrote:
>> I have pre-emptively given you commit access to the debhelper repo, so
>> you should be able to start whenever you are ready.  :)
> 
> Just now I had some free minutes :~)

Great. :)  Thanks for the help. :)

> I hope, I didn't break anything...
> 
> 
> [...]


Looks fine at first glance. :)

Speaking of breakage; if there are any bug reports against the
backported version, then people are very welcome to file them in /
forward them to the BTS against debhelper. :)

Thanks,
~Niels

Bug#873598: spice-gtk: diff for NMU version 0.34-1.1

[Liang Guo]

Hi, Laurent,

On Wed, Aug 30, 2017 at 8:50 PM, Laurent Bigonville  wrote:
> Control: tags 873598 + pending
>
> Dear maintainer,
>
> I've prepared an NMU for spice-gtk (versioned as 0.34-1.1) and
> uploaded it to DELAYED/3. Please feel free to tell me if I
> should delay it longer.
>
> Regards.
> diff -Nru spice-gtk-0.34/debian/changelog spice-gtk-0.34/debian/changelog
> --- spice-gtk-0.34/debian/changelog 2017-08-06 11:02:13.0 +0200
> +++ spice-gtk-0.34/debian/changelog 2017-08-30 14:45:42.0 +0200
> @@ -1,3 +1,13 @@
> +spice-gtk (0.34-1.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * debian/rules: Call the gir sequence so the gir1.2-* packages have the
> +correct dependencies defined. (Closes: #873598)
> +  * Make the gir1.2-* packages Multi-Arch: same
> +  * Add Breaks to force the uninstallation of the old gir1.2-* packages
> +
> + -- Laurent Bigonville   Wed, 30 Aug 2017 14:45:42 +0200
> +
>  spice-gtk (0.34-1) unstable; urgency=medium
>
Please upload 0.34-1 to unstable with no delay.

Thanks for working on spice-gtk.

-- 
Liang Guo
http://guoliang.me/

Bug#873787: gdk-pixbuf: CVE-2017-2870

[Salvatore Bonaccorso]

Source: gdk-pixbuf
Version: 2.36.5-3
Severity: important
Tags: patch security upstream
Forwarded: https://bugzilla.gnome.org/show_bug.cgi?id=780269

Hi,

the following vulnerability was published for gdk-pixbuf.

CVE-2017-2870[0]:
tiff: Check for integer overflows in multiplication

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-2870
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-2870
[1] https://bugzilla.gnome.org/show_bug.cgi?id=780269
[2] https://git.gnome.org/browse/gdk-pixbuf/commit/?id=31a6cff

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#718816: moreutils: split parallel binary in extra package

[Nicolas Schier]

Dear Mika,

> With the upload of parallel 20161222-1
> (https://tracker.debian.org/news/828794) there seems to be a nice
> solution to have parallel and moreutils installed at the same time:

thanks for the pointer.  I don't like that kind of "solution", but as 
moreutils and parallel are now installable at the same time, it is time 
to close this one.

Kind regards,
Nicolas


signature.asc
Description: Digital signature

Bug#871093: ruby-rbnacl: FTBFS: ERROR: Test "ruby2.3" failed.

[Steve Langasek]

Package: ruby-rbnacl
Version: 5.0.0-1
Followup-For: Bug #871093
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu artful ubuntu-patch autopkgtest

The build failure is caused by a bugfix change in libsodium 1.0.13 that
changed the alignment (and therefore the size) of the blake2b_state struct. 
Please find attached a patch for this issue.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru ruby-rbnacl-5.0.0/debian/patches/fix-blake2b_state-struct-size.patch 
ruby-rbnacl-5.0.0/debian/patches/fix-blake2b_state-struct-size.patch
--- ruby-rbnacl-5.0.0/debian/patches/fix-blake2b_state-struct-size.patch
1969-12-31 16:00:00.0 -0800
+++ ruby-rbnacl-5.0.0/debian/patches/fix-blake2b_state-struct-size.patch
2017-08-30 21:05:40.0 -0700
@@ -0,0 +1,30 @@
+Description: pad blake2b_state struct declaration for libsodium 1.0.13
+ libsodium 1.0.13 includes a bugfix to the alignment of the
+ crypto_generichash_blake2b_state struct, which was supposed to be declared
+ CRYPTO_ALIGN(64).  Non-obviously, this refers to 64 *byte* alignment, not
+ 64 *bit* alignment, and accordingly, initialization functions that try to
+ zero out a struct will walk off the end and scribble on memory if the struct
+ they're passed isn't padded out to a multiple of 64.
+ .
+ The size of this struct rounds up to 384 bytes (6*64).  On a 32-bit system
+ (where sizeof(size_t) == 4), the declared members of the struct only add
+ up to 357 bytes.  Add 27 bytes of padding to our allocated struct, so that
+ we allocate enough memory for either 32-bit or 64-bit architectures.
+ (Ideally we would just declare an alignment for the struct the same as we do
+ in GCC, but this doesn't appear to be supported in ffi.)
+Author: Steve Langasek 
+
+Index: ruby-rbnacl-5.0.0/lib/rbnacl/hash/blake2b.rb
+===
+--- ruby-rbnacl-5.0.0.orig/lib/rbnacl/hash/blake2b.rb
 ruby-rbnacl-5.0.0/lib/rbnacl/hash/blake2b.rb
+@@ -175,7 +175,8 @@
+:f, [:uint64, 2],
+:buf, [:uint8, 2 * 128],
+:buflen, :size_t,
+-   :last_node, :uint8
++   :last_node, :uint8,
++   :padding, [:uint8, 27]
+   end
+ end
+   end
diff -Nru ruby-rbnacl-5.0.0/debian/patches/series 
ruby-rbnacl-5.0.0/debian/patches/series
--- ruby-rbnacl-5.0.0/debian/patches/series 2017-07-08 23:57:19.0 
-0700
+++ ruby-rbnacl-5.0.0/debian/patches/series 2017-08-30 20:51:40.0 
-0700
@@ -3,3 +3,4 @@
 0003-Drop-usage-of-git-in-gemspec.patch
 0004-Drop-gem-dependency-on-rbnacl-libsodium.patch
 0005-Drop-development-dependency-on-bundler.patch
+fix-blake2b_state-struct-size.patch

Bug#873786: registration-agent: missing epoch on resiprocate B-D

[Aaron M. Ucko]

Source: registration-agent
Version: 1.3.3-1
Severity: important
Justification: fails to build from source

Builds of registration-agent have been failing on architectures with
old versions of libresiprocate-1.11-dev (so far, the non-release
architectures powerpc and sparc; all release architectures should be
OK here):

  /«PKGBUILDDIR»/registrationAgent.cxx:55:10: error: 'installSignalHandler' was 
not declared in this scope
  [...]
  /«PKGBUILDDIR»/registrationAgent.cxx:183:10: error: 'mainLoop' was not 
declared in this scope

It looks like you have a versioned B-D on libresiprocate-1.11-dev in
an attempt to avoid this situation, but accidentally left off the
epoch ("1:"), so old versions wind up qualifying.  Could you please
account for the epoch?

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

Bug#873785: e-d-s: FTBFS on hurd-i386: i18n::phonenumbers::* symbols missing

[Aaron M. Ucko]

Source: evolution-data-server
Version: 3.24.5-2
Severity: important
Justification: fails to build from source (but built successfully in the past)

Builds of evolution-data-server for hurd-i386 (admittedly not a
release architecture) have been failing lately, presumably because
e-d-s necessarily builds without libphonenumber there.

  +#MISSING: 3.24.5-2# (c++)"i18n::phonenumbers::Logger::WriteLevel()@Base" 
3.24.1
  +#MISSING: 3.24.5-2# 
(c++)"i18n::phonenumbers::NullLogger::WriteMessage(std::__cxx11::basic_string, std::allocator > const&)@Base" 3.24.1
  +#MISSING: 3.24.5-2# 
(c++)"i18n::phonenumbers::NullLogger::~NullLogger()@Base" 3.24.1
  +#MISSING: 3.24.5-2# (c++)"typeinfo for i18n::phonenumbers::Logger@Base" 
3.24.1
  +#MISSING: 3.24.5-2# (c++)"typeinfo for i18n::phonenumbers::NullLogger@Base" 
3.24.1
  +#MISSING: 3.24.5-2# (c++)"typeinfo name for i18n::phonenumbers::Logger@Base" 
3.24.1
  +#MISSING: 3.24.5-2# (c++)"typeinfo name for 
i18n::phonenumbers::NullLogger@Base" 3.24.1
  +#MISSING: 3.24.5-2# (c++)"vtable for i18n::phonenumbers::NullLogger@Base" 
3.24.1

Please accommodate this possibility, and consider also doing without
libphonenumber on kfreebsd-* for now, since it's currently
uninstallable there.

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

Bug#872596: confclerk: infinite loop of error dialogs with DebConf17: UNCAUGHT OrmException: No object exception

[Paul Wise]

On Wed, 2017-08-30 at 22:42 +0200, gregor herrmann wrote:

> I guess you don't have the pentabarf.xml which caused you problems
> lying around somewhere locally?

I don't have it as ConfClerk doesn't appear to cache the file itself.

ConfClerk on my system is still exhibiting the same behaviour, even
after I "Reloaded from URL" for DebConf17.

I then backed up and deleted the ConfClerk database and added the
DebConf17 penta URL and now the issue is resolved.

I restored from the backup, deleted and re-added DebConf17 and the
issue is again resolved.

I was able to fix the issue by executing this SQL on the database:

$ sqlite ~/.local/share/data/Toastfreeware/ConfClerk/ConfClerk.sqlite
sqlite> DELETE FROM event WHERE id='';

I was then able to reintroduce the issue by running this SQL:

$ sqlite ~/.local/share/data/Toastfreeware/ConfClerk/ConfClerk.sqlite
sqlite> INSERT INTO event VALUES((SELECT id FROM conference WHERE 
url='https://debconf17.debconf.org/schedule/pentabarf.xml'),'',1502562600,0,36,'',NULL,NULL,'',NULL,'','',0,0);

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#873525: mrpt: FTBFS on mips64el: test_mrpt_graphslam fails

[Aaron M. Ucko]

JOSE LUIS BLANCO CLARACO  writes:

> Thanks for reporting this one!

Thanks for looking into it!

> Is there a procedure to request temporary access to such a builder machine?

Yes: https://dsa.debian.org/doc/guest-account/

This procedure is simpler if you're already an official DM, but possible
to arrange regardless.

-- 
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

Bug#873775: edb-debugger: FTBFS: ArchTypes.h: No such file or directory

[Marcio de Souza Oliveira]

On Wed, 30 Aug 2017 21:49:29 -0400 "Aaron M. Ucko"  wrote:
> Source: edb-debugger
> Version: 0.9.21-1
> Severity: important
> Tags: upstream
> Justification: fails to build from source
>
> Builds of edb-debugger failed on most platforms with the error
>
> /<>/include/Types.h:318:10: fatal error: ArchTypes.h: No
such file or directory
>
> That's mostly to be expected given limited upstream processor support.

Hi Aaron,

Firstly thanks for you reporting. I will change edb-debugger to build
only i386 and amd64.

> However, it looks like upstream intended to support arm64 but missed
> the fact that it shows up as aarch64, not armv*. Please try patching
> CMakeLists accordingly (on line 78). Also, please consider
> restricting the package's Architecture field so that autobuilders for
> unsupported architectures (all but x86 and ARM) don't bother trying to
> build edb-debugger.

This patch [1] in CMakeLists depends the other files that is not in
upstream release 0.9.21.
For example on line 84:  include_directories("include/arch/arm-generic")

I'm going to talk to the upstream about a new release to support arm.

[1]
https://github.com/eteran/edb-debugger/commit/7c93eb4babb1eff6ffbf418a76d3cae78cad4d2c

Regards,

--
Marcio de Souza Oliveira 



signature.asc
Description: OpenPGP digital signature

Bug#873784: libdazzle: FTBFS on mipsel and ppc64el: test-fuzzy-index fails

[Aaron M. Ucko]

Source: libdazzle
Version: 3.25.91-2
Severity: important
Tags: upstream
Justification: fails to build from source

Thanks for taking care of #873674 promptly!  libdazzle now builds on
most architectures, but still fails on mipsel and ppc64el:

  The output from the failed tests:
  
   9/19 test-fuzzy-indexFAIL 0.22 s
  
  --- command ---
  MALLOC_CHECK_='2' G_DEBUG='gc-friendly' GSETTINGS_BACKEND='memory' 
G_TEST_SRCDIR='/<>/tests' 
G_TEST_BUILDDIR='/<>/obj-mipsel-linux-gnu/tests' 
PYTHONDONTWRITEBYTECODE='yes' 
/<>/obj-mipsel-linux-gnu/tests/test-fuzzy-index
  --- stdout ---
  /Dazzle/Fuzzy/IndexBuilder/basic: OK
  /Dazzle/Fuzzy/Index/basic: 
  ---

  Full log written to 
/<>/obj-powerpc64le-linux-gnu/meson-logs/testlog.txt

I don't have further details or access to testlog.txt, but perhaps you
can reproduce the error on a porter box.

Could you please take a look?

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

Bug#873783: wcc: FTBFS on non-amd64 architectures

[Aaron M. Ucko]

Source: wcc
Version: 0.0.2+dfsg-1
Severity: important
Tags: upstream
Justification: fails to build from source

Builds of wcc for architectures other than (Linux) amd64 have been
failing.

On non-x86 architectures, there are two considerations: the
embedded copy of openlibm under src/wsh generally has no
$(ARCH)/Make.files, and GCC doesn't support -masm=intel regardless.
You could sidestep the former by building against separately packaged
libopenlibm-dev (as called for by Policy 4.13), but the latter may be
more of a problem.

On non-Linux architectures (kFreeBSD and presumably also the Hurd if
and when clang becomes installable there), there's no 
for arch.h to include.

On i386, wsh somehow winds up compiled for the wrong architecture,
leading to link errors:

  /usr/bin/ld: skipping incompatible 
/usr/lib/gcc/i686-linux-gnu/7/../../../i386-linux-gnu/libiberty.a when 
searching for -liberty
  /usr/bin/ld: skipping incompatible /usr/lib/i386-linux-gnu/libiberty.a when 
searching for -liberty
  /usr/bin/ld: cannot find -liberty

On x32 (admittedly not a release architecture), wcc is still in the
Needs-Build queue; I'm not sure what will happen there.

At any rate, I'm reporting this as a single bug because I suspect you
may just want to declare Architecture: amd64 (with the possible
addition of x32) and be done with it.  That said, you're certainly
welcome to address any or all of these portability issues if feasible.

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

Bug#873467: db5.3: FTBFS on mips64el

[Salvatore Bonaccorso]

Control: notfound -1 5.3.28-13.1

This was given back once on buildds and has builded fine.

Regards,
Salvatore

Bug#873782: svgpp: FTBFS when not building libsvgpp-doc

[Aaron M. Ucko]

Source: svgpp
Version: 1.2.3+dfsg1-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Builds of svgpp covering only its architecture-dependent binary
packages (as on the autobuilders or with dpkg-buildpackage -B) have
been failing:

 debian/rules override_dh_sphinxdoc
  make[1]: Entering directory '/<>/svgpp-1.2.3+dfsg1'
  dh_sphinxdoc
  dh_sphinxdoc: Sphinx documentation not found
  find debian/libsvgpp-doc/usr/share/doc/libsvgpp-doc/html -type f -print0 | 
xargs -0 sed -i 
's/https:\/\/cdn\.mathjax\.org\/mathjax\/latest/\/usr\/share\/javascript\/mathjax/g'
  find: 'debian/libsvgpp-doc/usr/share/doc/libsvgpp-doc/html': No such file or 
directory
  sed: no input files
  debian/rules:18: recipe for target 'override_dh_sphinxdoc' failed
  make[1]: *** [override_dh_sphinxdoc] Error 123
  make[1]: Leaving directory '/<>/svgpp-1.2.3+dfsg1'
  debian/rules:6: recipe for target 'binary-arch' failed
  make: *** [binary-arch] Error 2

Could you please take a look?  It would probably suffice to rename
override_dh_sphinxdoc to override_dh_sphinxdoc-indep.  (Also, you
might consider giving sed an alternative delimiter such as | or , to
avoid needing to escape all the slashes, but that's purely cosmetic.)

Thanks!

FTR, I'm classifying this bug as a regression because it would affect
binNMUs on amd64.

-- 
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

Bug#873781: ocaml-gen: FTBFS without ocamlopt: /usr/lib/ocaml/gen/*.a missing

[Aaron M. Ucko]

Source: ocaml-gen
Version: 0.4.0.1-1
Severity: important
Justification: fails to build from source

Builds of ocaml-gen for architectures lacking ocamlopt (so far, mips,
ppc64el, s390x, and the non-release architectures hppa, ppc64, and
sparc64) have been failing:

  is_native: ... false
  [...]
  dh_install --fail-missing
  dh_install: Please use dh_missing --list-missing/--fail-missing instead
  dh_install: This feature will be removed in compat 11.
  dh_install: Cannot find (any matches for) "/usr/lib/ocaml/gen/*.a" (tried in 
., debian/tmp)

  dh_install: libgen-ocaml-dev missing files: /usr/lib/ocaml/gen/*.a
  dh_install: missing files, aborting

Could you please take a look and either accommodate or explicitly
exclude these architectures?

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

Bug#853122: Same Error

[Carl N]

I am getting the same error

kernel: sp5100_tco: I/O address 0x0cd6 already in use

Is there a solution yet?

Carl

Bug#873780: mozjs52: FTBFS on kfreebsd-amd64: tests time out

[Aaron M. Ucko]

Source: mozjs52
Version: 52.3.1-3
Severity: important
Tags: upstream
Justification: fails to build from source

The build of mozjs52 for kfreebsd-amd64 (admittedly not a release
architecture) failed:

  TEST-KNOWN-FAIL | ecma_7/TypedObject/memory.js | (args: "") | (SKIP)
  TEST-PASS | ecma_7/Syntax/non-simple-with-strict-directive.js | (args: "")
  E: Caught signal ‘Terminated’: terminating immediately
  [...]
  Build killed with signal TERM after 150 minutes of inactivity

It's not clear from the log which test wound up triggering the
timeout; the order of tests appears to be random, and neither (Linux)
amd64 nor kfreebsd-i386 have the same order of tests prior to
ecma_7/Syntax/non-simple-with-strict-directive.js.  Perhaps you can
reproduce the problem on a porter box, though.

Could you please take a look?

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

Bug#873779: mozjs52: FTBFS on hurd-i386: platform gnu0 is not supported

[Aaron M. Ucko]

Source: mozjs52
Version: 52.3.1-3
Severity: important
Tags: upstream
Justification: fails to build from source

The mozjs build for hurd-i386 (admittedly not a release architecture)
failed:

  platform gnu0 is not supported
  
  Error processing command. Ignoring because optional. 
(optional:setup.py:python/psutil:build_ext:--inplace)
  Reexecuting in the virtualenv
  checking for a shell... /bin/sh
  checking for host system type... Traceback (most recent call last):

Could you please take a look?  The Linux settings should probably make
a decent starting point.

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

Bug#873778: mozjs52: FTBFS: Failed to test XUL condition

[Aaron M. Ucko]

Source: mozjs52
Version: 52.3.1-3
Severity: serious
Tags: upstream
Justification: fails to build from source (but built successfully in the past)

Builds of mozjs52 for several platforms failed with similar errors, as
detailed at
https://buildd.debian.org/status/logs.php?pkg=mozjs52&ver=52.3.1-3 and
excerpted below.

Could you please take a look?

Thanks!

On armel:

File "/<>/js/src/tests/lib/manifest.py", line 143, in 
_parse_one
  if xul_tester.test(cond):
File "/<>/js/src/tests/lib/manifest.py", line 110, in test
  cond, out, err))
  Exception: Failed to test XUL condition 'Android'; output was '', stderr was 
'Assertion failure: !joinable(), at 
/<>/js/src/threading/Thread.h:122\n'

On mips, s390x, and the non-release architectures powerpc and sparc64:

File "/<>/js/src/tests/lib/manifest.py", line 143, in 
_parse_one
  if xul_tester.test(cond):
File "/<>/js/src/tests/lib/manifest.py", line 110, in test
  cond, out, err))
  Exception: Failed to test XUL condition 'Android'; output was '', stderr was 
''

On the non-release architecture ppc64:

File "/<>/js/src/tests/lib/manifest.py", line 134, in 
_parse_one
  if xul_tester.test(cond):
File "/<>/js/src/tests/lib/manifest.py", line 110, in test
  cond, out, err))
  Exception: Failed to test XUL condition '!xulRuntime.shell'; output was '', 
stderr was ''

-- 
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

Bug#873777: ITP: whatthepatch -- Library for parsing patch files

[Reinhard Tartler]

Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler 

* Package name: whatthepatch
  Version : 0.0.5
  Upstream Author : Christopher S. Corley
* URL : https://github.com/cscorley/whatthepatch
* License : MIT
  Programming Lang: Python
  Description : Library for parsing patch files

Proposed package description:

 What The Patch!? is a library for parsing patch files. Its only purpose
 is to read a patch file and get it into some usable form by other
 programs.

Co-maintainers welcome, I'm interested in this package because one of my
pet packages, undertaker, ships tools that require this library, cf.
#860298

Bug#873776: edb-debugger: FTBFS on kFreeBSD and the Hurd

[Aaron M. Ucko]

Source: edb-debugger
Version: 0.9.21-1
Severity: important
Tags: upstream
Justification: fails to build from source

Builds of edb-debugger for kFreeBSD and the Hurd (admittedly not
release architectures) have been failing due to assorted small
formalities:

- On hurd-i386:

/<>/src/Debugger.cpp: In member function 'void 
Debugger::attach(pid_t)':
/<>/src/Debugger.cpp:2915:27: error: 'getpid' was not declared 
in this scope
  edb::pid_t current_pid = getpid();

  Please #include  on all Unix platforms, not just Linux and
  OpenBSD.  I'm not sure offhand whether  will be needed here
  as well, but it's certainly also available.

- On kfreebsd-amd64:

/«PKGBUILDDIR»/include/Types.h:318:10: fatal error: ArchTypes.h: No such 
file or directory

  (as in #873775), presumably because uname reports amd64 rather than
  x86_64.

- On kfreebsd-i386 (and presumably also kfreebsd-amd64 once you've
  taken care of the include path):

/«PKGBUILDDIR»/plugins/HeapAnalyzer/DialogHeap.cpp:383:4: error: #error 
"Unsupported Platform"
   #error "Unsupported Platform"
^
/«PKGBUILDDIR»/plugins/HeapAnalyzer/DialogHeap.cpp:491:4: error: #error 
"Unsupported Platform"
   #error "Unsupported Platform"
^
  These are probably over-conservative and OK to loosen.

Could you please take a look?

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

Bug#873774: Many gui apps become slow responsive after upgrading my sid

[liuxu]

Package: scim
Version: 1.4-18

many gui apps in my mate desktop env becomes slow responsive
after uprading my sid and restarting my notebook.
The problematic apps include mate-ternimal, firefox and chromium,
but don't include xterm, liferea, caja and mate menus.
".xsession-erros" shows "failed to initialize scim".
After purge all scim packages, those problematic apps become normal immediately.
After reinstall scim and scim-pinyin, those apps become probelmatic again 
immediately.

This problem may be related to scim-im-agent or scim-gtk-immodule instead.

Bug#873775: edb-debugger: FTBFS: ArchTypes.h: No such file or directory

[Aaron M. Ucko]

Source: edb-debugger
Version: 0.9.21-1
Severity: important
Tags: upstream
Justification: fails to build from source

Builds of edb-debugger failed on most platforms with the error

  /<>/include/Types.h:318:10: fatal error: ArchTypes.h: No such 
file or directory

That's mostly to be expected given limited upstream processor support.
However, it looks like upstream intended to support arm64 but missed
the fact that it shows up as aarch64, not armv*.  Please try patching
CMakeLists accordingly (on line 78).  Also, please consider
restricting the package's Architecture field so that autobuilders for
unsupported architectures (all but x86 and ARM) don't bother trying to
build edb-debugger.

Please note that edb-debugger is still in the Needs-Build queue on
both armel and armhf, so I don't know how complete its ARM support is
in general, but recognizing arm64 properly should at least help that
build make progress.

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

Bug#870837: pygobject FTBFS

[Jeremy Bicha]

Control: reassign -1 pygobject 3.22.0-2

pygobject simply needs to be updated.

Thanks,
Jeremy Bicha

Bug#824382: feed2imap: script to export OPML from configuration

[Antoine Beaupre]

Control: forwarded -1 https://github.com/feed2imap/feed2imap/pull/22
Control: tags -1 +patch

On Sun, May 15, 2016 at 04:20:28PM +0800, Paul Wise wrote:
> Package: feed2imap
> Version: 1.2.5-1
> Severity: wishlist
> File: /usr/bin/feed2imap-opmlexport
> 
> rss2email has an option to export OPML from the configuration.
> Since OPML is the standard interchange format for RSS feed reader
> configuration it would be nice if feed2imap could allow export to OPML
> for people who want to switch to a different feed reading system.

I wrote one, attached.

It's in Python, unfortunately, but if you're going to migrate to
rss2email, you'll need that anyways.

A.
#!/usr/bin/python

from __future__ import division, absolute_import
from __future__ import print_function, unicode_literals


from datetime import datetime
import fileinput


from xml.sax.saxutils import escape
import yaml


def main():
buf = ''
for line in fileinput.input():
buf += line.decode('utf-8')
feeds = yaml.load(buf)
body = ''
xml_tmpl = '''
  
{title}
{date}
  
  
{body}
'''
outline_tmpl = ''
for feed in feeds['feeds']:
body += outline_tmpl.format(name=escape(feed['name']),
url=escape(feed['url'])) + "\n"
output = xml_tmpl.format(title='feed2imap RSS feeds',
 date=datetime.now(),
 body=body).encode('utf-8')
print(output)


if __name__ == '__main__':
main()


signature.asc
Description: PGP signature

Bug#826014: feed2imap: cache.rb:84:in `load': incompatible marshal file format (can't be read) (TypeError)

[Antoine Beaupre]

Control: forward -1 https://github.com/feed2imap/feed2imap/issues/12
Control: tags -1 +patch

On Wed, Jun 29, 2016 at 04:44:27PM +0200, Matteo Calorio wrote:
> Hello, any news about that? Thanks, Matteo

This is not on load, but there's an upstream bug for the write part:

https://github.com/feed2imap/feed2imap/issues/12

With a possible patch:

https://github.com/feed2imap/ruby-feedparser/pull/6/files


signature.asc
Description: PGP signature

Bug#456819: feed2imap: Please support setting IMAP server info once, not per-feed

[Antoine Beaupre]

On Tue, Dec 18, 2007 at 12:24:08AM -0800, Josh Triplett wrote:
> Package: feed2imap
> Version: 0.9.2-1
> Severity: wishlist
> 
> I want to subscribe to various feeds, with all items going to the same
> IMAP server.  Please allow setting the IMAP server once, not per-feed.

Not sure this is a very well documented feature, but I use this at home:

target-refix: &target "maildir:///home/anarcat/Maildir/.feeds."
feeds:
- name: Ikiwiki recent changes
  url: http://ikiwiki.info/recentchanges/index.rss
  target: [ *target, 'releases' ]
- name: Ikiwiki-hosting RecentChanges
  url: http://ikiwiki-hosting.branchable.com/recentchanges/index.rss
  target: [ *target, 'releases' ]

that avoids repeating the target configuration. note the typo in
"target-prefix": i don't quite understand why, but it works here.

This is also documented in the sample configuration file, does that
answer your requirement?

A.

PS: btw, gna.org is dead now, so it's good the report was copied here.
:)

-- 
Quidquid latine dictum sit, altum sonatur.
Whatever is said in Latin sounds profound.


signature.asc
Description: PGP signature

Bug#873627: udisks2 in sid apparently left me with a borked system in plasma(?)

[Ben Caradoc-Davies]

udisks2 is now uninstallable on sid because of #873748:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=873748

Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Bug#864241: RFS: pnmixer/0.7.2-1 -- Simple mixer application for system tray

[Arnaud]

Hi all, sorry for late reply !

>
> > > Done, the watch file seem to work according to `uscan`, but
> > mentors.debian.net says there's a problem. I'm not sure what's wrong.
> >
> > Take a look on [1] as an example, your `watch` file is broken
> > presumably since you're calling `uupdate` directly.
> >
> > [1]https://wiki.debian.org/debian/watch#GitHub
>

Thanks for the reference !

I updated and fixed the watch file, I can now execute the command `uscan
-dd -v`
successfully.

I uploaded a new revision of the package to Mentors. However the web
interface
there still tells me that the watch file does not work. Does Mentors
support the
watchfile version 4 ?

>
> what is the status of this RFS?
>

Hi Gianfranco,

this RFS is still waiting.

Cheers !
  Arnaud

Bug#831521: Custom repacking

[Sergio Durigan Junior]

On Monday, August 28 2017, Osamu Aoki wrote:

>> diff --git a/scripts/uscan.pl b/scripts/uscan.pl
>> index f871daf2..49a7acb2 100755
>> --- a/scripts/uscan.pl
>> +++ b/scripts/uscan.pl
>> @@ -60,8 +60,9 @@ than the last upstream version.
>>  =item * B saves the downloaded tarball to the parent B<../> 
>> directory:
>>  I<< ../-.tar.gz >>
>>  
>> -=item * B invokes B to create the source tarball: I<<
>> -../_.orig.tar.gz >>
>> +=item * B invokes B to create the source tarball:
>> +I<< ../_.orig.tar.gz >> (if F
>> +exists and is executable, then execute it instead).
>>  
>>  =over
>>  
>> @@ -706,7 +707,8 @@ doesn't work.
>>  
>>  B invokes B to create the source tarball properly named
>>  for the source package with B<.orig.> (or B<< .orig-. >> for the
>> -secondary tarballs) in its filename.
>> +secondary tarballs) in its filename.  If F exists and 
>> is
>> +executable, then B invokes it instead.
>>  
>>  =over
>>  
>> @@ -3764,7 +3766,15 @@ EOF
>>  my $path = "$destdir/$newfile_base";
>>  my $target = $newfile_base;
>>  unless ($symlink eq "no") {
>> -my @cmd = ("mk-origtargz");
>> +my @cmd = ();
>> +if (-x 'debian/mk-origtargz') {
>> +# If the user has specified a personalized 'mk-origtargz'
>> +# under debian/, we use it instead of the system script.
>> +push @cmd "debian/mk-origtargz";
>> +uscan_verbose "Using debian/mk-origtargz instead of mk-origtargz\n";
>> +} else {
>> +push @cmd "mk-origtargz";
>> +}
>>  push @cmd, "--package", $pkg;
>>  push @cmd, "--version", $common_mangled_newversion;
>>  push @cmd, '--repack-suffix', $options{repacksuffix} if defined 
>> $options{repacksuffix};
>
> Yes, this is what I am talking about.  Maybe, we should add
> F in the same way. 
>
> Adding these features are easy but let's go slow.  Once we add any
> features, we can't remove them easily.  Let's wait and check if there
> are no objection or second thought.

Yeah, adding debian/update can be done later, prefereably in another bug
I think :-).

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#873508: sparse test failures on ppc32le (and other not so common archs)

[Christopher Li]

On Wed, Aug 30, 2017 at 1:36 PM, Uwe Kleine-König  
wrote:
>> >
>> > diff --git a/validation/backend/sum.c b/validation/backend/sum.c
>> > index 0604299..d0be8dd 100644
>> > --- a/validation/backend/sum.c
>> > +++ b/validation/backend/sum.c
>> > @@ -1,3 +1,5 @@
>> > +#define __powerpc64__
>> > +#define _CALL_ELF 2
>> >  #include 
>> >  #include 
>> >
>> >
>>
>> Yep, sparse/sparsec do not define various macros that gcc/clang define
>> by default on a given architecture. This is a known problem (that I have
>> been meaning to fix ...). The 'workaround' for the time being is to use
>> the cgcc front-end to sparse. (for example 'make CC=cgcc', or perhaps
>> 'cgcc -no-compile').
>>
>> [You didn't mention your usage - is this for a kernel build?]
>
> This problem became visible during the make check phase when creating packaged
> on the listed archs for horst[1]. You can see a build logs at
>
> 
> https://buildd.debian.org/status/fetch.php?pkg=horst&arch=s390x&ver=5.0-1&stamp=1503905687&raw=0
> 
> https://buildd.debian.org/status/fetch.php?pkg=horst&arch=ppc64el&ver=5.0-1&stamp=1503906226&raw=0
>
> The error message looks identical (I checked the ppc64el log) to the
> problem with backend/sum.c:
>
> sparse -g -O2 -fdebug-prefix-map=/<>=. 
> -fstack-protector-strong -Wformat -Werror=format-security -std=gnu99 -Wall 
> -Wextra -g -I. -DDO_DEBUG -I/usr/include/libnl3 *.[ch]
> /usr/include/powerpc64le-linux-gnu/gnu/stubs.h:8:12: error: unable to 
> open 'gnu/stubs-32.h'

That is very much like on x86_64 missing define "#weak_define __x86_64__ 1"

Does cgcc work for you? In the future we do want to move the archetecture
related define from cgcc into sparse by itself. For now you can set
"sparse" as "cgcc -no-compile"

Chris

Bug#840540: Raising severity

[Lisandro Damián Nicanor Pérez Meyer]

On 30 August 2017 at 18:49, Mònica Ramírez Arceda  wrote:
> Hi!
>
> On 30/08/17 23:34, Lisandro Damián Nicanor Pérez Meyer wrote:
>> Control: severity -1 serious
>>
>> Hi! I have just uploaded qoauth to unstable thus starting the transition. I 
>> don't mind nmuing dianara, feel free to ask me so. I'll do it if I don't get 
>> any answer in ~2 days.
> Sorry for the delayed answer. I will try to upload dianara tomorrow. If I 
> don't do it, feel free to NMU!
>
> Thanks!

Gracias a vos!

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

Bug#873525: mrpt: FTBFS on mips64el: test_mrpt_graphslam fails

[JOSE LUIS BLANCO CLARACO]

Dear Aaron,  (cc: Santiago)

Thanks for reporting this one!

I spent some time debugging this issue raised in mips64el and the only
suspicious operations in that code area (detected with GCC sanitizers)
have been fixed upstream with the patch in [1].

Unfortunately, I have no easy way (qemu aside...) to test the
compilation of the package in this architecture to assess whether the
bug has really gone; realistically, the bug might probably still be
there, and more testing would be required.

I found out [2] that there is one porter box named "eller.debian.org"
which may be useful to debug this issue...
Is there a procedure to request temporary access to such a builder machine?

Last year I read about this same topic and arrived to the conclusion
that "the way" was to apply to become a "Debian Maintainer"... what do
you think about this?

Best,
JL

[1] https://github.com/MRPT/mrpt/commit/440e1d8aa677933f7954c4ae4f0b086fa4e24761
[2] 
https://wiki.debian.org/MIPSPort?action=show&redirect=mips64el#Development_Team
[3] https://wiki.debian.org/DebianMaintainer#Becoming_a_Debian_Maintainer


On Mon, Aug 28, 2017 at 8:11 PM, Aaron M. Ucko  wrote:
> Source: mrpt
> Version: 1:1.5.3-1
> Severity: serious
> Justification: fails to build from source (but built successfully in the past)
>
> The latest mips64el build of mrpt failed:
>
>   cd /<>/obj-mips64el-linux-gnuabi64/tests && 
> ./test_mrpt_graphslam
>   [==] Running 4 tests from 2 test cases.
>   [--] Global test environment set-up.
>   [--] 2 tests from GraphSlamLevMarqTester2D
>   [ RUN  ] GraphSlamLevMarqTester2D.OptimizeSampleRingPath
>   /<>/libs/graphslam/src/graph_slam_levmarq_unittest.cpp:59: 
> Failure
>   Expected: (levmarq_info.final_total_sq_error) <= (1e-2), actual: 534.008 vs 
> 0.01
>   Bus error
>   tests/CMakeFiles/run_tests_mrpt_graphslam.dir/build.make:60: recipe for 
> target 'tests/CMakeFiles/run_tests_mrpt_graphslam' failed
>
> Could you please take a look?
>
> 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

-- 
___

Jose Luis Blanco-Claraco
Universidad de Almería - Departamento de Ingeniería
https://w3.ual.es/~jlblanco/
https://github.com/jlblancoc
___

Bug#873765: gnome-tweak-tool: Error on start: GLib-GIO-ERROR

[Jeremy Bicha]

Control: severity -1 serious

Sorry about this. I wasn't aware that this required gnome-shell >=
3.24. The good news is that we are working on getting gnome-shell 3.24
into unstable but it will probably be a few more days.

Thanks,
Jeremy Bicha

Bug#872252: Debian squeak-vm bug #862576 etoys: Doesn't get beyond Squeak security key generation

[David T. Lewis]

On Wed, Aug 30, 2017 at 08:08:57AM +0200, Petter Reinholdtsen wrote:
> 
> Hi, and thank you for reaching out.
> 

Hi Petter,

You raised a number of questions in your reply. I do not know the answers,
but I will try to add some clarifications where I can.

> 
> One thing that would help the maintainers is to know which of the 5 patches in
> https://sources.debian.net/patches/squeak-vm/1:4.10.2.2614-4.1/ >
> are now included in the official upstream source.  Can you tell?
> 

I do not know. I am not aware of any patches originating from the Debian
team, so it is quite likely that they are not present in the upstream
sources, or that the underlying concerns may have been addressed in other
ways.

> > The current sources are easily compiled, and are known to work with
> > the Etoys image on recent Debian-based distributions. Having said
> > that, I do not know for sure, and cannot guarantee, that there will
> > not be issues on the latest Debian version. However, if problems arise
> > I am fairly confident that we will be able to resolve them through a
> > bit of email collaboration.
> 
> Is it running in valgrind without any issues reported?  Does it build
> with both the most recent gcc and clang compilers?  Those tests tend to
> weed out quite a few bugs, so I thought it best to ask early. :)

I don't know. Someone will have to try it and find out. I cannot do it.

> 
> > What we need to do:
> >
> > Replace the old source package for squeak-vm with a source snapshot based
> > on the current upstream sources at squeak-vm.org. I expect that this will
> > produce a reliable squeak-vm for both 32-bit and 64-bit distributions. We
> > will need to confirm this by running Etoys on the new VM.
> 
> Why a snapshot and not a release?
> 

Because I thought that it might help you or others to do a quick check to
confirm whether or not the compiled VM works on Debian for Etoys.

If you are able to confirm that the upstream sources work on the latest Debian,
and also that Etoys works properly with that VM, then I am sure we can arrange
an official release on the Squeak side to support the Debian efforts.

> -- 
> Happy hacking
> Petter Reinholdtsen

Thanks Petter, I hope this helps a bit.

Dave

Bug#789927: libanthyinput0: fails to upgrade from 'sid' - trying to overwrite /usr/lib/x86_64-linux-gnu/libanthyinput.so.0.0.0'

[astian]

Control: affects -1 ibus-anthy
Control: found -1 ibus-anthy/1.5.9-2
Control: found -1 anthy/1:0.3-5

Hi,

Packaging is still broken on sid.  (Interesting how 2 years of forewarning
were still not sufficient to prevent this.)

  $ sudo apt install ibus-anthy
  Reading package lists... Done
  Building dependency tree
  Reading state information... Done
  Some packages could not be installed. This may mean that you have
  requested an impossible situation or if you are using the unstable
  distribution that some required packages have not yet been created
  or been moved out of Incoming.
  The following information may help to resolve the situation:

  The following packages have unmet dependencies:
   ibus-anthy : Depends: libanthy0 but it is not going to be installed
  E: Unable to correct problems, you have held broken packages.

Note: I have *not* held packages.

Anyway, it seems to me that the problem is not difficult to identify (though I
can't give great insight about the solution): it is obvious that the groups of
packages  and  conflict, yet there are
many (IME-related) packages (such as ibus-anthy, or kasumi) that depend on
both "anthy" (which now pulls in libanthy1 and libanthyinput0) and
"libanthy0", which is an unworkable situation.

Now, I wonder, why does libanthy0 have to still exist (in parallel to the new
libanthy1 and libanthyinput0)?  Why not simply replacing the dependency in all
packages dependent on libanthy0 (and then maybe even removing libanthy0)?
Just thinking out loud.

You might want to take a look at the graph below showing some anthy-related
dependencies on Debian unstable (I had to edit it by hand because both
"apt-cache dotty" and "debtree" are too under-featured).

Thanks.

--

digraph packages {
concentrate=true;
size="30,40";
"ibus-anthy" -> "anthy";
"ibus-anthy" -> "ibus";
"libanthyinput0" -> "libanthy1";
"libanthyinput0" -> "anthy"[color=springgreen];
"anthy" -> "anthy-common";
"anthy" -> "libanthy1";
"anthy" -> "libanthyinput0";
"anthy" -> "anthy-common"[color=springgreen];
"libanthy0" -> "anthy-common";
"libanthy1" -> "anthy-common";

"uim-dict-gtk3" -> "libanthy0";
"uim-dict-gtk" -> "libanthy0";
"uim-anthy" -> "libanthy0";
"hime-anthy" -> "libanthy0";
"gcin-anthy" -> "libanthy0";
"uim-dict-gtk3" -> "libanthy0";
"uim-dict-gtk" -> "libanthy0";
"uim-anthy" -> "libanthy0";
"fcitx-anthy" -> "libanthy0";
"uim-dict-gtk3" -> "libanthy0";
"uim-dict-gtk" -> "libanthy0";
"uim-anthy" -> "libanthy0";
"scim-anthy" -> "libanthy0";
"m17n-lib-mimx" -> "libanthy0";
"ibus-anthy" -> "libanthy0";
"hime-anthy" -> "libanthy0";
"gcin-anthy" -> "libanthy0";
"kasumi" -> "libanthy0";

"ibus-anthy" [shape=box];
"anthy-common" [shape=box];
"ibus" [color=orange,shape=box];
"libanthyinput0" [shape=box];
"anthy" [shape=box];
"libanthy0" [shape=box];
"libanthy1" [shape=box];

"uim-dict-gtk3" [shape=box];
"uim-dict-gtk" [shape=box];
"uim-anthy" [shape=box];
"hime-anthy" [shape=box];
"gcin-anthy" [shape=box];
"uim-dict-gtk3" [shape=box];
"uim-dict-gtk" [shape=box];
"uim-anthy" [shape=box];
"fcitx-anthy" [shape=box];
"uim-dict-gtk3" [shape=box];
"uim-dict-gtk" [shape=box];
"uim-anthy" [shape=box];
"scim-anthy" [shape=box];
"m17n-lib-mimx" [shape=box];
"hime-anthy" [shape=box];
"gcin-anthy" [shape=box];
"kasumi" [shape=box];
}

Bug#873602: pd-xsample FTBFS on ppc64el: UInt32 does not name a type

[Roberto Oliveira]

Hi,

I did a fix for this package and I'm sending the debdiff attached to this bug.

I also sent the patch upstream but it was not reviewed yet [1].


--
[1] - https://github.com/g/xsample/pull/3


fix_ftbfs_ppc64le.debdiff
Description: Binary data

Bug#873739: uim-anthy: Package uim-anthy is uninstallable

[NOKUBI Takatsugu]

anthy had released the new upstrem version, and changed library ABI.
uim is still depend on libanthy0, but it has gone.

So we need to adopt new anthy ABI/API, especially default encoding
(switched from EUC-JP to UTF-8).

We uim maintainers are going to deal the problem on the experimental.
Our works and TODO list is there:
https://wiki.debian.org/JapaneseEnvironment/Uim

Bug#870204: RFS: openfst/1.6.3-1 -- weighted finite-state transducers library

[Giulio Paci]

Il giorno 31/ago/2017 00:25, "Adam Borowski"  ha
scritto:
>
> On Wed, Aug 30, 2017 at 10:58:05PM +0200, Adam Borowski wrote:
> > On Wed, Aug 30, 2017 at 10:37:43PM +0200, Giulio Paci wrote:
> > > Are you able to try it on the kfreebsd-i386 building machine?
> >
> > You do know you have a kfreebsd-i386 capable machine right on your desk,
> > right?  All you need is qemu or virtualbox [...]
>
> > I've started a build (-smp 4 -m 2048 but no
DEB_BUILT_OPTIONS=parallel=X)
> > but you can do this on your machine whenever you wish.

I know it. It is just a temporary lack of time and bandwidth. :-)

> Test build succeeded.  I'm running another, this time with parallel=4
(same
> VM settings), but it smells good enough.
>
> Do we want this version uploaded?

I think so.

Cheers,
Giulio

Bug#869097: Sphinsearch crash dump

[Maxime “pep” Buquet]

On Sat, 22 Jul 2017 17:49:14 +0100 Maxime Buquet  wrote:
> https://github.com/sphinxsearch/sphinx/commit/e14a9bc5b63d9399dbabad4e63313079e4c6e8bb

> I uploaded a new release into unstable with this patch.
> Can you guys have a test?
> 
> If it works well, I will start the process to upload it to Stretch.

You uploaded the wrong patch. They do have the same commit message and
fix a similar problem though.

You uploaded: 1c1800755d99e4c5d3cfb5d15ac316383dc97cbd
The correct commit is: e14a9bc5b63d9399dbabad4e63313079e4c6e8bb

I suppose you can leave the current one as well as it obviously fixes
things, and fixing things is always good :)

Thanks

-- 
Maxime “pep” Buquet


signature.asc
Description: PGP signature

Bug#870204: RFS: openfst/1.6.3-1 -- weighted finite-state transducers library

[Adam Borowski]

On Wed, Aug 30, 2017 at 10:58:05PM +0200, Adam Borowski wrote:
> On Wed, Aug 30, 2017 at 10:37:43PM +0200, Giulio Paci wrote:
> > Are you able to try it on the kfreebsd-i386 building machine?
> 
> You do know you have a kfreebsd-i386 capable machine right on your desk,
> right?  All you need is qemu or virtualbox [...]

> I've started a build (-smp 4 -m 2048 but no DEB_BUILT_OPTIONS=parallel=X)
> but you can do this on your machine whenever you wish.

Test build succeeded.  I'm running another, this time with parallel=4 (same
VM settings), but it smells good enough.

Do we want this version uploaded?


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!?
⢿⡄⠘⠷⠚⠋⠀ -- Genghis Ht'rok'din
⠈⠳⣄ 

Bug#864831: [Debian-science-sagemath] NTL update to 10.3.0

[Ximin Luo]

Ximin Luo:
> Julien Puydt:
>> Hi,
>>
>> Le 29/08/2017 à 14:25, Tobias Hansen a écrit :
>>> Now is a good time for the NTL transition. Julien, could you update the
>>> package to 10.3.0? Then we can test-build the reverse dependencies and
>>> ask for a transition.
>>
>> Indeed there was a soname version bump from 27 to 35, so a transition is
>> in order.
>>
>> There also was a change of license, so I changed d/copyright -- I would
>> be glad if someone could check the result.
>>
>> Finally, lintian complains about hardening-no-fortify-functions and
>> hardening-no-bindnow, which means there's more digging to do for me.
>>
> 
> I'd ignore both:
> 
> 1. hardening-no-fortify-functions happens naturally when the library does not 
> use any libc functions that change under -D_FORTIFY_SOURCE=2 and this is 
> probably a false positive
> 
> 2. hardening-no-bindnow is just due to dpkg-buildflags not defaulting that to 
> on. If you really want to fix it you can
> 
> export DEB_BUILD_MAINT_OPTIONS=hardening=+bindnow
> 
> but IMO this is better fixed in dpkg-buildflags itself as a matter of Debian 
> policy.
> 
>> I still pushed this work-in-progress, as it should be good enought for
>> some tests already.
>>
> 
> I will have a go at testing it tomorrow/soon. Thanks!
> 

BTW, please don't forget about the other bug involving gf2x, #872711

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#860055: Inquiry about packaging progress

[Christoph Biedl]

Christoph Biedl wrote...

> * The build failure on i386 (also seen on armhf) and probably
>   all other 32bit archs needs to be fixed.

There we go:

--- a/debian/rules
+++ b/debian/rules
@@ -9,6 +9,7 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 # see ENVIRONMENT in dpkg-buildflags(1)
 # package maintainers to append CFLAGS
 #export DEB_CFLAGS_MAINT_APPEND  = -Wall -pedantic
+export DEB_CFLAGS_MAINT_APPEND  = -D_FILE_OFFSET_BITS=64 -DLARGEFILE_SOURCE=1
 # package maintainers to append LDFLAGS
 #export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed

Was fairly obivous in the gpgme documenation. Build passes on all
tested architectures, amd64, i386, armhf.

Now would please somebody finish the job? :->

Christoph



signature.asc
Description: Digital signature

Bug#864831: [Debian-science-sagemath] NTL update to 10.3.0

[Ximin Luo]

Julien Puydt:
> Hi,
> 
> Le 29/08/2017 à 14:25, Tobias Hansen a écrit :
>> Now is a good time for the NTL transition. Julien, could you update the
>> package to 10.3.0? Then we can test-build the reverse dependencies and
>> ask for a transition.
> 
> Indeed there was a soname version bump from 27 to 35, so a transition is
> in order.
> 
> There also was a change of license, so I changed d/copyright -- I would
> be glad if someone could check the result.
> 
> Finally, lintian complains about hardening-no-fortify-functions and
> hardening-no-bindnow, which means there's more digging to do for me.
> 

I'd ignore both:

1. hardening-no-fortify-functions happens naturally when the library does not 
use any libc functions that change under -D_FORTIFY_SOURCE=2 and this is 
probably a false positive

2. hardening-no-bindnow is just due to dpkg-buildflags not defaulting that to 
on. If you really want to fix it you can

export DEB_BUILD_MAINT_OPTIONS=hardening=+bindnow

but IMO this is better fixed in dpkg-buildflags itself as a matter of Debian 
policy.

> I still pushed this work-in-progress, as it should be good enought for
> some tests already.
> 

I will have a go at testing it tomorrow/soon. Thanks!

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#767982: Pending fixes for bugs in the aspectj-maven-plugin package

[pkg-java-maintainers]

tag 767982 + pending
thanks

Some bugs in the aspectj-maven-plugin package are closed in revision
4bc53fc2e837c75ab00d7bf7888f553763d970d1 in branch 'master' by
Emmanuel Bourg

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/aspectj-maven-plugin.git/commit/?id=4bc53fc

Commit message:

Keep the profiles in the pom to resolve the path to tools.jar (Closes: 
#767982)

Bug#873773: whysynth plugin library fails to load

[mchristias]

Package: whysynth
Version: 20090403-1.2+b2
Severity: important

Dear Maintainer,

After installing whysynth we can see it in the dssi list (terminal output):

user:~$ dssi_list_plugins
warning: DSSI_PATH not set, defaulting to '/usr/local/lib/dssi:/usr/lib/dssi'
/usr/lib/dssi/whysynth.so
WhySynth  WhySynth 20090403 DSSI plugin

But ghostess cannot load it (terminal output):

user:~$ ghostess /usr/lib/dssi/whysynth.so
ghostess: ghostess starting...
ghostess: failed to load plugin library /usr/lib/dssi/whysynth.so

Muse and carla also fail to load it.

-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages whysynth depends on:
ii  libasound2   1.1.3-5
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-11+deb9u1
ii  libcairo21.14.8-1
ii  libfftw3-single3 3.3.5-3
ii  libfontconfig1   2.11.0-6.7+b1
ii  libfreetype6 2.6.3-3.2
ii  libgdk-pixbuf2.0-0   2.36.5-2
ii  libglib2.0-0 2.50.3-2
ii  libgtk2.0-0  2.24.31-2
ii  liblo7   0.28-5+b2
ii  libpango-1.0-0   1.40.5-1
ii  libpangocairo-1.0-0  1.40.5-1
ii  libpangoft2-1.0-01.40.5-1

whysynth recommends no packages.

Versions of packages whysynth suggests:
pn  dssi-host-jack  
ii  qjackctl0.4.4-1
pn  vkeybd  

Bug#873772: lua-torch-cwrap autopkgtest must allow-stderr

[Steve Langasek]

Package: lua-torch-cwrap
Version: 0~20160222-gdbd0a62-4
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu artful ubuntu-patch autopkgtest

Dear maintainer,

The lua-torch-cwrap package works fine on most architectures, but it fails
on ppc64el and s390x in Ubuntu because these architectures don't have
luajit, only lua5.1; and by default, it's considered an error for an
autopkgtest to produce output on stderr:

autopkgtest [16:24:18]: test lua.require: [---
/tmp/autopkgtest.VpDUrM/build.isG/lua-torch-cwrap-0~20160222-gdbd0a62/debian/tests/lua.require:
 5: 
/tmp/autopkgtest.VpDUrM/build.isG/lua-torch-cwrap-0~20160222-gdbd0a62/debian/tests/lua.require:
 luajit: not found
/tmp/autopkgtest.VpDUrM/build.isG/lua-torch-cwrap-0~20160222-gdbd0a62/debian/tests/lua.require:
 test ok
autopkgtest [16:24:19]: test lua.require: ---]
autopkgtest [16:24:19]: test lua.require:  - - - - - - - - - - results - - - - 
- - - - - -
lua.require  FAIL stderr: 
/tmp/autopkgtest.VpDUrM/build.isG/lua-torch-cwrap-0~20160222-gdbd0a62/debian/tests/lua.require:
 5: 
/tmp/autopkgtest.VpDUrM/build.isG/lua-torch-cwrap-0~20160222-gdbd0a62/debian/tests/lua.require:
 luajit: not found
autopkgtest [16:24:20]: test lua.require:  - - - - - - - - - - stderr - - - - - 
- - - - -
/tmp/autopkgtest.VpDUrM/build.isG/lua-torch-cwrap-0~20160222-gdbd0a62/debian/tests/lua.require:
 5: 
/tmp/autopkgtest.VpDUrM/build.isG/lua-torch-cwrap-0~20160222-gdbd0a62/debian/tests/lua.require:
 luajit: not found
autopkgtest [16:24:20]:  summary
lua.require  FAIL stderr: 
/tmp/autopkgtest.VpDUrM/build.isG/lua-torch-cwrap-0~20160222-gdbd0a62/debian/tests/lua.require:
 5: 
/tmp/autopkgtest.VpDUrM/build.isG/lua-torch-cwrap-0~20160222-gdbd0a62/debian/tests/lua.require:
 luajit: not found

  http://autopkgtest.ubuntu.com/packages/l/lua-torch-cwrap/artful/ppc64el

The attached simple patch lets the autopkgtest pass on all Ubuntu
architectures.

This is a low-priority bug for Debian, since Debian only runs autopkgtests
on two architectures, both of which have luajit available.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru lua-torch-cwrap-0~20160222-gdbd0a62/debian/tests/control 
lua-torch-cwrap-0~20160222-gdbd0a62/debian/tests/control
--- lua-torch-cwrap-0~20160222-gdbd0a62/debian/tests/control2017-07-26 
00:02:38.0 -0700
+++ lua-torch-cwrap-0~20160222-gdbd0a62/debian/tests/control2017-08-30 
15:03:18.0 -0700
@@ -1 +1,2 @@
 Tests: lua.require
+Restrictions: allow-stderr

Bug#873633: [debhelper-devel] Bug#873633: Bug#873633: debhelper: Add meson support to debhelper in stable

[W. Martin Borgert]

On 2017-08-30 20:45, Niels Thykier wrote:
> I have pre-emptively given you commit access to the debhelper repo, so
> you should be able to start whenever you are ready.  :)

Just now I had some free minutes :~)
I hope, I didn't break anything...


signature.asc
Description: PGP signature

Bug#840540: Raising severity

[Mònica Ramírez Arceda]

Hi!

On 30/08/17 23:34, Lisandro Damián Nicanor Pérez Meyer wrote:
> Control: severity -1 serious
>
> Hi! I have just uploaded qoauth to unstable thus starting the transition. I 
> don't mind nmuing dianara, feel free to ask me so. I'll do it if I don't get 
> any answer in ~2 days.
Sorry for the delayed answer. I will try to upload dianara tomorrow. If I don't 
do it, feel free to NMU!

Thanks!

Bug#873771: stretch-pu: package evolution/3.22.6-1+deb9u1

[Phil Wyett]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Hi,

Please consider for stretch pu. debdiff attached.

A functionality update that fixes severe application hangs when you mouse right
click in the email composer window for spell checking or other available task.

Original bug report upstream:

https://bugzilla.gnome.org/show_bug.cgi?id=777086

Debian BTS bug, now closed:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871626

Debian RFS, superseded by upload into unstable after 17 day wait and nobody
stepped forward to sponsor:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872022

Regards

Phil

-- 
*** If this is a mailing list, I am subscribed, no need to CC me.***

Playing the game for the games sake.

Web: https://kathenas.org

Twitter: kathenasorg

Instagram: kathenasorgdiff -Nru evolution-3.22.6/debian/changelog evolution-3.22.6/debian/changelog
--- evolution-3.22.6/debian/changelog	2017-03-13 23:51:12.0 +
+++ evolution-3.22.6/debian/changelog	2017-08-13 17:01:34.0 +0100
@@ -1,3 +1,11 @@
+evolution (3.22.6-1+deb9u1) stretch; urgency=normal
+
+  * Non-maintainer upload.
+  * Added debian/patches/20_composer_hangs_right_click.patch.
+- Backport patch from git - Fix hangs on right click in composer window.
+
+ -- Phil Wyett   Sun, 13 Aug 2017 17:01:34 +0100
+
 evolution (3.22.6-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru evolution-3.22.6/debian/patches/20_composer_hangs_right_click.patch evolution-3.22.6/debian/patches/20_composer_hangs_right_click.patch
--- evolution-3.22.6/debian/patches/20_composer_hangs_right_click.patch	1970-01-01 01:00:00.0 +0100
+++ evolution-3.22.6/debian/patches/20_composer_hangs_right_click.patch	2017-08-13 16:59:10.0 +0100
@@ -0,0 +1,104 @@
+Description: Backported patch from git - Fix hangs on right click in composer
+ window.
+Bug-GNOME: https://bugzilla.gnome.org/show_bug.cgi?id=777086
+
+---
+Index: b/e-util/e-html-editor.c
+===
+--- a/e-util/e-html-editor.c	2017-08-10 02:19:27.349879933 +0100
 b/e-util/e-html-editor.c	2017-08-10 02:25:30.691503859 +0100
+@@ -488,36 +488,73 @@
+ 	g_strfreev (languages);
+ }
+
++typedef struct _ContextMenuData {
++	GWeakRef *editor_weakref; /* EHTMLEditor * */
++	EContentEditorNodeFlags flags;
++	guint button;
++	guint32 time;
++} ContextMenuData;
++
++static void
++context_menu_data_free (gpointer ptr)
++{
++	ContextMenuData *cmd = ptr;
++
++	if (cmd) {
++		e_weak_ref_free (cmd->editor_weakref);
++		g_free (cmd);
++	}
++}
++
++static gboolean
++html_editor_show_context_menu_idle_cb (gpointer user_data)
++{
++	ContextMenuData *cmd = user_data;
++	EHTMLEditor *editor;
++
++	g_return_val_if_fail (cmd != NULL, FALSE);
++
++	editor = g_weak_ref_get (cmd->editor_weakref);
++	if (editor) {
++		GtkWidget *menu;
++
++		menu = e_html_editor_get_managed_widget (editor, "/context-menu");
++
++		g_signal_emit (editor, signals[UPDATE_ACTIONS], 0, cmd->flags);
++
++		if (!gtk_menu_get_attach_widget (GTK_MENU (menu)))
++			gtk_menu_attach_to_widget (GTK_MENU (menu), GTK_WIDGET (editor), NULL);
++
++		gtk_menu_popup (GTK_MENU (menu), NULL, NULL, NULL,
++			GTK_WIDGET (e_html_editor_get_content_editor (editor)), cmd->button, cmd->time);
++
++		g_object_unref (editor);
++	}
++
++	return FALSE;
++}
++
+ static gboolean
+ html_editor_context_menu_requested_cb (EContentEditor *cnt_editor,
+EContentEditorNodeFlags flags,
+GdkEvent *event,
+EHTMLEditor *editor)
+ {
+-	GtkWidget *menu;
++	ContextMenuData *cmd;
++
++	g_return_val_if_fail (E_IS_HTML_EDITOR (editor), FALSE);
++
++	cmd = g_new0 (ContextMenuData, 1);
++	cmd->editor_weakref = e_weak_ref_new (editor);
++	cmd->flags = flags;
+
+-	/* COUNT FLAGS */
+-	menu = e_html_editor_get_managed_widget (editor, "/context-menu");
++	if (!event || !gdk_event_get_button (event, &cmd->button))
++		cmd->button = 0;
+
+-	g_signal_emit (editor, signals[UPDATE_ACTIONS], 0, flags);
++	cmd->time = event ? gdk_event_get_time (event) : gtk_get_current_event_time ();
+
+-	if (!gtk_menu_get_attach_widget (GTK_MENU (menu)))
+-		gtk_menu_attach_to_widget (GTK_MENU (menu),
+-	   GTK_WIDGET (editor),
+-	   NULL);
+-
+-	if (event)
+-		gtk_menu_popup (
+-			GTK_MENU (menu), NULL, NULL, NULL,
+-			GTK_WIDGET (cnt_editor),
+-			((GdkEventButton*) event)->button,
+-			((GdkEventButton*) event)->time);
+-	else
+-		gtk_menu_popup (
+-			GTK_MENU (menu), NULL, NULL, NULL,
+-			GTK_WIDGET (cnt_editor),
+-			0,
+-			gtk_get_current_event_time ());
++	g_idle_add_full (G_PRIORITY_LOW, html_editor_show_context_menu_idle_cb,
++		cmd, context_menu_data_free);
+
+ 	return TRUE;
+ }
diff -Nru evolution-3.22.6/debian/patches/series evolution-3.22.6/debian/patches/series
--- evolution-3.22.6/debian/patches/series	2016-11-0

Bug#873770: update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults

[積丹尼 Dan Jacobson]

Package: mdadm
Version: 4.0-1

I see
"update-rc.d: warning: start and stop actions are no longer supported; falling 
back to defaults"



Setting up mdadm (4.0-1) ...
update-initramfs: deferring update (trigger activated)
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.12.0-1-amd64
Found initrd image: /boot/initrd.img-4.12.0-1-amd64
Found linux image: /boot/vmlinuz-4.11.0-2-amd64
Found initrd image: /boot/initrd.img-4.11.0-2-amd64
Found linux image: /boot/vmlinuz-4.11.0-1-amd64
Found initrd image: /boot/initrd.img-4.11.0-1-amd64
done
update-rc.d: warning: start and stop actions are no longer supported; falling 
back to defaults
Setting up binutils-common:amd64 (2.29-8) ...
Setting up p11-kit-modules:amd64 (0.23.8-1) ...
Processing triggers for libc-bin (2.25-0experimental3) ...
Setting up libperl5.26:amd64 (5.26.0-6) ...
Setting up epiphany-browser-data (3.24.3-1) ...

Bug#873768: update-alternatives: warning: alternative /usr/bin/prename (part of link group rename) doesn't exist; removing from list of alternatives

[積丹尼 Dan Jacobson]

Package: perl
Version: 5.26.0-6

Setting up perl (5.26.0-6) ...
update-alternatives: warning: alternative /usr/bin/prename (part of link group 
rename) doesn't exist; removing from list of alternatives
update-alternatives: warning: /etc/alternatives/rename is dangling; it will be 
updated with best choice

Bug#873103: [release.debian.org] Plan for imagemagick7 landing before next stable

[Moritz Mühlenhoff]

On Thu, Aug 24, 2017 at 05:23:53PM +0200, Bastien ROUCARIÈS wrote:
> Package: release.debian.org
> Severity: wishlist
> 
> Hi,
> 
> I plan to release imagemagick 7 before next stable version. And I want to 
> coexist imagemagick6 and imagemagick7.

Why? That means twice the security updates (which are already a big
resource hog). We only do that in exceptional cases and this doesn't
sound like one.

All existing reverse dependencies can be converted before the freeze.

Cheers,
Moritz

Bug#873769: dpkg: warning: unable to delete old directory '/etc/gnome/epiphany': Directory not empty

[積丹尼 Dan Jacobson]

Package: epiphany-browser-data
Version: 3.24.3-1

Unpacking epiphany-browser-data (3.24.3-1) over (3.22.7-1) ...
dpkg: warning: unable to delete old directory '/etc/gnome/epiphany': Directory 
not empty
dpkg: warning: unable to delete old directory '/etc/gnome': Directory not empty

Still there: /etc/gnome/epiphany/mime-types-permissions.xml

Bug#840540: Raising severity

[Lisandro Damián Nicanor Pérez Meyer]

Control: severity -1 serious

Hi! I have just uploaded qoauth to unstable thus starting the transition. I
don't mind nmuing dianara, feel free to ask me so. I'll do it if I don't
get any answer in ~2 days.

Thanks!

Bug#873767: W: mdadm: failed to auto-generate the mdadm.conf file

[積丹尼 Dan Jacobson]

Package: initramfs-tools
Version: 0.130

Processing triggers for initramfs-tools (0.130) ...
update-initramfs: Generating /boot/initrd.img-4.12.0-1-amd64
W: mkconf: MD subsystem is not loaded, thus I cannot scan for arrays.
W: mdadm: failed to auto-generate the mdadm.conf file.
W: mdadm: please read /usr/share/doc/mdadm/README.upgrading-2.5.3.gz .

Also there is no such file in /usr/share/doc/mdadm/

Hope I can still boot...

Bug#849505: transition: nodejs

[Emilio Pozuelo Monfort]

On 29/08/17 23:15, Sebastiaan Couwenberg wrote:
> On 06/25/2017 01:15 PM, Jonathan Wiltshire wrote:
>> Now stretch is released we can deal with this.
>>
>> On Wed, Dec 28, 2016 at 12:49:33AM +0100, Jérémy Lal wrote:
>>> Transition should have minimal impact on these addons.
>>> Most other pure Node.js modules should be okay - they either
>>> are already compatible with Node.js 6 or have upstream updates
>>> providing that compatibility.
>>
>> This sounds rather, well, hopeful. Please stage the transition in
>> experimental first, and test/fix reverse dependencies. Then come back and
>> we'll schedule a time to do it in unstable.
>>
>> (Transitions should really be ready to go by the time they come to us;
>> they should also be able to happen quickly, because a blocked transition
>> holds up all sorts of other work.)
> 
> Jérémy, the transition was started by the upload of nodejs to unstable,
> but you've not replied to the above yet.
> 
> Can you confirm that all reverse dependencies build successfully with
> the new nodejs in unstable?
> 
> If so, the binNMUs can be scheduled to move this transition along.

The problem is the nodejs mips64el failure, caused by the mips64el gcc-7 bug
(#871514). I'm waiting for that to be fixed first.

Cheers,
Emilio

Bug#871652: jnoise: Italian translation of package description has a little typo

[Mattia Rizzolo]

Control: tag -1 l10n

On Thu, Aug 10, 2017 at 02:24:41PM +0200, Leandro Noferini wrote:
> Package: jnoise
> Severity: minor
> 
> The word "rumero" is a typo for "rumore" -> noise

This is not coming from the package itself, but from the DDTP.
CCing debian-i...@lists.debian.org as I have no idea how to update the
translated description of the packages.

-- 
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  `-


signature.asc
Description: PGP signature

Bug#873663: syncthing: Missing service files for discovery and relay service

[Achim Schaefer]

Sorry you are right, I did not see these packages.
Achim
On 30.08.2017 01:15, Alexandre Viau wrote:
> Really? Did you install the syncthing-discosrv and syncthing-relaysrv
> packages?
>
> These files are not shipped in the syncthing package.
>




smime.p7s
Description: S/MIME Cryptographic Signature

Bug#761032: hunspell-nl

[Mattia Rizzolo]

On Wed, Aug 30, 2017 at 09:54:00PM +0200, Kurt Roeckx wrote:
> It seems that libreoffice-dictionaries started shipping an
> hunspell-nl package at some point and it's actually providing an
> older version of the dictionaries.
> 
> I've talked to Rene about this, and he agreed we could take over
> this package.

Another possibility, which arguably is nicer for other non-Debian places
as well, would be to get upstream of libreoffice-dictionaries to budle a
newer version of that dictionary.

Just file a bug in 
https://bugs.documentfoundation.org/enter_bug.cgi?product=LibreOffice&component=Linguistic
asking for the nl dictionary to be updated.  If it's an update coming
from the same source it will be handled very quickly and land in the
next update.

-- 
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  `-


signature.asc
Description: PGP signature

Bug#872507: Config option causes segfault

[Ingo Jürgensmann]

Hi Marco!

With the help of Kees in Linux echomail area I found out that the following 
config option causes the segfault: 

options(time Any-2359) NoHold

When commenting this out, ifcico is working as expected. As this is not an easy 
to find error, I’d like to recommend to change the default config accordingly. 

-- 
Ciao...  //http://blog.windfluechter.net
  Ingo \X/ XMPP: i...@jabber.windfluechter.net

gpg pubkey:  http://www.juergensmann.de/ij_public_key.asc

Bug#870894: mirror submission for mirror.nbtelecom.com.br

[Pedro Alves]

Dear,

  As requested i create both /debian and /debian-cd. Mirroring is 
running...


Thank You


 A *NB Telecom* é cadastrada na *Onip* como fornecedor qualificado da 
indústria do petróleo e gás e, associada da *Rede Petro Rio e da *Telcomp*.


Acesse nossas redes sociais: facebook.com/nbtelecom 
 e twiter.com/telecomnb1 
.   Nosso site:www.nbtelecom.com.br 



DISCLAIMER
Esta é uma mensagem estritamente confidencial cujo sigilo é protegido 
por lei. Quaisquer informações e documentos nela contidos
são direcionados exclusivamente a seu(s) destinatário(s) acima 
identificado(s). Caso a tenha recebido equivocadamente, solicitamos
que os mesmos sejam imediatamente apagados e o seu remetente comunicado. 
Fica V.Sa. notificada de que a divulgação, retenção,
disseminação, distribuição ou cópia desta mensagem e seus anexos, sem a 
autorização do remetente, constitui crime nos

termos da Lei Complementar 105/01.
Obrigado.*
Em 30/08/2017 17:20, Peter Palfrader escreveu:

On Wed, 30 Aug 2017, Pedro Alves wrote:


Can you check again ?

Doesn't look healthy, because:


Archive-http: /debian/
CDImage-http: /debian/

Are you trying to mirror both CDimage and the Archive into /debian?

The archive should go to /debian, the cd images to /debian-cd.

Bug#860055: Inquiry about packaging progress

[Christoph Biedl]

[ Dominik re-added to the loop ]

Stefan Bühler wrote...

> Yes, the .dsc files in:
>
>   https://download.opensuse.org/repositories/home:/stbuehler/Debian_9.0/
>
> work for me with dget.

Thanks. That looks pretty well, so was "violates the debian policy in
many ways" really more than just an understatement?

Besides minor cosmetical issues, there are just two things:

* libsignal-protocol-c really should be packaged separately (#840366).
  Shouldn't be a bigger issue.
* The build failure on i386 (also seen on armhf) and probably
  all other 32bit archs needs to be fixed.

(Also I haven't checked all copyright attributions. That's something for
a long rainy night.)

Cheers,
Christoph


signature.asc
Description: Digital signature

Bug#873766: RM: FSO stack -- ROM; FTBFS; RC-buggy; bandoned upstream

[Sebastian Reichel]

Package: ftp.debian.org
Severity: normal

Hi,

This is a removal request for the FSO stack, which
is no longer maintained upstream. I kept it compiling
with newer vala releases for quite some time, but no
longer see any purpose in it (the stack recently broke
again with new Vala 0.36 upload #871058, #871119). It
mainly supports the old Openmoko Freerunner and requires
quite some configuration effort to be useful. Also the UI
parts have been broken for a few years without anyone caring
enough to fix it (#853504, #773586). There is an alternative
modem middle layer available in Debian, that is still
actively being developed: ofono. Getting that working
with telepathy-ring and some telepathy UI should be much
simpler and more future-proof than trying to maintain
the FSO + SHR stack.

Thus I request to remove the following packages from sid.
All of them are maintained by the "Debian FSO team", which
is effectively me nowadays.

 * fso-datad
 * fso-deviced
 * fso-frameworkd
 * fso-gsmd
 * fso-usaged
 * libphone-ui
 * libphone-ui-shr
 * libphone-utils
 * libshr-glib
 * openbmap-logger
 * phonefsod
 * phoneui-apps
 * phoneuid
 * python-phoneutils
 * shr-specs
 * fso-common
 * fso-gpsd
 * fso-gsm0710muxd
 * yue-sounds-fso

That leaves the following packages from the core FSO
stack, since the audio daemon is still useful for providing
audio support on Nokia N900 in combination with ofono.

 * fso-specs
 * libfsoframework
 * libfso-glib
 * libcmtspeechdata
 * libgsm0710
 * fso-audiod

I executed the following on mirror.ftp-master.debian.org and no dependency
problems have been found:

dak rm -Rn fso-datad fso-deviced fso-frameworkd fso-gsmd fso-usaged \
libphone-ui libphone-ui-shr libphone-utils libshr-glib openbmap-logger \
phonefsod phoneui-apps phoneuid python-phoneutils shr-specs fso-gpsd \
fso-common fso-gsm0710muxd yue-sounds-fso

-- Sebastian

Bug#870204: RFS: openfst/1.6.3-1 -- weighted finite-state transducers library

[Adam Borowski]

On Wed, Aug 30, 2017 at 10:37:43PM +0200, Giulio Paci wrote:
> On 29/08/2017 18:43, Giulio Paci wrote:
> > As far as I know it is just a matter of available memory.  In the past
> > we estimated how much memory is needed to compile the package and
> > limited the number of compilation processes according to available
> > memory, with a minimum of 1 process.
> 
> I just remembered that openfst used to FTBFS on hurd-i386, for the same 
> reason.
> I was able to make it compile by disabling optimizations for checks, so I just
> pushed a commit that should fix the compilation on kfreebsd-i386.
> 
> Are you able to try it on the kfreebsd-i386 building machine?

You do know you have a kfreebsd-i386 capable machine right on your desk,
right?  All you need is qemu or virtualbox (or vmware or Microsoft Virtual
PC if you fancy so) -- just remember to --enable-kvm when using qemu so you
get native speed, wget
https://d-i.debian.org/daily-images/kfreebsd-i386/daily/netboot-10/mini.iso
then press "Enter" a bunch of times (although https://xkcd.com/910/ is a
notoriously tricky question).

I've started a build (-smp 4 -m 2048 but no DEB_BUILT_OPTIONS=parallel=X)
but you can do this on your machine whenever you wish.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!?
⢿⡄⠘⠷⠚⠋⠀ -- Genghis Ht'rok'din
⠈⠳⣄ 

Bug#873765: gnome-tweak-tool: Error on start: GLib-GIO-ERROR **: Settings schema 'org.gnome.shell' does not contain a key named 'disable-user-extensions'

[Robert Velter]

Package: gnome-tweak-tool
Version: 3.25.91-1
Severity: important

Dear Maintainer,

gnome-tweak-tool exits immediately after start with exit code 133.
The complete error message is:

(gnome-tweak-tool:10988): GLib-GIO-ERROR **: Settings schema 'org.gnome.shell' 
does not contain a key named 'disable-user-extensions'
Trace/breakpoint trap

After downgrade to version 3.22.0-1 its usable again.

Best regards,
Robert

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

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

Versions of packages gnome-tweak-tool depends on:
ii  gir1.2-glib-2.01.53.2-4
ii  gir1.2-gnomedesktop-3.03.22.2-1
ii  gir1.2-gtk-3.0 3.22.19-1
ii  gir1.2-notify-0.7  0.7.7-2
ii  gir1.2-pango-1.0   1.40.11-1
ii  gir1.2-soup-2.42.56.1-1
ii  gnome-settings-daemon  3.24.3-1
ii  gnome-shell-common 3.22.3-3
ii  gsettings-desktop-schemas  3.24.0-2
ii  mutter-common  3.22.4-2
ii  python33.5.3-3
ii  python3-gi 3.22.0-2+b1

gnome-tweak-tool recommends no packages.

gnome-tweak-tool suggests no packages.

-- no debconf information

Bug#873764: Please remove xmkmf and imake from xutils-dev

[Steve Langasek]

Package: xutils-dev
Version: 1:7.7+5
Severity: wishlist

The xutils-dev package ships imake and xmkmf tools, which are long
considered obsolete and not used by xorg itself for building.  They are also
not cross-build-friendly, which makes the Multi-Arch: foreign field on
xutils-dev technically a lie.

We should encourage the remaining consumers of these tools to migrate to
something that isn't 20 years obsolete, and then drop them from the package.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#872559: RFS: opengrm-ngram/1.3.2-1 -- opengrm n-gram library

[Giulio Paci]

I noticed that the building failed on several architectures.

I have the impression that some of them failed due to memory exhaustion and 
some other were aborted.

I monitored RAM on amd64 and found out that most files require about 650MB of 
RAM in order to be compiled, but a couple of them require 3.5GB and 2.0GB.

So I decided to artificially limit parallelism if it cannot be guaranteed that 
each process will have at least 2.0GB of RAM.

The idea is that the build may still fail on amd64 build machines with 2 cores 
and 4.0GB of RAM, but should work on larger machines. On 32bit systems it 
should work even
with 2 core and 4.0GB as those files are expected to require less memory on 
32bit systems.

Can you upload the new version?
On mips64el the build failed while running the test suite. However I cannot see 
why (i.e., the build logs are not showing src/test/test-suite.log), can you 
provide me that
file?

Best regards,
Giulio

Bug#767941: watchdog: Ping option does not support IPv6

[Christoph Biedl]

nobody wrote...

> The "ping =" option in watchdog.conf does not support an IPv6 address.
>
> This means that IPv6-only systems cannot use the ping testing functionality
> of Watchdog.
>
> Setting "ping=" to an IPv6 literal address fails with:
>
> Starting watchdog daemon...watchdog: unknown host fe80::230:18ff:fec0:5339
> failed!
>
> The same happens if the setting is configured as a hostname which has only an 
>  record.

From Debian stretch only ping (at least ping provided by iputils-ping)
supports IPv6 addresses and tries  for hostnames first. Therefore,
this should no longer be an issue.

Mind to check?

Christoph (not the watchdog maintainer, just noticed this issue)


signature.asc
Description: Digital signature

Bug#873763: watchdog: watchdog fails to start in jessie, please fix #783166, #798294, #793309

[Christoph Biedl]

Package: watchdog
Version: 5.14-3
Severity: important
Tags: patch

Dear Maintainer,

I'm somewhat scared to find watchdog fails to start automatically in
jessie due to two bugs that were fixed later. As a result, watchdog
is fairly ususable for me in this distribution since I'll have to start
watchdog manually or by other means after each reboot. This voids the
entire purpose of watchdog: If the box crashes first, I'm stuck.

The fix is fairly simple, please address this for jessie in the next
point release. A debdiff is attached, works for me.

Cheers,
Christoph

-- System Information:
Debian Release: 8.9
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable-proposed-updates'), 
(500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.45 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
diff -u watchdog-5.14/debian/changelog watchdog-5.14/debian/changelog
--- watchdog-5.14/debian/changelog
+++ watchdog-5.14/debian/changelog
@@ -1,3 +1,11 @@
+watchdog (5.14-3+deb8u1) unstable; urgency=medium
+
+  * Added missing quote to systemd service file. (Closes: #783166,
+#798294)
+  * Re-added Install stanza to service file. (Closes: #793309)
+
+ -- Christoph Biedl   Wed, 30 Aug 2017 
22:09:56 +0200
+
 watchdog (5.14-3) unstable; urgency=medium
 
   * Updated Danish debconf translation.
diff -u watchdog-5.14/debian/watchdog.service 
watchdog-5.14/debian/watchdog.service
--- watchdog-5.14/debian/watchdog.service
+++ watchdog-5.14/debian/watchdog.service
@@ -10,5 +10,6 @@
-ExecStartPre=/bin/sh -c '[ -z "${watchdog_module}" ] || [ "${watchdog_module}" 
= "none" ] || /sbin/modprobe $watchdog_module
+ExecStartPre=/bin/sh -c '[ -z "${watchdog_module}" ] || [ "${watchdog_module}" 
= "none" ] || /sbin/modprobe $watchdog_module'
 ExecStart=/bin/sh -c '[ $run_watchdog != 1 ] || exec /usr/sbin/watchdog 
$watchdog_options'
 ExecStopPost=/bin/sh -c '[ $run_wd_keepalive != 1 ] || false'
 
 [Install]
+WantedBy=default.target


signature.asc
Description: Digital signature

Bug#873762: sqlite3: CVE-2017-13685

[Salvatore Bonaccorso]

Source: sqlite3
Version: 3.8.7.1-1
Severity: normal
Tags: security upstream

Hi,

the following vulnerability was published for sqlite3, it's quite
minor since should be only a problem in the command-line shell
program.

CVE-2017-13685[0]:
| The dump_callback function in SQLite 3.20.0 allows remote attackers to
| cause a denial of service (EXC_BAD_ACCESS and application crash) via a
| crafted file.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-13685
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-13685
[1] https://sqlite.org/src/info/02f0f4c54f2819b3

Regards,
Salvatore

Bug#873633: [debhelper-devel] Bug#873633: Bug#873633: debhelper: Add meson support to debhelper in stable

[Niels Thykier]

W. Martin Borgert:
> On 2017-08-30 05:44, Niels Thykier wrote:
>> I am a bit low on capacity at the moment, but you are very welcome to do
>> the debhelper backport on my behalf.  I am happy to give you commit
>> access to the debhelper git repo, so you can maintain the changes there
>> (it would also make it easier for me to contribute to the -backports
>> when I got more energy again).
>>
>> To the best of my knowledge, the current version in testing just needs a
>> version bump and a rebuild in stable(-backports) with the proper version
>> (see also https://jenkins.debian.net/job/lintian-tests_stretch/).
> 
> Cool, I'll check this! Probably in the next days, OK?
> 
> 
> [...]

Thanks, that will be great. :)

I have pre-emptively given you commit access to the debhelper repo, so
you should be able to start whenever you are ready.  :)

Thanks,
~Niels

Bug#872596: confclerk: infinite loop of error dialogs with DebConf17: UNCAUGHT OrmException: No object exception

[gregor herrmann]

On Wed, 16 Aug 2017 14:11:34 -0400, Paul Wise wrote:

Hi Pabs,

thanks for your bug report, and sorry for the late reply.

> When loading the DebConf17 schedule, switching to Saturday 2017-08-12,
> expanding the 16:15 - 18:50 slot and scrolling down to the blank entry,
>  confclerk pops up an Error dialog that gives the error message
> "UNCAUGHT OrmException: No object exception". This is accompanied by
> 100% CPU usage. Clicking on the OK button just leads to further dialogs.
> There are also some console messages listed below.
> 
> https://debconf17.debconf.org/schedule/pentabarf.xml
> 
> $ confclerk 
> No room found for event id:  0 
> OrmException: "No object exception" 

I suspect that you ran into the problem were waver exported a rather
broken XML file for some time. With the one currently available, I
can't reproduce the problem. I guess you don't have the pentabarf.xml
which caused you problems lying around somewhere locally?

Of course ConfClerk should handle such problems more gracefully (we
just had a similar case with missing tracks, reported privately), but
without an example file to test coming up with a fix is a bit
difficult (I just tried butchering the current schedule XML but
without success).

(For the future and other bug reporters: Please attach the XML files
causing problems.)


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#870204: RFS: openfst/1.6.3-1 -- weighted finite-state transducers library

[Giulio Paci]

On 29/08/2017 18:43, Giulio Paci wrote:
> On Tue, Aug 29, 2017 at 12:31, "Adam Borowski"  > wrote:
>>
>> On Mon, Aug 28, 2017 at 12:49:22PM +0200, Giulio Paci wrote:
>> > Hi Adam,
>> >   I just saw that building on freebsd-i386 failed due to memory exhaustion
>> > during compilation of tests. The only workaround that I can see is to
>> > prevent tests to be compiled if the memory is not enough to compile them.
>> > Do you see any better alternative?
>>
>> Do you think it's a matter of just available memory, or of address space?
>>
>> It did build on all other architectures, including 32-bit ones, so the
>> former is more likely, but you know the package better.
> 
> As far as I know it is just a matter of available memory. In the past we 
> estimated how much memory is needed to compile the package and limited the 
> number of compilation
> processes according to available memory, with a minimum of 1 process.

I just remembered that openfst used to FTBFS on hurd-i386, for the same reason.
I was able to make it compile by disabling optimizations for checks, so I just
pushed a commit that should fix the compilation on kfreebsd-i386.

Are you able to try it on the kfreebsd-i386 building machine?

Cheers,
Giulio

Bug#864831: [Debian-science-sagemath] NTL update to 10.3.0

[Julien Puydt]

Hi,

Le 29/08/2017 à 14:25, Tobias Hansen a écrit :

> Now is a good time for the NTL transition. Julien, could you update the
> package to 10.3.0? Then we can test-build the reverse dependencies and
> ask for a transition.

Uh, latest upstream is 10.5.0, and that's what I'm now working on.
Apparently quite a few things changed.

Snark on #debian-science

Bug#873450: openmpi: MPI_init in fortran fails on kfreebsd-amd64

[Boud Roukema]

hi Alastair

On Wed, 30 Aug 2017, Alastair McKinstry wrote:


I suspect this is due to the libgfortran4 transition that is currently
in progress. 2.1.1-6 was built against libgfortran3;
2.1.1-6+b1 against libgfortran4 and should not have this issue.



Can you please retest ?


I aptitude updated/upgraded, recompiled, and the error still occurs. To me
it looks unchanged.


If you still see the same problem, can you do
"ldd" on the binary produced and the OpenMPI libraries?


Diagnostics, including ldd, are below.

I'm doing this on a physical (primary) disk partition with Debian
kfreebsd-amd64 unstable, not an emulation. There are four Intel Core i5-2410M
cores available.

Cheers
Boud


--

dpkg -l |egrep "(fortran|gcc|mpi)"  # "mpi" is in "compile", so some irrelevant 
packages are listed

ii  g++  4:7.1.0-2  
kfreebsd-amd64 GNU C++ compiler
ii  g++-77.2.0-2
kfreebsd-amd64 GNU C++ compiler
ii  gcc  4:7.1.0-2  
kfreebsd-amd64 GNU C compiler
ii  gcc-5-base:kfreebsd-amd645.4.1-5
kfreebsd-amd64 GCC, the GNU Compiler Collection (base package)
ii  gcc-6-base:kfreebsd-amd646.4.0-4
kfreebsd-amd64 GCC, the GNU Compiler Collection (base package)
ii  gcc-77.2.0-2
kfreebsd-amd64 GNU C compiler
ii  gcc-7-base:kfreebsd-amd647.2.0-2
kfreebsd-amd64 GCC, the GNU Compiler Collection (base package)
ii  gfortran 4:7.1.0-2  
kfreebsd-amd64 GNU Fortran 95 compiler
ii  gfortran-7   7.2.0-2
kfreebsd-amd64 GNU Fortran compiler
ii  libgcc-7-dev:kfreebsd-amd64  7.2.0-2
kfreebsd-amd64 GCC support library (development files)
ii  libgcc1:kfreebsd-amd64   1:7.2.0-2  
kfreebsd-amd64 GCC support library
ii  libgfortran-7-dev:kfreebsd-amd64 7.2.0-2
kfreebsd-amd64 Runtime library for GNU Fortran applications (development files)
ii  libgfortran4:kfreebsd-amd64  7.2.0-2
kfreebsd-amd64 Runtime library for GNU Fortran applications
ii  libmagic-mgc 1:5.31-1   
kfreebsd-amd64 File type determination library using "magic" numbers (compiled 
magic file)
ii  libopenmpi-dev   2.1.1-6+b1 
kfreebsd-amd64 high performance message passing library -- header files
ii  libopenmpi2:kfreebsd-amd64   2.1.1-6+b1 
kfreebsd-amd64 high performance message passing library -- shared library
ii  make 4.1-9  
kfreebsd-amd64 utility for directing compilation
ii  openmpi-bin  2.1.1-6+b1 
kfreebsd-amd64 high performance message passing library -- binaries
ii  openmpi-common   2.1.1-6all 
   high performance message passing library -- common files


=

$ which gfortran
/usr/bin/gfortran

$ which gcc
/usr/bin/gcc

ls -l /usr/bin/gfortran /usr/bin/gcc

lrwxr-xr-x 1 root root  5 Aug  8 17:56 /usr/bin/gcc -> gcc-7
lrwxr-xr-x 1 root root 10 Aug  8 17:56 /usr/bin/gfortran -> gfortran-7

gfortran --version; gcc --version

GNU Fortran (Debian 7.2.0-2) 7.2.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

gcc (Debian 7.2.0-2) 7.2.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


===

uname -a
GNU/kFreeBSD myhost 10.3-0-amd64 #0 Fri Jan 20 17:41:38 UTC 2017 x86_64 amd64 
Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz GNU/kFreeBSD

mpifort --showme

gfortran -I/usr/lib/x86_64-kfreebsd-gnu/openmpi/include -pthread 
-I/usr/lib/x86_64-kfreebsd-gnu/openmpi/lib -L/usr//lib 
-L/usr/lib/x86_64-kfreebsd-gnu/openmpi/lib -lmpi_usempif08 
-lmpi_usempi_ignore_tkr -lmpi_mpifh -lmpi

===


=== program (1) 
mpifort -o a.out mpi_include_mpif_h_detect.f90 && ./a.out


[k3bsd:02478] PMIX ERROR: UNREACHABLE in file src/client/pmix_client.c at line 
1017
[k3bsd:02479] PMIX ERROR: NOT-SUPPORTED in file 
src/server/pmix_server_listener.c at line 540
[k3bsd:02478] PMIX ERROR: UNREACHABLE in file src/client/pmix_client.c at line 
205
--
It looks like orte_init failed for some reason;

Bug#870894: mirror submission for mirror.nbtelecom.com.br

[Peter Palfrader]

On Wed, 30 Aug 2017, Pedro Alves wrote:

> > Can you check again ?

Doesn't look healthy, because:

> > > > Archive-http: /debian/
> > > > CDImage-http: /debian/

Are you trying to mirror both CDimage and the Archive into /debian?

The archive should go to /debian, the cd images to /debian-cd.

-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#864831: [Debian-science-sagemath] NTL update to 10.3.0

[Julien Puydt]

Hi,

Le 29/08/2017 à 14:25, Tobias Hansen a écrit :
> Now is a good time for the NTL transition. Julien, could you update the
> package to 10.3.0? Then we can test-build the reverse dependencies and
> ask for a transition.

Indeed there was a soname version bump from 27 to 35, so a transition is
in order.

There also was a change of license, so I changed d/copyright -- I would
be glad if someone could check the result.

Finally, lintian complains about hardening-no-fortify-functions and
hardening-no-bindnow, which means there's more digging to do for me.

I still pushed this work-in-progress, as it should be good enought for
some tests already.

Snark on #debian-science

Bug#870894: mirror submission for mirror.nbtelecom.com.br

[Pedro Alves]

Dear,

Can you check again ?

Thanks


 A *NB Telecom* é cadastrada na *Onip* como fornecedor qualificado da 
indústria do petróleo e gás e, associada da *Rede Petro Rio e da 
*Telcomp*.


Acesse nossas redes sociais: facebook.com/nbtelecom 
<http://facebook.com/nbtelecom> e twiter.com/telecomnb1 
<http://twiter.com/telecomnb1>.   Nosso site:www.nbtelecom.com.br 
<http://www.nbtelecom.com.br>


DISCLAIMER
Esta é uma mensagem estritamente confidencial cujo sigilo é protegido 
por lei. Quaisquer informações e documentos nela contidos
são direcionados exclusivamente a seu(s) destinatário(s) acima 
identificado(s). Caso a tenha recebido equivocadamente, solicitamos
que os mesmos sejam imediatamente apagados e o seu remetente 
comunicado. Fica V.Sa. notificada de que a divulgação, retenção,
disseminação, distribuição ou cópia desta mensagem e seus anexos, sem 
a autorização do remetente, constitui crime nos

termos da Lei Complementar 105/01.
Obrigado.*
Em 30/08/2017 09:59, Peter Palfrader escreveu:

Control: retitle -1 [checked-20170830] mirror submission for 
mirror.nbtelecom.com.br [tracefile-missing]
Control: tag -1 +moreinfo

On Sun, 06 Aug 2017, Pedro Alves wrote:


Package: mirrors
Severity: wishlist
User:mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.nbtelecom.com.br
Aliases: mirror.nbtelecom.com.br
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
CDImage-http: /debian/
CDImage-rsync: debian/
Archive-upstream: sft.if.usp.br
CDImage-upstream: sft.if.usp.br
Updates: four
Maintainer: Pedro Alves
Country: BR Brazil
Location: Rio de Janeiro

Trace Url:http://mirror.nbtelecom.com.br/debian/project/trace/
Trace 
Url:http://mirror.nbtelecom.com.br/debian/project/trace/ftp-master.debian.org
Trace 
Url:http://mirror.nbtelecom.com.br/debian/project/trace/mirror.nbtelecom.com.br

Hi,

There is no tracefile at
  http://mirror.nbtelecom.com.br/debian/project/trace/mirror.nbtelecom.com.br

Pleae ensure that you're running the latest ftpsync version to mirror
Debian, and that you have set MIRRORNAME= in ftpsync.conf correctly.

Cheers,

Bug#860055: Inquiry about packaging progress

[Stefan Bühler]

Hi Christoph,

On 08/30/2017 07:27 PM, Christoph Biedl wrote:
> Stefan Bühler wrote...
> 
>> This ITP (#860055) is owned by Dominik George.
> 
> Ups, I indeed mis-directed Marcus here.
> 
>> I only wanted to give dino a short try, and preferred to have a package
>> for this.  My package probably violates the debian policy in many ways,
>> so it is not ready to be uploaded - I just posted a link in case it
>> helps anyone else doing similar work.
> 
> While I am willing to give it a look, the opensuse developers
> unfortunately spent a lot of time making web content as inaccessible as
> possible. In other words, I'd need a working download link, I get either
> 401 or just html. Is there *anywhere* an URL I can just feed to dget?

Yes, the .dsc files in:

  https://download.opensuse.org/repositories/home:/stbuehler/Debian_9.0/

work for me with dget.

cheers,
Stefan

Bug#867724: Multiple security issues

[Markus Koschany]

On Sun, 27 Aug 2017 21:29:43 +0200 Fabian Greffrath 
wrote:
> Am Sonntag, den 27.08.2017, 20:33 +0200 schrieb Markus Koschany:
> > Are you aware of any issues with your patch?
> 
> Yes, there was an issue with my patch! I added a field to a struct to
> keep track of reading errors, but the struct was defined in two
> different places in the source code. This led to a crash when free()ing
> a pointer to this struct on Linux, but not on Windows which I used to
> develop the patch (don't ask).
> 
> Applying this patch on top of the one I sent to the Debian BTS should
> fix this issue, although upstream decided to go a different way
> and entirely replace the mp4ff library.
> 
> https://sourceforge.net/p/faac/bugs/209/?limit=25&page=1#d838
> 
>  - Fabian

Hi,

I uploaded a security update for faad2 to wheezy-security a few hours
ago. I am attaching the debdiff to this bug report.

Do you intend to fix the issue in Stretch too? I could prepare the
update for Jessie and ask the release team for a jessie-pu.

Markus
diff -Nru faad2-2.7/debian/changelog faad2-2.7/debian/changelog
--- faad2-2.7/debian/changelog  2012-03-18 14:08:08.0 +0100
+++ faad2-2.7/debian/changelog  2017-08-30 20:07:59.0 +0200
@@ -1,3 +1,15 @@
+faad2 (2.7-8+deb7u1) wheezy-security; urgency=high
+
+  * Non-maintainer upload by the LTS team.
+  * Fix CVE-2017-9218, CVE-2017-9219, CVE-2017-9220, CVE-2017-9221,
+CVE-2017-9222, CVE-2017-9223, CVE-2017-9253, CVE-2017-9254, CVE-2017-9255,
+CVE-2017-9256, CVE-2017-9257.
+Various issues were discovered in faad2, a fast audio decoder, that could
+cause a denial of service (large loop and CPU consumption) via a crafted
+mp4 file.
+
+ -- Markus Koschany   Wed, 30 Aug 2017 20:07:59 +0200
+
 faad2 (2.7-8) unstable; urgency=low
 
   [ Fabian Greffrath ]
diff -Nru faad2-2.7/debian/patches/CVE-2017-92xx.patch 
faad2-2.7/debian/patches/CVE-2017-92xx.patch
--- faad2-2.7/debian/patches/CVE-2017-92xx.patch1970-01-01 
01:00:00.0 +0100
+++ faad2-2.7/debian/patches/CVE-2017-92xx.patch2017-08-30 
20:07:59.0 +0200
@@ -0,0 +1,551 @@
+From: Markus Koschany 
+Date: Tue, 29 Aug 2017 22:04:32 +0200
+Subject: CVE-2017-92xx
+
+Bug-Debian: https://bugs.debian.org/867724
+Origin: 
https://sourceforge.net/p/faac/faad2/ci/a67c75ed600cf4b41205d69664d3d9106e9c5380/
+---
+ common/mp4ff/mp4atom.c  |  76 ++
+ common/mp4ff/mp4ff.c|  22 -
+ common/mp4ff/mp4ff.h| 123 +++-
+ common/mp4ff/mp4ffint.h | 104 +---
+ common/mp4ff/mp4meta.c  |   4 +-
+ common/mp4ff/mp4util.c  |   3 ++
+ 6 files changed, 197 insertions(+), 135 deletions(-)
+
+diff --git a/common/mp4ff/mp4atom.c b/common/mp4ff/mp4atom.c
+index c735c2a..e88ffb4 100644
+--- a/common/mp4ff/mp4atom.c
 b/common/mp4ff/mp4atom.c
+@@ -258,6 +258,9 @@ uint64_t mp4ff_atom_read_header(mp4ff_t *f, uint8_t 
*atom_type, uint8_t *header_
+ 
+ static int32_t mp4ff_read_stsz(mp4ff_t *f)
+ {
++if (f->total_tracks == 0)
++return f->error++;
++
+ mp4ff_read_char(f); /* version */
+ mp4ff_read_int24(f); /* flags */
+ f->track[f->total_tracks - 1]->stsz_sample_size = mp4ff_read_int32(f);
+@@ -269,7 +272,10 @@ static int32_t mp4ff_read_stsz(mp4ff_t *f)
+ f->track[f->total_tracks - 1]->stsz_table =
+ (int32_t*)malloc(f->track[f->total_tracks - 
1]->stsz_sample_count*sizeof(int32_t));
+ 
+-for (i = 0; i < f->track[f->total_tracks - 1]->stsz_sample_count; i++)
++if (!f->track[f->total_tracks - 1]->stsz_table)
++return f->error++;
++
++for (i = 0; i < f->track[f->total_tracks - 1]->stsz_sample_count && 
!f->stream->read_error; i++)
+ {
+ f->track[f->total_tracks - 1]->stsz_table[i] = 
mp4ff_read_int32(f);
+ }
+@@ -283,6 +289,9 @@ static int32_t mp4ff_read_esds(mp4ff_t *f)
+ uint8_t tag;
+ uint32_t temp;
+ 
++if (f->total_tracks == 0)
++return f->error++;
++
+ mp4ff_read_char(f); /* version */
+ mp4ff_read_int24(f); /* flags */
+ 
+@@ -347,6 +356,9 @@ static int32_t mp4ff_read_mp4a(mp4ff_t *f)
+ uint8_t atom_type = 0;
+ uint8_t header_size = 0;
+ 
++if (f->total_tracks == 0)
++return f->error++;
++
+ for (i = 0; i < 6; i++)
+ {
+ mp4ff_read_char(f); /* reserved */
+@@ -380,12 +392,16 @@ static int32_t mp4ff_read_stsd(mp4ff_t *f)
+ int32_t i;
+ uint8_t header_size = 0;
+ 
++/* CVE-2017-9218 */
++if (f->total_tracks == 0)
++return f->error++;
++
+ mp4ff_read_char(f); /* version */
+ mp4ff_read_int24(f); /* flags */
+ 
+ f->track[f->total_tracks - 1]->stsd_entry_count = mp4ff_read_int32(f);
+ 
+-for (i = 0; i < f->track[f->total_tracks - 1]->stsd_entry_count; i++)
++for (i = 0; i < f->track[f->total_tracks - 1]->stsd_entry_count && 
!f->stream->read_error; i++) /* CVE-2017-9253 */
+ {
+ uint64_t

Bug#873760: golang-github-opencontainers-runc-dev: s/develpoment/development

[David Turner]

Package: golang-github-opencontainers-runc-dev
Severity: minor

Dear Maintainer,

The package describe itself as "develpoment files" instead of "development
files".

Thanks.



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

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

Versions of packages golang-github-opencontainers-runc-dev depends on:
pn  golang-dbus-dev 
pn  golang-github-codegangsta-cli-dev   
pn  golang-github-coreos-go-systemd-dev 
pn  golang-github-docker-go-units-dev   
pn  golang-github-opencontainers-specs-dev  
pn  golang-github-seccomp-libseccomp-golang-dev 
pn  golang-github-vishvananda-netlink-dev   
pn  golang-gocapability-dev | golang-github-syndtr  
ii  golang-goprotobuf-dev   0.0~git20161116.0.224aaba-3
pn  golang-logrus-dev   

golang-github-opencontainers-runc-dev recommends no packages.

golang-github-opencontainers-runc-dev suggests no packages.

Bug#873761: gtk: last prompt is "apply"

[David Turner]

Package: reportbug
Version: 7.1.7
Severity: minor

Dear Maintainer,

After I reported a bug, the button in the bottom right of the gtk dialog said,
"Apply".  It should probably say "Close" instead, sincce that is what it does.

Thanks.



-- Package-specific info:
** Environment settings:
EDITOR="emacs"
INTERFACE="gtk2"

** /home/novalis/.reportbugrc:
reportbug_version "7.1.7"
mode novice
ui gtk2
email "nova...@novalis.org"
smtphost "mail.novalis.org"
smtpuser "nova...@novalis.org"
smtptls

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

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

Versions of packages reportbug depends on:
ii  apt1.5~rc1
ii  python33.5.3-3
ii  python3-reportbug  7.1.7

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail  
pn  debconf-utils   
pn  debsums 
pn  dlocate 
ii  emacs24-bin-common  24.5+1-8
ii  file1:5.30-1
ii  gir1.2-gtk-3.0  3.22.16-1
ii  gir1.2-vte-2.91 0.46.2-1
ii  gnupg   2.1.18-8
ii  postfix [mail-transport-agent]  3.2.2-1
ii  python3-gi  3.22.0-2+b1
ii  python3-gi-cairo3.22.0-2+b1
pn  python3-gtkspellcheck   
pn  python3-urwid   
ii  xdg-utils   1.1.1-1

Versions of packages python3-reportbug depends on:
ii  apt1.5~rc1
ii  file   1:5.30-1
ii  python33.5.3-3
ii  python3-debian 0.1.30
ii  python3-debianbts  2.6.1
ii  python3-requests   2.12.4-1

python3-reportbug suggests no packages.

-- no debconf information

Bug#761032: hunspell-nl

[Kurt Roeckx]

It seems that libreoffice-dictionaries started shipping an
hunspell-nl package at some point and it's actually providing an
older version of the dictionaries.

I've talked to Rene about this, and he agreed we could take over
this package.

Anyway, the files we ship now require hunspell 1.3.1, so it should
have been renamed ages ago.

Thijs, do you have time to do this?


Kurt

Bug#873758: stretch-pu: package memcached/1.4.33-1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2017-08-30 at 21:33 +0200, g...@iroqwa.org wrote:
> The attached patch fix CVE-2017-9951 which has been not fixed via a DSA,
> as discussed with Salvatore Bonaccorso: https://bugs.debian.org/868701.

+memcached (1.4.33-1+deb9u1) stretch; urgency=high
+
+  * Non-maintainer upload by the Security Team.

So far as I can tell, you're not a member of the Security Team, so this
is incorrect.

+  * Fix CVE-2017-9951 by checking the integer length of commands that adds or
+replaces key/value pair
+
+ -- Guillaume Delacour   Tue, 25 Jul 2017 00:38:52 +0200

Please go ahead, bearing in mind the above comment.

Regards,

Adam

Bug#873708: libsystemd-shared: symbol collisions

[Michael Biebl]

Am 30.08.2017 um 15:32 schrieb Felipe Sateler:

> BTW, defining generic symbol names like `parse_time` in a public
> library like heimdal does is a bad idea. 

Agreed.

It would be nice to have
> heimdal either properly namespace their public symbols or hide
> nonpublic symbols. Johan, could you file a bug on heimdal for this issue?

Yeah, heimdal/libroken should be fixed to not expose such a generic
symbol name. The list of rdeps of libroken is thankfully manageable.
Only packages which are built from src:heimdal and src:openafs



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#770171: sshd jail fails when system solely relies on systemd journal for logging

[Jan Heitkötter]

Install rsyslog? Nonsense.

Creating /etc/fail2ban/jail.local with


[DEFAULT]

default_backend = systemd


will do the trick.

IMO the error lies within /etc/fail2ban/paths-common.conf which says


[DEFAULT]

default_backend = auto


This should be changed to


default_backend = systemd

Bug#873689: apt: create a clean-update command

[David Kalnischkies]

On Wed, Aug 30, 2017 at 08:55:19AM +0200, Cedric BRINER wrote:
> Hi, I'm looking for a way to suppress the data stored by the command apt
> update.

The obvious question is: Why? What is the goal you are trying to achieve?
You mention later apt-mirror troubleshooting, but that seems rather weak:
Its not like that would be a very common thing to do and the "workaround"
seems easy enough…


> It would be nice to have something like "apt clean-update".

That is a very suggestive name as everyone wants his "update to be clean".


> As this was missing, I was running : rm -r /var/cache/apt/ /var/lib/apt/lists.

"apt clean" removes the content of /var/cache/apt/. Clearing lists/ seems like
a mistake through. Beside that the updates can usually be better/quicker
performed if 'old' data is around as it can be patched it is also breaking some
security aspects as apt uses the old data e.g. to prevent an attacker from
serving "older but still valid" data…


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#870894: mirror submission for mirror.nbtelecom.com.br

[Pedro Alves]

Dear,

Can you check again ?

Thanks


 A *NB Telecom* é cadastrada na *Onip* como fornecedor qualificado da 
indústria do petróleo e gás e, associada da *Rede Petro Rio e da *Telcomp*.


Acesse nossas redes sociais: facebook.com/nbtelecom 
<http://facebook.com/nbtelecom> e twiter.com/telecomnb1 
<http://twiter.com/telecomnb1>.   Nosso site:www.nbtelecom.com.br 
<http://www.nbtelecom.com.br>


DISCLAIMER
Esta é uma mensagem estritamente confidencial cujo sigilo é protegido 
por lei. Quaisquer informações e documentos nela contidos
são direcionados exclusivamente a seu(s) destinatário(s) acima 
identificado(s). Caso a tenha recebido equivocadamente, solicitamos
que os mesmos sejam imediatamente apagados e o seu remetente comunicado. 
Fica V.Sa. notificada de que a divulgação, retenção,
disseminação, distribuição ou cópia desta mensagem e seus anexos, sem a 
autorização do remetente, constitui crime nos

termos da Lei Complementar 105/01.
Obrigado.*
Em 30/08/2017 09:59, Peter Palfrader escreveu:

Control: retitle -1 [checked-20170830] mirror submission for 
mirror.nbtelecom.com.br [tracefile-missing]
Control: tag -1 +moreinfo

On Sun, 06 Aug 2017, Pedro Alves wrote:


Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.nbtelecom.com.br
Aliases: mirror.nbtelecom.com.br
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
CDImage-http: /debian/
CDImage-rsync: debian/
Archive-upstream: sft.if.usp.br
CDImage-upstream: sft.if.usp.br
Updates: four
Maintainer: Pedro Alves 
Country: BR Brazil
Location: Rio de Janeiro

Trace Url: http://mirror.nbtelecom.com.br/debian/project/trace/
Trace Url: 
http://mirror.nbtelecom.com.br/debian/project/trace/ftp-master.debian.org
Trace Url: 
http://mirror.nbtelecom.com.br/debian/project/trace/mirror.nbtelecom.com.br

Hi,

There is no tracefile at
  http://mirror.nbtelecom.com.br/debian/project/trace/mirror.nbtelecom.com.br

Pleae ensure that you're running the latest ftpsync version to mirror
Debian, and that you have set MIRRORNAME= in ftpsync.conf correctly.

Cheers,

Bug#873723: ncurses: multiple vulnerabilities on tic, captoinfo, infotocap (CVE-2017-13728 to CVE-2017-13734)

[Salvatore Bonaccorso]

Hey!

On Wed, Aug 30, 2017 at 06:17:40PM +0200, Sven Joachim wrote:
> All but CVE-2017-13733 have been fixed in the latest upstream patchlevel
> for which I have already prepared a release, cloning the bug to track
> that one separately.

Alright, I took the liberty to slightly retitle the subject to thus
explicitly list the CVEs, hope this is fine with both of you. Updated
the tracker as well to track CVE-2017-13733 with the cloned bug.

Sven, for oldstable and stable we can go either again via a point
release or ignore those issues.

Regards,
Salvatore

Bug#868557: mirror submission for mirrors.ges.net.pk

[Peter Palfrader]

On Thu, 31 Aug 2017, Imran Qazi wrote:

> How to create the trace file for our server ? any suggestions ?

You should use ftpsync for mirroring.

You can find it on http://mirrors.ges.net.pk/debian/project/ftpsync/

in ftpsync.conf, you can configure your upstream's rsync host and path,
and where it should sync to.

if your unix hostname is not mirrors.ges.net.pk, you can set MIRRORNAME.

-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#873650: obnam: backup raises UnicodeDecodeError

[Lars Wirzenius]

On Tue, Aug 29, 2017 at 09:10:55PM +0200, Max Hofer wrote:
> after updating to the newest version of python-cliapp which should have fixed 
> #873298
> the 'backup' command spamms the console output with following messages:
> 
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 41: 
> ordinal not in range(128)
> Logged from file backup_plugin.py, line 397
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/logging/__init__.py", line 861, in emit
> msg = self.format(record)
>   File "/usr/lib/python2.7/logging/__init__.py", line 734, in format
> return fmt.format(record)
>   File "/usr/lib/python2.7/logging/__init__.py", line 476, in format
> raise e

I can't reproduce this and you didn't provide enough information for
me to guess what it might be. What is the actual command you ran and
what is the config you have (obnam --dump-config)?

Also, you should switch to another backup program. Sooner rather than
later would be good.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature