Bug#761941: xchat: Allow selection/removal of multiple networks at once from Network List dialog

[Jesse Taylor]

Package: xchat
Version: 2.8.8-7.1
Severity: normal
Tags: upstream

Dear Maintainer,

I only use xchat to connect to a few IRC networks (Freenode, Mozilla, OFTC).
However, the default install comes with dozens of networks that I never use
pre-loaded into the Network List (ChatJunkies, GalaxyNet, etc.).

I want to remove all of the networks, other than the three that I actually use.
However the only way to do this right now is to remove them one-by-one in the
following manner:

1) Select a network.
2) Click "Remove".
3) A dialog pops up asking 'Really remove network "FooBar" and all its
servers?'
4) Click "OK"

 Doing this for each of the dozens of networks is very tedious and time
consuming. It would be very helpful to be able to just select multiple networks
at once (either with Shift + Arrow Keys or CTRL + Click) and then click Remove
and have them all be deleted at once.

Thanks!



-- System Information:
Debian Release: 7.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages xchat depends on:
ii  libatk1.0-0 2.4.0-2
ii  libc6   2.13-38+deb7u4
ii  libcairo2   1.12.2-3
ii  libdbus-1-3 1.6.8-1+deb7u3
ii  libdbus-glib-1-20.100.2-1
ii  libfontconfig1  2.9.0-7.1
ii  libfreetype62.4.9-1.1
ii  libgdk-pixbuf2.0-0  2.26.1-1
ii  libglib2.0-02.33.12+really2.32.4-5
ii  libgtk2.0-0 2.24.10-2
ii  libpango1.0-0   1.30.0-1
ii  libperl5.14 5.14.2-21+deb7u1
ii  libsexy20.1.11-2+b1
ii  libssl1.0.0 1.0.1e-2+deb7u12
ii  libx11-62:1.5.0-1+deb7u1
ii  libxml2 2.8.0+dfsg1-7+wheezy1
ii  xchat-common2.8.8-7.1

Versions of packages xchat recommends:
ii  alsa-utils1.0.25-4
ii  libnotify40.7.5-1
ii  libpython2.7  2.7.3-6+deb7u2
pn  tcl8.5
ii  xdg-utils 1.1.0~rc1+git20111210-6

xchat suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#761687: RFS: abraca/0.8.0+dfsg-1 -- Simple and powerful graphical client for XMMS2

[Tobias Frost]

On 16. September 2014 21:24:13 MESZ, Daniel Lintott  
wrote:
>Hi Guys,
>
>On 16/09/14 07:23, Tobias Frost wrote:
>> 
>> There are no indications that the package has been orphaned, so it
>> likely hasn't.
>> 
>
>In case your not aware, it seems the package has now been orphaned[1]
>as
>of today (excellent work by Ricardo Mones).
>
>Regards,
>
>Daniel
>
>[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761830

Good :) So you can now adopt it officially...


-- 
Tobias Frost

13C9 04F0 CE08 5E7C 3630 7985 DECF 849A A635 7FB7

Bug#761881: flashplugin-nonfree: Timeout behind proxy

[Bart Martens]

Hi Cesare,

On Tue, Sep 16, 2014 at 03:43:35PM +0200, Cesare Leonardi wrote:
> Please, add some timeout to wget, both in update-flashplugin-nonfree and
> in get-upstream-version.pl.

I just added a timeout of 15 seconds in get-upstream-version.pl.  Maybe this is
already sufficient for you.  Can you try this please ? (First remove
/var/cache/flashplugin-nonfree/get-upstream-version.pl and then run
update-flashplugin-nonfree --status.)

Regards,

Bart Martens


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#743596: #743596: fix for gimp with lcms2

[Pino Toscano]

Hi,


I'm not sure there's much I can do at this point beyond patching
upstream.


Fixing debian/rules, for example:

| DEB_CONFIGURE_EXTRA_FLAGS := --disable-static \
| --enable-python \
| PYTHON=/usr/bin/`pyversions -d` \
| --enable-default-binary \
| --enable-gtk-doc
| --with-lcms=lcms2 \
| --without-webkit

The \ is missing at the end of the --enable-gtk-doc line, so the other
arguments, --with-lcms=lcms2 --without-webkit, are not part of
DEB_CONFIGURE_EXTRA_FLAGS and thus not passed to configure.

Thanks,
--
Pino Toscano


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#761801: /usr/share/vim/vim74/ftplugin/perl.vim: isfname erroneously set to include ":"

[Philipp Marek]

> > " The following line changes a global variable but is necessary to make
> > " gf and similar commands work.  The change to iskeyword was incorrect.
> > " Thanks to Andrew Pimlott for pointing out the problem. If this causes 
> > a
> > " problem for you, add an after/ftplugin/perl.vim file that contains
> > "   set isfname-=:
> > set isfname+=:
> > set iskeyword+=:
> > 
> > But that is incorrect - including ":" in "isfname" breaks "gF".
> 
> The reasoning behind this change is exactly to allow gf and friends to
> work on Perl package names, which are of the form Foo::Bar.
Oh, right. That's a good reason.

But how about setting that buffer-local, so that "gF" at least works in 
other, independently opened data files?

Most compiler error/warning outputs are of this format, for example...


And the "iskeyword" line can be removed, as per the comment above, right?


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#742409: [Sereal] 2.06 fails to build on some architectures: (#47)

[Niko Tyni]

On Tue, Sep 16, 2014 at 10:24:35PM +0200, demerphq wrote:

> Well I am wondering if you can look the patch I referenced above and see if
> you can work out what you need to do to get s390x to do the right thing? As
> you have identified yourself this is clearly a problem with the snappy
> support. But we pass test on other big-endian 64 bit platform as far as I
> understand (although I might be wrong).

64-bit big endian is pretty rare I think, and none of such Debian ports
(s390x, powerpc64, sparc64) show successful tests. I think the sparc64
port is pretty much dead though and we don't have test results for
3.002 on that.

Also, ppc64el (little-endian version of powerpc64), works fine. 

So I suspect it's a general 64-bit big-endian problem.

But sure, I'll see what I can do.
-- 
Niko Tyni   nt...@debian.org


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#761930: lintian: Please ship API documentation also as POD or as man page

[Niels Thykier]

On 2014-09-17 00:00, Axel Beckert wrote:
> Package: lintian
> Version: 2.5.27
> Severity: wishlist
> 
> Hi,
> 
> it took me a moment to recognize that the Lintian API documentation is
> indeed in package -- because I neither found them with man nor with
> perldoc.
> 
> I expect that I'm not the only one who'd prefer perldoc or man over a
> web browser for reading perl-related documentation.
> 
> So it would be nice if the POD sources would be shipped in perldoc's
> search path and/or man pages generated from POD.
> 
> [...]
> 

Hi Axel,

I presume you are talking about (e.g.) the Lintian::Tutorial POD and not
the actual POD for the modules.  At least the POD from our ".pm" seems
to be available (i.e. a call like perldoc Lintian::Path gives a Perldoc
page).

~Niels


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#736066: Allow encfs into jessie?

[Matthias Urlichs]

Hi,

Michael Halcrow:
> > Finally, encfs has an interesting reverse crypto mode where it
> > presents an encrypted FUSE view over a plaintext mountpoint.
> 
> With eCryptfs, you would accomplish this by unmounting and then
> reading the encrypted files directly from the lower file system.
> 
This is not a replacement for encfs' Reverse Mode. Rev mode means that
there _is_ no encrypted "lower file system".

Reverse Mode means that you translate an unencrypted directory tree to an
encrypted one, instead of vice versa.

This is very useful for creating backups of critical data (which I cannot
store on an encrypted FS, as that would be much too slow) to 'unsafe'
remote media.

> The incidentally lost or misplaced laptop is just about the only
> adversarial model that the currently available data-at-rest encryption
> options available for Linux can effectively address.
> 
… or USB stick.

> Do not expect any currently available encryption solutions to help you
> much if you are individually targeted.
> 
You need non-encrypted data to actually work with them.
Thus an encrypted file system cannot and will not help make anything
more secure if the FS in question is mounted anyway.

That's pretty much a truism.

In any case, yes encfs is not 100% safe, but frankly it's still much better
than not encrypting data at all (esp. if the data to be stored is not
controlled by an adversary) – and there currently is no better solution
for a couple of important use cases. Thus, please bring it back.

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#761940: nginx:CVE-2014-3616: possible to reuse cached SSL sessions in unrelated contexts

[Salvatore Bonaccorso]

Source: nginx
Version: 0.7.67-3
Severity: grave
Tags: security upstream patch fixed-upstream

Hi,

the following vulnerability was published for nginx.

CVE-2014-3616[0]:
reuse cached SSL sessions in unrelated contexts

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2014-3616
[1] http://mailman.nginx.org/pipermail/nginx-announce/2014/000147.html

Regards,
Salvatore


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#761939: solaar: [debconf_rewrite] Debconf templates and debian/control review proposal

[Christian Perrier]

Package: solaar
Version: N/A
Severity: normal

Dear Debian maintainer,

Hello,

I just noticed new or modified debconf templates appearing for this
package.

I would like to suggest you to consider calling for debconf templates
review AND translation updates when you introduce new debconf
templates or modify the existing templates in a package or, if you
prefer, to send a call for translations after uploading the first
version that introduces new templates or templates changes.

If you're interested in suggestions for doing this, you can find some
at the end of this bug report.

The debian-l10n-english team will now start a review, on our own
initiative. It will be conducted through this bug report.


Suggestions for future debconf templates review


1) Getting debconf templates reviewed
--

The Debian i18n contributors have developed a set of suggestions for
the writing style of debconf templates, to give them an overall
consistency all around Debian. These writing style suggestions are
explained in the Developers Reference. Lintian also warns about common
writing style concerns.

Maintainers are welcome when they ask for a review of debconf templates
and/or packages descriptions on debian-l10n-engl...@lists.debian.org.
It is of course not needed to wait for someone (such as me right me)
proposing you such a review.

In such situations (whether the review is requested by the maintainer
or proposed by someone else), someone from the debian-l10n-english
team will pick up the review to do, handle it, and finally send you a
bug report with the suggested templates. If you want, you can ask for
being CC'ed to the various discussions when the templates are
reviewed.


2) Call for new translations


As soon as the templates have been reviewed, you can ask Debian
translators for new translations:

Just go to your package's build tree and use:

$ podebconf-report-po --call

This will propose you a generic mail which is to be sent to
debian-i...@lists.debian.org and call for new translations.

This utility will mention existing translations to avoid duplicate
work. 

It will also attach the needed material to this mail.

Please also think about giving a deadline to translators. We like
deadlines..:-)

3) Always call for translation updates before uploading
---

(of course only when you change the debconf templates!)

If your package already includes debconf translations (ie *.po files
in debian/po), please consider calling for translation updates if you
happen to change something in the templates...or just in case when you
release a new version.

This is done with the following command:

$ podebconf-report-po

This will build private mails to translators (ie people listed in
"Last-Translator" in the PO files) for translations that are
incomplete. These mails will included the needed PO file for each
translator.


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

Kernel: Linux 3.16-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#758783: julia: does not start with -p option specified

[Viral Shah]

Do you still observe this behaviour with Julia 0.3?

-viral


