Bug#799494: kalgebra: FTBFS: Missing Build-Depends on libsoprano-dev

[Chris Lamb]

Source: kalgebra
Version: 4:4.14.2-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

kalgebra fails to build from source due to missing Build-Depends on
libsoprano-dev. This was previously pulled-in via a transitive
relationship.


Regards,

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

Bug#799492: eqonomize: FTBFS: Missing Build-Depends on libsoprano-dev

[Chris Lamb]

Source: eqonomize
Version: 0.6-7
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

eqonomize fails to build from source due to missing Build-Depends on
libsoprano-dev. This was previously pulled-in via a transitive
relationship.


Regards,

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

Bug#799493: k3b: FTBFS: Missing Build-Depends on libsoprano-dev

[Chris Lamb]

Source: k3b
Version: 2.0.2-8
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

k3b fails to build from source due to missing Build-Depends on
libsoprano-dev. This was previously pulled-in via a transitive
relationship.


Regards,

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

Bug#796535: libmodule-starter-plugin-cgiapp-perl: diff for NMU version 0.42-1.1

[gregor herrmann]

On Sat, 19 Sep 2015 15:13:32 -0400, Jaldhar H. Vyas wrote:

> >I've prepared an NMU for libmodule-starter-plugin-cgiapp-perl (versioned as 
> >0.42-1.1) and
> >uploaded it to DELAYED/5. Please feel free to tell me if I
> >should delay it longer.
> Thanks for the NMU.  I'm also the upstream for this package and I've been
> preparing a new version that deals with this bug.  But I also had an issue
> with Windows I wanted to fix and I only just solved it.  I'll put out a new
> version today and then update the Debian package.

Excellent, that's a better way forward of course :)

Cheers,
gregor, cancelling the NMU

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Bettina Wegner: Blues vom eigenen Begräbnis


signature.asc
Description: Digital Signature

Bug#799491: choqok: FTBFS: Missing Build-Depends on libsoprano-dev

[Chris Lamb]

Source: choqok
Version: 1.5-2
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

choqok fails to build from source due to missing Build-Depends on
libsoprano-dev. This was previously pulled-in via a transitive
relationship.


Regards,

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

Bug#799523: zanshin: FTBFS: Missing Build-Depends on libsoprano-dev

[Chris Lamb]

Source: zanshin
Version: 0.2.1-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

zanshin fails to build from source due to missing Build-Depends on
libsoprano-dev. This was previously pulled-in via a transitive
relationship.


Regards,

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

Bug#799521: umbrello: FTBFS: Missing Build-Depends on libsoprano-dev

[Chris Lamb]

Source: umbrello
Version: 4:4.14.2-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

umbrello fails to build from source due to missing Build-Depends on
libsoprano-dev. This was previously pulled-in via a transitive
relationship.


Regards,

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

Bug#799522: webkitkde: FTBFS: Missing Build-Depends on libsoprano-dev

[Chris Lamb]

Source: webkitkde
Version: 1.3.4-2
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

webkitkde fails to build from source due to missing Build-Depends on
libsoprano-dev. This was previously pulled-in via a transitive
relationship.


Regards,

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

Bug#793741: (no subject)

[Rob Browning]

> Can this be cherry picked for Debian's emacs24?

Should be in the next upload.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#799527: icedove: intermittent button icon corruption

[Ben Caradoc-Davies]

Package: icedove
Version: 38.1.0-1
Severity: minor

Dear Maintainer,

icedove button icons sometimes become corrupted. The corruption appears to be
triggered by hovering over buttons, causing them to be highlighted; the
corruption occurs when moving away from the button, and then persists. See
attached screenshot. Icons for all active buttons on this row appear to be
affected, but no other icons. These are icons for the GNOME theme. Workaround
is to restart icedove.

Kind regards,
Ben.



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

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

Versions of packages icedove depends on:
ii  debianutils   4.5.1
ii  fontconfig2.11.0-6.3
ii  libasound21.0.29-1
ii  libatk1.0-0   2.16.0-2
ii  libc6 2.19-20
ii  libcairo2 1.14.2-2
ii  libdbus-1-3   1.10.0-3
ii  libdbus-glib-1-2  0.102-1
ii  libevent-2.0-52.0.21-stable-2
ii  libffi6   3.2.1-3
ii  libfontconfig12.11.0-6.3
ii  libfreetype6  2.6-1
ii  libgcc1   1:5.2.1-17
ii  libgdk-pixbuf2.0-02.31.7-1
ii  libglib2.0-0  2.44.1-1.1
ii  libgtk2.0-0   2.24.28-1
ii  libhunspell-1.3-0 1.3.3-3+b1
ii  libicu55  55.1-5
ii  libnspr4  2:4.10.9-2
ii  libnss3   2:3.20-1
ii  libpango-1.0-01.36.8-3
ii  libpangocairo-1.0-0   1.36.8-3
ii  libpangoft2-1.0-0 1.36.8-3
ii  libpixman-1-0 0.33.2-2
ii  libsqlite3-0  3.8.11.1-1
ii  libstartup-notification0  0.12-4
ii  libstdc++65.2.1-17
ii  libvpx2   1.4.0-4
ii  libx11-6  2:1.6.3-1
ii  libxcomposite11:0.4.4-1
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.1-2+b2
ii  libxrender1   1:0.9.8-1+b1
ii  libxt61:1.1.4-1+b1
ii  psmisc22.21-2.1
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages icedove recommends:
ii  hunspell-en-us [hunspell-dictionary]  20070829-6
ii  iceowl-extension  38.1.0-1
ii  myspell-en-gb [myspell-dictionary]1:3.3.0-4

Versions of packages icedove suggests:
ii  fonts-lyx 2.1.4-2
ii  libgssapi-krb5-2  1.13.2+dfsg-2

-- no debconf information

Bug#799533: libsoci-dev: soci need a rebuild to work with gcc-5

[Jan Losinski]

Package: libsoci-dev
Version: 3.2.3-1
Severity: grave
Tags: newcomer
Justification: renders package unusable

Dear Maintainer,

Since debian testing changed the default gcc version to 5 the
-dev package is no longer useable with the default gcc. Every
try to compile against the library ends in unresolved symbol:

--
$ cat test.cpp
#include 

int main(int argc, char * args[]) {
soci::session sess("abc");
}
$ g++ -lsoci_core -o foo test.cpp
/tmp/ccn7VKWE.o: In function `main':
test.cpp:(.text+0x4c): undefined reference to
`soci::session::session(std::__cxx11::basic_string const&)'
collect2: error: ld returned 1 exit status
--

This is caused by a ABI change in gcc-5. A possible workaround
is to use the -D_GLIBCXX_USE_CXX11_ABI=0 flag. But this gives
unresolved symbol vor all other libraries that are not backward
compatible. The post at [1] describe the situation more in
detail.

Please rebuild using gcc-5 and upload as new build.

Thanks,
Jan Losinski


[1] http://developerblog.redhat.com/2015/02/05/gcc5-and-the-c11-abi/



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

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

Versions of packages libsoci-dev depends on:
ii  libsoci-core3.23.2.3-1
ii  libsoci-firebird3.23.2.3-1
ii  libsoci-mysql3.2   3.2.3-1
ii  libsoci-odbc3.23.2.3-1
ii  libsoci-postgresql3.2  3.2.3-1
ii  libsoci-sqlite3-3.23.2.3-1

libsoci-dev recommends no packages.

libsoci-dev suggests no packages.

-- no debconf information

Bug#799538: Don't migrate to testing, no maintained

[Mathieu Parent]

Package: shinken-common
Version: 2.0.3-4
Severity: grave

Hello,

Nobody is maintaining actively the package anymore [1].

We won't support it for stretch, but anybody wanting to test it on sid still 
can.

I will fill an RFA too.

Regards

Mathieu Parent

[1]: 
http://lists.alioth.debian.org/pipermail/pkg-shinken-maint/Week-of-Mon-20150914/000273.html

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

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

Bug#799542: Gwenview lost editing capabilities

[Carlos Kosloff]

Package: gwenview
Version: 4:15.08.0-3
Severity: important


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

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

Versions of packages gwenview depends on:
ii  libc6   2.19-20
ii  libexiv2-14 0.25-2
ii  libgcc1 1:5.2.1-17
ii  libjpeg62-turbo 1:1.4.1-2
ii  libkf5activities5   5.13.0-1
ii  libkf5baloo55.13.0-2
ii  libkf5completion5   5.13.0-1
ii  libkf5configcore5   5.13.0-1
ii  libkf5configgui55.13.0-1
ii  libkf5configwidgets55.13.0-2
ii  libkf5coreaddons5   5.13.0-1
ii  libkf5filemetadata3 5.13.0-1
ii  libkf5i18n5 5.13.0-1
ii  libkf5iconthemes5   5.13.0-1
ii  libkf5itemmodels5   5.13.0-1
ii  libkf5itemviews55.13.0-1
ii  libkf5jobwidgets5   5.13.0-1
ii  libkf5kdelibs4support5  5.13.0-3
ii  libkf5kiocore5  5.13.0-1
ii  libkf5kiofilewidgets5   5.13.0-1
ii  libkf5kiowidgets5   5.13.0-1
ii  libkf5notifications55.13.0-1
ii  libkf5parts55.13.0-1
ii  libkf5service5  5.13.0-2
ii  libkf5textwidgets5  5.13.0-1
ii  libkf5widgetsaddons55.13.0-1
ii  libkf5xmlgui5   5.13.0-1
ii  liblcms2-2  2.6-3+b3
ii  libphonon4qt5-4 4:4.8.3-2
ii  libpng12-0  1.2.50-2+b2
ii  libqt5core5a5.4.2+dfsg-9
ii  libqt5gui5  5.4.2+dfsg-9
ii  libqt5opengl5   5.4.2+dfsg-9
ii  libqt5printsupport5 5.4.2+dfsg-9
ii  libqt5svg5  5.4.2-3
ii  libqt5widgets5  5.4.2+dfsg-9
ii  libqt5x11extras55.4.2-2+b1
ii  libstdc++6  5.2.1-17
ii  libx11-62:1.6.3-1
ii  phonon4qt5  4:4.8.3-2

Versions of packages gwenview recommends:
ii  kamera  4:4.14.2-1+b1
ii  kio-extras  4:15.08.0-1

gwenview suggests no packages.

-- no debconf information


Dear maintainer,

I did not do anything special, just tried to edit an image and noticed 
that all the edition capabilties: crop, resize, etc., were gone.

Upgraded to latest version in stretch and same behavior.
Please consider fixing these issues.

--
*Carlos Kosloff*

Bug#729840: Mistake

[Riley Baird]

close 729840
archive 729840
thanks

I accidentally reopened this bug and changed the owner to myself. I had
intended to do this to #728940 instead, but made a typing error.

Bug#792281: texlive-latex-base: not Multi-Arch: foreign

[Johannes Schauer]

Hi Norbert,

Quoting Norbert Preining (2015-09-20 04:20:34)
> On Sun, 20 Sep 2015, Norbert Preining wrote:
> >  /* The size of `long', as computed by sizeof. */
> > -#define SIZEOF_LONG 8
> > +#define SIZEOF_LONG 4
> 
> Concerning this:
> Is there a place to install *arch* dependent header files?

yes, there is /usr/include//

> To explain the situation: The normal texlive installation puts
> the one changing file
> c-auto.h
> into
> usr/lib/kpathsea/c-auto.h
> (not the "lib" part!)
> 
> It seems to be the only file that differs.
> 
> But in my rules file I have:
> # we don't support this kind of arch-separation by now
> mv debian/tmp/usr/lib/kpathsea/c-auto.h 
> debian/tmp/usr/include/kpathsea/

so you could do:

DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
mv debian/tmp/usr/lib/kpathsea/c-auto.h 
debian/tmp/usr/include/$(DEB_HOST_MULTIARCH)/kpathsea/

/usr/include// is already part of the default gcc search path, so
tools should automatically pick up that header from there.

cheers, josch


signature.asc
Description: signature

Bug#798358: cryptmount: fails to install: cryptmount.postinst: deb-systemd-helper: not found

[R.Penney]

cryptmount-5.1-3 is available now at
http://www.rwpenney.org.uk/software/index.html#cryptmount .
I am hoping my sponsor will be able to upload it into Sid soon.

Bug#799542: Gwenview lost editing capabilities

[Carlos Kosloff]

OK, got it, thank you.

*Carlos Kosloff*


On 09/20/2015 12:15 AM, Scott Kitterman wrote:

On Saturday, September 19, 2015 11:47:29 PM Carlos Kosloff wrote:

Package: gwenview
Version: 4:15.08.0-3
Severity: important

...

Dear maintainer,

I did not do anything special, just tried to edit an image and noticed
that all the edition capabilties: crop, resize, etc., were gone.
Upgraded to latest version in stretch and same behavior.
Please consider fixing these issues.

