Bug#835342: curl or git clone commands throws "gnutls_handshake() failed" on https targets

[Andreas Metzler]

Control: tags -1 moreinfo

On 2016-08-28 Andreas Metzler  wrote:
> On 2016-08-26 "marcelomven...@gmail.com"  wrote:
[...]
> > First, let me say I'm behind a proxy server.
> [ no. Looks like no access without proxy, which gnutls-cli does not
> seem to support ]

> Could use git bisect to find the offending commit?

Any specific difficulties I could help you with there?

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#822394: seq24: FTBFS: error: reference to 'mutex' is ambiguous

[Philip Chung]

On Sat, 23 Apr 2016 18:19:46 -0700 Martin Michlmayr  wrote:
> Package: seq24
> Version: 0.9.3-1
> Severity: serious
> 
> This package fails to build in unstable:
> 
> > sbuild (Debian sbuild) 0.68.0 (15 Jan 2016) on dl580gen9-02.hlinux
> ...
> > make[1]: Entering directory '/<>'
> > make[2]: Entering directory '/<>'
> > g++ -DHAVE_CONFIG_H -I. -I./src   -Wdate-time -D_FORTIFY_SOURCE=2 
> > -std=c++11 -pthread -I/usr/include/gtkmm-2.4 
> > -I/usr/lib/x86_64-linux-gnu/gtkmm-2.4/include -I/usr/include/atkmm-1.6 
> > -I/usr/include/gtk-unix-print-2.0 -I/usr/include/gtk-2.0 
> > -I/usr/include/gdkmm-2.4 -I/usr/lib/x86_64-linux-gnu/gdkmm-2.4/include 
> > -I/usr/include/giomm-2.4 -I/usr/lib/x86_64-linux-gnu/giomm-2.4/include 
> > -I/usr/include/pangomm-1.4 -I/usr/lib/x86_64-linux-gnu/pangomm-1.4/include 
> > -I/usr/include/glibmm-2.4 -I/usr/lib/x86_64-linux-gnu/glibmm-2.4/include 
> > -I/usr/include/cairomm-1.0 -I/usr/lib/x86_64-linux-gnu/cairomm-1.0/include 
> > -I/usr/include/sigc++-2.0 -I/usr/lib/x86_64-linux-gnu/sigc++-2.0/include 
> > -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include 
> > -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo -I/usr/include/pango-1.0 
> > -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 
> > -I/usr/include/libpng16 -I/usr/include/gdk-pixbuf-2.0 
> > -I/usr/include/libpng16 -I/usr/include/pango-1.0 
> > -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 
> > -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/freetype2   
> > -Wall -g -O2 -fstack-protector-strong -Wformat -Werror=format-security 
> > -std=c++11 -c -o src/configfile.o src/configfile.cpp
> > In file included from src/sequence.h:33:0,
> >  from src/midibus.h:41,
> >  from src/perform.h:27,
> >  from src/configfile.h:23,
> >  from src/configfile.cpp:21:
> > src/mutex.h:47:30: error: reference to 'mutex' is ambiguous
> >  class condition_var : public mutex {
> >   ^
> > src/mutex.h:27:7: note: candidates are: class mutex
> >  class mutex {
> >^
> 
> -- 
> Martin Michlmayr
> Linux for HPE Helion, Hewlett Packard Enterprise
> 
> 

The ambiguity is between Seq24's "mutex" class and the "mutex" class
from the standard thread support library, which glibmm uses.

While it is possible to use "::mutex" to resolve the ambiguity, I think
a cleaner solution is to rename Seq24's mutex to something like
"ptmutex" (as it uses pthreads). In any rate, I think this should be
sent upstream for review.

Philip Chung

Bug#836437: FTBFS: Could not find 'gemojione' (>= 2.2.1, ~> 2.2) - did find: [gemojione-3.1.0]

[Pirate Praveen]

package: ruby-gitlab-emoji
version: 0.3.1-2
severity: serious

gitlab 8.10.5 now depends on ruby-gemojione directly. Once gitlab 8.10.5
enters testing, ruby-gitlab-emoji can be removed.

GEM_PATH= ruby2.3 -e gem\ \"gitlab_emoji\"
/usr/lib/ruby/2.3.0/rubygems/dependency.rb:319:in `to_specs': Could not
find 'gemojione' (>= 2.2.1, ~> 2.2) - did find: [gemojione-3.1.0]
(Gem::LoadError)
Checked in
'GEM_PATH=/home/debci/.gem/ruby/2.3.0:/var/lib/gems/2.3.0:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.3.0:/usr/share/rubygems-integration/2.3.0:/usr/share/rubygems-integration/all',
execute `gem env` for more information
from /usr/lib/ruby/2.3.0/rubygems/specification.rb:1438:in `block in
activate_dependencies'
from /usr/lib/ruby/2.3.0/rubygems/specification.rb:1427:in `each'
from /usr/lib/ruby/2.3.0/rubygems/specification.rb:1427:in
`activate_dependencies'
from /usr/lib/ruby/2.3.0/rubygems/specification.rb:1409:in `activate'
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_gem.rb:68:in `block
in gem'
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_gem.rb:67:in
`synchronize'
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_gem.rb:67:in `gem'
from -e:1:in `'
bigdecimal (1.2.8)
did_you_mean (1.0.0)
diff-lcs (1.2.5)
gemojione (3.1.0)
gitlab_emoji (0.3.1)
io-console (0.4.5)
json (2.0.1, 1.8.3)
minitest (5.9.0)
net-telnet (0.1.1)
power_assert (0.2.7)
psych (2.0.17)
rake (10.5.0)
rdoc (4.2.1)
rspec (3.4.0)
rspec-core (3.4.3)
rspec-expectations (3.4.0)
rspec-mocks (3.4.1)
rspec-support (3.4.1)
test-unit (3.1.7)
thread_order (1.1.0)
adt-run [17:14:47]: test command1: ---]
adt-run [17:14:47]: test command1:  - - - - - - - - - - results - - - -
- - - - - -
command1 FAIL non-zero exit status 1
adt-run [17:14:48]:  summary
command1 FAIL non-zero exit status 1



signature.asc
Description: OpenPGP digital signature

Bug#836436: plasma-desktop: KDE 5.6.5/stretch upgrade on Spetember 2nd makes system tray icons invisible

[Christian Bachmaier]

Package: plasma-desktop
Version: 4:5.6.5-1
Severity: normal

Dear Maintainer,

after a dist-upgrade on September 2nd of my stretch installation, the system
tray of KDE 5.6.5 does not show any icons. More precisely, it seams that they
are there, however only the background color of the panel is shown. One may see
tooltips and trigger the context menues with right click. A left click or
double click does nothing, i.e. does not start the volume mixer of plasma-pa
(after guessing the right mouse position). The menu of the black up arrow
operates as desired and shows some of the tray icons.

Thanks, Chris



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

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

Versions of packages plasma-desktop depends on:
ii  breeze   4:5.7.0-1
ii  kactivitymanagerd5.7.0-1
ii  kde-cli-tools4:5.7.0-1
ii  kded55.25.0-1
ii  kio  5.25.0-1
ii  libc62.23-5
ii  libcanberra0 0.30-3
ii  libfontconfig1   2.11.0-6.7
ii  libgcc1  1:6.1.1-11
ii  libkf5activities55.25.0-1
ii  libkf5activitiesexperimentalstats1   4:5.6.5-1
ii  libkf5archive5   5.25.0-1
ii  libkf5auth5  5.25.0-1
ii  libkf5baloo5 5.25.0-1
ii  libkf5bookmarks5 5.25.0-1
ii  libkf5codecs55.25.0-1
ii  libkf5completion55.25.0-1
ii  libkf5configcore55.25.0-1
ii  libkf5configgui5 5.25.0-1
ii  libkf5configwidgets5 5.25.0-1
ii  libkf5coreaddons55.25.0-1
ii  libkf5dbusaddons55.25.0-1
ii  libkf5emoticons-bin  5.25.0-1
ii  libkf5emoticons5 5.25.0-1
ii  libkf5globalaccel5   5.25.0-1
ii  libkf5guiaddons5 5.25.0-1
ii  libkf5i18n5  5.25.0-1
ii  libkf5iconthemes55.25.0-1
ii  libkf5itemmodels55.25.0-1
ii  libkf5itemviews5 5.25.0-1
ii  libkf5jobwidgets55.25.0-1
ii  libkf5kcmutils5  5.25.0-1
ii  libkf5kdelibs4support5   5.25.0-1
ii  libkf5kiocore5   5.25.0-1
ii  libkf5kiofilewidgets55.25.0-1
ii  libkf5kiowidgets55.25.0-1
ii  libkf5newstuff5  5.25.0-1
ii  libkf5notifications5 5.25.0-1
ii  libkf5notifyconfig5  5.25.0-1
ii  libkf5parts5 5.25.0-1
ii  libkf5people55.25.0-1
ii  libkf5peoplewidgets5 5.25.0-1
ii  libkf5plasma55.25.0-1
ii  libkf5plasmaquick5   5.25.0-1
ii  libkf5quickaddons5   5.25.0-1
ii  libkf5runner55.25.0-1
ii  libkf5service-bin5.25.0-1
ii  libkf5service5   5.25.0-1
ii  libkf5solid5 5.25.0-1
ii  libkf5sonnetui5  5.25.0-1
ii  libkf5wallet-bin 5.25.0-1
ii  libkf5wallet55.25.0-1
ii  libkf5widgetsaddons5 5.25.0-1
ii  libkf5windowsystem5  5.25.0-1
ii  libkf5xmlgui55.25.0-1
ii  libkfontinst54:5.6.5-1
ii  libkfontinstui5  4:5.6.5-1
ii  libkworkspace5-5 4:5.6.5.1-1
ii  libphonon4qt5-4  4:4.9.0-4
ii  libpulse-mainloop-glib0  9.0-2
ii  libpulse09.0-2
ii  libqt5concurrent55.6.1+dfsg-3+b1
ii  libqt5core5a 5.6.1+dfsg-3+b1
ii  libqt5dbus5  5.6.1+dfsg-3+b1
ii  libqt5gui5   5.6.1+dfsg-3+b1
ii  libqt5network5   5.6.1+dfsg-3+b1
ii  libqt5printsupport5  5.6.1+dfsg-3+b1
ii  libqt5qml5   5.6.1-5
ii  libqt5quick5 5.6.1-5
ii  libqt5quickwidgets5  5.6.1-5
ii  libqt5sql5   5.6.1+dfsg-3+b1
ii  libqt5svg5   5.6.1-2
ii  libqt5widgets5   

Bug#836435: mongodb: Fails to build from source on armhf

[Jeremy Bicha]

Package: mongodb
Version: 1:3.2.9-1
Severity: important

mongodb from experimental fails to build from source on armhf.

I understand that upstream prefers not to support this architecture.
So you can either disable building on armhf or try to get it to work
anyway.

See this discussion:
https://groups.google.com/forum/#!msg/mongodb-dev/G-kGjZEEam0/VSVB9fYCBAAJ


g++ -o build/opt/mongo/scripting/mozjs/base.o -c -g -O2
-fdebug-prefix-map=/«PKGBUILDDIR»=. -fstack-protector-strong -Wformat
-Werror=format-security -Wnon-virtual-dtor -Woverloaded-virtual
-Wno-maybe-uninitialized -std=c++11 -Wno-non-virtual-dtor
-fno-omit-frame-pointer -fPIC -fno-strict-aliasing -ggdb -pthread
-Wall -Wsign-compare -Wno-unknown-pragmas -Wno-nonnull-compare
-Wno-overflow -Winvalid-pch -Werror -O2 -Wno-unused-local-typedefs
-Wno-unused-function -Wno-deprecated-declarations
-Wno-unused-const-variable -Wno-unused-but-set-variable
-Wno-missing-braces -fno-builtin-memcmp -include js-config.h -include
js/RequiredDefines.h -Wno-invalid-offsetof -Wdate-time
-D_FORTIFY_SOURCE=2 -DJS_USE_CUSTOM_ALLOCATOR -DSTATIC_JS_API=1
-DNDEBUG -D_FILE_OFFSET_BITS=64 -DBOOST_THREAD_VERSION=4
-DBOOST_THREAD_DONT_PROVIDE_VARIADIC_THREAD
-DBOOST_SYSTEM_NO_DEPRECATED -Isrc/third_party/mozjs-38/include
-Isrc/third_party/mozjs-38/mongo_sources
-Isrc/third_party/mozjs-38/platform/arm/linux/include
-Isrc/third_party/asio-asio-1-11-0/asio/include -Isrc/third_party/s2
-Ibuild/opt -Isrc src/mongo/scripting/mozjs/base.cpp
cc1plus: fatal error: js-config.h: No such file or directory

Thanks,
Jeremy Bicha

Bug#835427: s/XML_NO_ERROR/XML_SUCCESS/

[Graham Inggs]

Hi Peter

On 2 September 2016 at 23:15, Peter Green  wrote:
> Unfortunately while that patch fixed the FTBFS in raspbian stretch at the
> time the package is now failing for us for a different reason. While I saw
> this in raspbian I have no reason to belive it is raspbian specific.
>
>
> In file included from /usr/include/spnav.h:33:0,
>  from
> /<>/gazebo-7.3.0+dfsg/gazebo/gui/SpaceNav.cc:27:
> /usr/include/google/protobuf/stubs/logging.h:66:7: error: expected
> identifier before 'int'
>  class Status;
>^
> /usr/include/google/protobuf/stubs/logging.h:66:7: error: multiple types in
> one declaration

This comes from protobuf 3.  I found it has already been fixed in git
[1], although the patch description is incorrect.

Regards
Graham


[1] 
https://anonscm.debian.org/cgit/debian-science/packages/gazebo.git/commit/?id=d033bbf3218580638e35b8df13565099a5c7c8db

Bug#829297: check-all-the-things: please make the build reproducible

[Paul Wise]

On Fri, 2016-09-02 at 11:03 +0100, Chris Lamb wrote:

> Any update on this? :)

Thanks for the ping, made a new release:

+- The "Reproducibly Depend On Thing Checkers" release
+- Fixes reproducible builds by sorting Recommends/Suggests (Closes: 
#829297)

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#836388: [pkg-go] Bug#836388: When cache is present, job run from incorrect working directory

[Dmitry Smirnov]

On Friday, 2 September 2016 10:01:14 AM AEST Sam Hartman wrote:
> If a job includes a cache, then it appears that the initial working
> directory is  some directory inside the cache, *not* the top of the
> project directory.

Please discuss upstream. From the description of the problem I'd say it is an 
upstream issue. I don't understand the problem well enough to help. Besides 
it may be worth trying the latest version...

Thanks.

-- 
Regards,
 Dmitry Smirnov.

---

Democracy is a pathetic belief in the collective wisdom of individual
ignorance.
-- H. L. Mencken


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

Bug#836407: RFP: libjs-jquery-at.js -- Autocompletion library to autocomplete mentions, smileys, etc

[Sergio Durigan Junior]

On Friday, September 02 2016, Sean Whitton wrote:

> Dear Sergio,
>
> Is there some reason some of your package names have '.js' and some of
> them don't?

Hi Sean,

Yes, I use the upstream name as part of the package name.  In this case,
the upstream is At.js, so the package name becomes libjs-jquery-at.js.

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#836434: reprepro: suggest includedeb preserve file mtime

[Kevin Ryde]

Package: reprepro
Version: 4.17.1-1
Severity: wishlist

When includedeb copies a file into the repo, it'd be good if it
preserved the file mtime.

I struck this when looking at dates of some old debs collected up and
being confused that the file dates were too new for their vintage.
I don't imagine anything in dpkg etc cares about dates, but it would
help humans, and possibly mirroring or backup by date.

Bug#836433: samba: install "hangs", synaptic more details reveals pager prompt

[F. Eugene Aumson]

Subject: samba: install "hangs", synaptic more details reveals pager prompt
Source: samba
Version: 2:4.2.10+dfsg-0+deb8u1
Severity: important

Dear Maintainer,

in synaptic package manager, i did "reload", then "mark all upgrades", then
"apply".

then i waited.  and waited.  and waited.  synaptic was taking forever to
"apply changes".  i waited at least 20 minutes, probably 30.

then i thought "surely something is wrong," so i clicked the "show more
details" thing in the dialog box, and the install was clearly just sitting
still.

eventually i noticed the ":" prompt at the bottom of the "screen", and
realized that it was sitting in a pager.  i hit 'q' and the install marched
onward.

i expected that the install of the package could proceed withouth manual
intervention

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

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

Bug#836432: muse: Type problem with previously submitted patch

[Philip Chung]

Package: muse
Version: 2.1.2-2
Severity: normal

Hello,

In bug #831147 I submitted a patch, which was incorporated as
"1002-abs-errors.patch". However, there is a problem with the changes to
muse/midiedit/ecanvas.cpp

When  is included, it seems that GCC 6 provides the C++
overloads of the functions in the global namespace. In this case,
floating-point overloads of abs() are provided.

The arguments to the invocations of abs() in ecanvas.cpp are unsigned
int, and it turns out that they actually call the "double abs(double)"
overload, rather than an integer overload as intended.

You can verify this with a simple test program:

#include 
#include 
#include 

int main() {
unsigned int x = 0;
std::cout << typeid(abs(x)).name() << std::endl;
return 0;
}

Running the output of this program through "c++filt -t" gives "double".

I don't think this is a major problem, but I think it should be fixed. I
will send an updated version of the patch that references this bug report.

Philip Chung

Bug#821027: Additional modules for HiKey support

[Martin Michlmayr]

* Vagrant Cascadian  [2016-06-04 18:20]:
> +CONFIG_WLAN_VENDOR_TI=y
> +CONFIG_WL18XX=m
> +CONFIG_COMMON_RESET_HI6220=m
> +CONFIG_PHY_HI6220_USB=m
> +CONFIG_MAILBOX=y
> +CONFIG_HI6220_MBOX=y
> +CONFIG_REGULATOR_HI655X=m
> +CONFIG_MFD_HI655X_PMIC=m
> +CONFIG_ARM_TIMER_SP804=y
> +CONFIG_STUB_CLK_HI6220=y

I enabled these (and some more) options in git, so please try out the
next upload to experimental.

-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#836247: ITP: libsquish -- DXT texture compression library

[Paul Wise]

On Fri, 2016-09-02 at 12:56 +0100, Wookey wrote:

> OK. summary:

Updated the data:

https://anonscm.debian.org/viewvc/secure-testing/data/embedded-code-copies?r1=44253=44283

> Then I'll upload and file bugs against all these packages about the
> option to use a system library.

Great, let me know what the bug numbers are and I'll add them to the
security team's embedded code copies data.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#831409: ltsp-client lacks gnupg / gnupg2 for apt-key to work

[Vagrant Cascadian]

Control: tags 831409 pending

On 2016-07-18, Daniel Kahn Gillmor wrote:
> On Mon 2016-07-18 17:19:13 +0200, Holger Levsen  wrote:
>> On Mon, Jul 18, 2016 at 08:02:40AM -0700, Vagrant Cascadian wrote:
> But i think that the better solution is to avoid using apt-key in the
> way you're talking about using it.  It's much better to place the
> OpenPGP binary format key that you care about directly into
> /etc/apt/trusted.gpg.d/$FOO
>
> If you've got it in ascii-armored format and aren't sure how to decode
> it, you should be able to do that with a short awk | base64 -d pipeline:
>
>   awk '/^$/{ x = 1; } /^[^=-]/{ if (x) { print $0; } ; }' | base64 -d 

Thanks!

Implemented the above in a couple commits upstream:

  https://bazaar.launchpad.net/~ltsp-upstream/ltsp/ltsp-trunk/revision/2746
  https://bazaar.launchpad.net/~ltsp-upstream/ltsp/ltsp-trunk/revision/2747


Hope to upload the fix soon.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#825558: ipmitool: Service do not start after installation

[Jörg Frings-Fürst]

Hello William,


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

The loading of requested kernel modules are part of the kernel and not
part of the program.

So I close this bug.

If the bug still exist please file a new bug report against the kernel.

CU
Jörg


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

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

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

Threema: SYR8SJXB

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

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


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

Bug#826862: ipmitool fails with Segmentation fault

[Jörg Frings-Fürst]

tags 826862 + moreinfo
thanks

Hello Raul,

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


Please can you debug the package? You find a how-to at [1][2].
And the install of the dbgsym files is described at [3].

Many thanks.


CU
Jörg



[1] 
http://www-numi.fnal.gov/offline_software/srt_public_context/WebDocs/Companion/intro_talks/gdb/gdb.html
[2] http://www.tutorialspoint.com/de/gnu_debugger/gdb_debugging_example1.htm
[3] https://wiki.debian.org/AutomaticDebugPackages


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

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

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

Threema: SYR8SJXB

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

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


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

Bug#836431: ksnapshot: Update dependency from libkipi11 to libkf5kipi31.0.0

[Alex Henry]

Just to clarify: the actual conflict seems to be "libkf5kipi-data breaks
libkipi-data" which is why I apparently can't have both libkipi11
(dependence for ksnapshot) and libkf5kipi31.0.0 (dependence for gwenview)
installed simultaneously. Again the naming here seems to suggest that it's
simply a case of the new version being renamed to libkf5-- (probably as a
way to indicate it's part of the KDE 5 framework?)

On 3 September 2016 at 00:00, Alex Henry  wrote:

> Package: ksnapshot
> Version: 4:15.08.0-1
> Severity: normal
>
> Hello, I've noticed a problem now while updating the KDE packages on my
> system to the next set of available testing packages.
>
> All packages seemed to update normally but ksnapshot is holding back
> gwenview due to a conflict between libkipi11 and libkf5kipi31.0.0. My
> understanding is that the latter is simply the new name for the package
> so if you could update the dependency to point to the latter it would
> probably solve the issue. This has just been a superficial analisys so
> sorry if I'm wrong - but gwenview for example is depending on the 31.0.0
> package instead, which replaces libkipi11 so I hope this is a safe
> assumption.
>
> Thanks for the great work maintaining this package. It has been my one
> and only screenshot tool since moving to Linux and KDE over a decade
> ago. I hope this issue can be solved easily by just reassigning the
> dependency to the new package name, thank again for you time!
>
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.6.0-1-amd64 (SMP w/8 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: systemd (via /run/systemd/system)
>
> Versions of packages ksnapshot depends on:
> ii  kde-runtime  4:16.08.0-1
> ii  libc62.23-5
> ii  libkdecore5  4:4.14.23-1
> ii  libkdeui54:4.14.23-1
> ii  libkio5  4:4.14.23-1
> ii  libkipi114:15.08.3-2
> ii  libqt4-dbus  4:4.8.7+dfsg-8
> ii  libqtcore4   4:4.8.7+dfsg-8
> ii  libqtgui44:4.8.7+dfsg-8
> ii  libstdc++6   6.1.1-11
> ii  libx11-6 2:1.6.3-1
> ii  libxext6 2:1.3.3-1
> ii  libxfixes3   1:5.0.2-1
>
> ksnapshot recommends no packages.
>
> ksnapshot suggests no packages.
>
> -- no debconf information
>

Bug#836431: ksnapshot: Update dependency from libkipi11 to libkf5kipi31.0.0

[Alex Henry]

Package: ksnapshot
Version: 4:15.08.0-1
Severity: normal

Hello, I've noticed a problem now while updating the KDE packages on my
system to the next set of available testing packages.

All packages seemed to update normally but ksnapshot is holding back
gwenview due to a conflict between libkipi11 and libkf5kipi31.0.0. My
understanding is that the latter is simply the new name for the package
so if you could update the dependency to point to the latter it would
probably solve the issue. This has just been a superficial analisys so
sorry if I'm wrong - but gwenview for example is depending on the 31.0.0
package instead, which replaces libkipi11 so I hope this is a safe 
assumption.

Thanks for the great work maintaining this package. It has been my one
and only screenshot tool since moving to Linux and KDE over a decade
ago. I hope this issue can be solved easily by just reassigning the
dependency to the new package name, thank again for you time!


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

Kernel: Linux 4.6.0-1-amd64 (SMP w/8 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: systemd (via /run/systemd/system)

Versions of packages ksnapshot depends on:
ii  kde-runtime  4:16.08.0-1
ii  libc62.23-5
ii  libkdecore5  4:4.14.23-1
ii  libkdeui54:4.14.23-1
ii  libkio5  4:4.14.23-1
ii  libkipi114:15.08.3-2
ii  libqt4-dbus  4:4.8.7+dfsg-8
ii  libqtcore4   4:4.8.7+dfsg-8
ii  libqtgui44:4.8.7+dfsg-8
ii  libstdc++6   6.1.1-11
ii  libx11-6 2:1.6.3-1
ii  libxext6 2:1.3.3-1
ii  libxfixes3   1:5.0.2-1

ksnapshot recommends no packages.

ksnapshot suggests no packages.

-- no debconf information

Bug#826300: Share knowledge on fpc and powerpc issue

[peter green]

On 02/09/16 23:05, Abou Al Montacir wrote:

Upstream suggests the following patch which may be temporary:
diff --git a/rtl/linux/powerpc/cprt0.as b/rtl/linux/powerpc/cprt0.as
index e237d8d..a5672e3 100644
--- a/rtl/linux/powerpc/cprt0.as
+++ b/rtl/linux/powerpc/cprt0.as
@@ -88,12 +88,8 @@ main_stub:
  .globl  _haltproc
  .type   _haltproc, @function
  _haltproc:
-lis 11, ___fpc_ret@ha
-lwz 1, ___fpc_ret@l(11)
-addi1, 1, 16
-lwz 0, 0(1)
-mtlr0
-blr
+bl _exit
+b  _haltproc

  #li  0, 1   /* exit call */
  #lis 3,operatingsystem_result@h  
Apparent good news. With this patch and the hacks I previously mentioned 
for building in a jessie chroot I was able to get a successful build in 
a jessie chroot on the porterbox. I was then able to run the resulting 
fpcmkcfg-3.0.0 in the sid chroot on the porterbox.


I then installed the packages built in the jessie chroot on the 
porterbox into a sid chroot in qemu and attempted to build the packge 
with the patch above but without the jessie hacks.


That build is currently ongoing. If it succeeds I intend to upload it to 
Debian (as a "source all powerpc" upload).

Bug#836430: aseprite: asperite switch to non-free license in version 1.1.8

[Alex Vong]

Source: aseprite
Severity: important
Tags: upstream

Dear Maintainer,

>From the homepage[0], asperite has recently switched to a non-free
license in version "1.1.8". I don't see any forks of the project
yet. What should we do with our package? Should we simply wait for
people to fork the old GPL version?

Thanks,
Alex

[0]: http://dev.aseprite.org/post/149797781837/new-source-code-license

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

Kernel: Linux 4.6.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=zh_TW.UTF-8, LC_CTYPE=zh_TW.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to zh_TW.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#836407: RFP: libjs-jquery-at.js -- Autocompletion library to autocomplete mentions, smileys, etc

[Sean Whitton]

Dear Sergio,

Is there some reason some of your package names have '.js' and some of
them don't?

-- 
Sean Whitton

Bug#835838: pulseaudio: Do not intercept ALSA if environment variable is set

[Felipe Sateler]

On 1 September 2016 at 18:28, Javier Serrano Polo  wrote:
> El dl 29 de 08 de 2016 a les 12:51 -0300, Felipe Sateler va escriure:
>> Hmm. I wonder if instead of using an override pointing to a different
>> file, it would be a simple disable flag (ALSA_PULSE_DISABLE). Is this
>> possible in this configuration language?
>
> As far as I know, there is no conditional processing. It does not seem
> possible to configure with ALSA Lisp either. I guess ALSA_PULSE_DISABLE
> could be implemented in the pulse_load_if_running function.

I think that is a more logical place. Also, it has a higher chance of
reaching upstream (as the pulse default is a debianism).

I have also a question. in pulse.conf:

# Enable PulseAudio hook if PULSE_ALSA_HOOK_CONF is not set.

I'm fairly ignorant on this format, but what this really does is load
the file described in PULSE_ALSA_HOOK_CONF, and default to the known
location?

-- 

Saludos,
Felipe Sateler

Bug#834974: Installation Report: Stretch Alpha 7 on Cubox-i4pro

[Rick Thomas]

On Sep 2, 2016, at 4:40 PM, Gunnar Wolf  wrote:

> Can somebody confirm whether the Jessie
> installer actually works reliably on this machine? (that is, whether
> it's always been broken or we have a regression)

I’ll give that a try as well over the weekend.  Let you know what I find.

Rick

Bug#836342: UDD/testing_autoremovals_gatherer.pl: Version in autoremoval notice may not be version actually checked

[Paul Wise]

Control: reassign -1 qa.debian.org
Control: retitle -1 UDD/testing_autoremovals_gatherer.pl: Version in 
autoremoval notice may not be version actually checked

On Fri, 2016-09-02 at 08:16 +0100, Rebecca N. Palmer wrote:

> That script looks like it gets version and bug information in one fetch 
> from UDD 
> (https://anonscm.debian.org/git/mirror/release-tools.git/tree/mailer/mail_autoremovals.pl#101),
>  
> which I took to mean the problem was in what generated that information, 
> but I don't know Perl.

Looks like you are right. Sorry for second-guessing you and not investigating :(

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#834974: Installation Report: Stretch Alpha 7 on Cubox-i4pro

[Rick Thomas]

On Sep 2, 2016, at 5:12 PM, Vagrant Cascadian  wrote:

> I'd be curious if you re-install and delete each partition individually
> and re-create manually vs. using one of the auto-partitioning methods.

I’ll give this a try over the weekend and report back what I find.

Is it possible that the auto-partitioning process during installation has 
somehow clobbered the u-boot image on the SD card?  How would I test for that?

Rick

Bug#833719: Workaround

[Borden Rhodes]

So confirmed. I forced libnss3 to upgrade to 3.26-1 and libnspr4 to
4.12-6 and that seemed to solve the problem. I suspect that the
offending library is the former. Once it goes into testing, all should
be well again.

Now if I can just get around the random crashes that seem to have come
with this update...

Bug#836230: [Debian-med-packaging] Bug#836230: genometools: FTBFS in testing (a2x: ERROR: "xsltproc" returned non-zero exit status 6)

[Santiago Vila]

On Sat, Sep 03, 2016 at 12:50:35AM +0100, Sascha Steinbiss wrote:

> I must admit that I’m inclined to either close this bug or leave it
> open with the comment that the issue is currently not
> reproducible. At least it’s difficult to debug if I can’t get it to
> fail…

This reminds me of Kunth's quote: "Beware of bugs in the above code; I
have only proved it correct, not tried it".

I'm not going to ask for a "mathematical proof" that the code is correct
as a condition to close the bug, but on the other hand, the fact that
it FTBFS for me not once but several times (on different machines) is
an indication that there is a bug somewhere, so if there is a bug, it
should be investigated, not closed.

My recommended debug procedure for this is not to build it many times
as if we were rolling a dice, but instead examine the code, examine
the build log, and try to see how such thing may happen based
on what the makefile and build system does.

In many cases, a close look at the code and the way it fails leads to
the reason for the random failures. Example:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817033#15

Thanks.

Bug#836429: q4wine: Please clarify upstream status and homepage

[Jens Reyer]

Source: q4wine
Version: 1.3.1-1
Severity: minor

Hi,

I (co-maintainer of Wine) just saw on
https://wiki.winehq.org/Third_Party_Applications
that q4wine is listed as an obsolete application. So I wanted to see why
q4wine is still in Debian ...

However after a bit of investigation it looks to me as if it is actively
developed, and still works and is useful with both wine and
wine-development. Can you confirm this?

Would it be correct to change this classification on winehq.org?


[Actual bug report:]

While investigating I noticed that the homepage field in d/control seems
to be outdated (reason stated in #761968):

Homepage:
https://web.archive.org/web/20131204020055/http://q4wine.brezblock.org.ua/

d/watch has:
http://sf.net/q4wine/q4wine-(.+)\.tar\.bz2 \
-> seems valid

Checking the web I see:

http://q4wine.brezblock.org.ua/
-> seems valid for q4wine itself (again), and points to these 2 resources:

https://github.com/brezerk/q4wine/tree/master
https://sourceforge.net/projects/q4wine/
-> both seem to be valid

So I think one of these 3 sites should be set as Homepage in d/control.
I don't know if any other change that was made because of #761968 needs
reconsideration.

Greets
jre

Bug#834974: Installation Report: Stretch Alpha 7 on Cubox-i4pro

[Vagrant Cascadian]

On 2016-08-29, Martin Michlmayr wrote:
> * Rainer Dorsch  [2016-08-22 00:18]:
>> > Can you 1) attach /var/log/installer/syslog from the SD card and b)
>> > show the boot log (after the installer).
>> 
>> I attached the syslog. On the serial console, there was no output indicating 
>> any boot attempt. The installer shutdown for reboot, but then I did not see 
>> further output.
>
> The log suggests that flash-kernel was installed successfully, i.e.
> that a u-boot boot script was generated correctly.
>
> I don't know anything about this device so unfortunately I cannot help
> you.  Maybe Vagrant Cascadian knows something?

In the past, I've had issues on other boards where it failed if the
partitioning process zero'ed out the partition table. In my experience,
re-installing u-boot usually resolved the issue without having the
re-install.

I'd be curious if you re-install and delete each partition individually
and re-create manually vs. using one of the auto-partitioning methods.


This is arguably where a u-boot-installer udeb would make some sense,
but for some boards there's a risk to brick the board(or at least
require re-installing a known-good version), so I've been hesitant to
implement...


This is somewhat related to:

  https://bugs.debian.org/812611

As upgrading u-boot on most systems is essentially the same as
installing it.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#833719: firerefox: NS_ERROR_NET_INADEQUATE_SECURITY on Google & Facebook only with i386 build

[Christopher W Carpenter]

I can also report I am having this with firefox 48.0-1+b1 x86_64.

Package: firefox
Version: 48.0-1+b1

-- Package-specific info:

-- Extensions information
Name: Abstract splash theme
Status: user-disabled

Name: Amazon Smile Redirect
Location: ${PROFILE_EXTENSIONS}/jid1-vgrlfatwwjy...@jetpack.xpi
Status: enabled

Name: Anonymous - I am free theme
Status: user-disabled

Name: Dark Fox theme
Status: user-disabled

Name: Default theme
Location: 
/usr/lib/firefox/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}.xpi
Package: firefox
Status: enabled

Name: Firefox Hello Beta
Location: ${PROFILE_EXTENSIONS}/l...@mozilla.org.xpi
Status: enabled

Name: fractal summer colors theme
Status: user-disabled

Name: GNU Linux theme
Status: user-disabled

Name: LastPass
Location: ${PROFILE_EXTENSIONS}/supp...@lastpass.com
Status: enabled

Name: Linux Generation theme
Status: user-disabled

Name: linux space dark theme
Status: user-disabled

Name: LiteFox theme
Status: user-disabled

Name: Multi-process staged rollout
Location: ${PROFILE_EXTENSIONS}/e10sroll...@mozilla.org.xpi
Status: enabled

Name: ng-inspect
Location: ${PROFILE_EXTENSIONS}/jid1-v6jvjrqacqc...@jetpack.xpi
Status: enabled

Name: Pocket
Location: ${PROFILE_EXTENSIONS}/fire...@getpocket.com.xpi
Status: enabled

Name: Privacy Badger
Location: ${PROFILE_EXTENSIONS}/jid1-mnnxcxisbpn...@jetpack.xpi
Status: enabled

Name: Reddit Enhancement Suite
Location: ${PROFILE_EXTENSIONS}/jid1-xufzosoflzs...@jetpack.xpi
Status: enabled

Name: succulent plant theme
Status: user-disabled

Name: uBlock Origin
Location: ${PROFILE_EXTENSIONS}/ublo...@raymondhill.net.xpi
Status: enabled

-- Plugins information
Name: Google Talk Plugin
Location: /opt/google/talkplugin/libnpgoogletalk.so
Package: google-talkplugin
Status: enabled

Name: Google Talk Plugin Video Renderer
Location: /opt/google/talkplugin/libnpo1d.so
Package: google-talkplugin
Status: enabled

Name: IcedTea-Web Plugin (using IcedTea-Web 1.6.2 (1.6.2-3))
Location: /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/IcedTeaPlugin.so
Package: icedtea-8-plugin:amd64
Status: enabled

Name: iTunes Application Detector
Location: /usr/lib/mozilla/plugins/librhythmbox-itms-detection-plugin.so
Package: rhythmbox-plugins
Status: enabled


-- Addons package information
ii  firefox48.0-1+b1amd64Mozilla Firefox web browser
ii  google-talkplu 5.41.3.0-1   amd64Google Talk Plugin
ii  icedtea-8-plug 1.6.2-3  amd64web browser plugin based on OpenJ
ii  rhythmbox-plug 3.4-1amd64plugins for rhythmbox music playe

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-1-amd64 (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: systemd (via /run/systemd/system)

Versions of packages firefox depends on:
ii  debianutils   4.8
ii  fontconfig2.11.0-6.7
ii  libasound21.1.2-1
ii  libatk1.0-0   2.20.0-1
ii  libc6 2.23-5
ii  libcairo2 1.14.6-1+b1
ii  libdbus-1-3   1.10.10-1
ii  libdbus-glib-1-2  0.106-1
ii  libevent-2.0-52.0.21-stable-2+b1
ii  libffi6   3.2.1-4
ii  libfontconfig12.11.0-6.7
ii  libfreetype6  2.6.3-3+b1
ii  libgcc1   1:6.1.1-11
ii  libgdk-pixbuf2.0-02.34.0-1
ii  libglib2.0-0  2.48.1-3
ii  libgtk2.0-0   2.24.30-4
ii  libhunspell-1.4-0 1.4.1-2
ii  libnspr4  2:4.12-2
ii  libnss3   2:3.25-1
ii  libpango-1.0-01.40.1-1
ii  libsqlite3-0  3.14.1-1
ii  libstartup-notification0  0.12-4
ii  libstdc++66.1.1-11
ii  libvpx4   1.6.0-2
ii  libx11-6  2:1.6.3-1
ii  libxcomposite11:0.4.4-1
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.2-1
ii  libxrender1   1:0.9.9-2
ii  libxt61:1.1.5-1
ii  procps2:3.3.12-2
ii  zlib1g1:1.2.8.dfsg-2+b1

firefox recommends no packages.

Versions of packages firefox suggests:
ii  fonts-lmodern  2.004.5-3
ii  fonts-stix [otf-stix]  1.1.1-4
ii  libcanberra0   0.30-3
ii  libgnomeui-0   2.24.5-3.1
ii  libgssapi-krb5-2   1.14.3+dfsg-1
pn  mozplugger 

-- no debconf information


signature.asc
Description: PGP signature

Bug#834833: marked as done (javassist: FTBFS too much often (failing tests))

[Harlan Lieberman-Berg]

On September 2, 2016 7:27:11 PM EDT, ow...@bugs.debian.org wrote:
>Your message dated Fri, 02 Sep 2016 23:25:14 +
>with message-id 
>and subject line Bug#834833: fixed in python-certbot 0.8.1-3
>has caused the Debian Bug report #834833,
>regarding javassist: FTBFS too much often (failing tests)
>to be marked as done.
>
>This means that you claim that the problem has been dealt with.
>If this is not the case it is now your responsibility to reopen the
>Bug report if necessary, and/or fix the problem forthwith.
>
>(NB: If you are a system administrator and have no idea what this
>message is talking about, this may indicate a serious mail system
>misconfiguration somewhere. Please contact ow...@bugs.debian.org
>immediately.)

reopen 834833
notfixed 834833 0.8.1-3
thanks

Whoops, looks like I got the bug number wrong. Sorry about that.
-- 
Harlan Lieberman-Berg
~hlieberman

Bug#836230: [Debian-med-packaging] Bug#836230: genometools: FTBFS in testing (a2x: ERROR: "xsltproc" returned non-zero exit status 6)

[Sascha Steinbiss]

Hi Santiago,

>> Ah, this looks suspicious indeed and falls directly into the gap. (By
>> the way, are these build logs available somewhere? Sounds quite useful
>> to have such a build history!)
> 
> I have put 15 different build logs here, temporarily:
> 
> https://people.debian.org/~sanvila/genometools/genometools.tar.gz
> 
> (I did more tests and now it does not fail anymore!)

I noticed the same, I couldn’t get it to fail at all on my side, even on a VM 
with 512MB RAM and no swap!
See https://paste.debian.net/805247/

> Here, machines called "uranio*" have 768 MB of RAM (plus 1 GB swap).
> The others have 3GB RAM at least.
> 
> Also, "Distribution: stretch" means I'm using eatmydata, while
> "Distribution: stretch-keepmydata" means I'm not.

Yes, doesn’t look like it’s dependent on that. Very mysterious.

> Just please make sure first (well, reasonably) that genometools is not
> contributing to the problem before reassigning.

Sure.

> For example, I set DEB_BUILD_OPTIONS = 'parallel=1' in the environment.
> When a package does not honor that, it ends up using double amount of
> memory without it being really necessary.

This is true (and I will keep it in mind). However, the situation you mention 
in #836283 only affects the build-time tests, which are not likely to use a lot 
of memory here because they are extremely slimmed down and only act on small 
inputs (btw, I’m also upstream for GenomeTools).

> Also, if you are calling external programs which accept command line
> options to enable/disable parallel processing, make sure that no
> parallel processing is happening (when DEB_BUILD_OPTIONS is setup
> that way).

OK. The default for these tests, for example, is to use 1 thread by default if 
no specific value is given.

I must admit that I’m inclined to either close this bug or leave it open with 
the comment that the issue is currently not reproducible. At least it’s 
difficult to debug if I can’t get it to fail…
What do you think?

Cheers
Sascha

Bug#834974: Installation Report: Stretch Alpha 7 on Cubox-i4pro

[Gunnar Wolf]

tags 834974 + confirmed
thanks

Martin Michlmayr dijo [Mon, Aug 29, 2016 at 07:49:48PM -0700]:
> The log suggests that flash-kernel was installed successfully, i.e.
> that a u-boot boot script was generated correctly.
> 
> I don't know anything about this device so unfortunately I cannot help
> you.  Maybe Vagrant Cascadian knows something?

I own a Cubox-i4pro as well, and can assert I Rainer's experience is
reproducible: The installer finishes doing its work and reports having
installed the boot loader, but after it attempts to reboot, nothing
happens (the computer just hangs idly).

My Cubox-i was originally installed via a chroot and manual boot
fiddling, as I reported on my blog back in the day¹. In order to check
whether this was a regression, I tried installing Jessie, and also
ended up with a seemingly successful install that didn't boot.

¹ http://gwolf.org/content/cubox-i4pro

I might have botched something while preparing my Jessie install:
Having all the files at the same directory, it is possible I booted it
with the Stretch kernel — and I fear that because my syslog starts
with:

Jan  1 00:00:03 syslogd started: BusyBox v1.22.1
Jan  1 00:00:03 kernel: klogd started: BusyBox v1.22.1 (Debian 1:1.22.0-19)
Jan  1 00:00:03 kernel: [0.00] Booting Linux on physical CPU 0x0
Jan  1 00:00:03 kernel: [0.00] Linux version 4.6.0-1-armmp 
(debian-ker...@lists.debian.org) (gcc version 5.4.0 20160609 (Debian 5.4.0-4) ) 
#1 SMP Debian 4.6.2-2 (2016-06-25)

and of course, the installer started by telling me of a kernel version
conflict :) I cannot dig deeper into this today, but I'll come back to
this topic on Monday. Can somebody confirm whether the Jessie
installer actually works reliably on this machine? (that is, whether
it's always been broken or we have a regression)

Bug#836377: build system terminal locale not inherited by build programs

[gregor herrmann]

On Fri, 02 Sep 2016 17:29:33 +, Holger Levsen wrote:

> On Fri, Sep 02, 2016 at 10:40:17PM +1000, Ben Finney wrote:
> > The bug also appears on the normal buildd hosts. Should we remove
> >  from the loop?
> then I suppose this is an RC bug in dput :-D

I consider the following as RC as well:

% dput $whatever.changes

Trying to upload package to ftp-master (ftp.upload.debian.org)
Checking signature on .changes
Traceback (most recent call last):
  File "/usr/bin/dput", line 11, in 
load_entry_point('dput==0.10.2', 'console_scripts', 'execute-dput')()
  File "/usr/share/dput/dput/dput.py", line 1053, in main
config, check_only, check_version, unsigned_upload, debug)
  File "/usr/share/dput/dput/dput.py", line 415, in verify_files
config, check_only, unsigned_upload, binary_upload, debug)
  File "/usr/share/dput/dput/dput.py", line 313, in verify_signature
check_signature(changes_file)
  File "/usr/share/dput/dput/dput.py", line 248, in check_signature
gnupg_stdout = dputhelper.make_text_stream(gnupg_subprocess.stdout)
  File "/usr/share/dput/dput/helper/dputhelper.py", line 188, in 
make_text_stream
result = io.TextIOWrapper(stream, encoding=encoding)
AttributeError: 'file' object has no attribute 'readable'
gpg: Signature made Sat Sep  3 01:42:56 2016 CEST
[..]
 

Cheers,
gregor


-- 
 .''`.  Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Rolling Stones: You Can't Always Get What You Want


signature.asc
Description: Digital Signature

Bug#832713: systemd: after "systemd (231-1) unstable" update systemd-jurnald.service fails to start

[Felipe Sateler]

On 30 August 2016 at 13:43, Felipe Sateler  wrote:
> On 30 August 2016 at 13:32, Pete Batard  wrote:
>> On 2016.08.30 17:30, Felipe Sateler wrote:
>>>
>>> I managed to get the config from a jessie rpi by loading the 'configs'
>>> module (sudo modprobe configs). After that the config is found on
>>> /proc/config.gz
>>
>>
>> Yeah, I just discovered the same after I replied.
>> This is also documented on the official rpi github repo:
>> https://github.com/raspberrypi/firmware/issues/442
>>
>> I am  therefore attaching the config.gz for my current kernel.
>
> OK. So there is CONFIG_SECCOMP but no CONFIG_SECCOMP_FILTER. The first
> leads to having Seccomp: 0 in the status file, but then no filter
> support means that any actual program systemd tries to load fails.
> BTW, it might be a good idea to file an issue to the raspbian people
> so that they enable CONFIG_SECCOMP_FILTER, or disable SECCOMP
> entirely.
>
> I think I will be able to reproduce the issue now.

It took a while to reproduce (it was not obvious how to produce a
kernel with seccomp but no filtering), but I managed to reproduce.
Patch is up for review upstream:
https://github.com/systemd/systemd/pull/4087

-- 

Saludos,
Felipe Sateler

Bug#822697: Experimental packages.

[Vladimir K]

I'm trying new Qt packages from experimental and found that GTK integration 
does not work.

I've installed qt5-gtk-platformtheme and testing with:

QT_QPA_PLATFORMTHEME=gtk3  screengrab

App looks like it uses Fusion.

Could not find any docs on how to properly use qt5-gtk-platformtheme.

Bug#833719: firerefox: NS_ERROR_NET_INADEQUATE_SECURITY on Google & Facebook only with i386 build

[Dan Hill-Moses]

I have this issue with amd64 builds and the 48.0-1+b1 build.

Bug#797998: unknown-horizons: Crash shortly after start of single player game

[Markus Koschany]

Control: severity -1 grave
Control: tags -1 confirmed

On Wed, 20 Jul 2016 16:58:19 +0200 Nils Dagsson Moskopp
 wrote:
> Package: unknown-horizons
> Version: 2014.1+ds1-2
> Followup-For: Bug #797998
> 
> Dear Maintainer,
> 
> I have updated the python-fife package, suspecting it might be too old.
> The game now crashes immediately when started. See the terminal output:
> 
> --- snib ---
> 
> # 2016-07-20T16:46+0200 $home 
> ; unknown-horizons
> Traceback (most recent call last):
>   File 
> "/usr/lib/python2.7/dist-packages/horizons/engine/generate_atlases.py", line 
> 64, in 
> from run_uh import init_environment
> ImportError: No module named run_uh
> Atlas generation failed. Continuing without atlas support.
> This just means that the game will run a bit slower.
> It will still run fine unless there are other problems.
> 
> Traceback (most recent call last):
>   File "/usr/games/unknown-horizons", line 380, in 
> main()
>   File "/usr/games/unknown-horizons", line 189, in main
> ret = horizons.main.start(options)
>   File "/usr/lib/python2.7/dist-packages/horizons/main.py", line 192, in start
> horizons.globals.fife.init()
>   File "/usr/lib/python2.7/dist-packages/horizons/engine/engine.py", line 
> 178, in init
> self._setting.apply()
>   File "/usr/lib/python2.7/dist-packages/horizons/engine/settings.py", line 
> 91, in apply
> change_language(language)
>   File "/usr/lib/python2.7/dist-packages/horizons/i18n/__init__.py", line 
> 125, in change_language
> horizons.globals.fife.pychan.loadFonts(fontdef)
>   File "/usr/lib/python2.7/dist-packages/fife/extensions/pychan/fonts.py", 
> line 88, in loadFonts
> for font in Font.loadFromFile(filename):
>   File "/usr/lib/python2.7/dist-packages/fife/extensions/pychan/fonts.py", 
> line 73, in loadFromFile
> fonts.append( Font(name,_get) )
>   File "/usr/lib/python2.7/dist-packages/fife/extensions/pychan/fonts.py", 
> line 46, in __init__
> self.font.setAntiAlias(self.antialias)
>   File "/usr/lib/python2.7/dist-packages/fife/fife.py", line 3917, in 
> setAntiAlias
> return _fife.GuiFont_setAntiAlias(self, antiAlias)
> TypeError: in method 'GuiFont_setAntiAlias', argument 2 of type 'bool'
> AL lib: (EE) alc_cleanup: 1 device not closed
> # exited 1
> 
> --- snab ---

Confirmed. This happens with python-fife version 0.3.5-2 and 0.3.5-3.
The game won't start thus making it unusable.

Markus




signature.asc
Description: OpenPGP digital signature

Bug#836428: hurd, initscripts: /tmp cleaning deletes files through a firmlink

[Richard Braun]

On Sat, Sep 03, 2016 at 01:12:27AM +0300, Kalle Olavi Niemitalo wrote:
> Richard Braun  writes:
> 
> > This was famously shown with the example of the
> > firmlink translator used in /tmp, which would cause the removal of
> > any file targeted by the firmlink on /tmp cleanup during system
> > startup.
> 
> That was already fixed in daemons/rc.sh as Debian bug #39925
> (hurd: /libexec/rc waits for /tmp/* translators), likely in
> version 19990714 of the Debian hurd package.  The bug has been
> reintroduced: although the fixed script is still installed
> (now as /etc/hurd/rc), it is no longer run by default.  Instead,
> /lib/init/bootclean.sh in the initscripts package cleans /tmp.
> 
> I don't see an open bug report about this in the hurd or
> initscripts package, and #39925 has been deleted,
> so I'm filing a new one now.

Thanks for that.

But you do understand that it's not a fix, right ? It's just a hack.
A true fix would mean we provide the same assumptions the init
scripts on Unix.

-- 
Richard Braun

Bug#834989: [Letsencrypt-devel] Bug#834989: Cronjob fails when apache is running

[Harlan Lieberman-Berg]

Hi Andrey,

This should only happen if you used the standalone plugin the first
time, rather than the apache plugin.

What does it have for installer and authenticator in
/etc/letsencrypt/renewal/.conf?

Sincerely,
-- 
Harlan Lieberman-Berg
~hlieberman

Bug#802212: libpam-ssh: pam-ssh returns PAM_NO_MODULE_DATA, when no .ssh directory found

[burban]

Hi,

Hit by the same problem. I think there are 2 issues at play here.

First, it doesn't make sense that failing to retrieve "ssh_agent_pid"
returns an error, as the agent wasn't started at all. We should return
PAM_SUCCESS, like we do when $HOME/.ssh doesn't exist at session
opening.

So the code I use in pam_ssh.c in function pam_sm_close_session is:

/* retrieve the agent's process id */
 
-   if ((retval = pam_get_data(pamh, "ssh_agent_pid",
+   if ((pam_get_data(pamh, "ssh_agent_pid",
(const void **)(void *)_agent_pid)) != PAM_SUCCESS) {
openpam_restore_cred(pamh);
-   return retval;
+   return PAM_SUCCESS;
}

Secondly, I discovered while debugging the issue that my logs
contained the message "inexistent configuration directory", when I was
performing a su to root, where /root/.ssh existed. So that directory
wasn't detected. The existence test is done in function
pam_sm_open_session with the access() system call, which man page
states:

"The check is done using the calling process's real UID and GID,
 rather than the effective IDs as is done when actually attempting an
 operation"

And su which is using libpam_ssh is suid... So you can never start an
ssh_agent (it's the main task of the pam_ssh session module) when you
su from an unpriviledged user to root!

Notice that the pam_ssh authentication module is fine, it doesn't use
access().

Here my patch was to use opendir() instead:

openpam_restore_cred(pamh);
return PAM_SERVICE_ERR;
}
-   if ((access(dotdir,F_OK)) == -1) {
-   pam_ssh_log(LOG_DEBUG, "inexistent configuration directory");
-   free(dotdir);
-   openpam_restore_cred(pamh);
-   return PAM_SUCCESS;
+   {
+ DIR *dirs;
+ if (dirs = opendir(dotdir)) {
+   closedir(dirs);
+ } else {
+   pam_ssh_log(LOG_DEBUG, "inexistent configuration directory");
+   free(dotdir);
+   openpam_restore_cred(pamh);
+   return PAM_SUCCESS;
+ }
}

Regards.

-- 

Bernard

Bug#836427: apt: Dir::Etc is different by a trailing slash between stable and unstable

[Anne C. Hanna]

Thanks for the clarification, Julian.  I will (attempt to) pass that along to
the skypeforlinux developers.

 - Anne



signature.asc
Description: OpenPGP digital signature

Bug#836427: apt: Dir::Etc is different by a trailing slash between stable and unstable

[Julian Andres Klode]

On Fri, Sep 02, 2016 at 05:34:54PM -0400, Anne C. Hanna wrote:
> Package: apt
> Version: 1.3~rc3
> Severity: minor
> 
> The Dir::Etc entry in the apt-config defaults seems to have changed somewhere
> between the current stable (1.0.9.8.3) and unstable (1.3~rc3) versions.  In
> stable, the default seems to be:
> 
> Dir::Etc "etc/apt/";
> 
> while in unstable it's:
> 
> Dir::Etc "etc/apt";

That's a side effect of making that user configurable. I could probably change
the default back to add a slash, but relying on the value of a Dir:: option is
broken anyway (except for some Dir::Bin::...) - you must always access them
correctly as either directory (Dir::Etc/d in apt-config) or file (Dir::Etc/f
in apt-config).

> 
> without the trailing slash.  This causes a slight problem with installation of
> Microsoft's skypeforlinux alpha package (see the discussion starting here:
> https://community.skype.com/t5/Linux/Skype-for-Linux-Alpha-and-calling-on-Chrome-amp-Chromebooks/m-p/4468583/highlight/true#M15719
> ), so a few of us users are trying to determine whether this is an intentional
> change that we should ask the skypeforlinux developers to respect or a bug in
> apt unstable that should be fixed on that side.  (The skypeforlinux alpha
> package appears to have some other issues too, but I'll leave those aside for
> now.)

That software is broken. I'm not sure how it queries its stuff,
but if it is using apt-config, it forgot to append /d to get a
directory path.

You may not use the value of Dir::Etc, Dir::State and so on
without /d. Especially for sources.list.d, there should be
non concatenation at all it should be

Dir::Etc::SourceParts/d

That gives you the right path, including root directory settings
and other shit.

-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev

When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to (`inline'). Thank you.

Bug#836428: hurd, initscripts: /tmp cleaning deletes files through a firmlink

[Kalle Olavi Niemitalo]

Package: hurd
Version: 1:0.8.git20160826-1

Richard Braun  writes:

> This was famously shown with the example of the
> firmlink translator used in /tmp, which would cause the removal of
> any file targeted by the firmlink on /tmp cleanup during system
> startup.

That was already fixed in daemons/rc.sh as Debian bug #39925
(hurd: /libexec/rc waits for /tmp/* translators), likely in
version 19990714 of the Debian hurd package.  The bug has been
reintroduced: although the fixed script is still installed
(now as /etc/hurd/rc), it is no longer run by default.  Instead,
/lib/init/bootclean.sh in the initscripts package cleans /tmp.

I don't see an open bug report about this in the hurd or
initscripts package, and #39925 has been deleted,
so I'm filing a new one now.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: hurd-i386 (i686-AT386)

Kernel: GNU-Mach 1.7+git20160809-486-dbg/Hurd-0.8
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages hurd depends on:
ii  hurd-libs0.3  1:0.8.git20160826-1
ii  libblkid1 2.28.1-1
ii  libbz2-1.01.0.6-8
ii  libc0.3   2.23-5
ii  libdaemon00.14-6
ii  libncursesw5  6.0+20160625-1+b1
ii  libtinfo5 6.0+20160625-1+b1
ii  libx11-6  2:1.6.3-1+b1
ii  netdde0.0.20150828-3
ii  sysv-rc   2.88dsf-59.8
ii  xkb-data  2.17-1
ii  zlib1g1:1.2.8.dfsg-2

Versions of packages hurd recommends:
pn  bf-utf-source  

Versions of packages hurd suggests:
pn  hurd-doc  

Versions of other related packages:
ii  initscripts2.88dsf-59.8
ii  sysvinit-core  2.88dsf-59.8
ii  sysvinit-utils 2.88dsf-59.8
ii  coreutils  8.25-2+b1

-- Configuration Files:
/etc/default/hurd-console changed:
ENABLE='false'
DISPLAY='-d vga'
KBD='-d pc_kbd'
if [ -f /etc/default/keyboard ]
then
  . /etc/default/keyboard
fi
[ -z "$XKBLAYOUT" ] || KBD="$KBD --keymap $XKBLAYOUT"
KBD_REPEAT='--repeat=kbd'
MOUSE='-d pc_mouse --protocol=ps/2'
MOUSE_REPEAT='--repeat=mouse'

/etc/hurd/rc changed:
PATH=/bin:/sbin:/usr/bin:/usr/sbin
swapon -a
echo juu > /doh
if [ -r /fastboot ]
then
# ... or don't.
rm -f /fastboot
echo Fast boot ... skipping disk checks
elif [ $1x = autobootx ]
then
echo Automatic boot in progress...
date
fsysopts / --update --readonly
/sbin/fsck -p -A
case $? in
# Successful completion
0)
fsysopts / --update --writable
;;
# Filesystem modified (but ok now)
1)
fsysopts / --update --writable
;;
# Filesystem modified, filesystem should be restarted
# Ideally we would only restart the filesystem
2 | 3)
/sbin/reboot
;;
# Fsck couldn't fix it.
4 | 5 | 8 | 9)
echo "Automatic boot failed... help!"
exit 1
;;
# Signal that really interrupted something
20 | 130 | 131)
echo "Boot interrupted"
exit 1
;;
# Special `let fsck finish' interruption (SIGQUIT)
12)
echo "Boot interrupted (filesystem checks complete)"
exit 1
;;
# Oh dear.
*)
echo "Unknown error during fsck (exit status $?)"
exit 1
;;
esac
fi
echo -n cleaning up left over files...
rm -f /etc/nologin
rm -f /var/lock/LCK.*
if test -d /tmp; then
  # Forcibly remove all translators in the directory.
  # It is then safe to attempt to remove files and descend directories.
  # All parameters must begin with "./".
  function remove_translators() {
local f
for f; do
  settrans -pagfS "$f"
  if [ -L "$f" ] || [ ! -d "$f" ]; then
rm "$f"
  else
remove_translators "$f"/* "$f"/.[!.] "$f"/.??*
rmdir "$f"
  fi
done
  }
  (cd /tmp
   shopt -s nullglob
   for f in * .[!.] .??*; do
 case "$f" in
 'lost+found'|'quotas') ;;
 *) remove_translators "./$f"
 esac
   done)
  unset -f remove_translators  # because it relies on nullglob
fi
if test -d /var/run; then
  (cd /var/run && {
find . ! -type d ! -name utmp ! -name innd.pid \
  -exec rm -f -- {} \;
cp /dev/null utmp
if grep -q ^utmp: /etc/group
then
chmod 664 utmp
chgrp utmp utmp
fi; })
fi
rm -fr /run/*
mkdir -p /run/lock /run/shm
chmod 1777 /run/lock /run/shm
: > /run/utmp
echo done
if ! test -e /proc/cmdline ; then
  settrans -c /proc /hurd/procfs --compatible
fi
ln -s /proc/mounts /var/run/mtab
ln -sf /proc/mounts /etc/mtab
chmod 664 /etc/motd
(
trap ":" INT QUIT TSTP
if [ -d /etc/rc.boot ]
then
for i in /etc/rc.boot/S*
do
[ ! -f $i ] && continue

Bug#832336: jessie-pu: package systemd/215-17+deb8u5

[Michael Biebl]

Am 02.09.2016 um 22:12 schrieb Adam D. Barratt:
> Sorry for the delays. I've been arguing with myself about the fsck fix
> as well, but I'd be happy for the remainder to be uploaded.

Ok then, uploaded with that one particular change backed out.

Regards,
Michael

-- 
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#826300: Share knowledge on fpc and powerpc issue

[Abou Al Montacir]

Hi All,

On Mon, 2016-08-29 at 11:59 +0200, Abou Al Montacir wrote:
...

> Please hold on, upstream fond the issue.
> The issue is related to longjump in cprt0.as. 
> They are going to give us a fix in the next few days.

Upstream suggests the following patch which may be temporary:diff --git 
a/rtl/linux/powerpc/cprt0.as b/rtl/linux/powerpc/cprt0.as
index e237d8d..a5672e3 100644
--- a/rtl/linux/powerpc/cprt0.as
+++ b/rtl/linux/powerpc/cprt0.as
@@ -88,12 +88,8 @@ main_stub:
 .globl  _haltproc
 .type   _haltproc, @function
 _haltproc:
-    lis 11, ___fpc_ret@ha
-    lwz 1, ___fpc_ret@l(11)
-    addi    1, 1, 16
-    lwz 0, 0(1)
-    mtlr    0
-    blr
+    bl _exit
+    b  _haltproc

 #    li  0, 1   /* exit call */
 #    lis 3, operatingsystem_result@h
-- 
Cheers,
Abou Al Montacir



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

Bug#836415: nodejs: SIGILL when running nodejs

[Jérémy Lal]

2016-09-02 21:37 GMT+02:00 Sam Imberman :

> Package: nodejs
> Version: 6.0.0~dfsg-1
> Severity: important
>
> Dear Maintainer,
>
> I am unable to run nodejs at all on a PowerBook G4 12", because of an
> illegal
> instruction. This is true for both the version in "sid" (4.x?) and
> "experimental" (6.0.0)
>
> "cat /proc/cpuinfo | grep cpu" returns:
> cpu : 7447A, altivec supported
>
>
> Here is some debugger output that someone suggested I send with my bug
> report:
>
> (gdb) run
> Starting program: /usr/bin/nodejs
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/powerpc-linux-gnu/
> libthread_db.so.1".
> [New Thread 0xb7fba450 (LWP 1712)]
> [New Thread 0xb77ba450 (LWP 1713)]
> [New Thread 0xb6fba450 (LWP 1714)]
> [New Thread 0xb67ba450 (LWP 1715)]
>
> Program received signal SIGILL, Illegal instruction.
> 0x6007e388 in ?? ()
> (gdb) x/i $pc
> => 0x6007e388:  fcfid   f1,f1
> (gdb) x/x $pc
> 0x6007e388: 0xfc200e9c
> (gdb)
>
> I am glad to supply more information if necessary - I am a competent Debian
> user but I do not know very much about debugging this sort of thing.
>
> Thanks,
> Sam
>

Please install nodejs-dbg package and do the same report again.

Thanks,
Jérémy.

Bug#828589: uw-imap: FTBFS with openssl 1.1.0

[Sebastian Andrzej Siewior]

control: tags -1 patch

On 2016-06-26 12:24:37 [+0200], Kurt Roeckx wrote:
> OpenSSL 1.1.0 is about to released.  During a rebuild of all packages using
> OpenSSL this package fail to build.  A log of that build can be found at:
> https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/uw-imap_2007f~dfsg-4_amd64-20160529-1548
> 
> On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of 
> the
> reasons why it might fail.  There are also updated man pages at
> https://www.openssl.org/docs/manmaster/ that should contain useful 
> information.
> 
> There is a libssl-dev package available in experimental that contains a recent
> snapshot, I suggest you try building against that to see if everything works.

So I tried. However this code is level advanced and my skill level is
somewhere between easy and medium. More strong medium. This has been
compiled tested.

> Kurt

Sebastian
>From c3f68d987c00284d91ad6599a013b7111662545b Mon Sep 17 00:00:00 2001
From: Sebastian Andrzej Siewior 
Date: Fri, 2 Sep 2016 21:33:33 +
Subject: [PATCH] uw-imap: compile against openssl 1.1.0

I *think* I replaced access to cert->name with certificate's subject name. I
assume that the re-aranged C-code is doing the same thing. A double check
wouldn't hurt :)

Signed-off-by: Sebastian Andrzej Siewior 
---
 src/osdep/unix/ssl_unix.c | 28 +---
 1 file changed, 17 insertions(+), 11 deletions(-)

diff --git a/src/osdep/unix/ssl_unix.c b/src/osdep/unix/ssl_unix.c
index 3bfdff3..836e9fa 100644
--- a/src/osdep/unix/ssl_unix.c
+++ b/src/osdep/unix/ssl_unix.c
@@ -59,7 +59,7 @@ typedef struct ssl_stream {
 static SSLSTREAM *ssl_start(TCPSTREAM *tstream,char *host,unsigned long flags);
 static char *ssl_start_work (SSLSTREAM *stream,char *host,unsigned long flags);
 static int ssl_open_verify (int ok,X509_STORE_CTX *ctx);
-static char *ssl_validate_cert (X509 *cert,char *host);
+static char *ssl_validate_cert (X509 *cert,char *host, char *cert_subj);
 static long ssl_compare_hostnames (unsigned char *s,unsigned char *pat);
 static char *ssl_getline_work (SSLSTREAM *stream,unsigned long *size,
 			   long *contd);
@@ -210,6 +210,7 @@ static char *ssl_start_work (SSLSTREAM *stream,char *host,unsigned long flags)
   BIO *bio;
   X509 *cert;
   unsigned long sl,tl;
+  char cert_subj[250];
   char *s,*t,*err,tmp[MAILTMPLEN];
   sslcertificatequery_t scq =
 (sslcertificatequery_t) mail_parameters (NIL,GET_SSLCERTIFICATEQUERY,NIL);
@@ -266,14 +267,19 @@ static char *ssl_start_work (SSLSTREAM *stream,char *host,unsigned long flags)
   if (SSL_write (stream->con,"",0) < 0)
 return ssl_last_error ? ssl_last_error : "SSL negotiation failed";
 /* need to validate host names? */
-  if (!(flags & NET_NOVALIDATECERT) &&
-  (err = ssl_validate_cert (cert = SSL_get_peer_certificate (stream->con),
-host))) {
-/* application callback */
-if (scq) return (*scq) (err,host,cert ? cert->name : "???") ? NIL : "";
+  if (!(flags & NET_NOVALIDATECERT)) {
+
+	cert_subj[0] = '\0';
+	cert = SSL_get_peer_certificate(stream->con);
+	if (cert)
+		X509_NAME_oneline(X509_get_subject_name(cert), cert_subj, sizeof(cert_subj));
+	err = ssl_validate_cert (cert, host, cert_subj);
+	if (err)
+		/* application callback */
+		if (scq) return (*scq) (err,host,cert ? cert_subj : "???") ? NIL : "";
 /* error message to return via mm_log() */
-sprintf (tmp,"*%.128s: %.255s",err,cert ? cert->name : "???");
-return ssl_last_error = cpystr (tmp);
+	sprintf (tmp,"*%.128s: %.255s",err,cert ? cert_subj : "???");
+	return ssl_last_error = cpystr (tmp);
   }
   return NIL;
 }
@@ -313,7 +319,7 @@ static int ssl_open_verify (int ok,X509_STORE_CTX *ctx)
  * Returns: NIL if validated, else string of error message
  */
 
-static char *ssl_validate_cert (X509 *cert,char *host)
+static char *ssl_validate_cert (X509 *cert,char *host, char *cert_subj)
 {
   int i,n;
   char *s,*t,*ret;
@@ -322,9 +328,9 @@ static char *ssl_validate_cert (X509 *cert,char *host)
 /* make sure have a certificate */
   if (!cert) ret = "No certificate from server";
 /* and that it has a name */
-  else if (!cert->name) ret = "No name in certificate";
+  else if (cert_subj[0] == '\0') ret = "No name in certificate";
 /* locate CN */
-  else if (s = strstr (cert->name,"/CN=")) {
+  else if (s = strstr (cert_subj,"/CN=")) {
 if (t = strchr (s += 4,'/')) *t = '\0';
 /* host name matches pattern? */
 ret = ssl_compare_hostnames (host,s) ? NIL :
-- 
2.9.3

Bug#834318: c-blosc: please update c-blosc

[Daniel Stender]

On 02.09.2016 23:20, Jean-Christophe Jaskula wrote:
> 
>> Le 1 sept. 2016 à 13:59, Daniel Stender  a écrit :
>>
>> On 01.09.2016 17:49, Jean-Christophe Jaskula wrote:
>>> Hey Daniel,
>>>
>>> Sorry I have been busy these days and lost track of my emails. I might be 
>>> able to do it quickly these next days too. There would be the step of 
>>> sponsorship and I don’t know if Mathieu would be available right away to 
>>> check the package. 
>>>
>>> On the other hand, I could orphan the package if you wish and/or intend to 
>>> update it frequently. Also FYI, I had started the packaging of python-blosc 
>>> and its friends but it never went to a state where I would send them over.
>>>
>>> Cheers,
>>> JC
>>
>> Hi,
>>
>> ... no problem.
>>
>> Yes, I would sponsor the upload if you going to have an updated package 
>> ready.
>>
>> Beyond that, yes I would be interested in constantly looking after/taking 
>> care of blosc. No need to orphan
>> it - I'm going to change the Maintainer field, then (if you could sign an 
>> email/reply saying that this is all
>> right with you, that would be o.k.).
>>
>> I've filed ITP bugs for python-blosc and bloscpack recently, making a wrap. 
>> If you would like to send
>> over your work on that so far, I would keep you in deb/copyright then.
>>
>> DS
> 
> Hi,
> 
> I won’t have time to do anything this weekend. You can take over this package 
> if you wish. Please tell me if you want a signed text file.
> 
> Thank you for taking care of that.
> JC

Yes, all right, I'll take care of the package. It's a wrap with the Python 
packages depending on that.

I think it's not required for that, but if you could state that also in a 
signed reply some time in the next
days, that would be great ...

DS

-- 
4096R/DF5182C8
http://www.danielstender.com/blog/

Bug#836314: 9wm: man page update

[Jacob Adams]

control: tags -1 + fixed-upstream

On 09/01/2016 10:27 AM, Ricardo Fabian Peliquero wrote:
> < -cursor cursor
>> -curs cursor

Thanks for finding this!
This should have been -cursor not -curs

It has now been fixed upstream as of commit a650d4850eba
A new release will be published ASAP.

-- 
Jacob Adams
GPG Key: AF6B 1C26 E2D0 A988 432B  94F4 24C0 2B85 B59F E5A9



signature.asc
Description: OpenPGP digital signature

Bug#836407: RFP: libjs-jquery-at.js -- Autocompletion library to autocomplete mentions, smileys, etc

[Sergio Durigan Junior]

On Friday, September 02 2016, Andrew Shadura wrote:

> Hi,
>
> On 2 September 2016 at 19:17, Sergio Durigan Junior
>  wrote:
>> Package: wnpp
>> Severity: wishlist
>> Owner: Sergio Durigan Junior 
>>
>> * Package name: libjs-jquery-at.js
>>   Version : 1.4.1
>>   Upstream Author : Harold.Luo 
>> * URL : https://github.com/ichord/At.js
>> * License : Expat
>>   Programming Lang: JavaScript
>>   Description: Autocompletion library to autocomplete mentions, smileys, etc
>
> It is actually in Debian already: ruby-jquery-atwho-rails, see
> https://bugs.debian.org/832583

Thanks for pointing that out.

It seems to me that the bug has not been fixed yet, right?

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#827296: #827296 - connman: Connman slow down the boot when no network available

[Kristian Klausen]

Hi

Yes it was changed in June, see 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812209

- Kristian


> Subject: Bug#827296: #827296 - connman: Connman slow down the boot when no 
> network available
> From: a...@debian.org
> Date: Fri, 2 Sep 2016 13:55:21 +0200
> To: klausenb...@hotmail.com
> CC: 827...@bugs.debian.org; flor...@biree.name; cont...@bugs.debian.org
>
> Hi,
>
> so NM does enable the wait job by default also? Just timeout
> difference? If not I tend to agree that whatever the NM default is
> this one should have as well (assuming folks are happy with NM boot
> behaviour).
>
> Let me know,
>
> - Alexander
>
> 2016-09-02 11:05 GMT+02:00 Kristian Klausen :
>> Never mind, maybe I should reread the bug report next time before I
>> respond..
>>
>>
>> 
>> From: klausenb...@hotmail.com
>> To: a...@debian.org; 827...@bugs.debian.org
>> CC: flor...@biree.name; cont...@bugs.debian.org
>> Subject: RE: Bug#827296: #827296 - connman: Connman slow down the boot when
>> no network available
>> Date: Fri, 2 Sep 2016 11:03:15 +0200
>>
>>
>> Hello Alexander
>>
>> NetworkManager don't enable it as default which Connman does.
>> I think that is what the bug report is about :)
>>
>> Regards
>> Kristian Klausen
>>
>>> Subject: Bug#827296: #827296 - connman: Connman slow down the boot when no
>>> network available
>>> From: a...@debian.org
>>> Date: Fri, 2 Sep 2016 10:53:45 +0200
>>> To: 827...@bugs.debian.org
>>> CC: flor...@biree.name; cont...@bugs.debian.org
>>>
>>> tags 827296 + moreinfo
>>> severity 827296 normal
>>> thanks
>>>
>>> Hi,
>>>
>>> this seems to be a feature. Seems you were able to resolve this issue?
>>> Anything you think that should be done here?
>>>
>>> Network Manager also has a similar wait job. timeout there is 30
>>> seconds. connman just seem to have a higher default timeout in code
>>> (120 seconds).
>>>
>>> You could customize the job with --timeout=30 or we could use that as
>>> the default in the package if we feel there is strong reason to
>>> believe that majority of debian users will want the shorter timeout.
>>>
>>> Let me know if you are happy with the ability to tweak by yourself...
>>>
>>> Thanks,
>>>
>>> - Alexander
>>>
>
  

Bug#836427: apt: Dir::Etc is different by a trailing slash between stable and unstable

[Anne C. Hanna]

Package: apt
Version: 1.3~rc3
Severity: minor

The Dir::Etc entry in the apt-config defaults seems to have changed somewhere
between the current stable (1.0.9.8.3) and unstable (1.3~rc3) versions.  In
stable, the default seems to be:

Dir::Etc "etc/apt/";

while in unstable it's:

Dir::Etc "etc/apt";

without the trailing slash.  This causes a slight problem with installation of
Microsoft's skypeforlinux alpha package (see the discussion starting here:
https://community.skype.com/t5/Linux/Skype-for-Linux-Alpha-and-calling-on-Chrome-amp-Chromebooks/m-p/4468583/highlight/true#M15719
), so a few of us users are trying to determine whether this is an intentional
change that we should ask the skypeforlinux developers to respect or a bug in
apt unstable that should be fixed on that side.  (The skypeforlinux alpha
package appears to have some other issues too, but I'll leave those aside for
now.)

This is pretty trivial, I suppose, but any light the developers can shed on
the issue would be appreciated.

 - Anne


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

Kernel: Linux 4.4.0-1-amd64 (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: systemd (via /run/systemd/system)

Versions of packages apt depends on:
ii  adduser 3.115
ii  debian-archive-keyring  2014.3
ii  gpgv2.1.15-2
ii  init-system-helpers 1.42
ii  libapt-pkg5.0   1.3~rc3
ii  libc6   2.24-1
ii  libgcc1 1:6.2.0-2
ii  libstdc++6  6.2.0-2

Versions of packages apt recommends:
ii  gnupg   2.1.15-2
ii  gnupg2  2.1.15-2

Versions of packages apt suggests:
pn  apt-doc 
ii  aptitude0.8.3-1
ii  dpkg-dev1.18.10
ii  powermgmt-base  1.31+nmu1
pn  python-apt  
ii  synaptic0.83+b1
ii  wajig   2.17

-- Configuration Files:
/etc/logrotate.d/apt changed [not included]

-- no debconf information



signature.asc
Description: OpenPGP digital signature

Bug#836426: Graphics rendering (with QXL graphics) doesn't update

[Josh Triplett]

Package: gnome-boxes
Version: 3.20.2-2+b1
Severity: important

("important" because I assume this doesn't happen for everyone.)

Recently, a Windows VM running in gnome-boxes (using the QXL graphics
driver with SPICE) started having an issue with graphical rendering not
updating.  The screen goes black a moment after the login screen shows
up, and never updates.  Resizing the window immediately causes the
contents to show, until the guest notices the change and changes its
video mode to match, at which point the screen goes black again.

This doesn't occur when running via KVM directly, with either the QXL or
vga driver.

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

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

Versions of packages gnome-boxes depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-1
ii  libarchive13 3.2.1-2
ii  libatk1.0-0  2.21.90-2
ii  libc62.24-1
ii  libcairo-gobject21.14.6-1+b1
ii  libcairo21.14.6-1+b1
ii  libgdk-pixbuf2.0-0   2.34.0-1
ii  libgirepository-1.0-11.49.1-2
ii  libglib2.0-0 2.49.6-1
ii  libgovirt2   0.3.4-2
ii  libgtk-3-0   3.21.5-3
ii  libgtk-vnc-2.0-0 0.5.3-1.3+b1
ii  libgudev-1.0-0   230-3
ii  libgvnc-1.0-00.5.3-1.3+b1
ii  libosinfo-1.0-0  0.3.1-5
ii  libosinfo-bin0.3.1-5
ii  libpango-1.0-0   1.40.2-1
ii  libpangocairo-1.0-0  1.40.2-1
ii  librest-0.7-00.8.0-1
ii  libsoup2.4-1 2.55.90-1
ii  libspice-client-glib-2.0-8   0.32-1
ii  libspice-client-gtk-3.0-50.32-1
ii  libtracker-sparql-1.0-0  1.8.0-4+b1
ii  libusb-1.0-0 2:1.0.20-1
ii  libuuid1 2.28.1-1
ii  libvirt-daemon   2.1.0-2
ii  libvirt-glib-1.0-0   0.2.3-2
ii  libvirt0 2.1.0-2
ii  libxml2  2.9.4+dfsg1-1+b1
ii  mtools   4.0.18-2
ii  tracker  1.8.0-4+b1

Versions of packages gnome-boxes recommends:
ii  qemu-system-x86  1:2.6+dfsg-3

gnome-boxes suggests no packages.

-- no debconf information

Bug#834318: c-blosc: please update c-blosc

[Jean-Christophe Jaskula]

> Le 1 sept. 2016 à 13:59, Daniel Stender  a écrit :
> 
> On 01.09.2016 17:49, Jean-Christophe Jaskula wrote:
>> Hey Daniel,
>> 
>> Sorry I have been busy these days and lost track of my emails. I might be 
>> able to do it quickly these next days too. There would be the step of 
>> sponsorship and I don’t know if Mathieu would be available right away to 
>> check the package. 
>> 
>> On the other hand, I could orphan the package if you wish and/or intend to 
>> update it frequently. Also FYI, I had started the packaging of python-blosc 
>> and its friends but it never went to a state where I would send them over.
>> 
>> Cheers,
>> JC
> 
> Hi,
> 
> ... no problem.
> 
> Yes, I would sponsor the upload if you going to have an updated package ready.
> 
> Beyond that, yes I would be interested in constantly looking after/taking 
> care of blosc. No need to orphan
> it - I'm going to change the Maintainer field, then (if you could sign an 
> email/reply saying that this is all
> right with you, that would be o.k.).
> 
> I've filed ITP bugs for python-blosc and bloscpack recently, making a wrap. 
> If you would like to send
> over your work on that so far, I would keep you in deb/copyright then.
> 
> DS

Hi,

I won’t have time to do anything this weekend. You can take over this package 
if you wish. Please tell me if you want a signed text file.

Thank you for taking care of that.
JC

Bug#835427: s/XML_NO_ERROR/XML_SUCCESS/

[Peter Green]

On 29/08/16 15:45, Peter Michael Green wrote:

tags 835427 +patch
thanks
Older versions of tinyxml defined both XML_NO_ERROR and XML_SUCCESS 
to 0. Never

versions define only XML_SUCCESS.


Attatched is a patch that replaces XML_NO_ERROR with XML_SUCCESS
Unfortunately while that patch fixed the FTBFS in raspbian stretch at 
the time the package is now failing for us for a different reason. While 
I saw this in raspbian I have no reason to belive it is raspbian specific.



In file included from /usr/include/spnav.h:33:0,
 from /<>/gazebo-7.3.0+dfsg/gazebo/gui/SpaceNav.cc:27:
/usr/include/google/protobuf/stubs/logging.h:66:7: error: expected identifier 
before 'int'
 class Status;
   ^
/usr/include/google/protobuf/stubs/logging.h:66:7: error: multiple types in one 
declaration
In file included from /usr/include/google/protobuf/stubs/common.h:45:0,
 from /usr/include/google/protobuf/stubs/atomicops.h:59,
 from 
/usr/include/google/protobuf/stubs/atomic_sequence_num.h:33,
 from /usr/include/google/protobuf/arena.h:52,
 from /usr/include/google/protobuf/message.h:118,
 from 
/<>/gazebo-7.3.0+dfsg/gazebo/transport/CallbackHelper.hh:20,
 from 
/<>/gazebo-7.3.0+dfsg/obj-arm-linux-gnueabihf/gazebo/transport/transport.hh:2,
 from 
/<>/gazebo-7.3.0+dfsg/gazebo/gui/SpaceNavPrivate.hh:23,
 from /<>/gazebo-7.3.0+dfsg/gazebo/gui/SpaceNav.cc:31:
/usr/include/google/protobuf/stubs/logging.h:90:32: error: expected ')' before 
'::' token
   LogMessage&  operator<<(const ::google::protobuf::util::Status&  status);
^~
/usr/include/google/protobuf/stubs/logging.h:90:32: error: 
'google::protobuf::internal::LogMessage&  
google::protobuf::internal::LogMessage::operator<<(...)' must not have variable 
number of arguments
/usr/include/google/protobuf/stubs/logging.h:90:26: error: expected ';' at end 
of member declaration
   LogMessage&  operator<<(const ::google::protobuf::util::Status&  status);
  ^
In file included from /usr/include/spnav.h:33:0,
 from /<>/gazebo-7.3.0+dfsg/gazebo/gui/SpaceNav.cc:27:
/usr/include/google/protobuf/stubs/logging.h:90:58: error: expected 
unqualified-id before 'int'
   LogMessage&  operator<<(const ::google::protobuf::util::Status&  status);
  ^
gazebo/gui/CMakeFiles/gazebo_gui.dir/build.make:1194: recipe for target 
'gazebo/gui/CMakeFiles/gazebo_gui.dir/SpaceNav.cc.o' failed

http://buildd.raspbian.org/status/fetch.php?pkg=gazebo=armhf=7.3.0%2Bdfsg-2%2Brpi1%2Bb1=1472782288

I'm guessing some sort of header conflict, I will try to take a look but not 
promising anything. Ideas welcome.

Bug#828453: nginx: FTBFS with openssl 1.1.0

[Kurt Roeckx]

On Fri, Sep 02, 2016 at 10:52:14PM +0200, Kurt Roeckx wrote:
> nginx-upstream-fair also has a problem with the reference
> counters.

Patch here:
https://github.com/gnosek/nginx-upstream-fair/pull/22


Kurt

Bug#836425: traceroute: -i interface not working

[Julien Sansonnens]

Package: traceroute
Version: 1:2.0.20-2+b1
Severity: normal
Tags: ipv6

Dear Maintainer,

traceroute ipv6 parameters "-i interface" doesnt work correctly on my Linux 
router. I'm running BGP daemon on the router.
see this example:

traceroute6 -i mypeer ipv6.google.com
traceroute to ipv6.google.com (2a00:1450:4007:80d::200e), 30 hops max, 80 byte 
packets
connect: Le réseau n'est pas accessible
(network unreachable)

I have a route in the kernel for this network, and the interface is up and 
working. 

if I try with ping6, it works: 

ping6 -I mypeer ipv6.google.com
ping6: Warning: source address might be selected on device other than mypeer.
PING ipv6.google.com(par10s21-in-x0e.1e100.net) from 2a06: mypeer: 
56 data bytes
64 bytes from par10s21-in-x0e.1e100.net: icmp_seq=1 ttl=55 time=44.1 ms
64 bytes from par10s21-in-x0e.1e100.net: icmp_seq=2 ttl=55 time=44.3 ms

so it's not a routing (or DNS) problem, it's related to traceroute6. 
cheers julien 


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

Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages traceroute depends on:
ii  libc6  2.19-18+deb8u4

traceroute recommends no packages.

traceroute suggests no packages.

-- no debconf information

Bug#836424: hddtemp: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Diego Neves]

Package: hddtemp
Tags: l10n patch
Severity: wishlist

Hello,

Please, Could you update the Brazilian Portuguese Translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is
tested with msgfmt and podebconf-display-po.

Kind regards.

pt_BR.po.gz
Description: application/gzip


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

Bug#834266: dbconfig-pgsql: support specifying the socket dir and socket "port"

[Christoph Anton Mitterer]

On Fri, 2016-09-02 at 20:35 +0200, Paul Gevers wrote:
> I am not sure anymore. I haven't tested it, but with PostgreSQL one
> can
> just fill in the socket file name instead of the hostname, so I
> assume
> that works with dbconfig-common as well.
IIRC, the problem is simply that... *if* UNIX-sockets is chosen before,
it simply even doesn't ask you for a hostname (which it only does when
choosing TCP)...

Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature

Bug#836423: kerberos-configs: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Diego Neves]

Package: kerberos-configs
Tags: l10n patch
Severity: wishlist

Hello,

Please, Could you update the Brazilian Portuguese Translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is
tested with msgfmt and podebconf-display-po.

Kind regards.

pt_BR.po.gz
Description: application/gzip


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

Bug#836422: kerberos-configs: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Diego Neves]

Package: kerberos-configs
Tags: l10n patch
Severity: wishlist

Hello,

Please, Could you update the Brazilian Portuguese Translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is
tested with msgfmt and podebconf-display-po.

Kind regards.# Kerberos-configs Brazilian Portuguese debconf template translation.
# Copyright (C), 2006 André Luís Lopes
# This file is distributed under the same license as the kerberos-configs package.
# André Luís Lopes , 2006.
# Diego Neves , 2016.
#
msgid ""
msgstr ""
"Project-Id-Version: kerberos-configs\n"
"Report-Msgid-Bugs-To: kerberos-conf...@packages.debian.org\n"
"POT-Creation-Date: 2009-07-21 13:57-0400\n"
"PO-Revision-Date: 2016-08-31 20:46-0300\n"
"Last-Translator: Diego Neves \n"
"Language-Team: Brazilian Portuguese \n"
"Language: pt_BR\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Poedit 1.8.8\n"

#. Type: title
#. Description
#: ../krb5-config.templates:1001
msgid "Configuring Kerberos Authentication"
msgstr "Configurando Autenticação via Kerberos"

#. Type: string
#. Description
#: ../krb5-config.templates:2001
msgid "Default Kerberos version 5 realm:"
msgstr "Realm Kerberos versão 5 padrão:"

#. Type: string
#. Description
#: ../krb5-config.templates:2001
msgid ""
"When users attempt to use Kerberos and specify a principal or user name "
"without specifying what administrative Kerberos realm that principal belongs "
"to, the system appends the default realm.  The default realm may also be "
"used as the realm of a Kerberos service running on the local machine.  "
"Often, the default realm is the uppercase version of the local DNS domain."
msgstr ""
"Quando os usuários tentam utilizar o Kerberos e especificam um principal ou "
"nome de usuário sem especificar a qual realm Kerberos administrativo esse "
"principal pertence, o sistema acrescenta o realm padrão. O realm padrão "
"também pode ser usado como o realm de um serviço Kerberos em execução na "
"máquina local. Muitas vezes, o realm padrão é a versão em maiúsculas do "
"domínio DNS local."

#. Type: boolean
#. Description
#: ../krb5-config.templates:5001
msgid "Add locations of default Kerberos servers to /etc/krb5.conf?"
msgstr ""
"Adicionar as localizações dos servidores Kerberos padrão em /etc/krb5.conf?"

#. Type: boolean
#. Description
#: ../krb5-config.templates:5001
msgid ""
"Typically, clients find Kerberos servers for their default realm in the "
"domain-name system. ${dns}"
msgstr ""
"Tipicamente, clientes encontram servidores Kerberos para os seus realms "
"padrão no sistema de nomes de domínio. ${dns}"

#. Type: text
#. Description
#. Type: text
#. Description
#: ../krb5-config.templates:6001 ../krb5-config.templates:7001
msgid "short description unused"
msgstr "Descrição curta não utilizada"

#. Type: text
#. Description
#: ../krb5-config.templates:6001
msgid ""
"However, the Kerberos servers for your realm do not appear to be listed "
"either in the domain-name system or the kerberos configuration file shipped "
"with Debian. You may add them to the Kerberos configuration file or add them "
"to your DNS configuration."
msgstr ""
"No entanto, os servidores Kerberos para o seu realm não parecem estar "
"listados no sistema de nomes de domínio ou no arquivo de configuração "
"Kerberos distribuído pelo Debian. Você pode adicioná-los ao arquivo de "
"configuração Kerberos ou nas configurações do seu DNS."

#. Type: text
#. Description
#: ../krb5-config.templates:7001
msgid ""
"Servers for your realm were found in DNS. For most configurations it is best "
"to use DNS to find these servers so that if the set of servers for your "
"realm changes, you need not reconfigure each machine in the realm. However, "
"in special situations, you can locally configure the set of servers for your "
"Kerberos realm."
msgstr ""
"Servidores para o seu realm foram encontrados no DNS. Para a maioria das "
"configurações, é melhor utilizar o DNS para encontrar esses servidores para "
"que, caso ocorram alterações, você não precise reconfigurar cada máquina do "
"seu realm. No entanto, em situações especiais, você pode configurar "
"localmente o conjunto de servidores para o seu realm Kerberos."

#. Type: string
#. Description
#: ../krb5-config.templates:8001
msgid "Kerberos servers for your realm:"
msgstr "Servidores Kerberos para seu realm:"

#. Type: string
#. Description
#: ../krb5-config.templates:8001
msgid ""
"Enter the hostnames of Kerberos servers in the ${realm} Kerberos realm "
"separated by spaces."
msgstr ""
"Informe os hostnames dos servidores Kerberos no realm Kerberos ${realm}, "
"separados por espaços."

#. Type: string
#. Description
#: ../krb5-config.templates:9001
msgid "Administrative server for your Kerberos realm:"
msgstr "Servidor administrativo para seu realm Kerberos:"

#. Type: string

Bug#835472: Gajim 0.16.5-2 crashed after update on startup

[Thilo Molitor]

Hi folks,

for the next gajim version using python3 and gtk3 (located at the default 
branch), we already disabled demandimport.

So this is definitely the way to go :)

Greetings,
Thilo Molitor (tmolitor)




On Thu, 1 Sep 2016 10:58:55 +0200 "W. Martin Borgert"  
wrote:
> On 2016-08-31 22:13, Antonio Ospite wrote:
> > That I don't know. If you are willing to ask gajim developers point them
> > to this report, and please let us know their reply.
> 
> I asked in xmpp:ga...@conference.gajim.org to possibly remove
> demandimport.py entirely and there was one developer, Linus
> Heckemann, who already did this in his branch. There were a
> number of older bugs in Gajim related to demandimport, so maybe
> upstream was not happy with it.
> 
> For Debian, we do not want to break existing plugins, however.
> Until the change is in an official Gajim release, I suggest to
> patch demandimport.py so that it is only a dummy.
> 
> Attached is a patch for this. Not yet checked with plugins.
> 
> > I still feel that the issue should be addressed in a more general way,
> > but I guess for now I'll suggest the gajim-omemo devs to just blacklist
> > _thread.
> 
> OK, whatever solves this bug :~)

Bug#836407: RFP: libjs-jquery-at.js -- Autocompletion library to autocomplete mentions, smileys, etc

[Andrew Shadura]

Hi,

On 2 September 2016 at 19:17, Sergio Durigan Junior
 wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Sergio Durigan Junior 
>
> * Package name: libjs-jquery-at.js
>   Version : 1.4.1
>   Upstream Author : Harold.Luo 
> * URL : https://github.com/ichord/At.js
> * License : Expat
>   Programming Lang: JavaScript
>   Description: Autocompletion library to autocomplete mentions, smileys, etc

It is actually in Debian already: ruby-jquery-atwho-rails, see
https://bugs.debian.org/832583

-- 
Cheers,
  Andrew

Bug#685439: I found what entries trigger the Use of uninitialized value in hash element

[積丹尼 Dan Jacobson]

severity 685439 normal
thanks

First,  should say what file.

Second, I found what entries trigger the
  Use of uninitialized value in hash element

# apt-show-versions -r -p '^linux-(doc|image)-[0-9]+\.'
Use of uninitialized value in hash element at /usr/bin/apt-show-versions line 
577,  line 3093.
# apt-show-versions -r -p '^linux-(doc|image)-[0-9]+\.'

# less -N +3093 /var/lib/dpkg/status
   3087 Package: modutils
   3088 Status: unknown ok not-installed
   3089 Priority: extra
   3090 Section: admin
   3091 Origin: debian
   3092 Bugs: debbugs://bugs.debian.org/
   3093

It's those super short entries.

$ grep -n 'Status: unknown ok not-installed' /var/lib/dpkg/status
3088:Status: unknown ok not-installed
4946:Status: unknown ok not-installed
23084:Status: unknown ok not-installed

and in fact the first one, on the first run of apt-show-versions in a
long time. As you see above the second run doesn't trigger the error.

Bug#828453: nginx: FTBFS with openssl 1.1.0

[Kurt Roeckx]

Hi,

It seems the version in experimental needs this patch to build
nginx itself:
http://hg.nginx.org/nginx/rev/1891b2892b68

You might also want this one:
http://hg.nginx.org/nginx/rev/3eb1a92a2f05

But then there some files in debian/modules that have minor
problems.

For nginx-lua see:
https://github.com/openresty/lua-nginx-module/pull/761

nginx-upstream-fair also has a problem with the reference
counters.


Kurt

Bug#834326: jessie-pu: package gnupg/1.4.18-7+deb8u2

[Salvatore Bonaccorso]

Hi Adam,

On Fri, Sep 02, 2016 at 09:10:48PM +0100, Adam D. Barratt wrote:
> Control: tags -1 - moreinfo
> 
> On Fri, 2016-09-02 at 20:58 +0200, Cyril Brulebois wrote:
> > Hi,
> > 
> > Adam D. Barratt  (2016-09-02):
> > > On Thu, 2016-08-18 at 07:25 +0200, Salvatore Bonaccorso wrote:
> > > > Control: retitle -1 jessie-pu: package gnupg/1.4.18-7+deb8u3
> > > > 
> > > > On Sun, Aug 14, 2016 at 03:58:28PM +0200, Salvatore Bonaccorso wrote:
> > > > > I would like to propose the following hardening to src:gnupg which was
> > > > > found during the analysis of a vulnerability report to the security 
> > > > > team
> > > > > and related to
> > > > > https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_razavi.pdf
> > > > > and developed by NIIBE Yutaka. The underlying problem in hardware 
> > > > > cannot
> > > > > be solved in software (and thus we don't want to issue a DSA for it, 
> > > > > and
> > > > > give possibly this false impression), and as pointed out by Florian
> > > > > there are some other open questions regarding the paper and the 
> > > > > attacks
> > > > > described there.
> > > [...]
> > > > This all stil holds, but I have rebased the patch on top of the update
> > > > via jessie-security.
> > > 
> > > Overall I think I'm happy to trust the maintainers on this, but would
> > > like a KiBi-ack due to d-i making use of at least gpgv.
> > 
> > Yeah, looks sane enough; I'd be slightly happier if it could reach p-u
> > sooner rather than later (ideally before the 8th), just to make sure
> > nothing explodes within d-i.
> 
> Thanks. Salvatore, please feel free to upload.

Thanks, uploaded!

Regards,
Salvatore


signature.asc
Description: PGP signature

Bug#834327: jessie-pu: package gnupg2/2.0.26-6+deb8u1

[Salvatore Bonaccorso]

Hi Adam,

On Fri, Sep 02, 2016 at 09:11:21PM +0100, Adam D. Barratt wrote:
> Control: tags -1 -moreinfo +confirmed
> 
> On Fri, 2016-09-02 at 18:57 +0100, Adam D. Barratt wrote:
> > Control: tags -1 + moreinfo
> > 
> > On Sun, 2016-08-14 at 16:00 +0200, Salvatore Bonaccorso wrote:
> > > I would like to propose the following hardening to src:gnupg2 which was
> > > found during the analysis of a vulnerability report to the security team
> > > and related to
> > > https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_razavi.pdf
> > > and developed by NIIBE Yutaka. The underlying problem in hardware cannot
> > > be solved in software (and thus we don't want to issue a DSA for it, and
> > > give possibly this false impression), and as pointed out by Florian
> > > there are some other open questions regarding the paper and the attacks
> > > described there.
> > 
> > I'd like to treat this and the corresponding gnupg update as a unit
> > (taking both or neither) so holding for now.
> 
> As that was confirmed, please go ahead.

Thanks! Uploaded.

Regards,
Salvatore

Bug#836421: O: fofix-dfsg -- rhythm game in the style of Rock Band(tm) and Guitar Hero(tm)

[Christian Brunotte]

Package: wnpp
Severity: normal

I'd like to orphan the fofix-dfsg package.

The package description is:
  FoFiX (Frets on Fire X) is a fork of Frets on Fire with many added
  features. The object of the game is to accurately play guitar, bass,
  or drums using the keyboard (or guitar and drum controllers from
  Guitar Hero(tm) and Rock Band(tm)) and to sing lyrics as accurately as
  possible. Many different single-player and multi-player game modes
  are available.
 
There was no new upstream release since 2009 and the
git repository is not very active neither so this project seems quite
dead to me and should eventually be removed before the next release
if no one objects.
 
Best Regards

-christian-



pgpes5KPUdMSI.pgp
Description: Digitale Signatur von OpenPGP

Bug#836420: python-getfem++: please depend on python-scipy for autopkgtests

[Graham Inggs]

Package: python-getfem++
Version: 5.0+dfsg1-1
Severity: wishlist


Hi Anton

Please add a dependency to python-getfem++ on python-scipy.
It is required by the autopkgtests and probably for proper operation
of python-getfem++ as well.

--- a/debian/control
+++ b/debian/control
@@ -77,6 +78,7 @@
  python (<< 2.8),
  python,
  python-numpy,
+ python-scipy,
  ${misc:Depends},
  ${python:Depends},
  ${shlibs:Depends}

Regards
Graham

Bug#832336: jessie-pu: package systemd/215-17+deb8u5

[Adam D. Barratt]

# see note at end
Control: tags -1 + confirmed

On Wed, 2016-08-31 at 01:43 +0200, Michael Biebl wrote:
> Am 18.08.2016 um 23:41 schrieb Michael Biebl:
> > Am 04.08.2016 um 22:13 schrieb Michael Biebl:
> >> Am 03.08.2016 um 22:41 schrieb Julien Cristau:
> >>> On Wed, Aug  3, 2016 at 22:32:16 +0200, Michael Biebl wrote:
> >>>
>  Am 29.07.2016 um 23:00 schrieb Michael Biebl:
> > Am 29.07.2016 um 14:00 schrieb Julien Cristau:
> >> This looks fine in general, I'm just wondering if the effect of bumping
> >> the util-linux dependency on upgrades from wheezy was 
> >> considered/tested?
> >
> > It was not specifically tested since I didn't expect any breakage
> > because of it. But I did it now for a basic wheezy system the upgrade to
> > jessie (with the updated systemd packages) worked fine. The tightened
> > dep on u-l seems to not cause any issues.
> >
> > I've attached the typescript from the wheezy → jessie dist-upgrade.
> 
>  Is that sufficient or do you still have concerns?
> 
> >>> I'm definitely concerned about changing dependencies in the base system
> >>> in stable, yes.  Is the parallel fsck bug that bad?
> >>
> >> I would really like to include that fsck fix. Parallel fsck on rotating
> >> disks is bad. It degrades the performance and we had reports from
> >> concerned users, that their disks made very strange noises when the
> >> heads where constantly repositioned.
> >> This doesn't affect SSDs, but I guess HDD are still very common on a
> >> typical server.
> > 
> > With the 8.6 release being close and no further response, I assume you
> > still object to this change. I would still like to see the other fixes
> > land in 8.6, so if you are ok with the other changes, can I proceed with
> > the upload if I exclude the 'fsck -l' fix?
> 
> 
> Hi, would be great to have a final decisions on this issue so I can
> proceed with the upload. I'd hate to see the accumulated fixes for
> systemd not to land in 8.6.

Sorry for the delays. I've been arguing with myself about the fsck fix
as well, but I'd be happy for the remainder to be uploaded.

Regards,

Adam

Bug#834327: jessie-pu: package gnupg2/2.0.26-6+deb8u1

[Adam D. Barratt]

Control: tags -1 -moreinfo +confirmed

On Fri, 2016-09-02 at 18:57 +0100, Adam D. Barratt wrote:
> Control: tags -1 + moreinfo
> 
> On Sun, 2016-08-14 at 16:00 +0200, Salvatore Bonaccorso wrote:
> > I would like to propose the following hardening to src:gnupg2 which was
> > found during the analysis of a vulnerability report to the security team
> > and related to
> > https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_razavi.pdf
> > and developed by NIIBE Yutaka. The underlying problem in hardware cannot
> > be solved in software (and thus we don't want to issue a DSA for it, and
> > give possibly this false impression), and as pointed out by Florian
> > there are some other open questions regarding the paper and the attacks
> > described there.
> 
> I'd like to treat this and the corresponding gnupg update as a unit
> (taking both or neither) so holding for now.

As that was confirmed, please go ahead.

Regards,

Adam

Bug#834326: jessie-pu: package gnupg/1.4.18-7+deb8u2

[Adam D. Barratt]

Control: tags -1 - moreinfo

On Fri, 2016-09-02 at 20:58 +0200, Cyril Brulebois wrote:
> Hi,
> 
> Adam D. Barratt  (2016-09-02):
> > On Thu, 2016-08-18 at 07:25 +0200, Salvatore Bonaccorso wrote:
> > > Control: retitle -1 jessie-pu: package gnupg/1.4.18-7+deb8u3
> > > 
> > > On Sun, Aug 14, 2016 at 03:58:28PM +0200, Salvatore Bonaccorso wrote:
> > > > I would like to propose the following hardening to src:gnupg which was
> > > > found during the analysis of a vulnerability report to the security team
> > > > and related to
> > > > https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_razavi.pdf
> > > > and developed by NIIBE Yutaka. The underlying problem in hardware cannot
> > > > be solved in software (and thus we don't want to issue a DSA for it, and
> > > > give possibly this false impression), and as pointed out by Florian
> > > > there are some other open questions regarding the paper and the attacks
> > > > described there.
> > [...]
> > > This all stil holds, but I have rebased the patch on top of the update
> > > via jessie-security.
> > 
> > Overall I think I'm happy to trust the maintainers on this, but would
> > like a KiBi-ack due to d-i making use of at least gpgv.
> 
> Yeah, looks sane enough; I'd be slightly happier if it could reach p-u
> sooner rather than later (ideally before the 8th), just to make sure
> nothing explodes within d-i.

Thanks. Salvatore, please feel free to upload.

Regards,

Adam

Bug#836419: vde2: FTBFS with openssl 1.1.0

[Sebastian Andrzej Siewior]

Package: vde2
Version: 2.3.2+r586-2
Severity: important
Tags: patch
Control: block 827061 by -1

OpenSSL 1.1.0 is about to released.  During a rebuild of all packages using
OpenSSL this package fail to build.  A log of that build can be found at:
https://breakpoint.cc/openssl-1.1-rebuild-2016-08-26/failed/vde2_2.3.2%2Br586-2_amd64-2016-08-26T19%3A57%3A29Z

I made a patch to fix this problem. Your package seems also to fail to build in
parallel (-j2+). I didn't look into this.

On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the
reasons why it might fail.  There are also updated man pages at
https://www.openssl.org/docs/manmaster/ that should contain useful information.

There is a libssl-dev package available in experimental that contains a recent
snapshot, I suggest you try building against that to see if everything works.

If you have problems making things work, feel free to contact us.

Kurt
>From 5f2c4c7b67617991af65798a4d177ada90f7e463 Mon Sep 17 00:00:00 2001
From: Sebastian Andrzej Siewior 
Date: Fri, 2 Sep 2016 19:52:49 +
Subject: [PATCH] vde_cryptcab: compile against openssl 1.1.0

Signed-off-by: Sebastian Andrzej Siewior 
---
 src/vde_cryptcab/cryptcab.c | 30 +++---
 1 file changed, 19 insertions(+), 11 deletions(-)

diff --git a/src/vde_cryptcab/cryptcab.c b/src/vde_cryptcab/cryptcab.c
index c5b4474..a2780f1 100644
--- a/src/vde_cryptcab/cryptcab.c
+++ b/src/vde_cryptcab/cryptcab.c
@@ -22,7 +22,7 @@ static void Usage(char *programname)
 	exit(1);
 }
 	
-static EVP_CIPHER_CTX ctx;
+static EVP_CIPHER_CTX *ctx;
 static int ctx_initialized = 0;
 static int encryption_disabled = 0;
 static int nfd;
@@ -30,6 +30,10 @@ static unsigned long long mycounter=1;
 static struct vde_open_args open_args={.port=0,.group=NULL,.mode=0700};
 static int verbose = 0;
 
+#if OPENSSL_VERSION_NUMBER < 0x1010
+#define EVP_CIPHER_CTX_reset(x)	EVP_CIPHER_CTX_cleanup(x)
+#endif
+
 void vc_printlog(int priority, const char *format, ...)
 {
 	va_list arg;
@@ -105,19 +109,21 @@ int data_encrypt(unsigned char *src, unsigned char *dst, int len, struct peer *p
 	}
 
 	if (!ctx_initialized) {
-		EVP_CIPHER_CTX_init ();
+		ctx = EVP_CIPHER_CTX_new ();
+		if (!ctx)
+			return -1;
 		ctx_initialized = 1;
 	}
 	
-	EVP_EncryptInit (, EVP_bf_cbc (), p->key, p->iv);
-	if (EVP_EncryptUpdate (, dst, , src, len) != 1)
+	EVP_EncryptInit (ctx, EVP_bf_cbc (), p->key, p->iv);
+	if (EVP_EncryptUpdate (ctx, dst, , src, len) != 1)
 	{
 		fprintf (stderr,"error in encrypt update\n");
 		olen = -1;
 		goto cleanup;
 	}
 
-	if (EVP_EncryptFinal (, dst + ulen, ) != 1)
+	if (EVP_EncryptFinal (ctx, dst + ulen, ) != 1)
 	{
 		fprintf (stderr,"error in encrypt final\n");
 		olen = -1;
@@ -126,7 +132,7 @@ int data_encrypt(unsigned char *src, unsigned char *dst, int len, struct peer *p
 	olen += tlen;
 
 cleanup:
-	EVP_CIPHER_CTX_cleanup();	
+	EVP_CIPHER_CTX_reset(ctx);
 	return olen;
 }
 
@@ -142,19 +148,21 @@ int data_decrypt(unsigned char *src, unsigned char *dst, int len, struct peer *p
 	}
 	
 	if (!ctx_initialized) {
-		EVP_CIPHER_CTX_init ();
+		ctx = EVP_CIPHER_CTX_new ();
+		if (!ctx)
+			return -1;
 		ctx_initialized = 1;
 	}
 
-	EVP_DecryptInit (, EVP_bf_cbc (), p->key, p->iv);
-	if (EVP_DecryptUpdate (, dst, , src, ulen) != 1)
+	EVP_DecryptInit (ctx, EVP_bf_cbc (), p->key, p->iv);
+	if (EVP_DecryptUpdate (ctx, dst, , src, ulen) != 1)
 	{
 		fprintf (stderr,"error in decrypt update\n");
 		olen = -1;
 		goto cleanup;
 	}
 
-	if (EVP_DecryptFinal (, dst + ulen, ) != 1)
+	if (EVP_DecryptFinal (ctx, dst + ulen, ) != 1)
 	{
 		fprintf (stderr,"error in decrypt final, ulen = %d, tlen = %d\n", ulen, tlen);
 		olen = -1;
@@ -163,7 +171,7 @@ int data_decrypt(unsigned char *src, unsigned char *dst, int len, struct peer *p
 	olen += tlen;
 
 cleanup:
-	EVP_CIPHER_CTX_cleanup();	
+	EVP_CIPHER_CTX_reset (ctx);
 	return olen;
 }
 
-- 
2.9.3

Bug#836418: RFA: quagga

[Christian Brunotte]

Package: wnpp
Severity: normal

I'm looking for a new maintainer for this package.

Bug#836417: RFS: netsed/1.2-3 [RC] -- Resolve a FTBFS situation.

[Mats Erik Andersson]

Package: sponsorship-requests
Severity: important


Dear mentors,

in an attempt to resolve an FTBFS blocker I am looking for a sponsor
of a new package revision of "netsed":

 Package name: netsed
 Version : 1.2-3
 Upstream Author : Julien Viard de Galbert 
 URL : http://silicone.homelinux.org/projects/netsed/
 License : GPL-2+
 Section : net

It builds a single binary package:

  netsed - network packet-altering stream editor

Information about this package is available at

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

The package can be downloaded with dget in the usual manner:

  dget -x https://mentors.debian.net/debian/pool/main/n/netsed/netsed_1.2-3.dsc

Changes since last upload:

  * Address FTBFS due to test suite failure.
+ debian/patches/use_calloc.diff: New file.  (Closes: #818852, #831270)
+ debian/patches/ruby_issues.diff: New file.


Regards,
  Mats Erik Andersson, maintainer of said binary package.

Bug#836416: libreoffice: Depends on both fonts-sil-gentium-basic and fonts-dejavu

[Fabian Greffrath]

Package: libreoffice
Version: 1:5.2.0-1
Severity: minor

Hi there,

currently, the libreoffice meta-package pulls in both
fonts-sil-gentium-basic and fonts-dejavu packages by hard
dependencies. I mean, sure libreoffice needs some fonts to work
properly, but (1) why does it need two font families installed and (2)
why does it have to be these two?

I guess with just fonts-liberation or fonts-croscore of fonts-texgyre
installed it is possible to work just as productively?

Cheers,

Fabian

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

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

Versions of packages libreoffice depends on:
ii  dpkg   1.18.10
ii  fonts-dejavu   2.36-1
ii  fonts-sil-gentium-basic1.1-7
ii  libreoffice-avmedia-backend-gstreamer  1:5.2.0-1
ii  libreoffice-base   1:5.2.0-1
ii  libreoffice-calc   1:5.2.0-1
ii  libreoffice-core   1:5.2.0-1
ii  libreoffice-draw   1:5.2.0-1
ii  libreoffice-impress1:5.2.0-1
ii  libreoffice-java-common1:5.2.0-1
ii  libreoffice-math   1:5.2.0-1
ii  libreoffice-report-builder-bin 1:5.2.0-1
ii  libreoffice-writer 1:5.2.0-1
ii  python3-uno1:5.2.0-1

libreoffice recommends no packages.

Versions of packages libreoffice suggests:
ii  cups-bsd2.1.4-4
ii  default-jre [java5-runtime] 2:1.8-57
ii  firefox 49.0~b1-1
ii  gstreamer1.0-libav  1.8.2-1
ii  gstreamer1.0-plugins-bad1.8.2-1+b2
ii  gstreamer1.0-plugins-base   1.8.2-1
ii  gstreamer1.0-plugins-good   1.8.2-1
ii  gstreamer1.0-plugins-ugly   1.8.2-1
ii  hunspell-de-at [hunspell-dictionary]20160407-1
ii  hunspell-de-ch [hunspell-dictionary]20160407-1
ii  hunspell-de-de [hunspell-dictionary]20160407-1
ii  hunspell-en-us [hunspell-dictionary]20070829-6
ii  hyphen-de [hyphen-hyphenation-patterns] 1:5.1.3-2
ii  hyphen-en-us [hyphen-hyphenation-patterns]  2.8.8-3
ii  imagemagick 8:6.8.9.9-7.2
ii  libgl1-mesa-glx [libgl1]11.2.2-1
ii  libreoffice-gnome   1:5.2.0-1
pn  libreoffice-grammarcheck
ii  libreoffice-help-de [libreoffice-help-5.2]  1:5.2.0-1
ii  libreoffice-help-en-us [libreoffice-help-5.2]   1:5.2.0-1
ii  libreoffice-l10n-de [libreoffice-l10n-5.2]  1:5.2.0-1
pn  libreoffice-officebean  
ii  libsane 1.0.25-2+b1
ii  libxrender1 1:0.9.9-2
pn  myspell-dictionary  
ii  mythes-de [mythes-thesaurus]20160424-3
ii  mythes-de-ch [mythes-thesaurus] 20160424-3
ii  mythes-en-us [mythes-thesaurus] 1:5.1.3-2
pn  openclipart2-libreoffice | openclipart-libreoffice  
ii  openjdk-7-jre [java5-runtime]   7u111-2.6.7-1
ii  openjdk-8-jre [java5-runtime]   8u102-b14.1-2
pn  pstoedit
pn  unixodbc

Versions of packages libreoffice-core depends on:
ii  fontconfig2.11.0-6.5
ii  fonts-opensymbol  2:102.7+LibO5.2.0-1
ii  libboost-date-time1.61.0  1.61.0+dfsg-2.1
ii  libc6 2.23-4
ii  libcairo2 1.14.6-1+b1
ii  libclucene-contribs1v52.3.3.4-4.2
ii  libclucene-core1v52.3.3.4-4.2
ii  libcmis-0.5-5v5   0.5.1+git20160603-1
ii  libcups2  2.1.4-4
ii  libcurl3-gnutls   7.50.1-1
ii  libdbus-1-3   1.10.8-1
ii  libdbus-glib-1-2  0.106-1
ii  libdconf1 0.26.0-1
ii  libeot0   0.01-3
ii  libexpat1 2.2.0-1
ii  libexttextcat-2.0-0   3.4.4-1
ii  libfontconfig12.11.0-6.5
ii  libfreetype6  2.6.3-3+b1
ii  libgcc1   1:6.1.1-11
ii  libgl1-mesa-glx [libgl1]  11.2.2-1
ii  libglew1.13   1.13.0-2
ii  libglib2.0-0  2.48.1-2
ii  libgltf-0.0-0v5   0.0.2-4+b1
ii  libglu1-mesa [libglu1]9.0.0-2.1
ii  libgraphite2-31.3.8-1
ii  libharfbuzz-icu0  1.2.7-1+b1
ii  libharfbuzz0b 

Bug#836415: nodejs: SIGILL when running nodejs

[Sam Imberman]

Package: nodejs
Version: 6.0.0~dfsg-1
Severity: important

Dear Maintainer,

I am unable to run nodejs at all on a PowerBook G4 12", because of an illegal
instruction. This is true for both the version in "sid" (4.x?) and
"experimental" (6.0.0)

"cat /proc/cpuinfo | grep cpu" returns:
cpu : 7447A, altivec supported


Here is some debugger output that someone suggested I send with my bug report:

(gdb) run
Starting program: /usr/bin/nodejs
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/powerpc-linux-gnu/libthread_db.so.1".
[New Thread 0xb7fba450 (LWP 1712)]
[New Thread 0xb77ba450 (LWP 1713)]
[New Thread 0xb6fba450 (LWP 1714)]
[New Thread 0xb67ba450 (LWP 1715)]

Program received signal SIGILL, Illegal instruction.
0x6007e388 in ?? ()
(gdb) x/i $pc
=> 0x6007e388:  fcfid   f1,f1
(gdb) x/x $pc
0x6007e388: 0xfc200e9c
(gdb)

I am glad to supply more information if necessary - I am a competent Debian
user but I do not know very much about debugging this sort of thing.

Thanks,
Sam



-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: powerpc (ppc)

Kernel: Linux 4.5.0-2-powerpc
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages nodejs depends on:
ii  libc-ares2   1.11.0-1
ii  libc62.24-1
ii  libgcc1  1:6.2.0-2
ii  libicu55 55.1-7
ii  libssl1.0.2  1.0.2h-1
ii  libstdc++6   6.2.0-2
ii  libuv1   1.9.1-1
ii  zlib1g   1:1.2.8.dfsg-2+b1

nodejs recommends no packages.

nodejs suggests no packages.

-- no debconf information

Bug#825840: localechooser: image display inverts red and blue color

[Ben Hutchings]

Control: tag -1 moreinfo

On Fri, 2016-09-02 at 20:56 +0200, Mathieu Malaterre wrote:
> Control: reassign -1 localechooser 2.68
> Control: retitle -1 localechooser: image display inverts red and blue
> color

How could this possibly be the fault of localechooser?

Ben.

-- 
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.


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

Bug#833777: kicad: New upstream version 4.0.3

[Carsten Schoenert]

retitle 833777 kicad: New upstream version 4.0.4
thanks

On Mon, Aug 08, 2016 at 05:35:06PM +0200, Carsten Schönert wrote:
 
> the next Fixup release 4.0.3 of KiCad was released last weekend.
> 
> http://kicad-pcb.org/post/release-4.0.3/

There is one more fixup release happen, the KiCad project has released
a new version 4.0.4.

 http://kicad-pcb.org/post/release-4.0.4/

Regards
Carsten

Bug#836321: gscan2pdf: failure in Lineart mode following recent updates in other packages

[Rainer Dorsch]

Package: gscan2pdf
Version: 1.5.2-1
Followup-For: Bug #836321

Dear Maintainer,

I would like to confirm that this bug is also present when I install 1.5.2-1 
from sid in jessie. As the original reporter describes it shows only in
lineart (it displays the scan correctly on the screen, but the pdf has only a 
white page). In greyscale everything works fine.


-- System Information:
Debian Release: 8.5
  APT prefers stable
  APT policy: (500, 'stable'), (450, 'proposed-updates'), (400, 'testing'), 
(300, 'unstable'), (250, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gscan2pdf depends on:
ii  imagemagick8:6.8.9.9-5+deb8u4
ii  libconfig-general-perl 2.56-1
ii  libfilesys-df-perl 0.92-5+b1
ii  libgoo-canvas-perl 0.06-2+b1
ii  libgtk2-ex-simple-list-perl0.50-2
ii  libgtk2-imageview-perl 0.05-2+b1
ii  libhtml-parser-perl3.71-1+b3
ii  libimage-magick-perl   8:6.8.9.9-5+deb8u4
ii  liblist-moreutils-perl 0.33-2+b1
ii  liblocale-gettext-perl 1.05-8+b1
ii  liblog-log4perl-perl   1.44-1
ii  libossp-uuid-perl [libdata-uuid-perl]  1.6.2-1.5+b1
ii  libpdf-api2-perl   2.023-1
ii  libproc-processtable-perl  0.51-1
ii  libreadonly-perl   2.000-1
ii  librsvg2-common2.40.5-1+deb8u2
ii  libsane-perl   0.05-2+b2
ii  libset-intspan-perl1.19-1
ii  libtiff-tools  4.0.3-12.3+deb8u1
ii  libtry-tiny-perl   0.22-1
ii  sane-utils 1.0.24-8+deb8u1

Versions of packages gscan2pdf recommends:
ii  djvulibre-bin  3.5.25.4-4+b1
ii  gocr   0.49-2
ii  libgtk2-ex-podviewer-perl  0.18-1
ii  sane   1.0.14-9
ii  tesseract-ocr  3.03.03-1
ii  unpaper0.4.2-1
ii  xdg-utils  1.1.0~rc1+git20111210-7.4

gscan2pdf suggests no packages.

-- no debconf information

Bug#836392: Please package 1.4.0

[Sebastien Badia]

On Fri, Sep 02, 2016 at 04:43:58PM (+0200), Thomas Goirand wrote:
> Package: gertty
> Version: 1.3.1-1
> Severity: important
> 
> Hi,
> 
> Version 1.3.1 is *very* slow to subscribe to projects. Version correct this
> issue as well as many bug fixes. Please package 1.4.0 ASAP (version 1.3.1 is
> anyway quite old).
> 
> I've set this bug with Severity: important as the current version 1.3.1 is
> hardly useable for me considering how slow it is to subscribe to projects, and
> I need to subscribe to hundreds of them.
> 
> Cheers,
> 
> Thomas Goirand (zigo)

tags 836392 + pending
thanks

Hi Thomas,

Thanks for the ping!

In fact the 1.4.0 is ready since July, I've sent two ping to Clint (who upload
in the archive previous version of this package), but no response. And indeed I
have not sent an RFS :-/ (my bad…)

Don't hesitate if you want to sponsor this package! Otherwise I'll sent a RFS.

  https://anonscm.debian.org/cgit/collab-maint/gertty.git
  https://mentors.debian.net/debian/pool/main/g/gertty/gertty_1.4.0-1.dsc

Cheers,

Seb


signature.asc
Description: PGP signature

Bug#829362: ruby-ronn: please make the output reproducible

[Chris Lamb]

Antonio Terceiro wrote:

> So do we want to replace the earlier patch with this one?

Hm, the patch to #829362 (which modifies the patch) is kinda ugly and
almost impossible to mentally parse. Sorry about that.

So, considering this cleaner patch:

 https://github.com/rtomayko/ronn/pull/98/files

… I believe we need all of these changes so, yes, we should replace
it. The following hunk demonstrates that it absorbs the previous patch:

 
https://github.com/rtomayko/ronn/pull/98/files#diff-a87e9e80c3a7693175aa8c08bdb48452L70

Thanks!


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#836414: freehdl: gvhdl requires libtool binary, which is in libtool-bin

[Sebastian]

Source: freehdl
Severity: normal

Hi,

the gvhdl script calls libtool when compiling VHDL code. If this
binary is missing, the linking step fails without any error message.

The libtool binary is not part of Debian's 'libtool' package, but is
instead in 'libtool-bin'. Therefore, the freehdl package should depend
on libtool-bin instead of libtool.

Best Regards.

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Bug#835992: [Pkg-zfsonlinux-devel] Bug#835992: 835992

[Carlos Alberto Lopez Perez]

And it seems that for kernel 4.8 another patch is needed:

https://github.com/zfsonlinux/spl/commit/b7c7008ba28ca926fbda929aec52f3761d72cffe



signature.asc
Description: OpenPGP digital signature

Bug#834326: jessie-pu: package gnupg/1.4.18-7+deb8u2

[Cyril Brulebois]

Hi,

Adam D. Barratt  (2016-09-02):
> On Thu, 2016-08-18 at 07:25 +0200, Salvatore Bonaccorso wrote:
> > Control: retitle -1 jessie-pu: package gnupg/1.4.18-7+deb8u3
> > 
> > On Sun, Aug 14, 2016 at 03:58:28PM +0200, Salvatore Bonaccorso wrote:
> > > I would like to propose the following hardening to src:gnupg which was
> > > found during the analysis of a vulnerability report to the security team
> > > and related to
> > > https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_razavi.pdf
> > > and developed by NIIBE Yutaka. The underlying problem in hardware cannot
> > > be solved in software (and thus we don't want to issue a DSA for it, and
> > > give possibly this false impression), and as pointed out by Florian
> > > there are some other open questions regarding the paper and the attacks
> > > described there.
> [...]
> > This all stil holds, but I have rebased the patch on top of the update
> > via jessie-security.
> 
> Overall I think I'm happy to trust the maintainers on this, but would
> like a KiBi-ack due to d-i making use of at least gpgv.

Yeah, looks sane enough; I'd be slightly happier if it could reach p-u
sooner rather than later (ideally before the 8th), just to make sure
nothing explodes within d-i.


KiBi.


signature.asc
Description: Digital signature

Bug#825840: localechooser: image display inverts red and blue color

[Mathieu Malaterre]

Control: reassign -1 localechooser 2.68
Control: retitle -1 localechooser: image display inverts red and blue color

Ok, so here is my latest experiment.

1. Get the latest Debian Installer Stretch Alpha 7 release
wget 
http://cdimage.debian.org/cdimage/stretch_di_alpha7/powerpc/iso-cd/debian-stretch-DI-alpha7-powerpc-netinst.iso
2. Burn to USB key:
dd if=debian-stretch-DI-alpha7-powerpc-netinst.iso of=/dev/sdb bs=4M && sync
3. Plug/Unplug to Mac Minig G4
4. Reboot Mac Mini G4
5. Press Cmd+Opt+o+f to get to Open Firmware
6. Boot USB key:
> boot usb0/disk@1:2,\\yaboot
7. Type:
install32

At this point you should see the localechooser screen with a nicely
inverted color (red background instead of blue background).

Now simply go to alternate screen (eg. Alt+F2), and then type:

# localechooser

And be amazed that now the background is a nice blue background !

Looking at the source of localechooser I could not figure out what
code path was used during debian-installer that gave it some sort of
byte-swapped idea.

Anyway please revert that change and leave the default `localechooser`
background to make big endian (powerpc?) behave the same way as little
endian.

Bug#829362: ruby-ronn: please make the output reproducible

[Antonio Terceiro]

Hi,

On Fri, Sep 02, 2016 at 11:04:07AM +0100, Chris Lamb wrote:
> Dear Maintainer,
> 
> > Source: ruby-ronn
> > Version: 0.7.3-4
> > Tags: patch
> 
> There hasn't seem to be any update here in a while and this package
> is affecting the reproducibility status of many packages.
> 
> Would you consider applying this patch and uploading? :)

Another reproducibility patch has been applied to close #807201, and
this one does not apply on top of 0.7.3-4; in fact it looks like a
modified version of that one.

So do we want to replace the earlier patch with this one?


signature.asc
Description: PGP signature

Bug#769172: Updated patches

[Linn Crosetto]

Attaching updated patches (also included in #836140).

From f270003bb7a4fab42884b4f373644cebdb51769e Mon Sep 17 00:00:00 2001
From: Linn Crosetto 
Date: Mon, 17 Nov 2014 11:55:40 -0700
Subject: [PATCH 1/2] Build UEFI images using prefix from lsb_release

Change prefix in build-efi-images from hardcoded path to use lsb_release.

Signed-off-by: Linn Crosetto 
---
 debian/build-efi-images | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/debian/build-efi-images b/debian/build-efi-images
index 68802f0..2b417cb 100755
--- a/debian/build-efi-images
+++ b/debian/build-efi-images
@@ -147,13 +147,15 @@ NET_MODULES="$CD_MODULES
 	tftp
 	"
 
+GRUB_IMAGE_PREFIX="/EFI/`(lsb_release -i -s 2> /dev/null || echo Debian) | tr A-Z a-z`"
+
 "$grub_mkimage" -O "$platform" -o "$outdir/gcd$efi_name.efi" \
 	-d "$grub_core" \
 	-c "$workdir/grub-bootstrap.cfg" -m "$workdir/memdisk.fat" \
 	-p /boot/grub \
 	$CD_MODULES
 "$grub_mkimage" -O "$platform" -o "$outdir/grub$efi_name.efi" \
-	-d "$grub_core" -p /EFI/ubuntu $GRUB_MODULES
+	-d "$grub_core" -p $GRUB_IMAGE_PREFIX $GRUB_MODULES
 "$grub_mkimage" -O "$platform" -o "$outdir/grubnet$efi_name.efi" \
 	-d "$grub_core" -c "$workdir/grub-bootstrap.cfg" \
 	-m "$workdir/memdisk-netboot.fat" -p /grub $NET_MODULES
-- 
2.6.4

From b6845d9d55777a3221ee63ddb29f64dab3088998 Mon Sep 17 00:00:00 2001
From: Linn Crosetto 
Date: Wed, 10 Aug 2016 14:31:56 -0600
Subject: [PATCH 2/2] Enable UEFI image builds for Secure Boot

Signed-off-by: Linn Crosetto 
---
 debian/rules | 2 --
 1 file changed, 2 deletions(-)

diff --git a/debian/rules b/debian/rules
index dea75ee..5863fb2 100755
--- a/debian/rules
+++ b/debian/rules
@@ -100,7 +100,6 @@ DEFAULT_HIDDEN_TIMEOUT_BOOL := false
 endif
 
 SB_PACKAGE :=
-ifeq (yes,$(shell dpkg-vendor --derives-from Ubuntu && echo yes))
 ifeq ($(DEB_HOST_ARCH),amd64)
 SB_PACKAGE := grub-efi-amd64
 SB_PLATFORM := x86_64-efi
@@ -111,7 +110,6 @@ SB_PACKAGE := grub-efi-arm64
 SB_PLATFORM := arm64-efi
 SB_EFI_NAME := aa64
 endif
-endif
 
 %:
 	dh $@ --parallel
-- 
2.6.4



signature.asc
Description: Digital signature

Bug#834797: lintian: depends on libdata-alias-perl, broken with Perl 5.24

[Niko Tyni]

On Sun, Aug 21, 2016 at 10:56:20PM +0300, Niko Tyni wrote:
> On Fri, Aug 19, 2016 at 01:37:36PM +0200, Jakub Wilk wrote:
> > 
> > * Niko Tyni , 2016-08-19, 09:42:
> > > This package depends and/or build-depends on libdata-alias-perl, which
> > > breaks with Perl 5.24 (currently in experimental.)
> > 
> > This dependency was added in 516add8dc237 "to avoid copying large texts in
> > memory". But my understanding is that Perl >= 5.20 has copy-on-write
> > strings[0], so this optimization is no longer necessary. Jessie has a
> > sufficiently new version, so the use of Data::Alias can be safely dropped.
> > 
> > [0] http://perldoc.perl.org/perl5200delta.html#Performance-Enhancements
> 
> Thanks for looking at this! That makes sense to me fwiw, but I see in
> #795641 that the patch author was using 5.20 at least when sending the
> patch. So presumably there was a reason for this? 

FWIW, I tested lintian 2.5.46 / Perl 5.22 execution speed a bit with
this (simulating the 'copyright-file-lacks-pointer-to-perl-license' check):

  % perl -MBenchmark -MFile::Slurp -e 'require q(./checks/copyright-file.pm); 
$cr=read_file(shift()); timethis(1000, sub { $_=$cr; 
Lintian::copyright_file::check_names_texts(qr/\b(?:perl|artistic)\b/, sub { 
/(?:under )?(?:the )?(?:same )?(?:terms )?as Perl itself\b/i && 
!m,usr/share/common-licenses/,; })})'  ~/tmp/perl/debian/copyright

With an unmodified check_names_texts():
  timethis 1000: 12 wallclock secs (12.19 usr +  0.03 sys = 12.22 CPU) @ 
81.83/s (n=1000)

With 'alias' removed:
 timethis 1000: 12 wallclock secs (12.36 usr +  0.02 sys = 12.38 CPU) @ 80.78/s 
(n=1000)

With '\$_ = $_[0];'  instead (and enabling the 'refaliasing' feature):
 timethis 1000: 12 wallclock secs (12.05 usr +  0.01 sys = 12.06 CPU) @ 82.92/s 
(n=1000)

The file tested (src:perl copyright file) is ~100Kbytes, which I expect
to be larger than average (though I'm sure there are larger ones in
the archive.)

Obviously this doesn't test memory usage, but at least these differences
don't seem worth optimizing for (unless I goofed up somehow.)
-- 
Niko Tyni   nt...@debian.org

Bug#531722: dbconfig-common: allow to generate multiple files via dbc_generate_include

[Paul Gevers]

Control: tags -1 moreinfo

Sorry it took so long to get to this bug. I took over ownership of
dbconfig-common last year and only now reached this bug.

On Wed, 03 Jun 2009 16:08:06 +0200 Thomas Koch  wrote:
> I need the database connection in PHP as well as in a shell script.
> Currently I can only specify one format in dbc_generate_include.

I assume you are aware that you can call dbc_generate_include yourself
after you called db_go, right? So you could easily generate the second
file you need (I mean, just a oneliner). Does this work for you?

To be honest, I don't think I will implement native support for this
request any time soon, if at all, as I believe it is trivial to do
yourself. One thing I could easily do though, is make this more clear in
the documentation. Would you think that is appropriate to solve this bug?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#834968: apt-cacher: Fails to run due to curl errors

[Helge Kreutzmann]

Hello Mark,
On Sun, Aug 28, 2016 at 10:58:48PM +0100, Mark Hindley wrote:
> On Sun, Aug 28, 2016 at 06:06:34PM +0200, Helge Kreutzmann wrote:
> > I attached it to this email.
> 
> Thanks, helpful.
> 
> > Sun Aug 28 16:34:53 2016|debug [6473]: Init new libcurl object
> > Sun Aug 28 16:34:53 2016|debug [6473]: Setting bandwidth limit to 30 bytes
> 
> This is the cause!
> 
> Have you got a limit configuration option set in 
> /etc/apt-cacher/apt-cacher.conf conf.d or on the command line in 
> /etc/default/apt-cacher?

Indeed, I just wonder how it got there:
root@samd:~# grep limit /etc/default/apt-cacher
EXTRAOPT=" daemon_port= limit=30 "

Thanks, now apt-cacher appears to work. 

I guess, best to close this bug.

Thanks again for your help.

Greetings

 Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: Digital signature

Bug#817319: NMU for crack

[Eriberto Mota]

Control: tags 817319 patch
Control: tags 817319 pending
Control: tags 817411 patch
Control: tags 817411 pending
Control: tags 821976 patch
Control: tags 821976 pending

Hi,

I uploaded a NMU to 10-day/delay queue. Feel free to cancel this
upload if needed.

The debian/changelog is:

 crack (5.0a-9.4) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * debian/compat: created. (Closes: #817319)
   * debian/control:
   - Added the ${misc:Depends} variable to all Depends field.
   - Bumped Standards-Version to 3.9.8.
   - Updated DH level to 9. (Closes: #817411)
   * debian/rules:
   - Disabled the DH_COMPAT variable.
   - Fixed the build system. Thanks to Santiago Vila .
 (Closes: #821976)

I attached a debdiff.

Regards,

Eriberto


crack.debdiff
Description: Binary data

Bug#834266: dbconfig-pgsql: support specifying the socket dir and socket "port"

[Paul Gevers]

On 14-08-16 11:39, Paul Gevers wrote:
> On 13-08-16 23:36, Christoph Anton Mitterer wrote:
>> As of now it seems, on cannot configure the socket dir and "port" that is
>> used by dbconfig, when UNIX sockets are used with postgresql.
> 
> Correct.

I am not sure anymore. I haven't tested it, but with PostgreSQL one can
just fill in the socket file name instead of the hostname, so I assume
that works with dbconfig-common as well. However, automatic detection of
the db administrator postgres will fail for now.

Paul



signature.asc
Description: OpenPGP digital signature

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

[Breno Leitao]

Hello,

I just created a debdiff that should solve this issue.

Please let me know how does it sound.

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

Bug#836413: opengm: FTBFS on powerpc: test-io-hdf5 data types not equal

[Aaron M. Ucko]

Source: opengm
Version: 2.3.6+20160901-1
Severity: important
Justification: fails to build from source

opengm now compiles on powerpc (thanks!), but hits a test suite error:

  23/49 Test #24: test-io-hdf5 .***Exception: Other  0.11 
sec
  terminate called after throwing an instance of 'std::runtime_error'
what():  Data types not equal error.

FWIW, sparc64 hit the same error in 2.3.6+20160814-1.  (As of this
report, builds of 2.3.6+20160901-1 for sparc64 and most other
architectures are still in progress.)

Could you please take a look?

Thanks!

Bug#833345: jessie-pu: package piuparts/0.62+deb8u1

[Holger Levsen]

On Fri, Sep 02, 2016 at 06:58:19PM +0100, Adam D. Barratt wrote:
> Please go ahead.

thanks, uploaded.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#803987: firmware-realtek: Very weak signal on RTL8723BE adaptor

[Sven Joachim]

On 2015-11-03 21:48 +0100, Antonio Peiro Saez wrote:

> Package: firmware-realtek
> Version: 20151018-2
> Severity: important
>
> After a clean installation of Debian 8.2 in a disk partition of my
> laptop the Realtek wireless network adapter, and the Realtek ethernet
> controller needed the installation of the nonfree firmware.
>
>antonio@BB-8:~$ uname -a
>Linux BB-8 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u4 (2015-09-19) 
> x86_64 GNU/Linux
>antonio@BB-8:~$ lspci | grep Realtek
>02:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8723BE PCIe 
> Wireless Network Adapter
>03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
> RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 07)
>
> The installation of the firmware-realtek 0.43 package included with
> the Debian distribution wasn't a problem.
>
> The ethernet controller works fine but the Wifi adapter not. It is a
> very strange situation because de wireless network adapter only catch
> the router signal if the laptop is situated at less than 1 meter from
> the router antenna.

This is not really a problem of the firmware, but rather of the
hardware.  Commit c18d8f5095715c56bb3cd9cba64242542632054b in the Linux
kernel tree gives an explanation:

,
| $ git show c18d8f5095715c56bb3cd9cba64242542632054b
| commit c18d8f5095715c56bb3cd9cba64242542632054b
| Author: Larry Finger 
| Date:   Wed Mar 16 13:33:34 2016 -0500
| 
| rtlwifi: rtl8723be: Add antenna select module parameter
| 
| A number of new laptops have been delivered with only a single antenna.
| In principle, this is OK; however, a problem arises when the on-board
| EEPROM is programmed to use the other antenna connection. The option
| of opening the computer and moving the connector is not always possible
| as it will void the warranty in some cases. In addition, this solution
| breaks the Windows driver when the box dual boots Linux and Windows.
| 
| A fix involving a new module parameter has been developed.  This commit
| adds the new parameter and implements the changes needed for the driver.
| 
| Signed-off-by: Larry Finger 
| Cc: Stable  [V4.0+]
| Signed-off-by: Kalle Valo 
`

With this commit (which went into Linux 4.7 and was subsequently
cherry-picked for the 4.x stable kernels), the rtl8723be module got a
new parameter ant_sel which you can set to 0 (the default), 1 or 2.

Recently I got myself a laptop with a RTL8723BE wireless adapter, and
with "modprobe rtl8723be ant_sel=1" the WiFi works perfectly, without
that parameter, "iwlist scan" would not report anything.

Cheers,
   Sven

Bug#828222: Pygoocanvas is deprecated & unmaintained

[Chris Lamb]

Hi Ross,

Thanks for getting back in touch.

> not had the time or inclination to look after pygoocanvas because it is
> deprecated and unmaintained upstream.

I totally understand.

> The best course of action is to remove pygoocanvas from the archive, but
> there are still 3 reverse dependencies that need to move away from it.

Can you ping those bugs? We might as well remove the package than bother with
an NMU…


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-