On Thu, 21 Aug 2014 12:21:05 +0200 Frederik Beaujean  
wrote:
> Package: julia
> Version: 0.2.1+dfsg-3
> Severity: normal
> 
> Dear Maintainer,
> 
> I wanted to try the parallel capabilities of julia. Following the manual, I 
> tried to start it up as
> $ julia -p 2
> Master process (id 1) could not connect within 60.0 seconds.
> exiting.
> Master process (id 1) could not connect within 60.0 seconds.
> exiting.
> 
> Master process (id 1) could not connect within 60.0 seconds.
> exiting.
> Master process (id 1) could not connect within 60.0 seconds.
> exiting.
> ^C
> 
> The same happens even with one process
> $ julia -p 1
> Master process (id 1) could not connect within 60.0 seconds.
> exiting.
> Master process (id 1) could not connect within 60.0 seconds.
> exiting.
> Master process (id 1) could not connect within 60.0 seconds.
> exiting.
> ^C
> 
> and I never get to do anything.
> 
> To start julia at all, I had to use julia -f due to this outstanding bug 
> #755576
> 
> bye
> 
> Fred
> 
> -- System Information:
> Debian Release: jessie/sid
>   APT prefers testing-updates
>   APT policy: (500, 'testing-updates'), (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 3.13-1-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
> 
> Versions of packages julia depends on:
> ii  libamd2.3.11:4.2.1-3
> ii  libarpack2 3.1.5-3
> ii  libblas3 [libblas.so.3]1.2.20110419-7
> ii  libc6  2.19-7
> ii  libcamd2.3.1   1:4.2.1-3
> ii  libcholmod2.1.21:4.2.1-3
> ii  libcolamd2.8.0 1:4.2.1-3
> ii  libdouble-conversion1  2.0.1-1
> ii  libffi63.1-2
> ii  libfftw3-double3   3.3.4-1
> ii  libfftw3-single3   3.3.4-1


-viral


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#761937: nmu: slic3r_1.2.0+dfsg-1

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Wed, 2014-09-17 at 12:16 +0800, Chow Loong Jin wrote:
> nmu slic3r_1.2.0+dfsg-1 . ALL . -m "Rebuild for perlapi-5.20.0"

Those rebuilds already happened a few weeks ago; is there a problem?

Regards,

Adam


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#748573: Embedded code copy of libuv makes inconsistent use of _GNU_SOURCE

[Viral Shah]

With Julia 0.3 released, is this still an issue?

-viral

On Sun, 18 May 2014 16:28:24 +0100 Michael Tautschnig  wrote:
> Package: julia
> Version: 0.2.1+dfsg-3
> Usertags: goto-cc
> 
> During a rebuild of all Debian packages in a clean sid chroot (using 
> cowbuilder
> and pbuilder) the build failed with the following error. Please note that we
> use our research compiler tool-chain (using tools from the cbmc package), 
> which
> permits extended reporting on type inconsistencies at link time.
> 
> [...]
> libtool: link: gcc -shared  -fPIC -DPIC  src/.libs/libuv_la-fs-poll.o 
> src/.libs/libuv_la-inet.o src/.libs/libuv_la-uv-common.o 
> src/.libs/libuv_la-version.o src/unix/.libs/libuv_la-async.o 
> src/unix/.libs/libuv_la-core.o src/unix/.libs/libuv_la-dl.o 
> src/unix/.libs/libuv_la-fs.o src/unix/.libs/libuv_la-getaddrinfo.o 
> src/unix/.libs/libuv_la-loop-watcher.o src/unix/.libs/libuv_la-loop.o 
> src/unix/.libs/libuv_la-pipe.o src/unix/.libs/libuv_la-poll.o 
> src/unix/.libs/libuv_la-process.o src/unix/.libs/libuv_la-signal.o 
> src/unix/.libs/libuv_la-stream.o src/unix/.libs/libuv_la-tcp.o 
> src/unix/.libs/libuv_la-thread.o src/unix/.libs/libuv_la-threadpool.o 
> src/unix/.libs/libuv_la-timer.o src/unix/.libs/libuv_la-tty.o 
> src/unix/.libs/libuv_la-udp.o src/unix/.libs/libuv_la-linux-core.o 
> src/unix/.libs/libuv_la-linux-inotify.o 
> src/unix/.libs/libuv_la-linux-syscalls.o src/unix/.libs/libuv_la-proctitle.o  
>  -lrt -lpthread -lnsl -ldl  -O2 -O2 -Wl,-z -Wl,relro   -Wl,-soname 
> -Wl,libuv.so.11 -o .libs/libuv.so.11.0.0
> file /usr/include/x86_64-linux-gnu/bits/socket2.h line 64: 
> 
> error: conflicting function declarations "recvfrom"
> old definition in module fs-poll file 
> /usr/include/x86_64-linux-gnu/bits/socket2.h line 64
> signed long int (signed int __fd, void * restrict __buf, unsigned long int 
> __n, signed int __flags, struct sockaddr * restrict __addr, unsigned int * 
> restrict __addr_len)
> new definition in module linux-syscalls file 
> /usr/include/x86_64-linux-gnu/bits/socket2.h line 64
> signed long int (signed int __fd, void * restrict __buf, unsigned long int 
> __n, signed int __flags, union sockaddr __addr, unsigned int * restrict 
> __addr_len)
> Makefile:824: recipe for target 'libuv.la' failed
> make[6]: *** [libuv.la] Error 64
> make[6]: Leaving directory 
> '/srv/jenkins-slave/workspace/sid-goto-cc-julia/julia-0.2.1+dfsg/deps/libuv'
> Makefile:616: recipe for target 'all' failed
> 
> This type conflict on parameter __addr is caused by an inconsistent use of
> #define _GNU_SOURCE, which is present in deps/libuv/src/unix/linux-syscalls.c,
> but not in deps/libuv/src/fs-poll.c.
> 
> Obviously this is a problem of libuv rather than julia - hooray for embedded
> code copies. The packaged version in Debian does not suffer from the above
> problem.
> 
> Best,
> Michael
> 


-viral


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#760712: WEP vs WPA2

[Stefan Lippers-Hollmann]

On Monday 15 September 2014, Ben Hutchings wrote:
> On Mon, 2014-09-15 at 23:08 +0200, Stefan Lippers-Hollmann wrote:
> > On Monday 15 September 2014, Cyril Brulebois wrote:
> > > Stefan Lippers-Hollmann  (2014-09-15):
[...]
> > [...] but the udeb
> > should support:
> > 
> > - no encryption
> > - WEP64
> > - WEP128
> > - WPAPSK v1 TKIP/ CCMP
> > - WPAPSK2 TKIP/ CCMP
> > 
> > More advanced setups, like IEEE8021X (using certificates and per-user 
> > encryption, e.g. eduroam and other commercial setups), smartcards and
> > are not supported by the udeb (nor would netcfg know how to configure
> > these).
> 
> WPS would also be nice to have.

Actually plain WPS support[1] (not allowing for external registrar 
functionality or NFC config methods) should already be supported by
wheezy's wpasupplicant packages (1.0-3). However I have not tested WPS
support (it was only enabled due to dependency issues of the udeb build
config) and I'm pretty sure that netcfg doesn't know how to configure 
this. WPS using pin numbers or push-button (QSS) support is horribly
insecure and should be strongly discouraged, even though it is 
convenient for the user (unfortunately many commercial access point 
firmware don't allow to disable this option completely).
 
[...]
> The built-in world regulatory domain allows *passive* use of channels
> 12-13 and other channels that are not permitted in all countries.  That
> is, the kernel will allow passively scanning on those channels and
> connecting to an AP, on the assumption that the AP is following the
> local rules.
[...]

Of course you're right, passive scanning mitigates this problem to 
quite some extent. Active scanning (which is faster and would be 
required for connecting to hidden SSIDs (which are a bad idea, but 
still common; of course netcfg would have to learn to support this 
as well) and 802.11d aren't available this way.

Regards
Stefan Lippers-Hollmann

[1] This should cover most consumer routers/ access points


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

Bug#761938: please stop breaking my system with systemd

[Gianluigi Tiesi]

Package: systemd
Severity: important

I've updated to systemd/udev 215-4, my system starts with a read-only
root, it has something to do with udev, mounting rw via kernel commandline,
or when a disk check occurs, workarounds the problem,
looks like a timing problem, but wait...
I'm unable to read the error because systemd is
SO BLAZING FAST!

really people, systemd and init scripts of many packages aren't just
ready for production.

I've rebuilt policykit removing systemd deps and my system magically
starts without any problems

and also:
- smartd daemon silently exits instead of starting
- transmission-daemon crashes
- I spin down my sdb disk, why hell it starts again at shutdown now?

If you want to play with systemd, just do it, but leave us an alternative,
please tell policykit maintainer to stop nazi mind and keep a non systemd
infected policykit.

Please stop this crazyness of forcing a non production-ready init system
or we'll just sit with pop-corn on jessie release wathing bug report storm.

Regards


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#761937: nmu: slic3r_1.2.0+dfsg-1

[Chow Loong Jin]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu slic3r_1.2.0+dfsg-1 . ALL . -m "Rebuild for perlapi-5.20.0"

-- System Information:
Debian Release: jessie/sid
  APT prefers trusty-updates
  APT policy: (500, 'trusty-updates'), (500, 'trusty-security'), (500, 
'trusty'), (100, 'trusty-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.2-hyper1 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-- 
Kind regards,
Loong Jin


signature.asc
Description: Digital signature

Bug#750115: patch review

[Tz-Huan Huang]

On Mon, Sep 15, 2014 at 11:19 AM, Rolf Leggewie <
debian-b...@rolf.leggewie.biz> wrote:

> Alexander,
>
> thank you for your report and the patch.
>
> Tz-Huan, can you please have a look at
> https://bugs.debian.org/750115
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=scim.diff;att=1;bug=750115
> and apply the patch upstream if you feel it is appropriate?
>
>
Sure, I'll take it.

Thanks,
Tz-Huan

Bug#761936: [dolibarr] "third parties external modules" in extended description

[Filipus Klutiero]

Package: dolibarr
Version: 3.5.4+dfsg2-1
Severity: minor

The extended description ends with:
You can also add third parties external modules or develop yours. 


"third parties external modules" should either read something like "external modules from 
third parties" or "third-party external modules".


By the way, there is something inconsistent in the list. If the items are presented as examples, 
the last item shouldn't say "And a lot more modules". Either the presentation should just 
say "Dolibarr offers the following modules" or the last item should be removed.

--
Filipus Klutiero
http://www.philippecloutier.com


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#757966: RFS: lutris/0.3.4-1 [ITP]

[Andrey Rahmatullin]

On Tue, Sep 16, 2014 at 09:13:01PM +0200, Pierre Rudloff wrote:
>   - My work is now on GitHub: https://github.com/Rudloff/lutris-debian
> GitHub uses the same URL for browser and git clone, you should I still fill
> both fields?
Of course, see
http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-VCS-fields

> 4. For some reason, help2man adds this statement at the end of every man
> page it generates. I removed it. I have also documented the different ways
> to install a game.

   -N, --no-info
  suppress pointer to Texinfo manual

> 6. I have added a generic README.source about quilt. Is this OK?
README.source is not needed if you don't repack the upstream tarball and use
dpkg to apply patches. See
http://www.debian.org/doc/debian-policy/ch-source.html#s-readmesource


-- 
WBR, wRAR


signature.asc
Description: Digital signature

Bug#637142: GDM3 - very slow start up

[Geoff Mishash]

Package: gdm3
Version: 3.4.1-8
Followup-For: Bug #637142

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these lines ***

I restarted my computer after using it as usual. When it was loading GUI, it 
displayed "Could not update ICEauthority file /var/lib/gdm3/.ICEauthority" and 
there was only a button reading "Log Out." The same message would just appear 
again if I click the log out button. So I couldn't log into the GUI. I have 
tried to boot into Debian several times, but the problem was still there. I 
then booted into another OS (Windows 8) on the same machine in ordered to look 
for solutions online. After I found a solution, I restarted my computer again.

Things became different here. This time the GUI is successfully loaded. I 
didn't even do anything to .ICEauthority , .ICEauthority-c or .ICEauthority-l .

I went to check /var/lib/gdm3/ , and found that the 2 files .ICEauthority-c and 
.ICEauthority-l disappeared. (They were existent when I encountered the 
problem.)

Now the GUI can be successfully loaded except a bit slower than before.
So, this bug still exists in Debian 7.6 Wheezy.

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

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages gdm3 depends on:
ii  accountsservice   0.6.21-8
ii  adduser   3.113+nmu3
ii  dconf-gsettings-backend   0.12.1-3
ii  dconf-tools   0.12.1-3
ii  debconf [debconf-2.0] 1.5.49
ii  dpkg  1.16.15
ii  gir1.2-freedesktop1.32.1-1
ii  gir1.2-glib-2.0   1.32.1-1
ii  gnome-session [x-session-manager] 3.4.2.1-4
ii  gnome-session-bin 3.4.2.1-4
ii  gnome-session-fallback [x-session-manage  3.4.2.1-4
ii  gnome-settings-daemon 3.4.2+git20121218.7c1322-3+deb7u3
ii  gnome-terminal [x-terminal-emulator]  3.4.1.1-2
ii  gsettings-desktop-schemas 3.4.2-3
ii  libaccountsservice0   0.6.21-8
ii  libatk1.0-0   2.4.0-2
ii  libattr1  1:2.4.46-8
ii  libaudit0 1:1.7.18-1.1
ii  libc6 2.13-38+deb7u4
ii  libcairo-gobject2 1.12.2-3
ii  libcairo2 1.12.2-3
ii  libcanberra-gtk3-00.28-6
ii  libcanberra0  0.28-6
ii  libdbus-1-3   1.6.8-1+deb7u3
ii  libdbus-glib-1-2  0.100.2-1
ii  libfontconfig12.9.0-7.1
ii  libgdk-pixbuf2.0-02.26.1-1
ii  libglib2.0-0  2.33.12+really2.32.4-5
ii  libglib2.0-bin2.33.12+really2.32.4-5
ii  libgtk-3-03.4.2-7
ii  libpam-modules1.1.3-7.1
ii  libpam-runtime1.1.3-7.1
ii  libpam0g  1.1.3-7.1
ii  libpango1.0-0 1.30.0-1
ii  librsvg2-common   2.36.1-2
ii  libselinux1   2.1.9-5
ii  libupower-glib1   0.9.17-1
ii  libwrap0  7.6.q-24
ii  libx11-6  2:1.5.0-1+deb7u1
ii  libxau6   1:1.0.7-1
ii  libxdmcp6 1:1.1.1-1
ii  libxklavier16 5.2.1-1
ii  libxrandr22:1.3.2-2+deb7u1
ii  lsb-base  4.1+Debian8+deb7u1
ii  metacity [x-window-manager]   1:2.34.3-4
ii  policykit-1-gnome 0.105-2
ii  upower0.9.17-1
ii  x11-common1:7.7+3~deb7u1
ii  x11-xserver-utils 7.7~3
ii  xterm [x-terminal-emulator]   278-4

Versions of packages gdm3 recommends:
ii  at-spi2-core   2.5.3-2
ii  desktop-base   7.0.3
ii  gnome-icon-theme   3.4.0-2
ii  gnome-icon-theme-symbolic  3.4.0-2
ii  x11-xkb-utils  7.7~1
ii  xserver-xephyr 2:1.12.4-6+deb7u2
ii  xserver-xorg   1:7.7+3~deb7u1
ii  zenity 3.4.0-2

Versions of packages gdm3 suggests:
ii  gnome-orca  

Bug#761921: [3dprinter-general] Bug#761921: slic3r: Uninstallable, depends on unavailable perlapi-5.18.2

[Chow Loong Jin]

On Tue, Sep 16, 2014 at 10:40:10PM +0200, Andreas Wettergren wrote:
> Package: slic3r
> Version: 1.2.0+dfsg-1
> Severity: grave
> Justification: renders package unusable
> 
> Like the subject says, not installable in experimental at present.
> 1.1.7+dfsg-2+b1 already depends on perlapi-5.20.0 so this is probably just an 
> oversight?

An oversight probably. +b1 means that a binNMU was done, and 1.1.7 is in
unstable. I'll look into this.

> (BTW, running slic3r with perl => 5.16 causes numerical bugs on some locales. 
> Should really be fixed upstream IMHO. Workaround is to run with "export 
> LC_NUMERIC=C; slic3r".)

What sort of numerical bugs? I'm unaware of this. Could you file these bugs
upstream please?

-- 
Kind regards,
Loong Jin


signature.asc
Description: Digital signature

Bug#663436: modprobe: does not seem to set module options for snd_hda_intel

[Marco d'Itri]

On May 02, Martin Steigerwald  wrote:

> Sorry. Still happens:
Are you really sure that snd_hda_intel is loaded in the initramfs?
In a normal configuration it would not be available there.

I did some tests with a different module which is available in the 
initramfs and I am still unable to reproduce this:

#!/bin/bash
kver=3.16-1-amd64
opts+=(-m 256M)
opts+=(-curses)
opts+=(-kernel /boot/vmlinuz-$kver -initrd /boot/initrd.img-$kver \
   -append 'break=top')
kvm "${opts[@]}"

Then at the console:
/lib/systemd/systemd-udevd &
echo 'options e1000 copybreak=16' > /etc/modprobe.d/test.conf
echo add > /sys/devices/pci:00/:00:03.0/uevent
cat /sys/module/e1000/parameters/copybreak

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Bug#733032: modprobe -d does the wrong thing

[Marco d'Itri]

On Dec 24, Joerg Dorchain  wrote:

> For the modules.dep.bin and all modules required by the given
> modules, it *prepends* the -d path to the default paths,
> resulting e.g. in /out/of/tree/modules//lib/modules/`uname -r`/...
> I would rather expect it to *replace* the default path with it,
> e.g. when I give 
> # modprobe -d /out/of/tree/modules/ mymodule

The man page is clear in documenting that your expectation is wrong:

   -d, --dirname
   Root directory for modules, / by default.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Bug#761935: shine: ftbfs on mips64el

[YunQiang Su]

Package: shine
Version: 3.1.0-2


In debian/rules, there are lines:

ifneq (,$(findstrings mips,$(DEB_HOST_ARCH)))
CFLAGS+= -mips32r2
export CFLAGS
endif

It will make all mips* ports use mips32r2.

change it to

ifneq (,$(filter mips mipsel,$(DEB_HOST_ARCH)))

can fix this problem.

-- 
YunQiang Su


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#722870: xmlstarlet link with -L/usr/lib

[Noam Postavsky]

On Tue, Sep 16, 2014 at 9:38 AM, Mònica Ramírez  wrote:
>
> Noam: Pleae, could you review if I am breaking something?

This would break attempts to ./configure with libxml or libxslt in
non-standard location, i.e., --with-lib(xml|xslt)-prefix and
--with-lib(xml|xslt)-libs-prefix options would not change the lib
search path. I suppose Debian builds can assume libxml and libxslt
will always be in the standard search path?


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#758972: Mojarra update 2.2.8

[Miguel Landaeta]

I keep working on this.

So far, I was able to build 2.2.8 in Debian and this should fix all
the serious bugs with this packages. I did this simplifying the build
and replacing ant with javahelper. Another option is to keep using
ant since Markus did some work in a branch.

However, as I said previously 2.2.8 introduces a new dependency on
Java EE 6/7 APIs but I found out some issues with the APIs source
licensing.

According to 
http://central.maven.org/maven2/javax/javaee-api/7.0/javaee-api-7.0.pom
that code is dual licensed under GPLv2 and CDDL.

However there are some .java files in the source with confidential
clauses and some weird non-free disclaimers. Maybe those disclaimers
are outdated, I have to confirm this and if everything is OK, then get
that package in the archive.

Another option is to check if some mojarra features depending on those
APIs can be disabled.

I'll post again when I have more info.

-- 
Miguel Landaeta, nomadium at debian.org
secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key.
"Faith means not wanting to know what is true." -- Nietzsche


signature.asc
Description: Digital signature

Bug#758105: bug#18266: handling bytes not part of the charset, and other garbage

[Paul Eggert]

Paul Eggert wrote:

Attached are some proposed patches which should improve the performance
of grep -P when applied to binary files, among other things.  I have
some other ideas for boosting performance further but thought I'd
publish these first.


I pushed those patches, along with the attached further patches to fix 
up some porting glitches and bugs I encountered in subsequent testing. 
I plan to follow up soon on Bug#18454 with more performance-related 
patches in this area.
From 53c5d9fd50b6895b886c1d19d0851562fc03e00c Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Tue, 16 Sep 2014 17:29:40 -0700
Subject: [PATCH 07/10] grep: avoid false alarms for mb_clen and to_uchar

* cfg.mk (_gl_TS_unmarked_extern_functions): New var,
to bypass the tight_scope false alarms on mb_clen and to_uchar.
---
 cfg.mk | 4 
 1 file changed, 4 insertions(+)

diff --git a/cfg.mk b/cfg.mk
index 947d184..3316b5d 100644
--- a/cfg.mk
+++ b/cfg.mk
@@ -28,6 +28,10 @@ local-checks-to-skip =   \
 # Tools used to bootstrap this package, used for "announcement".
 bootstrap-tools = autoconf,automake,gnulib
 
+# The tight_scope test gets confused about inline functions.
+# like 'to_uchar'.
+_gl_TS_unmarked_extern_functions = main usage mb_clen to_uchar
+
 # Now that we have better tests, make this the default.
 export VERBOSE = yes
 
-- 
1.9.3

From 493ddec2e61d48953600575896a5d3ce1d1a582b Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Mon, 15 Sep 2014 22:25:21 -0700
Subject: [PATCH 08/10] grep: use mbclen cache in one more place

* src/grep.c (fgrep_to_grep_pattern): Use mb_clen here, too.
---
 src/grep.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/grep.c b/src/grep.c
index 72a811e..e4379bc 100644
--- a/src/grep.c
+++ b/src/grep.c
@@ -1912,8 +1912,7 @@ fgrep_to_grep_pattern (size_t len, char const *keys,
 
   for (; len; keys += n, len -= n)
 {
-  wchar_t wc;
-  n = mbrtowc (&wc, keys, len, &mb_state);
+  n = mb_clen (keys, len, &mb_state);
   switch (n)
 {
 case (size_t) -2:
-- 
1.9.3

From 219f10596c17e38b2716673a140c2b3827549862 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Mon, 15 Sep 2014 17:27:58 -0700
Subject: [PATCH 09/10] grep: port -P speedup to hosts lacking
 PCRE_STUDY_JIT_COMPILE

* src/pcresearch.c (Pcompile): Do not assume that
PCRE_STUDY_JIT_COMPILE is defined.
(empty_match): Define on all platforms.
---
 src/pcresearch.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/src/pcresearch.c b/src/pcresearch.c
index 95877e3..ce65758 100644
--- a/src/pcresearch.c
+++ b/src/pcresearch.c
@@ -33,10 +33,6 @@ static pcre *cre;
 /* Additional information about the pattern.  */
 static pcre_extra *extra;
 
-/* Table, indexed by ! (flag & PCRE_NOTBOL), of whether the empty
-   string matches when that flag is used.  */
-static int empty_match[2];
-
 # ifdef PCRE_STUDY_JIT_COMPILE
 static pcre_jit_stack *jit_stack;
 # else
@@ -44,6 +40,10 @@ static pcre_jit_stack *jit_stack;
 # endif
 #endif
 
+/* Table, indexed by ! (flag & PCRE_NOTBOL), of whether the empty
+   string matches when that flag is used.  */
+static int empty_match[2];
+
 void
 Pcompile (char const *pattern, size_t size)
 {
@@ -129,11 +129,11 @@ Pcompile (char const *pattern, size_t size)
   pcre_assign_jit_stack (extra, NULL, jit_stack);
 }
 
-  empty_match[false] = pcre_exec (cre, extra, "", 0, 0, PCRE_NOTBOL, NULL, 0);
-  empty_match[true] = pcre_exec (cre, extra, "", 0, 0, 0, NULL, 0);
-
 # endif
   free (re);
+
+  empty_match[false] = pcre_exec (cre, extra, "", 0, 0, PCRE_NOTBOL, NULL, 0);
+  empty_match[true] = pcre_exec (cre, extra, "", 0, 0, 0, NULL, 0);
 #endif /* HAVE_LIBPCRE */
 }
 
-- 
1.9.3

From 530fd765922b16643c78652ef036024fc4dd72eb Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Mon, 15 Sep 2014 18:33:19 -0700
Subject: [PATCH 10/10] grep: fix -P speedup bug with empty match

* src/pcresearch.c (NSUB): New top-level constant, replacing
'nsub' within Pexecute.
(Pcompile, Pexecute): Use it.
(Pexecute): Don't assume sub[1] is zero after a PCRE_ERROR_BADUTF8
match failure.
* tests/pcre-invalid-utf8-input: Test for this bug.
---
 src/pcresearch.c  | 32 +++-
 tests/pcre-invalid-utf8-input |  5 +
 2 files changed, 24 insertions(+), 13 deletions(-)

diff --git a/src/pcresearch.c b/src/pcresearch.c
index ce65758..c41f7ef 100644
--- a/src/pcresearch.c
+++ b/src/pcresearch.c
@@ -44,6 +44,10 @@ static pcre_jit_stack *jit_stack;
string matches when that flag is used.  */
 static int empty_match[2];
 
+/* This must be at least 2; everything after that is for performance
+   in pcre_exec.  */
+enum { NSUB = 300 };
+
 void
 Pcompile (char const *pattern, size_t size)
 {
@@ -132,8 +136,10 @@ Pcompile (char const *pattern, size_t size)
 # endif
   free (re);
 
-  empty_match[false] = pcre_exec (cre, extra, "", 0, 0, PCRE_NOTBOL, NULL, 0);
-  empty_match[true] = pcre_exec (cre, extra

Bug#725157: [mailer-dae...@a.painless.aa.net.uk: Mail delivery failed: returning message to sender]

[Colin Watson]

I didn't notice you'd changed your submitter address.  Sorry about that.

-- 
Colin Watson   [cjwat...@debian.org]
--- Begin Message ---
This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  use...@zip.com.au
SMTP error from remote mail server after RCPT TO::
host mailin1.pacific.net.au [125.255.92.144]:
550 5.1.1 : Recipient address rejected:
User unknown in virtual mailbox table

-- This is a copy of the message, including all the headers. --

Return-path: 
Received: from 
3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.4.1.b.e.2.f.f.b.0.b.8.0.1.0.0.2.ip6.arpa 
([2001:8b0:bff2:eb14::3] helo=riva.pelham.vpn.ucam.org)
by a.painless.aa.net.uk with esmtps (TLSv1:AES128-SHA:128)
(Exim 4.77)
(envelope-from )
id 1XU3xE-0003LR-80; Wed, 17 Sep 2014 02:22:54 +0100
Received: from ns1.pelham.vpn.ucam.org ([172.20.153.2] helo=riva.ucam.org)
by riva.pelham.vpn.ucam.org with esmtps 
(TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128)
(Exim 4.80)
(envelope-from )
id 1XU3xC-0006Gj-N8; Wed, 17 Sep 2014 02:22:42 +0100
Date: Wed, 17 Sep 2014 02:22:41 +0100
From: Colin Watson 
To: Kevin Ryde , 725...@bugs.debian.org
Subject: Re: Bug#725157: man-db: /etc/mailcap of man page
Message-ID: <20140917012241.gw5...@riva.ucam.org>
References: <8761tgurkq@blah.blah>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <8761tgurkq@blah.blah>
User-Agent: Mutt/1.5.21 (2010-09-15)

Control: tag -1 pending

On Wed, Oct 02, 2013 at 04:15:01PM +1000, Kevin Ryde wrote:
> This is an idea for /etc/mailcap entries to run "man" on man pages.
> It allows for example
> 
> see /usr/share/man/man1/man.1.gz
> 
> to display with man in either X or a tty, and also non-interactive like
> the following (though groff-base trumps this just yet ...)
> 
> run-mailcap --action=cat /usr/share/man/man1/man.1.gz
> 
> The debian/man-db.mime file below can be taken by dh_installmime to
> install as /usr/lib/mime/packages/man-db.

Thanks!  I've applied this more or less verbatim, although I added
text/troff lines to match each of the application/x-troff-man lines, as
that seems to be what's needed with current file(1).

  
http://anonscm.debian.org/cgit/pkg-man-db/man-db.git/commit/?id=af63b7267097fc2a56607a31f3da8b3d5384a276

> /usr/lib/mime/packages/groff-base has a "copiousoutput" entry at
> priority=5 which is above what I propose here for man non-interactive,
> which means for now the groff bit has precedence in the --action=cat
> above.
> 
> I think the groff should be lower, but that will be a matter of groff
> and man-db cooperating.  The priority levels apply before the output
> style is considered, so usually any copiousoutput should be below any
> interactive viewing.

Well, I maintain groff as well, so send me patches.  I don't really use
mime-support much myself, so I'm happy to take guidance from those who
do.

> # "man -X" is only priority=6 since the gxditview it runs is rather
> # basic and perhaps something more sophisticated could be higher.  The
> # X entry is before the tty so the X is preferred under X.  (The tty
> # one still works there, in its declared needsterminal.)
> #
> # "-X100" seems to make better output than the default -X 75 dpi.
> # Dunno if that's some font dodginess or matching the X server's
> # advertised screen size resolution or something.
> #
> # "test -e gxditview" because it's in the "groff" package which is
> # only a Suggests of man-db and so may not be available.

Did you consider something like -Tpdf, which generally looks much nicer?
Is it possible to chain MIME handlers, so that we can say "this command
converts text/troff into image/pdf, and then you should go and work out
how to display image/pdf"?

> # "-Tascii" gives backspace overstriking, so use "col -b" to undo
> # that.  Piping to col also means "man" has a non-tty output and so
> # does not run its usual "more" etc pager, ensuring this entry is
> # non-interactive.
> #
> application/x-troff-man; /usr/bin/man -Tascii -l '%s' | col -b; 
> copiousoutput; description=Man page; priority=2

Why not -Tutf8 here?

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]


--- End Message ---

Bug#725157: man-db: /etc/mailcap of man page

[Colin Watson]

Control: tag -1 pending

On Wed, Oct 02, 2013 at 04:15:01PM +1000, Kevin Ryde wrote:
> This is an idea for /etc/mailcap entries to run "man" on man pages.
> It allows for example
> 
> see /usr/share/man/man1/man.1.gz
> 
> to display with man in either X or a tty, and also non-interactive like
> the following (though groff-base trumps this just yet ...)
> 
> run-mailcap --action=cat /usr/share/man/man1/man.1.gz
> 
> The debian/man-db.mime file below can be taken by dh_installmime to
> install as /usr/lib/mime/packages/man-db.

Thanks!  I've applied this more or less verbatim, although I added
text/troff lines to match each of the application/x-troff-man lines, as
that seems to be what's needed with current file(1).

  
http://anonscm.debian.org/cgit/pkg-man-db/man-db.git/commit/?id=af63b7267097fc2a56607a31f3da8b3d5384a276

> /usr/lib/mime/packages/groff-base has a "copiousoutput" entry at
> priority=5 which is above what I propose here for man non-interactive,
> which means for now the groff bit has precedence in the --action=cat
> above.
> 
> I think the groff should be lower, but that will be a matter of groff
> and man-db cooperating.  The priority levels apply before the output
> style is considered, so usually any copiousoutput should be below any
> interactive viewing.

Well, I maintain groff as well, so send me patches.  I don't really use
mime-support much myself, so I'm happy to take guidance from those who
do.

> # "man -X" is only priority=6 since the gxditview it runs is rather
> # basic and perhaps something more sophisticated could be higher.  The
> # X entry is before the tty so the X is preferred under X.  (The tty
> # one still works there, in its declared needsterminal.)
> #
> # "-X100" seems to make better output than the default -X 75 dpi.
> # Dunno if that's some font dodginess or matching the X server's
> # advertised screen size resolution or something.
> #
> # "test -e gxditview" because it's in the "groff" package which is
> # only a Suggests of man-db and so may not be available.

Did you consider something like -Tpdf, which generally looks much nicer?
Is it possible to chain MIME handlers, so that we can say "this command
converts text/troff into image/pdf, and then you should go and work out
how to display image/pdf"?

> # "-Tascii" gives backspace overstriking, so use "col -b" to undo
> # that.  Piping to col also means "man" has a non-tty output and so
> # does not run its usual "more" etc pager, ensuring this entry is
> # non-interactive.
> #
> application/x-troff-man; /usr/bin/man -Tascii -l '%s' | col -b; 
> copiousoutput; description=Man page; priority=2

Why not -Tutf8 here?

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#750348: libturpial: FTBFS: Trying to write outside builddir

[Miguel Landaeta]

retitle 750348 libturpial: unit tests are trying to write outside builddir
severity 750348 important
thanks

On Thu, Jul 31, 2014 at 06:16:58PM -0300, Miguel Landaeta wrote:
> [...]
> 
> I'm looking for help to get a fix or workaround for this issue.
> 

I decided to disable the unit tests during build time and prepared a
new upload (1.7.0-3) with this change.

I'm downgrading the severity of this bug since libturpial is not going
to FTBFS but I keep the bug open because this is not a proper fix.
This is a workaround, so libturpial can migrate to testing and can be
included in "jessie".

The units tests must not write outside the builddir and they must pass
to be able to close this bug report.

-- 
Miguel Landaeta, nomadium at debian.org
secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key.
"Faith means not wanting to know what is true." -- Nietzsche


signature.asc
Description: Digital signature

Bug#761170: libgit2: FTBFS on multiple architectures

[Russell Sim]

Laurent Bigonville  writes:

> libgit2 is unfortunately FTBFS on multiple architectures in unstable due
> to test failures.
>
> Would be nice if the pkg was building on all the architectures.

Thanks for the report, from what I can see, 3 of the failing builds are
segfaulting in the test suite, and the other 2 are just failing tests in
the test suite.

I'll see if I can replicate these locally.

Thanks for bringing these to my attention.

Cheers,
Russell


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#761466: libkolabxml: FTBFS test-case failure fixed with boost1.55 patch

[Mauricio Faria de Oliveira]

Problem in boost1.55 library.
Please see #761926.

--
Mauricio Faria de Oliveira
IBM Linux Technology Center


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#747078: #747078: eatmydata: breaks faketime (and maybe others)

[Edward J. Shornock]

* Antonio Terceiro  [12-05-2014 12:32 EEST]:
> hah, that's it, that chroot did have eatmydata configured as a
> command-prefix! I have now removed eaymydata usage, and I can narrow
> down the problem to:
> 
> $ faketime +1day date
> Tue May 13 12:06:09 UTC 2014
> $ eatmydata faketime +1day date
> shm_open: Bad address
> $ faketime +1day eatmydata date
> shm_open: Bad address
> 
> I can also reproduce that problem on my main system, so it is not
> specific to the chroot configuration.

I also had the same problem with eatmydata causing faketime to fail. I
built and installed an updated eatmydata from
http://anonscm.debian.org/cgit/users/mapreri-guest/pkg-libeatmydata.git
and faketime no longer fails.

   $ faketime '1 day ago' /bin/date
   Tue Sep 16 00:04:35 UTC 2014
   $ eatmydata faketime '1 day ago' /bin/date
   Tue Sep 16 00:04:38 UTC 2014
   $ dpkg -s eatmydata |grep ^Version
   Version: 82-1


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#761934: libkolabxml: add ppc64el symbols (fix FTBFS)

[Mauricio Faria de Oliveira]

Package: src:libkolabxml
Tags: patch
User: debian-powe...@lists.debian.org
Usertags: ppc64el

Hi,

The attached patch adds ppc64el to the symbols file,
fixing libkolabxml FTBFS.  The changes are:

$ sed 's,!ppc64,!ppc64 !ppc64el,' -i debian/libkolabxml1.symbols
$ sed 's, ppc64, ppc64 ppc64el,'  -i debian/libkolabxml1.symbols

With it applied (and a patch for boost1.55 from #761926), the package
builds successfully on ppc64el.  (build log attached).

[...]
 dpkg-genchanges -sa >../libkolabxml_1.0.2-1ppc64el1_ppc64el.changes
dpkg-genchanges: including full source code in upload
 dpkg-source --after-build libkolabxml-1.0.2
dpkg-buildpackage: full upload (original source is included)

May you please consider it for an upload?

Thanks!



--
Mauricio Faria de Oliveira
IBM Linux Technology Center


libkolabxml-ppc64el-symbols.debdiff.xz
Description: application/xz


libkolabxml_1.0.2-1ppc64el1_ppc64el.build.xz
Description: application/xz

Bug#761906: liblz4-dev: Please provide a pkg-config file

[Nobuhiro Iwamatsu]

Hi!

2014-09-17 2:49 GMT+09:00 Mathieu Parent :
> Package: liblz4-dev
> Version: 0.0~r119-2
> Severity: normal
> Control: block 725224 by -1
>
> Dear Maintainer,
>
> Dear Maintainer,
>
> While trying to fix #725224, I found that liblz4-dev was missing a .pc file.
>
> It appeared upstream at r120.
>
> Can you install it?

Sure. I will upload soon.

>
> Thanks
>
> Mathieu Parent
>

Best regards,
  Nobuhiro


-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#733108: python3-requests: redirect can expose netrc password

[Daniele Tricoli]

Hello Jakub,

On Tuesday 16 September 2014 23:50:56 Jakub Wilk wrote:
> Version: 2.3.0-1
> 
> It looks like the bug was fixed upstream in 2.3.0:

Thanks for taking care of closing this. I received the notification from 
github, but I will work on requests (I plan to update to 2.4.1) on the 
weekend.

To acknowledge the fix of this security bug, I should put something in the 
changelog anyway, right?
Something like this:
  * Acknowledge fix for CVE-2014-1829 and CVE-2014-1830 in 2.3.0-1
(Closes: #733108)

Developer reference[¹] says: "When closing security bugs include CVE numbers 
as well as the Closes: #n. This is useful for the security team to track 
vulnerabilities. If an upload is made to fix the bug before the advisory ID is 
known, it is encouraged to modify the historical changelog entry with the next 
upload."

So using "Closes: #733108" although the bug is arleady closed seems ok to me, 
is that right?

Many thanks!

Kind regards,

[¹] https://www.debian.org/doc/manuals/developers-reference/pkgs.html#newpackage

-- 
 Daniele Tricoli 'Eriol'
 http://mornie.org


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#717235: proftpd requests the whole passwd database at each login

[Marco d'Itri]

On Jul 18, Marco d'Itri  wrote:

> After I switched from libnss-ldap to libnss-ldapd I noticed that at 
> every login proftpd requests the whole content of the passwd database 
> (i.e. like running "getent passwd).
> This is evident from the nslcd debugging log ("passwd(all)").
Are there any news about fixing this?
This bug prevents using proftpd on systems with a large users database.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Bug#745778: openssh-server/permit-root-login should be honored for new installs too

[Marco d'Itri]

On Apr 25, Marco d'Itri  wrote:

> Some environments need PermitRootLogin=yes.
> They will configure it no matter what the openssh maintainers think 
> about it, so please let's save time for everybody and allow this to be 
> preseeded for new installs as well.
Would you accept a patch to implement this?

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Bug#761933: heimdal-multidev: Making libroken easier for other packages to use

[Benjamin Kaduk]

Package: heimdal-multidev
Version: 1.6~rc2+dfsg-8
Severity: wishlist

OpenAFS is starting the process of creating a new stable release branch, 
and the new branch will have dependencies on libroken and libhcrypto
(hcrypto will be covered separately).  Upstream OpenAFS bundles copies
of roken and hcrypto, but for Debian it is presumably better to use
the system's version instead.  Upstream has nominal support for using
external roken (though not, at present, hcrypto) in the form of a configure
argument --with-roken=DIR.  However, the implementation of the configure
check just attempts to set CPPFLAGS+=-I${DIR}/include and
LDFLAGS+=-L${DIR}/lib, which would require the use of heimdal-dev instead
of heimdal-multidev.  Given the other packages I comaintain, it would be
highly inconvenient to have heimdal-dev installed to work on openafs,
so I am interested in ways to get openafs working with only heimdal-multidev.

I do not see any real way around this that does not involve some changes
to upstream openafs, but it might be easier if there was (e.g.) a pkg-config
file for libroken.  I suppose a separate libroken-dev package would suffice
for my purposes, but might be quite awkward from your perspective.
Do you have any thoughts on this matter?

When I started writing this feature request, I thought there were some
symbols required by openafs that were not provided by the current
libroken18-heimdal-1.6~rc2+dfsg-8, but I no longer believe that is the
case.  So, it's just the question of how to hook the system libroken into
the openafs build, which is patchable in openafs if nothing else.

Please close this bug if you don't think there is anything reasonable that
can be done on the heimdal side to support this use case.

Thanks,

Ben


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

Kernel: Linux 3.14-2-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libroken18-heimdal depends on:
ii  libc6  2.19-11
ii  multiarch-support  2.19-11

libroken18-heimdal recommends no packages.

libroken18-heimdal suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#761222: swi-prolog: arch dir changed for java libs -- ftbfs on ppc64el

[Aurelien Jarno]

Hi,

On Thu, Sep 11, 2014 at 07:35:15PM +, Fernando Seiti Furusato wrote:
> Source: swi-prolog
> Severity: normal
> Tags: patch
> 
> Dear Maintainer,
> 
> The arch dir for openjdk has changed from ppc64le to ppc64 on ppc64el 
> architecture.
> https://packages.qa.debian.org/o/openjdk-7/news/20140707T173510Z.html
> 
> So, once again, I have modified the patch so it will fix the ftbfs.
> The patch is attached and the build log can be seen at:
> https://buildd.debian.org/status/fetch.php?pkg=swi-prolog&arch=ppc64el&ver=6.6.6-2&stamp=1409662735
> 

Sorry to be a bit pushy, but it would be nice if you can make an upload
of this package with the patch attached to the bug as soon as possible.
Due to this bug swi-prolog is not available on ppc64el, which causes a 
few dozen of reverse build-dependencies to not be buildable. Thanks in
advance.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#735385: synaptic: quick search / xapian not installed by defafile:///home/bernhard/data/entwicklung/2014/debian/synaptic/patches/0001-Avoid-hiding-quick-filter-when-package-apt-xapian-in.patchult

[Bernhard Übelacker]

Hello all,
this patch does at least these changes when package apt-xapian-index is not 
installed:

 * Only disable quick filter and show a tooltip pointing to configuration dialog
 * Add configuration option to switch it off even when package is installed.
 * Add button besides configuration option to mark package for installation.

It still adds no question on first run - do we really want to add this?
But if we do not add it I am unsure what the default setting should be?

Kind regards,
Bernhard
From 855539098c1256636a54de866a00b6a986365aad Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernhard=20=C3=9Cbelacker?= 
Date: Wed, 17 Sep 2014 00:29:40 +0200
Subject: Avoid hiding quick filter when package apt-xapian-index is not
 installed.

 * Only disable quick filter and show a tooltip pointing to configuration dialog
 * Add configuration option to switch it off even when package is installed.
 * Add button besides configuration option to mark package for installation.
---
 gtk/gtkbuilder/window_preferences.ui | 47 +++-
 gtk/rgmainwindow.cc  | 11 ++---
 gtk/rgpreferenceswindow.cc   | 33 +
 gtk/rgpreferenceswindow.h|  2 ++
 4 files changed, 89 insertions(+), 4 deletions(-)

diff --git a/gtk/gtkbuilder/window_preferences.ui b/gtk/gtkbuilder/window_preferences.ui
index f291750..0e904a6 100644
--- a/gtk/gtkbuilder/window_preferences.ui
+++ b/gtk/gtkbuilder/window_preferences.ui
@@ -254,6 +254,51 @@
   
 
 
+  
+True
+False
+2
+6
+
+  
+Enable quick search box (requires package 'apt-xapian-index', not recommended for slow machines)
+True
+True
+False
+2
+True
+0.5
+True
+  
+  
+False
+False
+1
+  
+
+
+  
+Mark package 'apt-xapian-index' for installation
+True
+True
+False
+True
+
+  
+  
+False
+False
+2
+  
+
+  
+  
+False
+False
+3
+  
+
+
   
 True
 False
@@ -398,7 +443,7 @@
   
 True
 True
-3
+4
   
 
   
diff --git a/gtk/rgmainwindow.cc b/gtk/rgmainwindow.cc
index cf54ae5..19e3421 100644
--- a/gtk/rgmainwindow.cc
+++ b/gtk/rgmainwindow.cc
@@ -1601,9 +1601,14 @@ void RGMainWindow::buildInterface()
// only enable fast search if its usable
 #ifdef WITH_EPT
if(!_lister->xapiandatabase() ||
-  !FileExists("/usr/sbin/update-apt-xapian-index")) {
-  gtk_widget_hide(GTK_WIDGET(gtk_builder_get_object
- (_builder, "vbox_fast_search")));
+  !FileExists("/usr/sbin/update-apt-xapian-index") ||
+  _config->FindB("Synaptic::useXapian", true) != true)
+   {
+  GtkWidget *fast_search = GTK_WIDGET(gtk_builder_get_object
+  (_builder, "entry_fast_search"));
+  gtk_widget_set_sensitive(fast_search, FALSE);
+  gtk_widget_set_tooltip_text(fast_search,
+_("To use the quick filter please check the configuration options."));
}
 #else
gtk_widget_hide(GTK_WIDGET(gtk_builder_get_object
diff --git a/gtk/rgpreferenceswindow.cc b/gtk/rgpreferenceswindow.cc
index a0e47d0..f703677 100644
--- a/gtk/rgpreferenceswindow.cc
+++ b/gtk/rgpreferenceswindow.c

Bug#760881: Info received (Bug#760881: Acknowledgement (linux-image-3.16-trunk-amd64: radeonsi DRM/KMS: Monitors on DP outputs not enabled))

[Ralf-Peter Rohbeck]

This was caused by specifying the video modes on the kernel command 
line, which was needed in the past. After I removed them in 
/etc/default/grub the monitors were initialized again.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#641932: man-db: Do not throw all messages from error output away

[Colin Watson]

Control: tag -1 wontfix

On Sat, Sep 17, 2011 at 07:34:46PM +, Bjarni Ingi Gislason wrote:
>   Warnings and error messages are important to show possible
> defects in a manual.  Redirecting them to a file (e.g.
> "/var/log/mandb.err") is better than discarding them.

I'm not convinced that it makes sense to catch them this way.  We
already have a better way to collect defects via Lintian, notably these
two tags:

  https://lintian.debian.org/tags/manpage-has-bad-whatis-entry.html
  https://lintian.debian.org/tags/manpage-has-errors-from-man.html

It would be possible to log all of these on every Debian system, yes.
However, it would be a tremendously inefficient way to record these
defects compared to the existing Lintian reports which are much more
convenient for maintainers.  Logging them locally would simply encourage
people to duplicate lots of effort reporting them manually as bugs,
which doesn't seem like a good use of time unless they're going to go to
the extra effort to figure out patches too; and history indicates that
some sizeable fraction of those reports will be misdirected to man-db
and I'll have to spend time reassigning them to the right places.
Furthermore, manual page errors are usually considered too minor to fix
in stable releases, so users of stable will have a pile of error reports
that are unlikely to be fixed at least until they upgrade to the next
stable release.

I can see some small value in logging these errors for the cases of
packages which are not in Debian and thus not covered by Lintian runs,
certainly.  However, there are other ways to get hold of the same error
messages (e.g. lexgrog), and in any case I think the benefits of this
logging would be too small to outweigh the costs.

Sorry,

-- 
Colin Watson   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#761931: reportbug: bogus "not fully qualified" with ssmtp

[Sandro Tosi]

> sendmail: RCPT TO: (554 5.7.1 domain idefix of  is not 
> fully qualified.)

domains in email addresses have to be fully qualified to be routed, so
that means you may want to change the address you're using with
reportbug with something fully qualified.

Regards,

-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#670562: libupnp6: Shared library package is not co-installable

[Nick Leverton]

From: Nick Leverton 
To: Philipp Matthias Hahn 
Cc: 670...@bugs.debian.org
Bcc: 
Subject: Re: libupnp6: Shared library package is not co-installable
Reply-To: 
In-Reply-To: <20140430144101.ga12...@pmhahn.de>

On Wed, Apr 30, 2014 at 04:41:01PM +0200, Philipp Matthias Hahn wrote:
> The attached patch would make libixml and libthreadutil "convenience"
> libraries .

Hi Philipp,

I'm sorry for the late reply.

Thankyou for the idea but I'm not sure that this is a great win over
the other approaches.  It seems to me that, by only having one SONAME,
we are basically in the same position as if we kept three libraries
but redefined the SONAMEs to be in lock-step.  We'd have to manage the
combined SONAME by tracking API changes in all the libs, thus increasing
packaging effort, and would end up with it differing from upstream.
It would also add another transition for our already busy release team.

The patch as suggested, by the way, didn't have the desired effect.
It omitted libixml and libthreadutil from the package but didn't link them
into libupnp.so.  I've not yet figured out how to do that - just adding a
definition of libupnp_la_LIBADD as per libtool docs causes build failure
due to duplication for all the symbols in the two convenience libs.
But in light of the first paragraph it doesn't seem like a much better
solution anyway.

Nick


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#709405: man-db: bad man page information for "man setrlimit"

[Colin Watson]

Control: tag -1 fixed-upstream

On Thu, May 23, 2013 at 04:14:17AM +0200, Vincent Lefevre wrote:
> When I type "man setrlimit", I get on the last line:
> 
>  Manual page vlimit(3) line 1 (press h for help or q to quit)
> 
> Information vlimit(3) is wrong: I requested setrlimit.
> (The man page itself is correct, though.)

Belatedly fixed upstream, thanks:

  
http://git.savannah.gnu.org/cgit/man-db.git/commit/?id=5d872f5122a641ebe6107d351bea290ef1774ec8

-- 
Colin Watson   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#717215: Another voice

[Nathaniel W Filardo]

We deploy debian images inside VMs and it'd be nice to be able to use virtio
networking... any chance that RedHat or Ubuntu's patch could make its way
into Debian?

Thanks,
--nwf;


pgpXZp1sowZ_A.pgp
Description: PGP signature

Bug#761689: Fwd: Re: Bug#761689: apt-listbugs: [INTL:de] Updated German translation

[Francesco Poli]

On Tue, 16 Sep 2014 22:31:00 +0200 Francesco Poli wrote:

[...]
> Thank you!
> I've just applied the modifications.

Thanks a lot for your contribution.
I've just pushed the updated translation to the public git repository:
it will be part of the next upload of the package.

Bye.

-- 
 http://www.inventati.org/frx/
 fsck is a four letter word...
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpOURqr2B7uA.pgp
Description: PGP signature

Bug#761480: [l10n] Updated Czech translation of apt-listbugs

[Francesco Poli]

On Sun, 14 Sep 2014 18:05:37 +0200 Francesco Poli wrote:

[...]
> Please reply to my questions, so that we may further improve the
> translation, if needed.
> Thanks for your time!

Thank you so much for your contribution.
I've just pushed the updated translation to the public git repository:
it will be part of the next upload of the package.

However, I would like to receive answers to my questions (please see my
previous message), so that I may further enhance the translation.
Thanks for the time you will dedicate to this.

Please let me know as soon as possible.


-- 
 http://www.inventati.org/frx/
 fsck is a four letter word...
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp6D7Dy1a9lw.pgp
Description: PGP signature

Bug#761932: yorick: linking with libpthread fixes FTBFS of yorick-av and yorick-hdf5

[Svante Signell]

Source: yorick
Version: 2.2.03+dfsg-2
Severity: important
User: debian-h...@lists.debian.org
Usertags: hurd
Tags: patch

Hello, currently yorick-av and yorick-hdf5 FTBFS on GNU/Hurd due to
implicit inclusion of libpthread. Furthermore, both yorick-av and
yorick-hdf5 are flagged as out-of-date. Linking yorick with libpthread
directly fixes these problems. The attached patch adds a link directive
on libpthread for Hurd in debian/rules.

Thanks!
--- a/debian/rules.orig	2014-04-01 13:41:24.0 +0200
+++ b/debian/rules	2014-09-16 23:02:56.0 +0200
@@ -13,6 +13,11 @@
 CFLAGS += $(CPPFLAGS)
 export CFLAGS
 
+ifneq (,$(filter $(DEB_HOST_ARCH), hurd-i386))
+	LDFLAGS += -lpthread
+endif
+export LDFLAGS
+
 # This has to be exported to make some magic below work.
 export DH_OPTIONS
 

Bug#761931: reportbug: bogus "not fully qualified" with ssmtp

[Eduard Bloch]

Package: reportbug
Version: 6.5.1
Severity: normal

Dear Maintainer,

I am trying to send bugreports from a laptop with a "nomadic" network
connection. Therefore, I have a configured ssmtp here which runs over an
adhoc SSH tunnel and this works fine... with everything but reportbug.
Example:

Report will be sent to "Debian Bug Tracking System" 
Submit this report on broadcom-sta-source (e to edit) 
[Y|n|a|c|e|i|l|m|p|q|d|t|s|?]? 
Sending message via /usr/sbin/sendmail...
sendmail: RCPT TO: (554 5.7.1 domain idefix of  is not 
fully qualified.)
Error: send/write operation failed, bug report saved to 
/tmp/reportbug-broadcom-sta-
source-20140916-6501-gCHq86
$ /usr/sbin/sendmail sub...@bugs.debian.org < 
/tmp/reportbug-broadcom-sta-source-20140916-6501-gCHq86 

So this should work just fine. What does it do to sendmail to make it behave
that way? The manual page does not tell me anything sensible WRT such problems.

Regards,
Eduard.

-- Package-specific info:

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

Kernel: Linux 3.16-1-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

Versions of packages reportbug depends on:
ii  apt   1.0.7
ii  python2.7.8-1
ii  python-reportbug  6.5.1
pn  python:any

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail   
pn  debconf-utils
pn  debsums  
ii  dlocate  1.02+nmu3
pn  emacs22-bin-common | emacs23-bin-common  
ii  file 1:5.19-1
ii  gnupg1.4.18-4
ii  python-gtk2  2.24.0-4
pn  python-gtkspell  
pn  python-urwid 
ii  python-vte   1:0.28.2-5
ii  ssmtp [mail-transport-agent] 2.64-8
ii  xdg-utils1.1.0~rc1+git20111210-7.1

Versions of packages python-reportbug depends on:
ii  apt   1.0.7
ii  python-debian 0.1.22
ii  python-debianbts  1.12
pn  python:any

python-reportbug suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#761930: lintian: Please ship API documentation also as POD or as man page

[Axel Beckert]

Package: lintian
Version: 2.5.27
Severity: wishlist

Hi,

it took me a moment to recognize that the Lintian API documentation is
indeed in package -- because I neither found them with man nor with
perldoc.

I expect that I'm not the only one who'd prefer perldoc or man over a
web browser for reading perl-related documentation.

So it would be nice if the POD sources would be shipped in perldoc's
search path and/or man pages generated from POD.

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (600, 'testing'), (400, 'stable'), (110, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.15-trunk-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages lintian depends on:
ii  binutils   2.24.51.20140903-1
ii  bzip2  1.0.6-7
ii  diffstat   1.58-1
ii  file   1:5.19-2
ii  gettext0.19.2-2
ii  hardening-includes 2.5+nmu1
ii  intltool-debian0.35.0+20060710.1
ii  libapt-pkg-perl0.1.29+b2
ii  libarchive-zip-perl1.38-1
ii  libclass-accessor-perl 0.34-1
ii  libclone-perl  0.37-1+b1
ii  libdigest-sha-perl 5.92-1+b1
ii  libdpkg-perl   1.17.13
ii  libemail-valid-perl1.195-1
ii  libfile-basedir-perl   0.03-1
ii  libipc-run-perl0.92-1
ii  liblist-moreutils-perl 0.33-2+b1
ii  libparse-debianchangelog-perl  1.2.0-1.1
ii  libtext-levenshtein-perl   0.09-1
ii  libtimedate-perl   2.3000-2
ii  liburi-perl1.64-1
ii  man-db 2.6.7.1-1
ii  patchutils 0.3.3-1
ii  perl [libdigest-sha-perl]  5.20.0-6
ii  t1utils1.37-2.1

Versions of packages lintian recommends:
ii  libautodie-perl 2.25-1
ii  libperlio-gzip-perl 0.18-3+b1
ii  perl5.20.0-6
ii  perl-modules [libautodie-perl]  5.20.0-6

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  dpkg-dev   1.17.13
ii  libhtml-parser-perl3.71-1+b2
ii  libtext-template-perl  1.46-1
ii  libyaml-perl   1.09-1
ii  xz-utils   5.1.1alpha+20120614-2

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#761922: [pkg-wpa-devel] Bug#761922: wpa: please enable syslog option for the udeb

[Cyril Brulebois]

Stefan Lippers-Hollmann  (2014-09-16):
> > as discussed in [1] it would be nice to get CONFIG_DEBUG_SYSLOG=y
> > added to the wpasupplicant-udeb configuration. I've successfully
> > tested this on linux (amd64), patching netcfg to call wpa_supplicant
> > with the proper flags (-s and -d/-dd).
> > 
> >  1. https://lists.debian.org/debian-boot/2014/09/msg00517.html
> > 
> > I see patches are already in svn but I'd like to make sure we can
> > track this properly to avoid adding those flags to netcfg before
> > wpa is uploaded and possibly has migrated to testing.
> [...]
> 
> Thanks, I'll try to get it uploaded as soon as possible (hopefully
> within the next 1-2 days).

So I've tested it again with:
 - wpa built from svn (r1889)
 - netcfg built from the pu/wpa branch (see #761923)
 - and against locally built linux image (see #761902)

and everything went very fine.

As you might have guessed, I've got no specific experience in the wpa
area but I can sponsor packages, so feel free to ping me when you have
a source package ready to review/upload (mentors.d.n or the like?).

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#761327: [INTL:tr] Turkish program translation of apt-listbugs

[Francesco Poli]

On Sat, 13 Sep 2014 19:52:41 +0200 Francesco Poli wrote:

[...]
> Thank you so much, I've just modified the translation as you suggested!

Thanks a lot for your contribution.
I've just pushed the updated translation to the public git repository:
it will be part of the next upload of the package.

Bye!

-- 
 http://www.inventati.org/frx/
 fsck is a four letter word...
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpLkkI7ktC1i.pgp
Description: PGP signature

Bug#760773: My apologies,

[Charles Laws]

Please accept my apologies, I had one too many windows open and sent a
reply meant for an openshot bug.

Bug#761303: apt-listbugs: [INTL:pt] Updated Portuguese translation for program

[Francesco Poli]

On Mon, 15 Sep 2014 22:36:46 +0200 Francesco Poli wrote:

> On Sun, 14 Sep 2014 18:41:31 +0100 Miguel Figueiredo wrote:
> 
> [...]
> > Thanks for your suggestions, I am attaching a reviewed version.
> 
> Thanks to you!
> I've just applied the modifications.

Thank you very much for your contribution.
I've just pushed the updated translation to the public git repository:
it will be part of the next upload of the package.

Bye!


-- 
 http://www.inventati.org/frx/
 fsck is a four letter word...
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpFx4Gnjw0A8.pgp
Description: PGP signature

Bug#760518: transition: gnome 3.14

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed pending

On 05/09/14 00:07, Emilio Pozuelo Monfort wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi,
> 
> We've been working on GNOME 3.14 during the summer, with the intention
> of trying to get it into Jessie. Most of the core packages are in
> experimental or in svn by now. It is my intention to get the final bits
> into experimental over the weekend and then deciding whether to go for
> it right after that, depending on how things look.
> 
> So far it seems pretty easy compared to e.g. the 3.8 -> 3.12 upgrade,
> as there are very few internal SONAME bumps (that shouldn't affect
> non-GNOME modules) and we won't block on external bits, like we did
> with upower and bluez for the previous upgrade.
> 
> Anyway I'll post a more detailed summary later on and then we can
> decide whether this is feasible for Jessie. If we go for it, I expect
> we can do it after the current ongoing transitions and have it done
> in 5 to 10 days (the time to upload a few packages, scheduled binNMUs
> and wait for everything to settle and transition). I think everything
> could be done by mid-September.

The only library transition we have so far is libmutter0d -> libmutter0e (with
only one rdep, gnome-shell, which will be updated as well). The core packages
(glib, gtk+, mutter, gnome-shell, ...) are all in experimental already, built
everywhere and working fine. I thus think we can get this done pretty quickly,
so I'm acking it. The 3.14 RC is scheduled for tomorrow, so we'll start
uploading that and we should be finished by next week.

Emilio


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#761518: Can confirm failed audio export,

[Charles Laws]

Sometime in the last six weeks I lost the ability to export audio, even
after selecting quite a few different encoding options. This was on an
updated testing install, however this morning I migrated to unstable and
the problem persists. Using openshot --debug and doing a render gives me
this:

[libx264 @ 0x7fac29e0] [Eval @ 0x7fac39ffa500] Undefined constant or
missing '(' in 'dct8x8'
[libx264 @ 0x7fac29e0] Unable to parse option value "dct8x8"
[aac @ 0x7fac002caec0] [Eval @ 0x7fac39ffa4b0] Undefined constant or
missing '(' in 'dct8x8'
[aac @ 0x7fac002caec0] Unable to parse option value "dct8x8"
[mp4 @ 0x7fac24a0] Using AVStream.codec.time_base as a timebase hint to
the muxer is deprecated. Set AVStream.time_base instead.
on_frmExportVideo_destroy
[consumer avformat] error writing flushed audio frame

Bug#761928: broadcom-sta-source: Fails to build with Debian's 3.16.2

[Eduard Bloch]

Package: broadcom-sta-source
Version: 6.30.223.248-1
Severity: normal

Dear Maintainer,

this is unlike the other report about 3.16 rc... kernel which was solved
before. This time it looks different after upgrading to latest kernel in
Sid:

for templ in ; do \
cp $templ `echo $templ | sed -e 's/_KVERS_/3.16-1-amd64/g'` ; \
  done
for templ in `ls debian/*.modules.in` ; do \
test -e ${templ%.modules.in}.backup || cp ${templ%.modules.in} 
${templ%.modules.in}.backup 2>/dev/null || true; \
sed -e 's/##KVERS##/3.16-1-amd64/g ;s/#KVERS#/3.16-1-amd64/g ; 
s/_KVERS_/3.16-1-amd64/g ; s/##KDREV##/3.16.2-2/g ; s/#KDREV#/3.16.2-2/g ; 
s/_KDREV_/3.16.2-2/g  ' < $templ > ${templ%.modules.in}; \
  done
dh_clean
/usr/bin/make clean KBUILD=/lib/modules/3.16-1-amd64/build KVERS=3.16-1-amd64
make[1]: Entering directory '/usr/src/modules/broadcom-sta'
KBUILD_NOPEDANTIC=1 make -C /lib/modules/3.16-1-amd64/build M=`pwd` clean
make[2]: Entering directory '/usr/src/linux-headers-3.16-1-amd64'
make[1]: Entering directory `/usr/src/linux-headers-3.16-1-amd64'
CFG80211 API is prefered for this kernel version
make[2]: Leaving directory '/usr/src/linux-headers-3.16-1-amd64'
make[1]: Leaving directory '/usr/src/modules/broadcom-sta'
 debian/rules KVERS=3.16-1-amd64 KSRC=/lib/modules/3.16-1-amd64/build 
KDREV=3.16.2-2 kdist_image
/usr/bin/make  -f debian/rules kdist_clean kdist_config binary-modules
make[1]: Entering directory '/usr/src/modules/broadcom-sta'
for templ in ; do \
cp $templ `echo $templ | sed -e 's/_KVERS_/3.16-1-amd64/g'` ; \
  done
for templ in `ls debian/*.modules.in` ; do \
test -e ${templ%.modules.in}.backup || cp ${templ%.modules.in} 
${templ%.modules.in}.backup 2>/dev/null || true; \
sed -e 's/##KVERS##/3.16-1-amd64/g ;s/#KVERS#/3.16-1-amd64/g ; 
s/_KVERS_/3.16-1-amd64/g ; s/##KDREV##/3.16.2-2/g ; s/#KDREV#/3.16.2-2/g ; 
s/_KDREV_/3.16.2-2/g  ' < $templ > ${templ%.modules.in}; \
  done
dh_clean
/usr/bin/make clean KBUILD=/lib/modules/3.16-1-amd64/build KVERS=3.16-1-amd64
make[2]: Entering directory '/usr/src/modules/broadcom-sta'
KBUILD_NOPEDANTIC=1 make -C /lib/modules/3.16-1-amd64/build M=`pwd` clean
make[3]: Entering directory '/usr/src/linux-headers-3.16-1-amd64'
Makefile:10: *** mixed implicit and normal rules: deprecated syntax
make[1]: Entering directory `/usr/src/linux-headers-3.16-1-amd64'
CFG80211 API is prefered for this kernel version
/usr/src/modules/broadcom-sta/Makefile:85: Neither CFG80211 nor Wireless 
Extension is enabled in kernel
make[3]: Leaving directory '/usr/src/linux-headers-3.16-1-amd64'
make[2]: Leaving directory '/usr/src/modules/broadcom-sta'
make[1]: Nothing to be done for 'kdist_config'.
dh_testdir
dh_testroot
dh_prep
# Build and install the module
make -C /lib/modules/3.16-1-amd64/build M=/usr/src/modules/broadcom-sta
make[2]: Entering directory '/usr/src/linux-headers-3.16-1-amd64'
make[1]: Entering directory `/usr/src/linux-headers-3.16-1-amd64'
CFG80211 API is prefered for this kernel version
Using CFG80211 API
Kernel architecture is X86_64
  LD  /usr/src/modules/broadcom-sta/built-in.o
make[5]: *** No rule to make target 
'/usr/src/modules/broadcom-sta/src/shared/linux_osl.o', needed by 
'/usr/src/modules/broadcom-sta/wl.o'.  Stop.
/usr/src/linux-headers-3.16-1-common/Makefile:1350: recipe for target 
'_module_/usr/src/modules/broadcom-sta' failed
make[4]: *** [_module_/usr/src/modules/broadcom-sta] Error 2
Makefile:181: recipe for target 'sub-make' failed
make[3]: *** [sub-make] Error 2
Makefile:8: recipe for target 'all' failed
make[2]: *** [all] Error 2
make[2]: Leaving directory '/usr/src/linux-headers-3.16-1-amd64'
debian/rules:16: recipe for target 'binary-modules' failed
make[1]: *** [binary-modules] Error 2
make[1]: Leaving directory '/usr/src/modules/broadcom-sta'
/usr/share/modass/include/common-rules.make:56: recipe for target 'kdist_build' 
failed
make: *** [kdist_build] Error 2

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

Kernel: Linux 3.16-1-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

Versions of packages broadcom-sta-source depends on:
ii  bzip2  1.0.6-7
ii  debhelper  9.20140817
ii  make-guile [make]  4.0-8

Versions of packages broadcom-sta-source recommends:
ii  module-assistant  0.11.7

broadcom-sta-source suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#760773: Could this bug cause failed audio export?

[Charles Laws]

Sometime in the last six weeks I seem to have lost the ability to export
audio with Openshot. Running openshot --debug and running an export gives
me this message:

[libx264 @ 0x7f2b782c7b40] [Eval @ 0x7f2b9d7f9500] Undefined constant or
missing '(' in 'dct8x8'
[libx264 @ 0x7f2b782c7b40] Unable to parse option value "dct8x8"
[aac @ 0x7f2b782c9f60] [Eval @ 0x7f2b9d7f94b0] Undefined constant or
missing '(' in 'dct8x8'
[aac @ 0x7f2b782c9f60] Unable to parse option value "dct8x8"
[mp4 @ 0x7f2b782c70a0] Using AVStream.codec.time_base as a timebase hint to
the muxer is deprecated. Set AVStream.time_base instead.
on_frmExportVideo_destroy
[consumer avformat] error writing flushed audio frame

Previously on testing, however I migrated to unstable this morning and the
problem persists.

Charles Laws

Bug#761923: netcfg: please enable wpa_supplicant syslog and debug flags

[Cyril Brulebois]

Control: tag -1 patch pending

Cyril Brulebois  (2014-09-16):
> Source: netcfg
> Version: 1.120
> Severity: normal
> Control: block -1 by 761922
> 
> Hi,
> 
> see discussion in [1] for background, and #761922 for the requested
> change in the wpa package. To enable this syslog mode, netcfg needs
> to pass the -s flag in its execlp call (wpa.c) but it MUST NOT do so
> before wpa has been uploaded (possibly migrated to testing) since
> wpa_supplicant would exit due to an unknown flag otherwise.
> 
>  1. https://lists.debian.org/debian-boot/2014/09/msg00517.html
> 
> It would also probably make sense to enable at least the first debug
> level (-d), and maybe the second one (-dd), even if I'm not sure.
> There might be a way to make it configurable, so that we can ask
> users to perform a single change when they report WPA-related
> issues?
> 
> I'd probably go for -s and -d in the next upload; and see how often
> we need -dd after that.

Testing with wpa 2.2-1 (as staged in wpa's svn as of r1889), that means
200+ wpa_supplicant lines on success, and 1200+ lines if I fail to enter
the right passphrase.

That might be a tad too much to be useful. Maybe having the possibility
to set -d or -dd “manually” (in case of errors) would be better. I'm
tempted to actually drop the -d flag for the next upload, and get back
to my initial idea: another bug report to track adding a “moar debug”
option.

Anyway, I've stacked the patch I've just tested in the pu/wpa branch for
now, and I'm tagging this bug report with patch + pending so that nobody
wastes time on it.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#761905: Database error in apper.

[Matthias Klumpp]

2014-09-16 19:48 GMT+02:00 Петр Кульшан :
> Package: apper
> Version: 0.9.1-1
>
> Unable to open database read-only: Database action 'prepare app insert 
> statement' failed: SQL logic error or missing database.
>
> It,s error message i can see, if i search packages.
Does
sudo rm -r /var/lib/listaller/
fix this issue for you?

Cheers,
Matthias


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#761927: Please add that we removed Magick-config to NEWS

[Bastien ROUCARIES]

package: src:imagemagick
severity: important



ari: but there isn't even anything in the changelog or NEWS about
Magick-config going awa
(23:27:42) ari: y
(23:28:04) broucarie: ari: will add something to new for next release. Thanks


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#761926: boost1.55: fix libkolabxml test-suite error on ppc64el

[Mauricio Faria de Oliveira]

Package: boost1.55
Tags: patch
User: debian-powe...@lists.debian.org
Usertags: ppc64el

This patch fixes this test-suite error of libkolabxml on ppc64el [1].

It is from the boost library shipped with IBM Advance Toolchain, which
is getting fixes/improvements for the Power architecture (e.g.,ppc64el)
that should be submitted upstream soon.

May you please consider it for an upload meanwhile?

Thank you!

[1] 
https://buildd.debian.org/status/fetch.php?pkg=libkolabxml&arch=ppc64el&ver=1.0.2-1&stamp=1410666021



--
Mauricio Faria de Oliveira
IBM Linux Technology Center
diff -Nru boost1.55-1.55.0+dfsg/debian/changelog 
boost1.55-1.55.0+dfsg/debian/changelog
--- boost1.55-1.55.0+dfsg/debian/changelog  2014-06-10 06:16:51.0 
-0300
+++ boost1.55-1.55.0+dfsg/debian/changelog  2014-09-16 17:11:18.0 
-0300
@@ -1,3 +1,9 @@
+boost1.55 (1.55.0+dfsg-2ppc64el1) UNRELEASED; urgency=medium
+
+  * ppc64el-fp_traits-ibm-long-double.patch: fix libkolabxml FTBFS on ppc64el.
+
+ -- Mauricio Faria de Oliveira   Tue, 16 Sep 2014 
16:40:22 -0300
+
 boost1.55 (1.55.0+dfsg-2) unstable; urgency=medium
 
   * Disable pch on arm64, to avoid FTBFS. (Closes: #750956)
diff -Nru 
boost1.55-1.55.0+dfsg/debian/patches/ppc64el-fp_traits-ibm-long-double.patch 
boost1.55-1.55.0+dfsg/debian/patches/ppc64el-fp_traits-ibm-long-double.patch
--- 
boost1.55-1.55.0+dfsg/debian/patches/ppc64el-fp_traits-ibm-long-double.patch
1969-12-31 21:00:00.0 -0300
+++ 
boost1.55-1.55.0+dfsg/debian/patches/ppc64el-fp_traits-ibm-long-double.patch
2014-09-16 17:11:24.0 -0300
@@ -0,0 +1,45 @@
+Origin: 
https://github.com/boost-at/boost_1_55_0/commit/4426b41dab6bb8d110ebda00e0b199b640c7896a
+From: Adhemerval Zanella 
+Date: Tue, 22 Apr 2014 14:31:19 -0500
+Subject: [PATCH] math: Fix fp_traits for IBM long double
+
+This patch fixes the fp_traits_non_native template specialization for
+IBM long double.  Current interface does not work correctly for the type
+due the fact for some operations (sign manipulation, for instance), both
+double should be manipulated.  For other operations that only require
+the 32 most significand bits (isinf/isnan for instance), the double
+specialization is suffice.
+
+This fixes the issues for getometry test in PPC64LE environment with no
+regreesions on PPC64BE.
+---
+ boost/math/special_functions/detail/fp_traits.hpp | 9 -
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+diff --git a/boost/math/special_functions/detail/fp_traits.hpp 
b/boost/math/special_functions/detail/fp_traits.hpp
+index 50c034d..72ebd4e 100644
+--- a/boost/math/special_functions/detail/fp_traits.hpp
 b/boost/math/special_functions/detail/fp_traits.hpp
+@@ -359,6 +359,13 @@ struct fp_traits_non_native
+ 
+ // PowerPC extended double precision format (128 bits)
+ 
++// Current 'fp_traits_non_native' does not work correctly with IBM long double
++// due the fact for some operations, like sign manipulation, the algorithm
++// should manipulate both 'double' value.  For algorithms that only depend on
++// the most significand 32 bits (for instance, isinf or isnan), using the
++// template double especialization is suffice.
++
++#if 0
+ template<>
+ struct fp_traits_non_native
+ {
+@@ -391,7 +398,7 @@ struct fp_traits_non_native
+ BOOST_STATIC_ASSERT(false);
+ #endif
+ };
+-
++#endif
+ 
+ // long double (>64 bits), Motorola 68K 

+ 
diff -Nru boost1.55-1.55.0+dfsg/debian/patches/series 
boost1.55-1.55.0+dfsg/debian/patches/series
--- boost1.55-1.55.0+dfsg/debian/patches/series 2013-12-28 21:14:48.0 
-0200
+++ boost1.55-1.55.0+dfsg/debian/patches/series 2014-09-16 17:11:24.0 
-0300
@@ -7,3 +7,4 @@
 boost-1.55.0-001-log_fix_dump_avx2.patch
 ELFv2-libboost1.54-dev-context-asm.patch
 boost-python-examples.patch
+ppc64el-fp_traits-ibm-long-double.patch

Bug#761922: [pkg-wpa-devel] Bug#761922: wpa: please enable syslog option for the udeb

[Stefan Lippers-Hollmann]

Thanks

On Tuesday 16 September 2014, Cyril Brulebois wrote:
> Source: wpa
> Version: 1.1-1
> Severity: normal
> Tags: d-i
> 
> Hi,
> 
> as discussed in [1] it would be nice to get CONFIG_DEBUG_SYSLOG=y
> added to the wpasupplicant-udeb configuration. I've successfully
> tested this on linux (amd64), patching netcfg to call wpa_supplicant
> with the proper flags (-s and -d/-dd).
> 
>  1. https://lists.debian.org/debian-boot/2014/09/msg00517.html
> 
> I see patches are already in svn but I'd like to make sure we can
> track this properly to avoid adding those flags to netcfg before
> wpa is uploaded and possibly has migrated to testing.
[...]

Thanks, I'll try to get it uploaded as soon as possible (hopefully
within the next 1-2 days).

Regards
Stefan Lippers-Hollmann


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

Bug#761900: RM: ctn/3.0.6-13 -- non-redistributable source file present

[Andreas Tille]

Hi Valerio,

On Tue, Sep 16, 2014 at 01:50:09PM -0400, Valerio Luccio wrote:
> >Ctn is orphaned upstream but 3.2.0 is the latest version.
> >
> >Kind regards
> >
> > Andreas.
> >
> OK. dinifti is build using ctn, does this mean I have to change
> dinifti ? It's possible, but not it's not a quick fix.

Using ctn 3.2.0 is fine - as far as I can say.

Kind regards

  Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#761925: exim4-config: add OUTGOING_INTERFACE macro to remote_smtp transport

[Paul Muster]

Package: exim4-config
Version: 4.80-7
Severity: wishlist
Tags: patch

Dear Maintainer,

could a macro for the outgoing interface be added to
conf.d/transport/30_exim4-config_remote_smtp ?

.ifdef OUTGOING_INTERFACE
  interface = OUTGOING_INTERFACE
.endif

so that one can configure the outgoing interface in
conf.d/main/000_localmacros instead of changing the above metioned file?

Thanks & greetings,

Paul


-- Package-specific info:
Exim version 4.80 #2 built 02-Jan-2013 19:40:19
Copyright (c) University of Cambridge, 1995 - 2012
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 
- 2012

Berkeley DB: Berkeley DB 5.1.29: (October 25, 2011)
Support for: crypteq iconv() IPv6 PAM Perl Expand_dlfunc GnuTLS 
move_frozen_messages Content_Scanning DKIM Old_Demime
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm 
dbmjz dbmnz dnsdb dsearch ldap ldapdn ldapm mysql nis nis0 passwd pgsql 
sqlite

Authenticators: cram_md5 cyrus_sasl dovecot plaintext spa
Routers: accept dnslookup ipliteral iplookup manualroute queryprogram 
redirect

Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp
Fixed never_users: 0
Size of off_t: 8
Configuration file is /var/lib/exim4/config.autogenerated

-- System Information:
Debian Release: 7.6
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 
'proposed-updates')

Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/3 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages exim4-config depends on:
ii  adduser3.113+nmu3
ii  debconf [debconf-2.0]  1.5.49

exim4-config recommends no packages.

exim4-config suggests no packages.

-- Configuration Files:
/etc/email-addresses changed [not included]
/etc/exim4/conf.d/auth/30_exim4-config_examples changed [not included]
/etc/exim4/conf.d/main/02_exim4-config_options changed [not included]
/etc/exim4/conf.d/router/200_exim4-config_primary changed [not included]
/etc/exim4/conf.d/router/900_exim4-config_local_user changed [not included]
/etc/exim4/conf.d/transport/30_exim4-config_maildrop_pipe changed [not 
included]
/etc/exim4/conf.d/transport/30_exim4-config_remote_smtp changed [not 
included]
/etc/exim4/passwd.client [Errno 13] Permission denied: 
u'/etc/exim4/passwd.client'


-- debconf information excluded


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#761924: Acknowledgement (open-vm-tools dkms build fails with linux kernel 3.16-1-amd64)

[Benjamin Kaduk]

Hmm, I missed my chance to add an attachment in reportbug, sorry.
Here's the log.

-Ben
DKMS make.log for open-vm-tools-9.4.6 for kernel 3.16-1-amd64 (x86_64)
Tue Sep 16 16:45:41 EDT 2014
make: Entering directory '/var/lib/dkms/open-vm-tools/9.4.6/build/vmhgfs'
Using 2.6.x kernel build system.
Building vmhgfs without VMCI module symbols.
make -C /lib/modules/3.16-1-amd64/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. \
  MODULEBUILDDIR=/var/lib/dkms/open-vm-tools/9.4.6/build modules
make[1]: Entering directory '/usr/src/linux-headers-3.16-1-amd64'
Makefile:10: *** mixed implicit and normal rules: deprecated syntax
make[1]: Entering directory `/usr/src/linux-headers-3.16-1-amd64'
  CC [M]  /var/lib/dkms/open-vm-tools/9.4.6/build/vmhgfs/message.o
In file included from 
/var/lib/dkms/open-vm-tools/9.4.6/build/vmhgfs/backdoor.h:44:0,
 from 
/var/lib/dkms/open-vm-tools/9.4.6/build/vmhgfs/message.c:68:
/var/lib/dkms/open-vm-tools/9.4.6/build/vmhgfs/./shared/vm_assert.h:291:0: 
warning: "DEPRECATED" redefined [enabled by default]
#define DEPRECATED(_fix) do {} while (0)
 ^
In file included from 
/usr/src/linux-headers-3.16-1-common/include/linux/kernel.h:13:0,
 from 
/var/lib/dkms/open-vm-tools/9.4.6/build/vmhgfs/./shared/kernelStubs.h:36,
 from 
/var/lib/dkms/open-vm-tools/9.4.6/build/vmhgfs/message.c:59:
/usr/src/linux-headers-3.16-1-common/include/linux/printk.h:103:0: note: this 
is the location of the previous definition
 #define DEPRECATED "[Deprecated]: "
 ^
  CC [M]  /var/lib/dkms/open-vm-tools/9.4.6/build/vmhgfs/request.o
In file included from 
/var/lib/dkms/open-vm-tools/9.4.6/build/vmhgfs/hgfs.h:54:0,
 from 
/var/lib/dkms/open-vm-tools/9.4.6/build/vmhgfs/hgfsProto.h:51,
 from 
/var/lib/dkms/open-vm-tools/9.4.6/build/vmhgfs/module.h:39,
 from 
/var/lib/dkms/open-vm-tools/9.4.6/build/vmhgfs/request.c:38:
/var/lib/dkms/open-vm-tools/9.4.6/build/vmhgfs/./shared/vm_assert.h:291:0: 
warning: "DEPRECATED" redefined [enabled by default]
#define DEPRECATED(_fix) do {} while (0)
 ^
In file included from 
/usr/src/linux-headers-3.16-1-common/include/linux/kernel.h:13:0,
 from 
/usr/src/linux-headers-3.16-1-common/arch/x86/include/asm/percpu.h:44,
 from 
/usr/src/linux-headers-3.16-1-common/arch/x86/include/asm/current.h:5,
 from 
/usr/src/linux-headers-3.16-1-common/arch/x86/include/asm/processor.h:15,
 from 
/usr/src/linux-headers-3.16-1-common/arch/x86/include/asm/atomic.h:6,
 from 
/var/lib/dkms/open-vm-tools/9.4.6/build/vmhgfs/request.c:29:
/usr/src/linux-headers-3.16-1-common/include/linux/printk.h:103:0: note: this 
is the location of the previous definition
 #define DEPRECATED "[Deprecated]: "
 ^
  CC [M]  /var/lib/dkms/open-vm-tools/9.4.6/build/vmhgfs/filesystem.o
In file included from 
/var/lib/dkms/open-vm-tools/9.4.6/build/vmhgfs/hgfs.h:54:0,
 from 
/var/lib/dkms/open-vm-tools/9.4.6/build/vmhgfs/request.h:38,
 from 
/var/lib/dkms/open-vm-tools/9.4.6/build/vmhgfs/transport.h:26,
 from 
/var/lib/dkms/open-vm-tools/9.4.6/build/vmhgfs/filesystem.c:48:
/var/lib/dkms/open-vm-tools/9.4.6/build/vmhgfs/./shared/vm_assert.h:291:0: 
warning: "DEPRECATED" redefined [enabled by default]
#define DEPRECATED(_fix) do {} while (0)
 ^
In file included from 
/usr/src/linux-headers-3.16-1-common/include/linux/kernel.h:13:0,
 from 
/usr/src/linux-headers-3.16-1-common/arch/x86/include/asm/percpu.h:44,
 from 
/usr/src/linux-headers-3.16-1-common/arch/x86/include/asm/current.h:5,
 from 
/usr/src/linux-headers-3.16-1-common/arch/x86/include/asm/processor.h:15,
 from 
/usr/src/linux-headers-3.16-1-common/arch/x86/include/asm/atomic.h:6,
 from 
/var/lib/dkms/open-vm-tools/9.4.6/build/vmhgfs/filesystem.c:29:
/usr/src/linux-headers-3.16-1-common/include/linux/printk.h:103:0: note: this 
is the location of the previous definition
 #define DEPRECATED "[Deprecated]: "
 ^
  CC [M]  /var/lib/dkms/open-vm-tools/9.4.6/build/vmhgfs/cpName.o
  CC [M]  /var/lib/dkms/open-vm-tools/9.4.6/build/vmhgfs/link.o
In file included from 
/var/lib/dkms/open-vm-tools/9.4.6/build/vmhgfs/hgfs.h:54:0,
 from 
/var/lib/dkms/open-vm-tools/9.4.6/build/vmhgfs/hgfsProto.h:51,
 from 
/var/lib/dkms/open-vm-tools/9.4.6/build/vmhgfs/module.h:39,
 from /var/lib/dkms/open-vm-tools/9.4.6/build/vmhgfs/link.c:32:
/var/lib/dkms/open-vm-tools/9.4.6/build/vmhgfs/./shared/vm_assert.h:291:0: 
warning: "DEPRECATED" redefined [enabled by default]
#define DEPRECATED(_fix) do {} while (0)
 ^
In file included from 
/usr/src/linux-headers-3.16-1-common/include/linux/kernel.h:13:0,
 from 
/usr/src/linux-headers-3.16-1-common/arch/x86/include/asm/percpu.h:44,
 from 
/usr/src/linux-headers-3.

Bug#761924: open-vm-tools dkms build fails with linux kernel 3.16-1-amd64

[Benjamin Kaduk]

Package: open-vm-tools
Version: 2:9.4.6-1770165-2
Severity: important

Updating my sid machine today gives me:
run-parts: executing /etc/kernel/header_postinst.d/dkms 3.16-1-amd64
Error! Bad return status for module build on kernel: 3.16-1-amd64 (x86_64)
Consult /var/lib/dkms/open-vm-tools/9.4.6/build/make.log for more information.


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

Kernel: Linux 3.14-2-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages open-vm-tools depends on:
ii  libc6 2.19-11
ii  libdumbnet1   1.12-4
ii  libfuse2  2.9.3-15
ii  libgcc1   1:4.9.1-14
ii  libglib2.0-0  2.40.0-5
ii  libicu52  52.1-5
ii  libprocps31:3.3.9-7
ii  libstdc++64.9.1-14

Versions of packages open-vm-tools recommends:
ii  ethtool   1:3.13-1
ii  zerofree  1.0.3-1

Versions of packages open-vm-tools suggests:
ii  open-vm-tools-desktop  2:9.4.6-1770165-2

-- Configuration Files:
/etc/modprobe.d/open-vm-tools.conf changed [not included]
/etc/vmware-tools/tools.conf changed [not included]

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#760712: WEP vs WPA2

[Cyril Brulebois]

Cyril Brulebois  (2014-09-15):
> Ben, I guess it might make sense to add those to crypto-modules? Not
> sure how feasible it would be to figure out which other ones might be
> interesting for other wireless modules though…
> 
> → I can open a bug against src:linux to keep track of it.

#761902, already fixed in linux's sid branch, and confirmed locally.

> Ben mentioned on IRC: CONFIG_DEBUG_SYSLOG=y which might be helpful for
> the udeb. Adding this option on top of sid's wpasupplicant-udeb isn't
> sufficient, since one also needs adding the -s flag to netcfg's execlp
> call. Once both udebs have been modified, wpasupplicant lines end up
> in syslog, which is definitely helpful.
> 
> → That should probably become 2 extra bug reports (src:wpa, src:netcfg).

wpa now has #761922, and there are patches in svn already.

netcfg now has #761923, blocked-by #761922.

> Beware of the order: passing -s without CONFIG_DEBUG_SYSLOG=y means
> getting an error and usage in syslog, so netcfg should only be patched
> when wpa is ready.
> 
> Once we get there, it might make sense to pass (or make it possible to
> pass) at least -d to wpa_supplicant.
> 
> → An extra bug report for netcfg.

I've lumped -d with -s into #761923.

Thanks again everyone.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#761913: percona-xtradb-cluster-server-5.5: Percona XtraDB Cluster lacks documentation of OpenSSL exception to GPL

[Andrei POPESCU]

Control: reassign -1 percona-xtradb-cluster-server-5.5

On Ma, 16 sep 14, 11:48:15, Clint Byrum wrote:
> Source: percona-xtradb-cluster-server-5.5
> Version: Percona XtraDB Cluster lacks documentation of OpenSSL exception to 
> GPL
> Severity: normal
> 
> OpenSSL cannot be linked to from GPL code without the authors providing
> an exception to clause 6 of the GPL, since the OpenSSL license imposes
> restrictions incompatible with the GPL. This is why MySQL does not link
> against OpenSSL.
> 
> CYaSSL was recently accepted into Debian unstable, and is available for
> use as a standard shared library. Percona XtraDB Cluster should build
> and link against that, as it is GPL compatible, or the license exception
> should be documented in debian/copyright.
> 
> -- System Information:
> Debian Release: jessie/sid
>   APT prefers trusty-updates
>   APT policy: (500, 'trusty-updates'), (500, 'trusty-security'), (500, 
> 'trusty'), (100, 'trusty-backports')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 3.13.0-35-generic (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

-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Bug#761923: netcfg: please enable wpa_supplicant syslog and debug flags

[Cyril Brulebois]

Source: netcfg
Version: 1.120
Severity: normal
Control: block -1 by 761922

Hi,

see discussion in [1] for background, and #761922 for the requested
change in the wpa package. To enable this syslog mode, netcfg needs
to pass the -s flag in its execlp call (wpa.c) but it MUST NOT do so
before wpa has been uploaded (possibly migrated to testing) since
wpa_supplicant would exit due to an unknown flag otherwise.

 1. https://lists.debian.org/debian-boot/2014/09/msg00517.html

It would also probably make sense to enable at least the first debug
level (-d), and maybe the second one (-dd), even if I'm not sure.
There might be a way to make it configurable, so that we can ask
users to perform a single change when they report WPA-related
issues?

I'd probably go for -s and -d in the next upload; and see how often
we need -dd after that.

Mraw,
KiBi.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#761921: slic3r: Uninstallable, depends on unavailable perlapi-5.18.2

[Andreas Wettergren]

Package: slic3r
Version: 1.2.0+dfsg-1
Severity: grave
Justification: renders package unusable

Like the subject says, not installable in experimental at present.
1.1.7+dfsg-2+b1 already depends on perlapi-5.20.0 so this is probably just an 
oversight?

(BTW, running slic3r with perl => 5.16 causes numerical bugs on some locales. 
Should really be fixed upstream IMHO. Workaround is to run with "export 
LC_NUMERIC=C; slic3r".)

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

Kernel: Linux 3.16-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=sv_SE.utf8, LC_CTYPE=sv_SE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#761922: wpa: please enable syslog option for the udeb

[Cyril Brulebois]

Source: wpa
Version: 1.1-1
Severity: normal
Tags: d-i

Hi,

as discussed in [1] it would be nice to get CONFIG_DEBUG_SYSLOG=y
added to the wpasupplicant-udeb configuration. I've successfully
tested this on linux (amd64), patching netcfg to call wpa_supplicant
with the proper flags (-s and -d/-dd).

 1. https://lists.debian.org/debian-boot/2014/09/msg00517.html

I see patches are already in svn but I'd like to make sure we can
track this properly to avoid adding those flags to netcfg before
wpa is uploaded and possibly has migrated to testing.

Mraw,
KiBi.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#760038: 17: get unusable black screen with pointer since second login

[Curtis Dean Smith]

I have also encountered this problem.  After upgrading Wheezy to Jessie, I
tried logging in from gdm3 to the new Enlightenment environment, but the
screen first goes blank, then comes back with the standard background and
pointer, but I cannot do anything from there.  The pointer "flashes" when I
press a mouse button, but nothing happens.
I tried stopping gdm3, logging into a command console, and starting with
"startx enlightenment_start".  I was successful several times, but
recently, this only gives a blank screen with nothing.

-- System Information:
Debian Release: jessie/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 3.14-2-686-pae (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

Versions of packages e17 depends on:
ii  dbus-x11   1.8.6-2
ii  e17-data   0.17.6-1
ii  libasound2 1.0.28-1
ii  libc6  2.19-11
ii  libdbus-1-31.8.6-2
ii  libecore-con1  1.8.6-2
ii  libecore-evas1 1.8.6-2
ii  libecore-file1 1.8.6-2
ii  libecore-imf1  1.8.6-2
ii  libecore-input11.8.6-2
ii  libecore-ipc1  1.8.6-2
ii  libecore-x11.8.6-2
ii  libecore1  1.8.6-2
ii  libedbus1  1.7.10-1
ii  libedje-bin1.8.6-2
ii  libedje1   1.8.6-2
ii  libeet11.8.6-2
ii  libeeze1   1.8.6-2
ii  libefreet-bin  1.8.6-2
ii  libefreet1a1.8.6-2
ii  libeina1   1.8.6-2
ii  libeio11.8.6-2
ii  libevas1   1.8.6-2
ii  libevas1-engines-x [libevas1-engine-software-x11]  1.8.6-2
ii  libpam0g   1.1.8-3.1
ii  libxcb-keysyms10.3.9-2
ii  libxcb-shape0  1.10-3
ii  libxcb11.10-3

Versions of packages e17 recommends:
ii  pm-utils  1.4.1-15

e17 suggests no packages.

-- no debconf information


--

Bug#761689: Fwd: Re: Bug#761689: apt-listbugs: [INTL:de] Updated German translation

[Francesco Poli]

On Tue, 16 Sep 2014 21:56:15 +0200 Chris Leick wrote:

[...]
> Good idea, it must be »für alle«. I've reviewed this file an I've
> changed some typos. The corrected file is attached.

Thank you!
I've just applied the modifications.

Bye.

-- 
 http://www.inventati.org/frx/
 fsck is a four letter word...
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpT1AjrpVlco.pgp
Description: PGP signature

Bug#761920: scilab: FTBFS on ppc64el: error: Could not detect the location of the Java

[Aurelien Jarno]

Source: scilab
Version: 5.5.0-3
Severity: important
Tags: patch

Dear Maintainer,

scilab FTBFS on ppc64el with the following error:

| checking if jni.h can be included... yes
| configure: error: Could not detect the location of the Java
| shared library. You will need to update java.m4
| to add support for this JVM configuration.
| Looking for JNI libs with ppc64le as machine hardware name
| Looking for /usr/lib/jvm/java-7-openjdk-ppc64el/jre/lib/ppc64le/libjava.so
| Looking for /usr/lib/jvm/java-7-openjdk-ppc64el/jre/lib/amd64/libjava.so
| Looking for /usr/lib/jvm/java-7-openjdk-ppc64el/jre/lib/i386/client/libjvm.so
| Looking for /usr/lib/jvm/java-7-openjdk-ppc64el/jre/bin/classic/libjvm.so
| Looking for /usr/lib/jvm/java-7-openjdk-ppc64el/lib/jvm.lib
| Looking for /usr/lib/jvm/java-7-openjdk-ppc64el/jre/lib/mipsel/libjava.so
| make: *** [debian/stamp-autotools] Error 1
| /usr/share/cdbs/1/class/autotools.mk:42: recipe for target 
'debian/stamp-autotools' failed

A full build log is available here:
https://buildd.debian.org/status/fetch.php?pkg=scilab&arch=ppc64el&ver=5.5.0-3&stamp=1410496986

As suggested by the error message, here is an update of m4/java.m4 to
support ppc64el. I have also changed the machine for ppc64 big endian,
which use the same directory as the little endian version. I guess it
was wrongly set as a 32-bit powerpc machine can run a 64-bit kernel.
Packages should be built using the linux32 wrapper on such machines.

diff -Nru scilab-5.5.0/debian/patches/m4-java-ppc64el.patch 
scilab-5.5.0/debian/patches/m4-java-ppc64el.patch
--- scilab-5.5.0/debian/patches/m4-java-ppc64el.patch   1970-01-01 
00:00:00.0 +
+++ scilab-5.5.0/debian/patches/m4-java-ppc64el.patch   2014-09-16 
18:47:50.0 +
@@ -0,0 +1,16 @@
+--- scilab-5.5.0.orig/m4/java.m4
 scilab-5.5.0/m4/java.m4
+@@ -471,9 +471,12 @@ AC_DEFUN([AC_JAVA_JNI_LIBS], [
+# Sun
+   machine=sparc
+   ;;
+-powerpc|ppc64)
++powerpc)
+   machine=ppc
+   ;;
++ppc64|ppc64le)
++  machine=ppc64
++  ;;
+ armv*)
+   machine=arm
+   ;;
diff -Nru scilab-5.5.0/debian/patches/series scilab-5.5.0/debian/patches/series
--- scilab-5.5.0/debian/patches/series  2014-08-02 10:48:00.0 +
+++ scilab-5.5.0/debian/patches/series  2014-09-16 18:47:55.0 +
@@ -6,3 +6,4 @@
 depend-scicos.diff
 missing-lib.diff
 m4-hdf5.patch
+m4-java-ppc64el.patch

Would it be possible to apply this patch in the next upload? Thanks in advance.

Aurelien

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: ppc64el (ppc64le)

Kernel: Linux 3.14-2-powerpc64le (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/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#742409: [Sereal] 2.06 fails to build on some architectures: (#47)

[demerphq]

On 16 September 2014 21:06, Niko Tyni  wrote:

> (Cc'ing Yves instead of the scary github address as he
>  explicitly asked for that in the upstream ticket.)
>
>
Thanks. :-)


> On Wed, Jul 16, 2014 at 05:06:29PM +0200, gregor herrmann wrote:
> > On Tue, 15 Jul 2014 13:03:56 -0700, Yves Orton wrote:
>
> > > This is so frustrating. Is there anyone in the Debian community that
> knows
> > > these platforms that can help?
> >
> > Hm, probably but I'm not sure who knows about all of them.
> > Cc'ing the Debian bug report.
>
> Hi, I looked at the Sereal-Encoder problems briefly. The current state
> with Debian libsereal-encoder-perl 3.002-1 (unpatched 3.002) is that it
> only fails on 64-bit big-endian architectures (s390x and powerpc64).
>
> The failures are all in t/700_roundtrip/ with the snappy tests, and
> involve array refs and long strings. I was able to reduce at least one
> of them to this:
>
>   #!/usr/bin/perl -w
>   use blib;
>   use Sereal::Decoder;
>   use Sereal::Encoder;
>   my $opt = { snappy => 1, use_protocol_v1 => 1};
>
>   my $len = shift || 509;
>
>   my $s="A"x$len;
>   my $e =  Sereal::Encoder->new($opt)->encode([$s, $s]);
>   my $d =  Sereal::Decoder->new($opt)->decode($e);
>
>   # print $e;
>   print "" . ($d->[0] eq $s ? "" : "not ") . "ok 1 first element\n";
>   print "" . ($d->[1] eq $s ? "" : "not ") . "ok 2 second element\n";
>
> which gives "not ok 2" on s390x when the length is 509 or greater.
>
> The problem is with the encoder: amd64 and s390x encoded contents differ,
> and feeding the amd64 encoded output to an s390x decoder works fine.
> The second element of the decoded array is just the string "3" in the
> incorrect case.
>
>
Yes, indeed. Snappy is getting something wrong.

IIRC, prior to this patch:

commit 910842fc8aa3b9666926e2a40ad8f7c6d5e1c6d5
Author: Yves Orton 
Date:   Tue Jul 15 13:32:14 2014 +0200

rework alignedness checks in Sereal code so that we do unaligned only
on x86

Snappy did not work at all.

https://github.com/Sereal/Sereal/commit/910842fc8aa3b9666926e2a40ad8f7c6d5e1c6d5


> I see the length of the encoded output shortens dramatically at the 508 ->
> 509 step, looks like some compression kicks in.
>
> I'm attaching the binary output from both s390x (incorrect) and amd64
> (correct) for reference for length==509. Hope they make it through,
> the md5sums should be
>
>  8787f3dd9a3bfa23bd91eb08c40f3716  509.amd64
>  276cbe59ce957915cc92b52fb0b7b51c  509.s390x
>
> All this makes me think that the problem is in snappy/csnappy_compress.c,
> but I haven't really delved into it yet.
>
> Hope this helps. Yves, please let me know if I can help in any way.
>

Well I am wondering if you can look the patch I referenced above and see if
you can work out what you need to do to get s390x to do the right thing? As
you have identified yourself this is clearly a problem with the snappy
support. But we pass test on other big-endian 64 bit platform as far as I
understand (although I might be wrong).

I have CC'ed Jarkko as he did some of the work getting us to build properly
on platforms with strict alignment and big-endian encodings.

Yves

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

Bug#761919: RFP: hockeypuck -- Hockeypuck is an OpenPGP Key Server developed in Go.

[Brian Minton]

Package: wnpp
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

* Package name: hockeypuck
  Version : 1.0
  Upstream Author : Casey Marshall 
* URL : https://hockeypuck.github.io/
* License : GPLv3
  Programming Lang: Go
  Description : Hockeypuck is an OpenPGP Key Server developed in Go.

This keyserver implements the HKP draft protocol specification as well as 
several extensions to the protocol supported by SKS.

Public key material conforming to RFC 4880 are supported by the service, as are 
RFC 6637 ECC keys.
Go Language

Hockeypuck is developed in 100% pure Go. It compiles and runs on Linux and BSD 
variants including Mac OS X. The concurrent capacity of the service should be 
limited only by the underlying key storage database. The Go language fosters a 
simple, modular, mostly-imperative programming style that I think is natural 
yet refreshing for developers coming from a C, Python or Java background (like 
myself).
PostgreSQL Key Database

Hockeypuck stores all public key material in a relational PostgreSQL database. 
The schema is optimized for performance but also data integrity, 
cross-referencing and search capabilities with judicious use of foreign keys 
and full-text indexing.
SKS Reconciliation Protocol

Hockeypuck is the first keyserver besides SKS that is capable of synchronizing 
public key material with peers using the SKS reconciliation protocol. Recon 
protocol support is provided with the Conflux library, developed initially for 
this purpose, but potentially useful for other applications.

- - why is this package useful/relevant?
It is useful because it provides a fast public keyserver.
- - do you use it?
not yet, but I'm trying it out.
- - if there are other packages providing similar functionality, how does it
compare?
the package sks provides similar functionality.  

 - how do you plan to maintain it? 
There is already an ubuntu package.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEAREDAAYFAlQYmdYACgkQ2/alund99IeaOQCePOxnpX1KPjTkAv1ovcocFKrT
mZ8AoL+hvtdPbm7vTw8h7EWG/+vUqTYF
=DX+V
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#761666: Updated patch for GNU/Hurd

[Andrew Shadura]

Hello,

On Tue, 16 Sep 2014 09:55:27 +0200
Svante Signell  wrote:

> As I wrote in this bug report the build fails since sysconf does not
> return any sane value. Attached is an updated patch for configure.in
> defining bmake_path_max to 1024 if it is undefined now when patch
> 130_maxpathlen.diff is gone.

Thanks Svante, I've forwarded it to Simon and applied it.

-- 
Cheers,
  Andrew


signature.asc
Description: PGP signature

Bug#761909: systemd does not unmount nfs shares before bringing down the network interface

[Giuseppe Bilotta]

On Tue, Sep 16, 2014 at 9:06 PM, Michael Biebl  wrote:
> Am 16.09.2014 um 20:15 schrieb Giuseppe Bilotta:
>> Most significantly, if I shutdown the system after bringing up the
>> network, the shutdown process will hang while waiting for the
>> un-mounting of /oneforall, which cannot happen because the network has
>> been automatically brought down already earlier in the shutdown process.
>
> What/which service is responsible for bringing down the network?

I have no idea. How do I check that?


-- 
Giuseppe "Oblomov" Bilotta


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#761917: libperl-apireference-perl: Support 5.20.1

[Dominic Hargreaves]

Package: libperl-apireference-perl
Version: 0.17-1
Severity: normal
Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=98885
Tags: upstream
Blocks: 760123

This needs to be updated so that we can upload 5.20.1 without things
like padre breaking (if memory serves correctly).

Cheers,
Dominic.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#761918: imagemagick: long standing warning now is an error

[Paul Gevers]

Package: imagemagick-6.q16
Version: 8:6.8.9.6-4
Control: affects -1 lazarus

Dear Maintainer,

Recently my package lazarus FTBFS (see bug 761536). The problem is apparently
a png file that we convert during build. As you can see from the loggings of
the past builds we have seen the warning below for ages, but suddenly the 
warning
turned into an error (while the message still says "warning"). I am wondering if
that was intended. (If yes, I couldn'd find what the problem is with the file,
an advice on improving the figure is also appreciated).

(pbuild1845) wollumbin lazarus-1.2.4+dfsg # identify images/ide_icon48x48.png 
|| echo we got an error
images/ide_icon48x48.png PNG 48x48 48x48+0+0 8-bit sRGB 4.24KB 0.010u 0:00.019
identify: tRNS chunk not allowed with alpha channel `images/ide_icon48x48.png' 
@ warning/png.c/MagickPNGWarningHandler/1831.
we got an error



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

Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash

Versions of packages imagemagick-6.q16 depends on:
ii  hicolor-icon-theme 0.13-1
ii  libc6  2.19-11
ii  libmagickcore-6.q16-2  8:6.8.9.6-4
ii  libmagickwand-6.q16-2  8:6.8.9.6-4

Versions of packages imagemagick-6.q16 recommends:
pn  ghostscript  
pn  libmagickcore-6.q16-2-extra  
pn  netpbm   

Versions of packages imagemagick-6.q16 suggests:
pn  autotrace   
pn  cups-bsd | lpr | lprng  
pn  curl
pn  enscript
pn  ffmpeg  
pn  gimp
pn  gnuplot 
pn  grads   
pn  graphviz
ii  groff-base  1.22.2-8
pn  hp2xx   
pn  html2ps 
pn  imagemagick-doc 
pn  libwmf-bin  
pn  mplayer 
pn  povray  
pn  radiance
pn  sane-utils  
pn  texlive-base-bin
pn  transfig
pn  ufraw-batch 
pn  xdg-utils   

-- no debconf information



signature.asc
Description: OpenPGP digital signature

Bug#731976: [pkg-ntp-maintainers] Bug#731976: ntpdate: Please use flock(1) in /etc/network/if-up.d/ntpdate

[Aurelien Jarno]

control: severity -1 important

On Wed, Dec 11, 2013 at 11:45:25PM +0100, Kurt Roeckx wrote:
> On Wed, Dec 11, 2013 at 10:26:32PM +0100, Christoph Biedl wrote:
> > Package: ntpdate
> > Version: 1:4.2.6.p5+dfsg-2
> > Severity: normal
> > Tags: patch
> > 
> > Dear Maintainer,
> > 
> > the code in /etc/network/if-up.d/ntpdate tries to prevent parallel
> > excution of ntpdate-debian by perusing the lockfile-progs package. If
> > this is not installed - and it seldom is here -,

With the switch to systemd by default, the problem appears at almost all
boots, even with -u is not added to /etc/default/ntpdate.

> You know there is a:
> Recommends: lockfile-progs

The problem now affects all users using systemd which is the default for
Jessie. In that case a Recommends: is clearly not enough. I am therefore
bumping the severity of this bug.

> I didn't know about flock(1), will look in to it.

I'll see if I can come with a patch.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#761902: linux: please add ctr and ccm to crypto-modules

[Cyril Brulebois]

Control: tag -1 pending

Cyril Brulebois  (2014-09-16):
> Hi,
> 
> as discovered in #760712[1], some extra crypto modules can be needed to
> get WPA support working in d-i, namely ctr and ccm (at least in the
> rtl8192cu case).
> 
>  1. https://lists.debian.org/debian-boot/2014/09/msg00517.html
> 
> Please consider adding those to the crypto-modules udeb in your next
> upload, thanks.

Implemented in r21856, and confirmed locally, thanks!

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#761689: Fwd: Re: Bug#761689: apt-listbugs: [INTL:de] Updated German translation

[Chris Leick]

 Original-Nachricht 
Betreff: 	Re: Bug#761689: apt-listbugs: [INTL:de] Updated German 
translation

Datum:  Tue, 16 Sep 2014 21:55:08 +0200
Von:Chris Leick 
An: Francesco Poli 



Hi Francesco,

Francesco Poli:

Chris Leick wrote:


#: ../lib/apt-listbugs/logic.rb:54
msgid ""
" -s   : Filter bugs by severities you want to see (or \"all\")\n"
"[%s].\n"
msgstr ""
" -s  : filtert nach Schweregraden, die Sie sehen wollen (oder"
"»all«).\n"

In order to clarify that "-s all" will show all the severities, would
the following translation be better?

msgstr ""
" -s  : filtert nach Schweregraden, die Sie sehen wollen\n"
" (oder »all« für alles)\n"
" [%s].\n"

(I have also re-added the [%s] that got lost somehow).
Please fix grammar errors, if any (I know almost nothing about
German, sorry!).


Good idea, it must be »für alle«. I've reviewed this file an I've
changed some typos. The corrected file is attached.

Kind regards,
Chris






de.po.gz
Description: application/gzip

Bug#761311: systemd: Sometimes at Boot systemd can't start some services (avahi, bluetooth)

[Michael Biebl]

Am 16.09.2014 um 10:58 schrieb MERLIN Philippe:
> Le vendredi 12 septembre 2014, 22:01:55 Michael Biebl a écrit :
>> Am 12.09.2014 21:39, schrieb merlin:
>>> Sep 11 11:28:36 localhost kernel: [0.00] Command line:
>>> BOOT_IMAGE=/boot/vmlinuz-3.16-1-amd64
>>> root=UUID=cfefa5bd-93c0-4451-818e-26207c170c14 ro clocksource=acpi_pm
>>> ipv6.disable=1 systemd.log_target=kmsg systemd.log_level=debug
>>> log_buf_len=1M enforcing=0
>> ..
>>
>>> Sep 11 11:28:36 localhost kernel: [0.619303] IPv6: Loaded, but
>>> administratively disabled, reboot required to enable
>> I wonder if this is the reason.
>>
>> Could you please enable ipv6 and test again.
> I test it and it works on  two start of the system, the third start failed.
> I join at my message, syslog of the session, the result of the commands :
> systemctl status avahi-daemon.service ---> avahi-status-16-09-2014.txt
> journalctl -xn >avahi-journal-16-09-2014.txt
> Best Regard.
> Philippe Merlin


I wonder, if this a hardware issue which causes dbus to timeout (iirc
the default timeout for responses is 25 seconds).

Is you hard drive / system slow?


-- 
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#761914: RFP: mapbox-studio -- Vector tile driven map design

[Pierre Rudloff]

Package: wnpp
Severity: wishlist

* Package name: mapbox-studio
  Version : 0.1.2
  Upstream Author : Mapbox (https://www.mapbox.com)
* URL : https://www.mapbox.com/mapbox-studio/
* License : BSD-3
  Programming Lang: Node
  Description : Vector tile driven map design


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#759725: Acknowledgement (postgresql-common: non-synchronous service postgresql start/stop/reload)

[Christoph Berg]

Re: b...@debian.org 2014-09-08 <20140908182249.ga25...@mail.beuc.net>
> Can you share a bit your motivations for decreasing the severity of
> this bug?
> 
> I don't think FusionForge is the only package that will be kicked in
> the balls when installed on a brand new, systemd-enabled Debian 8
> box next year :(
> 
> Is that asynchronous behavior Debian-specific?

Hi Sylvain, hi Richard,

frankly I was too fast with the severity change, sorry. This problem
needs to be fixed for Jessie.

It's insofar Debian-specific as stock PostgreSQL doesn't have
postgresql-common.


Re: Richard Hughes 2014-09-15 <1394146913.20140915225...@rhughes.net>
> A service which depends on postgresql (using the recommended
> Requires=/After= pair) is also affected by this, because the service
> cannot immediately connect to Postgres at startup.
> 
> This patch seems to make start/stop work for me, although it doesn't
> do anything about reload:
> 
> --- a/postgresql@.service 2014-08-11 14:40:56.0 +0100
> +++ b/postgresql@.service 2014-09-09 15:44:32.489366245 +0100
> @@ -8,10 +8,12 @@
>  ConditionPathExists=/etc/postgresql/%I/postgresql.conf
>  PartOf=postgresql.service
>  ReloadPropagatedFrom=postgresql.service
> +Before=postgresql.service
> 
>  [Service]
>  # @: use "postgresql@%i" as process name
> -ExecStart=@/usr/bin/pg_ctlcluster postgresql@%i --foreground --stdlog %i 
> start
> +Type=forking
> +ExecStart=@/usr/bin/pg_ctlcluster postgresql@%i --stdlog %i start
>  ExecStop=/usr/bin/pg_ctlcluster -m fast %i stop
>  ExecReload=/usr/bin/pg_ctlcluster %i reload
>  PIDFile=/var/run/postgresql/%i.pid

Thanks for the patch, applied. (Without --stdlog as that's only useful
with --foreground.)

Christoph
-- 
c...@df7cb.de | http://www.df7cb.de/


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#754757: timeout during g++

[Bas Wijnen]

Hello Mips-porters,

My package, openmsx, failed to build on mips due to a compiler timeout.
(#754757) Looking at the earlier successful buildd logs, it has always taken
quite long to build.  In the bug it was reported that compilation does succeed
if it is not interrupted, so the compiler doesn't hang.  It can be worked
around by disabling optimization, but my guess is that if even the buildds are
so slow, mips users will need all the optimization they can get.

What do you suggest I do?  My preference would be to get the timeout value
increased, so that it will build as is.  Is that an option?

Thank you,
Bas Wijnen

Ps: Please Cc me on replies, I'm not subscribed.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#761687: RFS: abraca/0.8.0+dfsg-1 -- Simple and powerful graphical client for XMMS2

[Daniel Lintott]

Hi Guys,

On 16/09/14 07:23, Tobias Frost wrote:
> 
> There are no indications that the package has been orphaned, so it
> likely hasn't.
> 

In case your not aware, it seems the package has now been orphaned[1] as
of today (excellent work by Ricardo Mones).

Regards,

Daniel

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761830



signature.asc
Description: OpenPGP digital signature

Bug#761590: Acknowledgement (owncloud-client: Unable to initialize a sync journal)

[Sylvain Collilieux]

Hi,

Log file attached. I've just removed some personal data.


-- 
Sylvain
09-16 20:49:11:080 application.cpp:344 "## ownCloud fr_FR () 1.6.3"
09-16 20:49:11:134 application.cpp:531 void Mirall::Application::setupTranslations() Using "fr_FR" translation
09-16 20:49:11:415 folderman.cpp:139 * Setup folders from  ""
09-16 20:49:11:436 folderman.cpp:262   ` -> setting up: "xxx"
09-16 20:49:11:458 folderman.cpp:280 -> file path:  "/home/sylvain/.local/share/data/ownCloud/folders/xxx"
09-16 20:49:11:475 folder.cpp:165 Checked local path ok
09-16 20:49:11:475 folder.cpp:84 setting remote poll timer interval to 3 msec
09-16 20:49:11:475 folderman.cpp:311 Adding folder to Folder Map  Mirall::Folder(0x12deaa0)
09-16 20:49:11:489 folderwatcher_linux.cpp:93 (+) Watcher: "/home/sylvain/Documents/xxx/"
09-16 20:49:11:490 folderwatcher_linux.cpp:123 `-> and 1 subdirectories
09-16 20:49:11:499 folderman.cpp:412 Schedule folder  "xxx"  to sync!
09-16 20:49:11:499 folderman.cpp:420 Folder is not enabled, not scheduled!
09-16 20:49:11:499 folderman.cpp:262   ` -> setting up: "yyy"
09-16 20:49:11:509 folderman.cpp:280 -> file path:  "/home/sylvain/.local/share/data/ownCloud/folders/yyy"
09-16 20:49:11:509 folder.cpp:165 Checked local path ok
09-16 20:49:11:510 folder.cpp:84 setting remote poll timer interval to 3 msec
09-16 20:49:11:510 folderman.cpp:311 Adding folder to Folder Map  Mirall::Folder(0x12d6c30)
09-16 20:49:11:510 folderwatcher_linux.cpp:93 (+) Watcher: "/home/sylvain/Documents/yyy/"
09-16 20:49:11:539 folderman.cpp:412 Schedule folder  "yyy"  to sync!
09-16 20:49:11:539 folderman.cpp:262   ` -> setting up: "zzz"
09-16 20:49:11:559 folderman.cpp:280 -> file path:  "/home/sylvain/.local/share/data/ownCloud/folders/zzz"
09-16 20:49:11:560 folder.cpp:165 Checked local path ok
09-16 20:49:11:560 folder.cpp:84 setting remote poll timer interval to 3 msec
09-16 20:49:11:560 folderman.cpp:311 Adding folder to Folder Map  Mirall::Folder(0x12670e0)
09-16 20:49:11:560 folderwatcher_linux.cpp:93 (+) Watcher: "/home/sylvain/Documents//"
09-16 20:49:11:578 folderwatcher_linux.cpp:123 `-> and 2 subdirectories
09-16 20:49:11:579 folderman.cpp:412 Schedule folder  ""  to sync!
09-16 20:49:11:579 folderman.cpp:262   ` -> setting up: "s"
09-16 20:49:11:592 folderman.cpp:280 -> file path:  "/home/sylvain/.local/share/data/ownCloud/folders/s"
09-16 20:49:11:592 folder.cpp:165 Checked local path ok
09-16 20:49:11:592 folder.cpp:84 setting remote poll timer interval to 3 msec
09-16 20:49:11:592 folderman.cpp:311 Adding folder to Folder Map  Mirall::Folder(0x1265740)
09-16 20:49:11:592 folderwatcher_linux.cpp:93 (+) Watcher: "/home/sylvain/Documents/s/"
09-16 20:49:11:630 folderman.cpp:412 Schedule folder  "s"  to sync!
09-16 20:49:11:630 folderman.cpp:420 Folder is not enabled, not scheduled!
09-16 20:49:11:630 folderman.cpp:262   ` -> setting up: "rrr"
09-16 20:49:11:645 folderman.cpp:280 -> file path:  "/home/sylvain/.local/share/data/ownCloud/folders/rrr"
09-16 20:49:11:646 folder.cpp:165 Checked local path ok
09-16 20:49:11:646 folder.cpp:84 setting remote poll timer interval to 3 msec
09-16 20:49:11:646 folderman.cpp:311 Adding folder to Folder Map  Mirall::Folder(0x1264c60)
09-16 20:49:11:646 folderwatcher_linux.cpp:93 (+) Watcher: "/home/sylvain/Documents/rrr/"
09-16 20:49:11:660 folderman.cpp:412 Schedule folder  "rrr"  to sync!
09-16 20:49:11:660 folderman.cpp:262   ` -> setting up: "ppp"
09-16 20:49:11:701 folderman.cpp:280 -> file path:  "/home/sylvain/.local/share/data/ownCloud/folders/ppp"
09-16 20:49:11:701 folder.cpp:165 Checked local path ok
09-16 20:49:11:701 folder.cpp:84 setting remote poll timer interval to 3 msec
09-16 20:49:11:701 folderman.cpp:311 Adding folder to Folder Map  Mirall::Folder(0x1268740)
09-16 20:49:11:701 folderwatcher_linux.cpp:93 (+) Watcher: "/home/sylvain/Documents/ppp/"
09-16 20:49:11:716 folderman.cpp:412 Schedule folder  "ppp"  to sync!
09-16 20:49:13:380 application.cpp:148 Mirall::Application::Application(int&, char**) Skipping update check
09-16 20:49:13:380 socketapi.cpp:55 SocketApi:  can't start server ""
09-16 20:49:13:557 updater.cpp:71 Sys Info size:  100
09-16 20:49:13:563 networkxxxs.cpp:192 !!! Mirall::CheckServerxxx created for  QUrl( "https://server.local"; )  querying "status.php"
09-16 20:49:13:564 folderman.cpp:461 FolderMan: Syncing is disabled, no scheduling.
09-16 20:49:13:564 folderman.cpp:461 FolderMan: Syncing is disabled, no scheduling.
09-16 20:49:13:564 folderman.cpp:461 FolderMan: Syncing is disabled, no scheduling.
09-16 20:49:13:564 folderman.cpp:461 FolderMan: Syncing is disabled, no scheduling.
09-16 20:49:14:306 networkxxxs.cpp:418 status.php returns:  QMap(("edition", QVariant(QString, "") ) ( "installed" ,  QVariant(QString, "true") ) ( "version" ,  QVariant(QString, "7.0.2.1") ) ( "versionstring" ,  QVariant(QString, "7.0.2") ) )0  Reply:  QNetworkReplyHtt

Bug#754987: udevadm settle causes 30 sec delay under sysvinit

[dimas]

hello!
i can confirm the same issue, and /lib/udev/net.agent is the reason.
after trying the tips given above, i thought: why the hell udev should raise up
the network when it starts? we have /etc/init.d/networking for this!
and i've just added "exit 0" at the very beginning of /lib/udev/net.agent
folks, this speeded up boot process like noting else)) network is maintained
fine by good old init script.
PS. seems that it's not only thing, that is duplucating init scripts
functions...


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#761407: [Pkg-openldap-devel] Bug#761407: slapd: changes of cn=config become effective only after restarting slapd

[Dietrich Clauss]

Hi Ryan,

Ryan Tandy schrieb:
> Thanks for the report. This is ITS#6035 upstream. In that report the
> developer wrote:
> 
> >This is a known limitation in authz regexp support. There are no
> >plans to change this any time soon.

Please, add a big fat warning in slapd-config(5).

Especially because online changes of most (all?) other config attributes
work fine, it is difficult to guess that in case of AuthzRegexp the
things are different.  I don't think that the limitation per se is
problematic, but it should be documented somewhere.

> Concerning attributes other than olcAuthzRegexp, in my tests on
> wheezy olcAccess changes did take effect immediately. Can you
> double-check that or provide a test case demonstrating it?

Confirmed.  Changes of olcAccess work fine here, too.

Best regards,
- Dietrich


signature.asc
Description: Digital signature

Bug#734236: Brasero won't work on Debian Wheezy with LXDE desktop

[Mateusz Łukasik]

Hello,

Package: lxde doesn't provides anything depends for Brasero. I want to 
close this bug.


Mateusz


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#761643: RFS: libstrophe/0.8.6-1 [ITP]

[Tobias Frost]

On Tue, 2014-09-16 at 09:07 +0200, Dariusz Dwornikowski wrote:

> > Hi Dariusz,
> >  
> > somehow the d/copyright is still not matching 100% to the code...
> > At least for many files there is a "Copyright (c) 2005-2009 Collecta,
> > Inc" which is not in d/copyright. So probably this copyright owner is
> > missing for the * rule. Can you please fix it.
> 
> Yes I fixed this. 
> 
> > 
> > Also, I'm missing see a proof for the "or later" option of the GPL, as
> > it would have to be explictly stated by upstream, see GPL-3 §14. So
> > write GPL-3 or ask upstream for clarification.
> 
> Fixed, yes they have GPL-3 not later.
> > 
> > (Please wrap your comment, there is also two empty lines at the end of
> > the file and one empty line in the middle. Those are nitpicks, though) 
> 
> Wrapped. 
> 

We're there, almost... Last question: Do you want to change the license
of debian/* also to MIT and GPL-3 (without later)?

Tobi


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#757966: RFS: lutris/0.3.4-1 [ITP]

[Pierre Rudloff]

Thanks for your help. I have updated the package on mentors.

1. Done.

2.
- Done.
- Done.
- Done.
- My work is now on GitHub: https://github.com/Rudloff/lutris-debian
GitHub uses the same URL for browser and git clone, you should I still 
fill both fields?
	- You can manually add to your Lutris library any game that can be 
installed on your computer (either natively or with Wine). Do you think 
the description can be misleading?

- Are you talking about game platforms? I've added a list of those.

3.
- I am not sure I understand. It does use the 1.0 format.
	- Where should I list the upstream authors? I don't see a field for 
this in the 1.0 format.


4. For some reason, help2man adds this statement at the end of every man 
page it generates. I removed it. I have also documented the different 
ways to install a game.


5. Lintian was complaining that the package did not include any upstream 
changelog so I added one from the upstream debian directory (oddly, I 
only contained information about the software itself and not the 
packaging). Anyway, I removed it.


6. I have added a generic README.source about quilt. Is this OK?

Please tell me if I did anything wrong. Thanks.

Regards,

Le 16/09/2014 15:59, Eriberto a écrit :

Hi Pierre,

Thanks for your fast reply. I will try help you.

1. d/changelog: please, use 'Initial release' instead of 'source
package automatically created by stdeb 0.6.0+git'.

2. d/control:
  - Change the Priority from extra to optional[1].
  - The upstream INSTALL file says that you must use Python 2.7.
So, change from 'python (<< 2.8), python (>= 2.7)' to 'python' in
Build-Depends and remove from Depends. The X-Python-Version field is
used to notify the system about the correct version to be used.
  - The same problem with X-Python-Version. Use 'X-Python-Version:
2.7'. More details here[2].
  - Please, create a VCS to control your debian/ versions. You can
use github or other. So, add the Vcs-Browser and Vcs-{Git|Svn|Cvs} to
d/control. You can see an example here[3].
  - In short description, is right the afirmation 'any video game'?
Is it real?
  - In long description, remove extra spaces in last three lines. I
saw in upstream site (GitHub) a list about some games that can be used
with lutris. To improve your long description and allow more people to
find your package via apt-cache search, I suggest add a list of
possible games.

[1] https://www.debian.org/doc/manuals/maint-guide/dreq.en.html#control
[2] 
https://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-specifying_versions
[3] 
http://sources.debian.net/src/yowsup/0.0~git20140314.938cf1-1/debian/control/

3. d/copyright: you should use the 1.0 format. Please, read this short
document[4] and fix this file.

[4] https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

Other comment is that you must to list all upstream authors and
licenses in d/copyright.

4. d/lutris.6: I asked: "Where I can find the 'info' manual of the
game?", because your manpage says: "The full documentation for lutris
is maintained as a Texinfo manual.  If the info and lutris programs
are properly installed at your site, the command 'info lutris' should
give you access to the complete manual."

I would appreciate it if you put an example of installation of the
game in manpage (the complete line command).

5. d/rules:
 - Please, remove all comments.
 - Why you are installing a changelog from Ubuntu (made by
upstream)? Please, remove it and the file ChangeLog.

6. Add a d/README.source file saying about the changes need in
upstream tarball to generate the package.

Thanks for your work. I will wait your package.

Cheers,

Eriberto


2014-09-15 19:52 GMT-03:00 Pierre Rudloff :

Hello,

Sorry, I thought it was better to reuse an existing package.
I have rebuilt it from scratch: http://mentors.debian.net/package/lutris

Here are the answers to your questions:
1. It does not use it anymore.
2. I have set it to 9, which seems to be the current level.
3. It isn't a game but a game manager, so isn't a man page enough?
4. It has one now.
5. I think it should be in main, as it complies with the DFSG and does not
rely on non-free packages.

Regards,


Le 15/09/2014 22:22, Eriberto a écrit :


Hi Pierre,

I checked your package and you are using/cloning the original upstream
packaging.

To put a package in Debian you must remove the debian/ directory from
upstream source code and generate a new tarball. So, you must start a
new Debian package. You can use some ideas from upstream, not clone
the code only.

I would like you to answer some questions:

1. Why the package is using CDBS?

2. What is the current DH level?

3. Where I can find the 'info' manual of the game?

4. Why the package hasn't a X-Python-Version field?

5. Your package must be main, contrib or non-free? Why?

If your want to put a package in Debian, you must have suffici

Bug#742409: [Sereal] 2.06 fails to build on some architectures: (#47)

[Niko Tyni]

(Cc'ing Yves instead of the scary github address as he
 explicitly asked for that in the upstream ticket.)

On Wed, Jul 16, 2014 at 05:06:29PM +0200, gregor herrmann wrote:
> On Tue, 15 Jul 2014 13:03:56 -0700, Yves Orton wrote:

> > This is so frustrating. Is there anyone in the Debian community that knows
> > these platforms that can help?
> 
> Hm, probably but I'm not sure who knows about all of them.
> Cc'ing the Debian bug report.

Hi, I looked at the Sereal-Encoder problems briefly. The current state
with Debian libsereal-encoder-perl 3.002-1 (unpatched 3.002) is that it
only fails on 64-bit big-endian architectures (s390x and powerpc64).

The failures are all in t/700_roundtrip/ with the snappy tests, and
involve array refs and long strings. I was able to reduce at least one
of them to this:

  #!/usr/bin/perl -w
  use blib;
  use Sereal::Decoder;
  use Sereal::Encoder;
  my $opt = { snappy => 1, use_protocol_v1 => 1};
  
  my $len = shift || 509;
  
  my $s="A"x$len;
  my $e =  Sereal::Encoder->new($opt)->encode([$s, $s]);
  my $d =  Sereal::Decoder->new($opt)->decode($e);
  
  # print $e;
  print "" . ($d->[0] eq $s ? "" : "not ") . "ok 1 first element\n";
  print "" . ($d->[1] eq $s ? "" : "not ") . "ok 2 second element\n";
 
which gives "not ok 2" on s390x when the length is 509 or greater.

The problem is with the encoder: amd64 and s390x encoded contents differ,
and feeding the amd64 encoded output to an s390x decoder works fine.
The second element of the decoded array is just the string "3" in the
incorrect case.

I see the length of the encoded output shortens dramatically at the 508 ->
509 step, looks like some compression kicks in.

I'm attaching the binary output from both s390x (incorrect) and amd64
(correct) for reference for length==509. Hope they make it through,
the md5sums should be

 8787f3dd9a3bfa23bd91eb08c40f3716  509.amd64
 276cbe59ce957915cc92b52fb0b7b51c  509.s390x

All this makes me think that the problem is in snappy/csnappy_compress.c,
but I haven't really delved into it yet.

Hope this helps. Yves, please let me know if I can help in any way.
-- 
Niko Tyni   nt...@debian.org


509.amd64
Description: Binary data


509.s390x
Description: Binary data

Bug#761909: systemd does not unmount nfs shares before bringing down the network interface

[Michael Biebl]

Am 16.09.2014 um 20:15 schrieb Giuseppe Bilotta:
> Package: systemd
> Version: 215-4
> Severity: normal
> 
> 
> My fstab includes the line
> 
> labrador:/oneforall /oneforallnfs auto,exec   0   0
> 
> and the nfs share is automatically mounted when a network interface that
> can resolve `labrador` is brought up. I don't use NM nor wicd, so I
> bring the network interfaces up myself, typically with something like:
> 
> sudo ifup wlan0=home
> 
> However, when the network is brought down (manually, or automatically
> during system shutdown), the mountpoint is not unmounted, causing a
> number of issues.
> 
> Most significantly, if I shutdown the system after bringing up the
> network, the shutdown process will hang while waiting for the
> un-mounting of /oneforall, which cannot happen because the network has
> been automatically brought down already earlier in the shutdown process.


What/which service is responsible for bringing down the network?


-- 
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#761912: littler: built with -march=native

[Dirk Eddelbuettel]

On 16 September 2014 at 20:33, Aurelien Jarno wrote:
| Package: littler
| Version: 0.2.0-1
| Severity: serious
| 
| littler is built using the -march=native GCC option. Besides the fact
| the that it is not something supported on all architectures, it means
| the package requires at least the same instruction set as the machine
| used to build the package. It's not something acceptable for a Debian
| package.

Good point. 

Being "upstream", I am actually putting this is in via configure.ac as a
default, and then just use a two-line debian/rules which does not override
it. 

Will address it in debian/rules.

Thanks,  Dirk
 
 
| -- System Information:
| Debian Release: jessie/sid
|   APT prefers unstable
|   APT policy: (500, 'unstable'), (1, 'experimental')
| Architecture: amd64 (x86_64)
| Foreign Architectures: i386
| 
| Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
| Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
| Shell: /bin/sh linked to /bin/bash

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org