The U/I is somewhat more hidden, but it's there.  Look at the tabs across the
bottom of the left side of the gwenview window and check operations.  All the
edit choices are there and I tested cropping and it works just fine.

Scott K

Bug#798809: [libreoffice-impress] Deleting and pasting slides in Impress trigger 100% CPU and freeze UI

[Michael Johnson]

On Sun, 13 Sep 2015 21:56:14 +0200 Chris Halls wrote:
> Hi Michael
>
> On 13/09/15 08:56, Michael Johnson wrote:
> > I've reduced the document to a seemingly minimum number of slides, but
> > it's still 13MiB on disk. If it's ok to upload something of that size
> > here, I will do so.
>
> Thanks for the report. I've not been able to reproduce the problem here
> without the document, so it would be useful to see the document. I can't
> find any documented limits to attachment sizes in Debian's bug system,
> but you could try emailing it to me, or sharing with me via Google drive
> or Dropbox or similar.
>
> Thanks
> Chris

Well, I kept thinking I had uploaded it but hadn't. Today brought a 
LibreOffice update and now everything works fine! Didn't see anything in 
the change log that would indicate a problem (except maybe disabling 
GTK3), but it works now. And other problems I was having (like drag and 
drop and a visible progress bar when saving) are fixed as well. Maybe it 
was disabling GTK3.


So YAY!

Thanks,
Michael


--
*Michael /redbeard/ Johnson*
/or someone like him/

Bug#799532: aptitude: typing Ctrl-L during an upgrade puts aptitude in background

[Manuel A. Fernandez Montecelo]

Control: tags -1 + unreproducible


2015-09-19 23:52 Vincent Lefevre:

Package: aptitude
Version: 0.7.1-1
Severity: important

During an upgrade from the aptitude UI, I got:

Configuration file '/etc/lightdm/lightdm.conf'
==> Modified (by you or by a script) since installation.
==> Package distributor has shipped an updated version.
  What would you like to do about it ?  Your options are:
   Y or I  : install the package maintainer's version
   N or O  : keep your currently-installed version
 D : show the differences between the versions
 Z : start a shell to examine the situation
The default action is to keep your current version.
*** lightdm.conf (Y/I/N/O/D/Z) [default=N] ?

I typed 'D', then in the pager, I typed Ctrl-L to refresh.
But this put aptitude and its descendents in background, and
I got the shell prompt.


I cannot reproduce with these steps and also 0.7.1-1.



zira:~> pstree -ap 29204
bash,29204
 └─aptitude,29206
 ├─(dpkg,29277)
 ├─dpkg,30424 --status-fd 76 --configure geoclue-2.0:amd64 ...
 │   └─sh,30438 -c...
 │   └─less,30440 -Lis
 └─{aptitude},29491

I had to kill the processes manually, then do "dpkg --configure -a".


Out of curiosity, what happens if you send SIGCONT instead of killing?


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#799537: RM: shinken-module-simple-log -- ROM; Replaced by shinken-mod-simple-log

[Mathieu Parent]

Package: ftp.debian.org
Severity: normal

Hello,

This package was forgotten during th shinken 2.0 transition, when all 
shinken-module-... where rename shinken-mod-...

Please remove it from the archive.

Regards

Mathieu Parent

Bug#792281: texlive-latex-base: not Multi-Arch: foreign

[Norbert Preining]

Hi all,

On Sun, 20 Sep 2015, Norbert Preining wrote:
>  /* The size of `long', as computed by sizeof. */
> -#define SIZEOF_LONG 8
> +#define SIZEOF_LONG 4

Concerning this:
Is there a place to install *arch* dependent header files?

To explain the situation: The normal texlive installation puts
the one changing file
c-auto.h
into
usr/lib/kpathsea/c-auto.h
(not the "lib" part!)

It seems to be the only file that differs.

But in my rules file I have:
# we don't support this kind of arch-separation by now
mv debian/tmp/usr/lib/kpathsea/c-auto.h debian/tmp/usr/include/kpathsea/

The reason is that many packages build-dep on libkpathsea-dev and
do *not* find the /usr/lib/kpathsea/c-auto.h and FTBFS.

I *could* do the following to achieve more M-A compatibility:
* ship the c-auto file in the libkpathsea6 together with the shlibs
* put it, as installed by texlive, into
/usr/lib//kpathsea/c-auto.h
* adjust the kpathsea.pc config file so that pkg-config --cflags
  adds this path and 
#include 
  again works.

But AFAIR putting .h below /usr/lib/ is forbidden in Debian.

What do you advise here?


Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13

Bug#799489: emacs24-lucid fails to start from fullscreened client in i3

[David Bremner]

Package: emacs24-lucid
Version: 24.5+1-1
Severity: normal

start an xterm/urxvt in i3. full screen it. Attempt to launch emacs
from within this terminal window. Instead of launching, I get

X protocol error: BadValue (integer parameter out of range for operation) on 
protocol request 12

I guess this might be a bug in i3, but emacs24 (gtk) doesn't have this
problem, so it looks like it might be client/toolkit specific.

As a data point, I get a similar failure trying to start xterm

xterm: warning, error event received:
X Error of failed request:  BadValue (integer parameter out of range for 
operation)
  Major opcode of failed request:  12 (X_ConfigureWindow)
  Value in failed request:  0x0
  Serial number of failed request:  994
  Current serial number in output stream:  1003

On the other hand urxvt starts up fine. I suppose if this bug is not
re-assigned to i3, I'll also report the xterm bug.

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

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

Versions of packages emacs24-lucid depends on:
ii  emacs24-bin-common 24.5+1-1
ii  libacl12.2.52-2
ii  libasound2 1.0.29-1
ii  libc6  2.19-20
ii  libcairo2  1.14.2-2
ii  libdbus-1-31.10.0-2
ii  libfontconfig1 2.11.0-6.3
ii  libfreetype6   2.6-1
ii  libgdk-pixbuf2.0-0 2.31.5-1
ii  libgif44.1.6-11
ii  libglib2.0-0   2.44.1-1.1
ii  libgnutls-deb0-28  3.3.17-1
ii  libgomp1   5.2.1-17
ii  libgpm21.20.4-6.1+b2
ii  libice62:1.0.9-1+b1
ii  libjpeg62-turbo1:1.4.1-2
ii  libm17n-0  1.7.0-1
ii  libmagickcore-6.q16-2  8:6.8.9.9-5.1+b1
ii  libmagickwand-6.q16-2  8:6.8.9.9-5.1+b1
ii  libotf00.9.13-2
ii  libpng12-0 1.2.50-2+b2
ii  librsvg2-2 2.40.10-1
ii  libselinux12.3-2+b1
ii  libsm6 2:1.2.2-1+b1
ii  libtiff5   4.0.5-1
ii  libtinfo5  6.0+20150810-1
ii  libx11-6   2:1.6.3-1
ii  libxext6   2:1.3.3-1
ii  libxft22.3.2-1
ii  libxinerama1   2:1.1.3-1+b1
ii  libxml22.9.1+dfsg1-5
ii  libxmu62:1.1.2-1
ii  libxpm41:3.5.11-1+b1
ii  libxrandr2 2:1.5.0-1
ii  libxrender11:0.9.8-1+b1
ii  libxt6 1:1.1.4-1+b1
ii  xaw3dg 1.5+E-18.2
ii  zlib1g 1:1.2.8.dfsg-2+b1

emacs24-lucid recommends no packages.

Versions of packages emacs24-lucid suggests:
pn  emacs24-common-non-dfsg  

-- no debconf information

Bug#799487: pkg-perl-autopkgtest: saner configuration file hierarchy

[gregor herrmann]

On Sat, 19 Sep 2015 21:14:44 +0300, Niko Tyni wrote:

