Bug#812470: kernel-package: cannot produce debs anymore

[Manoj Srivastava]

Hi,

Yes, I think I broke things pretty badly. I think kernel-package
 has bitrotted a bit in the last few years, and needs some care. I am
 going to see if I can steal from the upstream  method of making debian
 packages, and move the resulting rules files to use debhelper, and get
 this back to a useable state.

manoj
-- 
We cannot do everything at once, but we can do something at once. Calvin
Coolidge
Manoj Srivastava    
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C


smime.p7s
Description: S/MIME cryptographic signature

Bug#812207: linux: AUFS can hang up; Please update to v20160111 or later

[Akihiro Suda]

I also tested, and it works!

Thank you for patches Ben, thank you for testing Zachary, and thank
you for pointing out Roger san!

Bug#812791: xserver-xorg-core: Kills DM controlled session when opening X from another tty

[Julien Cristau]

On Tue, Jan 26, 2016 at 16:51:27 +0100, Agustin Martin wrote:

> Package: xserver-xorg-core
> Version: 2:1.17.3-2
> Severity: normal
> 
> Dear Maintainers,
> 
> I am having a strange problem apparently starting with 2:1.17.2-3.
> 
> I often have a display-manager controlled X session for one user and open
> another X session in a free tty for a different user with startx.
> 
> This has been working for a long time. However, after a recent testing
> upgrade including xserver-xorg-core 2:1.17.2-3 this started to fail
> (failure happened before in a sid box, but there were more upgrades to
> look when trying to locate which change might be responsible).
> 
> When I have a display-mamager controlled X session and, without leaving the
> session, switch to a free tty, login as another user and start an X session
> with startx original X session gets killed and I am sent to DM greeter.
> 
Please provide the log from both X processes.

Thanks,
Julien

Bug#812833: pan: Won't start--aborts with error

[Dominique Dumont]

Note: submitter email is unknown: 

: host mx.xmission.com[166.70.12.20] said: 550-XM-RJCT01:
Account  does not exist. [15.73.212.82] 550

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

Bug#802659: dbus-python: Please drop recommends on PyQt4 packages

[Dmitry Shachnev]

Hi Simon,

On Tue, Jan 26, 2016 at 06:49:11PM +0100, Simon McVittie wrote:
> On 26/01/16 10:37, Dmitry Shachnev wrote:
>> My point was that Qt main loop is usually used on Windows / OS X but *not*
>> on Debian. Here, Qt is compiled with GLib support and will use GLib main
>> loop unless explicitly asked not to do so (via QT_NO_GLIB=1 env variable).
>> That is a very rare use case and I don't see why one will ever need it.
>
> Am I right in thinking that Qt programs always the same external-facing
> main-loop API, and that results in callbacks being scheduled from GLib's
> GMainContext on Debian under normal circumstances, or from Qt's built-in
> equivalent of GMainContext/libevent/etc. on Windows, OS X, or with
> QT_NO_GLIB?

Right. Applications always use QCoreApplication/QEventLoop, that creates
an event dispatcher internally, which is different on different platforms.

On other platforms it may also use platform-specific dispatchers, though it
is not relevant for us.

For UNIX the logic is at:
https://code.woboq.org/qt5/qtbase/src/corelib/kernel/qcoreapplication.cpp.html#489

> dbus-python needs two things to work with a particular main-loop: it
> needs to be told how to make that main-loop monitor libdbus connections
> (a dbus.mainloop.* module), and the application author needs to actually
> be iterating that main-loop.
>
> For GLib, dbus.mainloop.glib is bundled with dbus-python, but the
> application author also needs to iterate the GLib main-loop via PyGI,
> either directly or by using a higher-level API like Gtk or GApplication.
> For Qt, dbus.mainloop.whatever replaces dbus.mainloop.glib (but on
> Debian, dbus.mainloop.glib would also work), and QApplication replaces
> PyGI (but on Debian, PyGI would also work).
>
> The "main loop" terminology for the dbus-python addons is perhaps
> unfortunate; it's really more like "event dispatcher integration glue".

I know — I have been playing with that stuff a bit in past :)

>> If you don't remove these packages from Recommends, then at least please
>> replace them with their modern PyQt5 alternatives, i.e.:
>>
>> python-qt4-dbus → python-dbus.mainloop.pyqt5
>> python3-dbus.mainloop.qt → python3-dbus.mainloop.pyqt5
>
> I've done that in git for now, while we decide whether to remove them
> altogether.

Thanks!

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#812833: pan: Won't start--aborts with error

[Dominique Dumont]

On Tuesday 26 January 2016 14:23:17 you wrote:
> ERROR:pan-tree.cc:80:GtkTreeIter PanTreeStore::get_iter(const
> PanTreeStore::Row*): assertion failed: (row) Aborted

There's already an upstream bug ticket for this issue. Unfortunately, pan 
maintenance has stalled, so a fix won't be released any time soon, unless some 
new people takes over this project.

In the meantime, you should be able to recover pan with this work-around:
* ssh into your own machine with -X option
* run pan from there.

Please tell me if this works.

All the best
-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

Bug#812626: libfreecontact-perl: FTBFS - Parse errors: Bad plan. You planned 10 tests but ran 6.

[Andreas Tille]

tags 812626 unreproducible
thanks

On Wed, 27 Jan 2016 gregor herrmann wrote:
> 
> On Tue, 26 Jan 2016 21:14:35 +0100, Andreas Tille wrote:
> 
> > > I cloned the git repo (very handy :)) and had a look, but I can't
> > > reproduce the test failure, not even when running them manually under
> > > high load.
> > H, I should have mentioned this: I also can not reproduce the
> > problem.
> 
> Ok, maybe the submitter can shed some light on this issue.

Michael, could you please be more verbose about the build conditions
since two people can not reproduce this independently.
   
> > > > > SSE2 veczweight, wchunk = 32
> > I get
> >   SSE2 veczweight, wchunk = 64
> > here instead (when building on amd64).
> 
> Me too.
>  
> > > I noticed that the non-perl-test output comes before t/02test.t while
> > > it comes later (after the "ok 3" of t/02test.t) for me. I thought this
> > > might be a parallelization problem but the test was run with -j1, and
> > > it also passes for me with -jN.
> > From my (limited) experience this kind of non-reproducible FTBFS are
> > often connected to parallelization.  I'm tempted to drop the --parallel
> > from d/rules.
> 
> Doesn't hurt, but since since the logs have
> make -j1 test TEST_VERBOSE=1
> this doesn't seem to have any effect anyway.

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#768857: torbrowser-launcher (0.1.6-1): processes do not terminate on exit and tor browser cannot be reopened

[Γιώργος Πάλλας]

On 25/01/16 20:27, Holger Levsen wrote:

control: tags -1 + unreproducible

Hi Giorgos,

do you still see this bug with recent versions of torbrowser(-launcher)?

I've not seen in it in a very long time and am tempted to close this bug
report - what do you think?


cheers,
Holger


Hi!

Let me use it for a couple of days and I will get back to you.

Thanks!
Giorgos




smime.p7s
Description: S/MIME Cryptographic Signature

Bug#812844: upower segfault on my ARM laptop

[Alexandre Detiste]

Package: upower
Version: 0.99.3-1+b3
Severity: important

upower does segfault every time; well the kernel is maybe a bit weird.
It's the ChromeOS one recompiled by the semi-automated Arch bootstrap
to enable features needed by systemd.


systemd[1]: Starting Daemon for power management...
systemd[1]: Started Daemon for power management.
upowerd[2045]: ** (upowerd:2045): CRITICAL **: 
dbus_g_connection_register_g_object: 
  assertion 'g_variant_is_object_path (at_path)' failed
upowerd[2045]: process 2045: arguments to dbus_message_new_signal() were 
incorrect,
   assertion "_dbus_check_is_valid_path (path)" failed in file 
../../dbus/dbus-message.c line 1433.
upowerd[2045]: This is normally a bug in some application using the D-Bus 
library.
upowerd[2045]: process 2045: arguments to dbus_message_iter_init_append() were 
incorrect, assertion "message !=
   NULL" failed in file ../../dbus/dbus-message.c line 2462. 
upowerd[2045]: This is normally a bug in some application using the D-Bus 
library.
systemd[1]: upower.service: Main process exited, code=killed, status=11/SEGV
systemd[1]: upower.service: Unit entered failed state.
systemd[1]: upower.service: Failed with result 'signal'.



This is the last device opened: (reproducible)

strace -e open -f /lib/upower/upowerd
[pid  2311] 
open("/sys/devices/soc0/sound.8/sound/card1/input5/event5/../capabilities/sw", 
O_RDONLY|O_LARGEFILE) = 14


Greets,

Alexandre


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (450, 'unstable')
Architecture: armhf (armv7l)
Foreign Architectures: i386

Kernel: Linux 3.10.18-5-ARCH (SMP w/4 CPU cores)
Locale: LANG=fr_BE.UTF8, LC_CTYPE=fr_BE.UTF8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages upower depends on:
ii  dbus   1.10.6-1
ii  libc6  2.21-6
ii  libdbus-1-31.10.6-1
ii  libdbus-glib-1-2   0.106-1
ii  libglib2.0-0   2.46.2-3
ii  libgudev-1.0-0 230-2
ii  libimobiledevice6  1.2.0+dfsg-2+b1
ii  libplist3  1.12-3.1
ii  libupower-glib30.99.3-1+b3
ii  libusb-1.0-0   2:1.0.20-1
ii  udev   228-4+b1

Versions of packages upower recommends:
ii  policykit-1  0.105-14.1

upower suggests no packages.

-- no debconf information

Bug#812843: iceweasel: Many notifications are not shown with libnotify enabled

[Matthew Gabeler-Lee]

Package: iceweasel
Version: 44.0-1
Severity: normal

I find that many HTML5 style notifications aren't shown in iceweasel (not
new in this version, just finally got motivated to dig a little due to the
notification enhancements advertised in this version).

Most notification demo sites work, but notably gmail only sometimes works,
and most annoyingly, google calendar _never_ works.

Searching in bugzilla, I find these reports that look similar, but I'm not
sure how to dig in further to find out if one of them matches my case:

https://bugzilla.mozilla.org/show_bug.cgi?id=1236150
https://bugzilla.mozilla.org/show_bug.cgi?id=726594
https://bugzilla.mozilla.org/show_bug.cgi?id=1162788

Installing this extension to disable libnotify usage makes notifications
from my "problem" sites work properly, though naturaully now with XUL
instead of libnotify appearance.

https://addons.mozilla.org/en-US/firefox/addon/disable-system-alerts/

It's also worth noting that there are new notification control options as of
44.0 in the XUL version that don't seem to be accessible from the libnotify
version.

-- Package-specific info:

-- Extensions information
Name: Adblock Plus
Location: ${PROFILE_EXTENSIONS}/{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}.xpi
Status: enabled

Name: Add-on Compatibility Reporter
Location: ${PROFILE_EXTENSIONS}/compatibil...@addons.mozilla.org.xpi
Status: enabled

Name: All-in-One Gestures
Location: ${PROFILE_EXTENSIONS}/{8b86149f-01fb-4842-9dd8-4d7eb02fd055}
Status: enabled

Name: bug489729(Disable detach and tear off tab)
Location: ${PROFILE_EXTENSIONS}/bug489729@alice0775
Status: enabled

Name: Cookie Monster
Location: ${PROFILE_EXTENSIONS}/{45d8ff86-d909-11db-9705-005056c8}.xpi
Status: enabled

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

Name: Disable System Alerts
Location: 
${PROFILE_EXTENSIONS}/disable-system-ale...@matthew.noorenberghe.com.xpi
Status: enabled

Name: dtv jira tweaks userstyle
Status: enabled

Name: Element Hiding Helper for Adblock Plus
Location: ${PROFILE_EXTENSIONS}/elemhidehel...@adblockplus.org.xpi
Status: enabled

Name: Google Privacy
Location: ${PROFILE_EXTENSIONS}/{ea61041c-1e22-4400-99a0-aea461e69d04}.xpi
Status: enabled

Name: Hide right hand pane in Gmail userstyle
Status: enabled

Name: Hide Tab Bar With One Tab
Location: ${PROFILE_EXTENSIONS}/{e5bbc237-c99b-4ced-a061-0be27703295f}.xpi
Status: enabled

Name: Linkification
Location: ${PROFILE_EXTENSIONS}/{35106bca-6c78-48c7-ac28-56df30b51d2a}.xpi
Status: enabled

Name: Master Password+
Location: ${PROFILE_EXTENSIONS}/masterpasswordtimeoutplus@vano
Status: enabled

Name: meta-q-override
Location: ${PROFILE_EXTENSIONS}/jid1-7osji9sxtay...@jetpack.xpi
Status: enabled

Name: msdn tweaks userstyle
Status: enabled

Name: PasswordMaker
Location: ${PROFILE_EXTENSIONS}/{5872365e-67d1-4afd-9480-fd293bebd20d}.xpi
Status: enabled

Name: Referrer Control
Location: ${PROFILE_EXTENSIONS}/referrercont...@qixinglu.com.xpi
Status: enabled

Name: ReloadEvery
Location: ${PROFILE_EXTENSIONS}/{888d99e7-e8b5-46a3-851e-1ec45da1e644}.xpi
Status: enabled

Name: Saved Password Editor
Location: ${PROFILE_EXTENSIONS}/savedpasswordedi...@daniel.dawson.xpi
Status: enabled

Name: Send Tab to Device
Location: ${PROFILE_EXTENSIONS}/jid1-mdjma7if6lo...@jetpack.xpi
Status: enabled

Name: SPDY indicator
Location: ${PROFILE_EXTENSIONS}/spdyindica...@chengsun.github.com.xpi
Status: enabled

Name: Stylish
Location: ${PROFILE_EXTENSIONS}/{46551EC9-40F0-4e47-8E18-8E5CF550CFB8}.xpi
Status: enabled

Name: Stylish Sync
Location: ${PROFILE_EXTENSIONS}/{0e3fc079-afbb-4a00-87e5-9486062d0f9c}.xpi
Status: enabled

Name: SuperStop
Location: ${PROFILE_EXTENSIONS}/supers...@gavinsharp.com.xpi
Status: enabled

Name: User Agent Switcher
Location: ${PROFILE_EXTENSIONS}/{e968fc70-8f95-4ab9-9e79-304de2a71ee1}.xpi
Status: enabled

Name: Video DownloadHelper
Location: ${PROFILE_EXTENSIONS}/{b9db16a4-6edc-47ec-a1f4-b86292ed211d}.xpi
Status: enabled

Name: xda-developers forum - suppress minimum page width userstyle
Status: enabled

-- Plugins information
Name: Gnome Shell Integration
Location: /usr/lib/mozilla/plugins/libgnome-shell-browser-plugin.so
Package: gnome-shell
Status: enabled

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

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


-- Addons package information
ii  gnome-shell3.18.1-1 amd64graphical shell for the GNOME des
ii  google-talkplu 5.41.0.0-1   amd64Google Talk Plugin
ii  iceweasel  44.0-1   amd64Web browser based on Firefox

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

Bug#812796: tokyocabinet ftbfs on ppc64el, failing to run the tests

[Tobias Frost]

Control: Retitle -1 tokyocabinet: testsuite sometimes failes
Control: Severity -1 normal
Control: Tags -1 unreproducible help


Hi Matthias,