> There's unfortunately little logic to the naming of the configuration
> files. We currently have at least
> 
>  debian/tests/pkg-perl/SKIP
>  debian/tests/pkg-perl/skip-smoke
>  debian/tests/pkg-perl/test-files
>  debian/tests/pkg-perl/module-name
>  debian/tests/pkg-perl/skip-syntax
>  debian/tests/pkg-perl/env-smoke
> 
> with more to come (see #799486).

Hm, I'm quite used to the not-so-logic files by now but ...
 
> Possibly organizing the files by subtest would be cleaner, maybe
> something like
> 
>  debian/tests/pkg-perl/SKIP
>  debian/tests/pkg-perl/smoke/SKIP
>  debian/tests/pkg-perl/smoke/files
>  debian/tests/pkg-perl/smoke/env
>  debian/tests/pkg-perl/syntax/SKIP

.. I agree that this would be more elegant.
 
> I suppose this would need a transition where the scripts would look in
> the old locations for a while, possibly forever. 

I don't think so.
I guess almost all of the packages are team-maintained (or maintained
by team members -- I think Axel uses the tests elsewhere as well), so
a transition with a mass commit/upload doesn't sounds too crazy to
me.

> Not sure if the gain
> is worth the complications, but filing this at least for future reference.

I'm also not sure if it's worth the effort but I think is doable if
we want it to happen.


Cheers,
gregor

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Peter Ratzenbeck: As I Roved Out


signature.asc
Description: Digital Signature

Bug#799509: kraft: FTBFS: Missing Build-Depends on libsoprano-dev

[Chris Lamb]

Source: kraft
Version: 0.55-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

kraft fails to build from source due to missing Build-Depends on
libsoprano-dev. This was previously pulled-in via a transitive
relationship.


Regards,

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

Bug#799512: ktp-common-internals: FTBFS: Missing Build-Depends on libsoprano-dev

[Chris Lamb]

Source: ktp-common-internals
Version: 0.9.0-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

ktp-common-internals fails to build from source due to missing
Build-Depends on libsoprano-dev. This was previously pulled-in via a
transitive relationship.


Regards,

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

Bug#799513: ktp-text-ui: FTBFS: Missing Build-Depends on libsoprano-dev

[Chris Lamb]

Source: ktp-text-ui
Version: 0.9.0+dfsg-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

ktp-text-ui fails to build from source due to missing Build-Depends on
libsoprano-dev. This was previously pulled-in via a transitive
relationship.


Regards,

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

Bug#799524: multiple security issues

[Vincent Fourmond]

Package: src:imagemagick
Version: 8:6.8.9.9-5
Severity: serious
Tags: security

  Current version of imagemagick in stable/unstable is affected by
multiple security bugs:

- A DOS on specially crafted MIFF file (TEMP-000-FDAC72).
- A DOS on specially crafted Vicar file (TEMP-000-EEF23C).
- A DOS on specially crafted HDR file (TEMP-000-7C079F).
- A DOS on specially crafted PDB file (TEMP-000-2FC21E).
- Avoid a null pointer dereference in JNG decoder.
- Avoid a DOS for RLE file.
- Avoid double free on TGA file.
- Avoid a bufer overflow by using field limit in sprintf.
- Avoid a stack overflow in fx handling.

  More info there:

https://bugs.launchpad.net/ubuntu/+source/imagemagick/+bug/1490362

  This bug report is just for tracking.

   Vincent


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

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

Bug#799529: RFS: shc/3.8.9b-1 new upstream release

[Tong Sun]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: shc
   Version : 3.8.9b-1
   Upstream Author : Francisco Rosales .
 * URL : http://www.datsi.fi.upm.es/~frosal/
 * License : GPL-2.0
   Section : devel


It builds those binary packages:

shc   - Generic shell script compiler

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

  http://mentors.debian.net/package/shc

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

dget -x http://mentors.debian.net/debian/pool/main/s/shc/shc_3.8.9b-1.dsc

Changes since the last upload:

   * New upstream release
   * Updated Standard-version to 3.9.6.
   * redo the makefile patching from scratch

More information about changes can be obtained from
https://github.com/suntong/shc-build/commits/master


Regards,

Tong Sun

Bug#576319: aptitude: "Cancel pending actions" erase "h - hold" state

[Manuel A. Fernandez Montecelo]

Control: tags -1 + moreinfo


2010-04-03 04:09 Osamu Aoki:

Package: aptitude
Version: 0.6.1.5-3
Severity: normal

I am not C++ coder but src/cmdline/cmdline_do_action.cc line 299 is where
problem comes from.

Please read on.

When I set a lower priority version in hold using =, I expect that
settig to live future package install actions unless specifically requested to
be removed.  Aptitude menu suggest so.

 "=":  Hold a package in its current version to prevent upgrades.
 ":":  Keep a package at its current version.  Unlike hold, this
   will not prevent future upgrades.

But "Actions" -> "Cancel pending actions" reset this frag too.  (The same goes 
to
keep-all for command line. It resets "State: installed [held]" to "State: 
installed".)

This menu entry is frequently used to revert suggested "dependencies" upon
starting interactive session or "aptitude install".


Note that the help that appears in the bottom of the screen when you
"hover" over that option in the menu is:

 "Cancel all pending installations, removals, holds, and upgrades."

I do not have a strong preference, and there is some sense in what you
say, but it seems that this has been done on purpose and by design.

(As a data point, I almost never used this option, BTW).


One thing to take into account is that in the command line there are
ways to mass-apply changes to packages (combinations of hold, unhold,
keep and keep-all, with patterns).  One can easily apply "keep" (==
reset pending install/upgrade/removal state) to packages which are not
already on hold, for example, so avoiding to change the flag of those
packages.

But in the UI, I think that there would be no way to reset the hold
state of all packages on hold, without going one by one and resorting to
the command line.

So if we simply change the menu option without offering alternatives,
maybe some users which already rely on this functionality are not happy.


There are many angles to consider to this question, so it will require
some thought, and review many other bug reports that have requests about
holds first.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#799540: libreoffice-writer: Export to PDF turns comments blank

[Ben Finney]

Package: libreoffice-writer
Version: 1:5.0.1-1
Severity: normal

Dear Maintainer,

When exporting a Writer document to PDF, comments appear as blank
space where the comment box is expected.

The attached document ‘bug-export-comments.odt’ contains two comments.

The following steps were performed to export to PDF:

* Tools → Options → LibreOffice Writer → Comments → In Margins.
* File → Export as PDF → General → Export comments.
  then Export.

The resulting PDF, attached as ‘bug-export-comments.pdf’, has the
normal markers for comments (the icon in the body, the arrow and
dashed line leading to the margin), but the space where the comment
box should be appears entirely blank.


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

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

Versions of packages libreoffice-writer depends on:
ii  libabw-0.1-1   0.1.1-2
ii  libc6  2.19-20
ii  libe-book-0.1-10.1.2-2
ii  libetonyek-0.1-1   0.1.3-1
ii  libgcc11:5.2.1-17
ii  libicu55   55.1-5
ii  libmwaw-0.3-3  0.3.6-1
ii  libodfgen-0.1-10.1.4-1
ii  libreoffice-base-core  1:5.0.1-1
ii  libreoffice-core   1:5.0.1-1
ii  librevenge-0.0-0   0.0.2-2
ii  libstdc++6 5.2.1-17
ii  libwpd-0.10-10 0.10.0-2+b1
ii  libwpg-0.3-3   0.3.0-3
ii  libwps-0.4-4   0.4.0-2
ii  libxml22.9.1+dfsg1-5
ii  uno-libs3  5.0.1-1
ii  ure5.0.1-1
ii  zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages libreoffice-writer recommends:
ii  libreoffice-math  1:5.0.1-1

Versions of packages libreoffice-writer suggests:
ii  default-jre [java5-runtime]2:1.7-52
ii  fonts-crosextra-caladea20130214-1
ii  fonts-crosextra-carlito20130920-1
ii  libreoffice-base   1:5.0.1-1
pn  libreoffice-gcj
ii  libreoffice-java-common1:5.0.1-1
ii  openjdk-7-jre [java5-runtime]  7u85-2.6.1-3

Versions of packages libreoffice-core depends on:
ii  fontconfig2.11.0-6.3
ii  fonts-opensymbol  2:102.6+LibO5.0.1-1
ii  libatk1.0-0   2.16.0-2
ii  libboost-date-time1.58.0  1.58.0+dfsg-3
ii  libc6 2.19-20
ii  libcairo2 1.14.2-2
ii  libclucene-contribs1v52.3.3.4-4.1
ii  libclucene-core1v52.3.3.4-4.1
ii  libcmis-0.5-5v5   0.5.0-3
ii  libcups2  2.0.3-10
ii  libcurl3-gnutls   7.44.0-2
ii  libdbus-1-3   1.10.0-2
ii  libdbus-glib-1-2  0.102-1
ii  libeot0   0.01-3
ii  libexpat1 2.1.0-7
ii  libexttextcat-2.0-0   3.4.4-1
ii  libfontconfig12.11.0-6.3
ii  libfreetype6  2.6-1
ii  libgcc1   1:5.2.1-17
ii  libgdk-pixbuf2.0-02.31.5-1
ii  libgl1-mesa-glx [libgl1]  10.6.3-1
ii  libglew1.10   1.10.0-3
ii  libglib2.0-0  2.44.1-1.1
ii  libgltf-0.0-0v5   0.0.2-4
ii  libglu1-mesa [libglu1]9.0.0-2.1
ii  libgraphite2-31.2.4-3
ii  libgtk2.0-0   2.24.28-1
ii  libharfbuzz-icu0  1.0.1-1+b1
ii  libharfbuzz0b 1.0.1-1+b1
ii  libhunspell-1.3-0 1.3.3-3+b1
ii  libhyphen02.8.8-2
ii  libice6   2:1.0.9-1+b1
ii  libicu55  55.1-5
ii  libjpeg62-turbo   1:1.4.1-2
ii  liblangtag1   0.5.1-3
ii  liblcms2-22.6-3+b3
ii  libldap-2.4-2 2.4.42+dfsg-2
ii  libmythes-1.2-0   2:1.2.4-1
ii  libneon27-gnutls  0.30.1-1
ii  libnspr4  2:4.10.9-2
ii  libnspr4-0d   2:4.10.9-2
ii  libnss3   2:3.20-1
ii  libnss3-1d2:3.20-1
ii  libodfgen-0.1-1   0.1.4-1
ii  libpango-1.0-01.36.8-3
ii  libpangocairo-1.0-0   1.36.8-3
ii  libpangoft2-1.0-0 1.36.8-3
ii  libpcre3  2:8.35-7.1
ii  libpng12-01.2.50-2+b2
ii  librdf0   1.0.17-1+b1
ii  libreoffice-common1:5.0.1-1
ii  librevenge-0.0-0  0.0.2-2
ii  libsm62:1.2.2-1+b1
ii  libssl1.0.0   1.0.2d-1
ii  libstdc++65.2.1-17
ii  libx11-6  2:1.6.3-1
ii  libxext6  2:1.3.3-1
ii  libxinerama1  2:1.1.3-1+b1
ii  libxml2   2.9.1+dfsg1-5
ii  libxrandr22:1.5.0-1
ii  libxrender1   1:0.9.8-1+b1
ii  libxslt1.11.1.28-2+b2
ii  libxt61:1.1.4-1+b1
ii  uno-libs3 5.0.1-1
ii  ure   5.0.1-1
ii  zlib1g1:1.2.8.dfsg-2+b1

-- no debconf information

-- 
 \   

Bug#602649: upstream WONTFIX

[Lionel Elie Mamane]

It looks like this bug / feature request will "never" be implemented
upstream... The chromium rendering engine *removed* support, webkit
itself (apparently the source of the feature) followed suit, ...

https://bugs.webkit.org/show_bug.cgi?id=127874


-- 
Lionel

Bug#796535: libmodule-starter-plugin-cgiapp-perl: diff for NMU version 0.42-1.1

[Jaldhar H. Vyas]

On Sat, 19 Sep 2015, gregor herrmann wrote:


Control: tags 796535 + pending

Dear maintainer,

I've prepared an NMU for libmodule-starter-plugin-cgiapp-perl (versioned as 
0.42-1.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.


Hi Gregor,

Thanks for the NMU.  I'm also the upstream for this package and I've been 
preparing a new version that deals with this bug.  But I also had an issue 
with Windows I wanted to fix and I only just solved it.  I'll put out a 
new version today and then update the Debian package.


--
Jaldhar H. Vyas 

Bug#799495: kbibtex: FTBFS: Missing Build-Depends on libsoprano-dev

[Chris Lamb]

Source: kbibtex
Version: 0.4-4
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

kbibtex fails to build from source due to missing Build-Depends on
libsoprano-dev. This was previously pulled-in via a transitive
relationship.


Regards,

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

Bug#799496: kde-baseapps: FTBFS: Missing Build-Depends on libsoprano-dev

[Chris Lamb]

Source: kde-baseapps
Version: 4:15.04.3-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

kde-baseapps fails to build from source due to missing Build-Depends on
libsoprano-dev. This was previously pulled-in via a transitive
relationship.


Regards,

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

Bug#799490: cervisia: FTBFS: Missing Build-Depends on libsoprano-dev

[Chris Lamb]

Source: cervisia
Version: 4:4.14.0-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

cervisia fails to build from source due to missing Build-Depends on
libsoprano-dev. This was previously pulled-in via a transitive
relationship.


Regards,

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

Bug#799149: emacs24: huge character height in file containing U+FB00 LATIN SMALL LIGATURE FF

[Vincent Lefevre]

On 2015-09-19 15:05:54 -0500, Rob Browning wrote:
> Do you see it with "emacs --font 6x13"?

No problems with:

  emacs --font 6x13
  emacs --font "DejaVu Serif"
  emacs --font "DejaVu Sans"
  emacs --font FreeMono

However

  emacs --font "DejaVu Sans Mono"
  emacs --font "Droid Serif"
  emacs --font "Droid Sans"
  emacs --font "Droid Sans Mono"

are incorrect.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#799149: emacs24: huge character height in file containing U+FB00 LATIN SMALL LIGATURE FF

[Vincent Lefevre]

On 2015-09-20 00:35:47 +0200, Vincent Lefevre wrote:
> On 2015-09-19 15:05:54 -0500, Rob Browning wrote:
> > Do you see it with "emacs --font 6x13"?
> 
> No problems with:
> 
>   emacs --font 6x13
>   emacs --font "DejaVu Serif"
>   emacs --font "DejaVu Sans"
>   emacs --font FreeMono
> 
> However
> 
>   emacs --font "DejaVu Sans Mono"
>   emacs --font "Droid Serif"
>   emacs --font "Droid Sans"
>   emacs --font "Droid Sans Mono"
> 
> are incorrect.

When I look with gucharmap, I can see that for "DejaVu Sans Mono",
the glyph is taken from Courier. But for the 3 Droid fonts, it is
taken from "DejaVu Sans", so that this doesn't explain the problem.

And the problem doesn't occur either with: emacs --font Courier

So, it seems that the problem occurs in Emacs only for fonts that
don't have the U+FB00 LATIN SMALL LIGATURE FF glyph.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#797788: gcc5 transition

[Chris Knadle]

micah:
> Chris Knadle  writes:
> 
>> Not yet, no.  Looking at the build logs for mumble, I want to wait for the
>> non-release architectures to have a build attempt, and some of them are
>> still in Dep-Wait.
>>
>> What happened is that after the gcc5 transition was thought to be completed,
>> zeroc-ice was still unpatched, so the build was still broken.  [And in
>> between the gcc-5 transition happened for Stretch.]  zeroc-ice has been
>> fixed now (by the release team), so mumble finally builds again... but not
>> all the architectures have gotten it yet.
> 
> Ok, thanks for the update, sounds reasonable to me!

The build logs for mumble 1.2.8-2+b1 on 6 of the non-release architectures
haven't changed in a few days; mumble 1.2.8-2+b1 should be migrating to
Stretch in a day or so, and at that point it's unclear how long I should
wait further for the non-release architecture builds.

>> I'm currently updating my 1.2.10-1 prepared upload for Debian with a patch
>> for #787384, which I just did for the package in my repo only for Sid,
>> because the new zeroc-ice hasn't transitioned to Stretch yet AFAIK.
> 
> The reason I'm really interested in this is because of the PFS cipher
> support. Unfortunately, it seems like this isn't particularly useful
> unless things are built from the git head at the moment, and maybe that
> support isn't even finished. It would be great if this could be brought
> into the debian packages (even if it might need to be done before 1.3 is
> released), see https://github.com/mumble-voip/mumble/issues/1811

I'm really interested in mumble in terms of encryption/privacy/integrity
too, so I'd love to get PFS support but in reading the bug it looks like
that's not possible for now.  Upstream has specifically requested I only
release the stable 1.2 builds (the non-snapshot+cherry-pick-patches release
for wheezy that Ron Lee made has been particularly painful for upstream) and
avoid uploading any of the 1.3 "snapshot" builds until they release a stable
version, and #1811 above states that the mumble 1.2 releases are bound to Qt
4... and sounds like Qt 4 can't do PFS.

Mumble upstream also have some Qt 4 patches to add TLS 1.1 and 1.2 support,
but the way they work is to redefine QSsl::TlsV1 to mean "TLS 1.0 or later"
and they don't recommend upstream distributions try to use these patches.
This is explained in:

   http://blog.mumble.info/mumble-1-2-9/

The only good news is that with the 1.2.10-1 release I'm about to upload,
the sslCiphers can be specified in the mumble-server.ini file. [That's
probably important enough that I should add a note about this to the NEWS file.]


BTW: in the "Advanced" settings under "Network" in the mumble client you can
use "Force TCP mode" so that mumble could be used over Tor and then starting
mumble in a terminal with 'torify mumble'.  [That works! :-)]


Re: integrity: a while ago I changed the the debian/watch file to have uscan
check OpenPGP signatures of the upstream releases.  And with 1.2.10-1 I'm
switching debian/rules to 'dh' in an effort to get reproducible builds.

>>> I'd really like this available as a jessie backport, so I'd love to see
>>> it transition soon!
>>
>> I'm not pleased with the way backports currently work; bugs for packages
>> from a backport aren't supposed to get reported to the normal BTS but
>> instead a [debian-backports] mailing list.  That's commonly confusing for
>> both users and maintainers, and the result is that users report the bug to
>> the BTS and maintainers have to close those reports and tell those users to
>> report the bug to a mailing list.  :-(  This also recently came up
>> concerning the PPA/bikesheds plan because it sounds like that's likely to
>> have the same issue with BTS integration.
> 
> This is a problem with the bug reporting path for backports, I
> agree. However, I dont think that this particular bug means that
> backports aren't useful, in fact they are incredibly indispensable for
> us, just that the bug reporting path is a bit annoying. I dont think
> that this should preclude backports from existing.

I agree that having backports available is very important, I'm just not sure
what advantage there is for a maintainer in having them at
backports.debian.org.  Right now backports.d.o is treated as an external
repository as far as the BTS is concerned, and AFAIK that's what's going to
happen with the PPA/bikesheds too, as well as all other external repos.  In
talking with several DDs at DC15 it's quite clear that external repos are
the only way that an actual "PPA" implementation is ever going to happen.

What I see some external repos do is add a "Bugs: " line to
the debian/control file for the source package (but not the binary
packages), but AFAICT the bug reporting tools don't use this, and there is
no Bugs: field listed for the control file in the Debian Policy Manual.

I guess it's time to try to discuss this on -devel, -qa, -policy, -project,
etc because we 

Bug#799532: aptitude: typing Ctrl-L during an upgrade puts aptitude in background

[Vincent Lefevre]

On 2015-09-20 01:25:50 +0100, Manuel A. Fernandez Montecelo wrote:
> I cannot reproduce with these steps and also 0.7.1-1.

I can no longer reproduce.

> >zira:~> pstree -ap 29204
> >bash,29204
> > └─aptitude,29206
> > ├─(dpkg,29277)
> > ├─dpkg,30424 --status-fd 76 --configure geoclue-2.0:amd64 ...
> > │   └─sh,30438 -c...
> > │   └─less,30440 -Lis
> > └─{aptitude},29491

There was a zombie dpkg process that was a child of aptitude.
Where did it come from?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#799543: dh_doxygen: fails if no docs found, even in binary-only builds

[Aaron M. Ucko]

Package: doxygen
Version: 1.8.9.1-5
Severity: important

Builds of signond covering only its architecture-dependent binary
packages (as on the autobuilders) have been failing:

  dh_doxygen
  dh_doxygen: Doxygen documentation not found
  make[2]: *** [override_dh_install] Error 2

I presume this error represents an intended sanity check, which could
be helpful in some circumstances.  However, the typical dh_*
convention is to treat having nothing to do as a (trivial) success
rather than a failure.  This convention is particularly appropriate
here, because many source packages (signond included) split
documentation into architecture-independent binary packages that not
all builds cover.

As such, please either downgrade this error to a warning or suppress
it altogether, at least in the case of builds covering only a subset
of possible binary packages.

See also sphinx-common bug https://bugs.debian.org/745690.

Thanks!

Bug#758047: open last session doesn't

[Sergio Durigan Junior]

On Wednesday, August 13 2014, 積丹尼 Dan Jacobson wrote:

> In the menus:
> Close all windows.
> $ midori #again
> Open Last session
>
> There is nothing now.

Hi,

Do you still see this bug?  I could not reproduce it here with 0.5.11-2.

Thanks,

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


signature.asc
Description: PGP signature

Bug#799076: Reproducing

[Chris Lamb]

Hey Jelmer,

> Ah, thanks. I've managed to reproduce it now - I had to enable the
> translation strings for ch_FR.UTF-8 for C git.

Great stuff. And other locales? I just tried that one.
 
> > Saying *that* I can't actually reproduce right this second in current
> > sid even under a "vanilla" locale as I'm FTBFS with:
[..]
> This is a regression in pypy-dev 2.6.1+dfsg-1.  I've filed
> http://bugs.debian.org/799485

Ah, good spot. Too many similar paths for my eyes :)


Regards,

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

Bug#799076: Reproducing

[Jelmer Vernooij]

Hey Chris,

On Sat, Sep 19, 2015 at 08:03:18PM +0100, Chris Lamb wrote:
> > Ah, thanks. I've managed to reproduce it now - I had to enable the
> > translation strings for ch_FR.UTF-8 for C git.
> Great stuff. And other locales? I just tried that one.
Dulwich runs some tests against C git (to verify compatibility) and
then greps its output for certain output. This is not ideal, but
the best way I've found so far to verify we produce files that C git
can handle.

I've modified the code to always pass LANG=C to C git when invoking
it, so that should cover all locales.

Cheers,

Jelmer

-- 
Jelmer Vernooij 
Debian Developer   https://jelmer.uk/


signature.asc
Description: Digital signature

Bug#799520: tellico: FTBFS: Missing Build-Depends on libsoprano-dev

[Chris Lamb]

Source: tellico
Version: 2.3.9+dfsg.1-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

tellico fails to build from source due to missing Build-Depends on
libsoprano-dev. This was previously pulled-in via a transitive
relationship.


Regards,

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

Bug#799517: smb4k: FTBFS: Missing Build-Depends on libsoprano-dev

[Chris Lamb]

Source: smb4k
Version: 1.1.2-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

smb4k fails to build from source due to missing Build-Depends on
libsoprano-dev. This was previously pulled-in via a transitive
relationship.


Regards,

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

Bug#799515: plasma-widget-adjustableclock: FTBFS: Missing Build-Depends on libsoprano-dev

[Chris Lamb]

Source: plasma-widget-adjustableclock
Version: 4.1.4-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

plasma-widget-adjustableclock fails to build from source due to missing
Build-Depends on libsoprano-dev. This was previously pulled-in via a
transitive relationship.


Regards,

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

Bug#799514: pike8.0: FTBFS: Missing Build-Depends on libsoprano-dev

[Chris Lamb]

Source: pike8.0
Version: 8.0.28-3
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

pike8.0 fails to build from source due to missing Build-Depends on
libsoprano-dev. This was previously pulled-in via a transitive
relationship.


Regards,

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

Bug#799516: skrooge: FTBFS: Missing Build-Depends on libsoprano-dev

[Chris Lamb]

Source: skrooge
Version: 1.9.3-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

skrooge fails to build from source due to missing Build-Depends on
libsoprano-dev. This was previously pulled-in via a transitive
relationship.


Regards,

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

Bug#799518: subtitlecomposer: FTBFS: Missing Build-Depends on libsoprano-dev

[Chris Lamb]

Source: subtitlecomposer
Version: 0.5.3-4
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

subtitlecomposer fails to build from source due to missing Build-Depends
on libsoprano-dev. This was previously pulled-in via a transitive
relationship.


Regards,

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

Bug#799519: svgpart: FTBFS: Missing Build-Depends on libsoprano-dev

[Chris Lamb]

Source: svgpart
Version: 4:4.11.3-2
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

svgpart fails to build from source due to missing Build-Depends on
libsoprano-dev. This was previously pulled-in via a transitive
relationship.


Regards,

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

Bug#799149: emacs24: huge character height in file containing U+FB00 LATIN SMALL LIGATURE FF

[Rob Browning]

Vincent Lefevre  writes:

> In a file that contains ff (U+FB00 LATIN SMALL), the character height
> of the line is huge. This can be seen on this file (if the character
> has not been mangled). Otherwise a file with such a character can be
> created with:
>
>   printf "\ufb00\n"
>
> I've attached a screenshot of the Emacs window, with the cursor just
> after the closing parenthesis, so that one can see the mark of the
> matching parentheses.

Interesting.  I wonder if it may be font or GTK+ related.  I don't see
the problem with emacs24-lucid and font "fixed" (i.e. 6x13).

Do you see it with "emacs --font 6x13"?

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#799532: aptitude: typing Ctrl-L during an upgrade puts aptitude in background

[Vincent Lefevre]

Package: aptitude
Version: 0.7.1-1
Severity: important

During an upgrade from the aptitude UI, I got:

Configuration file '/etc/lightdm/lightdm.conf'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
Y or I  : install the package maintainer's version
N or O  : keep your currently-installed version
  D : show the differences between the versions
  Z : start a shell to examine the situation
 The default action is to keep your current version.
*** lightdm.conf (Y/I/N/O/D/Z) [default=N] ? 

I typed 'D', then in the pager, I typed Ctrl-L to refresh.
But this put aptitude and its descendents in background, and
I got the shell prompt.

zira:~> pstree -ap 29204
bash,29204
  └─aptitude,29206
  ├─(dpkg,29277)
  ├─dpkg,30424 --status-fd 76 --configure geoclue-2.0:amd64 ...
  │   └─sh,30438 -c...
  │   └─less,30440 -Lis
  └─{aptitude},29491

I had to kill the processes manually, then do "dpkg --configure -a".

-- Package-specific info:
Terminal: xterm-debian
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.7.1 compiled at Sep  5 2015 23:44:20
Compiler: g++ 5.2.1 20150903
Compiled against:
  apt version 4.16.0
  NCurses version 6.0
  libsigc++ version: 2.4.1
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.0.20150810
  cwidget version: 0.5.17
  Apt version: 4.16.0

aptitude linkage:
linux-vdso.so.1 (0x7ffc9f394000)
libapt-pkg.so.4.16 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.16 
(0x7ffa83481000)
libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 
(0x7ffa83251000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 
(0x7ffa83026000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7ffa82e2)
libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 
(0x7ffa82b21000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7ffa82853000)
libboost_iostreams.so.1.58.0 => 
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.58.0 (0x7ffa8263a000)
libxapian.so.22 => /usr/lib/libxapian.so.22 (0x7ffa82238000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7ffa8201a000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7ffa81c9f000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7ffa8199e000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7ffa81787000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7ffa813de000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7ffa811db000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7ffa80fd6000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7ffa80dbb000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7ffa80bab000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7ffa80987000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7ffa8077f000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7ffa80579000)
/lib64/ld-linux-x86-64.so.2 (0x55b3a45d)

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

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

Versions of packages aptitude depends on:
ii  aptitude-common   0.7.1-1
ii  libapt-pkg4.161.0.10.2
ii  libboost-iostreams1.58.0  1.58.0+dfsg-3
ii  libc6 2.19-20
ii  libcwidget3v5 0.5.17-4
ii  libgcc1   1:5.2.1-17
ii  libncursesw5  6.0+20150810-1
ii  libsigc++-2.0-0v5 2.4.1-2
ii  libsqlite3-0  3.8.11.1-1
ii  libstdc++65.2.1-17
ii  libtinfo5 6.0+20150810-1
ii  libxapian22v5 1.2.21-1.2

Versions of packages aptitude recommends:
ii  aptitude-doc-en [aptitude-doc]  0.7.1-1
ii  libparse-debianchangelog-perl   1.2.0-8
ii  sensible-utils  0.0.9

Versions of packages aptitude suggests:
ii  apt-xapian-index  0.47
pn  debtags   
ii  tasksel   3.33

-- no debconf information

Bug#792281: texlive-latex-base: not Multi-Arch: foreign

[Norbert Preining]

Hi all,

thanks for the great suggestions and guidelines!!

On Fri, 18 Sep 2015, Johannes Schauer wrote:
>  - libkpathsea-dev, libptexenc-dev, libsynctex-dev, libtexlua52-dev,
>libtexluajit-dev carry the development headers and *.a files and a symlink
>to the shared library. *-dev packages are usually marked M-A:same as well
>and thus the same rules apply as for shared libraries: files that in a
>shared location between packages of different architecture must be
>bit-by-bit identical. The risk that they differ is a bit higher here as
>sometimes, headers carry auto-generated architecture specific information.

They are different. Arbitrarily checking mipsel versus amd64 I see:

 /* The size of `long', as computed by sizeof. */
-#define SIZEOF_LONG 8
+#define SIZEOF_LONG 4


...

 /* Number of bits in a file offset, on hosts where this is settable. */
-/* #undef _FILE_OFFSET_BITS */
+#define _FILE_OFFSET_BITS 64



That does mean we cannot share them, right? And as a consequence the
-dev
packages have to be M-A: 

MOre later ...

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13

Bug#799536: ITP: gnome-mpv -- simple GTK+ frontend for mpv

[Ximin Luo]

Package: wnpp
Severity: wishlist
Owner: Ximin Luo 

* Package name: gnome-mpv
  Version : 0.5
  Upstream Author : gnome-mpv 
* URL : https://github.com/gnome-mpv/gnome-mpv
* License : GPL-3+
  Programming Lang: C
  Description : simple GTK+ frontend for mpv

GNOME MPV is a simple GTK+ frontend for mpv. GNOME MPV interacts with mpv via
the client API exported by libmpv, allowing access to mpv's powerful playback
capabilities.

Bug#799539: RFA: shinken

[Mathieu Parent]

Package: wnpp
Severity: normal

Hello,

Nobody is maintaining actively the package anymore [1].

We won't support it for stretch, but keep it in sid (See #799538).

Regards

Mathieu Parent

[1]: 
http://lists.alioth.debian.org/pipermail/pkg-shinken-maint/Week-of-Mon-20150914/000273.html

Bug#687473: must click "Zoom in" twice before anything

[Sergio Durigan Junior]

On Wednesday, September 12 2012, jida...@jidanni.org wrote:

> Certainly you note one has to click "View > Zoom in" twice before anything
> happens.
>
> And CTRL++ doesn't work until then too.

Bug report is a bit confusing, but C-+ seems to be working totally fine
now.  Can you confirm?

Thanks,

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

Bug#781779: [DSE-Dev] Bug#781779: not grave

[Andre Florath]

Hello!

Please note that I'm currently using the latest version of
selinux-policy-default: 2:2.20140421-11

>
> What I really want to know in such cases is whether other desktop 
> environments 
> or other XDM programs work.  If one program breaks it could be an issue with 
> that program.  If multiple programs break it could be something more basic.
> 

Understand you - but I'm only using the default (gnome3).

> 
>> #= alsa_t ==
>>
>> # The source type 'alsa_t' can write to a 'dir' of the following types:
>> # pulseaudio_home_t, alsa_tmp_t, alsa_var_lib_t, var_lock_t, etc_t,
>> tmpfs_t, user_home_dir_t, root_t, tmp_t, user_tmp_t, pulseaudio_tmpfsfile,
>> alsa_etc_rw_t, user_home_t
>>
>> allow alsa_t var_run_t:dir write;
> 
> What is the name of the directory in question?  What is the name of the 
> program running in the alsa_t domain?

It's alsactl:

type=AVC msg=audit(1442688157.512:18): avc:  denied  { write } for  pid=346 
comm="alsactl" name="/" dev="tmpfs" ino=6530 
scontext=system_u:system_r:alsa_t:s0 tcontext=system_u:object_r:var_run_t:s0 
tclass=dir permissive=0
type=SYSCALL msg=audit(1442688157.512:18): arch=c03e syscall=83 success=no 
exit=-13 a0=b737c0 a1=1c0 a2= a3=7f3eca8f4460 items=0 ppid=1 pid=346 
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 
tty=(none) ses=4294967295 comm="alsactl" exe="/usr/sbin/alsactl" 
subj=system_u:system_r:alsa_t:s0 key=(null)


>>
>> allow systemd_logind_t tmpfs_t:dir write;
>> allow systemd_logind_t user_tmpfs_t:dir read;
>> allow systemd_logind_t user_tmpfs_t:file getattr;
>> allow systemd_logind_t xdm_tmpfs_t:dir read;
>> allow systemd_logind_t xdm_tmpfs_t:file getattr;
> 
> What are the names of the directories in question?  Use the -v option to 
> audit2allow.
> 

Here are the AVCs:

type=USER_AVC msg=audit(1442688229.804:280): pid=363 uid=105 auid=4294967295 
ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc:  
denied  { send_msg } for msgtype=signal interface=org.freedesktop.login1.Manager
 member=SessionRemoved dest=org.freedesktop.DBus spid=357 tpid=355 
scontext=system_u:system_r:systemd_logind_t:s0 
tcontext=system_u:system_r:NetworkManager_t:s0 tclass=dbus  
exe="/usr/bin/dbus-daemon" sauid=105 hostname=? addr=? termina
l=?'
type=USER_AVC msg=audit(1442688229.836:281): pid=1 uid=0 auid=4294967295 
ses=4294967295 subj=system_u:system_r:init_t:s0 msg='Unknown permission stop 
for class system exe="/lib/systemd/systemd" sauid=0 hostname=? addr=? 
terminal=?'
type=AVC msg=audit(1442688229.848:283): avc:  denied  { read } for  pid=357 
comm="systemd-logind" name="gnome-shell" dev="tmpfs" ino=15030 
scontext=system_u:system_r:systemd_logind_t:s0 
tcontext=system_u:object_r:xdm_tmpfs_t:s0 tclass=d
ir permissive=0
type=SYSCALL msg=audit(1442688229.848:283): arch=c03e syscall=257 
success=no exit=-13 a0=15 a1=7f2b62a19d03 a2=f0800 a3=0 items=0 ppid=1 pid=357 
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 
tty=(none) ses=
4294967295 comm="systemd-logind" exe="/lib/systemd/systemd-logind" 
subj=system_u:system_r:systemd_logind_t:s0 key=(null)
type=PROCTITLE msg=audit(1442688229.848:283): 
proctitle="/lib/systemd/systemd-logind"
type=AVC msg=audit(1442688229.848:284): avc:  denied  { read } for  pid=357 
comm="systemd-logind" name="pulse" dev="tmpfs" ino=14796 
scontext=system_u:system_r:systemd_logind_t:s0 
tcontext=system_u:object_r:xdm_tmpfs_t:s0 tclass=dir per
missive=0
type=SYSCALL msg=audit(1442688229.848:284): arch=c03e syscall=257 
success=no exit=-13 a0=15 a1=7f2b62a19d23 a2=f0800 a3=0 items=0 ppid=1 pid=357 
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 
tty=(none) ses=
4294967295 comm="systemd-logind" exe="/lib/systemd/systemd-logind" 
subj=system_u:system_r:systemd_logind_t:s0 key=(null)
type=PROCTITLE msg=audit(1442688229.848:284): 
proctitle="/lib/systemd/systemd-logind"
type=AVC msg=audit(1442688229.848:285): avc:  denied  { read } for  pid=357 
comm="systemd-logind" name="dconf" dev="tmpfs" ino=14402 
scontext=system_u:system_r:systemd_logind_t:s0 
tcontext=system_u:object_r:xdm_tmpfs_t:s0 tclass=dir per
missive=0
type=SYSCALL msg=audit(1442688229.848:285): arch=c03e syscall=257 
success=no exit=-13 a0=15 a1=7f2b62a19d43 a2=f0800 a3=0 items=0 ppid=1 pid=357 
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 
tty=(none) ses=
4294967295 comm="systemd-logind" exe="/lib/systemd/systemd-logind" 
subj=system_u:system_r:systemd_logind_t:s0 key=(null)
type=PROCTITLE msg=audit(1442688229.848:285): 
proctitle="/lib/systemd/systemd-logind"
type=AVC msg=audit(1442688229.848:286): avc:  denied  { write } for  pid=357 
comm="systemd-logind" name="systemd" dev="tmpfs" ino=14313 
scontext=system_u:system_r:systemd_logind_t:s0 
tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir perm
issive=0
type=SYSCALL msg=audit(1442688229.848:286): arch=c03e syscall=263 
success=no exit=-13 a0=16 

Bug#799486: pkg-perl-autopkgtest: setup hook for running scripts before testing

[gregor herrmann]

On Sat, 19 Sep 2015 21:05:10 +0300, Niko Tyni wrote:

> While debian/tests/pkg-perl/env-smoke (#763541) solved most issues
> with unusual test suites that require special treatment, there are
> still some that need patching or other workarounds.  One of these is
> libnet-sftp-sftpserver-perl, which would need a special directory
> created under $ADTTMP. Another is libapache2-authcookie-perl (and
> other Apache-Test based modules) which wants t/TEST.PL executed before
> the tests.  I'm sure there are others.

Right. env-smoke helped me in one situation (although setting
HOME=$ADTTMP felt a bit odd, and could be done by the test scripts)
but I didn't succeed with one of the *apache* packages.
 
> While I'd love to keep the stuff in debian/tests/pkg-perl declarative,
> there's a point of diminishing returns with adding special cases. I
> suspect this is the time, and adding a setup hook that could run an
> arbitrary script/executable would make sense.

I agree that we'll need something executable if we want to run all
tests everywhere. I guess this is a question of trade-offs between
running more tests and adding more complexity. Not sure yet which
side I'm on :)


Cheers,
gregor

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Arlo Guthrie & Pete Seeger: Arlo Guthrie - Amazing Grace


signature.asc
Description: Digital Signature

Bug#799506: konsole4: FTBFS: Missing Build-Depends on libsoprano-dev

[Chris Lamb]

Source: konsole4
Version: 4:4.14.2-3
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

konsole4 fails to build from source due to missing Build-Depends on
libsoprano-dev. This was previously pulled-in via a transitive
relationship.


Regards,

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

Bug#799498: RFS: neko/2.0.0-4

[Andy Li]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "neko". I'm a member of the
Haxe Foundation. I would like to maintain the package in the long term to
improve haxe's debian support.

 * Package name: neko
   Version : 2.0.0-4
   Upstream Author : Haxe Foundation
 * URL : http://nekovm.org/
 * License : MIT
   Section : interpreters

  It builds those binary packages:

libapache2-mod-neko - Apache module for running server-side Neko
programs
 libneko0   - Lightweight virtual machine - shared library
 neko  - Lightweight virtual machine - compiler and tools
 neko-dev   - Lightweight virtual machine - headers

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

  http://mentors.debian.net/package/neko


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

dget -x
http://mentors.debian.net/debian/pool/main/n/neko/neko_2.0.0-4.dsc

  Changes since the last upload:

  * Adopt package (Closes: #628939).
+ Set maintainer to myself.
  * Set Vcs-* fields to Haxe Foundation neko-debian git repo.
  * Bump Standards-Version to 3.9.6 (no changes).


  Regards,
   Andy Li

Bug#799504: kmldonkey: FTBFS: Missing Build-Depends on libsoprano-dev

[Chris Lamb]

Source: kmldonkey
Version: 2.0.5+kde4.3.3-2
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

kmldonkey fails to build from source due to missing Build-Depends on
libsoprano-dev. This was previously pulled-in via a transitive
relationship.


Regards,

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

Bug#799505: knights: FTBFS: Missing Build-Depends on libsoprano-dev

[Chris Lamb]

Source: knights
Version: 2.5.0-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

knights fails to build from source due to missing Build-Depends on
libsoprano-dev. This was previously pulled-in via a transitive
relationship.


Regards,

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

Bug#799503: kmess: FTBFS: Missing Build-Depends on libsoprano-dev

[Chris Lamb]

Source: kmess
Version: 2.0.6.1-3
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

kmess fails to build from source due to missing Build-Depends on
libsoprano-dev. This was previously pulled-in via a transitive
relationship.


Regards,

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

Bug#799502: kile: FTBFS: Missing Build-Depends on libsoprano-dev

[Chris Lamb]

Source: kile
Version: 4:2.1.3-2
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

kile fails to build from source due to missing Build-Depends on
libsoprano-dev. This was previously pulled-in via a transitive
relationship.


Regards,

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

Bug#799422: mumble: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Chris Knadle]

Adriano Rafael Gomes:
> On Fri, Sep 18, 2015 at 11:32:01PM -0400, Chris Knadle wrote:
>> This looks like a replacement file rather than a patch, and the filename
>> looks different -- I'm assuming this replaces debian/po/pt.po.  Let me know
>> if that's correct.
> 
> Hi Chris.
> 
> Please add the pt_BR.po file to the package. It is a new file, for
> Brazilian Portuguese. The pt.po is an unrelated file, for European
> Portuguese, let's leave it untouched.
> 
> Thank you.

Ah.  ;-)  Okay thank you for translating the installation for Brazilian
Portuguese.  pt_BR.po should be included in the next upload.

  -- Chris

-- 
Chris Knadle
chris.kna...@coredump.us



signature.asc
Description: OpenPGP digital signature

Bug#792309: closed by Alberto Gonzalez Iniesta <a...@inittab.org> (Bug#791829: fixed in openvpn 2.3.7-2)

[Michal Hocko]

On Tue, Sep 08, 2015 at 09:39:05AM +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the openvpn package:
> 
> #792309: init script no longer asks for user/passwd and fails connection
> 
> It has been closed by Alberto Gonzalez Iniesta .
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Alberto Gonzalez Iniesta 
>  by
> replying to this email.

The problem still seems to be present with 2.3.7-2:
$ apt-show-versions -p openvpn
openvpn:amd64/testing 2.3.7-2 uptodate
$ sudo /etc/init.d/openvpn start CONF 
[ ok ] Starting virtual private network daemon: CONF.

[...]
Sep 19 22:21:52 tiehlicka ovpn-CONF[16336]:   auth_user_pass_file = 'stdin'
Sep 19 22:21:52 tiehlicka ovpn-CONF[16336]: OpenVPN 2.3.7 x86_64-pc-linux-gnu 
[SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Sep  8 2015
Sep 19 22:21:52 tiehlicka ovpn-CONF[16336]: library versions: OpenSSL 1.0.2d 9 
Jul 2015, LZO 2.08
Sep 19 22:21:52 tiehlicka ovpn-CONF[16337]: ERROR: could not read Auth username 
from stdin
Sep 19 22:21:52 tiehlicka ovpn-CONF[16337]: Exiting due to fatal error
-- 
Michal Hocko

Bug#793451: amarok: Amarok is partially broken: mysql does not work

[adrian]

Package: amarok
Version: 2.8.0-2.1+b2
Followup-For: Bug #793451

How did you upgrade? I cannot do it via aptitude, it holds the package and I
don't know why.
I suppose that it has to be done by downloading the deb file manually.



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

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

Versions of packages amarok depends on:
ii  amarok-common 2.8.0-2.1
ii  amarok-utils  2.8.0-2.1+b2
ii  kde-runtime   4:4.14.2-2
ii  libaio1   0.3.110-1
ii  libavcodec-ffmpeg56   7:2.7.2-2+b1
ii  libavformat-ffmpeg56  7:2.7.2-2+b1
ii  libavutil-ffmpeg547:2.7.2-2+b1
ii  libc6 2.19-20
ii  libcurl3-gnutls   7.44.0-2
ii  libgcrypt20   1.6.3-2
ii  libgdk-pixbuf2.0-02.31.5-1
ii  libgl1-mesa-glx [libgl1]  10.6.4-1
ii  libglib2.0-0  2.44.1-1.1
ii  libgpod4  0.8.3-1.1+b3
ii  libkcmutils4  4:4.14.2-5
ii  libkdecore5   4:4.14.2-5
ii  libkdeui5 4:4.14.2-5
ii  libkdewebkit5 4:4.14.2-5
ii  libkdnssd44:4.14.2-5
ii  libkfile4 4:4.14.2-5
ii  libkio5   4:4.14.2-5
ii  libknewstuff3-4   4:4.14.2-5
ii  liblastfm11.0.8-3
ii  libloudmouth1-0   1.4.3-12.1
ii  libmtp9   1.1.9-3
ii  libmysqlclient18  5.6.25-4
ii  libnepomukcore4   4:4.14.0-1+b4
ii  libofa0   0.9.3-7
ii  libphonon44:4.8.3-2
ii  libplasma34:4.14.2-5
ii  libqjson0 0.8.1-3
ii  libqt4-dbus   4:4.8.7+dfsg-1
ii  libqt4-network4:4.8.7+dfsg-1
ii  libqt4-opengl 4:4.8.7+dfsg-1
ii  libqt4-script 4:4.8.7+dfsg-1
ii  libqt4-sql4:4.8.7+dfsg-1
ii  libqt4-svg4:4.8.7+dfsg-1
ii  libqt4-xml4:4.8.7+dfsg-1
ii  libqtcore44:4.8.7+dfsg-1
ii  libqtgui4 4:4.8.7+dfsg-1
ii  libqtscript4-core 0.2.0-1
ii  libqtscript4-gui  0.2.0-1
ii  libqtscript4-network  0.2.0-1
ii  libqtscript4-sql  0.2.0-1
ii  libqtscript4-uitools  0.2.0-1
ii  libqtscript4-xml  0.2.0-1
ii  libqtwebkit4  2.3.4.dfsg-3
ii  libsolid4 4:4.14.2-5
ii  libsoprano4   2.9.4+dfsg-3
ii  libstdc++65.1.1-14
ii  libthreadweaver4  4:4.14.2-5
ii  libx11-6  2:1.6.3-1
ii  libxml2   2.9.2+dfsg1-3
ii  phonon4:4.8.3-2
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages amarok recommends:
ii  clamz0.5-2+b1
ii  kio-audiocd  4:4.14.2-1

Versions of packages amarok suggests:
pn  amarok-doc 
ii  libqt4-sql-mysql   4:4.8.7+dfsg-1
pn  libqt4-sql-psql
ii  libqt4-sql-sqlite  4:4.8.7+dfsg-1
pn  moodbar

Versions of packages amarok-common depends on:
ii  perl  5.20.2-6

amarok-common recommends no packages.

Versions of packages amarok is related to:
ii  phonon-backend-gstreamer [phonon-backend]  4:4.8.0-3

-- no debconf information

Bug#799528: python-debianbts: base64-encoded strings

[Jakub Wilk]

Package: python-debianbts
Version: 2.2


import debianbts
[bug] = debianbts.get_status(71)
print bug.originator

Ik1pY2hhxYIgS3XFgmFjaCIgPG1pY2hhbGt1bGFjaEBnbWFpbC5jb20+


This worked correctly in jessie:


import debianbts
[bug] = debianbts.get_status(71)
print bug.originator

"Michał Kułach" 


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

Kernel: Linux 4.1.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages python-debianbts depends on:
ii  python-pysimplesoap  1.16-1
pn  python:any   

--
Jakub Wilk

Bug#799535: ITP: bauble-installer -- bauble is a botanic collection manager

[Mario Frasca]

Package: wnpp
Severity: whishlist

From the homepage (http://bauble.readthedocs.org):

  Bauble is an application for managing botanical specimen collections.
  With it you can create a searchable database of plant records.

  It is open and free and is released under the GNU Public License 2+.

From the README.md (http://github.com/Bauble/bauble.classic):

At its heart Bauble is a framework for creating database applications.
In its distributed form Bauble is an application to manage plant
records and specifically living collections. It is used among others
by the Quito Botanical Garden to manage their live collections.
Included by default is RBG Kew's Family and Genera list from Vascular
Plant Families and Genera compiled by R. K. Brummitt and published by
the Royal Botanic Gardens, Kew in 1992 used by permission from RBG Kew.

---

I am the current developer for Bauble and I have decided to distribute
Bauble connecting the installation with a branch on github.

I need to make the initial installation easier to less technical
people. to this end, I intend to package only the installation script,
not the whole program. this is because I have limited time and do not
trust myself for the extra work needed for packaging the program every
time I release a new patch, which is rather often (40 times in the
last 5 months).

I have written a very minimal and possibly working (only tested on
ubuntu 14.04) package for the installation script.


Package: bauble-installer
Version: 1.0-1
Section: base
Priority: optional
Architecture: all
Depends: gettext, git, python-all-dev, python-gtk2, python-virtualenv,
libxslt1-dev
Maintainer: Mario Frasca 
Description: Bauble installer
 installer script and dependencies for bauble-1.0
 to install Bauble, run bauble-install


the installation script is at:
https://github.com/Bauble/bauble.classic/blob/master/scripts/devinstall.sh






signature.asc
Description: OpenPGP digital signature

Bug#799541: lxc-stop kills Debian 7 upgraded containers to Debian 8 with systemd on a Debian 8 host

[Nulld1g1t]

Package: lxc
Version:   1:1.0.6-6+deb8u1


Hi,

On a D8 host server with D7 containers upgraded to D8 with systemd -
following the instructions from the LXC Debian page.

  When I use lxc-stop command to cleanly stop a container, it waits,
times out and finally kills the container instead of issuing a clean
shutdown.

The pb does not happen on native D8 containers.

 
Here is a transcript:

  #lxc-stop -n mylxcbox


  This is what lxc-checkconfig returns: [all green]
===
# lxc-checkconfig
Kernel configuration not found at /proc/config.gz; searching...
Kernel configuration found at /boot/config-3.16.0-4-amd64
--- Namespaces ---
Namespaces: enabled
Utsname namespace: enabled
Ipc namespace: enabled
Pid namespace: enabled
User namespace: enabled
Network namespace: enabled
Multiple /dev/pts instances: enabled

--- Control groups ---
Cgroup: enabled
Cgroup clone_children flag: enabled
Cgroup device: enabled
Cgroup sched: enabled
Cgroup cpu account: enabled
Cgroup memory controller: enabled
Cgroup cpuset: enabled

--- Misc ---
Veth pair device: enabled
Macvlan: enabled
Vlan: enabled
File capabilities: enabled
===

  This is the configuration of the container [nothing really fancy here]
===
cat /var/lib/lxc/mylxcbox/config
lxc.network.type = empty
lxc.rootfs = /var/lib/lxc/mylxcbox/rootfs

# Common configuration
lxc.include = /usr/share/lxc/config/debian.common.conf

# Container specific configuration
lxc.mount = /var/lib/lxc/mylxcbox/fstab
lxc.utsname = mylxcbox
lxc.arch = amd64
lxc.autodev = 1
lxc.kmsg = 0

lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = vbr0
lxc.network.ipv4 = 192.168.10.200/24
lxc.network.hwaddr = 00:1E:62:CH:NG:ME

# RAM
lxc.cgroup.memory.limit_in_bytes = 2G
===

# lxc-monitor -n mylxcbox --logpriority=DEBUG
'mylxcbox' exited with status [0]
'mylxcbox' changed state to [STOPPING]
'mylxcbox' changed state to [STOPPED]


status 0 indicates the container was successfully stopped but it does it
after timing out:


I can verify this starting the container in non deamon mode [lxc-start
-n mylxcbox]
The services are not stopping, everything is killed after 60 seconds.


# time lxc-stop -n mylxcbox

real   1m0.146s
user   0m0.000s
sys   0m0.004s

It takes 60 seconds which means the container is killed after a 60
seconds timeout.
With the --nokill option added, the command times out but the container
remains up and running [ie: not killed].


As per manpage documentation:
DESCRIPTION
 lxc-stop reboots, cleanly shuts down, or kills all the
processes inside the container.
 By default, it will request a clean shutdown of the
container by sending   lxc.haltsig nal
(defaults to SIGPWR) to the container's init process,
waiting up to 60 seconds for
 the container to exit, and then returning. If the container
fails to cleanly   exit   in
 60   seconds,   it   will be sent the lxc.stopsignal
(defaults to SIGKILL) to force it to
 shut down.



What could prevent lxc.haltsignal (defaults to SIGPWR) to reach an
upgraded D7 container to D8 with systemd ?

This is the solution/workaround I have found [took me 2 days] and which
will hopefully help you resolve the matter:

Changing the halt signal from the default (SIGPWR) to SIGRTMIN+4 by
adding the following configuration in the container config file:

allows me to shutdown the container with lxc-stop but also in a clean
manner with services being stopped as expected.

The two identified signals to request a clean shutdown [#1] and an
immediate halt[#2] for the D7 to D8 systemd containers are:

# modified signals for D7 containers upgraded to D8
lxc.haltsignal = SIGRTMIN+4   #1
lxc.stopsignal = SIGRTMIN+14#2


  I am using Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u3
(2015-08-04) x86_64 GNU/Linux
The server and containers are frequently updated, all stable with
debian-security.

-- 

Cheers,

Nulld1g1t

Nulld1g1t Blog:
http://www.yourprog.com

Nulld1g1t Youtube channel:
https://www.youtube.com/user/nulld1g1t

Twitter:
https://twitter.com/nulld1g1t



0x6CF19A40.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Bug#799542: Gwenview lost editing capabilities

[Scott Kitterman]

On Saturday, September 19, 2015 11:47:29 PM Carlos Kosloff wrote:
> Package: gwenview
> Version: 4:15.08.0-3
> Severity: important
... 
> Dear maintainer,
> 
> I did not do anything special, just tried to edit an image and noticed
> that all the edition capabilties: crop, resize, etc., were gone.
> Upgraded to latest version in stretch and same behavior.
> Please consider fixing these issues.

The U/I is somewhat more hidden, but it's there.  Look at the tabs across the 
bottom of the left side of the gwenview window and check operations.  All the 
edit choices are there and I tested cropping and it works just fine.

Scott K

Bug#799507: kpartsplugin: FTBFS: Missing Build-Depends on libsoprano-dev

[Chris Lamb]

Source: kpartsplugin
Version: 20120605-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

kpartsplugin fails to build from source due to missing Build-Depends on
libsoprano-dev. This was previously pulled-in via a transitive
relationship.


Regards,

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

Bug#799510: krusader: FTBFS: Missing Build-Depends on libsoprano-dev

[Chris Lamb]

Source: krusader
Version: 1:2.4.0~beta3-2
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

krusader fails to build from source due to missing Build-Depends on
libsoprano-dev. This was previously pulled-in via a transitive
relationship.


Regards,

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

Bug#799508: kplayer: FTBFS: Missing Build-Depends on libsoprano-dev

[Chris Lamb]

Source: kplayer
Version: 1:0.7-2.1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

kplayer fails to build from source due to missing Build-Depends on
libsoprano-dev. This was previously pulled-in via a transitive
relationship.


Regards,

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

Bug#799511: ktp-auth-handler: FTBFS: Missing Build-Depends on libsoprano-dev

[Chris Lamb]

Source: ktp-auth-handler
Version: 0.9.0-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

ktp-auth-handler fails to build from source due to missing Build-Depends
on libsoprano-dev. This was previously pulled-in via a transitive
relationship.


Regards,

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

Bug#799526: pdftk: update_info cannot eat its own dogfood

[Nomen Nescio]

Package: pdftk
Version: 2.02-2
Severity: normal

Dear Maintainer,

The "pdftk --help" documentation states that the update_info function
is expecting the same format of data from the dump_data function.
However, it does not work on a variety of files, even with no
alterations.  E.g.

  $ pdftk foo.pdf dump_data | pdftk foo.pdf update_info -
  Done.  Input errors, so no output created.

If the piping seems questionable, even the normal approach breaks:

  $ pdftk foo.pdf dump_data output dogfood.txt
  $ pdftk foo.pdf update_info dogfood.txt
  Done.  Input errors, so no output created.

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

Kernel: Linux 3.16.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
Init: systemd (via /run/systemd/system)

Versions of packages pdftk depends on:
ii  libc6   2.19-18
ii  libgcc1 1:4.9.2-10
ii  libgcj154.9.2-10
ii  libstdc++6  4.9.2-10

pdftk recommends no packages.

Versions of packages pdftk suggests:
ii  poppler-utils [xpdf-utils]  0.26.5-2

-- no debconf information

Bug#799530: iceweasel: opened/uploaded files are kept opened for arbitrary times after the upload has finished

[Christoph Anton Mitterer]

Package: iceweasel
Version: 38.2.1esr-1
Severity: important


Hi.

It seems Iceweasel keeps files that have been e.g. uploaded to some website
(e.g. Google+) open for arbitary times (sometimes they're closed fast
sometimes I waited 20 mins and nothing has happened).
The effect is e.g. that one cannot unmount filesystems on which those files
are.
After killing Iceweasel, the files are of course closed and unmounting works
again.

Cheers,
Chris.

Bug#798237: Same issue, compile with NSUPDATE fails

[Michel Meyers]

Same issue here. The 4.3.3 release seems to be missing DDNS update
functionality completely. Trying to undo the disable-nsupdate.patch and
manually compiling the package fails too:

---
../omapip/libomapi.a(isclib.o): In function `dhcp_dns_client_setservers':
/root/swdown/dhcp/isc-dhcp-4.3.3/omapip/isclib.c:51: undefined reference
to `irs_resconf_load'
/root/swdown/dhcp/isc-dhcp-4.3.3/omapip/isclib.c:58: undefined reference
to `irs_resconf_getnameservers'
collect2: error: ld returned 1 exit status
distcc[21884] ERROR: compile (null) on localhost failed
Makefile:439: recipe for target 'dhclient' failed
make[4]: *** [dhclient] Error 1
make[4]: Leaving directory '/root/swdown/dhcp/isc-dhcp-4.3.3/client'
Makefile:580: recipe for target 'all-recursive' failed
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory '/root/swdown/dhcp/isc-dhcp-4.3.3/client'
Makefile:426: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory '/root/swdown/dhcp/isc-dhcp-4.3.3'
debian/rules:46: recipe for target 'override_dh_auto_build' failed
make[1]: *** [override_dh_auto_build] Error 2
make[1]: Leaving directory '/root/swdown/dhcp/isc-dhcp-4.3.3'
debian/rules:41: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2

---

Downgraded to 4.3.2 for now.

Bug#799520: tellico: FTBFS: Missing Build-Depends on libsoprano-dev

[Regis Boudin]

reassign 799520 kdepimlibs5-dev
thanks

Hi, Chris,

On 19/09/15 21:46, Chris Lamb wrote:
> Source: tellico
> Version: 2.3.9+dfsg.1-1
> Severity: serious
> Justification: fails to build from source
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: ftbfs
> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
> 
> Dear Maintainer,
> 
> tellico fails to build from source due to missing Build-Depends on
> libsoprano-dev. This was previously pulled-in via a transitive
> relationship.
> 

Actually, Tellico does not have a single reference to soprano anywhere.
The attempt to find Soprano link to libsoprano.so are only due to the
FindNepomuk.cmake file trying to pull it in.

I don't believe it's the correct approach for tellico to have
build-depends for indirect dependencies, therefore I'm reassigning this
bug to kdelibs5-dev. As the latter source package control file mentions
'${sameVersionDep:libsoprano-dev:libnepomuk4}' in its depends, it looks
to me like something actually went wrong when building kde4libs and the
dependency was not actually added.

Thanks,
Regis

Bug#799532: aptitude: typing Ctrl-L during an upgrade puts aptitude in background

[Vincent Lefevre]

On 2015-09-20 02:50:45 +0200, Vincent Lefevre wrote:
> > >zira:~> pstree -ap 29204
> > >bash,29204
> > > └─aptitude,29206
> > > ├─(dpkg,29277)
> > > ├─dpkg,30424 --status-fd 76 --configure geoclue-2.0:amd64 ...
> > > │   └─sh,30438 -c...
> > > │   └─less,30440 -Lis
> > > └─{aptitude},29491
> 
> There was a zombie dpkg process that was a child of aptitude.
> Where did it come from?

And in the /var/log/aptitude log file:

Aptitude 0.7.1: log report
Sun, Sep 20 2015 00:34:35 +0200

IMPORTANT: this log only lists intended actions; actions which fail due to
dpkg problems may not be completed.

Will install 9 packages, and remove 0 packages.
50.2 kB of disk space will be used
===
[HOLD, DEPENDENCIES] libldb1:amd64
[HOLD] fvwm:amd64
[HOLD] info:amd64
[UPGRADE] geoclue-2.0:amd64 2.2.0-1 -> 2.3.0-1
[UPGRADE] klibc-utils:amd64 2.0.4-3 -> 2.0.4-4
[UPGRADE] libklibc:amd64 2.0.4-3 -> 2.0.4-4
[UPGRADE] liblightdm-gobject-1-0:amd64 1.14.2-2 -> 1.16.2-1
[UPGRADE] liblightdm-gobject-dev:amd64 1.14.2-2 -> 1.16.2-1
[UPGRADE] lightdm:amd64 1.14.2-2 -> 1.16.2-1
[UPGRADE] xfig:amd64 1:3.2.5.c-5 -> 1:3.2.5.c-6
[UPGRADE] xfig-doc:amd64 1:3.2.5.c-5 -> 1:3.2.5.c-6
[UPGRADE] xfig-libs:amd64 1:3.2.5.c-5 -> 1:3.2.5.c-6
===

Log complete.
Aptitude 0.7.1: log report
Sun, Sep 20 2015 00:35:01 +0200

IMPORTANT: this log only lists intended actions; actions which fail due to
dpkg problems may not be completed.

Will install 9 packages, and remove 0 packages.
50.2 kB of disk space will be used
===
[HOLD, DEPENDENCIES] libldb1:amd64
[HOLD] fvwm:amd64
[HOLD] info:amd64
[UPGRADE] geoclue-2.0:amd64 2.2.0-1 -> 2.3.0-1
[UPGRADE] klibc-utils:amd64 2.0.4-3 -> 2.0.4-4
[UPGRADE] libklibc:amd64 2.0.4-3 -> 2.0.4-4
[UPGRADE] liblightdm-gobject-1-0:amd64 1.14.2-2 -> 1.16.2-1
[UPGRADE] liblightdm-gobject-dev:amd64 1.14.2-2 -> 1.16.2-1
[UPGRADE] lightdm:amd64 1.14.2-2 -> 1.16.2-1
[UPGRADE] xfig:amd64 1:3.2.5.c-5 -> 1:3.2.5.c-6
[UPGRADE] xfig-doc:amd64 1:3.2.5.c-5 -> 1:3.2.5.c-6
[UPGRADE] xfig-libs:amd64 1:3.2.5.c-5 -> 1:3.2.5.c-6
===

Log complete.

I don't understand why this is duplicated.

In the /var/log/dpkg.log log file:

[...]
2015-09-19 19:37:16 startup packages configure
2015-09-20 00:34:55 startup packages configure
2015-09-20 00:35:11 startup archives unpack
2015-09-20 00:35:12 upgrade geoclue-2.0:amd64 2.2.0-1 2.3.0-1
2015-09-20 00:35:12 status half-configured geoclue-2.0:amd64 2.2.0-1
2015-09-20 00:35:12 status unpacked geoclue-2.0:amd64 2.2.0-1
2015-09-20 00:35:12 status half-installed geoclue-2.0:amd64 2.2.0-1
2015-09-20 00:35:12 status triggers-pending mime-support:all 3.59
2015-09-20 00:35:12 status triggers-pending desktop-file-utils:amd64 0.22-1
2015-09-20 00:35:12 status half-installed geoclue-2.0:amd64 2.2.0-1
2015-09-20 00:35:12 status triggers-pending dbus:amd64 1.10.0-3
2015-09-20 00:35:12 status triggers-pending dbus:amd64 1.10.0-3
2015-09-20 00:35:12 status half-installed geoclue-2.0:amd64 2.2.0-1
2015-09-20 00:35:12 status unpacked geoclue-2.0:amd64 2.3.0-1
2015-09-20 00:35:12 status unpacked geoclue-2.0:amd64 2.3.0-1
2015-09-20 00:35:12 upgrade klibc-utils:amd64 2.0.4-3 2.0.4-4
2015-09-20 00:35:12 status half-configured klibc-utils:amd64 2.0.4-3
2015-09-20 00:35:12 status unpacked klibc-utils:amd64 2.0.4-3
2015-09-20 00:35:12 status half-installed klibc-utils:amd64 2.0.4-3
2015-09-20 00:35:12 status half-installed klibc-utils:amd64 2.0.4-3
2015-09-20 00:35:12 status unpacked klibc-utils:amd64 2.0.4-4
2015-09-20 00:35:12 status unpacked klibc-utils:amd64 2.0.4-4
2015-09-20 00:35:12 upgrade libklibc:amd64 2.0.4-3 2.0.4-4
2015-09-20 00:35:12 status half-configured libklibc:amd64 2.0.4-3
2015-09-20 00:35:12 status unpacked libklibc:amd64 2.0.4-3
2015-09-20 00:35:12 status half-installed libklibc:amd64 2.0.4-3
2015-09-20 00:35:12 status half-installed libklibc:amd64 2.0.4-3
2015-09-20 00:35:12 status unpacked libklibc:amd64 2.0.4-4
2015-09-20 00:35:12 status unpacked libklibc:amd64 2.0.4-4
2015-09-20 00:35:12 upgrade liblightdm-gobject-dev:amd64 1.14.2-2 1.16.2-1
2015-09-20 00:35:12 status half-configured liblightdm-gobject-dev:amd64 1.14.2-2
2015-09-20 00:35:12 status unpacked liblightdm-gobject-dev:amd64 1.14.2-2
2015-09-20 00:35:12 status half-installed liblightdm-gobject-dev:amd64 1.14.2-2
2015-09-20 00:35:13 status half-installed liblightdm-gobject-dev:amd64 1.14.2-2
2015-09-20 00:35:13 status unpacked liblightdm-gobject-dev:amd64 1.16.2-1
2015-09-20 00:35:13 status unpacked liblightdm-gobject-dev:amd64 1.16.2-1
2015-09-20 00:35:13 upgrade liblightdm-gobject-1-0:amd64 1.14.2-2 1.16.2-1
2015-09-20 00:35:13 status half-configured liblightdm-gobject-1-0:amd64 1.14.2-2
2015-09-20 00:35:13 status unpacked 

Bug#799499: kdevelop-php-docs: FTBFS: Missing Build-Depends on libsoprano-dev

[Chris Lamb]

Source: kdevelop-php-docs
Version: 1.7.0-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

kdevelop-php-docs fails to build from source due to missing
Build-Depends on libsoprano-dev. This was previously pulled-in via a
transitive relationship.


Regards,

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

Bug#799497: kde-dev-utils: FTBFS: Missing Build-Depends on libsoprano-dev

[Chris Lamb]

Source: kde-dev-utils
Version: 4:4.12.2-2
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

kde-dev-utils fails to build from source due to missing Build-Depends on
libsoprano-dev. This was previously pulled-in via a transitive
relationship.


Regards,

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

Bug#799501: kftpgrabber: FTBFS: Missing Build-Depends on libsoprano-dev

[Chris Lamb]

Source: kftpgrabber
Version: 0.8.99~svn1214766-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

kftpgrabber fails to build from source due to missing Build-Depends on
libsoprano-dev. This was previously pulled-in via a transitive
relationship.


Regards,

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

Bug#799500: kdewebdev: FTBFS: Missing Build-Depends on libsoprano-dev

[Chris Lamb]

Source: kdewebdev
Version: 4:4.14.1-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

kdewebdev fails to build from source due to missing Build-Depends on
libsoprano-dev. This was previously pulled-in via a transitive
relationship.


Regards,

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

Bug#789670: Dropping python-pies2overrides

[Scott Kitterman]

On Fri, 18 Sep 2015 22:29:03 + Tristan Seligmann  
wrote:
> Since frosted is the only reverse dep of python-pies, and it can use
> python3-pies instead, how about just dropping
> python-pies/python-pies2overrides completely?

It doesn't look like frosted uses the xmlrpc override, so even simpler would 
be just to remove the xmlrpc override (since frosted does use others).  Then 
the change would be confined to python-pies2-overrides.

Scott K

Bug#799485: header files moved to /usr/lib/pypy

[Stefano Rivera]

Hi Jelmer (2015.09.19_20:04:34_+0200)
> With 2.6.1+dfsg-1, header files from pypy appear to have moved from
> /usr/lib/pypy/include to /usr/lib/pypy. This breaks module building, as
> it still happens with the old include path specified.

Oops. There's definitely my mistake in b56a15c7955711728af0e0dd80bf76c5302bfb53

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#799485: header files moved to /usr/lib/pypy

[Jelmer Vernooij]

Package: pypy-dev
Version: 2.6.1+dfsg-1
Severity: important

With 2.6.1+dfsg-1, header files from pypy appear to have moved from
/usr/lib/pypy/include to /usr/lib/pypy. This breaks module building, as
it still happens with the old include path specified.

Python 2.7.10 (2.6.1+dfsg-1, Sep 17 2015, 17:43:05)
[PyPy 2.6.1 with GCC 5.2.1 20150911] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 import distutils.sysconfig_pypy
 distutils.sysconfig_pypy.get_python_inc()
'/usr/lib/pypy/include'
 


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

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

Versions of packages pypy-dev depends on:
ii  dpkg  1.18.2
ii  pypy  2.6.1+dfsg-1

pypy-dev recommends no packages.

pypy-dev suggests no packages.

-- no debconf information

Bug#788457: lmms: New Version

[Sanjeev C]

need a build depend on fluild, other than it builds fine on jessie

Bug#799486: pkg-perl-autopkgtest: setup hook for running scripts before testing

[Niko Tyni]

Package: pkg-perl-autopkgtest
Version: 0.25
Severity: wishlist

While debian/tests/pkg-perl/env-smoke (#763541) solved most issues
with unusual test suites that require special treatment, there are
still some that need patching or other workarounds.  One of these is
libnet-sftp-sftpserver-perl, which would need a special directory
created under $ADTTMP. Another is libapache2-authcookie-perl (and
other Apache-Test based modules) which wants t/TEST.PL executed before
the tests.  I'm sure there are others.

While I'd love to keep the stuff in debian/tests/pkg-perl declarative,
there's a point of diminishing returns with adding special cases. I
suspect this is the time, and adding a setup hook that could run an
arbitrary script/executable would make sense.

I'd be happy to hear what others think about this.
-- 
Niko

Bug#799487: pkg-perl-autopkgtest: saner configuration file hierarchy

[Niko Tyni]

Package: pkg-perl-autopkgtest
Version: 0.25
Severity: wishlist

There's unfortunately little logic to the naming of the configuration
files. We currently have at least

 debian/tests/pkg-perl/SKIP
 debian/tests/pkg-perl/skip-smoke
 debian/tests/pkg-perl/test-files
 debian/tests/pkg-perl/module-name
 debian/tests/pkg-perl/skip-syntax
 debian/tests/pkg-perl/env-smoke

with more to come (see #799486).

Possibly organizing the files by subtest would be cleaner, maybe
something like

 debian/tests/pkg-perl/SKIP
 debian/tests/pkg-perl/smoke/SKIP
 debian/tests/pkg-perl/smoke/files
 debian/tests/pkg-perl/smoke/env
 debian/tests/pkg-perl/syntax/SKIP

I suppose this would need a transition where the scripts would look in
the old locations for a while, possibly forever. Not sure if the gain
is worth the complications, but filing this at least for future reference.
-- 
Niko Tyni   nt...@debian.org

Bug#799076: Reproducing

[Jelmer Vernooij]

On Sat, Sep 19, 2015 at 12:18:13PM +0100, Chris Lamb wrote:
> Hey,
> 
> > Can you reproduce it?
> 
> I always can reproduce issues before filing! :)
> 
> > How is the locale set exactly?
> 
> I installed the locales package, selected fr_CH.UTF-8, exported this as
> LANG, then rebuilt. Nothing crazy, just as if I was running this locale
> everyday.
Ah, thanks. I've managed to reproduce it now - I had to enable the
translation strings for ch_FR.UTF-8 for C git.

> Saying *that* I can't actually reproduce right this second in current
> sid even under a "vanilla" locale as I'm FTBFS with:
> 
>   running build_ext
>   building 'dulwich._objects' extension
>   creating build-pypy/temp.linux-x86_64-2.7
>   creating build-pypy/temp.linux-x86_64-2.7/dulwich
>   cc -O2 -fPIC -Wimplicit -D_FORTIFY_SOURCE=2 -g -O2
>   -fstack-protector-strong -Wformat -Werror=format-security
>   -I/usr/lib/pypy/include -c dulwich/_objects.c -o
>   build-pypy/temp.linux-x86_64-2.7/dulwich/_objects.o
>   dulwich/_objects.c:20:20: fatal error: Python.h: No such file or
>   directory
>   compilation terminated.
> 
> I'm sure this is unrelated, but a bit of a blocker :)
This is a regression in pypy-dev 2.6.1+dfsg-1.  I've filed
http://bugs.debian.org/799485

Cheers,

Jelmer

-- 
Jelmer Vernooij 
Debian Developer   https://jelmer.uk/


signature.asc
Description: Digital signature

Bug#798975: [Pkg-libvirt-maintainers] Bug#798975: libvirt-daemon-system: AppArmor profile breaks startup of QEMU VM with type=pty serial port

[intrigeri]

Guido Günther wrote (19 Sep 2015 12:39:17 GMT) :
> I'm having a VM which also has these elements but starts nicely.

I'll try to create a fresh one and test, and I'll send the complete
domain XML soonish.

> Could that be related to a newer QEMU? I'm running
> 1:2.1+dfsg-12+deb8u2 here with apparmor here.

sid's 2.4+dfsg-3 here.

Cheers,
-- 
intrigeri

Bug#799471: Updated r-cran-beeswarm and plink1.9

[Gert Wollny]

Hello again, 

> I'm just looking into plink1.9 to fix #799471.  I currently test the
> build on a 32 bit arch, and would also try to compile the changes on
> amd64. I'll ping you when it's done.

I've created a patch that should fix the build failures reported in
 #799471, but since it only replaces one define __LP64__ by another
__SSE2__, this does not result in a usable program on non x86 64 bit
architectures (see discussion on github [1]), therefore, I removed it
again, but it is available as commit b91b5d. 

Doing this properly will take some time, because there are 300 tests
for the __LP64__ define.

It would probably be best for now to disable the build for all archs
where the build fails, and also for big-endian archs, since upstream
says that the program doesn't work there.

Best,  
Gert 

[1] https://github.com/chrchang/plink-ng/issues/26

Bug#799488: ITP: libretro-gambatte - Gambatte libretro port

[Sérgio Benjamim]

Package: wnpp
Severity: wishlist
Owner: Sérgio Benjamim

* Package name   : gambatte
* Version: 0.5.0
* URL: https://github.com/libretro/gambatte-libretro
* License: GPL-2
Programming Lang : C++
Description  : port of Gambatte to the libretro API

Gambatte is a portable, open-source Game Boy and Game Boy Color emulator,
focused on accuracy.

This is the libretro core (it's not yet in upstream).

https://mentors.debian.net/package/libretro-gambatte

To test it you'll need to install RetroArch, the reference libretro

frontend:http://mentors.debian.net/package/retroarch


--

Sergio Benjamim

Bug#788457: lmms: New Version

[Petter Reinholdtsen]

[Sanjeev C]
> need a build depend on fluild, other than it builds fine on jessie

Thank you.  I've added the build dependency to git.  My pbuilder setup
is broken at the moment, so I did not notice it myself.

Did the program work fine for you?
-- 
Happy hacking
Petter Reinholdtsen

Bug#799298: torsocks: Unsupported syscall number 186/202 with iceweasel and video

[intrigeri]

Control: retitle -1 Does not support syscalls 186 and 202
Control: severity -1 normal
Control: tag -1 + upstream
Control forwarded -1 dgou...@ev0ke.net

Hi Petter,

Petter Reinholdtsen wrote (17 Sep 2015 16:30:13 GMT) :
> When starting 'torsocks iceweasel' [...]

FYI https://www.torproject.org/projects/torbrowser/design/ documents
why this generally gives the user a mistaken feeling of safety.

Hence downgrading severity a bit, since IMO we should not actively
support this specific usecase.

> [sep. 17 18:25:46] WARNING torsocks[26153]: [syscall] Unsupported
> syscall number 202. Denying the call (in tsocks_syscall() at
> syscall.c:165))

> [sep. 17 18:26:18] WARNING torsocks[26265]: [syscall] Unsupported
> syscall number 186. Denying the call (in tsocks_syscall() at
> syscall.c:165))

> I guess there is something not implemented in torsocks leading
> to these.

> Can the missing parts be added to get this working.

Let's ask the upstream author (Cc'd): David, any thoughts about this?

Cheers,
-- 
intrigeri

Bug#782676: libgraph-perl: warning about Storable version 2.49_01

[Steinar H. Gunderson]

On Sat, Sep 19, 2015 at 08:55:49PM +0300, Niko Tyni wrote:
> Please let me know if you'd like an NMU. The pkg-perl group is also
> happy to adopt the package in case you don't want to maintain it anymore.

Hi,

If you want to adopt it over, I'd be happy to give it away -- I don't use
this package myself anymore.

/* Steinar */
-- 
Homepage: http://www.sesse.net/

Bug#287014: (LDAP) object class modification from inetOrgPerson to evolutionPerson not allowed

[Tom]

Control: reassign -1 src:evolution-data-server
Control: retitle -1 evolutionPerson schema incompatible with other MUAs
Control: found -1 3.4.4-3+deb7u1 3.12.9~git20141128.5242b0-2+deb8u2
thanks

This bug is still present in jessie. It is due to the definition of the
evolutionPerson objectclass. It should not be STRUCTURAL, but AUXILIARY:

/usr/share/evolution-data-server/evolutionperson.schema contains:
# evolutionPerson
objectclass ( 1.3.6.1.4.1.8506.1.3.1
NAME 'evolutionPerson'
DESC 'Objectclass geared to Evolution Usage'
SUP inetOrgPerson
STRUCTURAL

Bug#780939: virtualbox-dkms does not work for backported kernels.

[Gianfranco Costamagna]

Hi Georg,




>Does this mean, if running jessie and a backported kernel, each time the
>kernel receives an update, virtualbox has to be updated as well?


well, each virtualbox release is guaranteed to build (except for bugs of course)
to kernels up to a particular version (e.g. 5.0.4 build fine until kernel 4.2, 
the latest stable
at the moment of the release).

This is because virtualbox provides a kernel module, and the code is strictly 
dependent on kernel
code, and since it changes *a lot* between releases, you can't know in advance 
if and how the kernel
module build will break with the kernel going forward

For Debian I guess the solution might be to use a virtualbox backported too.
(thanks Aron for providing it)

> Fortunately with the security updates this problem won't be there
> anymore.
>
>Could you elaborate on this?
>
>Thanks for your work and all the best,


well, security allowed us to update virtualbox from 4.3.18 to 4.3.30, and 
Oracle folks,
as part of their stable releases, updates the kernel modules too.

So as soon as we can update virtualbox without having to patch the kernel 
module manually,
we can guarantee a build with newer kernels too.

(if you look at the code it is a mess of "if defined kernel >= version and <= 
another one" and so on.)

Ubuntu adopted a really nice (from my virtualbox maintainer point of view) 
solution:
they ship the Virtualbox kernel module as part of the kernel itself, so they 
can guarantee a successful build
as long as you continue to use the official Canonical provided kernel.

You can see a module example (really easy to look at, fortunately it didn't 
change too much) here:
http://anonscm.debian.org/cgit/pkg-virtualbox/virtualbox.git/tree/src/VBox/HostDrivers/VBoxNetAdp/linux/VBoxNetAdp-linux.c

cheers,

G.

Bug#798699: java.lang.ClassCastException: java.io.File cannot be cast to java.lang.Class

[Vincent Fourmond]

  Dear Markus,

  Thanks for looking at the problem and finding the fix. I had somehow
missed the initial report.

  I was planning on packaging the latest release.

  Cheers,

  Vincent

On Sat, Sep 12, 2015 at 1:30 AM, Markus Koschany  wrote:
> Control: tags -1 patch
>
> Please find attached a patch that fixes the issue. The recent update of
> libcommons-cli-java to version 1.3.1 introduced some changes in
> OptionsBuilder.java which caused this FreeCol runtime error. In general
> Freecol should move away from OptionsBuilder because this class is
> deprecated. I changed the type from File to Class, and so far the game
> works again.
>
> Markus