this is some spurious error I've seen before. A give-back will fixed
that everytime until now... Unfortunatly I'm not able to reproduce it
here, even after looping the testsuite endlessly for an day or so.. 
so nothing I can do at the moment
(I'll do an upload for the parallel, so no gb will be needed)

So let me reduce the severity and tag it help.. Maybe someone is more
lucky than me in repproducing


--
tobi

Am Dienstag, den 26.01.2016, 17:45 +0100 schrieb Matthias Klose:
> Package: src:tokyocabinet
> Version: 1.4.48-4
> Severity: serious
> Tags: sid stretch
> 
> seen in 20160126 unstable:
> 
> AA@A01A2A9CA515D7E849493@98@24787308E46B9E6@44B098 (3850)
> AB3@475D023A21312976ECAA2728AD10C64778CAB06279C468 (3900)
> AC9AAD2EEE@CEC9124524674647@619B17A@EB85A53@01D832 (3950)
> 4DACD34D4B742@C0@02C0DA@9848492@C42@37E520E5480B40 (4000)
> 4E02000@@44331A6C3A845B@1AE8@0CB7DD@D974C048272CB4Makefile:236:
> recipe for 
> target 'check-hdb' failed
> make[2]: *** [check-hdb] Segmentation fault
> make[2]: Leaving directory '/home/doko/tmp/tokyocabinet-1.4.48'
> Makefile:166: recipe for target 'check' failed
> make[1]: *** [check] Error 2
> make[1]: Leaving directory '/home/doko/tmp/tokyocabinet-1.4.48'
> dh_auto_test: make -j1 check returned exit code 2
> debian/rules:9: recipe for target 'build-arch' failed
> make: *** [build-arch] Error 2

Bug#811451: linux-grsec-base: Some useful confs

[Yves-Alexis Perez]

On mer., 2016-01-27 at 03:36 +, ban...@openmailbox.org wrote:
> On 2016-01-26 10:15, Yves-Alexis Perez wrote:
> > 
> > I don't touch any KVM settings so it /should/ work as is. Without more
> > information I can't do anything. Also please try not to report new 
> > stuff on
> > existing bugs.
> > 
> > Regards,
> 
> Right but for virtualization support I had to choose the hypervisor 
> explicitly in menuconfig otherwise it doesn't work. Grsec defaults to 
> support for baremetal without vtx.

In case it wasn't clear:

- please open a *different* bug
- please provide a tested patch for the configuration

Regards,
-- 
Yves-Alexis



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

Bug#812821: nmu: pam_1.1.8-3.1+deb8u1

[Adam D. Barratt]

On Wed, 2016-01-27 at 05:48 +, Adam D. Barratt wrote:
> Control: tags -1 + jessie
> 
> On Tue, 2016-01-26 at 15:28 -0800, Tianon Gravi wrote:
> > Due to some kind of mistake in my amd64 build environment (details being
> > tracked down in #812566) the amd64 build of pam_1.1.8-3.1+deb8u1 is the
> > only one that got the intended man page update, but this causes
> > co-installability issues (as detailed in #812566).  Getting a binNMU of
> > amd64 in the meantime would be great so that at least the packages line
> > up properly while we figure out what happened. :(
> > 
> > nmu pam_1.1.8-3.1+deb8u1 . amd64 . jessie . -m "Rebuild with correct build 
> > environment"
> 
> libpam0g is "Multi-Arch: same" so this will need to be binNMUed on all
> architectures (at least both of i386 and amd64) or we'll just end up
> with a different set of installability issues.

Is it just the manpage that's the issue? i.e. do the packages published
as part of the point release include the actual security fix?

Regards,

Adam

Bug#650601: libpng is ready for transition

[Tobias Frost]

Am Dienstag, den 26.01.2016, 22:25 + schrieb Gianfranco Costamagna:
> Hi Tobias
> 
> > +libpng1.6 (1.6.20-1.2)
> > unstable; urgency=medium
> 
> Do you want to go on unstable or it is a typo?
> 
> Gianfranco

Typo

Bug#812835: boinc-client: leaks hundreds of x11 connections

[Preston Maness]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Howdy all,

I've got a new PR open for upstream:

https://github.com/BOINC/boinc/pull/1478

And I've attached the patch in the meantime. The patch just closes the
connections that are opened to the Xservers. I had erroneously thought
that dropping out of scope of the function in hostinfo_unix.cpp would
close the connection automatically. With this patch, I don't see the
boinc client pilling up X11 connections like it was before.

Cheers,
Preston

On 01/26/2016 11:10 PM, Preston Maness wrote:
> Howdy,
> 
> I'm almost positive this is a bug introduced by my pull request to
> add XSS-based idle detection back into the boinc client:
> 
> https://github.com/BOINC/boinc/pull/1453
> 
> I am able to replicate the issue (seeing the number of socket 
> connections grow for the boinc process). Sorry about that. Looks
> like I didn't have a corresponding XCloseDisplay() to go with the 
> XOpenDisplay(). I'm going to re-open the PR with what I hope is a
> fix to this after testing it on my end.
> 
> Cheers, Preston
> 
> On 01/26/2016 07:54 PM, Dan Merillat wrote:
>> Package: boinc-client Version: 7.6.22+dfsg-1exp3 Severity: 
>> important
> 
>> Dear Maintainer,
> 
>> boinc-client caused "maximum number of clients reached" errors
>> on my system. xrestop showed 248 clients. Ran 'service
>> boinc-client stop' and the client count dropped to 28.
> 
>> Multiple reboots had the same problem - after a few minutes the 
>> client list would start filling up with  clients.
> 
>> I had installed boinc a long time ago, intending to use it but 
>> never set it up - no projects or work.  The problems began only 
>> after a reboot on Monday, but the last change was january 3:
> 
>> 2016-01-03 00:04:52 upgrade boinc-client:amd64 7.0.15+dfsg-1 
>> 7.6.22+dfsg-1
> 
>> The only explanation is that there was no reboot after that 
>> upgrade, so perhaps the client either did not start or remained 
>> running the old 7.0.15 version.
> 
>> I verified the boinc was the cause by purging boinc-client and 
>> re-installing from experimental - after a few minutes it leaked 
>> again:
> 
>> harik@dan:~$ sudo ls -l /proc/`pidof boinc`/fd total 0 lr-x--
>> 1 boinc boinc 64 Jan 26 18:50 0 -> /dev/null lrwx-- 1 boinc
>> boinc 64 Jan 26 18:50 1 -> socket:[88000] lrwx-- 1 boinc
>> boinc 64 Jan 26 18:50 10 -> socket:[127916] lrwx-- 1 boinc
>> boinc 64 Jan 26 18:50 100 -> socket:[129791] lrwx-- 1 boinc
>> boinc 64 Jan 26 18:50 101 -> socket:[129792] lrwx-- 1 boinc
>> boinc 64 Jan 26 18:50 102 -> socket:[129828] lrwx-- 1 boinc
>> boinc 64 Jan 26 18:50 103 -> socket:[129836] lrwx-- 1 boinc
>> boinc 64 Jan 26 18:50 104 -> socket:[130925] lrwx-- 1 boinc
>> boinc 64 Jan 26 20:42 105 -> socket:[131250] lrwx-- 1 boinc
>> boinc 64 Jan 26 20:42 106 -> socket:[131251] lrwx-- 1 boinc
>> boinc 64 Jan 26 18:50 107 -> socket:[131252] lrwx-- 1 boinc
>> boinc 64 Jan 26 18:50 108 -> socket:[131288] lrwx-- 1 boinc
>> boinc 64 Jan 26 18:50 109 -> socket:[131291] ... harik@dan:~$
>> sudo ls -l /proc/`pidof boinc`/fd | grep socket | wc -l 212
> 
>> Killing boinc dropped my client count from 242 to 33, and I
>> could open new windows again.
> 
>> -- System Information: Debian Release: stretch/sid APT prefers 
>> unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 
>> 'experimental') Architecture: amd64 (x86_64) Foreign
>> Architectures: i386, armel
> 
>> Kernel: Linux 4.2.0-dan (SMP w/4 CPU cores; PREEMPT) 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 boinc-client depends on: ii  adduser 
>> 3.113+nmu3 ii  ca-certificates20160104 ii  debconf 
>> [debconf-2.0]  1.5.58 ii  init-system-helpers1.27 ii
>> libboinc7 7.6.22+dfsg-1exp3 ii  libc6  2.21-7 ii
>> libcurl3 7.46.0-1+b1 ii  libgcc11:6-20160122-1
>> ii libstdc++6 6-20160122-1 ii  libx11-6 2:1.6.3-1 ii
>> libxss11:1.2.2-1 pn  python:any  ii  zlib1g
>> 1:1.2.8.dfsg-2+b1
> 
>> boinc-client recommends no packages.
> 
>> Versions of packages boinc-client suggests: pn
>> boinc-client-fglrx  pn  boinc-client-nvidia-cuda   pn
>> boinc-client-opencl  ii  boinc-manager
>> 7.6.22+dfsg-1exp3 ii x11-xserver-utils 7.7+5
> 
>> -- Configuration Files: /etc/boinc-client/gui_rpc_auth.cfg
>> [Errno 13] Permission denied:
>> u'/etc/boinc-client/gui_rpc_auth.cfg'
> 
>> -- debconf information: boinc-client/remove_boinc_dir: true
> 
> 
> 

-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJWqFmwAAoJEFpzcfOOuHp0Zm8P/jjPT7xYllLqpFr90DuxvCJZ
FHpfp10C2rbO752iqmAuYhbsWqIVo4y3AxKVKH5bOS+0OxAIeoIPm7BLDFwGeJOT
opkZEPHho7gpcWbE3EXT3FAW9MCWbbOQGn3aJPR3y9VQdsUtiNJHtcG1L8vcnX0Q
eEksLLRaGspV/HKg9UVwpEC7eIK02Bid/1GZHPgmroWucn8ix/mwl1V/xt5lcAq8
gnVlfIhmmQ1UTxI88UTeOOSVFNPQPuJ2WIRWjwZ7+GKv8HjHGuN6oaoT9sOFcn5Y
Vpi6G78e2DymQQE6QL+Td64fthp/Mixx2aHRrnluLW8h

Bug#812842: EnableLogging=1 doesn't have any effect

[Jon Forsberg]

Package: usb-modeswitch
Version: 2.2.0+repack0-2

According to the comments in /etc/usb_modeswitch.conf, setting
EnableLogging=1 should make i
produce a logfile in /var/log. When I invoke usb_modeswitch it does work
(switches mode of
my 3G dongle) but no logfile is created in /var/log.

This is how I invoke it:

usb_modeswitch --default-vendor=0x12d1 --default-product=0x1446 -J -Q

This is the config file:

# cat /etc/usb_modeswitch.conf

# Configuration for the usb_modeswitch package, a mode switching tool for
# USB devices providing multiple states or modes
#
# Evaluated by the wrapper script /usr/sbin/usb_modeswitch_dispatcher
#
# To enable an option, set it to "1", "yes" or "true" (case doesn't matter)
# Everything else counts as "disable"


# Disable automatic mode switching globally (e.g. to access the original
# install storage)

DisableSwitching=0


# Enable logging (results in a extensive report file in /var/log, named
# "usb_modeswitch_" and probably others

EnableLogging=1


# Optional increase of "delay_use" for the usb-storage driver; there are
hints
# that a recent kernel default change to 1 sec. may lead to problems,
particu-
# larly with USB 3.0 ports. Set this to at least 3 (seconds) in that case.
# Does nothing if the current system value is same or higher

#SetStorageDelay=4

Bug#812821: nmu: pam_1.1.8-3.1+deb8u1

[Adam D. Barratt]

Control: tags -1 + jessie

On Tue, 2016-01-26 at 15:28 -0800, Tianon Gravi wrote:
> Due to some kind of mistake in my amd64 build environment (details being
> tracked down in #812566) the amd64 build of pam_1.1.8-3.1+deb8u1 is the
> only one that got the intended man page update, but this causes
> co-installability issues (as detailed in #812566).  Getting a binNMU of
> amd64 in the meantime would be great so that at least the packages line
> up properly while we figure out what happened. :(
> 
> nmu pam_1.1.8-3.1+deb8u1 . amd64 . jessie . -m "Rebuild with correct build 
> environment"

libpam0g is "Multi-Arch: same" so this will need to be binNMUed on all
architectures (at least both of i386 and amd64) or we'll just end up
with a different set of installability issues.

Regards,

Adam

Bug#442363: ITP: php-db-dataobject -- SQL Builder, Object Interface to Database Tables

[Bhuvan Krishna]

control: owner -1 !
control: tag -1 moreinfo




signature.asc
Description: OpenPGP digital signature

Bug#812835: boinc-client: leaks hundreds of x11 connections

[Preston Maness]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Howdy,

I'm almost positive this is a bug introduced by my pull request to add
XSS-based idle detection back into the boinc client:

https://github.com/BOINC/boinc/pull/1453

I am able to replicate the issue (seeing the number of socket
connections grow for the boinc process). Sorry about that. Looks like
I didn't have a corresponding XCloseDisplay() to go with the
XOpenDisplay(). I'm going to re-open the PR with what I hope is a fix
to this after testing it on my end.

Cheers,
Preston

On 01/26/2016 07:54 PM, Dan Merillat wrote:
> Package: boinc-client Version: 7.6.22+dfsg-1exp3 Severity:
> important
> 
> Dear Maintainer,
> 
> boinc-client caused "maximum number of clients reached" errors on
> my system. xrestop showed 248 clients. Ran 'service boinc-client
> stop' and the client count dropped to 28.
> 
> Multiple reboots had the same problem - after a few minutes the
> client list would start filling up with  clients.
> 
> I had installed boinc a long time ago, intending to use it but
> never set it up - no projects or work.  The problems began only
> after a reboot on Monday, but the last change was january 3:
> 
> 2016-01-03 00:04:52 upgrade boinc-client:amd64 7.0.15+dfsg-1 
> 7.6.22+dfsg-1
> 
> The only explanation is that there was no reboot after that
> upgrade, so perhaps the client either did not start or remained
> running the old 7.0.15 version.
> 
> I verified the boinc was the cause by purging boinc-client and 
> re-installing from experimental - after a few minutes it leaked
> again:
> 
> harik@dan:~$ sudo ls -l /proc/`pidof boinc`/fd total 0 lr-x-- 1
> boinc boinc 64 Jan 26 18:50 0 -> /dev/null lrwx-- 1 boinc boinc
> 64 Jan 26 18:50 1 -> socket:[88000] lrwx-- 1 boinc boinc 64 Jan
> 26 18:50 10 -> socket:[127916] lrwx-- 1 boinc boinc 64 Jan 26
> 18:50 100 -> socket:[129791] lrwx-- 1 boinc boinc 64 Jan 26
> 18:50 101 -> socket:[129792] lrwx-- 1 boinc boinc 64 Jan 26
> 18:50 102 -> socket:[129828] lrwx-- 1 boinc boinc 64 Jan 26
> 18:50 103 -> socket:[129836] lrwx-- 1 boinc boinc 64 Jan 26
> 18:50 104 -> socket:[130925] lrwx-- 1 boinc boinc 64 Jan 26
> 20:42 105 -> socket:[131250] lrwx-- 1 boinc boinc 64 Jan 26
> 20:42 106 -> socket:[131251] lrwx-- 1 boinc boinc 64 Jan 26
> 18:50 107 -> socket:[131252] lrwx-- 1 boinc boinc 64 Jan 26
> 18:50 108 -> socket:[131288] lrwx-- 1 boinc boinc 64 Jan 26
> 18:50 109 -> socket:[131291] ... harik@dan:~$ sudo ls -l
> /proc/`pidof boinc`/fd | grep socket | wc -l 212
> 
> Killing boinc dropped my client count from 242 to 33, and I could
> open new windows again.
> 
> -- System Information: Debian Release: stretch/sid APT prefers
> unstable APT policy: (500, 'unstable'), (500, 'testing'), (1,
> 'experimental') Architecture: amd64 (x86_64) Foreign Architectures:
> i386, armel
> 
> Kernel: Linux 4.2.0-dan (SMP w/4 CPU cores; PREEMPT) 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 boinc-client depends on: ii  adduser
> 3.113+nmu3 ii  ca-certificates20160104 ii  debconf
> [debconf-2.0]  1.5.58 ii  init-system-helpers1.27 ii  libboinc7
> 7.6.22+dfsg-1exp3 ii  libc6  2.21-7 ii  libcurl3
> 7.46.0-1+b1 ii  libgcc11:6-20160122-1 ii
> libstdc++6 6-20160122-1 ii  libx11-6
> 2:1.6.3-1 ii  libxss11:1.2.2-1 pn  python:any
>  ii  zlib1g 1:1.2.8.dfsg-2+b1
> 
> boinc-client recommends no packages.
> 
> Versions of packages boinc-client suggests: pn  boinc-client-fglrx
>  pn  boinc-client-nvidia-cuda   pn  boinc-client-opencl
>  ii  boinc-manager 7.6.22+dfsg-1exp3 ii
> x11-xserver-utils 7.7+5
> 
> -- Configuration Files: /etc/boinc-client/gui_rpc_auth.cfg [Errno
> 13] Permission denied: u'/etc/boinc-client/gui_rpc_auth.cfg'
> 
> -- debconf information: boinc-client/remove_boinc_dir: true
> 

-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJWqFFTAAoJEFpzcfOOuHp0Mc0P/i/dUUYb8SpYLnCv42vB8eVp
Pn+I63MGaCNfMSMfWMBgxGJRuimpGwGQSN5euALT7AAoYW6kkzkyjv/hmXbxtUa3
hHgop7CpkR3ts89K+geQxxVjnFCwkTUadYDkhBU6ucvGWLvraZ39c6NZvyN0479Z
fu8YSN5VJemww6F5CBFy1lIVNBjhP2YBj7wI+VWp3xu+qkUScJyR8nSdFFbA3ksG
Is1fPR5f/0H85PcUrTebWlE0JnZ1ib/cd3s8R6sN6CJIQ8gsw3PeQqsLQNLso0te
l2MwNGwIDr6tZXh28VHwANS22n9RMAhpZlWF7CEWeClQV7v2ouhLPx1eB7xlu/oV
QddTQ21OHLf0iW1rxIKUYD670W7odebxBJ06aN2szr0btQiq/cQoYqDS5ej6Wvl+
ngLT5OP/u9sGZ2q/uItz4KxxsLohyYGXHGPe7M21y2oaMhfhyTIGs9qIaCLRMvoF
4HukBRgieuv8fMcGJxL0MqvJFk3Ui0o/OcWWQVMLhNm2jTpVVY03L5LY7Fc1793q
2lluWZvjbMp8mVzcdkp9oxYclN96mLuJbhWXJNkTUYa/RghiOyveQM1DtWnXb6jp
g1GcKJ9NoVuS/y/N8aM7eefendFZemcInIGYFZy5c1rNDyX5xOmXKAP28fuTVCq0
PLEt8pTvuY+KQNXkLJlf
=bXU9
-END PGP SIGNATURE-

Bug#812841: gitlab: Fails to install with 'invoke-rc.d: initscript gitlab, action "start" failed'.

[Viktor Malyarchuk]

Package: gitlab
Version: 8.4.0+dfsg~rc2-2
Severity: important

Dear Maintainer,

on a system with nginx (see #812724) and ruby-influxdb (see #812839) present 
gitlab still fails to install with

---
Administrator account created:

login.root
password..5iveL!fe
fatal: Not a git repository (or any of the parent directories): .git
fatal: Not a git repository (or any of the parent directories): .git
fatal: Not a git repository (or any of the parent directories): .git
mkdir -p /var/lib/gitlab/repositories/: OK
mkdir -p /usr/share/gitlab/.ssh: OK
chmod 700 /usr/share/gitlab/.ssh: OK
touch /usr/share/gitlab/.ssh/authorized_keys: OK
chmod 600 /usr/share/gitlab/.ssh/authorized_keys: OK
chmod ug+rwX,o-rwx /var/lib/gitlab/repositories/: OK
Precompiling assets...
Job for gitlab.service failed because the control process exited with error 
code. See "systemctl status gitlab.service" and "journalctl -xe" for details.
invoke-rc.d: initscript gitlab, action "start" failed.
dpkg: error processing package gitlab (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 gitlab
E: Sub-process /usr/bin/dpkg returned an error code (1)
---

---
sudo systemctl status gitlab.service -l
● gitlab.service - LSB: GitLab git repository management
   Loaded: loaded (/etc/init.d/gitlab; bad; vendor preset: enabled)
   Active: failed (Result: exit-code) since Tue 2016-01-26 22:14:03 CST; 19min 
ago
 Docs: man:systemd-sysv-generator(8)
  Process: 2485 ExecStart=/etc/init.d/gitlab start (code=exited, 
status=1/FAILURE)

Jan 26 22:14:03 radiance systemd[1]: Starting LSB: GitLab git repository 
management...
Jan 26 22:14:03 radiance su[2492]: Successful su for gitlab by root
Jan 26 22:14:03 radiance su[2492]: + ??? root:gitlab
Jan 26 22:14:03 radiance su[2492]: pam_unix(su:session): session opened for 
user gitlab by (uid=0)
Jan 26 22:14:03 radiance gitlab[2485]: Starting gitlab (via systemctl): 
gitlab.serviceFailed to start gitlab.service: Interactive authentication 
required.
Jan 26 22:14:03 radiance gitlab[2485]: failed!
Jan 26 22:14:03 radiance systemd[1]: gitlab.service: Control process exited, 
code=exited status=1
Jan 26 22:14:03 radiance systemd[1]: Failed to start LSB: GitLab git repository 
management.
Jan 26 22:14:03 radiance systemd[1]: gitlab.service: Unit entered failed state.
Jan 26 22:14:03 radiance systemd[1]: gitlab.service: Failed with result 
'exit-code'.
---

---
sudo journalctl -xe
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit UNIT has finished shutting down.
Jan 26 22:40:15 radiance systemd[3216]: Received SIGRTMIN+24 from PID 3234 
(kill).
Jan 26 22:40:15 radiance systemd[3217]: pam_unix(systemd-user:session): session 
closed for user gitlab
Jan 26 22:40:15 radiance systemd[1]: Stopped User Manager for UID 1000.
-- Subject: Unit user@1000.service has finished shutting down
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit user@1000.service has finished shutting down.
Jan 26 22:40:15 radiance systemd[1]: Removed slice User Slice of gitlab.
-- Subject: Unit user-1000.slice has finished shutting down
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit user-1000.slice has finished shutting down.
Jan 26 22:40:15 radiance sudo[2975]: pam_unix(sudo:session): session closed for 
user root
Jan 26 22:40:22 radiance sudo[3245]:   viktor : TTY=pts/1 ; PWD=/home/viktor ; 
USER=root ; COMMAND=/bin/journalctl -xe
Jan 26 22:40:22 radiance sudo[3245]: pam_unix(sudo:session): session opened for 
user root by viktor(uid=0)
---

Thank you very much for bringing gitlab to Debian!

Best regards,
Viktor


-- 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)
Foreign Architectures: i386

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

Versions of packages gitlab depends on:
ii  adduser3.113+nmu3
ii  asciidoctor1.5.3-1
ii  bc 1.06.95-9+b1
ii  debconf [debconf-2.0]  1.5.58
ii  gitlab-shell   2.6.10-1
ii  gitlab-workhorse   0.5.0-1
ii  libjs-chartjs  1.0.2-1
ii  libjs-clipboard1.4.2-1
ii  libjs-fuzzaldrin-plus  0.3.1-1
ii  libjs-graphael 0.5+dfsg-1
ii  libjs-jquery-cookie10-2
ii  libjs-jquery-history   10-2
ii  libjs-jquery-nicescroll3.6.6-

Bug#812840: Configures initramfs SSH login with locked root account

[martin f krafft]

Package: dropbear
Version: 2014.65-1
Severity: normal

After installing dropbear and adding DROPBEAR=y to initramfs.conf,
the system starts with dropbear listening on port 22/tcp alright.
Yay!

Even the SSH authorized_keys file is pre-populated, which is also
a nice touch.

Unfortunately, though, root login does not work. The reason is
discerned from running dropbear with -F -E and then seeing

  [149] Jan 27 04:05:09 User account 'root' is locked

I had a look around, and I think the problem is simply that
/etc/passwd defines /root as root's homedir, whereas initramfs
mounts the target system there at some stage! Changing the homedir
to /root/root enables logging in, but obviously requires /root to be
mounted.

Maybe the best would be to create /roothome during setup for the
purpose of this package?

Note that this applies to the stable package, i.e. before the
dropbox-initramfs split-off.

-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#746011: trackballs: updated for guile-2.0

[Rob Browning]

Hi, I've just uploaded a 1.1.4-4.2 NMU to Debian which includes an
initial conversion to Guile 2.0.

You can find the relevant patches in the debian/patches/ directory, or
here:

  https://git.debian.org/?p=users/rlb/trackballs.git

The patches that show up in debian/patches are also separate commits in
the (unnamed) branch that's merged in to sid.  If it's useful, I'd also
be happy to send you a patch series (suitable for "git am").

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#812839: gitlab: Fails to install. Should gitlab depend on ruby-influxdb?

[Viktor Malyarchuk]

Package: gitlab
Version: 8.4.0+dfsg~rc2-2
Severity: important

Dear Maintainer,

on a system with nginx present (see #812724) gitlab still fails to install with

Verifying we have all required libraries...
Could not find influxdb-0.2.3 in any of the sources
dpkg: error processing package gitlab (--configure):
 subprocess installed post-installation script returned error exit status 7

Should gitlab depend on ruby-influxdb?

Best regards,
Viktor

-- 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)
Foreign Architectures: i386

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

Versions of packages gitlab depends on:
ii  adduser3.113+nmu3
ii  asciidoctor1.5.3-1
ii  bc 1.06.95-9+b1
ii  debconf [debconf-2.0]  1.5.58
ii  gitlab-shell   2.6.10-1
ii  gitlab-workhorse   0.5.0-1
ii  libjs-chartjs  1.0.2-1
ii  libjs-clipboard1.4.2-1
ii  libjs-fuzzaldrin-plus  0.3.1-1
ii  libjs-graphael 0.5+dfsg-1
ii  libjs-jquery-cookie10-2
ii  libjs-jquery-history   10-2
ii  libjs-jquery-nicescroll3.6.6-1
ii  nodejs 5.5.0~dfsg-1
ii  postgresql 9.5+172
ii  postgresql-client-9.5 [postgresql-client]  9.5.0-2
ii  redis-server   2:3.2~rc1-3
ii  ruby   1:2.2.4
ii  ruby-ace-rails-ap  3.0.3-2
ii  ruby-activerecord-deprecated-finders   1.0.4-1
ii  ruby-activerecord-session-store0.1.1-2
ii  ruby-acts-as-taggable-on   3.5.0-2
ii  ruby-addressable   2.3.8-1
ii  ruby-after-commit-queue1.3.0-1
ii  ruby-allocations   1.0.3-1
ii  ruby-asana 0.4.0-1
ii  ruby-babosa1.0.2-1
ii  ruby-bootstrap-sass3.3.5.1-3
ii  ruby-browser   1.0.1-1
ii  ruby-cal-heatmap-rails 3.5.1+dfsg-1
ii  ruby-carrierwave   0.10.0+gh-1
ii  ruby-charlock-holmes   0.7.3+dfsg-2
ii  ruby-coffee-rails  4.1.0-2
ii  ruby-colored   1.2-2
ii  ruby-colorize  0.7.7-1
ii  ruby-creole0.5.0-2
ii  ruby-d3-rails  3.5.6+dfsg-1
ii  ruby-default-value-for 3.0.1-1
ii  ruby-devise3.5.2-3
ii  ruby-devise-async  0.9.0-1
ii  ruby-devise-two-factor 2.0.0-1
ii  ruby-diffy 3.0.6-1
ii  ruby-doorkeeper2.2.1-1
ii  ruby-dropzonejs-rails  0.7.1-1
ii  ruby-email-reply-parser0.5.8-1
ii  ruby-enumerize 1.0.0-1
ii  ruby-fog   1.34.0-2
ii  ruby-fogbugz   0.2.1-2
ii  ruby-font-awesome-rails4.3.0.0-1
ii  ruby-gemnasium-gitlab-service  0.2.6-1
ii  ruby-github-linguist   4.7.2-1
ii  ruby-github-markup 1.3.3+dfsg-1
ii  ruby-gitlab-emoji  0.2.1-1
ii  ruby-gitlab-flowdock-git-hook  1.0.1-1
ii  ruby-gitlab-git7.2.22-1
ii  ruby-gollum-lib4.1.0-3
ii  ruby-gon   6.0.1-1
ii  ruby-grack 2.0.2-1
ii  ruby-grape 0.13.0-1
ii  ruby-grape-entity  0.4.5-1
ii  ruby-haml-rails0.9.0-4
ii  ruby-hipchat   1.5.2-1
ii  ruby-html-pipeline 1.11.0-1
ii  ruby-httparty  0.13.5-1
ii  ruby-jquery-atwho-rails1.3.2-2
ii  ruby-jquery-rails  4.0.5-1
ii  ruby-jquery-scrollto-rails 1.4.3+dfsg-1
ii  ruby-jquery-turbolinks 2.1.0~dfsg-1
ii  ruby-jquery-ui-rails   5.0.5-3
ii  ruby-kaminari  0.16.3-1
ii  ruby-mail-room 0.6.1-1
ii  ruby-method-source 0.8.2-2
ii  ruby-mousetrap-rails   1.4.6-4

Bug#812838: docker.io: please package 1.9.0 or later

[Olaf Meeuwissen]

Package: docker.io
Version: 1.8.3~ds1-2
Severity: normal

Dear Maintainer,

The 1.9.0 release introduces support for `docker build` environment
variables that are not persisted.  This should finally solve all my
"build behind a proxy" issues.

See https://github.com/docker/docker/blob/master/CHANGELOG.md#builder-1
and https://github.com/docker/docker/pull/15182 for details.

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

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

Versions of packages docker.io depends on:
ii  adduser  3.113+nmu3
ii  init-system-helpers  1.24
ii  iptables 1.4.21-2+b1
ii  libapparmor1 2.10-2+b2
ii  libc62.21-6
ii  libdevmapper1.02.1   2:1.02.114-1
ii  libsqlite3-0 3.9.2-1
ii  perl 5.22.1-4

Versions of packages docker.io recommends:
ii  ca-certificates  20160104
ii  cgroupfs-mount   1.2
ii  git  1:2.7.0~rc3-1
ii  xz-utils 5.1.1alpha+20120614-2.1

Versions of packages docker.io suggests:
ii  aufs-tools   1:3.2+20130722-1.1
pn  btrfs-tools  
ii  debootstrap  1.0.75
pn  lxc  
pn  rinse
pn  zfs-fuse | zfsutils  

-- Configuration Files:
/etc/default/docker changed:
DOCKER_OPTS="--bip 172.16.42.1/16 --storage-driver overlay"
export http_proxy="http://localhost:3128/";


-- no debconf information

-- 
Olaf Meeuwissen, LPIC-2   FLOSS Engineer -- EPSON AVASYS CORPORATION
   Free Software Foundation Associate Member since 2004-01-27
Support Free Software  https://my.fsf.org/donate
Support the Free Software Foundation https://my.fsf.org/join

Bug#812818: should dipy be removeed from debian?

[Yaroslav Halchenko]

On Tue, 26 Jan 2016, Mattia Rizzolo wrote:

> As of now there are 2 RC bugs, the package is not in testing, there are
> no reverse (build-)dependencies and the the popcon is resonably low.

> Please, can you consider maintaining the package?  Keeping an unusable
> thing in the archive is not going to help our users in any way.

Thanks for the buzz... we will fix it up in upcoming days

Cheers!

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#812782: dpkg: Please add hardened1-linux-amd64 port

[Balint Reczey]

Hi,

On Tue, 26 Jan 2016 15:23:43 +0100 Balint Reczey
 wrote:
...
> I'm working towards making the port ready for being accepted to Debian
> and the attached patch is the one adding the port to dpkg.

I forgot adding one more patch in my previous email.

Cheers,
Balint
>From 4428399dc197cd57a06a56640496443ff8ad90a3 Mon Sep 17 00:00:00 2001
From: Balint Reczey 
Date: Wed, 27 Jan 2016 04:35:01 +0100
Subject: [PATCH] Fix tests after adding hardened1-linux-

---
 scripts/t/Dpkg_Arch.t | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/t/Dpkg_Arch.t b/scripts/t/Dpkg_Arch.t
index b57a0cf..dcfd193 100644
--- a/scripts/t/Dpkg_Arch.t
+++ b/scripts/t/Dpkg_Arch.t
@@ -98,7 +98,7 @@ is(gnutriplet_to_debarch(undef), undef, 'undef gnutriplet');
 is(gnutriplet_to_debarch('unknown-unknown-unknown'), undef, 'unknown gnutriplet');
 is(gnutriplet_to_debarch('x86_64-linux-gnu'), 'amd64', 'known gnutriplet');
 
-is(scalar get_valid_arches(), 417, 'expected amount of known architectures');
+is(scalar get_valid_arches(), 446, 'expected amount of known architectures');
 
 {
 local $ENV{CC} = 'false';
-- 
2.1.4

Bug#812837: Patch to provide additional functionality for using IF-MIB::ifName

[Stephane Lapie]

Here is a patch for a -N/--use-ifname option that will switch from
IF-MIB::ifDescr to IF-MIB::ifName when looking up the interface's name.

This would enable users of nagios-snmp-plugins to tune whether they want to
match interfaces based on the description, or on the name.
-- 
ラピー ステファン Lapie Stephane
株式会社朝日ネット システム第1部
〒104-0061 東京都中央区銀座4-12-15 歌舞伎座タワー21F
TEL : 03-3541-9590(代表) 03-3541-9591(直通) FAX : 03-3541-5633
E-MAIL: stephane.la...@asahinet.com
--- /tmp/check_snmp_int.pl	2016-01-27 11:24:26.144765849 +0900
+++ /tmp/check_snmp_int.pl.new	2016-01-27 11:47:40.904312037 +0900
@@ -31,6 +31,7 @@
 my $inter_table= '.1.3.6.1.2.1.2.2.1';
 my $index_table = '1.3.6.1.2.1.2.2.1.1';
 my $descr_table = '1.3.6.1.2.1.2.2.1.2';
+my $name_table = '1.3.6.1.2.1.31.1.1.1.1';
 my $oper_table = '1.3.6.1.2.1.2.2.1.8.';
 my $admin_table = '1.3.6.1.2.1.2.2.1.7.';
 my $speed_table = '1.3.6.1.2.1.2.2.1.5.';
@@ -81,6 +82,7 @@
 my $o_meg=		undef; # output in MBytes or Mbits (-M)
 my $o_gig=		undef; # output in GBytes or Gbits (-G)
 my $o_prct=		undef; # output in % of max speed  (-u)
+my $o_use_ifname=	undef;  # use IF-MIB::ifName instead of IF-MIB::ifDescr
 
 my $o_timeout=  undef; 		# Timeout (Default 5)
 # SNMP Message size parameter (Makina Corpus contrib)
@@ -190,6 +192,8 @@
Test it before, because there are known bugs (ex : trailling /)
 -r, --noregexp
Do not use regexp to match NAME in description OID
+-N, --use-ifname
+   Use IF-MIB::ifName as source for NIC name instead of IF-MIB::ifDescr
 -i, --inverse
Make critical when up
 -a, --admin
@@ -257,6 +261,7 @@
 'H:s'   => \$o_host,		'hostname:s'	=> \$o_host,
 'p:i'   => \$o_port,   		'port:i'	=> \$o_port,
 	'n:s'   => \$o_descr,   'name:s'=> \$o_descr,
+	'N'	=> \$o_use_ifname,	'use-ifname'	=> \$o_use_ifname,
 'C:s'   => \$o_community,	'community:s'	=> \$o_community,
 		'2'	=> \$o_version2,	'v2c'		=> \$o_version2,		
 	'l:s'	=> \$o_login,		'login:s'	=> \$o_login,
@@ -446,9 +451,13 @@
 	verb(" new max octets:: $oct_test");
 }
 
-# Get desctiption table
+# Get description table
+my $query_table = $descr_table;
+if (defined($o_use_ifname)) {
+	$query_table = $name_table;
+}
 my $resultat = $session->get_table( 
-	Baseoid => $descr_table 
+	Baseoid => $query_table
 );
 
 if (!defined($resultat)) {

Bug#811451: linux-grsec-base: Some useful confs

[bancfc]

On 2016-01-26 10:15, Yves-Alexis Perez wrote:


I don't touch any KVM settings so it /should/ work as is. Without more
information I can't do anything. Also please try not to report new 
stuff on

existing bugs.

Regards,


Right but for virtualization support I had to choose the hypervisor 
explicitly in menuconfig otherwise it doesn't work. Grsec defaults to 
support for baremetal without vtx.

Bug#812837: nagios-snmp-plugins: check_snmp_int.pl can only check IF-MIB::ifDescr when in some cases it should check IF-MIB::ifName

[Stephane Lapie]

Package: nagios-snmp-plugins
Version: 1.1.1-11
Severity: wishlist

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

Net-SNMP's snmpd daemon has changed behavior in Debian Jessie,
returning detailed information about the network interfaces in the
IF-MIB::ifDescr MIB.
The original information is still available via IF-MIB::ifName, but
check_snmp_int.pl does not check it.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Can be reproduced with the following command :
$ /usr/lib/nagios/plugins/check_snmp_int.pl -H testmachine.local -C
haragahetta -2 -n ".*" -N -v -w 80 -c 90

   * What was the outcome of this action?

Alarm at 15 + 5
SNMP v2c login
Filter : .*
OID : 1.3.6.1.2.1.2.2.1.2.1, Desc : lo
Name : lo, Index : 1
OID : 1.3.6.1.2.1.2.2.1.2.2, Desc : Broadcom Corporation NetXtreme II
BCM5709 Gigabit Ethernet
Name : Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet, Index : 2
OID : 1.3.6.1.2.1.2.2.1.2.4, Desc : bond0
Name : bond0, Index : 4
OID : 1.3.6.1.2.1.2.2.1.2.3, Desc : Broadcom Corporation NetXtreme II
BCM5709 Gigabit Ethernet
Name : Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet, Index : 3
lo:UP, Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet:UP,
bond0:UP, Broadcom Corporation NetXtreme II BCM5709 Gigabit
Ethernet:UP:4 UP: OK

   * What outcome did you expect instead?

Alarm at 15 + 5
SNMP v2c login
Filter : .*
OID : 1.3.6.1.2.1.31.1.1.1.1.2, Desc : eth0
Name : eth0, Index : 2
OID : 1.3.6.1.2.1.31.1.1.1.1.4, Desc : bond0
Name : bond0, Index : 4
OID : 1.3.6.1.2.1.31.1.1.1.1.3, Desc : eth1
Name : eth1, Index : 3
OID : 1.3.6.1.2.1.31.1.1.1.1.1, Desc : lo
Name : lo, Index : 1
eth0:UP, bond0:UP, eth1:UP, lo:UP:4 UP: OK

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


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

Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages nagios-snmp-plugins depends on:
ii  libnet-snmp-perl   6.0.1-2
ii  monitoring-plugins-common  2.1.1-1
ii  nagios-plugins-basic   2.1.1-1
ii  perl   5.20.2-3+deb8u2
ii  perl-base  5.20.2-3+deb8u2
ii  ucf3.0030

Versions of packages nagios-snmp-plugins recommends:
pn  libcrypt-des-perl   
pn  libcrypt-rijndael-perl  

nagios-snmp-plugins suggests no packages.

-- no debconf information

Bug#794499: Workaround 2

[Maximilian Stein]

I noticed that just the entry in the application menu is not found, so I
added the kdeconnect manually.

Until switching to plasma5 fixing the menu entry would do it, in my
opinion. That way the program stays usuable for everyone.

Best,
-- 

Maximilian Stein
E-Mail: m...@steiny.biz 



signature.asc
Description: OpenPGP digital signature

Bug#810726: linux-image-4.3.0-1-amd64: Kernel 4.3 breaks Hauppauge HD-PVR recording

[David Engel]

On Tue, Jan 26, 2016 at 11:06:53PM -0300, Javier Martinez Canillas wrote:
> Hello David,
> 
> Sorry for the late response.

Hi Javier,

No problem.

> On 01/20/2016 04:41 PM, David Engel wrote:
> >Javier and Mauro, this is in regards to Debian bug #810726, which I
> >filed last week.  I also informed Hans about it at that time.
> >
> >Using git bisect, I finally identified the attached commit as the
> >offending one.  Sure enough, after reverting that change, my hdpvr
> >behaves reliably with the 4.3.3 kernel.  Further testing has revealed
> >that I can achieve the same result with the standard, Debian kernel by
> >blacklisting the ir_kbd_i2c module.
> >
> 
> The attached commit is only fixing module autoloading for the I2C driver
> so is just exposing a existent bug. If you built the driver in the image
> instead of as a module, the bug should be present even with that commit
> reverted.

Yes, I realize that.  The thing is the LIRC receive support on the
hdpvr has been notoriously flaky, at least in MythTV circles, and
often causes recording instability.  Previously, with the autoloading
bug, most hdpvr users weren't affected by it unless they manually
loaded the appropriate LIRC modules.  Now, with the autoloading bug
fixed, many unsuspecting hdpvr users will experience the instability
when upgrading kernels.

> >It seems something in the IR initialization is causing the hdpvr to
> >become unreliable.  This is even when the IR support is not used nor
> >wanted.  Additionally, blacklisting the lirc_zilog module is not
> >sufficient to work around the problem, nor is keeping it but using the
> >tx_only=1 parameter.
> >
> 
> I believe the root cause has to be found since as I said, it was only
> working because the module didn't have the module alias information so
> udev/kmod were not able to load the module when the kernel report the
> MODALIAS uevent when the I2C device was registered.

I agree the root cause needs to be found.  Personally, I think it
would be better to disable the LIRC support in some way by default
until the underlying problem can be fixed, but that's your call.
There is a work around with blacklisting the ir-kbd-i2c module, so
perhaps making sure that is more widely known is sufficient.

Anyway, I can offer my help in testing any fixes you come up with.

David
-- 
David Engel
da...@istwok.net

Bug#812836: ITP: sahara-dashboard -- OpenStack data processing cluster as a service - dashboard plugin

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: sahara-dashboard
  Version : 4.0.0~b2
  Upstream Author : OpenStack Foundation 
* URL : https://github.com/openstack/sahara-dashboard
* License : Apache-2.0
  Programming Lang: Python
  Description : OpenStack data processing cluster as a service - dashboard 
plugin

 The Sahara project provides a simple means to provision a data-intensive
 application cluster (Hadoop or Spark) on top of OpenStack. It's the ex
 Savanna project, renamed due to potential trademark issues.
 .
 This package contains the OpenStack dashboard plugin.

Bug#812741: neovim: Please don't build-depend on luajit on unsupported architectures

[James McCoy]

On Tue, Jan 26, 2016 at 10:03:31AM +0100, John Paul Adrian Glaubitz wrote:
> neovim is currently BD-Uninstallable on a number of architectures which
> are not supported by luajit [1]. I would therefore like to ask to limit
> the list of architectures for which neovim build-depends on libluajit-5.1-dev,
> similar to what haskell-hslua does [2].

Neovim's build system explicitly links against libluajit, so that's not
an option currently.  I'll talk with upstream to figure out if it really
is a required dependency.

Cheers,
-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy 

Bug#812737: neovim: python-neovim is recommended

[James McCoy]

Control: block 812737 by 808176

On Tue, Jan 26, 2016 at 09:33:54AM +0100, Ph. Marek wrote:
> In
> :help nvim-from-vim
> the documentation basically requires (or, at least, strongly recommends) 
> a python-neovim package - but that isn't available (yet).

This is in the process of being packaged.  Once that's done, I'll add it
as a Recommended package.

Cheers,
-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy 

Bug#812835: boinc-client: leaks hundreds of x11 connections

[Dan Merillat]

Package: boinc-client
Version: 7.6.22+dfsg-1exp3
Severity: important

Dear Maintainer,

boinc-client caused "maximum number of clients reached" errors on my system.
xrestop showed 248 clients. Ran 'service boinc-client stop' and the client
count dropped to 28.

Multiple reboots had the same problem - after a few minutes the client
list would start filling up with  clients.

I had installed boinc a long time ago, intending to use it but never set
it up - no projects or work.  The problems began only after a reboot on
Monday, but the last change was january 3:

2016-01-03 00:04:52 upgrade boinc-client:amd64 7.0.15+dfsg-1
7.6.22+dfsg-1

The only explanation is that there was no reboot after that upgrade, so
perhaps the client either did not start or remained running the old
7.0.15 version.  

I verified the boinc was the cause by purging boinc-client and
re-installing from experimental - after a few minutes it leaked again:

harik@dan:~$ sudo ls -l /proc/`pidof boinc`/fd
total 0
lr-x-- 1 boinc boinc 64 Jan 26 18:50 0 -> /dev/null
lrwx-- 1 boinc boinc 64 Jan 26 18:50 1 -> socket:[88000]
lrwx-- 1 boinc boinc 64 Jan 26 18:50 10 -> socket:[127916]
lrwx-- 1 boinc boinc 64 Jan 26 18:50 100 -> socket:[129791]
lrwx-- 1 boinc boinc 64 Jan 26 18:50 101 -> socket:[129792]
lrwx-- 1 boinc boinc 64 Jan 26 18:50 102 -> socket:[129828]
lrwx-- 1 boinc boinc 64 Jan 26 18:50 103 -> socket:[129836]
lrwx-- 1 boinc boinc 64 Jan 26 18:50 104 -> socket:[130925]
lrwx-- 1 boinc boinc 64 Jan 26 20:42 105 -> socket:[131250]
lrwx-- 1 boinc boinc 64 Jan 26 20:42 106 -> socket:[131251]
lrwx-- 1 boinc boinc 64 Jan 26 18:50 107 -> socket:[131252]
lrwx-- 1 boinc boinc 64 Jan 26 18:50 108 -> socket:[131288]
lrwx-- 1 boinc boinc 64 Jan 26 18:50 109 -> socket:[131291]
...
harik@dan:~$ sudo ls -l /proc/`pidof boinc`/fd | grep socket | wc -l
212

Killing boinc dropped my client count from 242 to 33, and I could open
new windows again.

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

Kernel: Linux 4.2.0-dan (SMP w/4 CPU cores; PREEMPT)
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 boinc-client depends on:
ii  adduser3.113+nmu3
ii  ca-certificates20160104
ii  debconf [debconf-2.0]  1.5.58
ii  init-system-helpers1.27
ii  libboinc7  7.6.22+dfsg-1exp3
ii  libc6  2.21-7
ii  libcurl3   7.46.0-1+b1
ii  libgcc11:6-20160122-1
ii  libstdc++6 6-20160122-1
ii  libx11-6   2:1.6.3-1
ii  libxss11:1.2.2-1
pn  python:any 
ii  zlib1g 1:1.2.8.dfsg-2+b1

boinc-client recommends no packages.

Versions of packages boinc-client suggests:
pn  boinc-client-fglrx
pn  boinc-client-nvidia-cuda  
pn  boinc-client-opencl   
ii  boinc-manager 7.6.22+dfsg-1exp3
ii  x11-xserver-utils 7.7+5

-- Configuration Files:
/etc/boinc-client/gui_rpc_auth.cfg [Errno 13] Permission denied: 
u'/etc/boinc-client/gui_rpc_auth.cfg'

-- debconf information:
  boinc-client/remove_boinc_dir: true

Bug#810726: linux-image-4.3.0-1-amd64: Kernel 4.3 breaks Hauppauge HD-PVR recording

[Javier Martinez Canillas]

Hello David,

Sorry for the late response.

On 01/20/2016 04:41 PM, David Engel wrote:

Javier and Mauro, this is in regards to Debian bug #810726, which I
filed last week.  I also informed Hans about it at that time.

Using git bisect, I finally identified the attached commit as the
offending one.  Sure enough, after reverting that change, my hdpvr
behaves reliably with the 4.3.3 kernel.  Further testing has revealed
that I can achieve the same result with the standard, Debian kernel by
blacklisting the ir_kbd_i2c module.



The attached commit is only fixing module autoloading for the I2C driver
so is just exposing a existent bug. If you built the driver in the image
instead of as a module, the bug should be present even with that commit
reverted.


It seems something in the IR initialization is causing the hdpvr to
become unreliable.  This is even when the IR support is not used nor
wanted.  Additionally, blacklisting the lirc_zilog module is not
sufficient to work around the problem, nor is keeping it but using the
tx_only=1 parameter.



I believe the root cause has to be found since as I said, it was only
working because the module didn't have the module alias information so
udev/kmod were not able to load the module when the kernel report the
MODALIAS uevent when the I2C device was registered.


David



Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America

Bug#790727: libmail-sender-perl: followup on bug report

[Adam Di Carlo]

I'm not the submitted but just an affected user.  Affects me quite
seriously now, I'm getting a compilation error just as perl uses the
module.  Perl update must have turned a deprecation warning to an error?

The following patch is against version 0.8.16-2.

This may be fixed upstream as well, I don't know...

-- 
...Adam Di Carlo..http://www.onshored.com/>
--- /usr/share/perl5/Mail/Sender.pm.orig	2016-01-26 20:28:09.192750941 -0500
+++ /usr/share/perl5/Mail/Sender.pm	2016-01-26 20:37:19.136913560 -0500
@@ -315,7 +315,7 @@
 sub __Debug {
 	my ($socket, $file) = @_;
 	if (defined $file) {
-		unless (defined @Mail::Sender::DBIO::ISA) {
+		unless (@Mail::Sender::DBIO::ISA) {
 			eval "use Symbol;";
 			eval $debug_code;
 			die $@ if $@;
@@ -2545,7 +2545,9 @@
 #	if (!defined($self->{'smtpaddr'})) { return $self->Error(HOSTNOTFOUND($self->{'smtp'})); }
 
 	if (exists $self->{'on_errors'} and (!defined($self->{'on_errors'}) or $self->{'on_errors'} eq 'undef')) {
-		return $self->Connect() and $self->Close() and 1;
+		if ($self->Connect() and $self->Close()) {
+  			return 1;
+		}
 	} elsif (exists $self->{'on_errors'} and $self->{'on_errors'} eq 'die') {
 		$self->Connect();
 		$self->Close();
@@ -2690,7 +2692,7 @@
 package Mail::Sender;
 sub GetHandle {
 	my $self = shift();
-	unless (defined @Mail::Sender::IO::ISA) {
+	unless (@Mail::Sender::IO::ISA) {
 		eval "use Symbol;";
 		eval $pseudo_handle_code;
 	}

Bug#812555: gnome-session-flashback (temporary) black screen

[Massimo Martelli]

I'm sorry I thought you meant THIS one: https://git.gnome.org/browse/at
-spi2-core/commit/bus?id=2a70ba6bf83a675664cda8f68f2d1e815612db53
That's the commented line I was talking about. Anyway tomorrow I'll
apply the patch and try again.
I really don't know what to say about it starting even if it's not
enabled, but I'm sure I'm not mistaken about it.
Anything else I can check to help you find the cause?

Bug#812555: gnome-session-flashback (temporary) black screen

[Alberts Muktupāvels]

On Wed, Jan 27, 2016 at 3:33 AM, Massimo Martelli 
wrote:

> Looks like you were half right about accessibility.
> From the logs I found out this:
> gnome-session-binary[4732]: WARNING: Application 'at-spi-dbus-
> bus.desktop' failed to register before timeout
> appearing right after the black screen. Anyway I do have accessibility
> disabled (triple-checked) and it's weird that other gnome sessions work
>

It would be nice to understand why it was autostarted even if it was
disabled...


> fine. What's even weirder is that it looks like my at-spi-dbus-
> bus.desktop already has that line not commented so the patch is not
> needed.
>

What line commented out?


> For now, since I don't use it, I worked around the issue moving the at-
> spi-dbus-bus.desktop file out of the way. Thank you so much for your
> kind help, I guess I'll have to report to the gnome bugtracker for this
> issue :)
>

gnome-session should start it only if it is enabled:
AutostartCondition=GSETTINGS org.gnome.desktop.interface
toolkit-accessibility

Failed to register before timeout was fixed today (master):
https://git.gnome.org/browse/at-spi2-core/commit/?id=d4ae614301bbc7f7204dab795cbd6f1289c401d2

and gnome-3-18 branch:
https://git.gnome.org/browse/at-spi2-core/commit/?h=gnome-3-18

-- 
Alberts Muktupāvels

Bug#812834: gcc-5: Please add support for hardened1-linux-amd64

[Balint Reczey]

Package: gcc-5
Version: 5.3.1-7
Severity: wishlist
Tags: patch
User: bal...@balintreczey.hu
Usertags: hardened1-linux-amd64

Dear GCC Maintainers,

I have successfully bootstrapped the hardened1-linux-amd64 [1]
port using a set of patches [2].
I'm working towards making the port ready for being accepted to
Debian and the attached patches are adding the port support to
GCC.

The first patch allows cross building GCC to a port enabling PIE
by default from a host witout PIE by default.
It may be useful on its own.

Dpkg support for the port is being discussed in #812782.

Accepting this patch would make (re-)bootstrapping the new
port easier.

Thank you in advance,
Balint

[1] 
http://balintreczey.hu/blog/proposing-amd64-hardened-architecture-for-debian/
[2] https://anonscm.debian.org/cgit/users/rbalint/rebootstrap.git/

>From f1d664b0ae440163d85f85ab6f014ad6d7daab4c Mon Sep 17 00:00:00 2001
From: Balint Reczey 
Date: Mon, 25 Jan 2016 17:56:30 +0100
Subject: [PATCH 1/3] Re-enable -fPIC when -fno-PIE is used in bootstrapping

---
 debian/patches/gcc-configure-pie.diff | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/patches/gcc-configure-pie.diff b/debian/patches/gcc-configure-pie.diff
index 7abe92a..f58ccf3 100644
--- a/debian/patches/gcc-configure-pie.diff
+++ b/debian/patches/gcc-configure-pie.diff
@@ -381,7 +381,7 @@ Index: b/src/gcc/Makefile.in
  	echo INHIBIT_LIBC_CFLAGS = '$(INHIBIT_LIBC_CFLAGS)' >> tmp-libgcc.mvars
  	echo TARGET_SYSTEM_ROOT = '$(TARGET_SYSTEM_ROOT)' >> tmp-libgcc.mvars
 +	if test @enable_default_pie@ = yes; then \
-+	  NO_PIE_CFLAGS="-fno-PIE"; \
++	  NO_PIE_CFLAGS="-fno-PIE -fPIC"; \
 +	else \
 +	  NO_PIE_CFLAGS=; \
 +	fi; \
-- 
2.1.4

>From 568bc9d19bdf9dbe505e7904fdc2ddd22ba9e767 Mon Sep 17 00:00:00 2001
From: Balint Reczey 
Date: Mon, 25 Jan 2016 19:23:23 +0100
Subject: [PATCH 2/3] Add support for hardened1-linux-amd64 architecture

---
 debian/libasan2.symbols |  4 ++--
 debian/rules.defs   | 37 ++---
 debian/rules2   |  2 +-
 3 files changed, 25 insertions(+), 18 deletions(-)

diff --git a/debian/libasan2.symbols b/debian/libasan2.symbols
index fa170da..23a06a7 100644
--- a/debian/libasan2.symbols
+++ b/debian/libasan2.symbols
@@ -1,7 +1,7 @@
 libasan.so.2 libasan2 #MINVER#
 #include "libasan.symbols.common"
-(arch=!arm64 !alpha !amd64 !ia64 !ppc64 !ppc64el !s390x !sparc64 !kfreebsd-amd64)#include "libasan.symbols.32"
-(arch=arm64 alpha amd64 ia64 ppc64 ppc64el s390x sparc64 kfreebsd-amd64)#include "libasan.symbols.64"
+(arch=!arm64 !alpha !amd64 !ia64 !ppc64 !ppc64el !s390x !sparc64 !kfreebsd-amd64 !hardened1-linux-amd64)#include "libasan.symbols.32"
+(arch=arm64 alpha amd64 ia64 ppc64 ppc64el s390x sparc64 kfreebsd-amd64 hardened1-linux-amd64)#include "libasan.symbols.64"
 (arch=armel armhf sparc64 x32)#include "libasan.symbols.16"
 # these are missing on some archs ...
  (arch=!arm64 !armel !armhf !powerpc !ppc64 !ppc64el !sparc !sparc64)__interceptor_ptrace@Base 4.9
diff --git a/debian/rules.defs b/debian/rules.defs
index a108f12..6d775f1 100644
--- a/debian/rules.defs
+++ b/debian/rules.defs
@@ -418,7 +418,7 @@ multiarch_xarch_map = \
 	amd64=i386-linux-gnu,x86_64-linux-gnux32 \
 	armel=arm-linux-gnueabi \
 	armhf=arm-linux-gnueabihf \
-	i386=x86_64-linux-gnu,x86_64-linux-gnux32 \
+	i386=x86_64-linux-gnu,x86_64-linux-gnux32,x86_64-linux-gnuhardened1 \
 	powerpc=powerpc64-linux-gnu \
 	ppc64=powerpc-linux-gnu \
 	sparc=sparc64-linux-gnu \
@@ -431,8 +431,9 @@ multiarch_xarch_map = \
 	mipsn32el=mipsel-linux-gnu,mips64el-linux-gnuabi64 \
 	mips64=mips-linux-gnu,mips64-linux-gnuabin32 \
 	mips64el=mipsel-linux-gnu,mips64el-linux-gnuabin32 \
-	x32=x86_64-linux-gnu,i386-linux-gnu \
-	kfreebsd-amd64=i386-kfreebsd-gnu
+	x32=x86_64-linux-gnu,i386-linux-gnu, x86_64-linux-gnuhardened1 \
+	kfreebsd-amd64=i386-kfreebsd-gnu \
+	hardened1-linux-amd64=i386-linux-gnu,x86_64-linux-gnux32
 xarch_multiarch_names = $(subst $(COMMA),$(SPACE),$(patsubst $(DEB_TARGET_ARCH)=%,%, \
 		$(filter $(DEB_TARGET_ARCH)=%,$(multiarch_xarch_map
 
@@ -464,7 +465,8 @@ multilib_multiarch_map = \
 	mips64el/n32=mips64el-linux-gnuabin32 \
 	x32/32=i386-linux-gnu \
 	x32/64=x86_64-linux-gnu \
-	kfreebsd-amd64/32=i386-kfreebsd-gnu
+	kfreebsd-amd64/32=i386-kfreebsd-gnu \
+	hardened1-linux-amd64/32=i386-linux-gnu
 # $(call mlib_to_march,|32|64|n32|x32|hf|sf)
 mlib_to_march = $(patsubst $(DEB_TARGET_ARCH)/$(1)=%,%, \
 		   $(filter $(DEB_TARGET_ARCH)/$(1)=%,$(multilib_multiarch_map)))
@@ -927,7 +929,7 @@ ifeq ($(with_d)-$(with_separate_gdc),yes-yes)
 endif
 
 ifeq ($(with_d),yes)
-  libphobos_archs = amd64 armel armhf i386 x32 kfreebsd-amd64 kfreebsd-i386
+  libphobos_archs = amd64 hardened1-linux-amd64 armel armhf i386 x32 kfreebsd-amd64 kfreebsd-i386
   ifneq (,$(filter $(DEB_TARGET_ARCH), $(libphobos_archs)))
 with_libphobos := yes
   endif
@@ -1106,7 +1108,7 @@ ifneq (,$(filter $(DEB_TARGET_ARCH),$(gomp_no_archs)))
 endif
 
 # itm --

Bug#812555: gnome-session-flashback (temporary) black screen

[Massimo Martelli]

Looks like you were half right about accessibility.
>From the logs I found out this:
gnome-session-binary[4732]: WARNING: Application 'at-spi-dbus-
bus.desktop' failed to register before timeout
appearing right after the black screen. Anyway I do have accessibility
disabled (triple-checked) and it's weird that other gnome sessions work
fine. What's even weirder is that it looks like my at-spi-dbus-
bus.desktop already has that line not commented so the patch is not
needed.
For now, since I don't use it, I worked around the issue moving the at-
spi-dbus-bus.desktop file out of the way. Thank you so much for your
kind help, I guess I'll have to report to the gnome bugtracker for this
issue :)

Bug#801925: [PATCH] SCSI: fix crashes in sd and sr runtime PM

[Erich Schubert]

Hello Alan,
Thank you:

The patch appears to work for me, too.

Applied on top of Debian kernel "4.4-1~exp1" I finally have a kernel boot again!
(And maybe this will also make the Intel ( i7-2677M IGP) video bugs
disappear...)

Best regards,
Erich

On Wed, Jan 20, 2016 at 5:26 PM, Alan Stern  wrote:
> Runtime suspend during driver probe and removal can cause problems.
> The driver's runtime_suspend or runtime_resume callbacks may invoked
> before the driver has finished binding to the device or after the
> driver has unbound from the device.
>
> This problem shows up with the sd and sr drivers, and can cause disk
> or CD/DVD drives to become unusable as a result.  The fix is simple.
> The drivers store a pointer to the scsi_disk or scsi_cd structure as
> their private device data when probing is finished, so we simply have
> to be sure to clear the private data during removal and test it during
> runtime suspend/resume.
>
> This fixes .
>
> Signed-off-by: Alan Stern 
> Reported-by: Paul Menzel 
> Reported-by: Erich Schubert 
> Reported-by: Alexandre Rossi 
> Tested-by: Paul Menzel 
> CC: "James E.J. Bottomley" 
> CC: Ben Hutchings 
> CC: 
>
> ---
>
>
> [as1795]
>
>
>  drivers/scsi/sd.c |7 +--
>  drivers/scsi/sr.c |4 
>  2 files changed, 9 insertions(+), 2 deletions(-)
>
> Index: usb-4.4/drivers/scsi/sd.c
> ===
> --- usb-4.4.orig/drivers/scsi/sd.c
> +++ usb-4.4/drivers/scsi/sd.c
> @@ -3275,8 +3275,8 @@ static int sd_suspend_common(struct devi
> struct scsi_disk *sdkp = dev_get_drvdata(dev);
> int ret = 0;
>
> -   if (!sdkp)
> -   return 0;   /* this can happen */
> +   if (!sdkp)  /* E.g.: runtime suspend following sd_remove() */
> +   return 0;
>
> if (sdkp->WCE && sdkp->media_present) {
> sd_printk(KERN_NOTICE, sdkp, "Synchronizing SCSI cache\n");
> @@ -3315,6 +3315,9 @@ static int sd_resume(struct device *dev)
>  {
> struct scsi_disk *sdkp = dev_get_drvdata(dev);
>
> +   if (!sdkp)  /* E.g.: runtime resume at the start of sd_probe() */
> +   return 0;
> +
> if (!sdkp->device->manage_start_stop)
> return 0;
>
> Index: usb-4.4/drivers/scsi/sr.c
> ===
> --- usb-4.4.orig/drivers/scsi/sr.c
> +++ usb-4.4/drivers/scsi/sr.c
> @@ -144,6 +144,9 @@ static int sr_runtime_suspend(struct dev
>  {
> struct scsi_cd *cd = dev_get_drvdata(dev);
>
> +   if (!cd)/* E.g.: runtime suspend following sr_remove() */
> +   return 0;
> +
> if (cd->media_present)
> return -EBUSY;
> else
> @@ -985,6 +988,7 @@ static int sr_remove(struct device *dev)
> scsi_autopm_get_device(cd->device);
>
> del_gendisk(cd->disk);
> +   dev_set_drvdata(dev, NULL);
>
> mutex_lock(&sr_ref_mutex);
> kref_put(&cd->kref, sr_kref_release);
>

Bug#812417: devscripts: uscan --verbose --rename exits with an error

[James McCoy]

Control: unmerge 812417

On Sat, Jan 23, 2016 at 04:14:34PM +0100, Andreas Metzler wrote:
> I am not sure when this changed, but it is broken now:
> 
> ametzler@argenau:/tmp/HUGIN/hugin-2015.0.0$ uscan --verbose --rename
> [snip]
> uscan info: New orig.tar.* tarball version (oversionmangled): 2016.0.0~beta1
> uscan: Successfully downloaded package hugin-2016.0.0_beta1.tar.bz2
> uscan info: Executing internal command:
>mk-origtargz --package hugin --version 2016.0.0~beta1 --rename 
> --compression gzip --directory .. --copyright-file debian/copyright 
> ../hugin-2016.0.0_beta1.tar.bz2
> uscan info: New orig.tar.* tarball version (after mk-origtargz): 
> 2016.0.0~beta1
> Can't open 'hugin-2016.0.0_beta1.tar.bz2': No such file or directory at 
> /usr/bin/uscan line 3705.
> ametzler@argenau:/tmp/HUGIN/hugin-2015.0.0$ echo $?
> 2

On Tue, Jan 26, 2016 at 11:10:48PM +0900, Osamu Aoki wrote:
> On Sat, Jan 23, 2016 at 04:14:34PM +0100, Andreas Metzler wrote:
> 
> > uscan info: Found the following matching hrefs on the web page (newest 
> > first):
> >/watch/sf.php/hugin/hugin-2016.0.0_beta1.tar.bz2 (2016.0.0~beta1) 
> > index=2016.0.0~beta1.2
> >/watch/sf.php/hugin/hugin-2015.0.0.tar.bz2 (2015.0.0) index=2015.0.0.2
> Wrong order

That's not what Andreas was referring to.  hugin-2016.0.0_beta1.tar.bz2
was successfully downloaded and renamed, but then uscan errors out with
“Can't open 'hugin-2016.0.0_beta1.tar.bz2'” because it's not using the
correct filename.

> ametzler@argenau:/tmp/HUGIN/hugin-2015.0.0$ ls ..
> hugin-2015.0.0   hugin_2016.0.0~beta1.orig.tar.bz2
   --^

Cheers,
-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy 

Bug#812833: pan: Won't start--aborts with error

[Bert Riding]

Package: pan
Version: 0.139-4+b1
Severity: important

Pan was shut down abruptly.  Upon restart, aborts.
Pan was upgraded since the last startup.
I moved .pan2/newsrc-1 to avoid sending my subscription list with
this bug report.

bertbob@blacky:~$ pan --debug 
(article-cache.cc:170:ArticleCache) loaded 1137 articles into cache from 
/home/bertbob/.pan2/article-cache
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name news.pan.NZB 
was not provided by any .service files
**
ERROR:pan-tree.cc:80:GtkTreeIter PanTreeStore::get_iter(const 
PanTreeStore::Row*): assertion failed: (row)
Aborted


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

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

Versions of packages pan depends on:
ii  gnome-keyring3.18.3-1
ii  libatk1.0-0  2.18.0-1
ii  libc62.21-7
ii  libcairo21.14.6-1
ii  libenchant1c2a   1.6.0-10.1
ii  libfontconfig1   2.11.0-6.3
ii  libfreetype6 2.6.1-0.1
ii  libgcc1  1:5.3.1-7
ii  libgdk-pixbuf2.0-0   2.32.3-1
ii  libglib2.0-0 2.46.2-3
ii  libgmime-2.6-0   2.6.20-1+b1
ii  libgnome-keyring03.12.0-1+b1
ii  libgnutls30  3.4.8-2
ii  libgtk2.0-0  2.24.29-1
ii  libgtkspell0 2.0.16-1.1
ii  libnotify4   0.7.6-2
ii  libpango-1.0-0   1.38.1-1
ii  libpangocairo-1.0-0  1.38.1-1
ii  libpangoft2-1.0-01.38.1-1
ii  libstdc++6   5.3.1-7

pan recommends no packages.

pan suggests no packages.

-- no debconf information

Bug#812832: libgpg-error: Please add support for hardened1-linux-amd64

[Balint Reczey]

Package: libgpg-error
Version: 1.21-1
Severity: wishlist
Tags: patch upstream
User: bal...@balintreczey.hu
Usertags: hardened1-linux-amd64

Dear GnuPG Maintainers,

I have successfully bootstrapped the hardened1-linux-amd64 [1] port
using a set of patches [2].
I'm working towards making the port ready for being accepted to Debian
and the attached patch is the one adding the port support to
libgpg-error.

Accepting this patch would make (re-)bootstrapping the new port easier.

Thank you in advance,
Balint

[1]
http://balintreczey.hu/blog/proposing-amd64-hardened-architecture-for-debian/
[2] https://anonscm.debian.org/cgit/users/rbalint/rebootstrap.git/

diff --git a/debian/rules b/debian/rules
index 3d5c777..db8a608 100755
--- a/debian/rules
+++ b/debian/rules
@@ -15,6 +15,8 @@ export DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
 
 override_dh_auto_configure:
 	touch po/libgpg-error.pot
+	# add support for hardened1-linux-amd64
+	sed 's/-gnu/-gnuhardened1/' src/syscfg/lock-obj-pub.x86_64-pc-linux-gnu.h > src/syscfg/lock-obj-pub.x86_64-pc-linux-gnuhardened1.h
 	dh_auto_configure -- \
 	--enable-static \
 	--disable-rpath \

Bug#582064: aptitude: unsigned package warning should show repository name

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending


Hi Marc,

2010-05-18 01:53 Marc Auslander:

Package: aptitude
Version: 0.4.11.11-1~lenny1
Severity: wishlist


When I decide to install an unsigned package, I'd like to know its at least 
apparently from the repostitory I expect.

I understand there are lots of theoretical attacks I could be exposed to, but 
I'd like to atleast know its not just a collision.


Thanks for the report.

I changed the messages so the program will now show the package origin,
will be present in the next release, so marking this as +pending.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#812831: nginx-common: testconfig returns 0 even on failure

[Alexandre Kouznetsov]

Package: nginx-common
Version: 1.6.2-5
Severity: normal

Hello.

When I run "/etc/init.d/nginx testconfig" and there is any problem, it returns
0 as exit code, and the message "[FAIL] Testing nginx configuration: failed!".
Same result when running "service nginx configtest".

In case of problems encountered, a non-zero return value is expected.

Steps to reproduce:
1. Break you Nginx configuration somehow (I put an extra "}" in the config).
2. Run "service nginx configtest".
3. Check exit value "echo $?", it's 0 instead of 1.

This functionality is very iseful when scripting Nginx controls, so it's
suitable to use constructions like this:
"/etc/init.d/nginx testconfig && /etc/init.d/nginx reload"

It worked as expected in Debian Wheezy and I first noticed this problem
in Debian Jessie.


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

Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=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 nginx-common depends on:
ii  init-system-helpers  1.22
ii  lsb-base 4.1+Debian13+nmu1

nginx-common recommends no packages.

Versions of packages nginx-common suggests:
pn  fcgiwrap   
pn  nginx-doc  
pn  ssl-cert   

-- Configuration Files:
/etc/nginx/sites-available/default [Errno 13] Permission denied: 
u'/etc/nginx/sites-available/default'

-- no debconf information

Bug#812830: [PATCH] Fix titleblock overflowing body's bounds

[James Clarke]

Package: ftp.debian.org
Severity: minor
Tags: patch
8<>8
---
 removals-style.css | 3 +++
 style.css  | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/removals-style.css b/removals-style.css
index 6c21fa6..19f2b36 100644
--- a/removals-style.css
+++ b/removals-style.css
@@ -20,6 +20,9 @@ a img {
background-color: #DF0451;
color: #00;
padding: 0.2em;
+   -moz-box-sizing: border-box;
+   -webkit-box-sizing: border-box;
+   box-sizing: border-box;
 }
.titleblock a {
color: #00;
diff --git a/style.css b/style.css
index 0d73e47..05c8052 100644
--- a/style.css
+++ b/style.css
@@ -380,6 +380,9 @@ a img {
background-color: #DF0451;
color: #00;
padding: 0.2em;
+   -moz-box-sizing: border-box;
+   -webkit-box-sizing: border-box;
+   box-sizing: border-box;
 }
.titleblock a {
color: #00;
-- 
2.7.0

Bug#812829: -o no longer works

[積丹尼 Dan Jacobson]

Package: aptitude
Version: 0.7.5-3

file:///usr/share/doc/aptitude/html/en/ch02s05s05.html says

aptitude's configuration is read from the following sources, in order:

 1. Configuration file options specified on the command-line.

 2. The user's configuration file, ~/.aptitude/config. This file is overwritten 
when the user modifies settings in the Options menu.

 3. The system configuration file, /etc/apt/apt.conf.

 4. The system configuration fragment files, /etc/apt/apt.conf.d/*.

 5. The file specified by the APT_CONFIG environment variable (if any).

 6. Default values stored in /usr/share/aptitude/aptitude-defaults.

 7. Default values built into aptitude.

but neglects to mention at what level -o on the command line overrides
any of these. (DOCUMENTATION) BUG1. In fact it doesn't even politely
mention -o one little bit.

In fact it doesn't anymore.

The man page says

   -o =
   Set a configuration file option directly; for instance, use -o
   Aptitude::Log=/tmp/my-log to log aptitude's actions to /tmp/my-log.
   For more information on configuration file options, see the section
   "Configuration file reference" in the aptitude reference manual.

   -v, --verbose
   Causes some commands (for instance, show) to display extra
   information. This may be supplied multiple times to get more and
   more information.

   This corresponds to the configuration option
   Aptitude::CmdLine::Verbose.

So
# aptitude why python-requests
i   python-pip Depends python-requests
# aptitude -v why python-requests|wc
  56676  285614 3690866
# aptitude -o Aptitude::CmdLine::Verbose=1 why python-requests|wc
  1   4  39
BUG2.

Likewise, if one has
Aptitude::CmdLine::Verbose 1;
in their configuration file,
-o Aptitude::CmdLine::Verbose=0
will no longer turn it off.

Here we see that it must be an aptitude problem, not an apt problem:

# apt-config -o Aptitude::CmdLine::VerboseX=0 dump|grep -i verb
Aptitude::CmdLine::Verbose "1";
Aptitude::CmdLine::VerboseX "0";
CommandLine::AsString "apt-config -o Aptitude::CmdLine::VerboseX=0 dump";
# apt-config -o Aptitude::CmdLine::Verbose=0 dump|grep -i verb
Aptitude::CmdLine::Verbose "0";
CommandLine::AsString "apt-config -o Aptitude::CmdLine::Verbose=0 dump";

Bug#812828: [PATCH] Improved styling of clickable text

[James Clarke]

Package: ftp.debian.org
Severity: minor
Tags: patch
8<>8
---
 style.css | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/style.css b/style.css
index 0d73e47..587dd1b 100644
--- a/style.css
+++ b/style.css
@@ -280,6 +280,9 @@ span.deferredfp {
border-bottom: dashed 1px black;
margin: 0.2em;
 }
+#NEW-details-page .infobox .title {
+   cursor: pointer;
+}
 #NEW-details-page .infobox .subtitle { 
text-align: center;
font-weight: bold;
@@ -327,8 +330,15 @@ span.deferredfp {
 #NEW p.togglepkg {
  font-size: 90%;
  font-family: monospace;
- margin: 0px;
+ margin-top: 0px;
+ margin-right: 0px;
  margin-left:2.5%;
+ cursor: pointer;
+ display: inline-block;
+}
+#NEW p.togglepkg:hover {
+ color: #FF;
+ text-decoration: underline;
 }
 table.NEW {
  margin: auto auto;
-- 
2.7.0

Bug#810740: libtool: Please pass -fsanitize=* flags to ld

[Balint Reczey]

On Mon, 11 Jan 2016 21:08:37 +0100 Balint Reczey
 wrote:
...
> Please let -fsanitize=* flags pass to linker. The attached patch
> enables building packages using libtool on hardened1-linux-amd64,
> where ASAN and UBSAN are enabled by default.
Also pass -fno-sanitize=* to be fair to them. :-)
diff --git a/libltdl/config/ltmain.sh b/libltdl/config/ltmain.sh
index 63ae69d..42854b1 100644
--- a/libltdl/config/ltmain.sh
+++ b/libltdl/config/ltmain.sh
@@ -5529,6 +5529,11 @@ func_mode_link ()
 	continue
 	;;
 
+  -fsanitize=* | -fno-sanitize=*)
+	func_append compiler_flags " $arg"
+	func_append linker_flags " $arg"
+	;;
+
   -inst-prefix-dir)
 	prev=inst_prefix
 	continue

Bug#812626: libfreecontact-perl: FTBFS - Parse errors: Bad plan. You planned 10 tests but ran 6.

[gregor herrmann]

On Tue, 26 Jan 2016 21:14:35 +0100, Andreas Tille wrote:

> > I cloned the git repo (very handy :)) and had a look, but I can't
> > reproduce the test failure, not even when running them manually under
> > high load.
> H, I should have mentioned this: I also can not reproduce the
> problem.

Ok, maybe the submitter can shed some light on this issue.
  
> > > > SSE2 veczweight, wchunk = 32
> I get
>   SSE2 veczweight, wchunk = 64
> here instead (when building on amd64).

Me too.
 
> > I noticed that the non-perl-test output comes before t/02test.t while
> > it comes later (after the "ok 3" of t/02test.t) for me. I thought this
> > might be a parallelization problem but the test was run with -j1, and
> > it also passes for me with -jN.
> From my (limited) experience this kind of non-reproducible FTBFS are
> often connected to parallelization.  I'm tempted to drop the --parallel
> from d/rules.

Doesn't hurt, but since since the logs have
make -j1 test TEST_VERBOSE=1
this doesn't seem to have any effect anyway.
  

Cheers,
gregor

-- 
 .''`.  Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: George Harrison: Run Of The Mill


signature.asc
Description: Digital Signature

Bug#812827: apt: Package pinning by origin broken

[Ben Kibbey]

Package: apt
Version: 1.2
Severity: normal

Dear Maintainer,

   * What led up to the situation?

Upgraded from apt version 1.1.10 to 1.2.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

It was just recently working in version 1.1 (if I remember right). Then broke
again in 1.2. Building from git source (HEAD=a133f79) has the same problem. But
reverting commit f6459e64 fixes things. Note the Canidate version below.

   * What was the outcome of this action?

$ apt policy ffmpeg
ffmpeg:
  Installed: 7:2.8.4-1+b1
  Candidate: 10:2.8.5-dmo1
  Version table:
 10:2.8.5-dmo1 990
990 http://www.deb-multimedia.org testing/main amd64 Packages
 7:2.8.5-1+b1 800
800 http://ftp.us.debian.org/debian unstable/main amd64 Packages
 *** 7:2.8.4-1+b1 990
990 http://ftp.us.debian.org/debian testing/main amd64 Packages
100 /var/lib/dpkg/status

   * What outcome did you expect instead?

$ apt policy ffmpeg
ffmpeg:
  Installed: 7:2.8.4-1+b1
  Candidate: 7:2.8.4-1+b1
  Version table:
 10:2.8.5-dmo1 600
990 http://www.deb-multimedia.org testing/main amd64 Packages
 7:2.8.5-1+b1 800
800 http://ftp.us.debian.org/debian unstable/main amd64 Packages
 *** 7:2.8.4-1+b1 990
990 http://ftp.us.debian.org/debian testing/main amd64 Packages
100 /var/lib/dpkg/status



-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "false";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-4\.3\.3-1-g4c13c39$";
APT::NeverAutoRemove:: "^linux-image-4\.4\.0-1-g1448f50$";
APT::NeverAutoRemove:: "^linux-headers-4\.3\.3-1-g4c13c39$";
APT::NeverAutoRemove:: "^linux-headers-4\.4\.0-1-g1448f50$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.3\.3-1-g4c13c39$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.4\.0-1-g1448f50$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.3\.3-1-g4c13c39$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.4\.0-1-g1448f50$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.3\.3-1-g4c13c39$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.4\.0-1-g1448f50$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.3\.3-1-g4c13c39$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.4\.0-1-g1448f50$";
APT::NeverAutoRemove:: "^gnumach-image-4\.3\.3-1-g4c13c39$";
APT::NeverAutoRemove:: "^gnumach-image-4\.4\.0-1-g1448f50$";
APT::NeverAutoRemove:: "^.*-modules-4\.3\.3-1-g4c13c39$";
APT::NeverAutoRemove:: "^.*-modules-4\.4\.0-1-g1448f50$";
APT::NeverAutoRemove:: "^.*-kernel-4\.3\.3-1-g4c13c39$";
APT::NeverAutoRemove:: "^.*-kernel-4\.4\.0-1-g1448f50$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.3\.3-1-g4c13c39$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.4\.0-1-g1448f50$";
APT::NeverAutoRemove:: "^linux-tools-4\.3\.3-1-g4c13c39$";
APT::NeverAutoRemove:: "^linux-tools-4\.4\.0-1-g1448f50$";
APT::NeverAutoRemove:: "^postgresql-";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-image";
APT::VersionedKernelPackages:: "linux-headers";
APT::VersionedKernelPackages:: "linux-image-extra";
APT::VersionedKernelPackages:: "linux-signed-image";
APT::VersionedKernelPackages:: "kfreebsd-image";
APT::VersionedKernelPackages:: "kfreebsd-headers";
APT::VersionedKernelPackages:: "gnumach-image";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::VersionedKernelPackages:: "linux-backports-modules-.*";
APT::VersionedKernelPackages:: "linux-tools";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::Update "";
APT::Update::Post-Invoke "";
APT::Update::Post-Invoke:: "[ ! -x /usr/bin/debtags ] || debtags update || 
true";
APT::Default-Release "testing";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Architectures:: "i386";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::lz4 "";
APT:

Bug#812826: ibus: while typing a Korean character, pressing space inserts a space before (not after) the character

[Sean Whitton]

Package: ibus
Version: 1.5.11-1
Severity: normal
Affects: ibus-hangul

Dear maintainers,

** Steps to reproduce:

1) Enable ibus and the Hangul keyboard layout.
2) Switch to Korean layout with your "next input method" key.
3) Type "가나" followed by the space key (on a US keyboard this is "rksk ").

** Expected result: "가나 "

** Actual result: "가 나"

** Possibly related non-Debian bug reports:

https://bugzilla.redhat.com/show_bug.cgi?id=753781
https://bugs.launchpad.net/ubuntu/+source/unity/+bug/880876
https://bugs.launchpad.net/ubuntu/+source/ibus-hangul/+bug/840823

** Commentary:

I have filed this bug against ibus rather than ibus-hangul because I
experienced the bug when upgrading Jessie->Stretch (ibus 1.5.9->1.5.11)
yet the version of ibus-hangul in both Jessie and Stretch is 1.5.0.

Thanks.

-- Package-specific info:
default-display-manager: /usr/sbin/lightdm
ibus is /usr/bin/ibus
ibus-setup is /usr/bin/ibus-setup
im-config -l => im-config -m => default missing ibus
XMODIFIERS=@im=ibus
GTK_IM_MODULE=xim
QT4_IM_MODULE=xim
QT_IM_MODULE=xim
XDG_DATA_DIRS=/usr/share/xfce4:/usr/local/share/:/usr/share/:/usr/share
XDG_MENU_PREFIX=xfce-
PATH=~/src/ical2img/.cabal-sandbox/bin:~/local/src/stack/.cabal-sandbox/bin:~/local/src/gtk2hs-buildtools-0.13.0.5/.cabal-sandbox/bin:~/local/src/dash-haskell-1.1.0.2/.cabal-sandbox/bin:~/local/src/happy-1.19.5/.cabal-sandbox/bin:~/local/src/propellor-2.15.2/.cabal-sandbox/bin:~/local/src/pandoc-1.15.2.1/.cabal-sandbox/bin:~/local/src/alex-3.1.6/.cabal-sandbox/bin:~/local/src/hscolour-1.23/.cabal-sandbox/bin:~/.local/bin:~/local/bin:/usr/sbin:/sbin:~/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

ls -l /usr/lib/ibus/
total 380
-rwxr-xr-x 1 root root  14052 Nov 20 00:36 ibus-dconf
-rwxr-xr-x 1 root root  30516 Oct 12  2014 ibus-engine-hangul
-rwxr-xr-x 1 root root   9828 Nov 20 00:36 ibus-engine-simple
-rwxr-xr-x 1 root root912 Oct 12  2014 ibus-setup-hangul
-rwxr-xr-x 1 root root 220388 Nov 20 00:36 ibus-ui-gtk3
-rwxr-xr-x 1 root root 100332 Nov 20 00:36 ibus-x11

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

Kernel: Linux 4.3.0-1-686-pae (SMP w/2 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 ibus depends on:
ii  adwaita-icon-theme   3.18.0-2
ii  dconf-cli0.24.0-2
ii  dconf-gsettings-backend [gsettings-backend]  0.24.0-2
ii  gir1.2-gtk-3.0   3.18.6-1
ii  gir1.2-ibus-1.0  1.5.11-1
ii  libatk1.0-0  2.18.0-1
ii  libc62.21-6
ii  libcairo21.14.6-1
ii  libdconf10.24.0-2
ii  libgdk-pixbuf2.0-0   2.32.3-1
ii  libglib2.0-0 2.46.2-3
ii  libgtk-3-0   3.18.6-1
ii  libibus-1.0-51.5.11-1
ii  libnotify4   0.7.6-2
ii  libpango-1.0-0   1.38.1-1
ii  libpangocairo-1.0-0  1.38.1-1
ii  librsvg2-common  2.40.11-2
ii  libx11-6 2:1.6.3-1
ii  libxi6   2:1.7.5-1
ii  python3-gi   3.18.2-2
pn  python3:any  

Versions of packages ibus recommends:
ii  im-config   0.27-2
ii  libqt5gui5  5.5.1+dfsg-12

Versions of packages ibus suggests:
pn  ibus-clutter  
pn  ibus-doc  
pn  ibus-qt4  
ii  libqt5gui55.5.1+dfsg-12

-- no debconf information

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#812825: rustc: FTBFS on i386: run-pass-valgrind/down-with-thread-dtors.rs ... FAILED

[Aaron M. Ucko]

Source: rustc
Version: 1.6.0+dfsg1-2
Severity: serious
Justification: fails to build from source

rustc compilation succeeds again on i386 now that you've taken care of
#812448.  (Thanks!)  However, the build still eventually fails, with a
test suite error, as detailed below.  Could you please take a look?

Thanks!

https://buildd.debian.org/status/fetch.php?pkg=rustc&arch=i386&ver=1.6.0%2Bdfsg1-2&stamp=1453812219

test [run-pass-valgrind] run-pass-valgrind/down-with-thread-dtors.rs ... FAILED
[...]
failures:

 [run-pass-valgrind] run-pass-valgrind/down-with-thread-dtors.rs stdout 

error: test run failed!
status: signal: 9
command: /usr/bin/valgrind --error-exitcode=100 --fair-sched=try --quiet 
--soname-synonyms=somalloc=NONE 
--suppressions=/«BUILDDIR»/rustc-1.6.0+dfsg1/src/etc/x86.supp --tool=memcheck 
--leak-check=full 
i686-unknown-linux-gnu/test/run-pass-valgrind/down-with-thread-dtors.stage2-i686-unknown-linux-gnu
stdout:
--

--
stderr:
--
--29164-- WARNING: Serious error when reading debug info
--29164-- When reading debug info from /lib/i386-linux-gnu/ld-2.21.so:
--29164-- Ignoring non-Dwarf2/3/4 block in .debug_info
--29164-- WARNING: Serious error when reading debug info
--29164-- When reading debug info from /lib/i386-linux-gnu/ld-2.21.so:
--29164-- Last block truncated in .debug_info; ignoring
--29164-- WARNING: Serious error when reading debug info
--29164-- When reading debug info from /lib/i386-linux-gnu/ld-2.21.so:
--29164-- parse_CU_Header: is neither DWARF2 nor DWARF3 nor DWARF4
--29164-- WARNING: Serious error when reading debug info
--29164-- When reading debug info from /lib/i386-linux-gnu/libc-2.21.so:
--29164-- Ignoring non-Dwarf2/3/4 block in .debug_info
--29164-- WARNING: Serious error when reading debug info
--29164-- When reading debug info from /lib/i386-linux-gnu/libc-2.21.so:
--29164-- Last block truncated in .debug_info; ignoring
--29164-- WARNING: Serious error when reading debug info
--29164-- When reading debug info from /lib/i386-linux-gnu/libc-2.21.so:
--29164-- parse_CU_Header: is neither DWARF2 nor DWARF3 nor DWARF4
--29164-- WARNING: Serious error when reading debug info
--29164-- When reading debug info from /lib/i386-linux-gnu/libdl-2.21.so:
--29164-- Ignoring non-Dwarf2/3/4 block in .debug_info
--29164-- WARNING: Serious error when reading debug info
--29164-- When reading debug info from /lib/i386-linux-gnu/libdl-2.21.so:
--29164-- Last block truncated in .debug_info; ignoring
--29164-- WARNING: Serious error when reading debug info
--29164-- When reading debug info from /lib/i386-linux-gnu/libdl-2.21.so:
--29164-- parse_CU_Header: is neither DWARF2 nor DWARF3 nor DWARF4
--29164-- WARNING: Serious error when reading debug info
--29164-- When reading debug info from /lib/i386-linux-gnu/libm-2.21.so:
--29164-- Ignoring non-Dwarf2/3/4 block in .debug_info
--29164-- WARNING: Serious error when reading debug info
--29164-- When reading debug info from /lib/i386-linux-gnu/libm-2.21.so:
--29164-- Last block truncated in .debug_info; ignoring
--29164-- WARNING: Serious error when reading debug info
--29164-- When reading debug info from /lib/i386-linux-gnu/libm-2.21.so:
--29164-- parse_CU_Header: is neither DWARF2 nor DWARF3 nor DWARF4
==29164== Can't extend stack to 0x4b76880 during signal delivery for thread 2:
==29164==   no stack segment
==29164== 
==29164== Process terminating with default action of signal 11 (SIGSEGV)
==29164==  Access not within mapped region at address 0x4B76880
==29164==at 0x109312: Bar::drop.3572::he1906ad0926bab78 (in 
/«BUILDDIR»/rustc-1.6.0+dfsg1/i686-unknown-linux-gnu/test/run-pass-valgrind/down-with-thread-dtors.stage2-i686-unknown-linux-gnu)
==29164==by 0x4BDEA3B: __call_tls_dtors (in 
/lib/i386-linux-gnu/libc-2.21.so)
==29164==by 0x4B7CF78: start_thread (pthread_create.c:343)
==29164==by 0x4C83C5D: clone (in /lib/i386-linux-gnu/libc-2.21.so)
==29164==  If you believe this happened as a result of a stack
==29164==  overflow in your program's main thread (unlikely but
==29164==  possible), you can try to increase the size of the
==29164==  main thread stack using the --main-stacksize= flag.
==29164==  The main thread stack size used in this run was 8388608.
==29164== 152 bytes in 1 blocks are possibly lost in loss record 6 of 7
==29164==at 0x482E118: calloc (in 
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==29164==by 0x4010B06: allocate_dtv (in /lib/i386-linux-gnu/ld-2.21.so)
==29164==by 0x40114EB: _dl_allocate_tls (in /lib/i386-linux-gnu/ld-2.21.so)
==29164==by 0x4B7D7B4: allocate_stack (allocatestack.c:587)
==29164==by 0x4B7D7B4: pthread_create@@GLIBC_2.1 (pthread_create.c:537)
==29164==by 0x48D3910: 
sys::thread::_$LT$impl$GT$::new::h0c26d6244eb55dc5V2w (in 
/«BUILDDIR»/rustc-1.6.0+dfsg1/i686-unknown-linux-gnu/stage2/lib/rustlib/i686-unknown-linux-gnu/lib/

Bug#812824: RFS: tiny-initramfs/0.1-1 [ITP] - Minimalistic initramfs implementation

[Christian Seiler]

Control: retitle -1 RFS: tiny-initramfs/0.1-1 [ITP] - Minimalistic initramfs 
implementation

Sorry for the noise, just noticed I had ITA in the title
instead of ITP after receiving the bugtracker confirmation
email. :-(

Regards,
Christian



signature.asc
Description: OpenPGP digital signature

Bug#808141: sponsorship-requests: Dear mentors, I am looking for a sponsor for my package eclipse-titan.

[Mattia Rizzolo]

On Tue, Jan 26, 2016 at 12:19:09PM +0100, Jakub Wilk wrote:
> * Pilisi Gergely , 2016-01-22, 14:55:
> >export DEB_BUILD_MAINT_OPTIONS = hardening=+all
> >export CPPFLAGS=$(shell dpkg-buildflags --get CPPFLAGS)
> >export CFLAGS=$(shell dpkg-buildflags --get CFLAGS)
> >export CXXFLAGS=$(shell dpkg-buildflags --get CXXFLAGS)
> >export LDFLAGS=$(shell dpkg-buildflags --get LDFLAGS)
> 
> Note that $(shell) constructs are not affected by variables exported in the
> same makefile.
> 
> >export CCFLAGS=$(shell dplg-buildflags --get CFLAGS)
> 
> Typo: s/dplg/dpkg/.

oh, thank you, indeed!
Your email made me try some more, and I get a better state in blhc.
I noticed that the faulty flag is pie-related.
I applied this:

--- eclipse-titan-5.4.1/debian/rules2016-01-22 13:30:30.0 +
+++ eclipse-titan-5.4.1/debian/rules2016-01-26 23:42:37.0 +
@@ -1,12 +1,9 @@
 #!/usr/bin/make -f
 export V=1
 export DH_VERBOSE=1
-export DEB_BUILD_MAINT_OPTIONS = hardening=+all
-export CPPFLAGS=$(shell dpkg-buildflags --get CPPFLAGS)
-export CFLAGS=$(shell dpkg-buildflags --get CFLAGS)
-export CXXFLAGS=$(shell dpkg-buildflags --get CXXFLAGS)
-export LDFLAGS=$(shell dpkg-buildflags --get LDFLAGS)
-export CCFLAGS=$(shell dplg-buildflags --get CFLAGS)
+
+export DEB_BUILD_OPTIONS=hardening=+all,-pie
+export CCFLAGS = $(shell DEB_BUILD_OPTIONS=hardening=+all,-pie dpkg-buildflags 
--get CFLAGS)
 
 %:
dh $@ --verbose --parallel

Which I like some more than your version (I want to remember you that
debhlper with compat 9+ exports those flags by itself, except CCFLAGS
which is non-standard)

Still, I couldn't carry this thing further.
Given that I like this more, can I upload this instead? :)

> >What is wrong with that? :(
> 
> blhc(1) is invaluable for debugging hardening issues.

Yeah, I do use it, even if usually the thing I fixed in the past were
quite easy to fix and I had ever had the need to look at its output
closer than just glancing over it.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://mapreri.org  : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#812824: RFS: tiny-initramfs/0.1-1 [ITA] - Minimalistic initramfs implementation

[Christian Seiler]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "tiny-initramfs"

 * Package name: tiny-initramfs
   Version : 0.1-1
   Upstream Author : Christian Seiler 
 * URL : https://github.com/chris-se/tiny-initramfs/
 * License : GPL-3+
   Section : utils

It builds those binary packages:

tiny-initramfs - Minimalistic initramfs implementation (automation)
 tiny-initramfs-core - Minimalistic initramfs implementation (core tools)

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

  http://mentors.debian.net/package/tiny-initramfs

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

  dget -x 
http://mentors.debian.net/debian/pool/main/t/tiny-initramfs/tiny-initramfs_0.1-1.dsc

More information about tiny-initramfs can be obtained from 

  https://github.com/chris-se/tiny-initramfs/

Regards,
Christian



signature.asc
Description: OpenPGP digital signature

Bug#812823: utopia-documents: Segmentation fault on start

[Douglas Calvert]

Package: utopia-documents
Version: 2.4.4-2.1
Severity: normal

utopia-documents dumps core immediately after execution:

gdb followus:

gdb -c core /usr/bin/utopia-documents 
GNU gdb (Debian 7.10-1+b1) 7.10
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/utopia-documents...Reading symbols from 
/usr/lib/debug/.build-id/f5/27b237fb425a544a4e73a9e803e56dd84e8207.debug...done.
done.

warning: core file may not match specified executable file.
[New LWP 11438]
[New LWP 11439]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `utopia-documents'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7fc100d95795 in QMetaObject::className() const () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
[Current thread is 1 (Thread 0x7fc157bcc7c0 (LWP 11438))]
(gdb) bt
#0  0x7fc100d95795 in QMetaObject::className() const () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#1  0x7fc1017187bf in ?? () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#2  0x7fc1016b2e77 in ?? () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#3  0x7fc157a0c26a in call_init (l=, argc=argc@entry=1, 
argv=argv@entry=0x7ffdd0e4b218, 
env=env@entry=0x7ffdd0e4b228) at dl-init.c:72
#4  0x7fc157a0c37b in call_init (env=0x7ffdd0e4b228, argv=0x7ffdd0e4b218, 
argc=1, l=) at dl-init.c:30
#5  _dl_init (main_map=main_map@entry=0x1b96420, argc=1, argv=0x7ffdd0e4b218, 
env=0x7ffdd0e4b228) at dl-init.c:120
#6  0x7fc157a108a8 in dl_open_worker (a=a@entry=0x7ffdd0e4a738) at 
dl-open.c:569
#7  0x7fc157a0c114 in _dl_catch_error 
(objname=objname@entry=0x7ffdd0e4a728, 
errstring=errstring@entry=0x7ffdd0e4a730, 
mallocedp=mallocedp@entry=0x7ffdd0e4a727, 
operate=operate@entry=0x7fc157a104e0 , 
args=args@entry=0x7ffdd0e4a738)
at dl-error.c:187
#8  0x7fc157a0ff63 in _dl_open (file=0x1b93a18 
"/usr/lib/utopia-documents/plugins/libambrosia-atom_basic.so", 
mode=-2147483391, 
caller_dlopen=0x7fc150cc8f98 , 
nsid=-2, argc=, argv=, 
env=0x7ffdd0e4b228) at dl-open.c:653
#9  0x7fc15018af09 in dlopen_doit (a=a@entry=0x7ffdd0e4a950) at dlopen.c:66
#10 0x7fc157a0c114 in _dl_catch_error (objname=0x1afd700, 
errstring=0x1afd708, mallocedp=0x1afd6f8, 
operate=0x7fc15018aeb0 , args=0x7ffdd0e4a950) at dl-error.c:187
#11 0x7fc15018b4d9 in _dlerror_run (operate=operate@entry=0x7fc15018aeb0 
, args=args@entry=0x7ffdd0e4a950)
at dlerror.c:163
#12 0x7fc15018afa1 in __dlopen (file=, mode=mode@entry=257) 
at dlopen.c:87
#13 0x7fc150cc8f98 in Utopia::(anonymous namespace)::loadLibrary (path_=...)
at 
/build/utopia-documents-S_06Pl/utopia-documents-2.4.4/libutopia2/utopia2/library.cpp:72
#14 Utopia::Library::load (path_=...) at 
/build/utopia-documents-S_06Pl/utopia-documents-2.4.4/libutopia2/utopia2/library.cpp:177
#15 0x7fc150cc970b in Utopia::Library::loadDirectory (directory=..., 
recursive_=recursive_@entry=false)
at 
/build/utopia-documents-S_06Pl/utopia-documents-2.4.4/libutopia2/utopia2/library.cpp:199
#16 0x7fc150cbff5f in Utopia::ExtensionLibrary::loadDirectory 
(directory_=..., recursive_=recursive_@entry=false)
at 
/build/utopia-documents-S_06Pl/utopia-documents-2.4.4/libutopia2/utopia2/extensionlibrary.cpp:121
#17 0x7fc150cc3653 in Utopia::init 
(progressIndicator_=progressIndicator_@entry=0x0)
at 
/build/utopia-documents-S_06Pl/utopia-documents-2.4.4/libutopia2/utopia2/global.cpp:101
#18 0x0040bc0a in main (argc=1, argv=)
at /build/utopia-documents-S_06Pl/utopia-documents-2.4.4/papyro/main.cpp:286




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

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

Versions of packages utopia-documents depends on:
ii  libboost-python1.58.0 1.58.0+dfsg-4.1
ii  libboost-system1.58.0 1.58.0+dfsg-4.1
ii  libboost-thread1.58.0 1.58.0+dfsg-4.1
ii  libc6 2.21-7
ii  libexpat1 2.1.0-7
ii  libfreetype6  2.6.1-0.1
ii  libgcc1   1:5.3.1-7
ii  libgl1

Bug#812358: debian-live: Please add gparted

[Ben Armstrong]

On Jan 26, 2016 5:21 PM, Don Raikes  wrote:
> When I do 
> $ apt-get live-images 
>
> From within jesse, I see a /usr/share/live/images/rescue folder and except 
> for about 4 packages it seems to build fine. 
>
> Couldn't we just fixup those few packages and/or remove them from the 
> package-list and be good? 
>
> Or is this more a matter of debian has decided to go a different direction 
> with tasksel-* and blends? 

How you come up with the list is not as important as having a team independent 
of the live team to make them into one or more metapackages and maintain them. 
Even whether you call that a blend or not is not as important as having people 
make that commitment of long term maintainership of rescue.

Rescue was trimmed from live-images in the first place because it doesn't fit 
with the goal of those images, which was to provide live flavors equivalent to 
what a user would get by default installing Debian. The live team has no 
special interest in being the arbiter of what does it does not go into each 
image on a package by package basis. That's better suited to a blend, with a 
special interest in serving a particular group of users with a common set of 
needs. 

Ben

Bug#757940: aptitude: TERM=dumb not respected

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending


Hi Andreas,

2014-08-12 16:21 Andreas Tolfsen:

Package: aptitude
Version: 0.6.11-1
Severity: minor

Dumb terminals only support a limited number of control codes.  In
particular they do not have the ability to process ANSI escape
sequences which are commonly used for a number of aptitude's commands
to display progress of steps.

As far as I can gather this is a matter of avoiding some of the
conditionals in the switch statement in src/download_item.cc:77.
The problematic cases are the “transient” states: StatIdle,
StatFetching, and StatDone.

This makes the output of the following command rather ugly:

~ % TERM=dumb aptitude update

0% [Working]

Ign http://ppa.launchpad.net trusty InRelease

17% [Connecting to ftp.no.debian.org (2001:700:0:12e::f70)]
[...]
94% [Working]
[  0%] Reading package lists

[100%] Reading package lists


The expected output should be what you see in an intelligent terminal:

~ % aptitude update
Ign http://ppa.launchpad.net trusty InRelease
Hit http://ppa.launchpad.net trusty Release.gpg
Hit http://ppa.launchpad.net trusty Release
Hit http://ppa.launchpad.net trusty/main Sources
Hit http://ppa.launchpad.net trusty/main amd64 Packages
Ign http://ppa.launchpad.net trusty/main Translation-en_US
Ign http://ppa.launchpad.net trusty/main Translation-en
Ign http://ppa.launchpad.net trusty/main Translation-en_GB
Hit http://ftp.no.debian.org sid InRelease
Hit http://ftp.no.debian.org sid/main Sources/DiffIndex
Hit http://ftp.no.debian.org sid/main amd64 Packages/DiffIndex
Hit http://ftp.no.debian.org sid/main Translation-en/DiffIndex


Thanks for the report.

The problem was elsewhere (cmdline_progress.cc and
cmdline_download_progress_display.cc, not src/download_item.cc).

Now I added a check to check for TERM=dumb, as well as in previous cases
when the output was a file or quite>0 -- in those cases the output would
be like in your second example.

Marking as +pending, it will be present in the next release.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#812822: debian-security-support: virtualbox EOL in wheezy

[Moritz Muehlenhoff]

Package: debian-security-support
Severity: normal

See DSA 3454

Cheers,
Moritz

Bug#812821: nmu: pam_1.1.8-3.1+deb8u1

[Tianon Gravi]

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

Due to some kind of mistake in my amd64 build environment (details being
tracked down in #812566) the amd64 build of pam_1.1.8-3.1+deb8u1 is the
only one that got the intended man page update, but this causes
co-installability issues (as detailed in #812566).  Getting a binNMU of
amd64 in the meantime would be great so that at least the packages line
up properly while we figure out what happened. :(

nmu pam_1.1.8-3.1+deb8u1 . amd64 . jessie . -m "Rebuild with correct build 
environment"

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#766794: radare2: new upstream version available

[Douglas Calvert]

Source: radare2
Followup-For: Bug #766794

0.10.0 is out

It would be awesome if radare2 could get a version bump so the new bokken could 
be packaged. 

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

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

Bug#812820: bokken: Please Package Latest Version

[Douglas Calvert]

Package: bokken
Severity: normal

Hello,

THere is a new version of bokken available. Among other things it drops the 
dependency on pyew. 


It looks like the debian package has not been updated in 4 years? 


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

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

Bug#810383: emacs24: hang with 100% CPU usage while editing C++ file

[Satoru Takeuchi]

Package: emacs24-nox

Version: 24.5+1-6+b1

Followup-For: Bug #810383


Dear Maintainer,


   * What led up to the situation?


emacs hung up with 100% CPU usage while editing a bash script.


   * What exactly did you do (or not do) that was effective (or

 ineffective)?


1. Open the following bash script.


foo.sh

==

#!/bin/bash


if $# !=


awk -F, -f by_state.awk $*

==


NOTE: There is no "newline" at the end of this script.


2. Move a cursor to point to "i" at the beginning of line 3.


   * What was the outcome of this action?


emacs hung up.


   * What outcome did you expect instead?


emacs didn't hang up


   * additional information


- The reproducibility is 100%.


- The backtrace is similar to what Sergey reported very much.


=

#1  0x004f3853 in mark_object (arg=) at
alloc.c:6195^M

#2  0x004f3853 in mark_object (arg=) at
alloc.c:6195^M

#3  0x004f393c in mark_object (arg=) at
alloc.c:6308^M

#4  0x004f393c in mark_object (arg=) at
alloc.c:6308^M

#5  0x004f393c in mark_object (arg=) at
alloc.c:6308^M

#6  0x004f3853 in mark_object (arg=) at
alloc.c:6195^M

#7  0x004f3ae4 in mark_object (arg=) at
alloc.c:6095^M

#8  0x004f3853 in mark_object (arg=) at
alloc.c:6195^M

#9  0x004f3d0e in mark_vectorlike (ptr=0x1059578) at alloc.c:5849^M

#10 0x004f382a in mark_object (arg=) at
alloc.c:6181^M

#11 0x004f3853 in mark_object (arg=) at
alloc.c:6195^M

#12 0x004f393c in mark_object (arg=) at
alloc.c:6308^M

#13 0x004f3ae4 in mark_object (arg=) at
alloc.c:6095^M

#14 0x004f3853 in mark_object (arg=) at
alloc.c:6195^M

#15 0x004f3d0e in mark_vectorlike (ptr=0xc09078) at alloc.c:5849^M

...

#1754 0x004f393c in mark_object (arg=) at
alloc.c:6308^M

#1755 0x004f3860 in mark_object (arg=) at
alloc.c:6196^M

#1756 0x004f393c in mark_object (arg=) at
alloc.c:6308^M

#1757 0x004f3d0e in mark_vectorlike (ptr=ptr@entry=0xafd3a8
) at alloc.c:5849^M

#1758 0x004f3db2 in mark_buffer (buffer=) at
alloc.c:5900^M

#1759 0x004f41d3 in Fgarbage_collect () at alloc.c:5592^M

#1760 0x0054189a in maybe_gc () at lisp.h:4563^M

#1761 exec_byte_code (bytestr=, vector=28562157,
maxdepth=, args_template=, nargs=nargs@entry=0,
args=, args@entry=0x1d25671) at bytecode.c:961^M

#1762 0x0050c957 in funcall_lambda (fun=140722811537456,
nargs=nargs@entry=0, arg_vector=0x1d25671, arg_vector@entry=0x7ffc953187c0)
at eval.c:2978^M

#1763 0x0050cc5b in Ffuncall (nargs=1, args=args@entry=0x7ffc953187b8)
at eval.c:2872^M

#1764 0x00541483 in exec_byte_code (bytestr=,
vector=13292141, maxdepth=, args_template=,
nargs=nargs@entry=0, args=, args@entry=0x1d05d61) at
bytecode.c:916^M

#1765 0x0050c957 in funcall_lambda (fun=140722811537872,
nargs=nargs@entry=0, arg_vector=0x1d05d61, arg_vector@entry=0x7ffc95318920)
at eval.c:2978^M

#1766 0x0050cc5b in Ffuncall (nargs=1, args=args@entry=0x7ffc95318918)
at eval.c:2872^M

#1767 0x00541483 in exec_byte_code (bytestr=,
vector=31445173, maxdepth=, args_template=,
nargs=nargs@entry=0, args=, args@entry=0x1d584f1) at
bytecode.c:916^M

#1768 0x0050c957 in funcall_lambda (fun=140722811538576,
nargs=nargs@entry=0, arg_vector=0x1d584f1, arg_vector@entry=0x7ffc95318aa8)
at eval.c:2978^M

#1769 0x0050cc5b in Ffuncall (nargs=1, args=0x7ffc95318aa0) at
eval.c:2872^M

#1770 0x0050c36c in eval_sub (form=form@entry=32641062) at
eval.c:2154^M

#1771 0x0050af9b in internal_catch (tag=16826386, func=0x50bcd0
, arg=32641062) at eval.c:1112^M

#1772 0x005427d0 in exec_byte_code (bytestr=,
vector=13267813, maxdepth=, args_template=,
nargs=nargs@entry=5, args=, args@entry=0x1d585f1) at
bytecode.c:1097^M

#1773 0x0050c957 in funcall_lambda (fun=140722811538928,
nargs=nargs@entry=5, arg_vector=0x1d585f1, arg_vector@entry=0x7ffc95318d78)
at eval.c:2978^M

#1774 0x0050cc5b in Ffuncall (nargs=6, args=args@entry=0x7ffc95318d70)
at eval.c:2872^M

#1775 0x00541483 in exec_byte_code (bytestr=,
vector=13268053, maxdepth=, args_template=,
nargs=nargs@entry=1, args=, args@entry=0x1d515f1) at
bytecode.c:916^M

#1776 0x0050c957 in funcall_lambda (fun=140722811539312,
nargs=nargs@entry=1, arg_vector=0x1d515f1, arg_vector@entry=0x7ffc95318ed8)
at eval.c:2978^M

#1777 0x0050cc5b in Ffuncall (nargs=2, args=args@entry=0x7ffc95318ed0)
at eval.c:2872^M

#1778 0x00541483 in exec_byte_code (bytestr=,
vector=14150797, maxdepth=, args_template=,
nargs=nargs@entry=0, args=, args@entry=0x1d4ed71) at
bytecode.c:916^M

#1779 0x0050c957 in funcall_lambda (fun=140722811540048,
nargs=nargs@entry=0, arg_vector=0x1d4ed71, arg_vector@entry=0x7ffc95319048)
at eval.c:2978^M

#1780 0x0050cc5b in Ffuncall (nargs=1, args=0x7ffc95319040) at
eval.c:2872^M

#1781 0x0050c36c in eval_sub (form=form@entry=326

Bug#766392: maven-debian-helper: --no-usj-versionless does not work

[Emmanuel Bourg]

I stumbled on the same issue, and it looks like this feature got broken
in maven-debian-helper 1.5.1. The copyJarToUsj() method was changed in
the commit 296f73f. Before that change the implementation was:

private void copyJarToUsj() throws IOException {
File jarFile = new File(fullJarName());
if (jarFile.exists()) {
System.out.println("Install jar for " + artifactId + " into 
/usr/share/java");
mkdir(compatSharePath());
FileUtils.copyFile(jarFile, new File(jarDestPath()));
if (noUsjVersionless) {
FileUtils.copyFile(jarFile, new 
File(versionedFullCompatPath()));
} else {
FileUtils.copyFile(jarFile, new File(fullCompatPath()));
run(linkCommand(destUsjJarName(), versionedFullCompatPath()));
}
}
}

In this version the jar is first copied into the Maven repository
(jarDestPath), if noUsjVersionless is set it's then copied as a
versionned jar (versionedFullCompatPath) into /usr/share/java.
The jar was duplicated but no versionless jar was installed.

After the commit the method became:

private void copyJarToUsj() throws IOException {
File jarFile = new File(fullJarName());
if (jarFile.exists()) {
System.out.println("Install jar for " + artifactId + " into 
/usr/share/java");
mkdir(compatSharePath());
FileUtils.copyFile(jarFile, new File(fullCompatPath()));
if (noUsjVersionless) {
run(linkCommand(destUsjJarName(), versionedFullCompatPath()));
} else {
run(linkCommand(destUsjJarName(), fullCompatPath()));
run(linkCommand(destUsjJarName(), versionedFullCompatPath()));
}
}
}

Here the jar is first copied as a versionless jar into /usr/share/java
even if noUsjVersionless is set, which is wrong.

Emmanuel Bourg

Bug#810919: libsane: libusb_bulk_write returns "Resource temporarily unavailable"

[Jörg Frings-Fürst]

tags 810919 -patch +pending
forwarded 810919 
https://alioth.debian.org/tracker/?func=detail&atid=410366&aid=315288&group_id=30186
thanks


Hello Steve,

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

I have forwarded your bug report and your patch to the upstream
authors.

And I add your patch to the next Debian upload.

Many thanks again.

CU
Jörg


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

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

Jörg Frings-Fürst
D-54538 Bausendorf

Threema: SYR8SJXB

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

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




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

Bug#812778: RM: llvm-toolchain-3.5 -- ROM; Old version

[Scott Kitterman]

On Tue, 26 Jan 2016 14:42:29 +0100 Sylvestre Ledru  
wrote:
> Package: ftp.debian.org
> Severity: normal
> 
> Hello,
> 
> Now that we have 3.8 in new and 3.9 as snapshot, we will
> soon have 3.5, 3.6, 3.7, 3.8 and 3.9 in the archive.
> We should remove 3.5. 3.6 has been the default since last october.

There's still rdepends that need to be dealt with.

Checking reverse dependencies...
# Broken Depends:
gambas3: gambas3-gb-jit [amd64 arm64 armel armhf i386 kfreebsd-amd64 kfreebsd-
i386 mips mips64el mipsel powerpc ppc64el s390x]
ghc: ghc [arm64 armel armhf]
pocl: libpocl1 [amd64 kfreebsd-amd64]

# Broken Build-Depends:
feel++: clang-3.5
gambas3: llvm-3.5-dev
ghc: llvm-3.5
kfreebsd-10: clang-3.5
ldc: llvm-3.5-dev
pocl: libclang-3.5-dev
  llvm-3.5-dev

Dependency problem found.

Please remove the moreinfo tag once they are resolved.

Scott K

Bug#812819: should pystatgrab be removed from Debian?

[Mattia Rizzolo]

Source: pystatgrab
Severity: serious


Dear maintainer,

I know this may sound a bit harsh, but I'm concerned by the state of
pystatgrab in Debian.
The package is currently uninstallable due to the removal of a
dependency (that has been deprecated for 5 years now), and  it's
unbuildable since more than 2 years!!

The last upload of this package happened early in 2012, so it's nearly 4
years ago.
There is also a new upstream release out.

pystatgrab missed the last Debian stable release (jessie), and since
then it never came back into testing.
Currently there are 2 open RC bugs, and a kinda low popcon.

Please, can you consider maintaining the package?  Keeping an unusable
thing in the archive is not going to help our users in any way.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://mapreri.org  : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#812818: should dipy be removeed from debian?

[Mattia Rizzolo]

Source: dipy
Severity: serious


Dear dipy maintainer,
I know this may sound a bit harsh and premature, but I'm concerned by
the state of dipy in Debian.
The package is currently uninstallable due to the removal of a
dependency (that has been deprecated for 5 years now), and  it's
unbuildable since more than 6 months (and the maintainers are aware of
it, as you can see in #785991#12).
A new upstream release since more or less that time.

From my restricted point of view there is no activity around it (I at
least se no changes in the public VCS).

As of now there are 2 RC bugs, the package is not in testing, there are
no reverse (build-)dependencies and the the popcon is resonably low.

Please, can you consider maintaining the package?  Keeping an unusable
thing in the archive is not going to help our users in any way.


-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://mapreri.org  : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#498239: warnings, status printed twice

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending
Control: owner -1 !


Fixed by one of the changes in the next release, by failing as soon as
the first action fails.


--
Manuel A. Fernandez Montecelo 

Bug#812723: lintian: package-contains-broken-symlink should look at dependencies

[Niels Thykier]

Adam D. Barratt:
> On Tue, 2016-01-26 at 12:43 -0700, Sean Whitton wrote:
>> Dear Adam,
>>
>> On Tue, Jan 26, 2016 at 05:39:52AM +, Adam D. Barratt wrote:
>>> The tag description explicitly indicates that this is expected in the
>>> situation you describe.
>>
>> I know.  I was under the impression, though, that all false positives
>> are considered Lintian bugs.
> 
> It's a situation that Lintian can't reasonably address, as it doesn't
> know what files are in the package that you depend on.
> 
> The tag's intentionally marked as Experimental; I'm not sure whether the
> current recommendation for such tags is to override or simply ignore
> them.
> 
> Regards,
> 
> Adam
> 

From my PoV: Lets retire the tag.

It has a lot of false-positives due to design restrictions of lintian
and the average user do not understand this (this bug being case in
point, but far from the only one).
  Piuparts have a better possibility of testing this reliably and
without the issues Lintian have.

Thanks,
~Niels





signature.asc
Description: OpenPGP digital signature

Bug#805167: "Regression: rpcbind doesn't start at boottime on systemd controlled machines."

[Patrik Flykt]

> Can I add that the problem also exists on my machine, with nfs-common and 
> autofs as the 
> dependent services?
> 
> My home directories are automounted from an NFS server, but lately I have to 
> manually 
> restart rpcbind and nfs-common before my NFS client finally connects. Reading 
> the 
> output of systemctl status nfs-common shows that nfs-common fails to 
> correctly start 
> because rpcbind isn't running, and just restarting nfs-common does nothing 
> for rpcbind.

On my machine I discovered this in the logs:
Jan 26 14:40:14 xx systemd[1]: nfs-common.service: Found ordering cycle on 
nfs-common.service/start
Jan 26 14:40:14 xx systemd[1]: nfs-common.service: Found dependency on 
rpcbind.target/start
Jan 26 14:40:14 xx systemd[1]: nfs-common.service: Found dependency on 
rpcbind.service/start
Jan 26 14:40:14 xx systemd[1]: nfs-common.service: Found dependency on 
rpcbind.socket/start
Jan 26 14:40:14 xx systemd[1]: nfs-common.service: Found dependency on 
sysinit.target/start
Jan 26 14:40:14 xx systemd[1]: nfs-common.service: Found dependency on 
nfs-common.service/start
Jan 26 14:40:14 xx systemd[1]: nfs-common.service: Breaking ordering cycle 
by deleting job rpcbind.target/start
Jan 26 14:40:14 xx systemd[1]: rpcbind.target: Job rpcbind.target/start 
deleted to break ordering cycle starting with nfs-comm

Since DefaultDependencies is not disabled, rpcbind.socket ends up
depending on sysinit.target. From the above one can see a cycle forming,
which is (correctly) solved by throwing out one of the offending units.

DefaultDependencies should be set to 'no' for early boot, as is the case
for the provided rpcbind.service file. Also rpcbind.socket needs to be
updated with these, i.e. by modifying the following lines in its unit
section:

[Unit]
DefaultDependencies=no
Conflicts=shutdown.target
Before=shutdown.target
After=systemd-tmpfiles-setup.service

The easiest way of applying the modification is to add the above lines
to a .conf file in the /etc/systemd/system/rpcbind.socket.d/ directory.

This solved my problem of unmounted krb5p secured NFS /home and other
directories on bootup.

HTH.

Bug#787959: Severity

[Germar Reitze]

Just downgraded severity to important as here is no progress on new
upstream version. Its not worth that this will block at least v1.1.6 for
all others...


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

Bug#650601: libpng is ready for transition

[Gianfranco Costamagna]

Hi Tobias

>+libpng1.6 (1.6.20-1.2)
> unstable; urgency=medium

Do you want to go on unstable or it is a typo?

Gianfranco

Bug#539978: marked as done ("show" says an installed package is not installed)

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending
Control: owner -1 !


2014-02-01 05:58 Daniel Hartwig:

The package details shown above are for the installed version.  The
manual states that "show" displays the candidate version, which is
presently not the case due to open issues with version selection on the
command line [1].

Details for the candidate version still show "not installed":

$ aptitude show acpi | grep '^\(Pac\|Ver\|Sta\)'
Package: acpi
State: installed
Version: 1.6-1
$ aptitude show acpi=CANDIDATE | grep '^\(Pac\|Ver\|Sta\)'
Package: acpi
State: not installed
Version: 1.7-1

The concern being that it is misleading to report "not installed" for
upgrades, though it may be technically correct, in a sense.  It has been
suggested to make things more clear by changing the state field to say
"not installed, upgrade" or similar.


Fixed it in this way, so marking as +pending.

Also, moved Version to be the second field rather than be buried as #6th
or so, so maybe it's more noticeable that we're showing information
about that version (and because most of the other fields depend on the
version and not the package name).

--
Manuel A. Fernandez Montecelo 

Bug#755202: network-manager: Bug also present in Raspbian Jessie

[Jan Heitkoetter]

Package: network-manager
Version: 0.9.10.0-7
Followup-For: Bug #755202

Dear Maintainer,

It occours to me that this bug is still present in Raspbian Jessie.

I'm trying to set up eth0 with static IP.

/etc/network/interfaces:
# Please note that this file is written to be used with dhcpcd.
# For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf'.

auto lo
iface lo inet loopback

#auto eth0
#iface eth0 inet dhcp

#auto wlan0
#allow-hotplug wlan0
#iface wlan0 inet dhcp
#wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

#iface default inet dhcp


Rebooting after installing network-manager, network-manager has automatically 
created a connection 16a3... using device eth0 and DHCP:
root@himbeere2:/home/jan# nmcli c s
NAME  UUID  TYP GERÄT 
eth0  16a38f40-3cd1-4794-a7b3-e86c318546ca  802-3-ethernet  eth0  


Now editing this connection:
root@himbeere2:/home/jan# nmcli c e eth0

===| nmcli interaktiver Verbindungs-Editor |===

Bestehende Verbindung »802-3-ethernet« wird bearbeitet: »eth0«

[setting static IP etc.]

nmcli> save
Saving the connection with 'autoconnect=yes'. That might result in an immediate 
activation of the connection.
Do you still want to save? (ja/nein) [ja] 
Verbindung »eth0« (16a38f40-3cd1-4794-a7b3-e86c318546ca) erfolgreich 
aktualisiert.
nmcli> quit


Reboot and see what happens:
root@himbeere2:/home/jan# reboot

[...]

jan@himbeere2:~$ sudo nmcli c s
[sudo] password for jan: 
NAME  UUID  TYP GERÄT 
eth0  84150a4e-91b0-446d-b324-4298ff3b1d77  802-3-ethernet  eth0  
eth0  16a38f40-3cd1-4794-a7b3-e86c318546ca  802-3-ethernet  --

network-manager has created another connection 8415... claiming device eth0 and 
using DHCP. It does so after each reboot. I would expect network-manager to use 
the existing connection 16a3...


No conffile for 8415...:
jan@himbeere2:~$ ls -l /etc/NetworkManager/system-connections/
insgesamt 4
-rw--- 1 root root 267 Jan 26 22:52 eth0


Conffile for 16a3... is there (contents OK):
jan@himbeere2:~$ sudo grep uuid /etc/NetworkManager/system-connections/eth0
uuid=16a38f40-3cd1-4794-a7b3-e86c318546ca


/etc/NetworkManager/NetworkManager.conf:
[main]
plugins=ifupdown,keyfile

[ifupdown]
managed=false

Regards

Jan

P.S. Does nobody take care about all those spam replies?

-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 8.0 (jessie)
Release:8.0
Codename:   jessie
Architecture: armv7l

Kernel: Linux 4.1.15-v7+ (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 network-manager depends on:
ii  adduser3.113+nmu3
ii  dbus   1.8.20-0+deb8u1
ii  init-system-helpers1.22
ii  isc-dhcp-client4.3.1-6+deb8u2
ii  libc6  2.19-18+deb8u2
ii  libdbus-1-31.8.20-0+deb8u1
ii  libdbus-glib-1-2   0.102-1
ii  libgcrypt201.6.3-2
ii  libglib2.0-0   2.42.1-1
ii  libgnutls-deb0-28  3.3.8-6+deb8u3
ii  libgudev-1.0-0 215-17+deb8u3
ii  libmm-glib01.4.0-1
ii  libndp01.4-2
ii  libnewt0.520.52.17-1
ii  libnl-3-2003.2.24-2
ii  libnl-genl-3-200   3.2.24-2
ii  libnl-route-3-200  3.2.24-2
ii  libnm-glib40.9.10.0-7
ii  libnm-util20.9.10.0-7
ii  libpam-systemd 215-17+deb8u3
ii  libpolkit-gobject-1-0  0.105-8
ii  libreadline6   6.3-8
ii  libsoup2.4-1   2.48.0-1
ii  libsystemd0215-17+deb8u3
ii  libteamdctl0   1.12-2
ii  libuuid1   2.25.2-6
ii  lsb-base   4.1+Debian13+rpi1+nmu1
ii  policykit-10.105-8
ii  udev   215-17+deb8u3
ii  wpasupplicant  2.3-1+deb8u3

Versions of packages network-manager recommends:
ii  crda3.13-1
ii  dnsmasq-base2.72-3+deb8u1
ii  iptables1.4.21-2
ii  iputils-arping  3:20121221-5
ii  modemmanager1.4.0-1
ii  ppp 2.4.6-3.1

Versions of packages network-manager suggests:
pn  avahi-autoipd  
pn  libteam-utils  

-- no debconf information

Bug#793057: Godot packaging

[e est]

Hello,

Seeing that this ITP is dead for some time already, what has happened with it? 
I'd love to see the godot engine in Debian.

Thanks a lot,

est

Bug#659965: Fixed upstream

[Germar Reitze]

All of this has been fixed upstream couple releases ago.

Example user-callback scripts can be found in
https://github.com/bit-team/user-callback


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

Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

[adrian15]

El 26/01/16 a las 10:18, Michal Suchanek escribió:

If you set bootloaders like

LB_BOOTLOADERS="syslinux grub-efi"

then you can just do

for bootloader in $LB_BOOTLOADERS ; do some $bootloader foo


Mostly what current path does but with commas instead.


IIRC multivalue options use mostly spaces for separator in l-b so far.


dba requested it like this. I agree on that criteria for doing so. You 
are not obliged to use quotes when defining bootloaders on the command 
line or scripts.


What are these multivalue options so that I take a look at them? Having 
to deal with IFS it's not ideal but I think using commas it's the way to 
go... although I'm not 100% convinced.



after you check that you have at most two bootloaders and if you have
more than one then only the latter one ends with -efi.



This is not a good approach. You are requesting the bootloaders to end in
"-efi". The current approach is to name them based on the Debian package
name. These packages do not need to end in "-efi".


It so happens that bootloaders that support efi are packaged as
packages with -efi suffix (well, except elilo). Maybe there is some
intent there?

However, grub-pc is now split in grub-pc scripts that are meant to
install the bootloader in the system which you probably don't want and
grub-pc-bin which just includes the binaries. The situation is even
more complicated with the 32bit and 64bit efi packages. Also expect
that at some point the maintainers figure out some new completely
awesome way to split the bootloader into packages and then the package
sets will be different in stable/testing/oldstable.

So naming the l-b option *exactly* like the package is not that good idea.
dba commited a change ( 
https://anonscm.debian.org/cgit/debian-live/live-build.git/commit/?id=f93fa286d5e7348150aab4874794f7d96dac0894 
) for that behaviour. I think the reasoning of that was avoid file 
naming collisions in the future because package names are not repeated.






My use case is the following one. The final user requests:

--bootloaders=grub-efi,syslinux

so I show him:

"Warning. You are using: syslinux as a non first bootloader. This might work
but it is not advised."

How do I know that I have to output this message?


for bootloader in $BOOTLOADERS ; do

 # some bootloader foo

 if echo $BIOS_BOOTLOADERS | grep "${bootloader}" >/dev/null; then
# a fixed list of bootloaders that load through legacy BIOS -
currently should be "syslinux grub-pc" although grub is not well
supported
 case $MEDIA_TYPE in # or whatever the variable
 iso*)
 case "${BOOTLOADERS}" in
 "${bootloader}"*);;
 *) echo "Warning: it is recommended to specify
$bootloader first in bootloader list so it gets installed as first
el-torito boot entry."
 ;;
 esac ;;
 esac
 fi
done
Here you are creating a new variable: $BIOS_BOOTLOADERS which will have 
to be updated manually each time a new bios bootloader binary_ file is 
added.


The grep part should be improved to avoid problems (e.g. syslinux is 
inside syslinux-efi).



Because I compare the internal variable:

LB_FIRST_BOOTLOADER="grub-efi"

with the bootloader name "syslinux" and I see they are not the same one.

So, as you see I need to use:

"non first bootloader" term


Why that has to be a term? Just say it should come first in the list
of bootloaders if specified at all.


"It should come first". "It should not come first". Ok. I can do that 
and ditch the "non first bootloader" or "first bootloader" from my messages.





and
LB_FIRST_BOOTLOADER variable.


what for?


For two reasons:

1) Being able to use current live-build code which used LB_BOOTLOADER in 
the past.


Check what it's in current alioth git (Seach for LB_PRIMARY_BOOTLOADER 
on there):


https://anonscm.debian.org/cgit/debian-live/live-build.git/tree/scripts/build/binary_hdd?id=1ccb41623046f2a8f823d62a5f417cdae724c22b

https://anonscm.debian.org/cgit/debian-live/live-build.git/tree/scripts/build/binary_iso?id=1ccb41623046f2a8f823d62a5f417cdae724c22b

https://anonscm.debian.org/cgit/debian-live/live-build.git/tree/functions/defaults.sh?id=1ccb41623046f2a8f823d62a5f417cdae724c22b

2) Not having to use awk each time I need to compare a first / default 
bootloader... when I can just use a variable with previous (once only) 
calculated value.




So...

1) I don't mind renaming "non first bootloader" or LB_FIRST_BOOTLOADER to
another terminology which makes more technical sense.
2) I prefer this approach over yours (Michal) because it's the own
bootloader which decides if it is more suited for "first bootloader" or not.


How does it decide that? It can install equally well in 1st, 2nd or
10th el-torito record. The only reason we want BIOS record first is


Inside the binary_bootloader file by running a function that shows that 
warning. The author of the binary_bootloader it's who decides where it's 

Bug#806215: mdadm: Problem also occurs with RAID1 array

[Daniel Sullivan]

Package: mdadm
Version: 3.3.2-5+deb8u1
Followup-For: Bug #806215

Dear Maintainer,

I've completed the questions in the template provided by reportbug below.

   * What led up to the situation?

 Ran full update and upgrade using apt-get at around 11AM on Tuesday,
 January 26th.
 Rebooted the machine and the problem occurred.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

 1. Mounted the root drive using a Debian Stable LiveCD.
 2. Commented out the line in /etc/fstab that mounted /dev/md0
to a folder in my home directory:
/dev/md0 [HOMEDIR] ext4 noatime,noexec,rw 0 0
 3. Rebooted the machine.
 4. Re-assembled the RAID1 array using
mdadm --assemble --force /dev/md0 /dev/sdb1,/dev/sdd1
 5. Uncommented the line in /etc/fstab mentioned in step 3.
 6. Mounted /dev/md0 to the original folder in my home directory using
mount --all
and confirmed that files could be read from the folder.
 7. Rebooted the machine.

   * What was the outcome of this action?

 Same problem. /dev/md0 was not created, and mdadm made no apparent
 attempts to re-assemble the RAID1 array after logging in.

   * What outcome did you expect instead?

 I expected the RAID1 array to be created as /dev/md0 and mounted to the
 folder in my home directory that I designated in /etc/fstab.

-- Package-specific info:
--- mdadm.conf
ARRAY /dev/md0 devices=/dev/sdb,/dev/sdd level=1 num-devices=2 auto=yes
CREATE owner=root group=disk mode=0660 auto=yes
HOMEHOST 
MAILADDR root

--- /etc/default/mdadm
INITRDSTART='none'
AUTOCHECK=true
START_DAEMON=true
DAEMON_OPTIONS="--syslog"
VERBOSE=false

--- /proc/mdstat:
Personalities :
unused devices: 

--- /proc/partitions:
major minor  #blocks  name

   80   78150744 sda
   81 248832 sda1
   82  1 sda2
   85   77899776 sda5
   8   16  976762584 sdb
   8   17  976761560 sdb1
   8   32 5860522584 sdc
   8   33 5860520960 sdc1
   8   48  976762584 sdd
   8   49  976761560 sdd1
  1101048575 sr0
 2540   77897728 dm-0
 2541   74690560 dm-1
 25423203072 dm-2

--- LVM physical volumes:
  PV VG   Fmt  Attr PSize  PFree
  /dev/mapper/sda5_crypt doofwagon-vg lvm2 a--  74.29g0
--- mount output
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=1013494,mode=755)
devpts on /dev/pts type devpts
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,relatime,size=1638800k,mode=755)
/dev/mapper/doofwagon--vg-root on / type ext4
(rw,relatime,errors=remount-ro,data=ordered)
securityfs on /sys/kernel/security type securityfs
(rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup
(rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/cpuset type cgroup
(rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup
(rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/devices type cgroup
(rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup
(rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup
(rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/blkio type cgroup
(rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/perf_event type cgroup
(rw,nosuid,nodev,noexec,relatime,perf_event)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs
(rw,relatime,fd=22,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
mqueue on /dev/mqueue type mqueue (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
/dev/sdc1 on /home/dnsullivan/library2 type ext4
(rw,noexec,noatime,data=ordered)
/dev/sda1 on /boot type ext2 (rw,relatime)
rpc_pipefs on /run/rpc_pipefs type rpc_pipefs (rw,relatime)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
tmpfs on /run/user/1000 type tmpfs
(rw,nosuid,nodev,relatime,size=819400k,mode=700,uid=1000,gid=1000)

--- initrd.img-3.16.0-4-amd64:
106904 blocks
131be8e959b59b6dc48c289966125cd4  ./sbin/mdadm
d11fdf5c4dc36e493e12540b64cc8fc4  ./conf/mdadm
599bbf3fe6093157a26863dcb59cdf5d  ./scripts/local-top/mdadm
1aa46962fd59231a7aef46f17ab354fd  ./etc/mdadm/mdadm.conf
d3be82c0f275d6c25b04d388baf9e836  ./etc/modprobe.d/mdadm.conf
07fb41218499d831672

Bug#812708: Same issue

[Yvan - Dugwood]

Before upgrading the package, if you run:
strace curl -O /dev/null -Iv https://www.ecod.pl
(I kept your url as a test)

=> stat("/etc/ssl/certs/98ec67f0.0", {st_mode=S_IFREG|0644, 
st_size=1155, ...}) = 0


ls -al /etc/ssl/certs/98ec67f0.0
lrwxrwxrwx 1 root root 28 avril 27  2015 /etc/ssl/certs/98ec67f0.0 -> 
Thawte_Premium_Server_CA.pem


ls -al /etc/ssl/certs/Thawte_Premium_Server_CA.pem
lrwxrwxrwx 1 root root 63 avril 29  2014 
/etc/ssl/certs/Thawte_Premium_Server_CA.pem -> 
/usr/share/ca-certificates/mozilla/Thawte_Premium_Server_CA.crt


But, after the upgrade:
stat("/etc/ssl/certs/98ec67f0.0", 0x7fff3c5501d0) = -1 ENOENT (No such 
file or directory)


Same file, but can't be found anymore.

I've already tried «sudo update-ca-certificates --fresh», with no luck, 
as there's no Thawte Premium CA anymore. The only way is to copy the 
file from an older release (see http://curl.haxx.se/docs/caextract.html, 
under «RSA-1024 removed»).


So far I don't know if the issue is the missing file or the fact that 
the certificate should be in another file, which is badly linked.


Best regards,
Yvan.

Bug#780530: [calendarserver]

[Rahul Amaram]

On Sunday 24 January 2016 04:13 AM, Ximin Luo wrote:

(k) Another bug that hit me with 7.0: I couldn't save events with unicode characters such 
as "ß" in them. Looking at the error log got me this:

2016-01-23 22:40:03+0100 [-] [caldav-0]  [-] [twistedcaldav.storebridge#error] 
Error while handling (calendar) PUT: 'ascii' codec can't decode byte 0xc3 in 
position 355: ordinal not in range(128)

Adding some "import traceback; traceback.print_exc()" to storebridge.py told me 
that the error was from pg8000/core.py:

2016-01-23 22:46:11+0100 [-] [caldav-1]  [-] Traceback (most recent call last):
2016-01-23 22:46:11+0100 [-] [caldav-1]  [-]   File 
"/usr/lib/python2.7/dist-packages/twistedcaldav/storebridge.py", line 2869, in 
http_PUT
2016-01-23 22:46:11+0100 [-] [caldav-1]  [-] response = (yield 
self.storeComponent(component, options=options))
[..]
many many lines omitted, omg
[..]
2016-01-23 22:46:11+0100 [-] [caldav-1]  [-]   File 
"/usr/lib/python2.7/dist-packages/txdav/base/datastore/dbapiclient.py", line 
83, in execute
2016-01-23 22:46:11+0100 [-] [caldav-1]  [-] self.realCursor.execute(sql, 
args)
2016-01-23 22:46:11+0100 [-] [caldav-1]  [-]   File 
"/usr/lib/python2.7/dist-packages/pg8000/core.py", line 910, in execute
2016-01-23 22:46:11+0100 [-] [caldav-1]  [-] self._c.execute(self, 
operation, args)
2016-01-23 22:46:11+0100 [-] [caldav-1]  [-]   File 
"/usr/lib/python2.7/dist-packages/pg8000/core.py", line 2031, in execute
2016-01-23 22:46:11+0100 [-] [caldav-1]  [-] val = send_func(value)
2016-01-23 22:46:11+0100 [-] [caldav-1]  [-]   File 
"/usr/lib/python2.7/dist-packages/pg8000/core.py", line 1353, in text_out
2016-01-23 22:46:11+0100 [-] [caldav-1]  [-] return 
v.encode(self._client_encoding)
2016-01-23 22:46:11+0100 [-] [caldav-1]  [-] UnicodeDecodeError: 'ascii' codec 
can't decode byte 0xc3 in position 322: ordinal not in range(128)
2016-01-23 22:46:11+0100 [-] [caldav-1]  [-] [twistedcaldav.storebridge#error] 
Error while handling (calendar) PUT: 'ascii' codec can't decode byte 0xc3 in 
position 322: ordinal not in range(128)

Adding some debugging code reveals that text_out() is called with both unicode() and 
str() objects. When I do PUT, the event object is serialised into a str 
"BEGIN:VCALENDER..." and eventually makes its way to text_out(), causing an 
exception.

Experimenting a bit, the errors go away and I can save the event again, if I 
patch pg8000 like this:


diff --git a/pg8000/core.py b/pg8000/core.py
index 246e0b6..14093cc 100644
--- a/pg8000/core.py
+++ b/pg8000/core.py
@@ -1350,6 +1350,7 @@ class Connection(object):
  self.ParameterStatusReceived += self.handle_PARAMETER_STATUS
  
  def text_out(v):

+if not isinstance(v, text_type): return v
  return v.encode(self._client_encoding)
  
  def time_out(v):



I will forward this bug upstream to pg8000. It may *also* be a bug on the 
calendarserver side, but I'm pretty sure pg8000 should be fixed as well - since 
text_out() is an internal function, if pg8000 has any requirements on the input 
it receives from calendarserver, it should raise a better error message 
*before* it gets to text_out().

X



Ok. I have included this as a patch. I am almost done with everything, 
except for the following bug while ugrading. After upgarding from 5.2.2 
as per the instructions in READE.Debian (which I have updated), I am 
seeing the following errors in error.log whenever I try to connect via 
Icedove:


===

2016-01-27 02:54:58+0530 [BinaryBoxProtocol,1,] Unhandled Error
Traceback (most recent call last):
  File 
"/usr/lib/python2.7/dist-packages/twisted/protocols/amp.py", line 954, 
in _commandReceived

deferred = self.dispatchCommand(box)
  File 
"/usr/lib/python2.7/dist-packages/twisted/protocols/amp.py", line 1011, 
in dispatchCommand

return maybeDeferred(responder, box)
  File 
"/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 150, 
in maybeDeferred

result = f(*args, **kw)
  File 
"/usr/lib/python2.7/dist-packages/twisted/protocols/amp.py", line 1100, 
in doit

return maybeDeferred(aCallable, **kw).addCallback(
---  ---
  File 
"/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 150, 
in maybeDeferred

result = f(*args, **kw)
  File 
"/usr/lib/python2.7/dist-packages/calendarserver/accesslog.py", line 
685, in logStats

self.observer.logStats(stats)
  File 
"/usr/lib/python2.7/dist-packages/calendarserver/accesslog.py", line 
378, in logStats

self.systemStats = SystemMonitor()
  File 
"/usr/lib/python2.7/dist-packages/calendarserver/accesslog.py", line 
587, in __init__
"cpu count" : psutil.NUM_CPUS if psutil is not None 
else -1,
exceptions.AttributeError: 'module' objec

Bug#809265: debci: FTBFS: ./test_blame.sh failed at least one test (test_passing_the_test_resets_the_blame?)

[Antonio Terceiro]

On Tue, Jan 26, 2016 at 09:10:09PM +0100, Chris Lamb wrote:
> Hi,
> 
>* test/test_blame.sh: Sleep for one second between process() calls, to
>  ensure that timestamps in run IDs are different. (Closes: #809265)
> 
> http://anonscm.debian.org/cgit/collab-maint/debci.git/commit/?id=2bbce0782ca079073c2504dacf00058ac4e70420
> 
> Can you elaborate how that sleep ensures the ids are the different? Are they 
> based on a timestamp..?

yes, exactly that. the id is mmddHHMMSS


signature.asc
Description: PGP signature

Bug#650601: libpng is ready for transtion

[Tobias Frost]

Am Dienstag, den 26.01.2016, 20:45 +1100 schrieb Aníbal Monsalve
Salazar:
> On Tue, 2016-01-26 10:23:13 +0100, Tobias Frost wrote:
> > > Tobias Frost  (2016-01-25):
> > > > Dear release-team,
> > > > 
> > > > Now that all NMUs are in DELAYED for all fixables.
> > > > I think we are ready to throw the switch.
> > > 
> > > You haven't answered <20160106232316.ga28...@mraw.org>.
> > > 
> > > Mraw,
> > > KiBi.
> > > 
> > 
> > Nobuhiro, Anibal,
> > 
> > this is a question for you:
> > 
> > https://lists.debian.org/debian-devel/2016/01/msg00248.html
> > 
> > {quote}
> > Speaking of this particular udeb, I've just spotted libpng16-16-
> > udeb has
> > a Conflicts against libpng12-0-udeb. I'm not sure why, and the
> > changelog
> > doesn't seem to explain either. libpng16-16 and libpng12-0 seems to
> > be
> > co-installable, so I'm not sure why their respective udebs
> > shouldn't be.
> > {/quote}
> 
> The Conflicts against libpng12-0-udeb can be removed.

Hi Anibal,

OK to NMU that or do you want to do the upload yourself?

diff -Nru libpng1.6-1.6.20/debian/changelog libpng1.6-
1.6.20/debian/changelog
--- libpng1.6-1.6.20/debian/changelog   2016-01-24 11:26:12.0
+0100
+++ libpng1.6-1.6.20/debian/changelog   2016-01-26 22:28:29.0
+0100
@@ -1,3 +1,10 @@
+libpng1.6 (1.6.20-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * libpng16-16-udeb should not Conflicts: libpng-12-0
+
+ -- Tobias Frost   Tue, 26 Jan 2016 22:27:21 +0100
+
 libpng1.6 (1.6.20-1.1) experimental; urgency=medium
 
   * Non-maintainer upload.
diff -Nru libpng1.6-1.6.20/debian/control libpng1.6-
1.6.20/debian/control
--- libpng1.6-1.6.20/debian/control 2016-01-24 11:29:17.0
+0100
+++ libpng1.6-1.6.20/debian/control 2016-01-26 22:28:22.0
+0100
@@ -71,7 +71,6 @@
 Priority: extra
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}
-Conflicts: libpng12-0-udeb
 Description: PNG library - minimal runtime library (version 1.6)
  libpng is a library implementing an interface for reading and writing
  PNG (Portable Network Graphics) format files.

Bug#714232: Debian bts#714232: tsort manual page does not describe input format

[Thilo Six]

Hello Brian,
Hello Bob,

lately coreutils 8.24 has been uploaded to unstable and through p.d.o and pts i
landed here.

Reading through this discussion in this bugreport gave me some new knowledge.
So thanks to both of you.

Well actually that alone would not be sufficient for an entry in this 
discussion.

I think i can understand Brians point. I used to feel info pages discouraging
myself for a long time. Info pages feel like wiki pages, no start no end and it
is difficult to keep track where you came from.

Now through this discussion here i noticed this distraction about info pages
seems to be a bug in pinfo rather then in info pages them self.
With coreutils info one ,  through info pages like in man. pinfo
rather seems to stop that where a new topic begins.

I am not sure whether this is new in more recent version of info though.
But this made me reconsider my decision toward pinfo as primary info pages 
viewer.

Extra Points:
I wrote this tiny little function (attached) which makes it irrelevant which
info implementation one uses. With it all of these will lead to the same 
location:

% info '(coreutils) tsort invocation'
% info coreutils "tsort invocation"
% info coreutils tsort invocation

I really like it when my computer learns to adapt to my habbits and not the
other way round!

btw.: The attached function surely has Zsh'isms. Should be straight forward to
backport (scnr) to bash.  ;)


Hope you find this useful.



kind regards,

 Thilo


# vim: ts=8:sw=4:sts=4:et:ft=zsh:
# kate: byte-order-marker false; dynamic-word-wrap false; indent-mode normal; 
indent-pasted-text true; indent-width 4; keep-extra-spaces false; 
newline-at-eof true; remove-trailing-spaces all; replace-tabs true; 
replace-tabs-save true; show-tabs true; smart-home true; syntax Zsh; tab-width 
8; word-wrap false;
#---
#

# info() {
builtin emulate -L zsh && builtin setopt csh_null_glob NO_glob_dots 
NO_sh_word_split NO_ksh_arrays unset \
NO_extended_glob
local -a prog node
# if check_com -c pinfo ; then
# prog=(command pinfo)
# else
prog=(command  info)
# fi
case ${#} in
(1)
${prog} ${1}
;;
(*)
if [[ ${prog} == *pinfo ]] ; then
${prog} ${1} --node="${*[2,$]}"
else
${prog} \(${@[1]}\) "${*[2,$]}"
fi
;;
esac
# }

# vim: ts=8:sw=4:sts=4:et:ft=zsh:
# kate: byte-order-marker false; dynamic-word-wrap false; indent-mode normal; 
indent-pasted-text true; indent-width 4; keep-extra-spaces false; 
newline-at-eof true; remove-trailing-spaces all; replace-tabs true; 
replace-tabs-save true; show-tabs true; smart-home true; syntax Zsh; tab-width 
8; word-wrap false;
#---
#

# pinfo() {
builtin emulate -L zsh && builtin setopt csh_null_glob NO_glob_dots 
NO_sh_word_split NO_ksh_arrays unset \
NO_extended_glob
info "${@}"
# }

Bug#812817: TLS_DHPARAMS misconfiguration

[Jacob Shreffler]

Package: courier-mta-ssl
Version: 0.73.1-1.6

A clean install with no user supplied config files results in 
/etc/courier/esmtpd-ssl having the line 
"TLS_DHPARAMS=/usr/lib/courier/dhparams.pem", but the output of 
mkdhparams sensibly places dhparams.pem in /etc/courier/dhparams.pem.


As I am ignorant concerning the upstream build, I don't know whether the 
misconfiguration results from special debian build parameters or not. I 
do notice that there are man pages for other certificate mk* utilities 
accompanying courier that use the /usr/lib prefix as a default.


I know of no good reason why the user should have to bother knowing to 
change TLS_DHPARAMS to a default filepath like /etc/courier/dhparams.pem.


Therefore, I suggest patching esmtpd-ssl so that it includes 
"TLS_DHPARAMS=/etc/courier/dhparams.pem". Alternatively, I suggest some 
sort of patch which by default creates a soft link which permits 
accession of dhparams.pem from either path.


Please consider moving this misconfiguration issue upstream if applicable.

Bug#812358: debian-live: Please add gparted

[Don Raikes]

Ben,

When I do 
$ apt-get live-images 

>From within jesse, I see a /usr/share/live/images/rescue folder and except for 
>about 4 packages it seems to build fine.

Couldn't we just fixup those few packages and/or remove them from the 
package-list and be good?

Or is this more a matter of debian has decided to go a different direction with 
tasksel-* and blends?

-Original Message-
From: Ben Armstrong [mailto:sy...@sanctuary.nslug.ns.ca] 
Sent: Saturday, January 23, 2016 4:32 AM
To: adrian15; Don Raikes; 812...@bugs.debian.org; Devin Trotter
Subject: Bug#812358: debian-live: Please add gparted

On 22/01/16 07:46 PM, adrian15 wrote:
> 1) There was some discussion about the original dba plans on 
> submitting a tasksel-rescue package versus what it's currently used:
>
> * task-rescue (task-* is official tasks maintained by the d-i team).
> * blendname-tasks (Already used in blends for their specific stuff.)
>
> What I mean is that my article begins with me trying to make a 
> tasksel-rescue package and it turns out that this package name not 
> even exists.
>
> 2) Ben Armstrong wanted to reuse some of the packages I used on 
> Rescatux. I warned him that Rescatux was graphical oriented and that I 
> left out some cli tools from it. Some sysadmins might consider using 
> grml instead of Rescatux for cli purposes just for that.

If the three of you wanted to make a blend that provides a set of rescue tools 
on a live image (or maybe more than one, if you decide there is a need for it), 
I could help in an administrative capacity (alioth project, mailing list, etc.)

Ben

Bug#669053: smartd.conf.5.in, version 5.42: Escape before "<" and ">", spaces and orthography in the manual.

[Bjarni Ingi Gislason]

On Mon, Jan 25, 2016 at 11:50:56AM +, Jonathan Dowland wrote:
[...]
> This is a substantial amount of the patch (in lines-changed terms).
> Is there a technical reason for this?

  Yes.
In man-pages the technical issue is to have
every sentence begin on a new line
or (worse) sentences are separated with two spaces.

  References are:

  1) man-pages(7) from package "man-pages" or
"www.kernel.org/doc/man-pages" section 7 or
"man7.org/linux/man-pages/man7/man-pages.7.html:

New sentences should be started on new lines.
This makes it easier to see the effect of patches,
which often operate at the level of individual sentences.

[The above is an example of how to write text,
making any "subsentence" (subordinate clause) start on its own line.]

  2) groff_diff(7) in package "groff":

In GNU troff, as in UNIX troff, you should always follow a sentence
with either a newline or two spaces.

  3) "info groff":

  Search for "sentence" to get more hints about input conventions.

-- 
Bjarni I. Gislason

Bug#654924: [Pkg-tigervnc-devel] Bug#654924: Bug#654924: Helping with tigervnc 1.5.0

[Yaroslav Halchenko]

On Tue, 26 Jan 2016, Ola Lundqvist wrote:

>Hi
>I think we should try to finalize 1.5 first, unless we see major issues
>with that, or if you know what they have fixed important things in 1.6.

nope -- I know nothing yet about 1.6 ;-)  so ok -- let's finalize 1.5.

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#812816: gbp-clone: user-defined post-clone script

[IOhannes m zmoelnig]

Package: git-buildpackage
Version: 0.7.1
Severity: wishlist

Dear Maintainer,

i find myself repeatedly doing certain tasks after a fresh clone of a packaging
repository.
gbp-clone helps a bit, but i find that i need more:
- ignore quilt's ".pc" directory (reported as #812815)
- set 'push.followTags' via git-config, so i don't forget to push tags :-)

while i think the former is of general interest (hence the separate bug-report),
i think that the latter might be very specific to my personal workflow (and
therefore not a good addition to gbp in general).

so here's an idea:
it would be great if once could specify a script within the repository that is
run after 'gbp clone' has finished. e.g.

 $ gbp clone --post-clone-script=debian/gitfix.sh 
git+ssh://honk.sigxcpu.org/git/git-buildpackage.git

 $ cat git-buildpackage/debian/gitfix.sh
 echo '/.pc/' >> .git/info/exclude
 git config push.followTags true 

 $

now this becomes really powerful in conjunction with gbp.conf:

 $ gbp clone --post-clone-script=debian/gitfix.sh 
git+ssh://honk.sigxcpu.org/git/git-buildpackage.git

 $ cat git-buildpackage/debian/gpg.conf
 [DEFAULT]
 pristine-tar = True
 sign-tags = True
 [clone]
 post-clone-script = debian/gitfix.sh


the security implications and their fixes are left as an exercise for the 
reader.

gfmasrd
IOhannes

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

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

Versions of packages git-buildpackage depends on:
ii  devscripts2.15.10
ii  git   1:2.7.0-1
ii  man-db2.7.5-1
ii  python-dateutil   2.4.2-1
pn  python-pkg-resources  
ii  python-six1.10.0-1
pn  python:any

Versions of packages git-buildpackage recommends:
ii  cowbuilder   0.78
ii  pbuilder 0.222
ii  pristine-tar 1.33
ii  python-requests  2.9.1-1

Versions of packages git-buildpackage suggests:
ii  python-notify  0.1.1-4
ii  sudo   1.8.15-1.1
ii  unzip  6.0-20

-- no debconf information

Bug#702134: Processed: retitle 702134 to ITP: koha -- Koha Integrated Library System, owner 702134

[Jonas Smedegaard]

Quoting Dmitry Smirnov (2016-01-25 19:05:10)
> On Mon, 25 Jan 2016 01:09:04 PM Debian Bug Tracking System wrote:
>>> retitle 702134 ITP: koha -- Koha Integrated Library System
>
> It is really awesome that you are working on Koha, Jonas.
>
> I wish I had time to give you a hand but likely I won't be able to do 
> so anytime soon. I only want to aks you to consider using DH packaging 
> layout instead of CDBS to make co-maintenance easier. Thank you.

Sorry, I cannot package using short-form dh sequencer.

If someone steps up to maintain this package instead of me then please 
speak up now, and I will happily hand over the maintenance task.  If 
not, then I will do it the way I can do it efficiently, which is using 
CDBS.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#650601: libpng is ready for transtion

[Tobias Frost]

Hallo KiBi,

On Tue, 26 Jan 2016 10:51:11 +0100 Cyril Brulebois 
wrote:

> Has anyone tested a debian installer build where some packages were
> built against libpng12-0-udeb and some other against libpng16-16-
udeb?
> Does that work? Or are we looking at a giant transition where
everything
> must switch to libpng16 at once?
> 
> Mraw,
> KiBi.

As requested, I performed those build of the d-i, version 20160106: 

Testmatrix

A libcairo2-udeb_1.14.6-1.1~libpng16_amd64.udeb
B libdirectfb-1.2-9-udeb_1.2.10.0-5.2~libpng16_amd64.udeb 
C libfreetype6-udeb_2.6.1-0.2~libpng16_amd64.udeb
D libgdk-pixbuf2.0-0-udeb_2.32.3-1.1~libpng16_amd64.udeb
E libpng16-16-udeb_1.6.20-1.2~libpng16+patched+1_amd64.udeb
F matchbox-keyboard-udeb_0.1+svn20080916-10.1~libpng16_amd64.udeb

Two more udeb packages where generated during the mass rebuild on my
server, bu removed from test-matrix, as they do not Depend: on libpng:
libslang2, libdirectfb-bin

Key x -> libpng16-version used
. -> standard version used

   A B C D E F   result   (comment)
1  . . . . . .   builds   "control group"
2  x . x . x .   builds 
3  . x x . x .   builds
4  . . . x x .   builds
5  . x . x x x   builds   
6  x x x x x x   builds   "target version" 


Procedure:
- debuld in debian-installer directory.
- examination of created debian-installer-images tarball, especially
the MANIFEST.udebs file for installed udebs (if matches expectations,
if both libpngs are present


Let me know if you want to see other combinations tested too (and
which)

Thanks
-- 
tobi

Bug#654924: [Pkg-tigervnc-devel] Bug#654924: Bug#654924: Helping with tigervnc 1.5.0

[Ola Lundqvist]

Hi

I think we should try to finalize 1.5 first, unless we see major issues
with that, or if you know what they have fixed important things in 1.6.

Best regards,

// Ola

On Tue, Jan 26, 2016 at 6:21 PM, Yaroslav Halchenko 
wrote:

>
> On Tue, 26 Jan 2016, Geoffrey Thomas wrote:
>
> > Hi maintainers,
>
> > I'm interested in using tigervnc for its 3D acceleration support. I
> > built tigervnc 1.5.0 from git (4a25ccd) on jessie, with a no-change
> > backport of fltk1.3 1.3.3-6, and it seems to work very well out of the
> > box: I can run GNOME 3 with llvmpipe inside the server, and the client
> > also works well.
>
> that is great news since for me that revision was segfaulting but could
> be due to my crude setup ... or may be since I have tried on stretch/sid
> mix.  Thanks!
>
> > Is there anything I can do to help get this package into Debian? I see
> > the thread at
> >
> http://lists.alioth.debian.org/pipermail/pkg-tigervnc-devel/Week-of-Mon-20160125/thread.html
> > seems to be making good progress. If I can do more testing or look at
> > copyrights or something, just let me know what's helpful!
>
> AFAIK Ola is looking into updating it to 1.6 release.  If you could
> indeed make a pass to refresh debian/copyright -- that would be awesome.
>
> Ola -- what do you think -- should we aim for upload of 1.6 or we could
> finalize 1.5 may be first?  if 1.6 -- then would be nice to import/merge
> upstream so that Geoffrey could have a pass on up-to-date source base
>
> > Thanks for your work in packaging this.
>
> You are most welcome -- thanks for offering your help!
>
> --
> Yaroslav O. Halchenko
> Center for Open Neuroscience http://centerforopenneuroscience.org
> Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
> Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
> WWW:   http://www.linkedin.com/in/yarik
>
> ___
> Pkg-tigervnc-devel mailing list
> pkg-tigervnc-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-tigervnc-devel
>



-- 
 - Ola Lundqvist ---
/  o...@debian.org Annebergsslingan 37  \
|  o...@inguza.com  654 65 KARLSTAD  |
|  http://inguza.com/  +46 (0)70-332 1551   |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---

Bug#812814: CVE-2015-7578 CVE-2015-7579 CVE-2015-7580

[Moritz Muehlenhoff]

Package: ruby-rails-html-sanitizer
Severity: grave
Tags: security

Please see
https://marc.info/?l=oss-security&m=145375052028672&w=2
https://marc.info/?l=oss-security&m=145375059928688&w=2
https://marc.info/?l=oss-security&m=145375090928793&w=2

Cheers,
Moritz

Bug#812815: git-buildpackage: ignore "/.pc/" directory for "3.0 (quilt)"

[IOhannes m zmoelnig]

Package: git-buildpackage
Version: 0.7.1
Severity: wishlist

Dear Maintainer,

'gbp clone' provides a nice wrapper around 'git clone' that helps dealing with
packaging repositories.

now one of the things i need to do with many packaging repositories is to ignore
the /.pc/¹ directory created when maintaining patches with quilt.
as i don't want to touch /.gitignore (being outside of the /debian/ directory;
potentially conlicting with upstream's .gitignore), what i usually do is²:

 echo "/.pc/" >> .git/info/exclude

it would be great if 'gpb clone' could do this automatically for me (probably
only if the source-format is set to "3.0 (quilt)" in debian/source/format)

mgfards
IOhannes

¹ rooted in the packaging directory
² or rather: egrep "^/?\.pc/?$" .git/info/exclude >/dev/null || (echo "/.pc/" 
>> .git/info/exclude)

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

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

Versions of packages git-buildpackage depends on:
ii  devscripts2.15.10
ii  git   1:2.7.0-1
ii  man-db2.7.5-1
ii  python-dateutil   2.4.2-1
pn  python-pkg-resources  
ii  python-six1.10.0-1
pn  python:any

Versions of packages git-buildpackage recommends:
ii  cowbuilder   0.78
ii  pbuilder 0.222
ii  pristine-tar 1.33
ii  python-requests  2.9.1-1

Versions of packages git-buildpackage suggests:
ii  python-notify  0.1.1-4
ii  sudo   1.8.15-1.1
ii  unzip  6.0-20

-- no debconf information

Bug#810830: closed by Manoj Srivastava (Flex produces some basic errors in lex.yy.c)

[Manoj Srivastava]

On Mon, Jan 25 2016, André Z.D.A. wrote:

> I ask you to be more kind with this issue, and I have reasons to consider
> it a clear problem in Flex (this is the reason why I reported it as a
> bug).
>
> "Using flex normally seems to work." -> Why do you consider the way I used
> flex as not normal? I think I did the most normal and common steps that
> everyone should do. Let me describe.

You are not using flex as provided by Debian. You could go and
 report a bug against upstream flex if you do not wish to uyse the
 Debian provided package, and use the upstream, unpatched version
 yourself.

> Now I want to use flex. So I download its source code, compile it, and
> install according the documentation that comes with it. What is the
> result? It doesn't work! And the original bug report shows all the
> details I think that are relevant to point the problem, and (I hope)
> to fix the problem. Is it related to flex? Of course! It got a working
> setup machine and could not work with it! We need a correct setup and
> flex do not have it.

You can report bugs in the downloaded flex here:
 http://sourceforge.net/p/flex/bugs/?source=navbar

Manoj
-- 
"The cat has too much spirit to have no heart."  --Ernest Menaul
Manoj Srivastava    
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C


smime.p7s
Description: S/MIME cryptographic signature

Bug#812362: jessie-pu: package giflib/4.1.6-11+deb8u1

[Adam D. Barratt]

Control: tags -1 + pending

On Mon, 2016-01-25 at 07:33 +0100, Guido Günther wrote:
> On Sun, Jan 24, 2016 at 07:28:39PM +, Adam D. Barratt wrote:
> > Control: tags -1 + confirmed
> > 
> > On Fri, 2016-01-22 at 19:49 +0100, Guido Günther wrote:
> > > I'd like to fix CVE-2015-7555 via jessie-pu since the bug is fixed in
> > > Squeeze LTS and we try to not introduce new security issues when people
> > > upgrade (the Debian security team marked this CVE as no-dsa).
> > 
> > Please go ahead.
> 
> Uploaded. Thanks a lot!

Flagged for acceptance, thanks.

Regards,

Adam

Bug#812363: wheezy-pu: package giflib/4.1.6-10+deb7u1

[Adam D. Barratt]

Control: tags -1 + pending

On Mon, 2016-01-25 at 08:16 +0100, Guido Günther wrote:
> On Sun, Jan 24, 2016 at 07:27:47PM +, Adam D. Barratt wrote:
> > Control: tags -1 + confirmed
> > 
> > On Fri, 2016-01-22 at 19:50 +0100, Guido Günther wrote:
> > > I'd like to fix CVE-2015-7555 via wheezy-pu since the bug is fixed in
> > > Squeeze LTS and we try to not introduce new security issues when people
> > > upgrade (the Debian security team marked this CVE as no-dsa).
> > 
> > Please go ahead, with "wheezy" in the changelog rather than
> > "oldstable-security".
> 
> Uploaded now. Thanks!

Flagged for acceptance.

Regards,

Adam